Bug#976133: marked as pending in glibc
On Sat, Sep 04, 2021 at 07:56:12PM +, Aurelien Jarno wrote: > Hello, > > Bug #976133 in glibc reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/glibc-team/glibc/-/commit/331bb702600840c345d804fe689e0d402dc5ad05 > > > debian/debhelper.in/libc-dev.install, debian/debhelper.in/libc.install, > debian/control.in/libc: move sotruss-lib.so from libc6 to libc6-dev. Closes: > #976133. > Thank you! - Josh
Processed: retitle 607573 to libc0.1: setxattr, fsetxattr and lsetxattr are ENOSYS stubs
Processing commands for cont...@bugs.debian.org: > retitle 607573 libc0.1: setxattr, fsetxattr and lsetxattr are ENOSYS stubs Bug #607573 [src:glibc] setxattr, fsetxattr and lsetxattr are ENOSYS stubs Bug #897335 [src:glibc] extattr prototypes declared in kernel headers sys/extattr.h but not implemented by libc0.1 Changed Bug title to 'libc0.1: setxattr, fsetxattr and lsetxattr are ENOSYS stubs' from 'setxattr, fsetxattr and lsetxattr are ENOSYS stubs'. Changed Bug title to 'libc0.1: setxattr, fsetxattr and lsetxattr are ENOSYS stubs' from 'extattr prototypes declared in kernel headers sys/extattr.h but not implemented by libc0.1'. > thanks Stopping processing here. Please contact me if you need assistance. -- 607573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573 897335: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897335 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: found 607573 in glibc/2.11.2-7
Processing commands for cont...@bugs.debian.org: > found 607573 glibc/2.11.2-7 Bug #607573 [src:glibc] setxattr, fsetxattr and lsetxattr are ENOSYS stubs Bug #897335 [src:glibc] extattr prototypes declared in kernel headers sys/extattr.h but not implemented by libc0.1 The source glibc and version 2.11.2-7 do not appear to match any binary packages Marked as found in versions glibc/2.11.2-7. Marked as found in versions glibc/2.11.2-7. > thanks Stopping processing here. Please contact me if you need assistance. -- 607573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573 897335: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897335 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 607573 to src:glibc
Processing commands for cont...@bugs.debian.org: > reassign 607573 src:glibc Bug #607573 [libc0.1] setxattr, fsetxattr and lsetxattr are ENOSYS stubs Bug #897335 [libc0.1] extattr prototypes declared in kernel headers sys/extattr.h but not implemented by libc0.1 Warning: Unknown package 'libc0.1' Bug reassigned from package 'libc0.1' to 'src:glibc'. Bug reassigned from package 'libc0.1' to 'src:glibc'. Ignoring request to alter found versions of bug #607573 to the same values previously set Ignoring request to alter found versions of bug #897335 to the same values previously set Ignoring request to alter fixed versions of bug #607573 to the same values previously set Ignoring request to alter fixed versions of bug #897335 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 607573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573 897335: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897335 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#771261: marked as done (locales: date_fmt appears to be wrong in es_ES and ca_ES)
Your message dated Sun, 5 Sep 2021 00:49:01 +0200 with message-id and subject line Bug#771261: locales: date_fmt appears to be wrong in es_ES and ca_ES has caused the Debian Bug report #771261, regarding locales: date_fmt appears to be wrong in es_ES and ca_ES to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 771261: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771261 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: locales Version: 2.19-13 Severity: normal Tags: l10n Dear Maintainer, Thanks for working in locales. The "date_fmt" string in es_ES (and in ca_ES as one friend confirmed) appears to produce a wrong order in the dates. With the standard generated file (including the line date_fmt="%a %b %e %H:%M:%S %Z %Y" ) $ date vie nov 28 02:25:05 CET 2014 This looks wrong for es_ES (and ca_ES), the day of the month should go before the name of the month. $ date +"%a %e %b %H:%M:%S %Z %Y" vie 28 nov 02:26:27 CET 2014 This is correct. So I suppose the date_fmt line should be changed from date_fmt="%a %b %e %H:%M:%S %Z %Y" to date_fmt="%a %e %b %H:%M:%S %Z %Y" I'm not sure if this is a problem of Debian or a problem in glibc in general. I also don't know if other locales derived from "es" or "ca" are affected. But at least, I can confirm that my proposal is correct for es_ES and ca_ES. Below you can find the details about locale of my system. Thank you very much Laura Arjona Reina https://wiki.debian.org/LauraArjona $ locale LANG=es_ES.utf8 LANGUAGE= LC_CTYPE="es_ES.utf8" LC_NUMERIC="es_ES.utf8" LC_TIME="es_ES.utf8" LC_COLLATE="es_ES.utf8" LC_MONETARY="es_ES.utf8" LC_MESSAGES="es_ES.utf8" LC_PAPER="es_ES.utf8" LC_NAME="es_ES.utf8" LC_ADDRESS="es_ES.utf8" LC_TELEPHONE="es_ES.utf8" LC_MEASUREMENT="es_ES.utf8" LC_IDENTIFICATION="es_ES.utf8" LC_ALL= larjona@larjona-laptop:/usr/share/i18n/locales$ locale -k LC_TIME abday="dom;lun;mar;mié;jue;vie;sáb" day="domingo;lunes;martes;miércoles;jueves;viernes;sábado" abmon="ene;feb;mar;abr;may;jun;jul;ago;sep;oct;nov;dic" mon="enero;febrero;marzo;abril;mayo;junio;julio;agosto;septiembre;octubre;noviembre;diciembre" am_pm=";" d_t_fmt="%a %d %b %Y %T %Z" d_fmt="%d/%m/%y" t_fmt="%T" t_fmt_ampm="" era= era_year="" era_d_fmt="" alt_digits= era_d_t_fmt="" era_t_fmt="" time-era-num-entries=0 time-era-entries="d" week-ndays=7 week-1stday=19971130 week-1stweek=5 first_weekday=2 first_workday=2 cal_direction=1 timezone="" date_fmt="%a %b %e %H:%M:%S %Z %Y" time-codeset="UTF-8" -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.53 ii libc6 [glibc-2.19-1] 2.19-13 locales recommends no packages. locales suggests no packages. -- debconf information: locales/default_environment_locale: None locales/locales_to_be_generated: es_ES.UTF-8 UTF-8 --- End Message --- --- Begin Message --- Version: 2.31-0experimental0 Hi, On 2014-11-28 02:32, Laura Arjona Reina wrote: > Package: locales > Version: 2.19-13 > Severity: normal > Tags: l10n > > Dear Maintainer, > > Thanks for working in locales. > > The "date_fmt" string in es_ES (and in ca_ES as one friend confirmed) appears > to produce a wrong order in the dates. > > With the standard generated file (including the line date_fmt="%a %b %e > %H:%M:%S %Z %Y" ) > > $ date > > vie nov 28 02:25:05 CET 2014 > > This looks wrong for es_ES (and ca_ES), the day of the month should go before > the name of the month. > > $ date +"%a %e %b %H:%M:%S %Z %Y" > vie 28 nov 02:26:27 CET 2014 > > This is correct. So I suppose the date_fmt line should be changed from > > date_fmt="%a %b %e %H:%M:%S %Z %Y" > > to > > date_fmt="%a %e %b %H:%M:%S %Z %Y" > > I'm not sure if this is a problem of Debian or a problem in glibc in general. > I > also don't know if other locales derived from "es" or "ca" are affected. But > at > least, I can confirm that my proposal is correct for es_ES and ca_ES. This issue has been fixed upstream for both es_ES and ca_ES locales (actually many more) in the following commit: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=75ba929987f6950dd008ef0f6270f1b21e9af511 This commit went into glibc package version 2.31-0experimental0 and is included in Bullseye. I am therefore closing the bug accordingly. Regards, Aurelien -- Aurelien Jarno
Bug#551292: marked as done (locales: Bad collate for pl_PL.UTF-8. Places space after [a-Z0-9])
Your message dated Sun, 5 Sep 2021 00:28:07 +0200 with message-id and subject line Re: locales: Bad collate for pl_PL.UTF-8. Places space after [a-Z0-9] has caused the Debian Bug report #551292, regarding locales: Bad collate for pl_PL.UTF-8. Places space after [a-Z0-9] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 551292: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551292 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: locales Version: 2.9-25 Severity: normal There exist bad sorting according to a space position when locale set to pl_PL. Script started on pią, 16 paź 2009, 23:27:11 kacper@mini: $ cat huuu a bc abc abc kacper@mini:$ sort huuu abc a bc abc kacper@mini:$ locale LANG=pl_PL.UTF-8 LC_CTYPE="pl_PL.UTF-8" LC_NUMERIC="pl_PL.UTF-8" LC_TIME="pl_PL.UTF-8" LC_COLLATE="pl_PL.UTF-8" LC_MONETARY="pl_PL.UTF-8" LC_MESSAGES="pl_PL.UTF-8" LC_PAPER="pl_PL.UTF-8" LC_NAME="pl_PL.UTF-8" LC_ADDRESS="pl_PL.UTF-8" LC_TELEPHONE="pl_PL.UTF-8" LC_MEASUREMENT="pl_PL.UTF-8" LC_IDENTIFICATION="pl_PL.UTF-8" LC_ALL= kacper@mini:$ exit Script done on pią, 16 paź 2009, 23:27:36 It's suggested that a mistake exists in a '/usr/share/i18n/locales/pl_PL'. http://groups.google.pl/group/pl.comp.os.linux/msg/3368e6ec856420cf -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.30-2-powerpc Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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.27 Debian configuration management sy ii libc6 [glibc-2.9-1] 2.9-25 GNU C Library: Shared libraries locales recommends no packages. locales suggests no packages. -- debconf information: locales/default_environment_locale: pl_PL.UTF-8 locales/locales_to_be_generated: pl_PL.UTF-8 UTF-8 --- End Message --- --- Begin Message --- Version: 2.27-0experimental0 On 2009-10-16 23:56, Kacper Perschke wrote: > Package: locales > Version: 2.9-25 > Severity: normal > > > There exist bad sorting according to a space position when locale set to > pl_PL. > Script started on pią, 16 paź 2009, 23:27:11 > kacper@mini: $ cat huuu > a bc > abc > abc > kacper@mini:$ sort huuu > abc > a bc > abc > kacper@mini:$ locale > LANG=pl_PL.UTF-8 > LC_CTYPE="pl_PL.UTF-8" > LC_NUMERIC="pl_PL.UTF-8" > LC_TIME="pl_PL.UTF-8" > LC_COLLATE="pl_PL.UTF-8" > LC_MONETARY="pl_PL.UTF-8" > LC_MESSAGES="pl_PL.UTF-8" > LC_PAPER="pl_PL.UTF-8" > LC_NAME="pl_PL.UTF-8" > LC_ADDRESS="pl_PL.UTF-8" > LC_TELEPHONE="pl_PL.UTF-8" > LC_MEASUREMENT="pl_PL.UTF-8" > LC_IDENTIFICATION="pl_PL.UTF-8" > LC_ALL= > kacper@mini:$ exit > Script done on pią, 16 paź 2009, 23:27:36 > > It's suggested that a mistake exists in a '/usr/share/i18n/locales/pl_PL'. > http://groups.google.pl/group/pl.comp.os.linux/msg/3368e6ec856420cf This bug has been fixed in the following upstream commit that went into glibc 2.27: https://sourceware.org/git/?p=glibc.git;a=commit;h=3ffc4cc1ad37fb36e419c9a3a72e1916d7d893d3 Closing the bug accordingly. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Processed: reassign 607573 to libc0.1
Processing commands for cont...@bugs.debian.org: > reassign 607573 libc0.1 Bug #607573 [src:glibc] setxattr, fsetxattr and lsetxattr are ENOSYS stubs Bug #897335 [src:glibc] extattr prototypes declared in kernel headers sys/extattr.h but not implemented by libc0.1 Bug reassigned from package 'src:glibc' to 'libc0.1'. Bug reassigned from package 'src:glibc' to 'libc0.1'. Warning: Unknown package 'libc0.1' Warning: Unknown package 'libc0.1' No longer marked as found in versions glibc/2.11.2-7 and glibc/2.27-3. No longer marked as found in versions glibc/2.27-3 and glibc/2.11.2-7. Warning: Unknown package 'libc0.1' Warning: Unknown package 'libc0.1' Ignoring request to alter fixed versions of bug #607573 to the same values previously set Ignoring request to alter fixed versions of bug #897335 to the same values previously set Warning: Unknown package 'libc0.1' > thanks Stopping processing here. Please contact me if you need assistance. -- 607573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573 897335: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897335 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#878159: marked as done (glibc: CVE-2018-6485: Integer overflow in posix_memalign)
Your message dated Sat, 4 Sep 2021 23:59:04 +0200 with message-id <20210904215904.gl19...@aurel32.net> and subject line Re: fixed 878159 in 2.26.9000+20180127.7e23a7dd-0experimental0 has caused the Debian Bug report #878159, regarding glibc: CVE-2018-6485: Integer overflow in posix_memalign to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 878159: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878159 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- 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 --- End Message --- --- Begin Message --- Version: glibc/2.26.9000+20180127.7e23a7dd-0experimental0 On 2018-02-02 22:35, Salvatore Bonaccorso wrote: > fixed 878159 2.26.9000+20180127.7e23a7dd-0experimental0 > thanks Closing the bug in addition of marking it fixed. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#757474: marked as done (libc6: amd copying a SVCXPRT structure leads to libc's RPC code sending packets of incorrect length)
Your message dated Sat, 4 Sep 2021 22:15:48 +0200 with message-id and subject line Re: Bug#757474: libc6: amd copying a SVCXPRT structure leads to libc's RPC code sending packets of incorrect length has caused the Debian Bug report #757474, regarding libc6: amd copying a SVCXPRT structure leads to libc's RPC code sending packets of incorrect length to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 757474: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757474 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.13-38+deb7u3 Severity: normal Tags: upstream patch This is really a problem with amd (am-utils), not the eglibc, but it's hard to solve on amd's side (see topic "NFS v2 RPC reply on LOOKUP" on the am-utils list) but can easily be hacked around on eglibc's side. The phenomenon is an amd NFS mount (typically on user login) to stall for 5 or 10 seconds. The root problem is that amd occasionally copies (the contents of) a SVCXPRT structure to store it away and be able to respond in the background. This is probably illegal, but "used to work" with the traditional SUN RPC implementation. Now eglibc stores both an iovec and a msghdr structure in a private part of the SVCXPRT, with the embedded msgghdr's msg_iov field set to point at the corresponding embedded iovec. When the structure is copied, the embedded msghdr's msg_iov still points to the original SVCXPT's embedded iovec, not the one embedded in the copy. If the copy is then used to transmit a reply, the embedded iovec's length is set to the desired value, but sendmsg() actually uses the original SVCXPRT's value due to the msg_iov field of the msghdr embedded in the copy pointing at the iovec embedded in the original (which fields are not set to the desired values). Then, sendmsg() transmits a reply of incorrect length and doesn't return with the expected value, which causes a second (error) reply being sent, confusing the client. The client then discard the reply and resends the request after a (five second) timeout. At that point, amd has probably finished the mount operation, doesn't background the request, replies correctly and everything works as expected. The problem can obviously be hacked around by forcing the embedded msghdr's msg_iov field to point to the embedded iovec before passing the msghdr to sendmsg(), which the attached (one-line) patch does. -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10.42.wap (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6:amd64 depends on: ii libc-bin 2.13-38+deb7u3 ii libgcc1 1:4.7.2-5 libc6:amd64 recommends no packages. Versions of packages libc6:amd64 suggests: ii debconf [debconf-2.0] 1.5.49 pn glibc-doc ii locales2.13-38+deb7u3 -- debconf information excluded Index: sunrpc/svc_udp.c === --- sunrpc/svc_udp.c(revision 3768) +++ sunrpc/svc_udp.c(revision 3769) @@ -329,6 +329,7 @@ iovp = (struct iovec *) >xp_pad [0]; iovp->iov_base = rpc_buffer (xprt); iovp->iov_len = slen; + mesgp->msg_iov = iovp; /* hack around clients like amd that memcpy() a SVCXPRT structure */ sent = __sendmsg (xprt->xp_sock, mesgp, 0); } else --- End Message --- --- Begin Message --- Version: 2.32-0experimental0 On 2014-08-08 17:24, Edgar Fuß wrote: > Package: libc6 > Version: 2.13-38+deb7u3 > Severity: normal > Tags: upstream patch > > This is really a problem with amd (am-utils), not the eglibc, but it's hard > to solve on amd's side (see topic "NFS v2 RPC reply on LOOKUP" on the > am-utils list) but can easily be hacked around on eglibc's side. > > The phenomenon is an amd NFS mount (typically on user login) to stall for 5 > or 10 seconds. > > The root problem is that amd occasionally copies (the contents of) a SVCXPRT > structure to store it away and be able to respond in the background. This is > probably illegal, but "used to work" with the traditional SUN RPC > implementation. > > Now eglibc stores both an iovec and a msghdr structure in a private part of > the SVCXPRT, with the embedded msgghdr's msg_iov field set to point at the > corresponding embedded iovec. When the structure is copied, the embedded > msghdr's msg_iov still points to the original
Processed: Bug#976133 marked as pending in glibc
Processing control commands: > tag -1 pending Bug #976133 [libc6] Please ship sotruss-lib.so in a different package Added tag(s) pending. -- 976133: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976133 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#826678: marked as done (libc6: upgrade of libc6 overwrites libraries in active use by Upstart /sbin/init)
Your message dated Sat, 4 Sep 2021 21:58:24 +0200 with message-id and subject line Re: Bug#826678: libc6: upgrade of libc6 overwrites libraries in active use by Upstart /sbin/init has caused the Debian Bug report #826678, regarding libc6: upgrade of libc6 overwrites libraries in active use by Upstart /sbin/init to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 826678: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826678 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.13-38+deb7u11 Severity: important Dear Maintainer, After an `apt-get upgrade` on a Debian stable system running with Upstart as /sbin/init, `initctl list` no longer works, giving me the error "Failed to connect to socket /com/ubuntu/upstart: Connection refused". Running `lsof -p1` shows a number of the linked libraries were deleted and overwritten during the libc6 upgrade. root@vps39987:~# lsof -p1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME init 1 root cwd DIR 182,564737 4096 2 / init 1 root rtd DIR 182,564737 4096 2 / init 1 root txt REG 182,564737 224568 2202 /sbin/init init 1 root mem REG 182,564737 274084 (deleted)/lib/x86_64-linux-gnu/libnss_files-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 274087 (deleted)/lib/x86_64-linux-gnu/libnss_nis-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 273955 (deleted)/lib/x86_64-linux-gnu/libnsl-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 274061 (deleted)/lib/x86_64-linux-gnu/libnss_compat-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 273075 (deleted)/lib/x86_64-linux-gnu/libdl-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 265765 (deleted)/lib/x86_64-linux-gnu/libpthread-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 272111 (deleted)/lib/x86_64-linux-gnu/libc-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 274113 (deleted)/lib/x86_64-linux-gnu/librt-2.13.so (stat: No such file or directory) init 1 root mem REG 182,564737 39744 262559 /lib/x86_64-linux-gnu/libjson.so.0.1.0 init 1 root mem REG 182,564737 126232 262470 /lib/x86_64-linux-gnu/libselinux.so.1 init 1 root mem REG 182,564737 286488 264017 /lib/x86_64-linux-gnu/libdbus-1.so.3.7.2 init 1 root mem REG 182,564737 38848 264236 /lib/libnih-dbus.so.1.0.0 init 1 root mem REG 182,564737 96216 264225 /lib/libnih.so.1.0.0 init 1 root mem REG 182,564737 272094 (deleted)/lib/x86_64-linux-gnu/ld-2.13.so (stat: No such file or directory) init 1 root 0u CHR 1,3 0t0 95 /dev/null init 1 root 1u CHR 1,3 0t0 95 /dev/null init 1 root 2u CHR 1,3 0t0 95 /dev/null init 1 root 3r FIFO 0,8 0t0 212010621 pipe init 1 root 4w FIFO 0,8 0t0 212010621 pipe init 1 root 5r DIR 0,10 0 1 inotify init 1 root 6r DIR 0,10 0 1 inotify init 1 root 8u unix 0x880425366100 0t0 212012641 socket init 1 root 9r DIR 0,10 0 1 inotify init 1 root 10r FIFO 0,8 0t0 97808 pipe `reboot` was ineffective. `reboot -f` may work, but I am waiting on my client's go-ahead, as the server seems to be otherwise working, and it's now the middle of the business day. I'm not sure what the solution would be. Just making sure you're aware of the situation. -- System Information: Debian Release: 7.11 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-042stab111.12 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-38+deb7u11 ii libgcc1 1:4.7.2-5 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.49 pn glibc-doc ii locales2.13-38+deb7u11 -- debconf information: glibc/upgrade: true glibc/restart-services: libraries/restart-without-asking: false glibc/disable-screensaver: glibc/restart-failed: --- End Message --- --- Begin Message --- On 2016-06-07 13:23, John Comeau wrote: > Package: libc6 > Version: 2.13-38+deb7u11 > Severity: important > > Dear Maintainer, > > After an `apt-get upgrade` on a Debian stable system running with Upstart > as /sbin/init, `initctl list` no longer works, giving me the error "Failed > to connect to socket /com/ubuntu/upstart: Connection refused". Running > `lsof -p1` shows a number of the linked libraries were deleted and overwritten > during the libc6 upgrade. > > root@vps39987:~# lsof -p1 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE
Bug#945888: The nscd daemon use a wrong path to open cache files
On 2020-02-08 17:57, Aurelien Jarno wrote: > On 2019-11-30 16:00, André Rodier wrote: > > Package: nscd > > Version: 2.28-10 > > > > When using AppArmor and ldap for users database, and nscd on Debian, a > > lot of errors are visible in the AppArmor logs, when any program > > queries nscd. > > > > The nscd daemon tries to open files in "var/cache/nscd/..." instead of > > "/var/cache/nscd/...". Note the missing slash character at the > > beginning. AppArmor complains about the file access denied, but the > > error is really a missing '/' character in the path of the cache files. > > What makes you believe that? I have just tried with strace, and I see > the correct path with the leading '/': > > openat(AT_FDCWD, "/var/cache/nscd/passwd", O_RDWR|O_CLOEXEC) = 4 > openat(AT_FDCWD, "/var/cache/nscd/passwd", O_RDONLY|O_CLOEXEC) = 5 > openat(AT_FDCWD, "/var/cache/nscd/group", O_RDWR|O_CLOEXEC) = 6 > openat(AT_FDCWD, "/var/cache/nscd/group", O_RDONLY|O_CLOEXEC) = 7 > openat(AT_FDCWD, "/var/cache/nscd/hosts", O_RDWR|O_CLOEXEC) = 8 > openat(AT_FDCWD, "/var/cache/nscd/hosts", O_RDONLY|O_CLOEXEC) = 9 > openat(AT_FDCWD, "/var/cache/nscd/services", O_RDWR|O_CLOEXEC) = 10 > openat(AT_FDCWD, "/var/cache/nscd/services", O_RDONLY|O_CLOEXEC) = 11 > openat(AT_FDCWD, "/var/cache/nscd/netgroup", O_RDWR|O_CLOEXEC) = 12 > openat(AT_FDCWD, "/var/cache/nscd/netgroup", O_RDONLY|O_CLOEXEC) = 13 Any news about that? Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#966173: marked as done (libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm)
Your message dated Sat, 4 Sep 2021 21:53:54 +0200 with message-id and subject line Re: Bug#966173: libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm has caused the Debian Bug report #966173, regarding libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 966173: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966173 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.31-1 Severity: normal I've encountered an odd bug in openarena (#966150) which I'm concerned might be a glibc regression affecting other packages. Some background: openarena is a game running on the ioquake3 engine (main executable: /usr/lib/ioquake3/ioquake3). During startup, the engine dlopens some modules, which implement the actual openarena game and UI. One of those modules is uix86_64.so. uix86_64.so uses mathematical functions from libm, but is not itself linked to libm. At runtime (at least on older systems) it works as intended, because the ioquake3 executable *is* linked to libm. I'm aware that this is not the most robust setup, and uix86_64.so would ideally be linked with -lm to make it self-contained; but it's documented as being expected to work, and has always worked in the past: Symbol references in the shared object are resolved using (in order): symbols in the link map of objects loaded for the main program and its dependencies; [... and some more places ...] — dlopen(3) The bug (#966150) is that a version of uix86_64.so compiled with a slightly older (2020-02-18) toolchain fails to load on an up-to-date sid system, with: undefined symbol: __atan2_finite If I recompile openarena in a sid chroot, *with no source code changes* (in particular uix86_64.so is still not linked to -lm!), then it starts to work again. The recompiled uix86_64.so has an undefined reference to atan2, but no reference to __atan2_finite any more. I'm going to address this in bullseye by making openarena more robust (explicitly linking to -lm). After I've done that, the updated version of openarena will not be suitable as a reproducer for this bug report, but the buster version of openarena will still be suitable. If you believe this is not a significant regression in glibc and should only be fixed by changes in openarena, I have no problem with doing that and just closing this bug report. However, I wanted to raise this in case it affects other previously-built binaries. This can be reproduced somewhat conveniently as follows: * Have a buster virtual machine * Install openarena and enough of a desktop to get a terminal in an X11 environment * Run openarena * It succeeds * To exit quickly: Shift+Escape, type "/quit", Enter * Add a bullseye apt source and "apt update", but do not upgrade everything * Upgrade libc6 from 2.28-10 to 2.31-1, while upgrading as few other packages as possible * I used aptitude, which made me also upgrade gcc-9 and related packages, removing gcc-8 * Run openarena * It fails as described in #966150 * Downgrade libc6 and closely-related packages from 2.31-1 to 2.28-10 * In my case this meant downgrading libc-dev-bin, libc6-dev, libc6 and libc-bin, and removing libcrypt-dev and libcrypt1 * Run openarena * It succeeds again, confirming that this was a glibc behaviour change I've been trying to put together a standalone reproducer that only uses libdl and libm, but so far I have not been successful. I believe this is related to a change in the representation of the __atan2_finite symbol, which is used (at least by versions of openarena compiled against older glibc) because openarena is compiled with -ffast-math. In 2.28-10, that symbol was not hidden: $ objdump -Tx /lib/x86_64-linux-gnu/libm.so.6 ... 00028280 g iD .text 0046 GLIBC_2.15 __atan2_finite In 2.31-1, it is hidden, and there is no non-hidden definition (default symbol-version): $ objdump -Tx /lib/x86_64-linux-gnu/libm.so.6 ... 0002a1e0 g iD .text 0049 (GLIBC_2.15) __atan2_finite Because uix86_64.so is not directly linked to -lm, it has an undefined reference to __atan2_finite with no particular version: $ objdump -Tx /usr/lib/openarena/baseoa/pak6-patch088/uix86_64.so ... D *UND* __atan2_finite As far as I can work out, this unversioned undefined reference can be satisfied by __atan2_finite@@GLIBC_2.15 in the global
[Git][glibc-team/glibc][glibc-2.32] 11 commits: debian/changelog: whitespace fixes
Aurelien Jarno pushed to branch glibc-2.32 at GNU Libc Maintainers / glibc Commits: 18fbdadc by Aurelien Jarno at 2021-09-04T17:41:01+02:00 debian/changelog: whitespace fixes - - - - - 31126816 by Aurelien Jarno at 2021-09-04T17:46:47+02:00 debian/rules, rules.d/build.mk, rules.d/debhelper.mk, debian/libc*.symbols*, debhelper.in/*install*: drop support for building with libcrypt now that the transition has been done in bullseye. - - - - - 64a25ee0 by Aurelien Jarno at 2021-09-04T18:42:10+02:00 debian/libc6.symbols.hppa: drop symbol overrides for linuxthreads - NPTL transition. - - - - - 0cbdfb17 by Aurelien Jarno at 2021-09-04T18:43:10+02:00 debian/libc6.symbols.sparc, debian/libc6-sparc.symbols.sparc64: drop symbol overrides for SPARCV8 - SPARCV8PLUS ABI transition. - - - - - d81f0b60 by Aurelien Jarno at 2021-09-04T18:43:53+02:00 debian/libc6.symbols.arm: drop file, the arm architecture is not supported anymore for quite some time. - - - - - 32fc7f94 by Aurelien Jarno at 2021-09-04T18:43:54+02:00 debian/libc6.symbols.armel, debian/libc6.symbols.armhf: drop symbol overrides for make/get/set/swapcontext. - - - - - 5f5dfcb0 by Aurelien Jarno at 2021-09-04T19:59:48+02:00 debian/libc6-i386.symbols.x32, debian/libc6.symbols.i386: drop symbol overrides for TLS support. - - - - - fc9be287 by Aurelien Jarno at 2021-09-04T19:59:48+02:00 debian/libc6.symbols.powerpc: drop symbol overrides for TLS support. - - - - - d3f9fade by Aurelien Jarno at 2021-09-04T19:59:48+02:00 debian/libc6.symbols.mips, debian/libc6.symbols.mipsel: drop symbol overrides for TLS support. - - - - - a046e800 by Aurelien Jarno at 2021-09-04T21:11:44+02:00 debian/rules.d/debhelper.mk: drop workaround for an old dpkg-shlibdeps bugs (see #433723). - - - - - 331bb702 by Aurelien Jarno at 2021-09-04T21:15:37+02:00 debian/debhelper.in/libc-dev.install, debian/debhelper.in/libc.install, debian/control.in/libc: move sotruss-lib.so from libc6 to libc6-dev. Closes: #976133. - - - - - 27 changed files: - debian/changelog - debian/control - debian/control.in/libc - debian/debhelper.in/libc-dev-alt.install - debian/debhelper.in/libc-dev.install - debian/debhelper.in/libc-dev.install.hurd-i386 - debian/debhelper.in/libc-udeb.install - debian/debhelper.in/libc-udeb.install.hurd-i386 - debian/debhelper.in/libc.install - debian/libc0.1.symbols.common - debian/libc0.3.symbols.hurd-i386 - debian/libc6-i386.symbols.x32 - debian/libc6-sparc.symbols.sparc64 - debian/libc6.1.symbols.alpha - − debian/libc6.symbols.arm - debian/libc6.symbols.armel - debian/libc6.symbols.armhf - debian/libc6.symbols.common - debian/libc6.symbols.hppa - debian/libc6.symbols.i386 - debian/libc6.symbols.mips - debian/libc6.symbols.mipsel - debian/libc6.symbols.powerpc - debian/libc6.symbols.sparc - debian/rules - debian/rules.d/build.mk - debian/rules.d/debhelper.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/compare/8af0959b7d8dca7ecf58c975ab736f5263ad0dee...331bb702600840c345d804fe689e0d402dc5ad05 -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/compare/8af0959b7d8dca7ecf58c975ab736f5263ad0dee...331bb702600840c345d804fe689e0d402dc5ad05 You're receiving this email because of your account on salsa.debian.org.
Bug#536085: marked as done (locales: ru_RU.UTF8 collate UKR-GHE incorrectly)
Your message dated Sat, 4 Sep 2021 21:46:05 +0200 with message-id and subject line Bug#536085: locales: ru_RU.UTF8 collate UKR-GHE incorrectly has caused the Debian Bug report #536085, regarding locales: ru_RU.UTF8 collate UKR-GHE incorrectly to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 536085: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536085 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: locales Version: 2.9-12 Severity: normal ru_RU.UTF8 locale collate UKR-GHE (U0491 and U0490) incorrectly, here is example: wrong: seb@seb:~$ (export LANG=ru_RU.UTF-8; echo "абвгґдеєжзиіїйклмнопрстуфхцчшщьюя" | sed -e 's/\(.\)/\1\n/g' | sort | head) а б в г д ґ е є ж correct: seb@seb:~$ (export LANG=uk_UA.UTF-8; echo "абвгґдеєжзиіїйклмнопрстуфхцчшщьюя" | sed -e 's/\(.\)/\1\n/g' | sort | head) а б в г ґ д е є ж correct: seb@seb:~$ (export LANG=en_US.UTF-8; echo "абвгґдеєжзиіїйклмнопрстуфхцчшщьюя" | sed -e 's/\(.\)/\1\n/g' | sort | head) а б в г ґ д е є ж -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (70, 'unstable'), (65, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii libc6 [glibc-2.9-1] 2.9-4 GNU C Library: Shared libraries locales recommends no packages. locales suggests no packages. -- debconf information: * locales/default_environment_locale: ru_RU.UTF-8 * locales/locales_to_be_generated: en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, en_GB.UTF-8 UTF-8, en_US ISO-8859-1, en_US.ISO-8859-15 ISO-8859-15, en_US.UTF-8 UTF-8, ru_RU ISO-8859-5, ru_RU.CP1251 CP1251, ru_RU.KOI8-R KOI8-R, ru_RU.UTF-8 UTF-8, ru_UA.UTF-8 UTF-8, uk_UA.UTF-8 UTF-8 --- End Message --- --- Begin Message --- Version: 2.27-0experimental0 On 2009-07-07 18:01, Sergey Burladyan wrote: > Package: locales > Version: 2.9-12 > Severity: normal > > > ru_RU.UTF8 locale collate UKR-GHE (U0491 and U0490) incorrectly, here is > example: > > wrong: > seb@seb:~$ (export LANG=ru_RU.UTF-8; echo "абвгґдеєжзиіїйклмнопрстуфхцчшщьюя" > | sed -e 's/\(.\)/\1\n/g' | sort | head) > > а > б > в > г > д > ґ > е > є > ж > > correct: > seb@seb:~$ (export LANG=uk_UA.UTF-8; echo "абвгґдеєжзиіїйклмнопрстуфхцчшщьюя" > | sed -e 's/\(.\)/\1\n/g' | sort | head) > > а > б > в > г > ґ > д > е > є > ж > > correct: > seb@seb:~$ (export LANG=en_US.UTF-8; echo "абвгґдеєжзиіїйклмнопрстуфхцчшщьюя" > | sed -e 's/\(.\)/\1\n/g' | sort | head) > > а > б > в > г > ґ > д > е > є > ж This bug has been fixed in the following upstream commit that went into glibc 2.27: https://sourceware.org/git/?p=glibc.git;a=commit;h=159738548130d5ac4fe6178977e940ed5f8cfdc4 Closing the bug accordingly. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#854007: marked as done (libc6: crash during thread exit when using thread local storage)
Your message dated Sat, 4 Sep 2021 21:24:39 +0200 with message-id and subject line Re: libc6: crash during thread exit when using thread local storage has caused the Debian Bug report #854007, regarding libc6: crash during thread exit when using thread local storage to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 854007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854007 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.19-18+deb8u7 Severity: normal Tags: upstream patch Dear Maintainer, An application we develop crashes on exit with: *** Error in `foo': free(): invalid pointer: 0x09309bc0 *** This issue occurs when there are a large number of threads running which use thread local storage. We have identified the issue as an existing upstream glibc bug, #13862. This bug was fixed in glibc-2.21. See https://sourceware.org/bugzilla/show_bug.cgi?id=13862. The upstream bug report has a reproducer which reliably reproduces the problem. I have backported the upstream patch to glibc 2.19, based on the patch made by Red Hat and CentOS for their bug https://bugzilla.redhat.com/show_bug.cgi?id=1238778. I additionally applied the patch for upstream TLS-related glibc bugs 17090, 17620, 17621, and 17628, which is the same set of patches Red Hat backported for their fix to glibc-2.17. After rebuilding glibc-2.19-18+deb8u7 with the attached patches, the issue no longer occurs. Given that Debian 8 still has several years of support left, can these patches be added to Debian's build? Thanks, Mike -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (500, 'stable'), (300, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.4.0-0.bpo.tmw1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) >From 439e927dd88e2cd0d2b4b956d5db4f4a13b9f8d7 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Fri, 28 Nov 2014 07:54:07 -0800 Subject: [PATCH] Resize DTV if the current DTV isn't big enough This patch changes _dl_allocate_tls_init to resize DTV if the current DTV isn't big enough. Tested on X86-64, x32 and ia32. [BZ #13862] * elf/dl-tls.c: Include . (oom): Remove #ifdef SHARED/#endif. (_dl_static_dtv, _dl_initial_dtv): Moved before ... (_dl_resize_dtv): This. Extracted from _dl_update_slotinfo. (_dl_allocate_tls_init): Resize DTV if the current DTV isn't big enough. (_dl_update_slotinfo): Call _dl_resize_dtv to resize DTV. * nptl/Makefile (tests): Add tst-stack4. (modules-names): Add tst-stack4mod. ($(objpfx)tst-stack4): New. (tst-stack4mod.sos): Likewise. ($(objpfx)tst-stack4.out): Likewise. ($(tst-stack4mod.sos)): Likewise. (clean): Likewise. * nptl/tst-stack4.c: New file. * nptl/tst-stack4mod.c: Likewise. (cherry picked from commit d8dd00805b8f3a011735d7a407097fb1c408d867) * Modified to avoid use of atomic_load_acquire, based on RH glibc patch glibc-rh1189278.patch. --- ChangeLog| 20 +++ elf/dl-tls.c | 105 +- nptl/Makefile| 17 +- nptl/tst-stack4.c| 159 +++ nptl/tst-stack4mod.c | 28 + 5 files changed, 286 insertions(+), 43 deletions(-) create mode 100644 nptl/tst-stack4.c create mode 100644 nptl/tst-stack4mod.c diff --git a/ChangeLog b/ChangeLog index 92b8a2e..a1861d1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,23 @@ +2014-11-28 H.J. Lu + + [BZ #13862] + * elf/dl-tls.c: Include . + (oom): Remove #ifdef SHARED/#endif. + (_dl_static_dtv, _dl_initial_dtv): Moved before ... + (_dl_resize_dtv): This. Extracted from _dl_update_slotinfo. + (_dl_allocate_tls_init): Resize DTV if the current DTV isn't + big enough. + (_dl_update_slotinfo): Call _dl_resize_dtv to resize DTV. + * nptl/Makefile (tests): Add tst-stack4. + (modules-names): Add tst-stack4mod. + ($(objpfx)tst-stack4): New. + (tst-stack4mod.sos): Likewise. + ($(objpfx)tst-stack4.out): Likewise. + ($(tst-stack4mod.sos)): Likewise. + (clean): Likewise. + * nptl/tst-stack4.c: New file. + * nptl/tst-stack4mod.c: Likewise. + 2015-01-28 Adhemerval Zanellla [BZ #16576] diff --git a/elf/dl-tls.c b/elf/dl-tls.c index dbaea0a..c148c54 100644 --- a/elf/dl-tls.c +++ b/elf/dl-tls.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include @@ -34,14 +35,12 @@ /* Out-of-memory handler. */ -#ifdef SHARED static void __attribute__
Bug#890138: marked as done (glibc: Allow to not build Xen packages)
Your message dated Sat, 4 Sep 2021 21:19:30 +0200 with message-id and subject line Bug#890138: Allow to not build Xen packages has caused the Debian Bug report #890138, regarding glibc: Allow to not build Xen packages to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 890138: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890138 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: glibc Version: 2.26-6 Severity: wishlist X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, aurel...@aurel32.net, sthiba...@debian.org Please consider adding a pkg/glibc/noxen build profile to skip building Xen files. smime.p7s Description: S/MIME cryptographic signature --- End Message --- --- Begin Message --- Version: 2.32-0experimental1 On 2018-02-11 14:47, Javier Serrano Polo wrote: > Source: glibc > Version: 2.26-6 > Severity: wishlist > X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, aurel...@aurel32.net, > sthiba...@debian.org > > Please consider adding a pkg/glibc/noxen build profile to skip building > Xen files. Since glibc version 2.32-0experimental1, xen packages are not built anymore, making this bug obsolete. Closing it. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Re: Preparing for glibc 2.34: library locations
Hi,
On 2021-07-15 11:11, Michael Hudson-Doyle wrote:
> Hi,
>
> I know it won't be relevant to Debian for a while, but we're planning to
> upload to the upcoming glibc 2.34 release in Ubuntu fairly soon and I want
> to make sure we adapt to an upstream way in a way that is aligned with any
> plans for Debian.
>
> The issue is this: 2.33 and previous releases install the dynamic linker
> and libc as files with names like ld-${GLIBC_VERSION}.so and
> libc-${GLIBC_VERSION}.so and makes symlinks from the SONAME to these files
> (for example ld-linux-x86-64.so.2 -> ld-2.31.so, libc.so.6 -> libc-2.31.so).
> 2.34 and later will just install the libraries directly to the SONAME
> location.
>
> There is another wrinkle of course in that Debian/Ubuntu install these
> files to /lib/$multiarch/, not /lib or /lib64 as upstream expects.
>
> What I've implemented[0] for Ubuntu (only for testing so far) is to install
> libc to /lib/$multiarch/libc.so.6, the dynamic linker to
> /lib/$multiarch/$dynamic_linker_soname, and then have a symlink from the
> ABI-mandated dynamic linker path to the new path for the dynamic linker.
> This feels like a reasonable compromise between the upstream changes and
> what Debian does to me but I'm certainly interested in hearing other
> opinions (ideally before Ubuntu feature freeze :-p).
I think all the issues above are not really due to multiarch, but are
created by the local-rtlddir-cross.diff patch that we have dropped in
Debian as it introduces many issues. This makes the cross-toolchain-base
maintainer unhappy, but I do not think we should introduce complexity in
the libc6 package just to make dpkg-cross simpler.
With that patch dropped, there is no symlink to add, you can just use
the upstream makefile do their jobs. The dynamic linker is installed
directly in the ABI-mandated dynamic linker and there is no need for
symlinks.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
