opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

Hi,

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! 
Thanks.

-- 
Denys

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Alejandro del Castillo]

On 05/01/2015 11:06 AM, Denys Dmytriyenko wrote:
> Hi,
>
> 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! 
> Thanks.
>
The error is saying that there is a mismatch between the registered package mds5sum and the actual md5sum of the package. On your log.do_rootfs log file you should find the opkg-cl command being called, which has an opkg.conf file as parameter. Inside the conf file, you will see the paths to the local repos being used to build your image.  Can you confirm that the registered md5sum for one of the problematic packages on the Package file on the repo doesn't match the actual package md5sum?

Alejandro

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Andrea Adami]

On Fri, May 1, 2015 at 6:06 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> Hi,
>
> 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!
> Thanks.
>
> --
> Denys
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


Hi,
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.

Configuring packagegroup-base.
Collected errors:
  * opkg_install_pkg: Package update-rc.d md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package psplash.
 * opkg_install_pkg: Package update-rc.d md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package packagegroup-base-extended.
 * opkg_install_pkg: Package run-postinsts md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package run-postinsts.
 * opkg_install_pkg: Package update-rc.d md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package packagegroup-core-boot.
ERROR: Function failed: do_rootfs

I retried right now after reboot (clean tmpdir) but this time it didn't happen.
Once/if I find the way to reproduce it I'll open a bug.

Cheers

Andrea

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Andrea Adami]

On Fri, May 1, 2015 at 6:06 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> Hi,
>
> 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!
> Thanks.
>
> --
> Denys
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


Hi,
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.

Configuring packagegroup-base.
Collected errors:
  * opkg_install_pkg: Package update-rc.d md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package psplash.
 * opkg_install_pkg: Package update-rc.d md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package packagegroup-base-extended.
 * opkg_install_pkg: Package run-postinsts md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package run-postinsts.
 * opkg_install_pkg: Package update-rc.d md5sum mismatch. Either the
opkg or the package index are corrupt. Try 'opkg update'.
 * opkg_install_cmd: Cannot install package packagegroup-core-boot.
ERROR: Function failed: do_rootfs

I retried right now after reboot (clean tmpdir) but this time it didn't happen.
Once/if I find the way to reproduce it I'll open a bug.

Cheers

Andrea

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

On Fri, May 01, 2015 at 05:13:05PM -0500, Alejandro del Castillo wrote:
> 
> 
> On 05/01/2015 11:06 AM, Denys Dmytriyenko wrote:
> > Hi,
> >
> > 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! 
> > Thanks.

> The error is saying that there is a mismatch between the registered package 
> mds5sum and the actual md5sum of the package. On your log.do_rootfs log file 
> you should find the opkg-cl command being called, which has an opkg.conf 
> file as parameter. Inside the conf file, you will see the paths to the local 
> repos being used to build your image.  Can you confirm that the registered 
> md5sum for one of the problematic packages on the Package file on the repo 
> doesn't match the actual package md5sum?

Yes, md5sum of the package doesn't match the one recorded in the Packages file 
of the local feed.

BTW, this seems to only happen to arch-less packages from the "all" feed, 
mainly packagegroups...

-- 
Denys

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

On Mon, May 04, 2015 at 02:50:17PM -0400, Denys Dmytriyenko wrote:
> On Fri, May 01, 2015 at 05:13:05PM -0500, Alejandro del Castillo wrote:
> > 
> > 
> > On 05/01/2015 11:06 AM, Denys Dmytriyenko wrote:
> > > Hi,
> > >
> > > 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! 
> > > Thanks.
> 
> > The error is saying that there is a mismatch between the registered package 
> > mds5sum and the actual md5sum of the package. On your log.do_rootfs log file 
> > you should find the opkg-cl command being called, which has an opkg.conf 
> > file as parameter. Inside the conf file, you will see the paths to the local 
> > repos being used to build your image.  Can you confirm that the registered 
> > md5sum for one of the problematic packages on the Package file on the repo 
> > doesn't match the actual package md5sum?
> 
> Yes, md5sum of the package doesn't match the one recorded in the Packages file 
> of the local feed.
> 
> BTW, this seems to only happen to arch-less packages from the "all" feed, 
> mainly packagegroups...

