Bug#1068737: locales fails to install: locales failed to preconfigure, with exit status 2
Package: locales Version: 2.37-16 Severity: grave A fresh `debootstrap unstable' chroot plus `apt install locales`: Preconfiguring packages ... locales failed to preconfigure, with exit status 2 dpkg: error processing package locales (--configure): installed locales package post-installation script subprocess returned error exit status 2 Errors were encountered while processing: locales This is coming from this line in locales.config: DEFAULT_ENVIRONMENT="$(sed -En -e '/^LANG="?([^"]+)"?/h; g; $s//\1/p' /etc/default/locale /etc/locale.conf 2>/dev/null)" /etc/locale.conf does not exist (and it doesn't exist on my regular system too), so sed fails with "can't read: No such file or directory" error message (which is sent to /dev/null), and since whole script is run under `set -e', it exits here. This is caused by "debian/debhelper.in/locales.config: Extract default environment LANG using only sed" change in 2.37-16. Do we really need /etc/locale.conf at this time? I think it's unused for a very long time. Also see EE= assignment at the very beginning of this script.
Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system
Control: title -1 nscd caches "wrong" name for accounts with the same uid Control: found -1 2.37-15 Rehashing this 17-years old bug which biten me today quite hard. On Mon, 12 Feb 2007 22:55:28 -0500 Yaroslav Halchenko wrote: Today, after unsucsessful attempt to login as sashroot, I've got somewhat broken system -- all processes running under uid=0 were reported belonging to sashroot. Due to lack of knowledge of nss internals I inquired on -devel mailing list and it seems that multiple accounts sharing uid=0 might be considered a bad practice. For more details see http://lists.debian.org/debian-devel/2007/02/msg00323.html thread. If you can prove that it is 'documented feature of nss' to resolve in some deterministic way a uid whenever multiple ones are possible, then probably this bug has to be reassigned against libc6 to which libnss_files belongs. Since this bug might drive whole system broken, I am assigning it important priority, since a big proportion of sash users probably use sashroot account feature. The problem here is that nscd caches both username and uid on each lookup, instead of caching just the lookup which has been asked, and doing the other lookup the normal way as would be done by getpwnam/getpwuid (and similar for getgrnam/getgrgid etc). For very long time we relied on multiple special accounts having the same uid, exactly like this very sashroot case. We had this for a few system/special accounts. Each name has its own password and/or ssh keys (when in use), and each does start/manage its subsystem with the right permissions. Now, with normal getpwuid(), it will return the first entry with the given uid. But in case of nscd, it returns last looked up entry with this uid instead. Eg, we have root and r_mjt, - when I run getpwnam(root), getpwuid(0) will return the same entry. But once I looked up getpwname(r_mjt), getpwuid(0) will return r_mjt instead of root from now on. Here's another incarnation of the very same theme: https://run.tournament.org.il/multiple-users-with-the-same-uid-gid/ I guess they use oracle rdbms, and for this one it is also very helpful to have 2-3 accounts with the same uid, for managing purposes. And it breaks badly with nscd too. Why this bug is marked 'wontfix'? Thanks, /mjt
Bug#1056739: -static-pie fails on i386
Package: libc6-dev Version: 2.37-12 Severity: normal X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org When building a statically-linked application with -static-pie flag (which is not supported on every platform), on i386 where it seems to be supported (at least -static-pie flag is accepted), the link fails like this: /usr/bin/ld: /usr/lib/gcc/i686-linux-gnu/13/../../../i386-linux-gnu/libc.a(memset_chk-nonshared.o): unsupported non-PIC call to IFUNC `memset' /usr/bin/ld: failed to set dynamic section sizes: bad value This can be observed, for example, here: https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=i386&ver=1%3A8.2.0%7Erc1%2Bds-1&stamp=1700774780&raw=0 There are some architectures where -static-pie build is supported and works (eg amd64, arm64, s390x), where it is not supported at all (most other architectures), and where it is supported but does not work, and this is i386, - this is what this bug is about. I guess it needs to be either rejected entirely as unsupported, or to be working. Does it make sense to enable pic build of glibc on i386 architecture? Right now I'm not sure what to do with qemu which is FTBFS on i386 due to this. Thanks, /mjt
Bug#1001156: qemu-arm needs some help with finding libs
05.12.2021 19:33, Michael Tokarev wrote: ... libc64:armhf libc6:armhf ofcourse. Something's wrong with my typing today :) Thanks, /mjt
Bug#757941: Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
13.11.2014 00:03, Michael Tokarev пишет: > 12.11.2014 22:45, Aurelien Jarno wrote: >> On Wed, Nov 12, 2014 at 09:17:20PM +0400, Michael Tokarev wrote: >>> Should I list them all in the build-deps? If yes, what's the complete list? > >> It should be libc6-dev[linux-any !alpha !ia64] | libc6.1-dev [alpha ia64] | >> libc0.1-dev (>> 2.19-12~) [kfreebsd-any] | libc0.3 (2.19-12~) [hurd-any] > > Please double-check: > > Build-Depends: > # glibc static-nss #754813, 2.19..2.19-11, -12 is ok > libc6-dev (>> 2.19-12~) [linux-any !alpha !ia64] | > libc6-dev (<< 2.19) [linux-any !alpha !ia64] | This does not work. conflicting-negation-in-source-relation build-depends: libc6-dev (>> 2.19-12~) [linux-any !alpha !ia64] It looks like the arch strings in []s must either be all positive or all negative, but not a mix. So this becomes insane. I'll just add a build-time check for it. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5463d95c.4000...@msgid.tls.msk.ru
Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
12.11.2014 22:45, Aurelien Jarno wrote: > On Wed, Nov 12, 2014 at 09:17:20PM +0400, Michael Tokarev wrote: >> Should I list them all in the build-deps? If yes, what's the complete list? > It should be libc6-dev[linux-any !alpha !ia64] | libc6.1-dev [alpha ia64] | > libc0.1-dev (>> 2.19-12~) [kfreebsd-any] | libc0.3 (2.19-12~) [hurd-any] Please double-check: Build-Depends: # glibc static-nss #754813, 2.19..2.19-11, -12 is ok libc6-dev (>> 2.19-12~) [linux-any !alpha !ia64] | libc6-dev (<< 2.19) [linux-any !alpha !ia64] | libc6.1-dev (>> 2.19-12~) [alpha ia64] | libc6.1-dev (<< 2.19) [alpha ia64] | libc0.1-dev (>> 2.19-12~) [kfreebsd-any] | libc0.1-dev (<< 2.19) [kfreebsd-any] | libc0.3-dev (>> 2.19-12~) [hurd-any] | libc0.3-dev (<< 2.19) [hurd-any], Since this is all alternatives, is it really necessary to list the [arch] names? I mean, just list of pkgs with versions should be enough I think, each arch will pick the right name, no? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5463cb2b.9050...@msgid.tls.msk.ru
Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
12.11.2014 21:05, Aurelien Jarno wrote: [] >> And there's nothing I can do about this on busybox side -- except, >> again, adding a versioned build-dep. > > I'll schedule binNMUs for now, but it might be a good idea to add a > versioned build-dep so that it doesn't happen again. Please don't. I want to fix it for real today, one way or another. And this brings an interesting question: how to add this build-dep? I tried adding build-depends: libc-bin (>>2.19-12~) | libc-bin (<<2.19) but this one just pulls the libc-bin package not libc6 and libc6-dev. Ofcourse I thouht about using libc6[-dev] in this context, but immediately come across the fact that on different arches, libc is named differently (libc6.1, libc0.3 etc). Should I list them all in the build-deps? If yes, what's the complete list? (I tried to keep it buildable on older glibc too; but it's ofcourse possible to add a build-conflicts: libc6 (<<2.19-12), libc6.1 (<<2.19-12) etc -- this is easier than listing two versions for each) Another thought is to add a build-time test that the thing actually work (eg, busybox-static ping localhost or something, or a small separate program to be run before real build) -- with this in mind, it might not be even required to add a build-dep, -- build will just fail with a friendly message telling to fix glibc... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54639620.5000...@msgid.tls.msk.ru
Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
BTW, the bug is _not_ fixed by -12 upload where I added a build-dep on libc-bin. /mjt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546396a3.1000...@msgid.tls.msk.ru
Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
12.11.2014 04:27, Diederik de Haas wrote: > Package: busybox-static > Version: 1:1.22.0-11 > Severity: important > > This is basically the same error as with bug #757941, but it was > reassigned to glibc and fixed there. As Aurelien Jarno correctly stated > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757941#120 > it was indeed fixed with version 1.22.0-9+b1, which I have verified. > > However, I just received version 1.22.0-11 of busybox-static and now it > fails again: Now this is funny. Should I add a versioned build-dependency against libc6-dev perhaps? Because, according to the build log of amd64 (that's your arch), the package has been built against glibc (= 2.19-11) -- grep for Built-Using in the build log: https://buildd.debian.org/status/fetch.php?pkg=busybox&arch=amd64&ver=1%3A1.22.0-11&stamp=1415729242 now I wonder how the -9+b1 version has been built against fixed glibc-2.19-12 while at least one of amd64 buildds have -11 ? And there's nothing I can do about this on busybox side -- except, again, adding a versioned build-dep. Aurelien? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5463120f.6030...@msgid.tls.msk.ru
Bug#765718: please provide tzdata for new DST rules in Russia 2014 for wheezy
Package: tzdata Version: 2014e-0wheezy1 Severity: important Tags: wheezy In 2014, Russia is returning daylight saving time rules back. At 26 Oct, 2014, Russia will switch time to winter time (MSD=>MSK). tzdata package in jessie already has the right rules applied. But wheezy package does not have the necessary rules appended. Please consider updating tzdata package in wheezy, BEFORE the switch in Russia. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017132459.28759.52824.reportbug@gandalf.local
Bug#757941: static linking: alternatives for glibc?
07.10.2014 08:34, Steve Langasek wrote: [] >>> Was the removal of gethostby* APIs from the static glibc intentional? > >> Yes. It's the nsswitch problem. The behavior of those APIs is controlled >> by the nsswitch mechanism (specifically the hosts configuration), which is >> inherently dynamic and doesn't support static linking. > > It nevertheless is expected to work when the corresponding NSS modules are > present. It's not truly static, but the dynamic loading from static libc is > supported. When a statically linked app calls getaddrinfo() (it is getnameinfo not gethostbyname), the call immediately returns "host not found, try again", without any attempt to load anything or look for other files. This is with jessie glibc. With wheezy's glibc it worked when the right nss modules are presnt (iirc anyway -- I know it worked, I didn't check _how_ it worked). > So bug #757941 should be reassigned to glibc, instead of claiming that this > is somehow expected glibc behavior. > >>> Perhaps glibc upstream would be willing to restore them? > >> It would be nice, but I doubt you'll make much progress. Lots of people >> have complained about this over the years. > > At issue here is a glibc regression, not the standard complaints about > static glibc being not truly static. Regression or not, but there are several other problems here. First of all, glibc wasn't really intended to be used for static linking -- apps becomes huge in size and if it still tries to load nss modules or other things, it means static isn't really static, it wont work that well if your system is damaged (rescue purposes of busybox-static). Other libcs exists which are intended to be used statically from the ground up (uclibc, dietlibc, musl) and which works well in this context and provides more than enough to be really useful and small. That's exactly why I used the subject I used: because I want to find a good alternative to glibc, alternative which is intended for such use case. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543380ec.1070...@msgid.tls.msk.ru
Bug#600310: reassigning to cron
reassign 600310 cron retitle 600310 cron uses regexps that return wrong results depending on locale severity 600310 serious thanks Ok, as stated in two previous emails, it's problem in cron, not in glibc/locales. Sadly, but... ;) And the severity isn't critical but serious (makes cron to not process some crontabs unexpectedly). Fortunately, another program mentioned in this bugreport, run-parts, does not call setlocale() so is not affected. As to the solution, I'd say we should either reset LC_COLLATE, or retrieve default charset using some other, less intrusive, way, or use comparisons like (c>='a' && c<='z') (or isalnum), instead of using regexps with classes. Thanks. /mjt -- 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/4cb97c94.6040...@msgid.tls.msk.ru
Bug#600310: wrong collation(?) order for et_EE.UTF-8 causes regexps to fail matching randomly
Ok, after discussing on #debian-devel and some more thinking, even if it's 02:23 here already... I now see the problem isn't in locales package actually, and it should affect other locales too. The prob is that people used to use [a-z] to mean all 26 latin chars, while various locales have them in different order, like this Estonian case: http://en.wikipedia.org/wiki/Estonian_alphabet For now, there are 2 important problem cases: it's cron and run-parts. Both are using [a-z]-like regexps to filter out "invalid" filenames. In cron this comes with this context: + /* Get the default locale character set for the mail +* "Content-Type: ...; charset=" header +*/ + setlocale(LC_ALL,""); /* set locale to system defaults or to +that specified by any LC_* env vars */ + /* Except that "US-ASCII" is preferred to "ANSI_x3.4-1968" in MIME, +* even though "ANSI_x3.4-1968" is the official charset name. */ + if ( ( cs = nl_langinfo( CODESET ) ) != 0L && + strcmp(cs, "ANSI_x3.4-1968") != 0 ) + strncpy( cron_default_mail_charset, cs, MAX_ENVSTR ); + else + strcpy( cron_default_mail_charset, "US-ASCII" ); + so it's basically used only to get "proper" charset name in email notifications, but setlocale() comes not only with charset name, but with collation sequence and other things. Note both cron and run-parts cases are RC-critical too and should be fixed -- it's just that this is not bug in locales anymore. And it's too late already for me to think more ;) Thanks! /mjt -- 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/4cb8d5d0.1000...@msgid.tls.msk.ru
Bug#600310: wrong collation(?) order for et_EE.UTF-8 causes regexps to fail matching randomly
Package: locales Version: 2.11.2-6 Severity: critical Tags: l10n There's a bug in et_EE.UTF-8 locale definition causing some latin chars to be treated as non-letters. These are at least in range t..y inclusive, i.e. [t-y]. Like this: $ echo $LANG et_EE.UTF-8 $ echo s | grep '[a-z]' s $ echo t | grep '[a-z]' $ _ I.e., the latin letter "t" does not match [a-z] regexp. This is a critical issue unfortunately, because it makes various regex failing to match, breaking random components. In the actual problem case the issue were that many cron jobs were not running on the system for a mysterious reason, and the problem was because cron uses a regexp to filter invalid cronjob names, which is /^[a-zA-Z0-9_-]+$/. Thanks. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.35-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy ii libc6 [glibc-2.11-1] 2.11.2-6 Embedded GNU C Library: Shared lib locales recommends no packages. locales suggests no packages. -- debconf information: * locales/default_environment_locale: ru_RU.UTF-8 * locales/locales_to_be_generated: en_US.UTF-8 UTF-8, ru_RU.KOI8-R KOI8-R, ru_RU.UTF-8 UTF-8 -- 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/20101015214742.17728.79430.report...@gandalf.local
Bug#595724: typo in /etc/locale.gen header file
Package: locales Version: 2.11.2-2 Severity: minor The file /etc/locale.gen starts with the following comment block: # This file lists locales that you wish to have built. You can find a list # of valid supported locales at /usr/share/i18n/SUPPORTED, and you can add # user defined locales to /usr/locale/share/i18n/SUPPORTED. If you change # this file, you need to rerun locale-gen. Note it names /usr/LOCALE/share/i18n, not /usr/LOCAL/share/i18n/. This is a typo, should be really trivial to fix... Thanks! -- 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/20100906050410.29918.29622.report...@gandalf.local
Bug#459643: It's Debian-specific, after all
$subj. debian/patches/any/submitted-fileops-and-signals.diff in glibc package. See #429021 for details. The change was made for 2.6-1, at 07 Jul 2007. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459643: fflush() with WRITE ERROR it really is
While trying to save space in Subject line, I created an unclear bugreport. The change in fflush() was with write error only. Under normal conditions, fflush() writes pending data just fine AND clears the write buffer. But in case write(2) errors out, fflush() now does nothing, while in pre-2.7 glibc it cleared the write buffer. Please excuse me for possible confusion. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459643: fflush() change wrt pending write in glibc causes others to break
Package: glibc Version: 2.7-5 Severity: important Since 2.7, glibc changed behavour of fflush() wrt pending write in the FILE* buffer. Before, the pending write data was cleared on fflush(), now it's keept in the buffer. As a result, we see some.. interesting stuff, like this: $ echo foo > /dev/full bash: echo: write error: No space left on device $ echo bar foo bar $ _ Note the 2nd echo prints BOTH foo and bar. Here, echo(1) is built-in to bash, and bash just switches filedescriptor #1 behind the scenes of stdio when doing redirects. It correctly calls fflush() (which reports error on first echo) and clearerror(), but neither of them now clears the pending write, and the data remains in the buffer attached to stdout FILE* structure. The same behavour is reported for zsh, too, which seems to do similar behind-the-scenes trick when doing redirections. As far as I can see, this is a grey area in C standard - whenever the pending write should be cleared and when. More, I see no stdio function to force clearing the pding write - at least not a standard one. So the bug seems to be in bash (and in zsh) - (ab)users of fflush(), but I'm filing bugreport against glibc as the change lies here, and it's more generic. I see several possible portable, "white" way to do it all cleanly: o issue freopen() on each redirection (which is tricky too, because freopen() does not accept a file descriptor) o use separate FILE stream instead of stdout (requires many changes in bash and other places) o don't use stdio at all And finally, to revert glibc to do the same as was done before 2.7. What exactly to do is a.. good question. Oh well. /mjt -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23-i686smp Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages bash depends on: ii libc6 2.7-5 GNU C Library: Shared libraries ii bash 3.1dfsg-8 The GNU Bourne Again SHell -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
