[gentoo-user] A question about emerge --info

[gentoo-user] A question about emerge --info

[Paul Hartman]

I've always been curious about something in emerge --info's output:

$ emerge --info
Portage 2.2_rc12 (default/linux/amd64/2008.0/desktop, gcc-4.3.2,
glibc-2.8_p20080602-r0, 2.6.27-gentoo-r1 x86_64)
=================================================================
System uname:
Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.2.5
Timestamp of tree: Tue, 28 Oct 2008 00:31:02 +0000

Why does it show the glibc-2.8 on the second line but glibc2.2.5 on the fifth?

Thanks,
Paul

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

On Wed, Oct 29, 2008 at 6:53 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> I've always been curious about something in emerge --info's output:
>
> $ emerge --info
> Portage 2.2_rc12 (default/linux/amd64/2008.0/desktop, gcc-4.3.2,
> glibc-2.8_p20080602-r0, 2.6.27-gentoo-r1 x86_64)
> =================================================================
> System uname:
> Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.2.5
> Timestamp of tree: Tue, 28 Oct 2008 00:31:02 +0000
>
> Why does it show the glibc-2.8 on the second line but glibc2.2.5 on the fifth?

Uname returns only the kernel version string. Why glibc is in there is
beyond me.
However, I'm still using 2.6.26, so it might be a 2.6.27 issue.


-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Andrey Falko]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com<paul.hartman%2Bgentoo@gmail.com>
> wrote:

> I've always been curious about something in emerge --info's output:
>
> $ emerge --info
> Portage 2.2_rc12 (default/linux/amd64/2008.0/desktop, gcc-4.3.2,
> glibc-2.8_p20080602-r0, 2.6.27-gentoo-r1 x86_64)
> =================================================================
> System uname:
> Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@
> _2.40GHz-with-glibc2.2.5
> Timestamp of tree: Tue, 28 Oct 2008 00:31:02 +0000
>
> Why does it show the glibc-2.8 on the second line but glibc2.2.5 on the
> fifth?
>
> Thanks,
> Paul
>
>
My best guess is that your kernel was compiled by a toolchain that was
running on glibc2.2.5

See what happens if you recompile the kernel under the newer toolchain.

[-- Attachment #2: Type: text/html, Size: 1138 bytes --]

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

On Wed, Oct 29, 2008 at 7:09 PM, Andrey Falko <ma3oxuct@gmail.com> wrote:
>
>
> On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
>>
>> I've always been curious about something in emerge --info's output:
>>
>> $ emerge --info
>> Portage 2.2_rc12 (default/linux/amd64/2008.0/desktop, gcc-4.3.2,
>> glibc-2.8_p20080602-r0, 2.6.27-gentoo-r1 x86_64)
>> =================================================================
>> System uname:
>>
>> Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.2.5
>> Timestamp of tree: Tue, 28 Oct 2008 00:31:02 +0000
>>
>> Why does it show the glibc-2.8 on the second line but glibc2.2.5 on the
>> fifth?
>>
>> Thanks,
>> Paul
>>
>
> My best guess is that your kernel was compiled by a toolchain that was
> running on glibc2.2.5
>
> See what happens if you recompile the kernel under the newer toolchain.
>
2.6.27 uses glibc? Really?
I'm asking lkml what's happening.


-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Paul Hartman]

On Wed, Oct 29, 2008 at 6:09 PM, Andrey Falko <ma3oxuct@gmail.com> wrote:
>
>
> On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
>>
>> I've always been curious about something in emerge --info's output:
>>
>> $ emerge --info
>> Portage 2.2_rc12 (default/linux/amd64/2008.0/desktop, gcc-4.3.2,
>> glibc-2.8_p20080602-r0, 2.6.27-gentoo-r1 x86_64)
>> =================================================================
>> System uname:
>>
>> Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.2.5
>> Timestamp of tree: Tue, 28 Oct 2008 00:31:02 +0000
>>
>> Why does it show the glibc-2.8 on the second line but glibc2.2.5 on the
>> fifth?
>>
>> Thanks,
>> Paul
>>
>
> My best guess is that your kernel was compiled by a toolchain that was
> running on glibc2.2.5
>
> See what happens if you recompile the kernel under the newer toolchain.

By toolchain do you mean gcc/binutils? Both have been built since I've
had glibc 2.8 installed. When I build my kernel I just "make all"
(after configuring, of course).

I've never even had glibc2.2.5 on this computer. The earliest was 2.5
and I've been using 2.8 since June. That's why the message confuses
me. "uname -a" does not actually mention anything about glibc, but
emerge --info is getting it from somewhere. I haven't tried to look
into the depths of emerge sources yet to figure out exactly where it's
getting that info.

Thanks,
Paul

Re: [gentoo-user] A question about emerge --info

[Andrey Falko]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Wed, Oct 29, 2008 at 4:13 PM, Andrey Vul <andrey.vul@gmail.com> wrote:

> On Wed, Oct 29, 2008 at 7:09 PM, Andrey Falko <ma3oxuct@gmail.com> wrote:
> >
> >
> > On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman
> > <paul.hartman+gentoo@gmail.com <paul.hartman%2Bgentoo@gmail.com>> wrote:
> >>
> >> I've always been curious about something in emerge --info's output:
> >>
> >> $ emerge --info
> >> Portage 2.2_rc12 (default/linux/amd64/2008.0/desktop, gcc-4.3.2,
> >> glibc-2.8_p20080602-r0, 2.6.27-gentoo-r1 x86_64)
> >> =================================================================
> >> System uname:
> >>
> >> Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@
> _2.40GHz-with-glibc2.2.5
> >> Timestamp of tree: Tue, 28 Oct 2008 00:31:02 +0000
> >>
> >> Why does it show the glibc-2.8 on the second line but glibc2.2.5 on the
> >> fifth?
> >>
> >> Thanks,
> >> Paul
> >>
> >
> > My best guess is that your kernel was compiled by a toolchain that was
> > running on glibc2.2.5
> >
> > See what happens if you recompile the kernel under the newer toolchain.
> >
> 2.6.27 uses glibc? Really?
> I'm asking lkml what's happening.
>
>
> --
> Andrey Vul
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
Well it doesn't use glibc per se, gcc uses the glibc.....however, his uname
-a output does look funky.

Here is mine: System uname: 2.6.24.7 x86_64 Intel(R) Core(TM)2 CPU 6700 @
2.66GHz

Did all underscores make it there by accident? What happens when you do a
plain uname -a?

[-- Attachment #2: Type: text/html, Size: 2336 bytes --]

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

On Wed, Oct 29, 2008 at 7:23 PM, Andrey Falko <ma3oxuct@gmail.com> wrote:
>
>
> On Wed, Oct 29, 2008 at 4:13 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
>>
>> On Wed, Oct 29, 2008 at 7:09 PM, Andrey Falko <ma3oxuct@gmail.com> wrote:
>> >
>> >
>> > On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman
>> > <paul.hartman+gentoo@gmail.com> wrote:
>> >>
>> >> I've always been curious about something in emerge --info's output:
>> >>
>> >> $ emerge --info
>> >> Portage 2.2_rc12 (default/linux/amd64/2008.0/desktop, gcc-4.3.2,
>> >> glibc-2.8_p20080602-r0, 2.6.27-gentoo-r1 x86_64)
>> >> =================================================================
>> >> System uname:
>> >>
>> >>
>> >> Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.2.5
>> >> Timestamp of tree: Tue, 28 Oct 2008 00:31:02 +0000
>> >>
>> >> Why does it show the glibc-2.8 on the second line but glibc2.2.5 on the
>> >> fifth?
>> >>
>> >> Thanks,
>> >> Paul
>> >>
>> >
>> > My best guess is that your kernel was compiled by a toolchain that was
>> > running on glibc2.2.5
>> >
>> > See what happens if you recompile the kernel under the newer toolchain.
>> >
>> 2.6.27 uses glibc? Really?
>> I'm asking lkml what's happening.
>>
>>

> Well it doesn't use glibc per se, gcc uses the glibc.....however, his uname
> -a output does look funky.
My point exactly.

> Here is mine: System uname: 2.6.24.7 x86_64 Intel(R) Core(TM)2 CPU 6700 @
> 2.66GHz
>
> Did all underscores make it there by accident? What happens when you do a
> plain uname -a?

Here's my uname -a: Linux andrey 2.6.26.5-rt9 #6 PREEMPT RT Mon Oct 20
18:21:31 EDT 2008 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux
But emerge --info | grep uname is this: System uname:
Linux-2.6.26.5-rt9-i686-AMD_Athlon-tm-_XP_1700+-with-glibc2.0

Clearly, the underscores and -with-glibc are part of portage 2.2_rc12.
I'm going to scan through the portage _rc12.patch diff to see what's
going on.
Will report when finished.


-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

Update: it has something to do with platform.platform()
Now to search for platform by grepping all the .py files in /usr/lib.
Hopefully this will take less time than emerge --regen.


-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

Found the code, and it's actually part of python (as of 2.4).
Gentoo sets aliased to 1 when printing the system uname.
/usr/lib/python2.{4,5,6}/platform.py:

def _platform(*args):

    """ Helper to format the platform string in a filename
        compatible format e.g. "system-version-machine".
    """
    # Format the platform string
    platform = string.join(
        map(string.strip,
            filter(len,args)),
        '-')

    # Cleanup some possible filename obstacles...
    replace = string.replace
    platform = replace(platform,' ','_')
    platform = replace(platform,'/','-')
    platform = replace(platform,'\\','-')
    platform = replace(platform,':','-')
    platform = replace(platform,';','-')
    platform = replace(platform,'"','-')
    platform = replace(platform,'(','-')
    platform = replace(platform,')','-')

    # No need to report 'unknown' information...
    platform = replace(platform,'unknown','')

    # Fold '--'s and remove trailing '-'
    while 1:
        cleaned = replace(platform,'--','-')
        if cleaned == platform:
            break
        platform = cleaned
    while platform[-1] == '-':
        platform = platform[:-1]

    return platform

def platform(aliased=0, terse=0):

    """ Returns a single string identifying the underlying platform
        with as much useful information as possible (but no more :).

        The output is intended to be human readable rather than
        machine parseable. It may look different on different
        platforms and this is intended.

        If "aliased" is true, the function will use aliases for
        various platforms that report system names which differ from
        their common names, e.g. SunOS will be reported as
        Solaris. The system_alias() function is used to implement
        this.

        Setting terse to true causes the function to return only the
        absolute minimum information needed to identify the platform.

    """
    result = _platform_cache.get((aliased, terse), None)
    if result is not None:
        return result

    # Get uname information and then apply platform specific cosmetics
    # to it...
    system,node,release,version,machine,processor = uname()
    if machine == processor:
        processor = ''
    if aliased:
        system,release,version = system_alias(system,release,version)

    if system == 'Windows':
        # MS platforms
        rel,vers,csd,ptype = win32_ver(version)
        if terse:
            platform = _platform(system,release)
        else:
            platform = _platform(system,release,version,csd)

    elif system in ('Linux',):
        # Linux based systems
        distname,distversion,distid = dist('')
        if distname and not terse:
            platform = _platform(system,release,machine,processor,
                                 'with',
                                 distname,distversion,distid)
        else:
            # If the distribution name is unknown check for libc vs. glibc
            libcname,libcversion = libc_ver(sys.executable)
            platform = _platform(system,release,machine,processor,
                                 'with',
                                 libcname+libcversion)
    elif system == 'Java':
        # Java platforms
        r,v,vminfo,(os_name,os_version,os_arch) = java_ver()
        if terse:
            platform = _platform(system,release,version)
        else:
            platform = _platform(system,release,version,
                                 'on',
                                 os_name,os_version,os_arch)

    elif system == 'MacOS':
        # MacOS platforms
        if terse:
            platform = _platform(system,release)
        else:
            platform = _platform(system,release,machine)

    else:
        # Generic handler
        if terse:
            platform = _platform(system,release)
        else:
            bits,linkage = architecture(sys.executable)
            platform = _platform(system,release,machine,processor,bits,linkage)

    _platform_cache[(aliased, terse)] = platform
    return platform


Proof: run /usr/lib/python2.{4,5,6}/platform.py
aliased and terse have no effect wrt output (kernel_version-with-libc_version)
-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Andrey Falko]

