Bug#267594: libc6 depends on bash
GOTO Masanori wrote: At Mon, 30 Aug 2004 06:20:06 +0200, Harald Dunkel wrote: IMHO libc6 should not depend upon other packages at all. If there is no way around this, then it should work with any /bin/sh, not just bash. Why does "there is no way around this" lead "it should work with any /bin/sh"? BTW, read libc6.postinst/preinst before replying... If libc6 needs a shell at installation time, then the risk for problems is higher for "bash only", than it would be if either bash, dash, ash, busybox, or whatever are supported. The user could use another shell if bash doesn't work for him. I have read libc6.preinst and postinst, but I am not sure what you are trying to tell? There are some "$()" inside which could be replaced by "``" to support other shells, but it doesn't look that difficult. Please don't get me wrong: I like bash. I am using it for about 10 years as my login shell. I completely agree that there should be no system without it. What I do not like in Debian are package dependencies that could be avoided. They make Debian more complex than it could be. And libc6 is such a fundamental package that its dependencies can become very painfull. Regards Harri
Bug#274367: serious conflict between ia32-libs and libc6
Frederik Schueler wrote: > Hello, > > On Mon, Apr 18, 2005 at 07:25:41AM +0200, Harald Dunkel wrote: > >>Preparing to replace ia32-libs 0.7.0.0.1.gcc4 (using >>.../ia32-libs_1.2.0.0.1.gcc4_amd64.deb) ... >>Unpacking replacement ia32-libs ... >>dpkg: error processing >>/var/cache/apt/archives/ia32-libs_1.2.0.0.1.gcc4_amd64.deb (--unpack): >> trying to overwrite `/lib/ld-linux.so.2', which is also in package libc6-i386 > > > >>This makes me very nervous. Could anybody please resolve this >>conflict? > > > Try purging the offending packages, or switch to pure64. > I will switch next weekend. Too many things are broken with gcc-3.4. Regards Harri signature.asc Description: OpenPGP digital signature
Bug#584914: metoo
I got the same problem for version 2.11.2-7. If I replace the "compat" in nsswitch.conf by "nis files" _and_ stop nscd, then it works. IMHO nscd should not ignore nsswitch.conf. Is this another bug? Please mail if I can help to track this down. Regards Harri -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cea7451.4000...@aixigo.de
Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Are there any news about this? Is this unique to eglibc? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz747QACgkQUTlbRTxpHjfLXwCggKtGYyzIFyXJbe1zaiiLLfIC JO8An3Gv2dVWjbjn9X0+G+NF3fHsATfv =ZjZr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cfbe3c1.4030...@afaics.de
Bug#584914: this serious
Hi folks, of course fixing bugs is an ugly business, but would it be possible to increase the priority of this bug report? This problem produced 30 minutes downtime on our CVS server. Many thanx Harri -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc25ff1.9060...@aixigo.de
question about overriding ld.so.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Looking at http://bugs.debian.org/572895 I wonder if it is reasonable to allow a hard-coded priority (the os abi tag set in a library) to override a configurable priority (ld.so.conf and ld.so.conf.d/*)? Shouldn't the package providing the library make use of ld.so.conf instead, too? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3l+j8ACgkQUTlbRTxpHjfmpwCeK/Nr4rXh/LkvplZ/okrN7ehq sdgAn1HwwWhyxzg9/Hl+5xj6DE6MC8b5 =cHDq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de5fa3f.4010...@afaics.de
Re: question about overriding ld.so.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Aurelien, On 06/04/11 13:06, Aurelien Jarno wrote: > > I do think it is reasonable. The idea behind hwcap or osversion is to > provide two versions of the same libraries and select the right one at > runtime depending on the hardware or kernel capabilities. > I see. But what if there are 2 versions of the same library on the same compatibility level, coming from different vendors? Vendor A uses the os abi tag (setting it to 2.4.20, which was +8 years ago), and vendor B doesn't care about ancient systems and doesn't set this tag. Obviously there is something wrong. As a consumer, how can I fix this and get the library I want? (I know "strip", but that would be cheating.) Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3rPDYACgkQUTlbRTxpHjdTQQCfcVM7fMKxGzj+XF6bg2+HTqx/ 7zIAnRlHeY3GG8H6rqUGwmkmO/Sb4hlR =dgGY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4deb3c36.4080...@afaics.de
Re: question about overriding ld.so.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/11 13:00, Aurelien Jarno wrote: > > I think the problem has to be fixed in the libraries themselves, this > can be done in two ways: > - the library not providing an os abi tag should be changed to provide > one. > - the library providing an (outdated) os abi tag should not be provided. > That should be obvious, but the vendors don't. :-( I would guess if vendor B sets his os abi tag to 2.6.32, overriding vendor A (2.4.20), then A would shout "foul". > As a consumer, here are the things you can do: > - Remove the os abi tag stripping the library Highly ugly, but it works. Its a hack. > - Removing the wrong library, or replace the wrong one by the good one > - Use LD_LIBRARY_PATH with the path to the right library. It gets > priority over os abi tag. > LD_LIBRARY_PATH is highly error-prone, and it affects build time, too. I would prefer to ignore this variable unless there is really really really no other option. Removing the "wrong" library is not possible without either loosing a lot of packages from the dependency chain of package A, or loosing the enhanced functionality of package B. Are there other options? Is the os abi tag broken beyond repair? Any helpful comment would be highly appreciated. Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk32+gQACgkQUTlbRTxpHjc5mACgiKt61f5JG5GQJb47iC/CtfWr cbwAn39llhtcn6W+aXga+WjuMdIIOXM0 =vNxc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df6fa08.7050...@afaics.de
Bug#584914: backport from wheezy?
AFAICS the problem doesn't exist for Wheezy (correct me if I am wrong), so I wonder if it would be possible to backport the fix to Squeeze? Regards Harri -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1aae46.4000...@aixigo.de
Bug#584914: security issue?
PS: If -@netgroup doesn't work as expected, doesn't this mean that a user might be granted _more_ group permissions than configured? Wouldn't this mean that this problem is a security issue? Regards Harri -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1be638.3080...@aixigo.de
Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: libc-bin Version: 2.10.2-6 I would like to override the "standard" libGL.so files by a "private" library installed in a special directory. Problem: It seems that the libraries in in /lib and /usr/lib have a higher priority than any other directory. This is a severe restriction. Looking at ld.so(8) I had the impression that /lib and /usr/lib are supposed to provide a _default_ set of libraries to be overridden by ld.so.conf and $LD_LIBRARY_PATH as needed; : : The necessary shared libraries needed by the program are searched for in the following order o Using the environment variable LD_LIBRARY_PATH (LD_AOUT_LIBRARY_PATH for a.out programs). Except if the executable is a setuid/setgid binary, in which case it is ignored. o From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path. o In the default path /lib, and then /usr/lib. : : Here is my setup: % cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf % cat /etc/ld.so.conf.d/*.conf /usr/lib/nvidia-current /usr/lib32/nvidia-current # libc default configuration /usr/local/lib # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu AFAICS this is Debian's default, except for the nvidia libs. Please note that there is neither /usr/lib nor /lib included in this list. ldd and strace show that the library is taken from the wrong directory. Sample session: % cat #include > int main () { glBegin(GL_POINTS); return 0; } > EOF % g++ /tmp/conftest.cpp -I/usr/include/nvidia-current -L/usr/lib/nvidia-current -lGL -o /tmp/conftest % ldd /tmp/conftest linux-vdso.so.1 => (0x7fff217ff000) libGL.so.1 => /usr/lib/libGL.so.1 (0x7f4673b5f000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f467384b000) : : % % file -L /usr/lib/libGL.so.1 /usr/lib/nvidia-current/libGL.so.1 /usr/lib/libGL.so.1:ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, for GNU/Linux 2.4.20, stripped /usr/lib/nvidia-current/libGL.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuTvM0ACgkQUTlbRTxpHjfWbwCcD4pDDI6BwI3v1mAz01AIAe1m ZBcAn34Pw3/iSKtsskC8duMc1XNRtCcK =B/XD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b93bccd.7070...@darkharri.de
Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Of course I ran ldconfig (as root). # ldconfig -p | grep libGL.so.1 libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so.1 libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so.1 libGL.so.1 (libc6) => /usr/lib32/nvidia-current/libGL.so.1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkubrokACgkQUTlbRTxpHjdmJgCfQpFJQUsutRDCcoM/oJ+HUetU wUMAnAvleqTDyJk5Gxr6E7vZNIU82Jjl =Fs9F -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9bae91.8000...@darkharri.de
Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PS: I found this thread: http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg11607.html AFAICS the issue is still unresolved. What would be your suggestion? Is there some configure option to tell ldconfig or ld.so to ignore the OS ABI tags? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkubs6IACgkQUTlbRTxpHjcg3QCdE6Z1yPdAsRdLOZGQILp1YrRm v5gAniB5MoNTSuiV9fOfux9JWw7q3zOB =FV47 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9bb3a2.4070...@darkharri.de
Bug#572895: resolved?
AFAICS the mesa folks don't rely upon the os abi tag anymore: https://bugs.freedesktop.org/show_bug.cgi?id=26663 Regards Harri -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e25075.4070...@afaics.de
Bug#717629: please document LANG and LC_ALL in locale(1)
Package: locales Version: 2.13-38 Seems that LANG and LC_ALL have been lost in locale(1). It would be nice if they could be added. http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html Many thanx Harri -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ee2dbd.1040...@aixigo.de
Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sorry to say, but I doubt that it is reasonable to set a bug to "wishlist", just because the OS ABI tag issue is complex. This does not help. My suggestion is to keep things simple. Since mesa doesn't need it anymore, are there any other packages in x86/amd64 that cannot follow the documented priority scheme as described in ld.so(8) and therefore require the OS ABI tag? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBCAAGBQJSOVfCAAoJEAqeKp5m04HLJXIH/03CahavsyYy/VhIPmZaPjaG B2kPnyye21ettV6BJjpAL6IBcoiP77pUEB2SyekQW2fcHh4gRhn/P56tEOKJuKEA /aH3OtsvDt6uXxCLgrkAsAZwNkXKQMoqUi6pmHgBiiyBLFUcsn8Iy3xGOSv4tZ4c c4tPL+IgCKlIWkqpsSjdq46VM52Km1qr/+4rXjMTyREgkNH0HXoXsvyYWVyUuDEg i41t8i2NJetlR+d1xvGIRBo3PiYalgEWAWMW8QFDjPhX/rHadIGhRjavxxhk5RuS mOb6Z+er8tMAsvIJbD95TWldJNYj/9zHtLj3FryyuCT/f9H3bcyt9ae4HZV0yD0= =FUAS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523957ca.4010...@afaics.de
Bug#743866: getaddrinfo(3) failure for zeroconf (avahi)
Package: libc6 Version: 2.18-4 Sometimes avahi-resolve-host-name and getaddrinfo(3) disagree about DNS. Sample: % avahi-resolve-host-name pepe.local; ./getaddrinfo pepe.local pepe.local 10.42.100.198 getaddrinfo: Name or service not known nscd is not running. /etc/nsswitch.conf says hosts: files mdns4_minimal [NOTFOUND=return] dns getaddrinfo.c is attached. Regards Harri /* * getaddrinfo.c - Simple example of using getaddrinfo(3) function. * * Michal Ludvig (c) 2002, 2003 * http://www.logix.cz/michal/devel/ * * License: public domain. */ #include #include #include #include #include #include #include int lookup_host (const char *host) { struct addrinfo hints, *res; int errcode; char addrstr[100]; void *ptr; memset (&hints, 0, sizeof (hints)); hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_STREAM; hints.ai_flags |= AI_CANONNAME; errcode = getaddrinfo (host, NULL, &hints, &res); if (errcode != 0) { fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(errcode)); exit(EXIT_FAILURE); } printf ("Host: %s\n", host); while (res) { inet_ntop (res->ai_family, res->ai_addr->sa_data, addrstr, 100); switch (res->ai_family) { case AF_INET: ptr = &((struct sockaddr_in *) res->ai_addr)->sin_addr; break; case AF_INET6: ptr = &((struct sockaddr_in6 *) res->ai_addr)->sin6_addr; break; } inet_ntop (res->ai_family, ptr, addrstr, 100); printf ("IPv%d address: %s (%s)\n", res->ai_family == PF_INET6 ? 6 : 4, addrstr, res->ai_canonname); res = res->ai_next; } return 0; } int main (int argc, char *argv[]) { if (argc < 2) exit (1); return lookup_host (argv[1]); } signature.asc Description: OpenPGP digital signature
Bug#998438: invalidate caches on package removal
Package: nscd Version: 2.31-13+deb11u2 The nscd.prerm script should cleanup the caches nscd -i {group,hosts,netgroup,passwd,services} rm -f /var/cache/nscd/{group,hosts,netgroup,passwd,services} to invalidate and remove all caches, before the service is stopped and removed. The nscd -i is necessary to tell running processes about the change. They might keep these cache files open with a local file descriptor, even if they are erased. You might want to consider to move /var/cache/nscd to /run. Regards Harri
Bug#998438: Acknowledgement (invalidate caches on package removal)
Control: tag -moreinfo The caches have to be invalidated before nscd is removed, because after removing nscd (the binary) you cannot run "nscd -i" anymore. The cache files have to be removed to make sure that new jobs ignore the caches completely. A general problem with nscd is that running jobs continue to use the caches, even though nscd is gone. Sample: # lsof | grep nscd | wc -l 474 # systemctl stop nscd # lsof | grep nscd | wc -l 56 See that its not even close to 0? Obviously some jobs didn't recognize that nscd has been stopped. Running nscd -i and removing the caches is all the nscd maintainer script could do. About /run: /var/cache/nscd is appr 1MByte on the hosts I checked. This is the perfect size to store it RAM. The caches are mapped into memory, anyway. Please check the output of lsof | grep nscd It says "mem" in the FD column. There is no reason to store the caches on SSD or rusty disks. Regards Harri
Bug#965323: postinst script deletes custom locales
How can I get out of this? What do you suggest? Are the tools to create custom locales included in the Debian package by accident? Harri
Bug#1080318: postinst fails if /etc/locatime exists
Package: tzdata Version: 2024a-4 At the upgrade from Bookworm to Trixie the postinst for tzdata failed: Setting up tzdata (2024a-4) ... dpkg: error processing package tzdata (--configure): installed tzdata package post-installation script subprocess returned error exit status 10 /etc/localtime was # ls -al /etc/localtime lrwxrwxrwx 1 root root 23 Jul 7 10:09 /etc/localtime -> /usr/share/zoneinfo/CET Restarting the upgrade did not help. After manually removing the symlink the upgrade succeeded. Regards Harri
Bug#895981: please cleanup /var/cache/nscd on restart
Package: nscd Version: 2.24-11+deb9u3 If I change nscd.conf (to adjust some ttl or to disable some cache) and restart the service, then the cache files in /var/cache/nscd are not adjusted accordingly, AFIACS. In worst case the passwd cache is kept forever and never adjusted, even though it has been disabled in nscd.conf. nscd's caches should be deleted or recreated at service start or restart, as applicable. Regards Harri
Bug#895981: please cleanup /var/cache/nscd on restart
Hi Aurelien, I am using both systemd and sysvinit-core, but I am not sure which one was active when I ran into this problem. Consider a split DNS setup for a remote network. I had started an IPsec connection to the remote side. /etc/resolv.conf was changed to include the new internal DNServer on the remote side, but a host lookup gave me still the old external address. Stopping nscd did not help, AFAIR. See also #895977 (resolvconf). Regards Harri
Bug#895981: please cleanup /var/cache/nscd on restart
Not sure if it matters, but if resolvconf is active, then /etc/resolv.conf is a symbolic link. Regards Harri
Bug#895981: please cleanup /var/cache/nscd on restart
Any news on this? Did you report this bug upstream? Here is a sample session showing the effect: # ping lxc01 PING lxc01.example.de (172.16.99.198) 56(84) bytes of data. From dpcl082.example.de (172.16.97.128) icmp_seq=1 Destination Host Unreachable From dpcl082.example.de (172.16.97.128) icmp_seq=2 Destination Host Unreachable From dpcl082.example.de (172.16.97.128) icmp_seq=3 Destination Host Unreachable ^C --- lxc01.example.de ping statistics --- 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms pipe 4 # service nscd stop # ping lxc01 PING lxc01.example.de (172.16.99.28) 56(84) bytes of data. 64 bytes from lxc01.example.de (172.16.99.28): icmp_seq=1 ttl=64 time=0.362 ms 64 bytes from lxc01.example.de (172.16.99.28): icmp_seq=2 ttl=64 time=0.396 ms ^C --- lxc01.example.de ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.362/0.379/0.396/0.017 ms # service nscd start # ping lxc01 PING lxc01.example.de (172.16.99.198) 56(84) bytes of data. From dpcl082.example.de (172.16.97.128) icmp_seq=1 Destination Host Unreachable From dpcl082.example.de (172.16.97.128) icmp_seq=2 Destination Host Unreachable From dpcl082.example.de (172.16.97.128) icmp_seq=3 Destination Host Unreachable ^C --- lxc01.example.de ping statistics --- 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms pipe 4 See how the old IP address pops up again, as soon as nscd is active? Obviously "service nscd stop" did not flush the cache. Regards Harri -- aixigo AG, Karl-Friedrich-Strasse 68, 52072 Aachen, Germany phone: +49 241 559709-79, fax: +49 241 559709-99 eMail: harald.dun...@aixigo.de, web: http://www.aixigo.de Amtsgericht Aachen - HRB 8057, Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein, Vors. des Aufsichtsrates: Prof. Dr. Ruediger von Nitzsch
Bug#921913: locales: character map file `C' not found: No such file or directory
Metoo. Hopefully this is not too difficult to fix before Buster? Regards Harri
Bug#952516: please support LC_CTYPE=UTF-8
Package: locales Version: 2.29-10 Severity: wishlist Apparently MacOS 10.15 uses "UTF-8" instead of "C.UTF-8". This affects ssh terminal sessions from MacOS to Debian, e.g. # apt upgrade : : Processing triggers for mime-support (3.64) ... Processing triggers for libc-bin (2.29-10) ... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "UTF-8", LC_COLLATE = "C", LANG = "C" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "UTF-8", LC_COLLATE = "C", LANG = "C" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). The workaround is to run localedef -i C -f UTF-8 UTF-8 on Debian, but probably others are affected by this problem as well. A central solution would be reasonable. Do you think it would be possible to introduce "UTF-8" as an alias for "C.UTF-8"? Regards Harri
Bug#965323: postinst script deletes custom locales
Package: locales Version: 2.28-10 To support MacOS terminal I have to define "UTF-8" using localedef (see #952516). Problem is, custom locales are wiped out by the postinst script. Sample: # locale -a C C.UTF-8 POSIX # localedef -i C -f UTF-8 UTF-8 # locale -a C C.UTF-8 POSIX UTF-8 UTF-8.utf8 # apt reinstall locales : : # locale -a C C.UTF-8 POSIX See UTF-8 is gone? Shouldn't happen. Same for locales 2.31-1. Harri
Bug#952516: please support LC_CTYPE=UTF-8
Not yet. Do you have some Posix document, RFC, best practice guideline, etc showing that it should be "C.UTF-8" instead of "UTF-8"? Something to present to Apple proving that they are not Posix compliant? https://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html says "The contents of this string are implementation-defined." I could live with having to run localedef once to define a locale UTF-8 at installation time, but that is wiped out again and again, see #965323. What would you suggest? Regards Harri
Bug#965323: postinst script deletes custom locales
Can't be worse than not having the locale at all. Not to mention that there is an option --posix to assure compatibility to POSIX.1-2008, AFAICT. If there are incompatible changes, then its my job to worry about recreating the custom locales. Since the postinst builds just a subset of all locales and since it even maintains a list about it, I would suggest to erase and rebuild only these locales. Thanx very much Harri
Re: Bug#965323: postinst script deletes custom locales
On 7/29/20 12:35 PM, Aurelien Jarno wrote: On 2020-07-27 08:26, Harald Dunkel wrote: Since the postinst builds just a subset of all locales and since it even maintains a list about it, I would suggest to erase and rebuild only these locales. This is not so easy as the list evolve from version to version. I don't get this. The custom locales are not included in your lists, so how comes they are affected by these internal changes? What would you suggest me to do to make sure the files I created using the API provided by your package are not deleted again on the next opportunity?
Bug#166914: glibc 2.1 binary says: __strtoul_internal not defined in file libpthread.so.0
Hi Goto, The problem is ages old. In the meantime we have migrated our build environment from RH6.2 to 7.2, and the problem became irrelevant for us. From my point of view its OK to close this bug report. But there are still incompatibilities between glibc 2.2.4 of RH7.2 and glibc 2.3.1-14. Our major GUI (built on RH7.2) does a reproducable core dump when I run it on Sid. Are you interested in another bug report? Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218408: libc6 2.3.2.ds1-8 breaks NVidia's driver
Package: libc6 Version: 2.3.2.ds1-8 Hi folks, After upgrading glibc in Sid to version 2.3.2.ds1-8 the NVidia driver for XFree86 did not work anymore. Instead of the usual splash screen I got a white screen with just a few horizontal lines, then the screen was frozen. Downgrading glibc back to version 2.3.2-9 made the problem disappear. Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#57195: bugfix for libc6 2.1.2-13, /etc/init.d/devpts.sh
Package: libc6 Version: 2.1.2-13 Small typo in /etc/init.d/devpts.sh. Patch: # diff -c /etc/init.d/devpts.sh~ /etc/init.d/devpts.sh *** /etc/init.d/devpts.sh~ Sat Jan 29 05:39:14 2000 --- /etc/init.d/devpts.sh Sun Feb 6 20:07:50 2000 *** *** 13,19 make_devpts() { [ -d /dev/pts ] || mkdir --mode=755 /dev/pts ! { mount_devpts_fs() { --- 13,19 make_devpts() { [ -d /dev/pts ] || mkdir --mode=755 /dev/pts ! } mount_devpts_fs() { Regards Harri
Bug#166914: glibc 2.1 binary says: __strtoul_internal not defined in file libpthread.so.0
Package: libc6 Version: 2.3.1-3 Hi folks, I've got this error message at runtime, using glibc 2.3.1-3: myexec: relocation error: myexec: symbol __strtoul_internal, version GLIBC_2.0 \ not defined in file libpthread.so.0 with link time reference FATAL: Exec 'myexec' failed: status = 127 Some shared libraries used by myexec were built on RedHat 6.2. The rest was compiled and linked on Sid using gcc 2.95.2. No error messages at build time. Regards Harri
Bug#166914: glibc 2.1 binary says: __strtoul_internal not defined in file libpthread.so.0
Package: libc6 Version: 2.3.1-3 Hi folks, I've got this error message at runtime, using glibc 2.3.1-3: myexec: relocation error: myexec: symbol __strtoul_internal, version GLIBC_2.0 \ not defined in file libpthread.so.0 with link time reference FATAL: Exec 'myexec' failed: status = 127 Some shared libraries used by myexec were built on RedHat 6.2. The rest was compiled and linked on Sid using gcc 2.95.2. No error messages at build time. Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glibc 2.3.3 not in?
Hi folks, I am just curious: Why isn't glibc 2.3.3 in Debian? Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267594: libc6 depends on bash
Package: libc6 Version: 2.3.2.ds1-16.0.0.1.amd64 Hi folks, libc6 depends on bash (see /var/lib/dpkg/info/libc6.preinst), but doesn't list it in the Depends list. Would it be possible to fix the package header? Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267594: libc6 depends on bash
PS.: Maybe you could consider to use /bin/sh instead? This would make it easier to setup a minimum system based upon dash or ash, for example. Most packages use /bin/sh for their dpkg scripts, as it seems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267594: libc6 depends on bash
GOTO Masanori wrote: Bash is required package, so minimum base system should have bash. If you don't use such debian base system, then libc6.postinst becomes meaningless because you don't use the normal debian system. I do not understand why you refuse to add this dependency to the control file. libc6 is a required package too (much more "required" than bash), but still it is listed in all affected headers, AFAICS. Just by chance I stumbled over this. If you think that the dependency should not be listed in control, then feel free to close this report. Thanx anyway Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267594: libc6 depends on bash
GOTO Masanori wrote: BTW, even we use /bin/bash, do we have reason to use /bin/sh? If so, why? bash is included in the base system. We use various tools for postinst/preinst, because those tools are also in the bootstrapping base system. Most of the other packages don't work without libc6, including bash. If libc6 depends upon a complex shell like bash, then the chain of dependencies gets even longer. Its a higher risk. IMHO libc6 should not depend upon other packages at all. If there is no way around this, then it should work with any /bin/sh, not just bash. Just my $0.02. Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267594: libc6 depends on bash
GOTO Masanori wrote: My point is: "installing debian package needs the debian base system that includes bash". Moreover it's not only glibc package issue. If you have plan to support all base packages with /bin/sh, and that makes easier installation for bootstrapping, I don't complain it. If not, I dislike to get tool/shell limitation for postinst/preinst from the point of maintainance view. The debian base system won't work without libc6. There is no alternative. But it is surely possible to imagine a debian base system without bash. I guess you're talking about bootstrapping (actually you didn't show your purpose). Package dependencies are complex, and it's not only glibc issue. Why don't you use debootstrap and so on? Its not just at bootstrap time. I also thought about a firewall where each new program is an additional risk. Or about an embedded system where memory consumption is still a problem. Or about a tiny ogg player that simply has no need for an interactive shell. If we can reduce the number of dependencies between the packages where possible, then Debian becomes more modular. Imagine a Lego box with most of the basic parts glued together. Nobody would like to play with it. Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]