Re: [gentoo-user] A question about emerge --info
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
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
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
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
[gentoo-user] A question about emerge --info
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: [EMAIL PROTECTED] Timestamp of tree: Tue, 28 Oct 2008 00:31:02 + 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
On Wed, Oct 29, 2008 at 6:53 PM, Paul Hartman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Timestamp of tree: Tue, 28 Oct 2008 00:31:02 + 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
On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman [EMAIL PROTECTED][EMAIL PROTECTED] 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 + 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.
Re: [gentoo-user] A question about emerge --info
On Wed, Oct 29, 2008 at 7:09 PM, Andrey Falko [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Timestamp of tree: Tue, 28 Oct 2008 00:31:02 + 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
On Wed, Oct 29, 2008 at 6:09 PM, Andrey Falko [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Timestamp of tree: Tue, 28 Oct 2008 00:31:02 + 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
On Wed, Oct 29, 2008 at 4:13 PM, Andrey Vul [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 7:09 PM, Andrey Falko [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman [EMAIL PROTECTED] [EMAIL PROTECTED] 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 + 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?
Re: [gentoo-user] A question about emerge --info
On Wed, Oct 29, 2008 at 7:23 PM, Andrey Falko [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 4:13 PM, Andrey Vul [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 7:09 PM, Andrey Falko [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 3:53 PM, Paul Hartman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Timestamp of tree: Tue, 28 Oct 2008 00:31:02 + 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
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
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
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
On Wed, Oct 29, 2008 at 5:03 PM, Andrey Vul [EMAIL PROTECTED] 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.
Re: [gentoo-user] A question about emerge --info
On Wed, Oct 29, 2008 at 8:15 PM, Andrey Falko [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 5:03 PM, Andrey Vul [EMAIL PROTECTED] 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
On Wed, Oct 29, 2008 at 7:51 PM, Andrey Vul [EMAIL PROTECTED] 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
On Wed, Oct 29, 2008 at 8:47 PM, Joshua Murphy [EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 7:51 PM, Andrey Vul [EMAIL PROTECTED] 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
On Wed, Oct 29, 2008 at 8:47 PM, Joshua Murphy [EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 7:51 PM, Andrey Vul [EMAIL PROTECTED] 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
On Wed, Oct 29, 2008 at 7:03 PM, Andrey Vul [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Regards, Paul
Re: [gentoo-user] A question about emerge --info
On Wed, Oct 29, 2008 at 8:15 PM, Andrey Falko [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 5:03 PM, Andrey Vul [EMAIL PROTECTED] 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?
