[OE-core] Unexpected behavior from PR server

[Richard Purdie]

On Sun, 2013-09-08 at 09:40 +0100, Richard Purdie wrote:
> On Sat, 2013-09-07 at 15:23 -0500, Peter A. Bigot wrote:
> > I'm apparently a little shaky on exactly how the PR service is supposed 
> > to work.  I noticed an anomaly that adding a patch to SRC_URI for u-boot 
> > did not result in a new package revision as I expected.  I'm using 
> > PRSERV_HOST="localhost:0" and have bulidhistory enabled.
> > 
> > I just tried this with a toy recipe named "hello" with a constant PR=r1 
> > which does nothing but install a file from SRC_URI into ${datadir} with 
> > this:
> > 
> > PR = "r1"
> > 
> > SRC_URI = " \
> >      file://file1 \
> > "
> > 
> > S = "${WORKDIR}"
> > 
> > do_install () {
> >    install -d ${D}/${datadir}/files
> >    install file* ${D}/${datadir}/files
> > }
> > 
> > FILES_${PN} = "${datadir}/files/*"
> > 
> > I started with one file in SRC_URI, and "bitbake hello" produced 
> > hello-1.0-r1.0.armv7a_vfp_neon.rpm as I expected.
> > 
> > I then added a second file to SRC_URI and re-ran "bitbake hello". The 
> > recipe stages were re-executed, the new file was fetched and installed, 
> > and I now have a hello-1.0-r1.0.armv7a_vfp_neon.rpm (same name) with 
> > different contents.  Build history confirms the differences in the 
> > package FILELIST but no change to PKGR, as does dumping the rpm contents.
> > 
> > It is true that changing SRC_URI had no effect on the run.* task script 
> > contents for the package, so it makes sense that the PR server doesn't 
> > detect that the package is different from the last time it was built if 
> > signatures from those scripts are the only way recipe changes are 
> > detected.  But it very much surprises me that changing the sources does 
> > not result in a PR bump.  In the normal work flow, adding a new patch to 
> > SRC_URI is certainly something that I would expect to produce a new 
> > package revision.
> > 
> > Is this how it's supposed to work?
> 
> It appears that something is broken :/
> 
> I'll see if I can figure out exactly what but it seems to be something
> in the PR server itself.

Found the problem, the PR server wasn't persisting data after some
recent changes. I've fixed it. Thanks for reporting that.

Cheers,

Richard