* e2fsprogs-libs build failure analysis
@ 2009-07-12 20:34 Khem Raj
2009-07-13 3:57 ` Denys Dmytriyenko
0 siblings, 1 reply; 9+ messages in thread
From: Khem Raj @ 2009-07-12 20:34 UTC (permalink / raw)
To: openembedded-devel
[-- 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 --]
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-12 20:34 e2fsprogs-libs build failure analysis Khem Raj
@ 2009-07-13 3:57 ` Denys Dmytriyenko
2009-07-14 19:47 ` Richard Purdie
0 siblings, 1 reply; 9+ messages in thread
From: Denys Dmytriyenko @ 2009-07-13 3:57 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-13 3:57 ` Denys Dmytriyenko
@ 2009-07-14 19:47 ` Richard Purdie
2009-07-14 20:33 ` Koen Kooi
2009-07-14 20:35 ` Khem Raj
0 siblings, 2 replies; 9+ messages in thread
From: Richard Purdie @ 2009-07-14 19:47 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-14 19:47 ` Richard Purdie
@ 2009-07-14 20:33 ` Koen Kooi
2009-07-14 21:13 ` Leon Woestenberg
2009-07-14 20:35 ` Khem Raj
1 sibling, 1 reply; 9+ messages in thread
From: Koen Kooi @ 2009-07-14 20:33 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-14 19:47 ` Richard Purdie
2009-07-14 20:33 ` Koen Kooi
@ 2009-07-14 20:35 ` Khem Raj
2009-07-14 22:16 ` Denys Dmytriyenko
1 sibling, 1 reply; 9+ messages in thread
From: Khem Raj @ 2009-07-14 20:35 UTC (permalink / raw)
To: openembedded-devel; +Cc: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-14 20:33 ` Koen Kooi
@ 2009-07-14 21:13 ` Leon Woestenberg
2009-07-15 1:43 ` Elvis Dowson
2009-07-15 7:10 ` Koen Kooi
0 siblings, 2 replies; 9+ messages in thread
From: Leon Woestenberg @ 2009-07-14 21:13 UTC (permalink / raw)
To: openembedded-devel; +Cc: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-14 20:35 ` Khem Raj
@ 2009-07-14 22:16 ` Denys Dmytriyenko
0 siblings, 0 replies; 9+ messages in thread
From: Denys Dmytriyenko @ 2009-07-14 22:16 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-14 21:13 ` Leon Woestenberg
@ 2009-07-15 1:43 ` Elvis Dowson
2009-07-15 7:10 ` Koen Kooi
1 sibling, 0 replies; 9+ messages in thread
From: Elvis Dowson @ 2009-07-15 1:43 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: e2fsprogs-libs build failure analysis
2009-07-14 21:13 ` Leon Woestenberg
2009-07-15 1:43 ` Elvis Dowson
@ 2009-07-15 7:10 ` Koen Kooi
1 sibling, 0 replies; 9+ messages in thread
From: Koen Kooi @ 2009-07-15 7:10 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-07-15 7:23 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-12 20:34 e2fsprogs-libs build failure analysis Khem Raj
2009-07-13 3:57 ` Denys Dmytriyenko
2009-07-14 19:47 ` Richard Purdie
2009-07-14 20:33 ` Koen Kooi
2009-07-14 21:13 ` Leon Woestenberg
2009-07-15 1:43 ` Elvis Dowson
2009-07-15 7:10 ` Koen Kooi
2009-07-14 20:35 ` Khem Raj
2009-07-14 22:16 ` Denys Dmytriyenko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.