And then I realized that the failing packagegroup shouldn't really be 
arch-less! Apparently, I misplaced PACKAGE_ARCH = "${MACHINE_ARCH}" before 
inheriting packagegroup class. Oops!

-- 
Denys

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Alejandro del Castillo]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]



On 05/04/2015 02:19 PM, Denys Dmytriyenko wrote:
> On Mon, May 04, 2015 at 02:50:17PM -0400, Denys Dmytriyenko wrote:
>> On Fri, May 01, 2015 at 05:13:05PM -0500, Alejandro del Castillo wrote:
>>>
>>> On 05/01/2015 11:06 AM, Denys Dmytriyenko wrote:
>>>> Hi,
>>>>
>>>> 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! 
>>>> Thanks.
>>> The error is saying that there is a mismatch between the registered package 
>>> mds5sum and the actual md5sum of the package. On your log.do_rootfs log file 
>>> you should find the opkg-cl command being called, which has an opkg.conf 
>>> file as parameter. Inside the conf file, you will see the paths to the local 
>>> repos being used to build your image.  Can you confirm that the registered 
>>> md5sum for one of the problematic packages on the Package file on the repo 
>>> doesn't match the actual package md5sum?
>> Yes, md5sum of the package doesn't match the one recorded in the Packages file 
>> of the local feed.
>>
>> BTW, this seems to only happen to arch-less packages from the "all" feed, 
>> mainly packagegroups...
> And then I realized that the failing packagegroup shouldn't really be 
> arch-less! Apparently, I misplaced PACKAGE_ARCH = "${MACHINE_ARCH}" before 
> inheriting packagegroup class. Oops!
>
For Dizzy and Fido, I think the order changed (you need to place PACKAGE_ARCH
before inherit packagegroup). The good news is that if you upgrade, there is a
check that breaks the build if the bad ordering is detected (
30aaada4b79fc1acad5fdaba98071b63c52b9e05).

[-- Attachment #2: Type: text/html, Size: 3506 bytes --]

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Steffen Sledz]

Am 02.05.2015 um 23:55 schrieb Andrea Adami:
> On Fri, May 1, 2015 at 6:06 PM, Denys Dmytriyenko <denis@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".

As said before this is just a hypothesis.

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Steffen Sledz]

Am 02.05.2015 um 23:55 schrieb Andrea Adami:
> On Fri, May 1, 2015 at 6:06 PM, Denys Dmytriyenko <denis@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".

As said before this is just a hypothesis.

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

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 <denis@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...

-- 
Denys

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

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 <denis@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...

-- 
Denys

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

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 <denis@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?

-- 
Denys

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

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 <denis@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?

-- 
Denys

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

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 <denis@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?

So, debugging further...

weston-init RDEPENDS on weston and kbd.

$ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670

Then, comparing signatures for weston, for exaple, gives all the changes 
caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
since one machine is cortexa8, while another is cortexa9.

But why would an allarch package even care about machine tunes in dependant 
packages, when it only RDEPENDS on them?

And how should I fix this? Thanks.

-- 
Denys

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

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 <denis@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?

So, debugging further...

weston-init RDEPENDS on weston and kbd.

$ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670

Then, comparing signatures for weston, for exaple, gives all the changes 
caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
since one machine is cortexa8, while another is cortexa9.

But why would an allarch package even care about machine tunes in dependant 
packages, when it only RDEPENDS on them?

And how should I fix this? Thanks.

-- 
Denys

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Richard Purdie]

