Re: Unexpected behavior from PR server

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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.

Cheers,

Richard



> Peter
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core