* [PATCH 0/2] Let uclibc provide rtld(GNU_HASH)
@ 2012-05-09 0:43 Khem Raj
2012-05-09 0:43 ` [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH Khem Raj
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Khem Raj @ 2012-05-09 0:43 UTC (permalink / raw)
To: openembedded-core
We have seen reports where rtld(GNU_HASH) is found missing
on uclibc based images infact uclibc rtld does provide GNU_HASH
support as default so we add that to PROVIDES
snapshot mirror url is changed. Currently the url will fetch
html files which will end in corrupted downloads so we
update the url location in mirrors class.
The following changes since commit 043871d7e5d2d19c2ff43e54d2ff180c09e8903e:
kern-tools: integrate minor fixes (2012-05-08 16:06:15 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib kraj/misc-fixes
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/misc-fixes
Khem Raj (2):
uclibc.inc: uclibc rtld does support GNU_HASH
classes/mirrors.bbclass: Point snapshot.debian.org mirror to working
location
meta/classes/mirrors.bbclass | 2 +-
meta/recipes-core/uclibc/uclibc.inc | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
--
1.7.5.4
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 0:43 [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Khem Raj @ 2012-05-09 0:43 ` Khem Raj 2012-05-09 0:59 ` Marko Lindqvist 2012-05-09 0:43 ` [PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location Khem Raj 2012-05-11 17:36 ` [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Saul Wold 2 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2012-05-09 0:43 UTC (permalink / raw) To: openembedded-core Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-core/uclibc/uclibc.inc | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/meta/recipes-core/uclibc/uclibc.inc b/meta/recipes-core/uclibc/uclibc.inc index f5b6bf7..55ab0c9 100644 --- a/meta/recipes-core/uclibc/uclibc.inc +++ b/meta/recipes-core/uclibc/uclibc.inc @@ -88,7 +88,8 @@ RPROVIDES_${PN}-dev += "libc-dev virtual-libc-dev" # uclibc does not really have libsegfault but then using the one from glibc is also not # going to work. So we pretend that we have it to make bitbake not pull other recipes # to satisfy this dependency for the images/tasks -RPROVIDES_uclibc += "libsegfault" + +RPROVIDES_uclibc += "libsegfault rtld(GNU_HASH)" SRC_URI = "\ http://www.uclibc.org/downloads/uClibc-${PV}.tar.bz2;name=uClibc-${PV} \ -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 0:43 ` [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH Khem Raj @ 2012-05-09 0:59 ` Marko Lindqvist 2012-05-09 1:36 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Marko Lindqvist @ 2012-05-09 0:59 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 9 May 2012 03:43, Khem Raj <raj.khem@gmail.com> wrote: > -RPROVIDES_uclibc += "libsegfault" > + > +RPROVIDES_uclibc += "libsegfault rtld(GNU_HASH)" You should know that I'm just figuring out what to do with "rtld(GNU_HASH)" that already exist for eglibc. When building deb-packets based image, that results in: "reference to 'rtld': error in version: version number does not start with digit" I've confirmed that error message is caused by this by simply removing "(GNU_HASH)" -> eglibc build success - ML ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 0:59 ` Marko Lindqvist @ 2012-05-09 1:36 ` Khem Raj 2012-05-09 1:53 ` Marko Lindqvist 0 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2012-05-09 1:36 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist <cazfi74@gmail.com> wrote: > > > You should know that I'm just figuring out what to do with > "rtld(GNU_HASH)" that already exist for eglibc. When building > deb-packets based image, that results in: > "reference to 'rtld': error in version: version number does not start > with digit" > > I've confirmed that error message is caused by this by simply > removing "(GNU_HASH)" -> eglibc build success yeah this is rpm brain damage actually that we are dealing with here. I think rpm should be fixed for this. I am not entirely sure why this would be needed on current OE-Core lets say if its needed it should then be made specific when someone is using rpm for packaging. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 1:36 ` Khem Raj @ 2012-05-09 1:53 ` Marko Lindqvist 2012-05-09 2:09 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Marko Lindqvist @ 2012-05-09 1:53 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 9 May 2012 04:36, Khem Raj <raj.khem@gmail.com> wrote: > On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist <cazfi74@gmail.com> wrote: >> >> >> You should know that I'm just figuring out what to do with >> "rtld(GNU_HASH)" that already exist for eglibc. When building >> deb-packets based image, that results in: >> "reference to 'rtld': error in version: version number does not start >> with digit" >> >> I've confirmed that error message is caused by this by simply >> removing "(GNU_HASH)" -> eglibc build success > > yeah this is rpm brain damage actually that we are dealing with here. > I think rpm should be fixed for this. I am not entirely sure why this > would be needed on current OE-Core lets say if its needed it should then > be made specific when someone is using rpm for packaging. I've not yet figured out what all this tries to achieve, but are you saying that it might be acceptable solution for eglibc too to simply remove "(GNU_HASH)" if nobody from rpm world vetoes such patch? - ML ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 1:53 ` Marko Lindqvist @ 2012-05-09 2:09 ` Khem Raj 2012-05-09 14:49 ` Mark Hatle 0 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2012-05-09 2:09 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, May 8, 2012 at 6:53 PM, Marko Lindqvist <cazfi74@gmail.com> wrote: > On 9 May 2012 04:36, Khem Raj <raj.khem@gmail.com> wrote: >> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist <cazfi74@gmail.com> wrote: >>> >>> >>> You should know that I'm just figuring out what to do with >>> "rtld(GNU_HASH)" that already exist for eglibc. When building >>> deb-packets based image, that results in: >>> "reference to 'rtld': error in version: version number does not start >>> with digit" >>> >>> I've confirmed that error message is caused by this by simply >>> removing "(GNU_HASH)" -> eglibc build success >> >> yeah this is rpm brain damage actually that we are dealing with here. >> I think rpm should be fixed for this. I am not entirely sure why this >> would be needed on current OE-Core lets say if its needed it should then >> be made specific when someone is using rpm for packaging. > > I've not yet figured out what all this tries to achieve, but are you > saying that it might be acceptable solution for eglibc too to simply > remove "(GNU_HASH)" if nobody from rpm world vetoes such patch? yes. We need to find why this PROVIDE is needed at all in current OE ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 2:09 ` Khem Raj @ 2012-05-09 14:49 ` Mark Hatle 2012-05-09 15:46 ` Marko Lindqvist 2012-05-09 15:47 ` Khem Raj 0 siblings, 2 replies; 16+ messages in thread From: Mark Hatle @ 2012-05-09 14:49 UTC (permalink / raw) To: openembedded-core On 5/8/12 9:09 PM, Khem Raj wrote: > On Tue, May 8, 2012 at 6:53 PM, Marko Lindqvist<cazfi74@gmail.com> wrote: >> On 9 May 2012 04:36, Khem Raj<raj.khem@gmail.com> wrote: >>> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist<cazfi74@gmail.com> wrote: >>>> >>>> >>>> You should know that I'm just figuring out what to do with >>>> "rtld(GNU_HASH)" that already exist for eglibc. When building >>>> deb-packets based image, that results in: >>>> "reference to 'rtld': error in version: version number does not start >>>> with digit" >>>> >>>> I've confirmed that error message is caused by this by simply >>>> removing "(GNU_HASH)" -> eglibc build success >>> >>> yeah this is rpm brain damage actually that we are dealing with here. >>> I think rpm should be fixed for this. I am not entirely sure why this >>> would be needed on current OE-Core lets say if its needed it should then >>> be made specific when someone is using rpm for packaging. >> >> I've not yet figured out what all this tries to achieve, but are you >> saying that it might be acceptable solution for eglibc too to simply >> remove "(GNU_HASH)" if nobody from rpm world vetoes such patch? > > yes. We need to find why this PROVIDE is needed at all in current OE The per-file "advanced" dependencies, which are not yet being used by ipkg or deb, include a marker for rtld support. The libc on the system needs to have a provide that it supports GNU_HASH, otherwise a missing dependency occurs and the system knows the package and libc has a mismatch. IPKG works with this, but apparently DEB does not. We have two solutions that I see. If the format of the RPROVIDE is legal in OE, then the DEB package solution needs to transform the provide into something that is legal for debian style packages. If the format of the RPROVIDE is illegal in OE (and just happens to work), then the RPM package manager needs to transform the provide... RPM is already doing a number of transforms to change from OE format to RPM format, I would expect the same behavior from other package managers -- assuming that the RPROVIDE is legal. Who can definitively state what the legal RPROVIDE format is in OE? --Mark > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 14:49 ` Mark Hatle @ 2012-05-09 15:46 ` Marko Lindqvist 2012-05-09 23:57 ` Marko Lindqvist 2012-05-09 15:47 ` Khem Raj 1 sibling, 1 reply; 16+ messages in thread From: Marko Lindqvist @ 2012-05-09 15:46 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 9 May 2012 17:49, Mark Hatle <mark.hatle@windriver.com> wrote: > On 5/8/12 9:09 PM, Khem Raj wrote: >> >> On Tue, May 8, 2012 at 6:53 PM, Marko Lindqvist<cazfi74@gmail.com> wrote: >>> >>> On 9 May 2012 04:36, Khem Raj<raj.khem@gmail.com> wrote: >>>> >>>> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist<cazfi74@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> >>>>> You should know that I'm just figuring out what to do with >>>>> "rtld(GNU_HASH)" that already exist for eglibc. When building >>>>> deb-packets based image, that results in: >>>>> "reference to 'rtld': error in version: version number does not start >>>>> with digit" >>>>> >>>>> I've confirmed that error message is caused by this by simply >>>>> removing "(GNU_HASH)" -> eglibc build success >>>> >>>> >>>> yeah this is rpm brain damage actually that we are dealing with here. >>>> I think rpm should be fixed for this. I am not entirely sure why this >>>> would be needed on current OE-Core lets say if its needed it should then >>>> be made specific when someone is using rpm for packaging. >>> >>> >>> I've not yet figured out what all this tries to achieve, but are you >>> saying that it might be acceptable solution for eglibc too to simply >>> remove "(GNU_HASH)" if nobody from rpm world vetoes such patch? >> >> >> yes. We need to find why this PROVIDE is needed at all in current OE > > The per-file "advanced" dependencies, which are not yet being used by ipkg > or deb, include a marker for rtld support. The libc on the system needs to > have a provide that it supports GNU_HASH, otherwise a missing dependency > occurs and the system knows the package and libc has a mismatch. > > IPKG works with this, but apparently DEB does not. We have two solutions > that I see. > > If the format of the RPROVIDE is legal in OE, then the DEB package solution > needs to transform the provide into something that is legal for debian style > packages. > > If the format of the RPROVIDE is illegal in OE (and just happens to work), > then the RPM package manager needs to transform the provide... > > RPM is already doing a number of transforms to change from OE format to RPM > format, I would expect the same behavior from other package managers -- > assuming that the RPROVIDE is legal. > > Who can definitively state what the legal RPROVIDE format is in OE? If we are to define it now, and selecting from existing alternatives, parenthesis could denote either: deb style) Single version number override. Recipe 1.0.0 can provide some 1.0.1 package. rpm style) General marker (does it even handle multiple ones?) Any use-case relevant to OE I see for deb style handling can be handled with smart use of rpm style, but not the other way around. - ML ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 15:46 ` Marko Lindqvist @ 2012-05-09 23:57 ` Marko Lindqvist 0 siblings, 0 replies; 16+ messages in thread From: Marko Lindqvist @ 2012-05-09 23:57 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 9 May 2012 18:46, Marko Lindqvist <cazfi74@gmail.com> wrote: > On 9 May 2012 17:49, Mark Hatle <mark.hatle@windriver.com> wrote: >> >> Who can definitively state what the legal RPROVIDE format is in OE? > > If we are to define it now, and selecting from existing alternatives, > parenthesis could denote either: > > deb style) Single version number override. Recipe 1.0.0 can provide > some 1.0.1 package. > > rpm style) General marker (does it even handle multiple ones?) > > Any use-case relevant to OE I see for deb style handling can be > handled with smart use of rpm style, but not the other way around. Working on assumption that deb-side was the broken one, I submitted patch http://patchwork.openembedded.org/patch/27417/ - ML ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 14:49 ` Mark Hatle 2012-05-09 15:46 ` Marko Lindqvist @ 2012-05-09 15:47 ` Khem Raj 2012-05-09 15:55 ` Mark Hatle 1 sibling, 1 reply; 16+ messages in thread From: Khem Raj @ 2012-05-09 15:47 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, May 9, 2012 at 7:49 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > The per-file "advanced" dependencies, which are not yet being used by ipkg > or deb, include a marker for rtld support. The libc on the system needs to > have a provide that it supports GNU_HASH, otherwise a missing dependency > occurs and the system knows the package and libc has a mismatch. I would assume that this was needed when transition for sysv hash to gnu hash was going on. Now that GNU_HASH is default in OE for long time this kind of makes it redundant unless I am missing something w.r.t. advanced dependency support. What is it exactly doing ? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH 2012-05-09 15:47 ` Khem Raj @ 2012-05-09 15:55 ` Mark Hatle 0 siblings, 0 replies; 16+ messages in thread From: Mark Hatle @ 2012-05-09 15:55 UTC (permalink / raw) To: openembedded-core On 5/9/12 10:47 AM, Khem Raj wrote: > On Wed, May 9, 2012 at 7:49 AM, Mark Hatle<mark.hatle@windriver.com> wrote: >> The per-file "advanced" dependencies, which are not yet being used by ipkg >> or deb, include a marker for rtld support. The libc on the system needs to >> have a provide that it supports GNU_HASH, otherwise a missing dependency >> occurs and the system knows the package and libc has a mismatch. > > I would assume that this was needed when transition for sysv hash to > gnu hash was going on. Now that GNU_HASH is default in OE for long > time this kind of > makes it redundant unless I am missing something w.r.t. advanced dependency > support. What is it exactly doing ? In the RPM case it was for people who download random binary packages from upstream sources and attempt to install them. If the local system doesn't support GNU_HASH then it won't work. I thought it was still possible to build and configure a system w/ no GNU_HASH dependencies (or even support). I know OE itself probably doesn't have this problem, OE-Core certainly shouldn't.. but it's external binary package cases that cause problems. --Mark > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location 2012-05-09 0:43 [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Khem Raj 2012-05-09 0:43 ` [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH Khem Raj @ 2012-05-09 0:43 ` Khem Raj 2012-05-16 18:02 ` Saul Wold 2012-05-11 17:36 ` [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Saul Wold 2 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2012-05-09 0:43 UTC (permalink / raw) To: openembedded-core If you point to snapshot.debian.net/archive/pool then it will fetch you a html page which will end up in corrupt download. The locations have changed for archives and here we point the mirror to right location. Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/classes/mirrors.bbclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass index bf23e05..86ccd7a 100644 --- a/meta/classes/mirrors.bbclass +++ b/meta/classes/mirrors.bbclass @@ -1,5 +1,5 @@ MIRRORS += "\ -${DEBIAN_MIRROR}/main http://snapshot.debian.net/archive/pool \n \ +${DEBIAN_MIRROR}/main http://snapshot.debian.org/archive/debian-archive/20120328T092752Z/debian/pool/ \n \ ${DEBIAN_MIRROR} ftp://ftp.de.debian.org/debian/pool \n \ ${DEBIAN_MIRROR} ftp://ftp.au.debian.org/debian/pool \n \ ${DEBIAN_MIRROR} ftp://ftp.cl.debian.org/debian/pool \n \ -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location 2012-05-09 0:43 ` [PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location Khem Raj @ 2012-05-16 18:02 ` Saul Wold 0 siblings, 0 replies; 16+ messages in thread From: Saul Wold @ 2012-05-16 18:02 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 05/09/2012 03:43 AM, Khem Raj wrote: > If you point to snapshot.debian.net/archive/pool then it will fetch > you a html page which will end up in corrupt download. The locations > have changed for archives and here we point the mirror to right > location. > > Signed-off-by: Khem Raj<raj.khem@gmail.com> > --- > meta/classes/mirrors.bbclass | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass > index bf23e05..86ccd7a 100644 > --- a/meta/classes/mirrors.bbclass > +++ b/meta/classes/mirrors.bbclass > @@ -1,5 +1,5 @@ > MIRRORS += "\ > -${DEBIAN_MIRROR}/main http://snapshot.debian.net/archive/pool \n \ > +${DEBIAN_MIRROR}/main http://snapshot.debian.org/archive/debian-archive/20120328T092752Z/debian/pool/ \n \ > ${DEBIAN_MIRROR} ftp://ftp.de.debian.org/debian/pool \n \ > ${DEBIAN_MIRROR} ftp://ftp.au.debian.org/debian/pool \n \ > ${DEBIAN_MIRROR} ftp://ftp.cl.debian.org/debian/pool \n \ Merged into OE-Core Thanks Sau! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) 2012-05-09 0:43 [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Khem Raj 2012-05-09 0:43 ` [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH Khem Raj 2012-05-09 0:43 ` [PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location Khem Raj @ 2012-05-11 17:36 ` Saul Wold 2012-05-11 19:09 ` Khem Raj 2 siblings, 1 reply; 16+ messages in thread From: Saul Wold @ 2012-05-11 17:36 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 05/08/2012 05:43 PM, Khem Raj wrote: > We have seen reports where rtld(GNU_HASH) is found missing > on uclibc based images infact uclibc rtld does provide GNU_HASH > support as default so we add that to PROVIDES > > snapshot mirror url is changed. Currently the url will fetch > html files which will end in corrupted downloads so we > update the url location in mirrors class. > > The following changes since commit 043871d7e5d2d19c2ff43e54d2ff180c09e8903e: > > kern-tools: integrate minor fixes (2012-05-08 16:06:15 +0100) > > are available in the git repository at: > git://git.openembedded.org/openembedded-core-contrib kraj/misc-fixes > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/misc-fixes > > Khem Raj (2): > uclibc.inc: uclibc rtld does support GNU_HASH > classes/mirrors.bbclass: Point snapshot.debian.org mirror to working > location > > meta/classes/mirrors.bbclass | 2 +- > meta/recipes-core/uclibc/uclibc.inc | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > Merged into OE-Core Thanks Sau! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) 2012-05-11 17:36 ` [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Saul Wold @ 2012-05-11 19:09 ` Khem Raj 2012-05-16 22:37 ` Scott Garman 0 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2012-05-11 19:09 UTC (permalink / raw) To: Saul Wold; +Cc: Patches and discussions about the oe-core layer On Fri, May 11, 2012 at 10:36 AM, Saul Wold <sgw@linux.intel.com> wrote: > On 05/08/2012 05:43 PM, Khem Raj wrote: >> >> We have seen reports where rtld(GNU_HASH) is found missing >> on uclibc based images infact uclibc rtld does provide GNU_HASH >> support as default so we add that to PROVIDES >> >> snapshot mirror url is changed. Currently the url will fetch >> html files which will end in corrupted downloads so we >> update the url location in mirrors class. >> >> The following changes since commit >> 043871d7e5d2d19c2ff43e54d2ff180c09e8903e: >> >> kern-tools: integrate minor fixes (2012-05-08 16:06:15 +0100) >> >> are available in the git repository at: >> git://git.openembedded.org/openembedded-core-contrib kraj/misc-fixes >> >> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/misc-fixes >> >> Khem Raj (2): >> uclibc.inc: uclibc rtld does support GNU_HASH >> classes/mirrors.bbclass: Point snapshot.debian.org mirror to working >> location >> >> meta/classes/mirrors.bbclass | 2 +- >> meta/recipes-core/uclibc/uclibc.inc | 3 ++- >> 2 files changed, 3 insertions(+), 2 deletions(-) >> > > Merged into OE-Core FWIW both these fixes are needed on denzil too. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) 2012-05-11 19:09 ` Khem Raj @ 2012-05-16 22:37 ` Scott Garman 0 siblings, 0 replies; 16+ messages in thread From: Scott Garman @ 2012-05-16 22:37 UTC (permalink / raw) To: openembedded-core On 05/11/2012 12:09 PM, Khem Raj wrote: > On Fri, May 11, 2012 at 10:36 AM, Saul Wold<sgw@linux.intel.com> wrote: >> On 05/08/2012 05:43 PM, Khem Raj wrote: >>> >>> We have seen reports where rtld(GNU_HASH) is found missing >>> on uclibc based images infact uclibc rtld does provide GNU_HASH >>> support as default so we add that to PROVIDES >>> >>> snapshot mirror url is changed. Currently the url will fetch >>> html files which will end in corrupted downloads so we >>> update the url location in mirrors class. >>> >>> The following changes since commit >>> 043871d7e5d2d19c2ff43e54d2ff180c09e8903e: >>> >>> kern-tools: integrate minor fixes (2012-05-08 16:06:15 +0100) >>> >>> are available in the git repository at: >>> git://git.openembedded.org/openembedded-core-contrib kraj/misc-fixes >>> >>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/misc-fixes >>> >>> Khem Raj (2): >>> uclibc.inc: uclibc rtld does support GNU_HASH >>> classes/mirrors.bbclass: Point snapshot.debian.org mirror to working >>> location >>> >>> meta/classes/mirrors.bbclass | 2 +- >>> meta/recipes-core/uclibc/uclibc.inc | 3 ++- >>> 2 files changed, 3 insertions(+), 2 deletions(-) >>> >> >> Merged into OE-Core > > FWIW both these fixes are needed on denzil too. Merged to sgarman/denzil-next: http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-05-16 22:47 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-09 0:43 [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Khem Raj 2012-05-09 0:43 ` [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH Khem Raj 2012-05-09 0:59 ` Marko Lindqvist 2012-05-09 1:36 ` Khem Raj 2012-05-09 1:53 ` Marko Lindqvist 2012-05-09 2:09 ` Khem Raj 2012-05-09 14:49 ` Mark Hatle 2012-05-09 15:46 ` Marko Lindqvist 2012-05-09 23:57 ` Marko Lindqvist 2012-05-09 15:47 ` Khem Raj 2012-05-09 15:55 ` Mark Hatle 2012-05-09 0:43 ` [PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location Khem Raj 2012-05-16 18:02 ` Saul Wold 2012-05-11 17:36 ` [PATCH 0/2] Let uclibc provide rtld(GNU_HASH) Saul Wold 2012-05-11 19:09 ` Khem Raj 2012-05-16 22:37 ` Scott Garman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox