e2fsprogs-libs build failure analysis

e2fsprogs-libs build failure analysis

[Khem Raj]

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

Hi

Like many others I was also getting this problem reported on this mailing list in past 

http://article.gmane.org/gmane.comp.handhelds.openembedded/24445/match=e2fsprogs+libs

I looked a bit into this and the problem is that PN gets overwritten when 
do_package_write_ipk -> read_subpackage_metadata 

this loop below reads the subpkgdata also reads PV PN and PR which are then overwritten
by bb.data.setVar(key, sdata[key], d)

       for pkg in bb.data.getVar('PACKAGES', d, 1).split():
                sdata = read_subpkgdata(pkg, d)
                for key in sdata.keys():
                        bb.data.setVar(key, sdata[key], d)


when this loop exits the last subpackage it read is build/eglibc/omap5912osk/pkgdata/armv5te-angstrom-linux-gnueabi/runtime/libblkid

which says that PN is util-linux-ng
and this value of PN is updated last into the bb.data for e2fsprogs-libs
so when do_package_ipk () is called it wants to get WORKDIR

workdir = bb.data.getVar('WORKDIR', d, 1)

but WORKDIR consits of PN PV and PR so it calculates it wrongly

So I think problem is caused because of emitting PV, PN and PR into pkgdata files
which is then read and updated into bb.data

I added a workaround in base.bbclass

diff --git a/classes/base.bbclass b/classes/base.bbclass
index bc50c67..5eefdb7 100644
--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -1090,7 +1090,9 @@ def read_pkgdata(pn, d):
 python read_subpackage_metadata () {
        import bb
        data = read_pkgdata(bb.data.getVar('PN', d, 1), d)
-
+       pn = bb.data.getVar('PN', d, 1)
+       pv = bb.data.getVar('PV', d, 1)
+       pr = bb.data.getVar('PR', d, 1)
        for key in data.keys():
                bb.data.setVar(key, data[key], d)

@@ -1098,6 +1100,9 @@ python read_subpackage_metadata () {
                sdata = read_subpkgdata(pkg, d)
                for key in sdata.keys():
                        bb.data.setVar(key, sdata[key], d)
+       bb.data.setVar('PN', pn, d)
+       bb.data.setVar('PV', pv, d)
+       bb.data.setVar('PR', pr, d)
 }


and it works now but I feel this is not the right fix. 

util-linux-ng.inc has

PACKAGES_DYNAMIC = "libblkid*"

and e2fsprogs-libs.inc has

do_stage () {
        for i in libcom_err libss libuuid libblkid; do
                oe_libinstall -a -C lib $i ${STAGING_LIBDIR}
.....
}

probably this also needs some thought.

Thanks

-Khem



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: e2fsprogs-libs build failure analysis

[Denys Dmytriyenko]

On Sun, Jul 12, 2009 at 01:34:34PM -0700, Khem Raj wrote:
> Hi
> 
> Like many others I was also getting this problem reported on this mailing list in past 
> 
> http://article.gmane.org/gmane.comp.handhelds.openembedded/24445/match=e2fsprogs+libs
> 
> I looked a bit into this and the problem is that PN gets overwritten when 
> do_package_write_ipk -> read_subpackage_metadata 

Khem,

Have you seen this thread several months ago with the same analysis:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/22376/focus=22556

As I said before, pkgdata/runtime handling needs fixing - if multiple recipes 
(or even target vs. native/sdk of the same package, like it was with curl) 
provide the identically named .so library (libblkid in this case) during the 
build, there may be a conflict in the pkgdata/runtime files.

What are the pkgdata files are used for ultimately? Do they need to contain 
PN/PV/PR? That was introduced by the commit mentioned in the thread above... 
Should it be reverted?

Lets ask Richard - he made this change in Poky, maybe he has a better fix for 
it... :)

-- 
Denys