[-- Attachment #1: Type: text/plain, Size: 4849 bytes --]

On Wed, Oct 29, 2008 at 4:51 PM, Andrey Vul <andrey.vul@gmail.com> wrote:

> Found the code, and it's actually part of python (as of 2.4).
> Gentoo sets aliased to 1 when printing the system uname.
> /usr/lib/python2.{4,5,6}/platform.py:
>
> def _platform(*args):
>
>    """ Helper to format the platform string in a filename
>        compatible format e.g. "system-version-machine".
>    """
>    # Format the platform string
>    platform = string.join(
>        map(string.strip,
>            filter(len,args)),
>        '-')
>
>    # Cleanup some possible filename obstacles...
>    replace = string.replace
>    platform = replace(platform,' ','_')
>    platform = replace(platform,'/','-')
>    platform = replace(platform,'\\','-')
>    platform = replace(platform,':','-')
>    platform = replace(platform,';','-')
>    platform = replace(platform,'"','-')
>    platform = replace(platform,'(','-')
>    platform = replace(platform,')','-')
>
>    # No need to report 'unknown' information...
>    platform = replace(platform,'unknown','')
>
>    # Fold '--'s and remove trailing '-'
>    while 1:
>        cleaned = replace(platform,'--','-')
>        if cleaned == platform:
>            break
>        platform = cleaned
>    while platform[-1] == '-':
>        platform = platform[:-1]
>
>    return platform
>
> def platform(aliased=0, terse=0):
>
>    """ Returns a single string identifying the underlying platform
>        with as much useful information as possible (but no more :).
>
>        The output is intended to be human readable rather than
>        machine parseable. It may look different on different
>        platforms and this is intended.
>
>        If "aliased" is true, the function will use aliases for
>        various platforms that report system names which differ from
>        their common names, e.g. SunOS will be reported as
>        Solaris. The system_alias() function is used to implement
>        this.
>
>        Setting terse to true causes the function to return only the
>        absolute minimum information needed to identify the platform.
>
>    """
>    result = _platform_cache.get((aliased, terse), None)
>    if result is not None:
>        return result
>
>    # Get uname information and then apply platform specific cosmetics
>    # to it...
>    system,node,release,version,machine,processor = uname()
>    if machine == processor:
>        processor = ''
>    if aliased:
>        system,release,version = system_alias(system,release,version)
>
>    if system == 'Windows':
>        # MS platforms
>        rel,vers,csd,ptype = win32_ver(version)
>        if terse:
>            platform = _platform(system,release)
>        else:
>            platform = _platform(system,release,version,csd)
>
>    elif system in ('Linux',):
>        # Linux based systems
>        distname,distversion,distid = dist('')
>        if distname and not terse:
>            platform = _platform(system,release,machine,processor,
>                                 'with',
>                                 distname,distversion,distid)
>        else:
>            # If the distribution name is unknown check for libc vs. glibc
>            libcname,libcversion = libc_ver(sys.executable)
>            platform = _platform(system,release,machine,processor,
>                                 'with',
>                                 libcname+libcversion)
>    elif system == 'Java':
>        # Java platforms
>        r,v,vminfo,(os_name,os_version,os_arch) = java_ver()
>        if terse:
>            platform = _platform(system,release,version)
>        else:
>            platform = _platform(system,release,version,
>                                 'on',
>                                 os_name,os_version,os_arch)
>
>    elif system == 'MacOS':
>        # MacOS platforms
>        if terse:
>            platform = _platform(system,release)
>        else:
>            platform = _platform(system,release,machine)
>
>    else:
>        # Generic handler
>        if terse:
>            platform = _platform(system,release)
>        else:
>            bits,linkage = architecture(sys.executable)
>            platform =
> _platform(system,release,machine,processor,bits,linkage)
>
>    _platform_cache[(aliased, terse)] = platform
>    return platform
>
>
> Proof: run /usr/lib/python2.{4,5,6}/platform.py
> aliased and terse have no effect wrt output
> (kernel_version-with-libc_version)
> --
> Andrey Vul
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
Good digging around :). So this is a python bug then? Or does portage need
to be update for some change that went into python? Actually, is this really
even a bug...its just a minor cosmetic problem really.

