Let uclibc provide rtld(GNU_HASH)

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<[email protected]>

---
  meta/classes/mirrors.bbclass |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

meta/classes/mirrors.bbclass +0 -0

index bf23e05..86ccd7a 100644

 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

Quoted 8 lines · Marko Lindqvist

 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"

Quoted 2 lines

 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.

Quoted 12 lines · Khem Raj

Quoted 10 lines · Marko Lindqvist

 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

Quoted 4 lines

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?

Quoted 18 lines · Marko Lindqvist

Quoted 16 lines · Khem Raj

Quoted 10 lines · Marko Lindqvist

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.

Quoted 3 lines

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

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 26 lines · Khem Raj

Quoted 24 lines · Marko Lindqvist

Quoted 20 lines · Khem Raj

Quoted 11 lines · Marko Lindqvist

 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.

Quoted 6 lines

Quoted 3 lines

 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?

Quoted 2 lines · Mark Hatle

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.

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.

Quoted 4 lines · Mark Hatle

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 ?

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/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(-)

Quoted 24 lines · 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

Quoted 4 lines

 meta/classes/mirrors.bbclass        |    2 +-
 meta/recipes-core/uclibc/uclibc.inc |    3 ++-

 2 files changed, 3 insertions(+), 2 deletions(-)

Merged into OE-Core

Quoted 25 lines · Saul Wold

Quoted 24 lines · 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

Quoted 6 lines

Quoted 4 lines

  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.