* Unexpected behavior from PR server
@ 2013-09-07 20:23 Peter A. Bigot
2013-09-08 8:40 ` Richard Purdie
0 siblings, 1 reply; 3+ messages in thread
From: Peter A. Bigot @ 2013-09-07 20:23 UTC (permalink / raw)
To: OE-core
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?
Peter
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Unexpected behavior from PR server
2013-09-07 20:23 Unexpected behavior from PR server Peter A. Bigot
@ 2013-09-08 8:40 ` Richard Purdie
2013-09-08 11:04 ` Richard Purdie
0 siblings, 1 reply; 3+ messages in thread
From: Richard Purdie @ 2013-09-08 8:40 UTC (permalink / raw)
To: Peter A. Bigot; +Cc: OE-core
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Unexpected behavior from PR server
2013-09-08 8:40 ` Richard Purdie
@ 2013-09-08 11:04 ` Richard Purdie
0 siblings, 0 replies; 3+ messages in thread
From: Richard Purdie @ 2013-09-08 11:04 UTC (permalink / raw)
To: Peter A. Bigot; +Cc: OE-core
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-09-08 11:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-07 20:23 Unexpected behavior from PR server Peter A. Bigot
2013-09-08 8:40 ` Richard Purdie
2013-09-08 11:04 ` Richard Purdie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox