[PATCH] libc-package bbclass: fix binary localedata dependency code

[PATCH] libc-package bbclass: fix binary localedata dependency code

[Koen Kooi]

When using binary locales rootfs generation fails with:

| Unknown package 'locale-base-en-us'.
| Collected errors:
|  * opkg_install_cmd: Cannot install package locale-base-en-us.

This is due to:

$ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep Depends
 Depends: eglibc-binary-localedata-en.us

Note the '.' seperator

$ ls ipk/armv7a/ | grep binary-localedata-en | grep us
eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk

Note the '-' seperator vs the '.' in the locale-base packages.

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 meta/classes/libc-package.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass
index de57230..67d08c0 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -243,7 +243,7 @@ python package_do_split_gconvs () {
 	def output_locale_binary_rdepends(name, pkgname, locale, encoding):
 		m = re.match("(.*)_(.*)", name)
 		if m:
-			libc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
+			libc_name = "%s-%s" % (m.group(1), m.group(2).lower().replace("-",""))
 		else:
 			libc_name = name
 		bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('%s-binary-localedata-%s' \
-- 
1.6.6.1

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Koen Kooi]

The bug I was seeing was caused by something else, but I'd still like feedback on this patch to find out why the dot vs dash difference exists

Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:

> When using binary locales rootfs generation fails with:
> 
> | Unknown package 'locale-base-en-us'.
> | Collected errors:
> |  * opkg_install_cmd: Cannot install package locale-base-en-us.
> 
> This is due to:
> 
> $ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep Depends
> Depends: eglibc-binary-localedata-en.us
> 
> Note the '.' seperator
> 
> $ ls ipk/armv7a/ | grep binary-localedata-en | grep us
> eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
> 
> Note the '-' seperator vs the '.' in the locale-base packages.
> 
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
> meta/classes/libc-package.bbclass |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass
> index de57230..67d08c0 100644
> --- a/meta/classes/libc-package.bbclass
> +++ b/meta/classes/libc-package.bbclass
> @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
> 	def output_locale_binary_rdepends(name, pkgname, locale, encoding):
> 		m = re.match("(.*)_(.*)", name)
> 		if m:
> -			libc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
> +			libc_name = "%s-%s" % (m.group(1), m.group(2).lower().replace("-",""))
> 		else:
> 			libc_name = name
> 		bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('%s-binary-localedata-%s' \
> -- 
> 1.6.6.1
> 

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Phil Blundell]

It does look a bit weird.  That code was introduced in 561d8754,
ostensibly as a merger of the eglibc and glibc equivalents.  But, the
original code from glibc-package.bbclass did:

       def output_locale_binary_rdepends(name, pkgname, locale, encoding):
               m = re.match("(.*)\.(.*)", name)
               if m:
                       glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
               else:
                       glibc_name = name
               bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)

... i.e. it was using the "." separator both for splitting and joining,
which seems reasonable.  But somehow when it showed up in
libc-package.bbclass it had gotten transmogrified so that it split on
"_" but joined with "." as you showed below.  That seems bogus to me.

p.

On Tue, 2011-08-02 at 16:55 +0200, Koen Kooi wrote:
> The bug I was seeing was caused by something else, but I'd still like feedback on this patch to find out why the dot vs dash difference exists
> 
> Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
> 
> > When using binary locales rootfs generation fails with:
> > 
> > | Unknown package 'locale-base-en-us'.
> > | Collected errors:
> > |  * opkg_install_cmd: Cannot install package locale-base-en-us.
> > 
> > This is due to:
> > 
> > $ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep Depends
> > Depends: eglibc-binary-localedata-en.us
> > 
> > Note the '.' seperator
> > 
> > $ ls ipk/armv7a/ | grep binary-localedata-en | grep us
> > eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
> > 
> > Note the '-' seperator vs the '.' in the locale-base packages.
> > 
> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> > ---
> > meta/classes/libc-package.bbclass |    2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass
> > index de57230..67d08c0 100644
> > --- a/meta/classes/libc-package.bbclass
> > +++ b/meta/classes/libc-package.bbclass
> > @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
> > 	def output_locale_binary_rdepends(name, pkgname, locale, encoding):
> > 		m = re.match("(.*)_(.*)", name)
> > 		if m:
> > -			libc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
> > +			libc_name = "%s-%s" % (m.group(1), m.group(2).lower().replace("-",""))
> > 		else:
> > 			libc_name = name
> > 		bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('%s-binary-localedata-%s' \
> > -- 
> > 1.6.6.1
> > 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Koen Kooi]

Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:

> It does look a bit weird.  That code was introduced in 561d8754,
> ostensibly as a merger of the eglibc and glibc equivalents.  But, the
> original code from glibc-package.bbclass did:
> 
>       def output_locale_binary_rdepends(name, pkgname, locale, encoding):
>               m = re.match("(.*)\.(.*)", name)
>               if m:
>                       glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
>               else:
>                       glibc_name = name
>               bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> 
> ... i.e. it was using the "." separator both for splitting and joining,
> which seems reasonable.  But somehow when it showed up in
> libc-package.bbclass it had gotten transmogrified so that it split on
> "_" but joined with "." as you showed below.  That seems bogus to me.

There is something funky going on if you use cross-localedef instead of on-target localedef and it looks like this is one of the reasons. I can respin the patch in different split formats if people want. But most of all I'd like to know what is going on :)

regards,

Koen

> 
> p.
> 
> On Tue, 2011-08-02 at 16:55 +0200, Koen Kooi wrote:
>> The bug I was seeing was caused by something else, but I'd still like feedback on this patch to find out why the dot vs dash difference exists
>> 
>> Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
>> 
>>> When using binary locales rootfs generation fails with:
>>> 
>>> | Unknown package 'locale-base-en-us'.
>>> | Collected errors:
>>> |  * opkg_install_cmd: Cannot install package locale-base-en-us.
>>> 
>>> This is due to:
>>> 
>>> $ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep Depends
>>> Depends: eglibc-binary-localedata-en.us
>>> 
>>> Note the '.' seperator
>>> 
>>> $ ls ipk/armv7a/ | grep binary-localedata-en | grep us
>>> eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
>>> 
>>> Note the '-' seperator vs the '.' in the locale-base packages.
>>> 
>>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>>> ---
>>> meta/classes/libc-package.bbclass |    2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> 
>>> diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass
>>> index de57230..67d08c0 100644
>>> --- a/meta/classes/libc-package.bbclass
>>> +++ b/meta/classes/libc-package.bbclass
>>> @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
>>> 	def output_locale_binary_rdepends(name, pkgname, locale, encoding):
>>> 		m = re.match("(.*)_(.*)", name)
>>> 		if m:
>>> -			libc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
>>> +			libc_name = "%s-%s" % (m.group(1), m.group(2).lower().replace("-",""))
>>> 		else:
>>> 			libc_name = name
>>> 		bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('%s-binary-localedata-%s' \
>>> -- 
>>> 1.6.6.1
>>> 
>> 
>> 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Phil Blundell]

On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
> 
> > It does look a bit weird.  That code was introduced in 561d8754,
> > ostensibly as a merger of the eglibc and glibc equivalents.  But, the
> > original code from glibc-package.bbclass did:
> > 
> >       def output_locale_binary_rdepends(name, pkgname, locale, encoding):
> >               m = re.match("(.*)\.(.*)", name)
> >               if m:
> >                       glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
> >               else:
> >                       glibc_name = name
> >               bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> > 
> > ... i.e. it was using the "." separator both for splitting and joining,
> > which seems reasonable.  But somehow when it showed up in
> > libc-package.bbclass it had gotten transmogrified so that it split on
> > "_" but joined with "." as you showed below.  That seems bogus to me.
> 
> There is something funky going on if you use cross-localedef instead of on-target localedef and it looks like this is one of the reasons. I can respin the patch in different split formats if people want. But most of all I'd like to know what is going on :)

Well, the original purpose of that code (when it split on dots) was to
squash hyphens in encoding names.  That is, it transforms "en-US.utf-8"
to "en-US.utf8", on the grounds that the dash isn't significant there
and might be confusing with all the other dashes that go on in the
package name.