> this loop below reads the subpkgdata also reads PV PN and PR which are then overwritten
> by bb.data.setVar(key, sdata[key], d)
> 
>        for pkg in bb.data.getVar('PACKAGES', d, 1).split():
>                 sdata = read_subpkgdata(pkg, d)
>                 for key in sdata.keys():
>                         bb.data.setVar(key, sdata[key], d)
> 
> 
> when this loop exits the last subpackage it read is build/eglibc/omap5912osk/pkgdata/armv5te-angstrom-linux-gnueabi/runtime/libblkid
> 
> which says that PN is util-linux-ng
> and this value of PN is updated last into the bb.data for e2fsprogs-libs
> so when do_package_ipk () is called it wants to get WORKDIR
> 
> workdir = bb.data.getVar('WORKDIR', d, 1)
> 
> but WORKDIR consits of PN PV and PR so it calculates it wrongly
> 
> So I think problem is caused because of emitting PV, PN and PR into pkgdata files
> which is then read and updated into bb.data
> 
> I added a workaround in base.bbclass
> 
> diff --git a/classes/base.bbclass b/classes/base.bbclass
> index bc50c67..5eefdb7 100644
> --- a/classes/base.bbclass
> +++ b/classes/base.bbclass
> @@ -1090,7 +1090,9 @@ def read_pkgdata(pn, d):
>  python read_subpackage_metadata () {
>         import bb
>         data = read_pkgdata(bb.data.getVar('PN', d, 1), d)
> -
> +       pn = bb.data.getVar('PN', d, 1)
> +       pv = bb.data.getVar('PV', d, 1)
> +       pr = bb.data.getVar('PR', d, 1)
>         for key in data.keys():
>                 bb.data.setVar(key, data[key], d)
> 
> @@ -1098,6 +1100,9 @@ python read_subpackage_metadata () {
>                 sdata = read_subpkgdata(pkg, d)
>                 for key in sdata.keys():
>                         bb.data.setVar(key, sdata[key], d)
> +       bb.data.setVar('PN', pn, d)
> +       bb.data.setVar('PV', pv, d)
> +       bb.data.setVar('PR', pr, d)
>  }
> 
> 
> and it works now but I feel this is not the right fix. 
> 
> util-linux-ng.inc has
> 
> PACKAGES_DYNAMIC = "libblkid*"
> 
> and e2fsprogs-libs.inc has
> 
> do_stage () {
>         for i in libcom_err libss libuuid libblkid; do
>                 oe_libinstall -a -C lib $i ${STAGING_LIBDIR}
> .....
> }
> 
> probably this also needs some thought.
> 
> Thanks
> 
> -Khem
> 
> 



> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: e2fsprogs-libs build failure analysis

[Richard Purdie]

Hi,

On Sun, 2009-07-12 at 23:57 -0400, Denys Dmytriyenko wrote:
> On Sun, Jul 12, 2009 at 01:34:34PM -0700, Khem Raj wrote:
> > Like many others I was also getting this problem reported on this mailing list in past 
> > 
> > http://article.gmane.org/gmane.comp.handhelds.openembedded/24445/match=e2fsprogs+libs
> > 
> > I looked a bit into this and the problem is that PN gets overwritten when 
> > do_package_write_ipk -> read_subpackage_metadata 
>
> Have you seen this thread several months ago with the same analysis:
> http://thread.gmane.org/gmane.comp.handhelds.openembedded/22376/focus=22556
> 
> As I said before, pkgdata/runtime handling needs fixing - if multiple recipes 
> (or even target vs. native/sdk of the same package, like it was with curl) 
> provide the identically named .so library (libblkid in this case) during the 
> build, there may be a conflict in the pkgdata/runtime files.
> 
> What are the pkgdata files are used for ultimately? Do they need to contain 
> PN/PV/PR? That was introduced by the commit mentioned in the thread above... 
> Should it be reverted?
> 
> Lets ask Richard - he made this change in Poky, maybe he has a better fix for 
> it... :)

The real problem here is two packages providing the same library. This
is actually a critical error and means your distro is screwed unless
handled very carefully. Rather than hacking around the problem, I'd much
rather we detect and abort in this case and warn the user something is
about to break and that any package feeds will need careful attention.

Cheers,

Richard


-- 
Richard Purdie
Intel Open Source Technology Centre

Re: e2fsprogs-libs build failure analysis

[Koen Kooi]

On 14-07-09 21:47, Richard Purdie wrote:

> The real problem here is two packages providing the same library. This
> is actually a critical error and means your distro is screwed unless
> handled very carefully. Rather than hacking around the problem, I'd much
> rather we detect and abort in this case and warn the user something is
> about to break and that any package feeds will need careful attention.

In this case it works as intended, at least in angstrom :)

regards,

Ken

Re: e2fsprogs-libs build failure analysis

[Leon Woestenberg]

Hello,

On Tue, Jul 14, 2009 at 10:33 PM, Koen Kooi<k.kooi@student.utwente.nl> wrote:
> On 14-07-09 21:47, Richard Purdie wrote:
>
>> The real problem here is two packages providing the same library. This
>> is actually a critical error and means your distro is screwed unless
>> handled very carefully. Rather than hacking around the problem, I'd much
>> rather we detect and abort in this case and warn the user something is
>> about to break and that any package feeds will need careful attention.
>
> In this case it works as intended, at least in angstrom :)
>
Not sure, I get build errors on both packages.

http://bugs.openembedded.org/show_bug.cgi?id=5149

Regards,
-- 
Leon

Re: e2fsprogs-libs build failure analysis

[Elvis Dowson]

Hi,

> On Tue, Jul 14, 2009 at 10:33 PM, Koen  
> Kooi<k.kooi@student.utwente.nl> wrote:
>>
>> In this case it works as intended, at least in angstrom :)

I'm using overo-oe, angstrom release, and I get this error if I build  
the environment from the beginning.

Best regards,

Elvis

