From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (dan.rpsys.net [93.97.175.187]) by mail.openembedded.org (Postfix) with ESMTP id 558F66A453 for ; Sun, 8 Sep 2013 11:05:07 +0000 (UTC) Received: from localhost (dan.rpsys.net [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r88BIUxE008121; Sun, 8 Sep 2013 12:18:30 +0100 X-Virus-Scanned: Debian amavisd-new at dan.rpsys.net Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4_QUV6IobH_r; Sun, 8 Sep 2013 12:18:30 +0100 (BST) Received: from [192.168.3.10] (rpvlan0 [192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r88BISe2008117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 8 Sep 2013 12:18:29 +0100 Message-ID: <1378638296.3484.63.camel@ted> From: Richard Purdie To: "Peter A. Bigot" Date: Sun, 08 Sep 2013 12:04:56 +0100 In-Reply-To: <1378629609.3484.50.camel@ted> References: <522B8B50.6080508@pabigot.com> <1378629609.3484.50.camel@ted> X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Cc: OE-core Subject: Re: Unexpected behavior from PR server X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 11:05:08 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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