r1494 - glibc-package/trunk/debian
Author: aurel32 Date: 2006-05-19 05:50:03 + (Fri, 19 May 2006) New Revision: 1494 Modified: glibc-package/trunk/debian/changelog Log: New changelog entry Modified: glibc-package/trunk/debian/changelog === --- glibc-package/trunk/debian/changelog2006-05-19 05:48:37 UTC (rev 1493) +++ glibc-package/trunk/debian/changelog2006-05-19 05:50:03 UTC (rev 1494) @@ -1,3 +1,9 @@ +glibc (2.3.6-10) UNRELEASED; urgency=low + + * + + -- Aurelien Jarno [EMAIL PROTECTED] Fri, 19 May 2006 05:49:18 + + glibc (2.3.6-9) unstable; urgency=low * Don't run make install with -j, as it is not SMP safe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of glibc_2.3.6-9_amd64.changes
glibc_2.3.6-9_amd64.changes uploaded successfully to localhost along with the files: glibc_2.3.6-9.dsc glibc_2.3.6-9.diff.gz glibc-doc_2.3.6-9_all.deb locales_2.3.6-9_all.deb libc6_2.3.6-9_amd64.deb libc6-dev_2.3.6-9_amd64.deb libc6-prof_2.3.6-9_amd64.deb libc6-pic_2.3.6-9_amd64.deb libc6-i386_2.3.6-9_amd64.deb libc6-dev-i386_2.3.6-9_amd64.deb nscd_2.3.6-9_amd64.deb libc6-dbg_2.3.6-9_amd64.deb libc6-udeb_2.3.6-9_amd64.udeb libnss-dns-udeb_2.3.6-9_amd64.udeb libnss-files-udeb_2.3.6-9_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Hello Aurelien, On 06-May-19 04:15, Aurelien Jarno wrote: [Ccing: amd64 and dpkg developers as they are concerned by this subject] Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6 package. Goswin von Brederlow asked for this link to be created in the postinst instead, so that packages could install files in both (/usr)/lib and (/usr)/lib64 directories. Could you please give me your opinion on that, so that I can take a decision? please do not change the status quo regarding the lib64 symlinks. During the porting of Debian to amd64 quite a few alternatives regarding the lib64 issue were discussed and tested. The biarch approach with /usr/lib and /usr/lib64 as two different directories failed badly. I have concerns about that: - I don't really want to add something specific to amd64 in postinst. But ok, that's not an argument. - I am not sure that creating the link in postinst will work. Creating it in preinst looks safer to me. - If you can install files in (/usr)/lib64, the files will end up in (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. - If you have two packages providing the same files in (/usr)/lib and (/usr)/lib64, then the files will be overwritten without warning. This is IMHO not acceptable. I share these concerns. The current policy which requires all packages to install native amd64 libraries in /usr/lib is simple and sane. This should not be changed. Anything which makes it easier to violate this simple policy will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently to problems which could be difficult to disentangle later. This is just my personal opinion. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc_2.3.6-9_amd64.changes ACCEPTED
Accepted: glibc-doc_2.3.6-9_all.deb to pool/main/g/glibc/glibc-doc_2.3.6-9_all.deb glibc_2.3.6-9.diff.gz to pool/main/g/glibc/glibc_2.3.6-9.diff.gz glibc_2.3.6-9.dsc to pool/main/g/glibc/glibc_2.3.6-9.dsc libc6-dbg_2.3.6-9_amd64.deb to pool/main/g/glibc/libc6-dbg_2.3.6-9_amd64.deb libc6-dev-i386_2.3.6-9_amd64.deb to pool/main/g/glibc/libc6-dev-i386_2.3.6-9_amd64.deb libc6-dev_2.3.6-9_amd64.deb to pool/main/g/glibc/libc6-dev_2.3.6-9_amd64.deb libc6-i386_2.3.6-9_amd64.deb to pool/main/g/glibc/libc6-i386_2.3.6-9_amd64.deb libc6-pic_2.3.6-9_amd64.deb to pool/main/g/glibc/libc6-pic_2.3.6-9_amd64.deb libc6-prof_2.3.6-9_amd64.deb to pool/main/g/glibc/libc6-prof_2.3.6-9_amd64.deb libc6-udeb_2.3.6-9_amd64.udeb to pool/main/g/glibc/libc6-udeb_2.3.6-9_amd64.udeb libc6_2.3.6-9_amd64.deb to pool/main/g/glibc/libc6_2.3.6-9_amd64.deb libnss-dns-udeb_2.3.6-9_amd64.udeb to pool/main/g/glibc/libnss-dns-udeb_2.3.6-9_amd64.udeb libnss-files-udeb_2.3.6-9_amd64.udeb to pool/main/g/glibc/libnss-files-udeb_2.3.6-9_amd64.udeb locales_2.3.6-9_all.deb to pool/main/g/glibc/locales_2.3.6-9_all.deb nscd_2.3.6-9_amd64.deb to pool/main/g/glibc/nscd_2.3.6-9_amd64.deb Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367999: libc6-i386: Can't upgrade package on amd64 arch
Package: libc6-i386 Version: 2.3.6-8 Severity: normal Preparing to replace libc6-i386 2.3.6-7 (using .../libc6-i386_2.3.6-8_amd64.deb) ... Unpacking replacement libc6-i386 ... dpkg: error processing /var/cache/apt/archives/libc6-i386_2.3.6-8_amd64.deb (--unpack): trying to overwrite `/usr/lib32', which is also in package lib32gfortran1 Errors were encountered while processing: /var/cache/apt/archives/libc6-i386_2.3.6-8_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-amd64-k8 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6-i386 depends on: ii libc6 2.3.6-8GNU C Library: Shared libraries libc6-i386 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Aurelien Jarno [EMAIL PROTECTED] writes: My intention is to seperate out 32bit stuff in lib and 64bit stuff in lib64 so that they comply with the FHS for each seperate package and can possibly be resorted into multiarch dirs by a conversion script. In this case the right thing to do is also the more helpfull one. But we will never be able to split lib and lib64 dirs on the filesystem if packages don't use them in the data.tar.gz first. So you in short you mean you want to allow, even temporarily to have both 32-bit and 64-bit libraries in /lib? That sucks. Aeh, no. As long as lib and lib64 are the same destination 32bit has to stay out of there. But once we get all 64bit stuff into lib64 (or a majority) a split can be atempted. I don't know where you have seen resistance from the glibc. We have uploaded a package ready from multiarch (with libc6 binaries splitted into libc-bin). But it has been rejected by the ftp masters. After seeing to much resistance, I have decided to stop on that. But I have always claimed that patches are welcomes, *if* you get an agreement from the ftpmasters and the release team. I don't want to spend my time on that. So please don't say we are making resistance. True. You have helped there. But even you were restistant to using the multiarch dirs (the x86_64-linux-gnu dirs). I'm talking about the dirs specificaly and not the wider multiarch iossues. happen even partialy for etch. Using lib64 now will make it much easier to change the dir to the multiarch name later if it is done with a proper abstraction (put the libdir in variable so only one place needs changing). Multiarch won't come in one big wave so now I'm trying to do it in many little steps. Well I don't see how it would help the transition to multiarch. The library path in multiarch is different, so the package would have to be changed again anyway. Because packages will be prepared to handle different libdirs. All that needs to be changed is the name of the libdir and not the handling for different names. For most packages this involves adding *.in files for debhelper (e.g. libfoobar.install) files. So here are my concerns about that: - I don't really want to add something specific to amd64 in postinst. But ok, that's not an argument. - If you can install files in /lib64, the files will end up in /lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. - If you have two packages providing the same files in /lib and /lib64, then the files will be overwritten without warning. This is not acceptable. That is a good point. I will have to test that. Not so much that you don't get a warning on overwrite (many systems have the default --force-overwrite option in dpkg.conf anyway) but it could be that upgrading from /lib to /lib64 in a package might loose the files (/lib64/foobar gets installed, then /lib/foobar gets removed). That's why I am not in favor of that, but I am not able to take the decision. I will send a mail to debian-devel to ask about more opinions. Bye, Aurelien MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Aurelien Jarno [EMAIL PROTECTED] writes: Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6 package. Goswin von Brederlow asked for this link to be created in the postinst instead, so that packages could install files in both (/usr)/lib and (/usr)/lib64 directories. I have concerns about that: - I don't really want to add something specific to amd64 in postinst. But ok, that's not an argument. - I am not sure that creating the link in postinst will work. Creating it in preinst looks safer to me. yes. - If you can install files in (/usr)/lib64, the files will end up in (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. Local admins are already allowed to convert directories into links, e.g. to move parts ot the directory tree to another disk. We had problems with that for the (/usr)/lib32 link used on amd64 and for example dpkg-shlibs was afaik patched to deal with it correctly. dpkg -S isn't but that could/should be fixed. - If you have two packages providing the same files in (/usr)/lib and (/usr)/lib64, then the files will be overwritten without warning. This is IMHO not acceptable. Could you please give me your opinion on that, so that I can take a decision? Thanks, Aurelien MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Andreas Jochens [EMAIL PROTECTED] writes: Hello Aurelien, On 06-May-19 04:15, Aurelien Jarno wrote: [Ccing: amd64 and dpkg developers as they are concerned by this subject] Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6 package. Goswin von Brederlow asked for this link to be created in the postinst instead, so that packages could install files in both (/usr)/lib and (/usr)/lib64 directories. Could you please give me your opinion on that, so that I can take a decision? please do not change the status quo regarding the lib64 symlinks. During the porting of Debian to amd64 quite a few alternatives regarding the lib64 issue were discussed and tested. The biarch approach with /usr/lib and /usr/lib64 as two different directories failed badly. I'm not suggesting splitting the dirs. Just the way the link is setup. I'm suggesting creating it in the maintainer scripts instead of the data.tar.gz so packages that do ship files in (/usr)/lib64 don't make libc6 unupgradable. I have concerns about that: - I don't really want to add something specific to amd64 in postinst. But ok, that's not an argument. - I am not sure that creating the link in postinst will work. Creating it in preinst looks safer to me. - If you can install files in (/usr)/lib64, the files will end up in (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. - If you have two packages providing the same files in (/usr)/lib and (/usr)/lib64, then the files will be overwritten without warning. This is IMHO not acceptable. I share these concerns. The current policy which requires all packages to install native amd64 libraries in /usr/lib is simple and sane. This should not be changed. Anything which makes it easier to violate this simple policy will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently to problems which could be difficult to disentangle later. The goal would be to actualy get everything into (/usr)/lib64 while intermittendly allowing a mixed usage. That would allow for FHS compliance for 32bit libraries shiped in lib32gcc1, lib32stdc++*, lib32asound, ia32-libs and more to come. This is just my personal opinion. Regards Andreas Jochens MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
On 06-May-19 11:02, Goswin von Brederlow wrote: Andreas Jochens [EMAIL PROTECTED] writes: Anything which makes it easier to violate this simple policy will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently to problems which could be difficult to disentangle later. The goal would be to actualy get everything into (/usr)/lib64 while intermittendly allowing a mixed usage. That would allow for FHS compliance for 32bit libraries shiped in lib32gcc1, lib32stdc++*, lib32asound, ia32-libs and more to come. Yes, I understand that it is your goal get everything into /usr/lib64. But this means that every single library package has to be changed to use /usr/lib64 instead /usr/lib. You will probably not achieve that in an etch or even in an etch+1 time frame. You will just get an ugly mixture of /usr/lib and /usr/lib64 usage. If you really want to do this, I suggest that you set up a test archive and convert everything to use /usr/lib64 and collect all the patches that are necessary to achieve this. Then these patches can be reviewed and it can be decided if this is the way to go. However, this has been tried before. The result was that this does not work well. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368022: libc6: rational rose license manager fails to start since last glibc update
Package: libc6 Version: 2.3.6-7 Severity: normal Hallo, since last glibc update the rational rose license manager produces the following error message at startup: ./rational: relocation error: ./rational: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Is there any workaround for this problem? Cheers Martin -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libc6 depends on: ii tzdata2006c-2Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
* Aurelien Jarno ([EMAIL PROTECTED]) wrote: The FHS is actually not very clear, as it says 64-bit libraries should be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib. This is a contradiction for a pure 64-bit system. The FHS is very clear about the path to the 64bit linker, and that goes through /lib64, getting rid of that isn't an option. - I am not sure that creating the link in postinst will work. Creating it in preinst looks safer to me. I'd be a little nervous about creating it in postinst too, honestly. - If you can install files in (/usr)/lib64, the files will end up in (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. Yeah, I'm not sure it really makes sense to need to install into both... It would have been much more useful for you to include the *reasoning* behind Goswin's request rather than just your reasons for not wanting to do what he's asking. - If you have two packages providing the same files in (/usr)/lib and (/usr)/lib64, then the files will be overwritten without warning. This is IMHO not acceptable. My guess is that his intent was actually to allow *seperate* packages to install into either /lib or /lib64 on a package-by-package basis. This might resolve some bugs in packages which, when they detect they're being compiled for amd64, default to installing into /lib64 instead of /lib. Personally I think that's something that just needs to be dealt with and those packages should be fixed but that's my guess as to where the question came from. It's also possible a given package wants to install some things in /lib64 (say, actual libraries) and other things in /lib (say, helper programs, ala blah-config). Could you please give me your opinion on that, so that I can take a decision? The link itself certainly can't go away. I'd be more inclined to say progams on a pure 64bit platform shouldn't install into /lib64 than to have some things installing into /lib and others into /lib64. Part of this comes from the concern that this will bring out other bugs in packages where having this distinction might cause overlaps as mentioned above. Thanks, Stephen signature.asc Description: Digital signature
Bug#368039: linux-kernel-headers: can't use _syscallx (x=2) with -fPIC on x86
Package: linux-kernel-headers
Version: 2.6.13+0rc3-2.1
Severity: normal
Hi,
When using _syscallx (with x=2) in an x86 shared library, gcc complains
that it can't find a BREG register, for instance:
#include sys/types.h
#include linux/unistd.h
_syscall2(int, tkill, pid_t, tid, int, sig)
int main(void) { tkill(0,0); }
gcc -c test.c -o test.o -fPIC
test.c: In function 'tkill':
test.c:4: error: can't find a register in class 'BREG' while reloading 'asm'
This is because with -fPIC, gcc keeps the GOT address in %ebx, and
refuses it be clobbered. In latest kernel sources (2.6.17-rc1 for
instance), the problem got fixed by saving %ebx in the assembly string:
#define _syscall2(type,name,type1,arg1,type2,arg2) \
type name(type1 arg1,type2 arg2) \
{ \
long __res; \
__asm__ volatile (push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx \
: =a (__res) \
: 0 (__NR_##name),ri ((long)(arg1)),c ((long)(arg2)) \
: memory); \
__syscall_return(type,__res); \
}
Please either upgrade to more recent kernel headers, or at least
backport these #defines.
Thanks,
Samuel
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc1
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
-- no debconf information
--
Samuel Thibault [EMAIL PROTECTED]
D m'enfin, le 5 juillet, le mec vient visiter le labo...
* D a marque d'une croix rouge le 5 juillet sur son agenda
y niarc niarc niarc
D cet homme va souffrir
B c'est donc le 5 juillet qu'il meurt d'un accident de la route écrasé par un
truck muni d'un pare buffle
-+- #ens-mim - repaire de terroristes -+-
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
On Fri, May 19, 2006 at 10:58:33AM +0200, Goswin von Brederlow wrote: Local admins are already allowed to convert directories into links, e.g. to move parts ot the directory tree to another disk. According to Steve Langasek in Message-ID: [EMAIL PROTECTED] that's not allowed and you should use bind mounts instead. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Goswin von Brederlow wrote: Aurelien Jarno [EMAIL PROTECTED] writes: I don't know where you have seen resistance from the glibc. We have uploaded a package ready from multiarch (with libc6 binaries splitted into libc-bin). But it has been rejected by the ftp masters. After seeing to much resistance, I have decided to stop on that. But I have always claimed that patches are welcomes, *if* you get an agreement from the ftpmasters and the release team. I don't want to spend my time on that. So please don't say we are making resistance. True. You have helped there. But even you were restistant to using the multiarch dirs (the x86_64-linux-gnu dirs). I'm talking about the dirs specificaly and not the wider multiarch iossues. So please have a look to the changelog of version 2.3.6-2: glibc (2.3.6-2) unstable; urgency=low [snip] * Build a 32-bit libc on amd64, using the new multiarch directories. (Closes: #274367) Such a change has been done, but it has been reverted on request from the release team. So please talk with them, and stop making false accusations. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Hi, I'm not suggesting splitting the dirs. Just the way the link is setup. I'm suggesting creating it in the maintainer scripts instead of the data.tar.gz so packages that do ship files in (/usr)/lib64 don't make libc6 unupgradable. On debootstrap install, libc6 postinst isn't actually ran that early, and if this change is made, probably require some hacks within debootstrap/cdebootstrap. regards, junichi -- [EMAIL PROTECTED],debian.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Junichi Uekawa [EMAIL PROTECTED] writes: Hi, I'm not suggesting splitting the dirs. Just the way the link is setup. I'm suggesting creating it in the maintainer scripts instead of the data.tar.gz so packages that do ship files in (/usr)/lib64 don't make libc6 unupgradable. On debootstrap install, libc6 postinst isn't actually ran that early, and if this change is made, probably require some hacks within debootstrap/cdebootstrap. regards, junichi Yes, preinst (or postinst) would have to mv /lib64/* /lib/; /lib/ld-linux.so.* ln -s lib /lib64 and the same for /usr/lib64. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365628: marked as done (postinst fails when LANG doesn't point to a valid locale)
Your message dated Fri, 19 May 2006 23:17:26 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#365628: postinst fails when LANG doesn't point to a valid locale has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: locales Version: 2.3.6-7 Severity: important Tags: patch # LANG=xx_XX DEBIAN_FRONTEND=noninteractive dpkg-reconfigure locales [...] *** update-locale: Error: invalid locale settings: when update-locale LANG is invoked, it verified LANG variable and, if invalid, aborts the script. The typical situation when this happens is: - You had belocs-locales-data installed. - You had LANG set to a locale that is only available in belocs, and not in glibc locales. - You attempt to replace belocs-locales-data with glibc locales. The following fix worked for me: --- /var/lib/dpkg/info/locales.postinst~2006-04-14 15:45:25.0 +0200 +++ /var/lib/dpkg/info/locales.postinst 2006-05-01 17:46:22.0 +0200 @@ -66,7 +66,7 @@ # Set default LANG environment variable if [ -e $EE ]; then # Remove previous definitions -/usr/sbin/update-locale LANG +LANG= /usr/sbin/update-locale LANG fi if [ -n $SELECTED ] [ $SELECTED != None ]; then /usr/sbin/update-locale LANG=$SELECTED But according to the manpage, I don't see why update-locale should care about the LANG env variable. Perhaps the problem is there? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.4.72 Debian configuration management sy ii libc6 [glibc-2.3.6-2] 2.3.6-7GNU C Library: Shared libraries locales recommends no packages. -- debconf information excluded ---End Message--- ---BeginMessage--- Version: 2.3.6-8 On Fri, May 05, 2006 at 01:55:09AM +0200, Denis Barbier wrote: On Wed, May 03, 2006 at 03:30:56PM +0200, Robert Millan wrote: Several problems have been reported because of inconsistencies between LANG and LANGUAGE, so I try to make sure that selected locale is usable. If these consistency checks make more harm than good, they will be dropped. AIUI, the checks update-locale is expected to do (and those --no-checks avoids) are the ones passed as arguments (ala update-locale LANG=foo). The manpage doesn't make any reference to variables passed through the environment. You are right, this is fixed now. Thanks. This has been fixed in 2.3.6-8, but I forgot to add the bug closer. Thanks for your report. Denis ---End Message---
Processed: retitle 357051 to glibc-doc: libc.info s9.4 qsort example uses wrong datatypes in function declaration
Processing commands for [EMAIL PROTECTED]: retitle 357051 glibc-doc: libc.info s9.4 qsort example uses wrong datatypes in function declaration Bug#357051: libc.info s9.4 qsort example is wrong Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: retitle 339572 to glibc-doc: please document that setlocale sets errno
Processing commands for [EMAIL PROTECTED]: retitle 339572 glibc-doc: please document that setlocale sets errno Bug#339572: glibc-doc: setlocale does set errno Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 360107
Processing commands for [EMAIL PROTECTED]: tags 360107 moreinfo fixed Bug#360107: glibc-doc: dangling symlinks in manpages There were no tags set. Tags added: moreinfo, fixed End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368116: libc6: robustness problem in preinst causing errors displayed by expr
Package: libc6 Version: 2.3.6-9 Severity: normal Upgrading libc6 gave 2 error messages saying expr: syntax error at preinst time. Running the script manually as simple user shows the following. + for dir in '$*' ++ readlink -f /lib/libc5-compat + dir=/lib/libc5-compat + expr /lib/libc5-compat : '/lib.*' + continue + for dir in '$*' ++ readlink -f /usr/i486-linuxlibc1/lib + dir= + expr : '/lib.*' expr: syntax error + expr : '/emul/.*' expr: syntax error + test -d -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.31-k6 Locale: LANG=C, LC_CTYPE=french (charmap=ISO-8859-1) Versions of packages libc6 depends on: ii tzdata2006c-2Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- Yann Dirson[EMAIL PROTECTED] | Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: | Freedom, Power, Stability, Gratis http://ydirson.free.fr/| Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#367999: libc6-i386: Can't upgrade package on amd64 arch
Processing commands for [EMAIL PROTECTED]: reassign 367999 lib32gfortran1 Bug#367999: libc6-i386: Can't upgrade package on amd64 arch Bug reassigned from package `libc6-i386' to `lib32gfortran1'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367999: libc6-i386: Can't upgrade package on amd64 arch
reassign 367999 lib32gfortran1 thanks g.gragnani wrote: Package: libc6-i386 Version: 2.3.6-8 Severity: normal Preparing to replace libc6-i386 2.3.6-7 (using .../libc6-i386_2.3.6-8_amd64.deb) ... Unpacking replacement libc6-i386 ... dpkg: error processing /var/cache/apt/archives/libc6-i386_2.3.6-8_amd64.deb (--unpack): trying to overwrite `/usr/lib32', which is also in package lib32gfortran1 Errors were encountered while processing: /var/cache/apt/archives/libc6-i386_2.3.6-8_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) The lib32gfortran1 package contains a /usr/lib32 library, while it should not. Reassigning the bug to this package. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc built with gcc-4.1
Hi all, As gcc-4.1 may be the default compiler soon (I hope so), I have tried to build the glibc with it. Currently it builds and works on the following architectures: amd64, hppa, i386, mips, mipsel, sparc The packages are available [1], but a but outdated. It should not be a problem, as the changes are not so important between this version and the current one. It would be nice if some other people could test them, so the problems (if any) could be fixed. It fails to build on powerpc, but I haven't investigated the problem yet. I will build it on arm as soon as I get back home, as my machine is currently down. I am looking for people to build an test it on alpha, ia64, m68k and s390. The source is available on the same place as the binaries [1]. Bye, Aurelien [1] http://people.debian.org/~aurel32/glibc -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368022: libc6: rational rose license manager fails to start since last glibc update
Martin Hans wrote: Package: libc6 Version: 2.3.6-7 Severity: normal Hallo, since last glibc update the rational rose license manager produces the following error message at startup: ./rational: relocation error: ./rational: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Is there any workaround for this problem? Well first we have to understand the problem. I don't really see what is wrong, as the symbol is present: [henry:~]$ objdump -T /lib/libc.so.6 | grep errno 000dfba0 gDF .text 0090 GLIBC_2.0 clnt_perrno 0011f360 gDO .bss 0004 (GLIBC_2.0) _errno 0011f360 gDO .bss 0004 (GLIBC_2.0) errno 000d3be0 gDF .text 0028 GLIBC_2.0 __h_errno_location 00120eb0 gDO .bss 0004 (GLIBC_2.0) h_errno 000155d0 gDF .text 0028 GLIBC_2.0 __errno_location 00120eb0 w DO .bss 0004 (GLIBC_2.0) _h_errno 000df7e0 gDF .text 0083 GLIBC_2.0 clnt_sperrno Which was the latest version which worked? Have you tried to upgrade the product? Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367633: [Patch] Fix build Error math-tests
Kazuhiro Inaoka wrote: Package:glibc Version:2.3.6-7 Serverity:wishlist Tags:patch Could you please apply the following patch? This patch is to fix build Error in math-tests. Could you please give us more information? The current glibc build correctly, so I don't really see what this patch does. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 368116
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.19 tags 368116 + pending Bug#368116: libc6: robustness problem in preinst causing errors displayed by expr Tags were: pending Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 368116
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.19 tags 368116 + pending Bug#368116: libc6: robustness problem in preinst causing errors displayed by expr There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
r1495 - in glibc-package/trunk/debian: . debhelper.in
Author: aurel32
Date: 2006-05-20 05:09:19 + (Sat, 20 May 2006)
New Revision: 1495
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/debhelper.in/libc.preinst
Log:
* debian/debhelper.in/libc.preinst: use the original path if readlink -f
fails to canonicalize the path. (Closes: bug#368116)
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2006-05-19 05:50:03 UTC (rev
1494)
+++ glibc-package/trunk/debian/changelog2006-05-20 05:09:19 UTC (rev
1495)
@@ -1,6 +1,8 @@
glibc (2.3.6-10) UNRELEASED; urgency=low
- *
+ [ Aurelien Jarno ]
+ * debian/debhelper.in/libc.preinst: use the original path if readlink -f
+fails to canonicalize the path. (Closes: bug#368116)
-- Aurelien Jarno [EMAIL PROTECTED] Fri, 19 May 2006 05:49:18 +
Modified: glibc-package/trunk/debian/debhelper.in/libc.preinst
===
--- glibc-package/trunk/debian/debhelper.in/libc.preinst2006-05-19
05:50:03 UTC (rev 1494)
+++ glibc-package/trunk/debian/debhelper.in/libc.preinst2006-05-20
05:09:19 UTC (rev 1495)
@@ -114,7 +114,8 @@
check_dirs () {
for dir in $*; do
# Follow symlinks
-dir=$(readlink -f $dir)
+dirlink=$(readlink -f $dir)
+[ -n $dirlink ] dir=$dirlink
# Handle /lib in LD_LIBRARY_PATH.
if expr $dir : /lib.* /dev/null; then
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
