Incomplete upload found in Debian upload queue
Probably you are the uploader of the following file(s) in the Debian upload queue directory: eglibc_2.9-20.dsc This looks like an upload, but a .changes file is missing, so the job cannot be processed. If no .changes file arrives within 15:40:47, the files will be deleted. If you didn't upload those files, please just ignore this message. Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Makeinfo version parsing broken?
I'm a debian-hppa porter, and I was building the most recent libc6 from unstable when I noticed: ~~~ configure: WARNING: *** These auxiliary programs are missing or incompatible versions: makeinfo *** some features will be disabled. *** Check the INSTALL file for required versions. ~~~ During glibc's configure. The installed makefino is 4.13 (part of texinfo), and that should meet glibc requirements. I don't see this warning when doing native glibc build (I'm also the upstream hppa ports maintainer). Has anyone already looked into this? Steps to reproduce would be: ~~~ apt-get build-dep libc6 apt-get source libc6 cd eglibc-2.9 dpkg-buildpackage -rfakeroot -b ~~~ It's a minor issue, and may look into this later. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Makeinfo version parsing broken?
On Mon, Jul 13, 2009 at 09:28:21AM -0400, Carlos O'Donell wrote: I'm a debian-hppa porter, and I was building the most recent libc6 from unstable when I noticed: ~~~ configure: WARNING: *** These auxiliary programs are missing or incompatible versions: makeinfo *** some features will be disabled. *** Check the INSTALL file for required versions. ~~~ During glibc's configure. The installed makefino is 4.13 (part of texinfo), and that should meet glibc requirements. I don't see this warning when doing native glibc build (I'm also the upstream hppa ports maintainer). Has anyone already looked into this? This is actually normal. The build of info files is disabled in the main glibc code, as this documentation is considered non-free. It is packaged instead in glibc-doc-reference in the non-free section. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Makeinfo version parsing broken?
On Mon, Jul 13, 2009 at 9:33 AM, Aurelien Jarnoaurel...@aurel32.net wrote: On Mon, Jul 13, 2009 at 09:28:21AM -0400, Carlos O'Donell wrote: I'm a debian-hppa porter, and I was building the most recent libc6 from unstable when I noticed: ~~~ configure: WARNING: *** These auxiliary programs are missing or incompatible versions: makeinfo *** some features will be disabled. *** Check the INSTALL file for required versions. ~~~ During glibc's configure. The installed makefino is 4.13 (part of texinfo), and that should meet glibc requirements. I don't see this warning when doing native glibc build (I'm also the upstream hppa ports maintainer). Has anyone already looked into this? This is actually normal. The build of info files is disabled in the main glibc code, as this documentation is considered non-free. It is packaged instead in glibc-doc-reference in the non-free section. Thanks, but now I'm curious, why is the GFDL licensed documentation considered non-free? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
libc6 2.10?
Aurelian, Is there a debian libc6 2.10 somewhere? I see unstable has 2.9. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Makeinfo version parsing broken?
On Mon, Jul 13, 2009 at 09:36:54AM -0400, Carlos O'Donell wrote: On Mon, Jul 13, 2009 at 9:33 AM, Aurelien Jarnoaurel...@aurel32.net wrote: On Mon, Jul 13, 2009 at 09:28:21AM -0400, Carlos O'Donell wrote: I'm a debian-hppa porter, and I was building the most recent libc6 from unstable when I noticed: ~~~ configure: WARNING: *** These auxiliary programs are missing or incompatible versions: makeinfo *** some features will be disabled. *** Check the INSTALL file for required versions. ~~~ During glibc's configure. The installed makefino is 4.13 (part of texinfo), and that should meet glibc requirements. I don't see this warning when doing native glibc build (I'm also the upstream hppa ports maintainer). Has anyone already looked into this? This is actually normal. The build of info files is disabled in the main glibc code, as this documentation is considered non-free. It is packaged instead in glibc-doc-reference in the non-free section. Thanks, but now I'm curious, why is the GFDL licensed documentation considered non-free? The GFDL instead is not considered non-free, but the GFDL *with* invariant sections is considered non-free. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Makeinfo version parsing broken?
On Mon, Jul 13, 2009 at 12:38 PM, Aurelien Jarnoaurel...@aurel32.net wrote: The GFDL instead is not considered non-free, but the GFDL *with* invariant sections is considered non-free. Sorry, I don't follow, I assume you meant to write free somwhere instead of non-free? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libc6 2.10?
On Mon, Jul 13, 2009 at 10:40:32AM -0400, Carlos O'Donell wrote: Aurelian, Is there a debian libc6 2.10 somewhere? I see unstable has 2.9. My plan is to upload it to experimental once it builds correctly on alpha/ia64/hppa. Currently it is developed in the SVN [1]. I have made a current snapshot of the SVN, you can find it on [2]. Note that linuxthreads is still the default on HPPA, you have to tweak debian/sysdeps/hppa.mk to switch to NPTL. [1] http://svn.debian.org/viewsvn/pkg-glibc/ [2] http://temp.aurel32.net/ -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Makeinfo version parsing broken?
On Mon, Jul 13, 2009 at 12:47 PM, Aurelien Jarnoaurel...@aurel32.net wrote: GFDL *without* invariant sections - free GFDL *with* invariant sections - non-free Thanks. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Help on memchr() EGLIBC assembly code
On Mon, Jul 13, 2009 at 02:24:00PM -0400, Carlos O'Donell wrote: On Mon, Jul 13, 2009 at 1:31 PM, Aurelien Jarnoaurel...@aurel32.net wrote: With a lot of patches (E)GLIBC 2.10 builds on alpha, but it fails on the testsuite for the memchr() function, which is an optimized assembly code on alpha. Unfortunately I don't speak alpha assembly very well, so help is needed. The problem is that the memchr() function on alpha uses prefetch, which can cause a page boundary to be crossed, while the standards (POSIX and C99) says it should stop when a match is found. I have built a small testcase (see file attached), which contains the code to trigger the bug and the assembly code of the memchr() function, copied from EGLIBC. It would be nice if someone can fix the assembly code so that the prefetching does not create memory faults. Thanks in advance. If you remove: ./sysdeps/alpha/alphaev6/memchr.S ./sysdeps/alpha/memchr.S and allow the build to fallback on string/memchr.c do the tests pass? You can always add memchr.S routines back in a later release if you need an immediate workaround. Yeah, it works, and that's actually my plan if I get no answer. But I would really like to see this fixed now, as otherwise, it will most probably stay like that indefinitely. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
EGLIBC: help on ia64 optimized math library
Hi, I have filled a bug upstream sometimes ago [1] about the ia64 optimized math library. According to the new POSIX version, some errno values have changes for some cases. The generic math code has been updated upstream as well as the testsuite. Unfortunately it has not been updated on ia64. It would be nice if someone can have a look. The current snapshot of eglibc 2.10 is available on [2]. Thanks in advance, Aurelien [1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=10163 [2] http://temp.aurel32.net/eglibc_2.10.1-0exp1.dsc -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Help on memchr() EGLIBC assembly code
On Mon, Jul 13, 2009 at 07:16:16PM -0300, Matt Turner wrote: On Mon, Jul 13, 2009 at 6:17 PM, Aurelien Jarnoaurel...@aurel32.net wrote: On Mon, Jul 13, 2009 at 02:24:00PM -0400, Carlos O'Donell wrote: On Mon, Jul 13, 2009 at 1:31 PM, Aurelien Jarnoaurel...@aurel32.net wrote: With a lot of patches (E)GLIBC 2.10 builds on alpha, but it fails on the testsuite for the memchr() function, which is an optimized assembly code on alpha. Unfortunately I don't speak alpha assembly very well, so help is needed. The problem is that the memchr() function on alpha uses prefetch, which can cause a page boundary to be crossed, while the standards (POSIX and C99) says it should stop when a match is found. I have built a small testcase (see file attached), which contains the code to trigger the bug and the assembly code of the memchr() function, copied from EGLIBC. It would be nice if someone can fix the assembly code so that the prefetching does not create memory faults. Thanks in advance. If you remove: ./sysdeps/alpha/alphaev6/memchr.S ./sysdeps/alpha/memchr.S and allow the build to fallback on string/memchr.c do the tests pass? You can always add memchr.S routines back in a later release if you need an immediate workaround. Yeah, it works, and that's actually my plan if I get no answer. But I would really like to see this fixed now, as otherwise, it will most probably stay like that indefinitely. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net I'm copying Richard Henderson and Ivan Kokshayshy on this, as they are without a doubt the most knowledgeable people about this sort of thing. Thanks. As an aside, please make sure these two bugs are fixed in eglibc (I don't know if they exist in eglibc, but I do realize that you filed them against glibc yourself -- so this is just a reminder). http://sources.redhat.com/bugzilla/show_bug.cgi?id=5350 http://sources.redhat.com/bugzilla/show_bug.cgi?id=5400 I have already put a first set of patches needed for alpha in a git repository [1], and sent a pull request on the libc-ports mailing list. I hope it will work better than filling bug reports. If it also fails, I'll send them to EGLIBC. [1] http://git.aurel32.net/?p=glibc-ports.git;a=shortlog;h=refs/heads/alpha-for-upstream -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Help on memchr() EGLIBC assembly code
On Mon, Jul 13, 2009 at 6:17 PM, Aurelien Jarnoaurel...@aurel32.net wrote: On Mon, Jul 13, 2009 at 02:24:00PM -0400, Carlos O'Donell wrote: On Mon, Jul 13, 2009 at 1:31 PM, Aurelien Jarnoaurel...@aurel32.net wrote: With a lot of patches (E)GLIBC 2.10 builds on alpha, but it fails on the testsuite for the memchr() function, which is an optimized assembly code on alpha. Unfortunately I don't speak alpha assembly very well, so help is needed. The problem is that the memchr() function on alpha uses prefetch, which can cause a page boundary to be crossed, while the standards (POSIX and C99) says it should stop when a match is found. I have built a small testcase (see file attached), which contains the code to trigger the bug and the assembly code of the memchr() function, copied from EGLIBC. It would be nice if someone can fix the assembly code so that the prefetching does not create memory faults. Thanks in advance. If you remove: ./sysdeps/alpha/alphaev6/memchr.S ./sysdeps/alpha/memchr.S and allow the build to fallback on string/memchr.c do the tests pass? You can always add memchr.S routines back in a later release if you need an immediate workaround. Yeah, it works, and that's actually my plan if I get no answer. But I would really like to see this fixed now, as otherwise, it will most probably stay like that indefinitely. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net I'm copying Richard Henderson and Ivan Kokshayshy on this, as they are without a doubt the most knowledgeable people about this sort of thing. As an aside, please make sure these two bugs are fixed in eglibc (I don't know if they exist in eglibc, but I do realize that you filed them against glibc yourself -- so this is just a reminder). http://sources.redhat.com/bugzilla/show_bug.cgi?id=5350 http://sources.redhat.com/bugzilla/show_bug.cgi?id=5400 Matt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