Re: e2fsprogs-libs build failure analysis

[Koen Kooi]

On 14-07-09 23:13, Leon Woestenberg wrote:
> Hello,
>
> On Tue, Jul 14, 2009 at 10:33 PM, Koen Kooi<k.kooi@student.utwente.nl>  wrote:
>> On 14-07-09 21:47, Richard Purdie wrote:
>>
>>> The real problem here is two packages providing the same library. This
>>> is actually a critical error and means your distro is screwed unless
>>> handled very carefully. Rather than hacking around the problem, I'd much
>>> rather we detect and abort in this case and warn the user something is
>>> about to break and that any package feeds will need careful attention.
>>
>> In this case it works as intended, at least in angstrom :)
>>
> Not sure, I get build errors on both packages.
>
> http://bugs.openembedded.org/show_bug.cgi?id=5149

I wasn't talking about build errors, I was getting at the "any package 
feeds will need careful attention" bit

Re: e2fsprogs-libs build failure analysis

[Khem Raj]

On (14/07/09 20:47), Richard Purdie wrote:
> Hi,
> 
> On Sun, 2009-07-12 at 23:57 -0400, Denys Dmytriyenko wrote:
> > On Sun, Jul 12, 2009 at 01:34:34PM -0700, Khem Raj wrote:
> > > Like many others I was also getting this problem reported on this mailing list in past 
> > > 
> > > http://article.gmane.org/gmane.comp.handhelds.openembedded/24445/match=e2fsprogs+libs
> > > 
> > > I looked a bit into this and the problem is that PN gets overwritten when 
> > > do_package_write_ipk -> read_subpackage_metadata 
> >
> > Have you seen this thread several months ago with the same analysis:
> > http://thread.gmane.org/gmane.comp.handhelds.openembedded/22376/focus=22556
> > 
> > As I said before, pkgdata/runtime handling needs fixing - if multiple recipes 
> > (or even target vs. native/sdk of the same package, like it was with curl) 
> > provide the identically named .so library (libblkid in this case) during the 
> > build, there may be a conflict in the pkgdata/runtime files.
> > 
> > What are the pkgdata files are used for ultimately? Do they need to contain 
> > PN/PV/PR? That was introduced by the commit mentioned in the thread above... 
> > Should it be reverted?
> > 
> > Lets ask Richard - he made this change in Poky, maybe he has a better fix for 
> > it... :)
> 
> The real problem here is two packages providing the same library. This
> is actually a critical error and means your distro is screwed unless
> handled very carefully. Rather than hacking around the problem, I'd much
> rather we detect and abort in this case and warn the user something is
> about to break and that any package feeds will need careful attention.

yeah I would agree on both counts.


> 
> Cheers,
> 
> Richard
> 
> 
> -- 
> Richard Purdie
> Intel Open Source Technology Centre
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: e2fsprogs-libs build failure analysis

[Denys Dmytriyenko]

On Tue, Jul 14, 2009 at 01:35:51PM -0700, Khem Raj wrote:
> On (14/07/09 20:47), Richard Purdie wrote:
> > Hi,
> > 
> > On Sun, 2009-07-12 at 23:57 -0400, Denys Dmytriyenko wrote:
> > > On Sun, Jul 12, 2009 at 01:34:34PM -0700, Khem Raj wrote:
> > > > Like many others I was also getting this problem reported on this mailing list in past 
> > > > 
> > > > http://article.gmane.org/gmane.comp.handhelds.openembedded/24445/match=e2fsprogs+libs
> > > > 
> > > > I looked a bit into this and the problem is that PN gets overwritten when 
> > > > do_package_write_ipk -> read_subpackage_metadata 
> > >
> > > Have you seen this thread several months ago with the same analysis:
> > > http://thread.gmane.org/gmane.comp.handhelds.openembedded/22376/focus=22556
> > > 
> > > As I said before, pkgdata/runtime handling needs fixing - if multiple recipes 
> > > (or even target vs. native/sdk of the same package, like it was with curl) 
> > > provide the identically named .so library (libblkid in this case) during the 
> > > build, there may be a conflict in the pkgdata/runtime files.
> > > 
> > > What are the pkgdata files are used for ultimately? Do they need to contain 
> > > PN/PV/PR? That was introduced by the commit mentioned in the thread above... 
> > > Should it be reverted?
> > > 
> > > Lets ask Richard - he made this change in Poky, maybe he has a better fix for 
> > > it... :)
> > 
> > The real problem here is two packages providing the same library. This
> > is actually a critical error and means your distro is screwed unless
> > handled very carefully. Rather than hacking around the problem, I'd much
> > rather we detect and abort in this case and warn the user something is
> > about to break and that any package feeds will need careful attention.
> 
> yeah I would agree on both counts.

Sorry, this might be a stupid question, but can update-alternatives handle 
libraries? Would that solve the issue of multiple packages providing the same 
library?

-- 
Denys