[-- Attachment #2: Type: text/html, Size: 7965 bytes --]

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

>
> Good digging around :). So this is a python bug then? Or does portage need
> to be update for some change that went into python? Actually, is this really
> even a bug...its just a minor cosmetic problem really.
>
One's bug is another's feature.
libc in uname is honestly WTF but this begs the real question: why
doesn't portage (emerge and repoman to be specific) simply get the
output of uname -a ? It's not written in C, you don't have to mess
around with 5-6 fd's to get the needed data.

And I think that this is both a design bug and a red herring.

By the way, should I make a bug report with a patch to remove this issue?
Making it selectable via FEATURES requires more digging around in portage.
-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Andrey Falko]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

On Wed, Oct 29, 2008 at 5:03 PM, Andrey Vul <andrey.vul@gmail.com> wrote:

> >
> > Good digging around :). So this is a python bug then? Or does portage
> need
> > to be update for some change that went into python? Actually, is this
> really
> > even a bug...its just a minor cosmetic problem really.
> >
> One's bug is another's feature.
> libc in uname is honestly WTF but this begs the real question: why
> doesn't portage (emerge and repoman to be specific) simply get the
> output of uname -a ? It's not written in C, you don't have to mess
> around with 5-6 fd's to get the needed data.
>
> And I think that this is both a design bug and a red herring.
>
> By the way, should I make a bug report with a patch to remove this issue?
> Making it selectable via FEATURES requires more digging around in portage.
> --
> Andrey Vul
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
Maybe we should ask gentoo-dev? The reason not to use uname -a straight up
is because it forces portage to depend on coreutils. Portage ebuilds
currently do not depend on it unless userland_GNU is enabled. I'm split, I
prefer code to always be as easy as possible, yet I don't like unnecessary
dependencies.

[-- Attachment #2: Type: text/html, Size: 1784 bytes --]

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

On Wed, Oct 29, 2008 at 8:15 PM, Andrey Falko <ma3oxuct@gmail.com> wrote:
>
>
> On Wed, Oct 29, 2008 at 5:03 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
>>
>> >
>> > Good digging around :). So this is a python bug then? Or does portage
>> > need
>> > to be update for some change that went into python? Actually, is this
>> > really
>> > even a bug...its just a minor cosmetic problem really.
>> >
>> One's bug is another's feature.
>> libc in uname is honestly WTF but this begs the real question: why
>> doesn't portage (emerge and repoman to be specific) simply get the
>> output of uname -a ? It's not written in C, you don't have to mess
>> around with 5-6 fd's to get the needed data.
>>
>> And I think that this is both a design bug and a red herring.
>>
>> By the way, should I make a bug report with a patch to remove this issue?
>> Making it selectable via FEATURES requires more digging around in portage.
>> --
>> Andrey Vul
>>
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing in e-mail?
>>
>
> Maybe we should ask gentoo-dev? The reason not to use uname -a straight up
> is because it forces portage to depend on coreutils. Portage ebuilds
> currently do not depend on it unless userland_GNU is enabled. I'm split, I
> prefer code to always be as easy as possible, yet I don't like unnecessary
> dependencies.
>
I'm going to try and reverse-engineer uname and make it python-able. I
just hope python<->C is much more simple than Java<->C (JNI is a
complex, horrible, and ugly piece of bloat).