On Fri, 2015-05-08 at 17:09 -0400, Denys Dmytriyenko wrote:
> weston-init RDEPENDS on weston and kbd.
> 
> $ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
> Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
> Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670
> 
> Then, comparing signatures for weston, for exaple, gives all the changes 
> caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
> since one machine is cortexa8, while another is cortexa9.
> 
> But why would an allarch package even care about machine tunes in dependant 
> packages, when it only RDEPENDS on them?

If A DEPENDS on B and B changes, the package name may change (thanks to
debian.bbclass) so A has to repackage. Very very annoying but
technically correct :/.

> And how should I fix this? Thanks.

See SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf of OE-Core. You probably
need to add weston-init to the list.

Cheers,

Richard

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Richard Purdie]

On Fri, 2015-05-08 at 17:09 -0400, Denys Dmytriyenko wrote:
> weston-init RDEPENDS on weston and kbd.
> 
> $ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
> Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
> Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670
> 
> Then, comparing signatures for weston, for exaple, gives all the changes 
> caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
> since one machine is cortexa8, while another is cortexa9.
> 
> But why would an allarch package even care about machine tunes in dependant 
> packages, when it only RDEPENDS on them?

If A DEPENDS on B and B changes, the package name may change (thanks to
debian.bbclass) so A has to repackage. Very very annoying but
technically correct :/.

> And how should I fix this? Thanks.

See SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf of OE-Core. You probably
need to add weston-init to the list.

Cheers,

Richard

Re: [oe] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Martin Jansa]

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 <denis@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.Jansa@gmail.com

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Martin Jansa]

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 <denis@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.Jansa@gmail.com

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Martin Jansa]

On Sat, May 09, 2015 at 09:36:01AM +0100, Richard Purdie wrote:
> On Fri, 2015-05-08 at 17:09 -0400, Denys Dmytriyenko wrote:
> > weston-init RDEPENDS on weston and kbd.
> > 
> > $ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
> > Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
> > Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670
> > 
> > Then, comparing signatures for weston, for exaple, gives all the changes 
> > caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
> > since one machine is cortexa8, while another is cortexa9.
> > 
> > But why would an allarch package even care about machine tunes in dependant 
> > packages, when it only RDEPENDS on them?
> 
> If A DEPENDS on B and B changes, the package name may change (thanks to
> debian.bbclass) so A has to repackage. Very very annoying but
> technically correct :/.
> 
> > And how should I fix this? Thanks.
> 
> See SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf of OE-Core. You probably
> need to add weston-init to the list.

IIRC this won't help, he would need to add weston and kbd to
SIGGEN_EXCLUDERECIPES_ABISAFE which will exclude it from signature of
all other recipes as well.

Maybe you meant SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.

SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
  weston-init->weston \
  weston-init->kbd \
"

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Martin Jansa]

On Sat, May 09, 2015 at 09:36:01AM +0100, Richard Purdie wrote:
> On Fri, 2015-05-08 at 17:09 -0400, Denys Dmytriyenko wrote:
> > weston-init RDEPENDS on weston and kbd.
> > 
> > $ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
> > Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
> > Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670
> > 
> > Then, comparing signatures for weston, for exaple, gives all the changes 
> > caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
> > since one machine is cortexa8, while another is cortexa9.
> > 
> > But why would an allarch package even care about machine tunes in dependant 
> > packages, when it only RDEPENDS on them?
> 
> If A DEPENDS on B and B changes, the package name may change (thanks to
> debian.bbclass) so A has to repackage. Very very annoying but
> technically correct :/.
> 
> > And how should I fix this? Thanks.
> 
> See SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf of OE-Core. You probably
> need to add weston-init to the list.

IIRC this won't help, he would need to add weston and kbd to
SIGGEN_EXCLUDERECIPES_ABISAFE which will exclude it from signature of
all other recipes as well.

Maybe you meant SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.

SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
  weston-init->weston \
  weston-init->kbd \
"

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [oe] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Richard Purdie]