I don't know why cross-localdef would be doing anything different to the
on-target one.  Can you expand on what exactly is the funky behaviour
you see?

p.

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Koen Kooi]

Op 3 aug. 2011, om 08:39 heeft Phil Blundell het volgende geschreven:

> On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
>> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
>> 
>>> It does look a bit weird.  That code was introduced in 561d8754,
>>> ostensibly as a merger of the eglibc and glibc equivalents.  But, the
>>> original code from glibc-package.bbclass did:
>>> 
>>>      def output_locale_binary_rdepends(name, pkgname, locale, encoding):
>>>              m = re.match("(.*)\.(.*)", name)
>>>              if m:
>>>                      glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
>>>              else:
>>>                      glibc_name = name
>>>              bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
>>> 
>>> ... i.e. it was using the "." separator both for splitting and joining,
>>> which seems reasonable.  But somehow when it showed up in
>>> libc-package.bbclass it had gotten transmogrified so that it split on
>>> "_" but joined with "." as you showed below.  That seems bogus to me.
>> 
>> There is something funky going on if you use cross-localedef instead of on-target localedef and it looks like this is one of the reasons. I can respin the patch in different split formats if people want. But most of all I'd like to know what is going on :)
> 
> Well, the original purpose of that code (when it split on dots) was to
> squash hyphens in encoding names.  That is, it transforms "en-US.utf-8"
> to "en-US.utf8", on the grounds that the dash isn't significant there
> and might be confusing with all the other dashes that go on in the
> package name.
> 
> I don't know why cross-localdef would be doing anything different to the
> on-target one.  Can you expand on what exactly is the funky behaviour
> you see?

If you look at e.g. http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yocto&id=0fb50099

-locale_base_en_us -> eglibc_localedata_en_us;
-locale_base_en_us -> localedef;
-locale_base_en_us -> eglibc_charmap_utf_8;
-localedef -> libc6;
+locale_base_en_us -> eglibc_binary_localedata_en_us;

That shows that locale-base-foo drops some deps like the charmap when switching to binary locales. There's other breakage in that build clouding the diff, so I copied the relevant lines above.

regards,

Koen

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Phil Blundell]

On Wed, 2011-08-03 at 09:03 +0200, Koen Kooi wrote:
> If you look at e.g. http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yocto&id=0fb50099
> 
> -locale_base_en_us -> eglibc_localedata_en_us;
> -locale_base_en_us -> localedef;
> -locale_base_en_us -> eglibc_charmap_utf_8;
> -localedef -> libc6;
> +locale_base_en_us -> eglibc_binary_localedata_en_us;
> 
> That shows that locale-base-foo drops some deps like the charmap when switching to binary locales. There's other breakage in that build clouding the diff, so I copied the relevant lines above.

I think that's expected.  IIRC, the charmap files are inputs to
localedef and the relevant bits from them are fully captured in the
binary archive output.  So, if you're using a pregenerated binary
locale, you don't need the charmap (or localedata, which is also a
source file) at run time.

p.

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Phil Blundell]

On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
> 
> > It does look a bit weird.  That code was introduced in 561d8754,
> > ostensibly as a merger of the eglibc and glibc equivalents.  But, the
> > original code from glibc-package.bbclass did:
> > 
> >       def output_locale_binary_rdepends(name, pkgname, locale, encoding):
> >               m = re.match("(.*)\.(.*)", name)
> >               if m:
> >                       glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
> >               else:
> >                       glibc_name = name
> >               bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> > 
> > ... i.e. it was using the "." separator both for splitting and joining,
> > which seems reasonable.  But somehow when it showed up in
> > libc-package.bbclass it had gotten transmogrified so that it split on
> > "_" but joined with "." as you showed below.  That seems bogus to me.

I'm not sure whether your original locale problem is still an issue, but
I am still fairly convinced that the change to the regex in the code
above was incorrect.  Unless the author of 561d8754 wants to speak up in
its defence soon, I will submit a patch to change it back to using ".".