-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Joshua Murphy]

On Wed, Oct 29, 2008 at 7:51 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
<snip>
>    elif system in ('Linux',):
>        # Linux based systems
>        distname,distversion,distid = dist('')
>        if distname and not terse:
>            platform = _platform(system,release,machine,processor,
>                                 'with',
>                                 distname,distversion,distid)
>        else:
>            # If the distribution name is unknown check for libc vs. glibc
>            libcname,libcversion = libc_ver(sys.executable)
>            platform = _platform(system,release,machine,processor,
>                                 'with',
>                                 libcname+libcversion)
<snip>

Hrm. I know just enough about python to get myself in trouble here...
but it looks like a python bug in magicking up the libc name and
version... but the below is WAY outside my level of practice with
python (it'll take re-reading and digging elsewhere a good few times
if I'm ever to make sense of it...

------------------
def libc_ver(executable=sys.executable,lib='',version='',

             chunksize=2048):

    """ Tries to determine the libc version that the file executable
        (which defaults to the Python interpreter) is linked against.

        Returns a tuple of strings (lib,version) which default to the
        given parameters in case the lookup fails.

        Note that the function has intimate knowledge of how different
        libc versions add symbols to the executable and thus is probably
        only useable for executables compiled using gcc.

        The file is read and scanned in chunks of chunksize bytes.

    """
    f = open(executable,'rb')
    binary = f.read(chunksize)
    pos = 0
    while 1:
        m = _libc_search.search(binary,pos)
        if not m:
            binary = f.read(chunksize)
            if not binary:
                break
            pos = 0
            continue
        libcinit,glibc,glibcversion,so,threads,soversion = m.groups()
        if libcinit and not lib:
            lib = 'libc'
        elif glibc:
            if lib != 'glibc':
                lib = 'glibc'
                version = glibcversion
            elif glibcversion > version:
                version = glibcversion
        elif so:
            if lib != 'glibc':
                lib = 'libc'
                if soversion > version:
                    version = soversion
                if threads and version[-len(threads):] != threads:
                    version = version + threads
        pos = m.end()
    f.close()
    return lib,version
------------------

It parses the header of an executable and guesses, but... the how is
too many directions from this that I'm not seeing it with my haphazard
abuse of grep. I'd presume anything that might care what platform it's
running on (underneath python itself) would be susceptible, so a word
thrown in the direction of upstream python would be the main way to
go... though it looks like emerge didn't used to use that call...

Portage 2.1.4.5 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0,
2.6.25-gentoo-r7-mahain i686)
=================================================================
System uname: 2.6.25-gentoo-r7-mahain i686 AMD Athlon(tm) MP 2400+

is my output, based on a call in emerge to "uname -mrp" .. not
platform.platform()

Looks like gentoo-dev aimed to drop that dependency in newer versions after all.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

On Wed, Oct 29, 2008 at 8:47 PM, Joshua Murphy <poisonbl@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 7:51 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
> <snip>
>>    elif system in ('Linux',):
>>        # Linux based systems
>>        distname,distversion,distid = dist('')
>>        if distname and not terse:
>>            platform = _platform(system,release,machine,processor,
>>                                 'with',
>>                                 distname,distversion,distid)
>>        else:
>>            # If the distribution name is unknown check for libc vs. glibc
>>            libcname,libcversion = libc_ver(sys.executable)
>>            platform = _platform(system,release,machine,processor,
>>                                 'with',
>>                                 libcname+libcversion)
> <snip>
>
> Hrm. I know just enough about python to get myself in trouble here...
> but it looks like a python bug in magicking up the libc name and
> version... but the below is WAY outside my level of practice with
> python (it'll take re-reading and digging elsewhere a good few times
> if I'm ever to make sense of it...
>
> ------------------
> def libc_ver(executable=sys.executable,lib='',version='',
>
>             chunksize=2048):
>
>    """ Tries to determine the libc version that the file executable
>        (which defaults to the Python interpreter) is linked against.
>
>        Returns a tuple of strings (lib,version) which default to the
>        given parameters in case the lookup fails.
>
>        Note that the function has intimate knowledge of how different
>        libc versions add symbols to the executable and thus is probably
>        only useable for executables compiled using gcc.
>
>        The file is read and scanned in chunks of chunksize bytes.
>
>    """
>    f = open(executable,'rb')
>    binary = f.read(chunksize)
>    pos = 0
>    while 1:
>        m = _libc_search.search(binary,pos)
>        if not m:
>            binary = f.read(chunksize)
>            if not binary:
>                break
>            pos = 0
>            continue
>        libcinit,glibc,glibcversion,so,threads,soversion = m.groups()
>        if libcinit and not lib:
>            lib = 'libc'
>        elif glibc:
>            if lib != 'glibc':
>                lib = 'glibc'
>                version = glibcversion
>            elif glibcversion > version:
>                version = glibcversion
>        elif so:
>            if lib != 'glibc':
>                lib = 'libc'
>                if soversion > version:
>                    version = soversion
>                if threads and version[-len(threads):] != threads:
>                    version = version + threads
>        pos = m.end()
>    f.close()
>    return lib,version
> ------------------
>
> It parses the header of an executable and guesses, but... the how is
> too many directions from this that I'm not seeing it with my haphazard
> abuse of grep. I'd presume anything that might care what platform it's
> running on (underneath python itself) would be susceptible, so a word
> thrown in the direction of upstream python would be the main way to
> go... though it looks like emerge didn't used to use that call...
>
> Portage 2.1.4.5 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0,
> 2.6.25-gentoo-r7-mahain i686)
> =================================================================
> System uname: 2.6.25-gentoo-r7-mahain i686 AMD Athlon(tm) MP 2400+
>
> is my output, based on a call in emerge to "uname -mrp" .. not
> platform.platform()
>
> Looks like gentoo-dev aimed to drop that dependency in newer versions after all.
Is it really better than making a small umake clone (to remove the
coreutils dependency)?
All *nixes (should) have uname, and you can scan PATH if uname exists.
If it doesn't, then emerge & install the mini-uname.

