Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address
Package: src:linux Version: 6.0.8-1 Tags: security Control: affects -1 + libc6 32-bit mmap() puts large (>= 2 MiB) files at the same address every time: $ i686-linux-gnu-gcc -static test-mmap.c -o test-mmap $ head -c $((2 * 1024 * 1024)) /dev/zero > zeros $ for i in 1 2 3; do ./test-mmap < zeros; done mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7c0 mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7c0 mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7c0 In contrast, for smaller files, there's a few bits of entropy in the address: $ head -c $((2 * 1024 * 1024 - 4096)) /dev/zero > zeros $ for i in 1 2 3; do ./test-mmap < zeros; done mmap(NULL, 2093056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d4a000 mmap(NULL, 2093056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7db8000 mmap(NULL, 2093056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d99000 This weakens ASLR for most(?) programs, because libc.so.6 has recently become slightly larger than 2 MiB: $ wc -c /lib/i386-linux-gnu/libc.so.6 2225200 /lib/i386-linux-gnu/libc.so.6 $ for i in 1 2 3; do cat /proc/self/maps | grep ' r-xp .*/libc'; done f7c22000-f7d9b000 r-xp 00022000 fd:00 12059068 /lib/i386-linux-gnu/libc.so.6 f7c22000-f7d9b000 r-xp 00022000 fd:00 12059068 /lib/i386-linux-gnu/libc.so.6 f7c22000-f7d9b000 r-xp 00022000 fd:00 12059068 /lib/i386-linux-gnu/libc.so.6 Curiously, not all file systems are affected. I could reproduce the bug on ext4, but not on tmpfs or unionfs. -- Package-specific info: ** Version: Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11) -- System Information: Debian Release: bookworm/sid APT prefers unstable Architecture: i386 (x86_64) Foreign Architectures: amd64 -- Jakub Wilk
Bug#620887: Please add a shm_mkstemp() function
* Goswin von Brederlow <goswin-...@web.de>, 2011-04-04, 23:33: int shm_mkstemp(char *template); FWIW, this function is available on OpenBSD: https://man.openbsd.org/shm_mkstemp.3 -- Jakub Wilk
Bug#878159: libc6: posix_memalign(): free(): invalid next size (fast)
Adding forgotten attachment...
--
Jakub Wilk
#include
#include
int main(int argc, char **argv)
{
void *p;
return posix_memalign(, 0x10, SIZE_MAX - 0x20);
}
Bug#878159: libc6: posix_memalign(): free(): invalid next size (fast)
Package: libc6 Version: 2.24-17 Some posix_memalign() calls fail catastrophically: $ grep memalign test-posix-memalign.c return posix_memalign(, 0x10, SIZE_MAX - 0x20); $ make test-posix-memalign cc test-posix-memalign.c -o test-posix-memalign $ ./test-posix-memalign *** Error in `./test-posix-memalign': free(): invalid next size (fast): 0x57a96008 *** ... Backtrace: #0 0xf7fd7dc9 in __kernel_vsyscall () #1 0xf7e2add0 in __libc_signal_restore_set (set=0xd160) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79 #2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48 #3 0xf7e2c297 in __GI_abort () at abort.c:89 #4 0xf7e6638f in __libc_message (do_abort=, fmt=) at ../sysdeps/posix/libc_fatal.c:175 #5 0xf7e6cfc7 in malloc_printerr (action=, str=0xf7f60318 "free(): invalid next size (fast)", ptr=, ar_ptr=0xf7fb2780 ) at malloc.c:5049 #6 0xf7e6d806 in _int_free (av=av@entry=0xf7fb2780 , p=p@entry=0x56558000, have_lock=have_lock@entry=1) at malloc.c:3905 #7 0xf7e6f8c3 in _int_memalign (av=av@entry=0xf7fb2780 , alignment=alignment@entry=16, bytes=bytes@entry=4294967263) at malloc.c:4497 #8 0xf7e70eea in _mid_memalign (alignment=16, bytes=4294967263, address=) at malloc.c:3158 #9 0xf7e71028 in _mid_memalign (alignment=alignment@entry=16, bytes=bytes@entry=4294967263, address=) at malloc.c:3121 #10 0xf7e72b7f in __posix_memalign (memptr=0xd6ac, alignment=16, size=4294967263) at malloc.c:5071 #11 0x566b in main () -- System Information: Architecture: i386 Versions of packages libc6 depends on: ii libgcc1 1:7.2.0-8 -- Jakub Wilk
Bug#816833: "LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 /lib/ld-linux.so.2" segfaults on some Go programs
Package: libc6 Version: 2.21-9 Control: affects -1 + adequate (This might be the same as #710521...) $ dpkg-query -W minica ratt minica 1.0-1 ratt0.0~git20150816.0.b060319-1 $ LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 /lib/ld-linux.so.2 /usr/bin/minica linux-gate.so.1 (0xf7786000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7763000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75e6000) /lib/ld-linux.so.2 (0x56628000) Segmentation fault $ LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 /lib/ld-linux.so.2 /usr/bin/ratt linux-gate.so.1 (0xf773d000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf771a000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf759d000) /lib/ld-linux.so.2 (0x565b) Segmentation fault -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libc6 depends on: ii libgcc1 1:5.3.1-10 Versions of packages libc6 recommends: pn libc6-i686 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.58 pn glibc-doc pn libc-l10n pn locales -- Jakub Wilk
Bug#806882: libc-bin: unable to set pts permissions (and open a terminal...)
* Aurelien Jarno <aurel...@aurel32.net>, 2015-12-04, 18:11: In that case given the issue is due to a user misconfiguration, I guess we should just try to detect it, display a note and fail the installation. Warning the user would be certainly a good idea. But of course that would only help if the devpts filesystem was misconfigured at installation time. For me, this wasn't the case. What was the issue on your case? I had schroot configured to mount /dev/pts with default permissions. (This should not be the problem for most schroot users. By default schroot bind-mounts /dev/pts from the host.) So my /dev/pts permissions were fine on upgrade; they only broke later, when I tried to build a package. In another mail Aurelien wrote: usertags 806882 + serious thanks tag 806882 + serious thanks Due to a typo, this bug didn't get upgraded to serious. FWIW, it wasn't a typo. :) It's an actual usertag of mine: https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=serious=jwilk%40debian.org -- Jakub Wilk
Bug#806882: libc-bin: unable to set pts permissions (and open a terminal...)
usertags 806882 + serious thanks I've been bitten by it too... Couldn't libc just leave ownership/permission as they are if /dev/pts is a devpts filesystem? * Domenico Andreoli <domenico.andreoli...@gmail.com>, 2015-12-02, 17:13: $ grep devpts /etc/fstab none /mnt/sid64/dev/pts devpts defaults 0 0 none /mnt/sid64/home/chernobyl/dev/pts devpts defaults 0 0 "defaults" are not correct options. You need "gid=5" at least. All devpts fstab entries need to have correct options, because all devpts filesystems are shared by default. (You can probably use the "newinstance" option to disable sharing them.) -- Jakub Wilk
Bug#806882: libc-bin: unable to set pts permissions (and open a terminal...)
Hi Aurelien!
Thanks for looking into this bug.
* Aurelien Jarno <aurel...@aurel32.net>, 2015-12-04, 15:05:
Couldn't libc just leave ownership/permission as they are if /dev/pts
is a devpts filesystem?
What do you mean? The libc doesn't change anymore the permissions
(pt_chown has been removed for security reasons), and that's actually
the issue.
grantpt() calls chown() or chmod() if the device ownership or mode is
not what it expects. See sysdeps/unix/grantpt.c, lines 130-171.
And it Domenico's strace output, it was chown() that failed:
chown("/dev/pts/2", 1000, 5)= -1 EPERM (Operation not permitted)
Now, I realize that changing ownership and permissions of the device is
exactly what grantpt() is documented to do. The problem is that it turns
a minor configuration problem (devpts mounted without gid=5) into a big
usability problem, which is difficult to debug.
IMO it'd be practical for glibc to assume that the devpts filesystem is
always correctly configured and that changing ownership and permissions
is not necessary. This would also fix bug #705056.
* Domenico Andreoli <domenico.andreoli...@gmail.com>, 2015-12-02, 17:13:
$ grep devpts /etc/fstab
none /mnt/sid64/dev/pts devpts defaults
0 0
none /mnt/sid64/home/chernobyl/dev/pts devpts defaults
0 0
"defaults" are not correct options. You need "gid=5" at least.
Well they are the one in the chroots...
All devpts fstab entries need to have correct options, because all
devpts filesystems are shared by default. (You can probably use the
"newinstance" option to disable sharing them.)
You really mean the other entries in the fstab are causing the
permissions of /dev/pts to be changed?
It's very surprising, but yet, this is the case, at least on Linux:
# mount | grep /dev/pts
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
# mount -t devpts devpts /mnt
# mount | grep devpts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
devpts on /mnt type devpts (rw,relatime,mode=600,ptmxmode=000)
As you can see, options changed for both mounts.
In that case given the issue is due to a user misconfiguration, I guess
we should just try to detect it, display a note and fail the
installation.
Warning the user would be certainly a good idea. But of course that
would only help if the devpts filesystem was misconfigured at
installation time. For me, this wasn't the case.
--
Jakub Wilk
Bug#555168: Many locales files do not permit modification
As a data point, glibc upstream seem to believe that localedata is not copyrightable: https://sourceware.org/ml/libc-locales/2012-q2/msg00136.html -- Jakub Wilk -- 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/20150626165024.ga6...@jwilk.net
Bug#779392: libc6: regexec.c:1401: pop_fail_stack: Assertion `num = 0' failed
Package: libc6
Version: 2.19-15
Tags: security
Usertags: afl
The attached test program, which compiles an invalid regexp and then
tries to match a string against it, triggers an assertion:
$ make CFLAGS=-Wall pop_fail_stack
cc -Wallpop_fail_stack.c -o pop_fail_stack
$ ./pop_fail_stack
pop_fail_stack: regexec.c:1401: pop_fail_stack: Assertion `num = 0' failed.
Aborted
This bug was found using American fuzzy lop:
http://lcamtuf.coredump.cx/afl/
(available in Debian experimental)
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libc6 depends on:
ii libgcc1 1:5-20150226-1
Versions of packages libc6 recommends:
ii libc6-i686 2.19-15
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.55
ii glibc-doc 2.19-15
ii locales2.19-15
--
Jakub Wilk
#include assert.h
#include regex.h
#include stdio.h
int main(int argc, char **argv)
{
int rc;
regex_t preg;
regmatch_t pmatch[2];
rc = regcomp(preg, ()*)|\\1)*, REG_EXTENDED);
assert(rc == 0);
regexec(preg, , 2, pmatch, 0);
regfree(preg);
return 0;
}
Bug#776671: glibc: integer overflow in bsearch(3)
Source: glibc
Version: 2.19-13
Tags: patch
The way bsearch() computes indices is subject to integer overflow. This
should be only a problem on 32-bit systems, where it's possible to
allocate more than SIZE_MAX/2 bytes of memory.
The attached patch should fix this bug, but it was only lightly tested.
I also attached test case, which currently loops forever on 32-bit
systems. (Beware that it allocates 3GB of memory. Don't run it on a
system that is short of RAM!)
--
Jakub Wilk
diff --git a/bits/stdlib-bsearch.h b/bits/stdlib-bsearch.h
--- a/bits/stdlib-bsearch.h
+++ b/bits/stdlib-bsearch.h
@@ -28,7 +28,7 @@
__u = __nmemb;
while (__l __u)
{
- __idx = (__l + __u) / 2;
+ __idx = __l + (__u - __l) / 2;
__p = (void *) (((const char *) __base) + (__idx * __size));
__comparison = (*__compar) (__key, __p);
if (__comparison 0)
#include assert.h
#include stdlib.h
int cmp(const void *this, const void *other)
{
return
*((const char *)this) -
*((const char *)other);
}
int main(int argc, char **argv)
{
char key = 42;
size_t size = 3UL 30;
char* base = calloc(1, size);
base[size - 1] = key + 1;
base[size - 2] = key;
void *found = bsearch(key, base, size, 1, cmp);
assert(found == base + size - 2);
return 0;
}
Bug#776659: libc6: missing newline after cannot allocate TLS data structures for initial thread
Package: libc6 Version: 2.19-13 Severity: minor $ ulimit -v 3524; bash -c '' || echo '-- missing newline here' cannot allocate TLS data structures for initial thread-- missing newline here -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libc6:i386 depends on: ii libgcc1 1:4.9.2-10 Versions of packages libc6:i386 recommends: ii libc6-i686 2.19-13 Versions of packages libc6:i386 suggests: ii debconf [debconf-2.0] 1.5.55 ii glibc-doc 2.19-13 ii locales2.19-13 -- Jakub Wilk -- 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/20150130175146.ga6...@jwilk.net
Bug#772705: libc6: buffer overflow in tzset
Package: libc6 Version: 2.19-13 The attached crafted timezone file makes tzset(3) crash: $ TZ=$PWD/crashtz date *** Error in `date': free(): invalid next size (fast): 0x0916b160 *** Aborted Valgrind says: ==7754== Invalid write of size 1 ==7754==at 0x40F7D7D: __tzfile_read (tzfile.c:379) ==7754==by 0x40F71D1: tzset_internal (tzset.c:447) ==7754==by 0x40F749E: __tz_convert (tzset.c:632) ==7754==by 0x40F5BDC: localtime (localtime.c:42) ==7754==by 0x8049B94: ??? (in /bin/date) ==7754==by 0x8049885: ??? (in /bin/date) ==7754==by 0x4069A62: (below main) (libc-start.c:287) ==7754== Address 0x41fe816 is 6 bytes after a block of size 0 alloc'd ==7754==at 0x40291CC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==7754==by 0x40F79A1: __tzfile_read (tzfile.c:278) ==7754==by 0x40F71D1: tzset_internal (tzset.c:447) ==7754==by 0x40F749E: __tz_convert (tzset.c:632) ==7754==by 0x40F5BDC: localtime (localtime.c:42) ==7754==by 0x8049B94: ??? (in /bin/date) ==7754==by 0x8049885: ??? (in /bin/date) ==7754==by 0x4069A62: (below main) (libc-start.c:287) ==7754== ==7754== Invalid write of size 1 ==7754==at 0x40F7DDD: __tzfile_read (tzfile.c:389) ==7754==by 0x40F71D1: tzset_internal (tzset.c:447) ==7754==by 0x40F749E: __tz_convert (tzset.c:632) ==7754==by 0x40F5BDC: localtime (localtime.c:42) ==7754==by 0x8049B94: ??? (in /bin/date) ==7754==by 0x8049885: ??? (in /bin/date) ==7754==by 0x4069A62: (below main) (libc-start.c:287) ==7754== Address 0x41fe817 is 7 bytes after a block of size 0 alloc'd ==7754==at 0x40291CC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==7754==by 0x40F79A1: __tzfile_read (tzfile.c:278) ==7754==by 0x40F71D1: tzset_internal (tzset.c:447) ==7754==by 0x40F749E: __tz_convert (tzset.c:632) ==7754==by 0x40F5BDC: localtime (localtime.c:42) ==7754==by 0x8049B94: ??? (in /bin/date) ==7754==by 0x8049885: ??? (in /bin/date) ==7754==by 0x4069A62: (below main) (libc-start.c:287) This bug was found using American fuzzy lop: http://lcamtuf.coredump.cx/afl/ -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libc6:i386 depends on: ii libgcc1 1:4.9.2-6 Versions of packages libc6:i386 recommends: ii libc6-i686 2.19-13 -- Jakub Wilk crashtz Description: Binary data
Bug#772705: libc6: buffer overflow in tzset
* Jakub Wilk jw...@debian.org, 2014-12-10, 12:30: $ TZ=$PWD/crashtz date *** Error in `date': free(): invalid next size (fast): 0x0916b160 *** Aborted In case you wonder why would anyone want to use a malformed timezone file, see bugs #772706 and #772707. -- Jakub Wilk -- 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/20141210114000.ga8...@jwilk.net
Bug#760902: libc6: ld-linux-x86-64.so.2 segfaults with LD_BIND_NOW=yes on binaries generated by golang
Control: forcemerge 710521 -1 * Paul Wise p...@debian.org, 2014-09-09, 22:02: Confirmed with strace that this is caused by a SIGSEGV in libc6 in the following packages: aptly heartbleeder golang-go.tools These command-lines cause a segfault: LD_BIND_NOW=yes /usr/bin/aptly LD_BIND_NOW=yes /usr/bin/heartbleeder LD_BIND_NOW=yes /usr/bin/present LD_BIND_NOW=yes /usr/bin/godoc LD_BIND_NOW=yes /usr/bin/updater LD_BIND_NOW=yes /usr/bin/builder Interestingly the issue doesn't happen with docker.io and some of the other executables in golang-go.tools even though they are written in Go. This was already known as #710521, but thanks for providing fresh examples. :-) BTW, piuparts knows which packages adequate(1) tripped over: https://piuparts.debian.org/sid/inadequate_exit_issue.html I've filed a new bug against adequate: #762615 -- Jakub Wilk -- 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/20140923191828.ga4...@jwilk.net
Bug#758632: libc6: can't set locale hy_AM.armscii8
Package: libc6 Version: 2.19-9 Severity: minor locale -a lists hy_AM.armscii8 as one of the locales; but this locale cannot be set: $ locale -a | grep AM. hy_AM.armscii8 $ LC_ALL=hy_AM.armscii8 locale charmap locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968 Curiously enough, hy_AM.armscii-8 works: $ LC_ALL=hy_AM.armscii-8 locale charmap ARMSCII-8 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libgcc1 1:4.9.1-7 Versions of packages libc6 recommends: pn libc6-i686 none Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.53 pn glibc-doc none ii locales2.19-9 ii locales-all [locales] 2.19-9 -- Jakub Wilk -- 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/20140819131032.ga9...@jwilk.net
Bug#756858: glibc-doc-reference: missing underscore in front of SC_SSIZE_MAX
Source: glibc-doc-reference
Version: 2.19-1
Severity: minor
Tags: patch
Please see the attached patch.
--
Jakub Wilk
diff --git a/manual/conf.texi b/manual/conf.texi
--- a/manual/conf.texi
+++ b/manual/conf.texi
@@ -899,7 +899,7 @@
@comment unistd.h
@comment X/Open
-@item SC_SSIZE_MAX
+@item _SC_SSIZE_MAX
Inquire about the maximum value which can be stored in a variable of type
@code{ssize_t}.
Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup
* Dimitri John Ledkov x...@debian.org, 2014-06-02, 21:12: What I find unexpected is this: $ LANGUAGE=de LC_ALL=de_DE.UTF-8 stat /moo stat: cannot stat '/moo': No such file or directory Above should be in German, no?! See, I was right when I said unexpected. :-P The message is in German only if the de_DE.UTF-8 locale is installed, and it isn't on my system. -- Jakub Wilk -- 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/20140602202406.ga9...@jwilk.net
Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup
[I'm not (e)glibc maintainer, just a random gettext user.] * Zygmunt Krynicki zygmunt.kryni...@canonical.com, 2014-05-15, 12:57: If the LANGUAGE environment variable is set to a nonempty value, and the locale is not the C locale, the value of LANGUAGE is assumed to contain a colon separated list of locale names. The functions will attempt to look up a translation of msgid in each of the locales in turn. This is a GNU extension. This semantics of LANGUAGE is confusing and error-prone (it overrides LC_ALL... except when it doesn't). The exception for C was needed not to break existing software that set LC_ALL=C with the expectation that it resets all internationalization settings. But the C.UTF-8 locale is newer invention that the LANGUAGE variable, so there is no need to add such exception. This part works as expected. I would like to propose that the same special-case behavior is used when the locale is C.UTF-8 as it is becoming the de-facto better C and it is unexpected to see, for example, translated gettext messages when using such locale. What I find unexpected is this: $ LANGUAGE=de LC_ALL=de_DE.UTF-8 stat /moo stat: cannot stat '/moo': No such file or directory $ LANGUAGE=de LC_ALL=pl_PL.UTF-8 stat /moo stat: der Aufruf von stat für „/moo“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden At least with the advent of C.UTF-8, I don't have to hunt for an installed locale, and just use: $ LANGUAGE=de LC_ALL=C.UTF-8 stat /moo stat: der Aufruf von stat für „/moo“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden which works everywhere. -- Jakub Wilk -- 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/20140526194236.ga3...@jwilk.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
* Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 12:25:
We currently have a problem with the libc{0.1,0.3,6,6.1} packages,
which are marked as Multiarch:same, but are in practice not
co-installable due to the ELF interpreter path being the same on
various architectures. For example libc6:i386 and libc6:sparc are not
co-installable, causing dpkg to exit complaining onifile overwrite.
Sounds like a job for Provides+Conflicts+Replaces.
Here is the list of the different ELF interpreters for the various
architectures we have in Debian or floating around:
i386/lib/ld-linux.so.2
Provides: lib-ld-linux-so-2
Conflicts: lib-ld-linux-so-2
Replaces: lib-ld-linux-so-2
hppa/lib/ld.so.1
m68k/lib/ld.so.1
mips/lib/ld.so.1
s390/lib/ld.so.1
Provides: lib-ld-so-1
Conflicts: lib-ld-so-1
Replaces: lib-ld-so-1
amd64 /lib64/ld-linux-x86-64.so.2
Provides: lib64-ld-linux-x86-64-so-2
Conflicts: lib64-ld-linux-x86-64-so-2
Replaces: lib64-ld-linux-x86-64-so-2
... and so on.
--
Jakub Wilk
--
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/20140519111636.gb8...@jwilk.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
* Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 13:28: i386/lib/ld-linux.so.2 Provides: lib-ld-linux-so-2 Conflicts: lib-ld-linux-so-2 Replaces: lib-ld-linux-so-2 So following your way, it would be exactly the same for libc6:sparc. libc6-i386 also provides /lib/ld-linux.so.2. It should be co-installable with libc6:i386, but libc6:sparc should not be co-installable with libc6:i386 or libc6-i386. Oh, right. Couldn't the biarch packages die already? :) If they can't, I suppose you can implement cross-architecture conflicts with plain conflicts against virtual packages: Package: libc6 Architecture: i386 Provides: libc6-on-i386 Conflicts: libc6-on-sparc, ... Package: libc6-i386 Architecture: amd64 Conflicts: libc6-on-sparc, ... Package: libc6 Architecture: sparc Provides: libc6-on-sparc Conflicts: libc6-on-i386, libc6-i386, ... -- Jakub Wilk -- 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/20140519120115.ga2...@jwilk.net
Bug#741482: libc6: ptsname_r() can use uninitialized memory
Package: libc6
Version: 2.18-4
If the fd refers to a terminal device, but not a pty master, ptsname_r()
passes the buffer (which would be normally uninitialized) unchanged to
stat64:
$ cat test.c
#define _XOPEN_SOURCE
#include stdlib.h
int main(int argc, char **argv)
{
char buffer[128] = garbage;
ptsname_r(0, buffer, sizeof buffer);
return 0;
}
$ gcc test.c -o t
$ strace -o '| grep -B2 garbage' ./t
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
ioctl(0, TIOCGPTN, [-142970892])= -1 ENOTTY (Inappropriate ioctl for
device)
stat64(garbage, 0xfffafe20) = -1 ENOENT (No such file or directory)
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6:i386 depends on:
ii libgcc1 1:4.9-20140303-1
Versions of packages libc6:i386 recommends:
ii libc6-i686 2.18-4
--
Jakub Wilk
--
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/20140312220627.ga5...@jwilk.net
Bug#734607: libc6-i686: granpt() fails with EPERM
Package: libc6-i686
Version: 2.18-0experimental0
Severity: important
grantpt() always fail with errno=EPERM:
$ ./test_grantpt
grantpt: Operation not permitted
Curiously enough, the non-686-optimized versions works correctly:
$ LD_HWCAP_MASK=0 ./test_grantpt
okay!
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6-i686 depends on:
ii libc6 2.18-0experimental0
--
Jakub Wilk
#define _GNU_SOURCE
#include stdio.h
#include stdlib.h
int main(int arg, char **argv)
{
int fd = getpt();
if (fd == -1) {
perror(getpt);
return 1;
}
int rc = grantpt(fd);
if (rc != 0) {
perror(grantpt);
return 1;
}
fprintf(stderr, okay!\n);
exit(0);
}
Bug#710521: ldd -r /usr/bin/go segfaults
Package: libc6 Version: 2.17-3 Running ldd -r on /usr/bin/go (shipped by golang-go 2:1.1-1) causes a segfault: $ ldd -r /usr/bin/go linux-gate.so.1 (0xf7757000) libpthread.so.0 = /lib/i386-linux-gnu/libpthread.so.0 (0xf7738000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf75c3000) /lib/ld-linux.so.2 (0xf7758000) /usr/bin/ldd: line 116: 8528 Segmentation fault LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= $@ -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libgcc1 1:4.8.0-9 Versions of packages libc6 recommends: pn libc6-i686 none Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.50 pn glibc-doc none pn localesnone -- Jakub Wilk -- 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/20130531153523.ga8...@jwilk.net
Bug#705056: /etc/default/devpts instructions to set mesg n by default don't work
Package: initscripts,libc6 /etc/default/devpts reads: # Set to 600 to have `mesg n' be the default TTYMODE=620 But this doesn't really work. Even if you mount /dev/pts with mode=600, your pty devices will end up with 620 permissions. This is because well-behaved software calls grantpt(), which changes the device permissions. Either grantpt() should be fixed not to touch permissions if /dev/pts is a devpts fs (as it did in the past[0]) or initscripts should be fixed not to claim you can have mesg n by default. [0] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=292e3abebff9f94ca47c1a725a691cb6ed6cff5f -- Jakub Wilk -- 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/20130409151347.ga5...@jwilk.net
Bug#698863: i386 ldd run against amd64 ld-*.so - exited with unknown exit code (127)
Package: libc-bin Version: 2.13-38 Severity: wishlist This is what happens when I run i386 ldd against the amd64 dynamic linker: $ ldd /lib/x86_64-linux-gnu/ld-2.16.so loader cannot load itself ldd: exited with unknown exit code (127) If with it printed the usual not a dynamic executable and continued processing other files provided on the command-line (if there are any) instead. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.7-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Jakub Wilk -- 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/20130124170814.ga3...@jwilk.net
Bug#689792: localedef --help: typo: conform - conforming
Package: libc-bin Version: 2.13-35 Severity: minor $ localedef --help | grep -w conform --posixBe strictly POSIX conform It should be s/conform/conforming/. -- Jakub Wilk -- 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/20121006112040.ga8...@jwilk.net
Bug#681688: ld.so manpage: truncated description of LD_VERBOSE
Package: libc-bin Version: 2.13-34 Severity: minor LD_VERBOSE description in ld.so manpage reads: If set to non-empty string, output symbol versioning information about the program if querying information about the program (ie. either This sentence appears to be truncated. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.4-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Jakub Wilk -- 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/20120715165903.ga6...@jwilk.net
Bug#654582: libc-bin: formatting error in ld.so(8) manpage
Package: libc-bin Version: 2.13-24 Severity: minor Tags: patch In the ld.so(8) manual page, there should be a new line between The following names are currently recognized and Alpha. Please see the attached patch. -- Jakub Wilk diff --git a/debian/local/manpages/ld.so.8 b/debian/local/manpages/ld.so.8 --- a/debian/local/manpages/ld.so.8 +++ b/debian/local/manpages/ld.so.8 @@ -166,6 +166,7 @@ the best suitable version of a given library. Hardware capabilities directories could be cascaded to combine CPU features. Hardware capabilities depends on the CPU. The following names are currently recognized: +.TP .B Alpha ev4, ev5, ev56, ev6, ev67 .TP
Bug#636947: ldd tries to call lddlibc4
Package: libc-bin Version: 2.13-14 Severity: minor If I run ldd on a non-ELF file, it tries to execute lddlibc4, but no such binary exist on modern Debian systems: $ ldd /etc/fstab /usr/bin/ldd: line 104: lddlibc4: command not found not a dynamic executable -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Jakub Wilk -- 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/20110807110609.ga7...@jwilk.net
Bug#636947: ldd tries to call lddlibc4
* Aurelien Jarno aurel...@aurel32.net, 2011-08-07, 16:31:
$ ldd /etc/fstab
/usr/bin/ldd: line 104: lddlibc4: command not found
not a dynamic executable
It's not something I am able to reproduce, also /usr/bin/ldd shipped
with the current libc-bin doesn't have any mention of lddlibc4.
It does, but oddly enough only on i386.
Could you please:
- send me a copy of your /usr/bin/ldd file
- send me the output of sh -x /usr/bin/ldd /etc/fstab
Both attached.
--
Jakub Wilk
#! /bin/bash
# Copyright (C) 1996-2008, 2009, 2010, 2011 Free Software Foundation, Inc.
# This file is part of the GNU C Library.
# The GNU C Library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
# The GNU C Library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
# You should have received a copy of the GNU Lesser General Public
# License along with the GNU C Library; if not, write to the Free
# Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
# 02111-1307 USA.
# This is the `ldd' command, which lists what shared libraries are
# used by given dynamically-linked executables. It works by invoking the
# run-time dynamic linker as a command and setting the environment
# variable LD_TRACE_LOADED_OBJECTS to a non-empty value.
# We should be able to find the translation right at the beginning.
TEXTDOMAIN=libc
TEXTDOMAINDIR=/usr/share/locale
RTLDLIST=/lib/ld-linux.so.2
warn=
bind_now=
verbose=
while test $# -gt 0; do
case $1 in
--vers | --versi | --versio | --version)
echo 'ldd (Debian EGLIBC 2.13-14) 2.13'
printf $Copyright (C) %s Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
2011
printf $Written by %s and %s.
Roland McGrath Ulrich Drepper
exit 0
;;
--h | --he | --hel | --help)
printf $Usage: ldd [OPTION]... FILE...
--help print this help and exit
--version print version information and exit
-d, --data-relocs process data relocations
-r, --function-relocs process data and function relocations
-u, --unusedprint unused direct dependencies
-v, --verbose print all information
printf $For bug reporting instructions, please see:
%s.
http://www.debian.org/Bugs/
exit 0
;;
-d | --d | --da | --dat | --data | --data- | --data-r | --data-re | \
--data-rel | --data-relo | --data-reloc | --data-relocs)
warn=yes
shift
;;
-r | --f | --fu | --fun | --func | --funct | --functi | --functio | \
--function | --function- | --function-r | --function-re | --function-rel | \
--function-relo | --function-reloc | --function-relocs)
warn=yes
bind_now=yes
shift
;;
-v | --verb | --verbo | --verbos | --verbose)
verbose=yes
shift
;;
-u | --u | --un | --unu | --unus | --unuse | --unused)
unused=yes
shift
;;
--v | --ve | --ver)
echo 2 $ldd: option \`$1' is ambiguous
exit 1
;;
--) # Stop option processing.
shift; break
;;
-*)
echo 2 'ldd:' $unrecognized option \`$1'
echo 2 $Try \`ldd --help' for more information.
exit 1
;;
*)
break
;;
esac
done
nonelf ()
{
# Maybe extra code for non-ELF binaries.
file=$1
# Run the ldd stub.
lddlibc4 $file
# Test the result.
if test $? -lt 3; then
return 0;
fi
# In case of an error punt.
return 1;
}
add_env=LD_TRACE_LOADED_OBJECTS=1 LD_WARN=$warn LD_BIND_NOW=$bind_now
add_env=$add_env LD_LIBRARY_VERSION=\$verify_out
add_env=$add_env LD_VERBOSE=$verbose
if test $unused = yes; then
add_env=$add_env LD_DEBUG=\$LD_DEBUG${LD_DEBUG:+,}unused\
fi
# The following use of cat is needed to make ldd work in SELinux
# environments where the executed program might not have permissions
# to write to the console/tty. But only bash 3.x supports the pipefail
# option, and we don't bother to handle the case for older bash versions.
if x=`set -o` test $x != ${x#*pipefail} set -o pipefail ; then
try_trace() {
eval $add_env '$@' | cat
}
else
try_trace() {
eval $add_env '$@'
}
fi
case $# in
0)
echo 2 'ldd:' $missing file arguments
echo 2 $Try \`ldd --help' for more information.
exit 1
;;
1)
single_file=t
;;
*)
single_file=f
;;
esac
result=0
for file do
# We don't list the file name when there is only one.
test $single_file = t || echo ${file}:
case $file in
*/*) :
;;
*) file=./$file
;;
esac
if test ! -e $file; then
echo ldd: ${file}: $No such file or directory 2
result=1
elif test
Bug#611411: glibc-doc-reference: FTBFS: texi2dvi fails
Source: glibc-doc-reference Version: 2.11.1-1 Severity: serious Justification: fails to build from source glibc-doc-reference FTBFS in a clean squeeze chroot. Tail of the build log: | texi2dvi --pdf libc.texinfo | make[1]: *** [libc.pdf] Error 1 | make[1]: Leaving directory `/build/sbuild-glibc-doc-reference_2.11.1-1-i386-6OZu9C/glibc-doc-reference-2.11.1/manual' | make: *** [build-stamp] Error 2 If texi2dvi weren't buggy (#611408), the error message would be: | This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) | restricted \write18 enabled. | I can't find the format file `etex.fmt'! | | kpathsea: Running mktexfmt etex.fmt | /usr/bin/mktexfmt: 974: /usr/share/texmf/texconfig/tcfmgr: not found | fmtutil: config file `fmtutil.cnf' not found. | texi2dvi: texinfo.tex appears to be broken, quitting. -- Jakub Wilk -- 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/20110129000809.ga2...@jwilk.net
Bug#608332: eglibc: tst-nice fails for nice=19
Source: eglibc Version: 2.11.2-7 Severity: minor $ gcc -O2 -Wall -D_GNU_SOURCE posix/tst-nice.c -o tst-nice $ nice -n19 ./tst-nice FAIL: retval (19) of nice(10) != 29 As a consequence, eglibc FTBFS when built with such a high niceness. -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Jakub Wilk -- 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/20101229235157.ga3...@jwilk.net
Bug#576826: eglibc: [sparc, alpha] missing declaration for epoll_create1 (?)
Package: eglibc
Version: 2.10.2-6
Severity: normal
While trying to debug bug #570689, I noticed some inconsistencies how
functions epoll_create1 and epoll_create2 are handled on sparc and
alpha architectures:
1. In contrast to all other architectures, sys/epoll.h declares
epoll_create2() rather epoll_create1(). However, this function is
not defined anywhere:
$ cat tmp.c
#include sys/epoll.h
int main(int argc, char **argv)
{
epoll_create2(42, EPOLL_CLOEXEC);
return 0;
}
$ gcc -Wall tmp.c
/tmp/ccymThnY.o: In function `main':
tmp.c:(.text+0x14): undefined reference to `epoll_create2'
collect2: ld returned 1 exit status
2. Conversely, the epoll_create1 symbol is defined, but not declared
anywhere within headers:
$ cat tmp.c
#include sys/epoll.h
int main(int argc, char **argv)
{
epoll_create1(EPOLL_CLOEXEC);
return 0;
}
$ gcc -Wall tmp.c
tmp.c: In function ‘main’:
tmp.c:4: warning: implicit declaration of function ‘epoll_create1’
$ nm -D a.out | grep epoll
U epoll_create1
3. epoll_create1() always fails with errno=ENOSYS (which is fine per
se), but on sparc __stub_epoll_create1 is not defined. (It *is* defined
on alpha, however.)
--
Jakub Wilk
signature.asc
Description: Digital signature
Bug#483189: manpages/docbook.xsl: LESS-THAN OR EQUAL TO character is converted incorrectly
reassign 483189 man-db 2.5.5-2 retitle 483189 man-db: does not really support UTF-8 manpages severity 483189 important clone 483189 -1 reassign -1 docbook-xsl 1.73.2.dfsg.1-5 retitle -1 manpages/docbook.xsl: please add encoding declarations severity -1 wishlist thanks * Daniel Leidert daniel.leid...@wgdd.de, 2008-06-15, 20:28: The file its actually UTF-8-encoded, but man interprets it as if it was ISO-8859-1. The file itself looks perfectly here. iconv doesn't seem to be happy about the UTF-8 character itself and because of this, man output does not show the character. After some investigation and reading: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519209#51 I'm quite sure that the bug has nothing to do with iconv. What is happening here is as follows: manconv tries to convert the manpage from UTF-8 to ISO-8859-1, which obviously fails; thus, it assumes the encoding is ISO-8859-1. To solve the issue: - man should support UTF-8-encoded manual pages with characters not covered by legacy encodings. - docbook stylesheet should be adding encoding declarations to the generated manpages. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528353: /usr/share/bug/locales/presubj: typo
Package: locales Version: 2.9-12 Severity: minor File: /usr/share/bug/locales/presubj $ grep abug /usr/share/bug/locales/presubj for more than 24 hours before reporting abug about `locales` dependencies. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527945: locales: bashism in locales.config
Package: locales Version: 2.9-12 Severity: serious Justification: Policy 10.4 User: debian-rele...@lists.debian.org Usertags: goal-dash Tags: patch /var/lib/dpkg/info/locales.config uses echo -e, which is a bashism. -- Jakub Wilk diff --git a/locales.config b/locales.config --- a/locales.config +++ b/locales.config @@ -459,7 +459,7 @@ fi # List of supported locales (PROVIDED_LOCALES + USER_LOCALES + GEN_LOCALES) -SUPPORTED_LOCALES=$(echo -e $PROVIDED_LOCALES\n$USER_LOCALES\n$GEN_LOCALES | grep -v ^$ | sort -u | tr '\n' ',' | sed -e 's/, */, /g' -e 's/, *$//g') +SUPPORTED_LOCALES=$(printf '%s\n' $PROVIDED_LOCALES $USER_LOCALES $GEN_LOCALES | grep -v ^$ | sort -u | tr '\n' ',' | sed -e 's/, */, /g' -e 's/, *$//g') db_subst locales/locales_to_be_generated locales $SUPPORTED_LOCALES # Get the list of selected locales from /etc/locale.gen
Bug#525299: iconv accepts UTF-8-encoded UTF-16 surrogates
Package: libc6 Version: 2.9-7 Severity: normal $ man utf-8 | grep -A 2 UTF-16 | sed -e 's/^ *//' The UCS code values 0xd800–0xdfff (UTF-16 surrogates) as well as 0xfffe and 0x (UCS non-characters) should not appear in conforming UTF-8 streams. $ s='\xed\xa0\x88\xed\xbd\x85' # 0xd808 + 0xdf45 $ for e in UTF-8 UTF-16 UTF-32 UCS-4 do printf $e\t printf $s | iconv -f UTF-8 -t $e /dev/null printf 'OK\n' done UTF-8 OK UTF-16 iconv: illegal input sequence at position 0 UTF-32 iconv: illegal input sequence at position 0 UCS-4 OK -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (900, 'unstable'), (500, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libgcc1 1:4.3.3-8 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii glibc-doc 2.9-7 GNU C Library: Documentation ii libc6-i6862.9-7 GNU C Library: Shared libraries [i ii locales 2.9-7 GNU C Library: National Language ( -- debconf information: glibc/upgrade: true glibc/disable-screensaver: glibc/restart-failed: * glibc/restart-services: -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518394: ld.so(8): typo
Package: libc6 Version: 2.9-4 Severity: minor File: /usr/share/man/man8/ld.so.8.gz $ man ld.so | grep LD_PROFILE | sed -e 's/^ *//' LD_PROFILE LD_PROFILE_OUTPUT File where LD_PROFILE output should be stored, default is standard output. LD_DEBUG_OUTPUT is ignored for setuid/setgid binaries. It should be, of course, s/DEBUG/PROFILE/. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (900, 'unstable'), (500, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libgcc1 1:4.3.3-5 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii glibc-doc 2.9-4 GNU C Library: Documentation ii libc6-i6862.9-4 GNU C Library: Shared libraries [i ii locales 2.9-4 GNU C Library: National Language ( -- debconf information excluded -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507488: mtrace always displays a warning
Package: libc6-dev Version: 2.7-16 Severity: minor File: /usr/bin/mtrace $ mtrace $* is no longer supported at /usr/bin/mtrace line 2. Wrong number of arguments, run /usr/bin/mtrace --help for help. at /usr/bin/mtrace line 88. $ mtrace --help $* is no longer supported at /usr/bin/mtrace line 2. Usage: mtrace [OPTION]... [Binary] MtraceData --help print this help, then exit --versionprint version number, then exit For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii linux-libc-dev2.6.26-10 Linux support headers for userspac Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-23 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.4-4The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.2-1The GNU C compiler ii tcc [c-compiler] 0.9.24-1 the smallest ANSI C compiler Versions of packages libc6-dev suggests: ii glibc-doc 2.7-16 GNU C Library: Documentation ii manpages-dev 3.05-1 Manual pages about using GNU/Linux -- no debconf information -- Jakub Wilk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505784: pthread_cancel(3): misleading information on cancellation points
Package: glibc-doc
Version: 2.7-15
Severity: normal
File: /usr/share/man/man3/pthread_cancel.3.gz
POSIX specifies that a number of system calls (basically, all system
calls that may block, such as read(2), write(2), wait(2), etc.) and
library functions that may call these system calls (e.g. fprintf(3))
are cancellation points. LinuxThreads is not yet integrated enough with
the C library to implement this, and thus none of the C library
functions is a cancellation point.
This is no longer true, as you can easily check with the attached
program.
--
Jakub Wilk
#include stdio.h
#include pthread.h
#include unistd.h
volatile int i;
void *start(void *p)
{
i = 0;
while (1)
{
putchar('.');
i++;
}
return NULL;
}
int main()
{
pthread_t thread;
pthread_create(thread, NULL, start, NULL);
usleep(1 15);
pthread_cancel(thread);
pthread_join(thread, NULL);
printf(\n%d\n, i);
return 0;
}
/* vim:set ts=2 sw=2 et:*/