p.

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 3:00 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] libc-package bbclass: fix binary
> localedata dependency code
> 
> On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
> > Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
> >
> > > It does look a bit weird.  That code was introduced in 561d8754,
> > > ostensibly as a merger of the eglibc and glibc equivalents.  But,
> the
> > > original code from glibc-package.bbclass did:
> > >
> > >       def output_locale_binary_rdepends(name, pkgname, locale,
> encoding):
> > >               m = re.match("(.*)\.(.*)", name)
> > >               if m:
> > >                       glibc_name = "%s.%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> > >               else:
> > >                       glibc_name = name
> > >               bb.data.setVar('RDEPENDS_%s' % pkgname,
> legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> > >
> > > ... i.e. it was using the "." separator both for splitting and
> joining,
> > > which seems reasonable.  But somehow when it showed up in
> > > libc-package.bbclass it had gotten transmogrified so that it split
> on
> > > "_" but joined with "." as you showed below.  That seems bogus to
> me.
> 
> I'm not sure whether your original locale problem is still an issue,
> but
> I am still fairly convinced that the change to the regex in the code
> above was incorrect.  Unless the author of 561d8754 wants to speak up
> in
> its defence soon, I will submit a patch to change it back to using ".".
> 
> p.
> 
Phil,
   Feel free to do the right thing. :) I am out of context here, and need to dig this further to understand the situation better. 
Nitin


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

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Khem Raj]

On Thu, Aug 4, 2011 at 3:00 PM, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
>> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
>>
>> > It does look a bit weird.  That code was introduced in 561d8754,
>> > ostensibly as a merger of the eglibc and glibc equivalents.  But, the
>> > original code from glibc-package.bbclass did:
>> >
>> >       def output_locale_binary_rdepends(name, pkgname, locale, encoding):
>> >               m = re.match("(.*)\.(.*)", name)
>> >               if m:
>> >                       glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
>> >               else:
>> >                       glibc_name = name
>> >               bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
>> >
>> > ... i.e. it was using the "." separator both for splitting and joining,
>> > which seems reasonable.  But somehow when it showed up in
>> > libc-package.bbclass it had gotten transmogrified so that it split on
>> > "_" but joined with "." as you showed below.  That seems bogus to me.
>
> I'm not sure whether your original locale problem is still an issue, but
> I am still fairly convinced that the change to the regex in the code
> above was incorrect.  Unless the author of 561d8754 wants to speak up in
> its defence soon, I will submit a patch to change it back to using ".".

yes I think that would be right thing to do. Will you submit a patch please ?

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

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Koen Kooi]

Nitin, any insights on this?

Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:

> It does look a bit weird.  That code was introduced in 561d8754,
> ostensibly as a merger of the eglibc and glibc equivalents.  But, the
> original code from glibc-package.bbclass did:
> 
>       def output_locale_binary_rdepends(name, pkgname, locale, encoding):
>               m = re.match("(.*)\.(.*)", name)
>               if m:
>                       glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
>               else:
>                       glibc_name = name
>               bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> 
> ... i.e. it was using the "." separator both for splitting and joining,
> which seems reasonable.  But somehow when it showed up in
> libc-package.bbclass it had gotten transmogrified so that it split on
> "_" but joined with "." as you showed below.  That seems bogus to me.
> 
> p.
> 
> On Tue, 2011-08-02 at 16:55 +0200, Koen Kooi wrote:
>> The bug I was seeing was caused by something else, but I'd still like feedback on this patch to find out why the dot vs dash difference exists
>> 
>> Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
>> 
>>> When using binary locales rootfs generation fails with:
>>> 
>>> | Unknown package 'locale-base-en-us'.
>>> | Collected errors:
>>> |  * opkg_install_cmd: Cannot install package locale-base-en-us.
>>> 
>>> This is due to:
>>> 
>>> $ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep Depends
>>> Depends: eglibc-binary-localedata-en.us
>>> 
>>> Note the '.' seperator
>>> 
>>> $ ls ipk/armv7a/ | grep binary-localedata-en | grep us
>>> eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
>>> 
>>> Note the '-' seperator vs the '.' in the locale-base packages.
>>> 
>>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>>> ---
>>> meta/classes/libc-package.bbclass |    2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> 
>>> diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-package.bbclass
>>> index de57230..67d08c0 100644
>>> --- a/meta/classes/libc-package.bbclass
>>> +++ b/meta/classes/libc-package.bbclass
>>> @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
>>> 	def output_locale_binary_rdepends(name, pkgname, locale, encoding):
>>> 		m = re.match("(.*)_(.*)", name)
>>> 		if m:
>>> -			libc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
>>> +			libc_name = "%s-%s" % (m.group(1), m.group(2).lower().replace("-",""))
>>> 		else:
>>> 			libc_name = name
>>> 		bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('%s-binary-localedata-%s' \
>>> -- 
>>> 1.6.6.1
>>> 
>> 
>> 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Kamble, Nitin A]