-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

On Wed, Oct 29, 2008 at 8:47 PM, Joshua Murphy <poisonbl@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 7:51 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
> <snip>
>>    elif system in ('Linux',):
>>        # Linux based systems
>>        distname,distversion,distid = dist('')
>>        if distname and not terse:
>>            platform = _platform(system,release,machine,processor,
>>                                 'with',
>>                                 distname,distversion,distid)
>>        else:
>>            # If the distribution name is unknown check for libc vs. glibc
>>            libcname,libcversion = libc_ver(sys.executable)
>>            platform = _platform(system,release,machine,processor,
>>                                 'with',
>>                                 libcname+libcversion)
> <snip>
>
> Hrm. I know just enough about python to get myself in trouble here...
> but it looks like a python bug in magicking up the libc name and
> version... but the below is WAY outside my level of practice with
> python (it'll take re-reading and digging elsewhere a good few times
> if I'm ever to make sense of it...
>
> ------------------
> def libc_ver(executable=sys.executable,lib='',version='',
>
>             chunksize=2048):
>
>    """ Tries to determine the libc version that the file executable
>        (which defaults to the Python interpreter) is linked against.
>
>        Returns a tuple of strings (lib,version) which default to the
>        given parameters in case the lookup fails.
>
>        Note that the function has intimate knowledge of how different
>        libc versions add symbols to the executable and thus is probably
>        only useable for executables compiled using gcc.
>
>        The file is read and scanned in chunks of chunksize bytes.
>
>    """
>    f = open(executable,'rb')
>    binary = f.read(chunksize)
>    pos = 0
>    while 1:
>        m = _libc_search.search(binary,pos)
>        if not m:
>            binary = f.read(chunksize)
>            if not binary:
>                break
>            pos = 0
>            continue
>        libcinit,glibc,glibcversion,so,threads,soversion = m.groups()
>        if libcinit and not lib:
>            lib = 'libc'
>        elif glibc:
>            if lib != 'glibc':
>                lib = 'glibc'
>                version = glibcversion
>            elif glibcversion > version:
>                version = glibcversion
>        elif so:
>            if lib != 'glibc':
>                lib = 'libc'
>                if soversion > version:
>                    version = soversion
>                if threads and version[-len(threads):] != threads:
>                    version = version + threads
>        pos = m.end()
>    f.close()
>    return lib,version
> ------------------
>
> It parses the header of an executable and guesses, but... the how is
> too many directions from this that I'm not seeing it with my haphazard
> abuse of grep. I'd presume anything that might care what platform it's
> running on (underneath python itself) would be susceptible, so a word
> thrown in the direction of upstream python would be the main way to
> go... though it looks like emerge didn't used to use that call...
>
> Portage 2.1.4.5 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0,
> 2.6.25-gentoo-r7-mahain i686)
> =================================================================
> System uname: 2.6.25-gentoo-r7-mahain i686 AMD Athlon(tm) MP 2400+
>
> is my output, based on a call in emerge to "uname -mrp" .. not
> platform.platform()
>
> Looks like gentoo-dev aimed to drop that dependency in newer versions after all.
The creator of paludis was right ... portage is a jack of all trades
and a master of none.



-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Paul Hartman]

On Wed, Oct 29, 2008 at 7:03 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
>>
>> Good digging around :). So this is a python bug then? Or does portage need
>> to be update for some change that went into python? Actually, is this really
>> even a bug...its just a minor cosmetic problem really.
>>
> One's bug is another's feature.
> libc in uname is honestly WTF but this begs the real question: why
> doesn't portage (emerge and repoman to be specific) simply get the
> output of uname -a ? It's not written in C, you don't have to mess
> around with 5-6 fd's to get the needed data.
>
> And I think that this is both a design bug and a red herring.
>
> By the way, should I make a bug report with a patch to remove this issue?
> Making it selectable via FEATURES requires more digging around in portage.
> --
> Andrey Vul