On Mon, 2015-05-11 at 08:22 +0200, Martin Jansa wrote:
> 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 <denis@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/

One thing we didn't discuss in that thread but which might help would be
whitelisting update-rc.d as a dependency? If that is the cause of many
of the problems, that would help. In this case it does look like the
weston RDEPENDS is the problem and  and the ABISAFE variable is the
better way to fix it though.

Cheers,

Richard

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Richard Purdie]

On Mon, 2015-05-11 at 08:22 +0200, Martin Jansa wrote:
> 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 <denis@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/

One thing we didn't discuss in that thread but which might help would be
whitelisting update-rc.d as a dependency? If that is the cause of many
of the problems, that would help. In this case it does look like the
weston RDEPENDS is the problem and  and the ABISAFE variable is the
better way to fix it though.

Cheers,

Richard

Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

On Mon, May 11, 2015 at 08:26:15AM +0200, Martin Jansa wrote:
> On Sat, May 09, 2015 at 09:36:01AM +0100, Richard Purdie wrote:
> > On Fri, 2015-05-08 at 17:09 -0400, Denys Dmytriyenko wrote:
> > > weston-init RDEPENDS on weston and kbd.
> > > 
> > > $ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
> > > Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
> > > Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670
> > > 
> > > Then, comparing signatures for weston, for exaple, gives all the changes 
> > > caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
> > > since one machine is cortexa8, while another is cortexa9.
> > > 
> > > But why would an allarch package even care about machine tunes in dependant 
> > > packages, when it only RDEPENDS on them?
> > 
> > If A DEPENDS on B and B changes, the package name may change (thanks to
> > debian.bbclass) so A has to repackage. Very very annoying but
> > technically correct :/.
> > 
> > > And how should I fix this? Thanks.
> > 
> > See SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf of OE-Core. You probably
> > need to add weston-init to the list.
> 
> IIRC this won't help, he would need to add weston and kbd to
> SIGGEN_EXCLUDERECIPES_ABISAFE which will exclude it from signature of
> all other recipes as well.
> 
> Maybe you meant SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.
> 
> SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
>   weston-init->weston \
>   weston-init->kbd \
> "

Thanks, Martin & Richard,

I can confirm that SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS seems to work in my local 
tests, while SIGGEN_EXCLUDERECIPES_ABISAFE doesn't.

-- 
Denys

Re: [OE-core] opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko]

On Mon, May 11, 2015 at 08:26:15AM +0200, Martin Jansa wrote:
> On Sat, May 09, 2015 at 09:36:01AM +0100, Richard Purdie wrote:
> > On Fri, 2015-05-08 at 17:09 -0400, Denys Dmytriyenko wrote:
> > > weston-init RDEPENDS on weston and kbd.
> > > 
> > > $ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d 
> > > Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295
> > > Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670
> > > 
> > > Then, comparing signatures for weston, for exaple, gives all the changes 
> > > caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, 
> > > since one machine is cortexa8, while another is cortexa9.
> > > 
> > > But why would an allarch package even care about machine tunes in dependant 
> > > packages, when it only RDEPENDS on them?
> > 
> > If A DEPENDS on B and B changes, the package name may change (thanks to
> > debian.bbclass) so A has to repackage. Very very annoying but
> > technically correct :/.
> > 
> > > And how should I fix this? Thanks.
> > 
> > See SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf of OE-Core. You probably
> > need to add weston-init to the list.
> 
> IIRC this won't help, he would need to add weston and kbd to
> SIGGEN_EXCLUDERECIPES_ABISAFE which will exclude it from signature of
> all other recipes as well.
> 
> Maybe you meant SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.
> 
> SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
>   weston-init->weston \
>   weston-init->kbd \
> "

Thanks, Martin & Richard,

I can confirm that SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS seems to work in my local 
tests, while SIGGEN_EXCLUDERECIPES_ABISAFE doesn't.

-- 
Denys