<div dir="ltr">As the commit says, small change in package.bbclass also causes all packages to be recreated with PR bump even when the content is most likely the same.<div><br></div><div>Fixing bug in gcc may at least provide different binaries so it might be useful to upgrade them on target (or at least distinguish if they were already rebuilt with fixed gcc-cross or not).</div><div><br></div><div>Reverting the commit doesn't fix the issue that sstate handler cannot compare if the change in signature produced "significantly different" binaries. If it's reverted in oe-core I'll just revert the revert in our builds, because we care about reproducible builds and we already gave up on working upgrade paths, which are broken too often anyway.</div><div><br></div><div>Reflash of "system" partitions and storing user data/configuration somewhere else is faster and safer since the sstate was invented (since we stopped using OE classic). You can find some rant e-mails from me about this e.g.</div><div><a href="http://lists.openembedded.org/pipermail/openembedded-core/2011-November/051354.html">http://lists.openembedded.org/pipermail/openembedded-core/2011-November/051354.html</a><br></div><div>and the Yocto bug I gave you.</div><div><br></div><div>Regards,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 4:33 AM, Robert Yang <span dir="ltr"><<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Martin,<br>
<br>
I found this patch in the bug:<br>
<br>
<a href="http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/sstatesig.py?id=336a7897e39b9e42dcfcba9e2520ea96b0c6a8d6" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/sstatesig.py?id=336a7897e39b9e42dcfcba9e2520ea96b0c6a8d6</a><br>
<br>
Too many PR bumps and rebuildings are caused by this patch. I'm<br>
not very sure about what this patch tries to fix, it seems that<br>
it is trying to fix problems when 32bit and 64bit uses the same<br>
sstate cache? Would you please provide a simple reproducer, please?<br>
<br>
Things will become much better after revert this patch. Be less<br>
stricter or more is a hard problem, if we still need the patch,<br>
can we leave such a choice to the end user? We can add some vars<br>
like DROP_NATIVE_SIG ? = "0/1". This would be good to the end user<br>
who uses stable release like jethro or krogoth to make their<br>
distributions, and PR Service really matters here. Even if they<br>
switch the build between 32 and 64 builds (This is unlikely to<br>
happen for production environment) and got problems, they still<br>
can fix the problem by rebuilding, this is still much better than<br>
current status: run a "smart/opkg/apt-get upgrade" on the target,<br>
*all* of the packages are downloaded and installed again after a<br>
CVE patch applies on native recipes like pseudo-native or rpm-native,<br>
but in fact, nothing is changed on the target this is really a bad<br>
experience.<span class="HOEnZb"><font color="#888888"><br>
<br>
// Robert</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 05/18/2016 06:15 PM, Martin Jansa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, May 18, 2016 at 05:31:09PM +0800, Robert Yang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 05/18/2016 05:20 PM, Martin Jansa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, May 18, 2016 at 04:03:58PM +0800, Robert Yang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Martin,<br>
<br>
On 05/18/2016 03:39 PM, Martin Jansa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
See:<br>
<a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970" rel="noreferrer" target="_blank">https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970</a><br>
<br>
Just using recipe checksum wont work, because the main reason for PR bumps is to<br>
automatically upgrade the packages when one of the dependencies changes .so<br>
version, which you won't detect from recipe checksum of the app which is just<br>
using the library.<br>
</blockquote>
<br>
For the development branch like master, yes, that would happen. But for<br>
the stable release like jethro and krogoth, it is unlikely that would<br>
happen, and if if does, the user can manually bump the impacted recipe's<br>
PR to fix the problem. The current problem is that when *all* recipes'<br>
PR are bumped, there is no way to fix the problem.<br>
</blockquote>
<br>
You can still stop using PR service and start doing manual PR bumps, but<br>
</blockquote>
<br>
We can't stop PR service and start doing manual PR bumps since we need keep<br>
update to date with upstream, the changes from upstream don't do the manual<br>
PR, and I don't think that we have to if they can be done automatically.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it's quite annoying if you need to bump a lot of recipes you don't<br>
control :).<br>
</blockquote>
<br>
What's your opinion about only consider RDEPENDS for PR service's checksum,<br>
please ?<br>
</blockquote>
<br>
I would like to have separate handler as described in that bug, option<br>
c).<br>
<br>
Not only because of unnecessary EXTENDPRAUTO bumps, but also unnecessary rebuilds.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, May 18, 2016 at 8:09 AM, Robert Yang <<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>> wrote:<br>
<br>
The PRServer bumps PR according to do_package's task hash, that<br>
causes it bumps *all* packages' PR when recipes like pseudo-native<br>
and rpm-native is changed. It is a very bad user experience when we<br>
run "smart/opkg upgrade" on running target, for example, when we apply<br>
a CVE patch to pseudo-native or rpm-native, or do some slight changes<br>
in their do_compile, "smart/opkg upgrade" will download/install *all*<br>
the packages since all of the packages' PR are bumped.<br>
<br>
Here are some rough suggestions to fix this problem, and please feel<br>
free to give your suggestions.<br>
1) Do not use do_package's task for bumping PR, the easiest way<br>
is simulate manually bump PR -- only bump PR when the recipe<br>
itself's checksum is changed.<br>
<br>
2) Add a new task for PRServer, redefine its task hash for bumping<br>
PR, for example, this task hash only considers RDEPENDS (no<br>
DEPENDS), and drop any native dependencies.<br>
<br>
I prefer the first way, and an alternative way maybe add a var so that<br>
the user can configure it:<br>
PR_CHECKSUM = "${BB_TASKHASH}" (current way)<br>
Or<br>
PR_CHECKSUM = "<recipe checksum>"<br>
<br>
--<br>
Thanks<br>
<br>
Robert<br>
--<br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<mailto:<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a>><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
<br>
<br>
</blockquote></blockquote>
<br>
</blockquote></blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div>