Dear Andrey & Andrey, thanks for the good info & ideas :)

For the record, my uname -a is:

Linux e6600 2.6.27-gentoo-r1 #1 SMP PREEMPT Thu Oct 23 17:45:32 CDT
2008 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel
GNU/Linux

Compared to that line from emerge --info:

System uname: Linux-2.6.27-gentoo-r1-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.2.5

Regards,
Paul

Re: [gentoo-user] A question about emerge --info

[Andrey Vul]

On Wed, Oct 29, 2008 at 8:15 PM, Andrey Falko <ma3oxuct@gmail.com> wrote:
>
>
> On Wed, Oct 29, 2008 at 5:03 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
>>
>> >
>> > Good digging around :). So this is a python bug then? Or does portage
>> > need
>> > to be update for some change that went into python? Actually, is this
>> > really
>> > even a bug...its just a minor cosmetic problem really.
>> >
>> One's bug is another's feature.
>> libc in uname is honestly WTF but this begs the real question: why
>> doesn't portage (emerge and repoman to be specific) simply get the
>> output of uname -a ? It's not written in C, you don't have to mess
>> around with 5-6 fd's to get the needed data.
>>
>> And I think that this is both a design bug and a red herring.
>>
>> By the way, should I make a bug report with a patch to remove this issue?
>> Making it selectable via FEATURES requires more digging around in portage.
>> --
>> Andrey Vul
>>
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing in e-mail?
>>
>
> Maybe we should ask gentoo-dev? The reason not to use uname -a straight up
> is because it forces portage to depend on coreutils. Portage ebuilds
> currently do not depend on it unless userland_GNU is enabled. I'm split, I
> prefer code to always be as easy as possible, yet I don't like unnecessary
> dependencies.
>
According to http://en.wikipedia.org/wiki/Uname , uname -s -r -m -p is
defined for all *nixes (with the exception of -p for HP-UX)
Unless you use uname -a, which is only supported in coreutils uname or
Darwin/MacOsX uname.

-- 
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [gentoo-user] A question about emerge --info

[Geralt]

Hi,
I don't know if this is clear by now, but apparently the glibc version
which is printed is the glibc version used to built python, because
>libcname,libcversion = libc_ver(sys.executable)
in this line the version is determined of sys.executable which is the
python interpreter used to run the script.

But I'm not sure if libc_ver is working correctly, since platform.py
says on my system "with-glibc2.0", but my current version is 2.6.1 and
I doubt that my python 2.5 was built with 2.0.

Some checking:
$ ldd $(which python)
        linux-gate.so.1 =>  (0xb7efb000)
        libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb7dcf000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7db7000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7db3000)
        libutil.so.1 => /lib/libutil.so.1 (0xb7daf000)
        libm.so.6 => /lib/libm.so.6 (0xb7d86000)
        libc.so.6 => /lib/libc.so.6 (0xb7c34000)
        /lib/ld-linux.so.2 (0xb7efc000)

and
$ ls -l /lib/libc.so.6
 lrwxrwxrwx 1 root root 13 2008-09-28 01:38 /lib/libc.so.6 -> libc-2.6.1.so
$ qfile /lib/libc.so.6
 sys-libs/glibc (/lib/libc.so.6)

$ eix -s glibc
[I] sys-libs/glibc
     Available versions:  (2.2)  [P]2.2.5-r10!s [P]2.3.2-r12!s
[P]2.3.5-r3!s [P]2.3.6-r4!s [P]2.3.6-r5!s 2.4-r4!s 2.5-r2!s 2.5-r3!s
2.5-r4!s **2.5.1!s ~2.6!s 2.6.1!s ~2.7-r2!s ~2.8_p20080602!s
        {build crosscompile_opts_headers-only debug erandom gd
glibc-compat20 glibc-omitfp hardened linuxthreads-tls multilib nls
nptl nptlonly pic profile selinux userlocales vanilla}
     Installed versions:  2.6.1(2.2)!s(01:38:10 AM
09/28/2008)(glibc-omitfp nls -crosscompile_opts_headers-only -debug
-gd -hardened -multilib -profile -selinux -vanilla)
     Homepage:            http://www.gnu.org/software/libc/libc.html
     Description:         GNU libc6 (also called glibc2) C library


As you can see 2.6.1 is installed and python is using this version of glibc.

That's why I'm wondering if it's not libc_ver which is buggy.





Geralt.

Re: [gentoo-user] A question about emerge --info

[Albert Hopkins]

