On Fri, May 08, 2015 at 03:28:52PM -0400, Denys Dmytriyenko wrote: > On Wed, May 06, 2015 at 07:31:37PM -0400, Denys Dmytriyenko wrote: > > On Wed, May 06, 2015 at 09:12:43PM +0200, Steffen Sledz wrote: > > > Am 02.05.2015 um 23:55 schrieb Andrea Adami: > > > > On Fri, May 1, 2015 at 6:06 PM, Denys Dmytriyenko <de...@denix.org> > > > > wrote: > > > >> Has anyone ever seen this message during <image>.do_rootfs task? > > > >> > > > >> Collected errors: > > > >> * opkg_install_pkg: Package <package> md5sum mismatch. Either the > > > >> opkg or the package index are corrupt. Try 'opkg update'. > > > >> * opkg_install_cmd: Cannot install package <package>. > > > >> > > > >> We started seeing it on random packages inside the <image> few weeks > > > >> ago on > > > >> different machines. At the time we had switched to bitbake 1.26. But > > > >> even > > > >> trying different bitbake versions still occasionally caused the same > > > >> error, so > > > >> the culprit is still unknwon. Using oe-core/daisy for now. > > > >> > > > >> Any comments or suggestions to where start looking would be > > > >> appreciated! > > > > > > > > yes, I have seen this during multimachine builds. > > > > My TMPDIR is on tmpfs in ram so everytime I reboot it is re-populated > > > > from sstate. > > > > ... > > > > > > We have the same problem here. Also with packages from the "all" feed in > > > a > > > multimachine build environment. But it does not seem related to > > > packagegroups. > > > > > > I've a hypothesis but was not able to validate or falsify it till now: > > > Given > > > a recipe which does only use file:// type SRC_URI. If i change something > > > in > > > these sources and do not update PR the prserv/hashing mechanism detects > > > the > > > changes a builds a new package. But this package has the same version > > > info > > > as the one before. So for opkg there's no need to update it's "package > > > database". > > > > After fixing few of our own goofs in packagegroups, I still saw this issue > > with some real packages like weston-init. It went away after it got rebuilt > > due to the dependencies, but I'll keep an eye on it and report if it comes > > back... > > Ok, so on the second day it failed again on weston-init and couple of our own > packages. They are all marked as allarch, but it seems they get re-packaged > for some reason for different machines in multi-machine build - the timestamp > of the ipk package changed, while nothing else in the recipe or its data has > changed. There's nothing obvious in weston-init I can see that would trigger > it. And in the logs I see that do_package_write_ipk_setscene being triggered > - > I'm trying to figure out why... Any pointers?
There are many recipes with incorrect PACKAGE_ARCH, see latest report from world build: http://lists.openembedded.org/pipermail/openembedded-core/2015-January/100734.html weston-init is one of recipes where I've sent change to drop allarch long time ago: http://patchwork.openembedded.org/patch/74133/ -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core