[PATCH 0/2] Let uclibc provide rtld(GNU_HASH)

[PATCH 0/2] Let uclibc provide rtld(GNU_HASH)

[Khem Raj]

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

[PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Khem Raj]

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

[PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location

[Khem Raj]

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

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Marko Lindqvist]

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

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Khem Raj]

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.

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Marko Lindqvist]

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

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Khem Raj]

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

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Mark Hatle]

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

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Marko Lindqvist]

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

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Khem Raj]

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 ?

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Mark Hatle]

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

Re: [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Marko Lindqvist]

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

Re: [PATCH 0/2] Let uclibc provide rtld(GNU_HASH)

[Saul Wold]

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!

Re: [PATCH 0/2] Let uclibc provide rtld(GNU_HASH)

[Khem Raj]

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.

Re: [PATCH 2/2] classes/mirrors.bbclass: Point snapshot.debian.org mirror to working location

[Saul Wold]

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!

Re: [PATCH 0/2] Let uclibc provide rtld(GNU_HASH)

[Scott Garman]

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