On Wed, 2008-10-29 at 20:47 -0400, Joshua Murphy wrote:
> 
> Hrm. I know just enough about python to get myself in trouble here...
> but it looks like a python bug in magicking up the libc name and
> version... but the below is WAY outside my level of practice with
> python (it'll take re-reading and digging elsewhere a good few times
> if I'm ever to make sense of it...
> 
> ------------------
> def libc_ver(executable=sys.executable,lib='',version='',
> 
>              chunksize=2048):


<deleted>
This is a very simple hack which simply doesn't work.  Nice try.  It's
not so much portage's fault as it is Python.

Basically what python is doing is opening it's executable
(/usr/bin/python') and doing a egrep for 

    (__libc_init)|(GLIBC_([0-9.]+))|(libc(_\w+)?\.so(?:\.(\d[0-9.]*))?)

Then it finds the matches and tries to apply some "logic" to decide the
best answer.  On my system it's "GLIBC_2.0" and so platform.libc_ver()
returns ('glibc', '2.0') whereas my actual libc is glibc 2.8.

Obviously the person who wrote the function was trying to be
cross-platform.  Python runs on many different platforms, POSIX and
non-POSIX.  But the implementation is a bit "lazy" and, obviously,
inaccurate.

OTOH, if I were to take a guess I'd say not many people use the platform
module.  I've been programming in python for over 10 years and this is
the first time I've even looked at it.  Most code I've seen will use
sys.platform.  It only returns the OS name but, when you're using a
cross-platform language, that's usually all you're worried about.

So partial blame goes to both python and portage: python for it's shoddy
implementation of platform.libc_ver() and portage for relying on it :-)

-a

Re: [gentoo-user] A question about emerge --info

[Heiko Wundram]

Am Thursday 30 October 2008 13:26:27 schrieb Albert Hopkins:
> On Wed, 2008-10-29 at 20:47 -0400, Joshua Murphy wrote:
> > Hrm. I know just enough about python to get myself in trouble here...
> > but it looks like a python bug in magicking up the libc name and
> > version... but the below is WAY outside my level of practice with
> > python (it'll take re-reading and digging elsewhere a good few times
> > if I'm ever to make sense of it...
> >
> > ------------------
> > def libc_ver(executable=sys.executable,lib='',version='',
> >
> >              chunksize=2048):
>
> <deleted>
> This is a very simple hack which simply doesn't work.  Nice try.  It's
> not so much portage's fault as it is Python.
>
> Basically what python is doing is opening it's executable
> (/usr/bin/python') and doing a egrep for
>
>     (__libc_init)|(GLIBC_([0-9.]+))|(libc(_\w+)?\.so(?:\.(\d[0-9.]*))?)
>
> Then it finds the matches and tries to apply some "logic" to decide the
> best answer.  On my system it's "GLIBC_2.0" and so platform.libc_ver()
> returns ('glibc', '2.0') whereas my actual libc is glibc 2.8.
>
> Obviously the person who wrote the function was trying to be
> cross-platform.  Python runs on many different platforms, POSIX and
> non-POSIX.  But the implementation is a bit "lazy" and, obviously,
> inaccurate.

That's utter bollocks and shows a fundamental misunderstanding of shared 
libraries.

True, your installed glibc might be _package version_ 2.8, but the base 
_interface_ (as in ABI) defined and supported by your shared glibc is version 
2.0, which is the currently developed interface version (the interface is 
also known as libc6), and that's what's actually of any interest to a 
dynamically linked application.

Guess why applications dynamically linked against a 2.3 glibc can still be run 
(without recompilation!) on a 2.8 glibc, and mostly vice-versa, except when 
the application linked with a 2.8 glibc uses symbols which were introduced 
later than the libc you're trying to run it on, but in that case these 
symbols aren't marked as GLIBC_2.0 in your 2.8 glibc, but as GLIBC_2.4, for 
example (stating that this symbol was first introduced and conforms to the 
ABI that glibc 2.4 upwards have/has).

Do a readelf -a /lib/libc.so.6 to see what I'm talking about (symbol 
versioning, and multiple symbols for one name differing in the symbol 
version).

> ...
> So partial blame goes to both python and portage: python for it's shoddy
> implementation of platform.libc_ver() and portage for relying on it :-)

Again, this is utter bullshit. Python doesn't have a "shoddy" implementation 
of libc_ver(), it just doesn't give you what you expect it to give you (it's 
not a package manager, for gods sake), but rather what's of actual interest 
to anyone doing application development.

-- 
Heiko Wundram
hackerkey://v4sw7CHJLSUY$hw5ln5pr7FOP$ck2ma9u7FL$w3DVWXm0l7GL$i65e6t3EMRSXb7ADORen5a26s5MSr2p-6.62/-6.56g5AORZ

Re: [gentoo-user] A question about emerge --info

[Albert Hopkins]

On Thu, 2008-10-30 at 13:43 +0100, Heiko Wundram wrote:

<snip>

> Again, this is utter bullshit. Python doesn't have a "shoddy" implementation 
> of libc_ver(), it just doesn't give you what you expect it to give you (it's 
> not a package manager, for gods sake), but rather what's of actual interest 
> to anyone doing application development.
> 

Thanks for the explanation. I realize the difference between interface
version and actual libc version.  However I was going on the actual
function documentation and the fact that all the other *_ver() functions
in the platform module give the actual version.  My apologies if I
confused anyone.

-a