[glibc] branch sid updated (e5d4f5d -> 3c1709f)
This is an automated email from the git hooks/post-receive script. sthibault pushed a change to branch sid in repository glibc. from e5d4f5d new changelog entry new 3c1709f hurd: work around fakeroot-tcp issue The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: debian/changelog | 4 +- .../hurd-i386/tg-libc_rwlock_recursive.diff| 67 ++ debian/patches/series | 1 + 3 files changed, 71 insertions(+), 1 deletion(-) create mode 100644 debian/patches/hurd-i386/tg-libc_rwlock_recursive.diff -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-glibc/glibc.git
[glibc] branch sid updated (cbbadae -> e5d4f5d)
This is an automated email from the git hooks/post-receive script. sthibault pushed a change to branch sid in repository glibc. from cbbadae releasing package glibc version 2.24-7 new e5d4f5d new changelog entry The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: debian/changelog | 6 ++ 1 file changed, 6 insertions(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-glibc/glibc.git
[glibc] 01/01: hurd: work around fakeroot-tcp issue
This is an automated email from the git hooks/post-receive script. sthibault pushed a commit to branch sid in repository glibc. commit 3c1709fb5378514a177b474a3911c0d50da9c1b0 Author: Samuel Thibault Date: Sun Nov 27 02:21:24 2016 +0100 hurd: work around fakeroot-tcp issue * hurd-i386/tg-libc_rwlock_recursive.diff: New patch, see #845930. --- debian/changelog | 4 +- .../hurd-i386/tg-libc_rwlock_recursive.diff| 67 ++ debian/patches/series | 1 + 3 files changed, 71 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 936ee75..8a468d3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,8 @@ glibc (2.24-8) UNRELEASED; urgency=medium - * + [ Samuel Thibault ] + * hurd-i386/tg-libc_rwlock_recursive.diff: New patch to work around +fakeroot-tcp issue, see #845930. -- Aurelien Jarno Fri, 25 Nov 2016 23:09:39 +0100 diff --git a/debian/patches/hurd-i386/tg-libc_rwlock_recursive.diff b/debian/patches/hurd-i386/tg-libc_rwlock_recursive.diff new file mode 100644 index 000..c6410d5 --- /dev/null +++ b/debian/patches/hurd-i386/tg-libc_rwlock_recursive.diff @@ -0,0 +1,67 @@ +From: Samuel Thibault +Subject: [PATCH] XXX: make libc_rwlock recursive + +Without making the rwlocks recursive, running fakeroot-tcp gets this: + +#0 0x0106e91c in mach_msg_trap () at /usr/src/glibc-2.24/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x0106f090 in __mach_msg (msg=0x20034a0, option=3, send_size=64, rcv_size=32, rcv_name=421, timeout=0, notify=0) at msg.c:110 +#2 0x0125a241 in __gsync_wait (task=1, addr=19101080, val1=2, val2=0, msec=0, flags=0) +at /usr/src/glibc-2.24/build-tree/hurd-i386-libc/mach/RPC_gsync_wait.c:175 +#3 0x010b0743 in __dcigettext (domainname=0x8050740 <_libc_intl_domainname@@GLIBC_2.2.6> "libc", +msgid1=0x8051d88 "undefined symbol: acl_get_fd", msgid2=0x0, plural=0, n=0, category=5) at dcigettext.c:527 +#4 0x010af776 in __dcgettext (domainname=0x8050740 <_libc_intl_domainname@@GLIBC_2.2.6> "libc", +msgid=0x8051d88 "undefined symbol: acl_get_fd", category=5) at dcgettext.c:47 +#5 0x0124e427 in __dlerror () at dlerror.c:94 +#6 0x01035ae3 in load_library_symbols () from /usr/lib/i386-gnu/libfakeroot/libfakeroot-tcp.so +#7 0x01035cc3 in tmp___fxstat64 () from /usr/lib/i386-gnu/libfakeroot/libfakeroot-tcp.so +#8 0x01036cd6 in __fxstat64 () from /usr/lib/i386-gnu/libfakeroot/libfakeroot-tcp.so +#9 0x010ad831 in _nl_load_locale_from_archive (category=category@entry=0, namep=namep@entry=0x200399c) at loadarchive.c:211 +#10 0x010ac45b in _nl_find_locale (locale_path=0x0, locale_path_len=0, category=category@entry=0, name=0x200399c) at findlocale.c:154 +#11 0x010abde7 in setlocale (category=0, locale=0x804c2e4 "") at setlocale.c:417 +#12 0x0804947f in main (argc=2, argv=0x2003ad4) at programs/locale.c:191 + +That's very unfortunate: libfakeroot gets initialized from a section +where __libc_setlocale_lock is already locked, and thus the dlerror() +call hangs inside __dcigettext. It happens that Linux doesn't have +the problem probably because pthread_rwlock_wrlock returns a EDEADLK +error instead of hanging, and then the first unlock unlocks, and the +second unlock probably returns an EINVAL. This is all very unsafe, but +that's fakeroot-tcp's matter (see http://bugs.debian.org/845930 for the +follow-up)... + +We only use it when constructing the debian installer for -s -r options +anyway. + +Signed-off-by: Samuel Thibault + +--- + sysdeps/mach/libc-lock.h | 18 +- + 1 file changed, 9 insertions(+), 9 deletions(-) + +--- a/sysdeps/mach/libc-lock.h b/sysdeps/mach/libc-lock.h +@@ -151,15 +151,15 @@ typedef cthread_key_t __libc_key_t; + __libc_lock_unlock_recursive (NAME) + + /* XXX for now */ +-#define __libc_rwlock_define __libc_lock_define +-#define __libc_rwlock_define_initialized __libc_lock_define_initialized +-#define __libc_rwlock_init__libc_lock_init +-#define __libc_rwlock_fini__libc_lock_fini +-#define __libc_rwlock_rdlock __libc_lock_lock +-#define __libc_rwlock_wrlock __libc_lock_lock +-#define __libc_rwlock_tryrdlock __libc_lock_trylock +-#define __libc_rwlock_trywrlock __libc_lock_trylock +-#define __libc_rwlock_unlock __libc_lock_unlock ++#define __libc_rwlock_define __libc_lock_define_recursive ++#define __libc_rwlock_define_initialized __libc_lock_define_initialized_recursive ++#define __libc_rwlock_init__libc_lock_init_recursive ++#define __libc_rwlock_fini__libc_lock_fini_recursive ++#define __libc_rwlock_rdlock __libc_lock_lock_recursive ++#define __libc_rwlock_wrlock __libc_lock_lock_recursive ++#define __libc_rwlock_tryrdlock __libc_lock_trylock_recursive ++#define __libc_rwlock_trywrlock __li
[glibc] 01/01: new changelog entry
This is an automated email from the git hooks/post-receive script. sthibault pushed a commit to branch sid in repository glibc. commit e5d4f5df7c48e55f48e80e361f457490b88610a3 Author: Samuel Thibault Date: Sun Nov 27 02:18:37 2016 +0100 new changelog entry --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index a362694..936ee75 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +glibc (2.24-8) UNRELEASED; urgency=medium + + * + + -- Aurelien Jarno Fri, 25 Nov 2016 23:09:39 +0100 + glibc (2.24-7) unstable; urgency=medium [ Samuel Thibault ] -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-glibc/glibc.git
Bug#845721: Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist
Thanks Adam + Aurelien, On Saturday, November 26, 2016 3:11:21 PM CST Aurelien Jarno wrote: > On 2016-11-26 11:02, Adam D. Barratt wrote: > > On Sat, 2016-11-26 at 01:02 -0600, Steve M. Robbins wrote: > > > I don't know how to make sense of these "breaks" versions. libc6 > > > doesn't even have a revision -7. Should both of those be > > > "breaks ... != 2.24-6"? > > > > -7 was uploaded a little over 10 hours ago. Looking at the dak log that > > would make sense in terms of what you're seeing - the amd64 build of -7 > > made it into the 0152UTC dinstall by a few minutes, so would have been > > available on mirrors when you filed this report, with the i386 build > > being part of the subsequent 0752 dinstall. Seems I was a victim of timing! I checked the PTS when filing the bug and there was no trace of -7 that I could see. All is well now. Thanks again, -Steve signature.asc Description: This is a digitally signed message part.
Bug#845721: marked as done (Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist)
Your message dated Sat, 26 Nov 2016 15:11:21 +0100 with message-id <20161126141121.u2qbvmrst7rea...@aurel32.net> and subject line Re: Bug#845721: Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist has caused the Debian Bug report #845721, regarding Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist 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.) -- 845721: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845721 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.24-7 Severity: normal Tried to install libc6:i386 but cannot. $ sudo apt-get install libc6:i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: cli-common : Depends: perl but it is not going to be installed libc6 : Breaks: libc6:i386 (!= 2.24-7) but 2.24-5 is to be installed libc6:i386 : Breaks: libc6 (!= 2.24-5) but 2.24-7 is to be installed [...] I don't know how to make sense of these "breaks" versions. libc6 doesn't even have a revision -7. Should both of those be "breaks ... != 2.24-6"? -Steve -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libc6 depends on: ii libgcc1 1:6.2.1-5 libc6 recommends no packages. Versions of packages libc6 suggests: ii cdebconf [debconf-2.0] 0.219 ii debconf [debconf-2.0] 1.5.59 ii glibc-doc 2.24-7 ii libc-l10n 2.24-7 ii locales 2.24-7 -- debconf information: * glibc/disable-screensaver: glibc/kernel-too-old: * glibc/upgrade: true * glibc/restart-services: spamassassin samba openbsd-inetd exim4 cron atd apache2 glibc/kernel-not-supported: glibc/restart-failed: * libraries/restart-without-asking: true --- End Message --- --- Begin Message --- On 2016-11-26 11:02, Adam D. Barratt wrote: > On Sat, 2016-11-26 at 01:02 -0600, Steve M. Robbins wrote: > > The following packages have unmet dependencies: > > cli-common : Depends: perl but it is not going to be installed > > libc6 : Breaks: libc6:i386 (!= 2.24-7) but 2.24-5 is to be installed > > libc6:i386 : Breaks: libc6 (!= 2.24-5) but 2.24-7 is to be installed > > [...] > > That normally means that apt is seeing libc6 2.24-7 as available on > amd64 and 2.24-5 as available on i386 and is refusing to install the > combination, as they're different versions and libc6 is marked > Multi-Arch:same. > > > I don't know how to make sense of these "breaks" versions. libc6 > > doesn't even have a revision -7. Should both of those be > > "breaks ... != 2.24-6"? > > -7 was uploaded a little over 10 hours ago. Looking at the dak log that > would make sense in terms of what you're seeing - the amd64 build of -7 > made it into the 0152UTC dinstall by a few minutes, so would have been > available on mirrors when you filed this report, with the i386 build > being part of the subsequent 0752 dinstall. glibc version 2.24-7 is now available on the mirrors for both amd64 and i386. I am therefore closing the bug. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#845721: Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist
On Sat, 2016-11-26 at 01:02 -0600, Steve M. Robbins wrote: > The following packages have unmet dependencies: > cli-common : Depends: perl but it is not going to be installed > libc6 : Breaks: libc6:i386 (!= 2.24-7) but 2.24-5 is to be installed > libc6:i386 : Breaks: libc6 (!= 2.24-5) but 2.24-7 is to be installed > [...] That normally means that apt is seeing libc6 2.24-7 as available on amd64 and 2.24-5 as available on i386 and is refusing to install the combination, as they're different versions and libc6 is marked Multi-Arch:same. > I don't know how to make sense of these "breaks" versions. libc6 > doesn't even have a revision -7. Should both of those be > "breaks ... != 2.24-6"? -7 was uploaded a little over 10 hours ago. Looking at the dak log that would make sense in terms of what you're seeing - the amd64 build of -7 made it into the 0152UTC dinstall by a few minutes, so would have been available on mirrors when you filed this report, with the i386 build being part of the subsequent 0752 dinstall. Regards, Adam