Hi Koen,
  Sorry for replying late, I am on vacation now. I looked at my commit 561d875404ef1783f94f37314b6e756766db8411, and from it I see that both eglibc & glibc package.bbclass has same lines 
-               if m:
-                       eglibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
-               else:
-                       eglibc_name = name
So I am not sure that this is the correct fix. I will look into it further and reply later.
Thanks,
Nitin

> -----Original Message-----
> From: Koen Kooi [mailto:koen@dominion.thruhere.net]
> Sent: Tuesday, August 09, 2011 11:14 PM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH] libc-package bbclass: fix binary
> localedata dependency code
> 
> Nitin, any insights on this?
> 
> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
> 
> > It does look a bit weird.  That code was introduced in 561d8754,
> > ostensibly as a merger of the eglibc and glibc equivalents.  But, the
> > original code from glibc-package.bbclass did:
> >
> >       def output_locale_binary_rdepends(name, pkgname, locale,
> encoding):
> >               m = re.match("(.*)\.(.*)", name)
> >               if m:
> >                       glibc_name = "%s.%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> >               else:
> >                       glibc_name = name
> >               bb.data.setVar('RDEPENDS_%s' % pkgname,
> legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> >
> > ... i.e. it was using the "." separator both for splitting and
> joining,
> > which seems reasonable.  But somehow when it showed up in
> > libc-package.bbclass it had gotten transmogrified so that it split on
> > "_" but joined with "." as you showed below.  That seems bogus to me.
> >
> > p.
> >
> > On Tue, 2011-08-02 at 16:55 +0200, Koen Kooi wrote:
> >> The bug I was seeing was caused by something else, but I'd still
> like feedback on this patch to find out why the dot vs dash difference
> exists
> >>
> >> Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
> >>
> >>> When using binary locales rootfs generation fails with:
> >>>
> >>> | Unknown package 'locale-base-en-us'.
> >>> | Collected errors:
> >>> |  * opkg_install_cmd: Cannot install package locale-base-en-us.
> >>>
> >>> This is due to:
> >>>
> >>> $ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk |
> grep Depends
> >>> Depends: eglibc-binary-localedata-en.us
> >>>
> >>> Note the '.' seperator
> >>>
> >>> $ ls ipk/armv7a/ | grep binary-localedata-en | grep us
> >>> eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
> >>>
> >>> Note the '-' seperator vs the '.' in the locale-base packages.
> >>>
> >>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> >>> ---
> >>> meta/classes/libc-package.bbclass |    2 +-
> >>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-
> package.bbclass
> >>> index de57230..67d08c0 100644
> >>> --- a/meta/classes/libc-package.bbclass
> >>> +++ b/meta/classes/libc-package.bbclass
> >>> @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
> >>> 	def output_locale_binary_rdepends(name, pkgname, locale,
> encoding):
> >>> 		m = re.match("(.*)_(.*)", name)
> >>> 		if m:
> >>> -			libc_name = "%s.%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> >>> +			libc_name = "%s-%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> >>> 		else:
> >>> 			libc_name = name
> >>> 		bb.data.setVar('RDEPENDS_%s' % pkgname,
> legitimize_package_name('%s-binary-localedata-%s' \
> >>> --
> >>> 1.6.6.1
> >>>
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] libc-package bbclass: fix binary localedata dependency code

[Khem Raj]

On Thu, Aug 11, 2011 at 9:43 PM, Kamble, Nitin A
<nitin.a.kamble@intel.com> wrote:
> Hi Koen,
>  Sorry for replying late, I am on vacation now. I looked at my commit 561d875404ef1783f94f37314b6e756766db8411, and from it I see that both eglibc & glibc package.bbclass has same lines
> -               if m:
> -                       eglibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
> -               else:
> -                       eglibc_name = name
> So I am not sure that this is the correct fix. I will look into it further and reply later.

this code is not the problem the real problem is the splitting code
that changed in this commit

-  m = re.match("(.*)\.(.*)", name)
+ m = re.match("(.*)_(.*)", name)


Why is regular expression splitting at _ and joining with . ?
original behaviour was to split and join with .

This seems incorrect to me.

> Thanks,
> Nitin
>
>> -----Original Message-----
>> From: Koen Kooi [mailto:koen@dominion.thruhere.net]
>> Sent: Tuesday, August 09, 2011 11:14 PM
>> To: Patches and discussions about the oe-core layer
>> Cc: Kamble, Nitin A
>> Subject: Re: [OE-core] [PATCH] libc-package bbclass: fix binary
>> localedata dependency code
>>
>> Nitin, any insights on this?
>>
>> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
>>
>> > It does look a bit weird.  That code was introduced in 561d8754,
>> > ostensibly as a merger of the eglibc and glibc equivalents.  But, the
>> > original code from glibc-package.bbclass did:
>> >
>> >       def output_locale_binary_rdepends(name, pkgname, locale,
>> encoding):
>> >               m = re.match("(.*)\.(.*)", name)
>> >               if m:
>> >                       glibc_name = "%s.%s" % (m.group(1),
>> m.group(2).lower().replace("-",""))
>> >               else:
>> >                       glibc_name = name
>> >               bb.data.setVar('RDEPENDS_%s' % pkgname,
>> legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
>> >
>> > ... i.e. it was using the "." separator both for splitting and
>> joining,
>> > which seems reasonable.  But somehow when it showed up in
>> > libc-package.bbclass it had gotten transmogrified so that it split on
>> > "_" but joined with "." as you showed below.  That seems bogus to me.
>> >
>> > p.
>> >
>> > On Tue, 2011-08-02 at 16:55 +0200, Koen Kooi wrote:
>> >> The bug I was seeing was caused by something else, but I'd still
>> like feedback on this patch to find out why the dot vs dash difference
>> exists
>> >>
>> >> Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
>> >>
>> >>> When using binary locales rootfs generation fails with:
>> >>>
>> >>> | Unknown package 'locale-base-en-us'.
>> >>> | Collected errors:
>> >>> |  * opkg_install_cmd: Cannot install package locale-base-en-us.
>> >>>
>> >>> This is due to:
>> >>>
>> >>> $ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk |
>> grep Depends
>> >>> Depends: eglibc-binary-localedata-en.us
>> >>>
>> >>> Note the '.' seperator
>> >>>
>> >>> $ ls ipk/armv7a/ | grep binary-localedata-en | grep us
>> >>> eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
>> >>>
>> >>> Note the '-' seperator vs the '.' in the locale-base packages.
>> >>>
>> >>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>> >>> ---
>> >>> meta/classes/libc-package.bbclass |    2 +-
>> >>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> >>>
>> >>> diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-
>> package.bbclass
>> >>> index de57230..67d08c0 100644
>> >>> --- a/meta/classes/libc-package.bbclass
>> >>> +++ b/meta/classes/libc-package.bbclass
>> >>> @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
>> >>>   def output_locale_binary_rdepends(name, pkgname, locale,
>> encoding):
>> >>>           m = re.match("(.*)_(.*)", name)
>> >>>           if m:
>> >>> -                 libc_name = "%s.%s" % (m.group(1),
>> m.group(2).lower().replace("-",""))
>> >>> +                 libc_name = "%s-%s" % (m.group(1),
>> m.group(2).lower().replace("-",""))
>> >>>           else:
>> >>>                   libc_name = name
>> >>>           bb.data.setVar('RDEPENDS_%s' % pkgname,
>> legitimize_package_name('%s-binary-localedata-%s' \
>> >>> --
>> >>> 1.6.6.1
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> Openembedded-core mailing list
>> >> Openembedded-core@lists.openembedded.org
>> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
>> core
>> >
>> >
>> >
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>