[glibc] branch glibc-2.22 updated (ab1f88f -> ca03255)

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a change to branch glibc-2.22
in repository glibc.

  from  ab1f88f   new changelog entry
   new  ca03255   debian/testsuite-xfail-debian.mk (alpha): mark a few 
failures which are not a regression compare to 2.21 as xfail.

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 | 3 ++-
 debian/testsuite-xfail-debian.mk | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

[glibc] 01/01: debian/testsuite-xfail-debian.mk (alpha): mark a few failures which are not a regression compare to 2.21 as xfail.

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch glibc-2.22
in repository glibc.

commit ca03255cb35776a2a32d3aebcdc89a30d756fc1f
Author: Aurelien Jarno 
Date:   Sun Mar 6 01:26:28 2016 +0100

debian/testsuite-xfail-debian.mk (alpha): mark a few failures which are not 
a regression compare to 2.21 as xfail.
---
 debian/changelog | 3 ++-
 debian/testsuite-xfail-debian.mk | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index f34aaa1..f104647 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 glibc (2.22-0experimental4) UNRELEASED; urgency=medium
 
-  * 
+  * debian/testsuite-xfail-debian.mk (alpha): mark a few failures which
+are not a regression compare to 2.21 as xfail.
 
  -- Aurelien Jarno   Tue, 01 Mar 2016 21:37:40 +0100
 
diff --git a/debian/testsuite-xfail-debian.mk b/debian/testsuite-xfail-debian.mk
index d956a90..92a069b 100644
--- a/debian/testsuite-xfail-debian.mk
+++ b/debian/testsuite-xfail-debian.mk
@@ -15,9 +15,12 @@ test-xfail-tst-cancel24-static = yes
 # alpha (including optimized flavours)
 ##
 ifneq (,$(filter $(config-machine)-$(config-os), alpha-linux-gnu 
alphaev67-linux-gnu))
+test-xfail-tst-backtrace5 = yes
+test-xfail-tst-backtrace6 = yes
 test-xfail-check-localplt = yes
 test-xfail-test-double = yes
 test-xfail-test-float = yes
+test-xfail-test-fenv-return = yes
 test-xfail-test-snan = yes
 test-xfail-tst-eintr1 = yes
 test-xfail-tst-mqueue5 = yes

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Processed: "LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 /lib/ld-linux.so.2" segfaults on some Go programs

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + adequate
Bug #816833 [libc6] "LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 
/lib/ld-linux.so.2" segfaults on some Go programs
Added indication that 816833 affects adequate

-- 
816833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816833
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#816833: "LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 /lib/ld-linux.so.2" segfaults on some Go programs

[Jakub Wilk]

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#816802: tzdata: hwclock not set properly when "tzdata-2016a-1" is installed

[Aurelien Jarno]

On 2016-03-05 14:32, Aurelien Jarno wrote:
> > I downgraded to "tzdata-2015g-0+deb8u1", and it behaved the expected way: 
> > the
> > system clock is set to UTC after reboot when reading the local time from the
> > hardware clock.
> 
> Indeed we have changed /etc/localtime into a symlink in version 2016a-1.
> It was previously a copy a file from /usr/share/zoneinfo to handle the
> case where /usr is a separate partition. The change was requested in bug
> #803144 [1], given that /usr is now mounted in the initramfs. I have
> added Martin Pitt in Cc so he can comment on that.

I have been pointed that it is true when using sysvinit only in recent
versions of initramfs-tools. Which version of initramfs-tools have you
installed on your system? You should have at least version 0.121.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Processed: Bug#814073: tzdata: FTBFS: Error: Unable to access jarfile /usr/lib/jvm/default-java//jre/lib/javazic.jar

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 814073 openjdk-8-jre-headless
Bug #814073 [src:tzdata] tzdata: FTBFS: Error: Unable to access jarfile 
/usr/lib/jvm/default-java//jre/lib/javazic.jar
Bug reassigned from package 'src:tzdata' to 'openjdk-8-jre-headless'.
No longer marked as found in versions tzdata/2016a-1.
Ignoring request to alter fixed versions of bug #814073 to the same values 
previously set
> retitle 814073 openjdk-8-jre-headless doesn't provide javazic.jar
Bug #814073 [openjdk-8-jre-headless] tzdata: FTBFS: Error: Unable to access 
jarfile /usr/lib/jvm/default-java//jre/lib/javazic.jar
Changed Bug title to 'openjdk-8-jre-headless doesn't provide javazic.jar' from 
'tzdata: FTBFS: Error: Unable to access jarfile 
/usr/lib/jvm/default-java//jre/lib/javazic.jar'
> affect 814073 tzdata
Bug #814073 [openjdk-8-jre-headless] openjdk-8-jre-headless doesn't provide 
javazic.jar
Added indication that 814073 affects tzdata
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
814073: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814073
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#816742: libc6: sem_post/sem_wait not working for 32bit to 64bit inter-process communication

[Carlos O'Donell]

On Sat, Mar 5, 2016 at 7:28 AM, Aurelien Jarno  wrote:
> control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=17980

Semaphore interoperability between two different ABIs has never been
supported. It worked because you were lucky and the implementation was
flawed. To fix the implementation flaws (which are real), we've had to
adopt slightly different algorithms for 32-bit and 64-bit.

Cheers,
Carlos.

Bug#816802: tzdata: hwclock not set properly when "tzdata-2016a-1" is installed

[Aurelien Jarno]

On 2016-03-05 13:42, Christophe Schockaert wrote:
> Package: tzdata
> Version: 2016a-1
> Severity: normal
> 
> Hi,
> 
> 
> I lately upgraded my system to current Strech.
> 
> Since that day, my clock is set one hour in advance after each reboot.
> The proper settings are in "/etc/adjtime", i.e. "LOCAL".
> The link "/etc/localtime" is set to my timzeone
> "/usr/share/zoneinfo/Europe/Paris".
> When I run "hwclock -s" manually after boot, system time is set accordingly to
> the local time from the hw clock.
> 
> The incorrect time happens to be applied when running "/lib/udev/hwclock-set",
> the timezone info does not seem to be available or used at that time, and then
> hwclock sets the system to UTC from the hardware clock, which is read as UTC
> eventhough it is registered as "LOCAL" in "/etc/adjtime". So, my UTC system
> time is one hour in advance, since my hardware clock is at CET, i.e. UTC+1.

Do you have an idea why it is not available? 

> I downgraded to "tzdata-2015g-0+deb8u1", and it behaved the expected way: the
> system clock is set to UTC after reboot when reading the local time from the
> hardware clock.

Indeed we have changed /etc/localtime into a symlink in version 2016a-1.
It was previously a copy a file from /usr/share/zoneinfo to handle the
case where /usr is a separate partition. The change was requested in bug
#803144 [1], given that /usr is now mounted in the initramfs. I have
added Martin Pitt in Cc so he can comment on that.

On your side, do you use a separate /usr partition?

Aurelien

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803144

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#816802: tzdata: hwclock not set properly when "tzdata-2016a-1" is installed

[Christophe Schockaert]

Package: tzdata
Version: 2016a-1
Severity: normal

Hi,


I lately upgraded my system to current Strech.

Since that day, my clock is set one hour in advance after each reboot.
The proper settings are in "/etc/adjtime", i.e. "LOCAL".
The link "/etc/localtime" is set to my timzeone
"/usr/share/zoneinfo/Europe/Paris".
When I run "hwclock -s" manually after boot, system time is set accordingly to
the local time from the hw clock.

The incorrect time happens to be applied when running "/lib/udev/hwclock-set",
the timezone info does not seem to be available or used at that time, and then
hwclock sets the system to UTC from the hardware clock, which is read as UTC
eventhough it is registered as "LOCAL" in "/etc/adjtime". So, my UTC system
time is one hour in advance, since my hardware clock is at CET, i.e. UTC+1.

I downgraded to "tzdata-2015g-0+deb8u1", and it behaved the expected way: the
system clock is set to UTC after reboot when reading the local time from the
hardware clock.

I don't know how the "tzdata" package affects this, here are some logging
information gathered with "tzdata-2015g-0+deb8u1" and "tzdata-2016a-1"
packages. I also attach the modified "/lib/udev/hwclock-set" script I used to
get this logging information.

The noteworthy part is that when running "date" (last printed line of each
set), the displayed timezone is "CET" in Jessie package, and "UTC" in current
Strecth package. So, when "hwclock" sets the time to local time, it seems to
see "local time" as "UTC" in Strech.


When I set "UTC" in "/etc/adjtime", it behaves normally: no timezone
conversions are needed indeed.


Regards,

Christophe



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (985, 'testing'), (120, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.58

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
  tzdata/Zones/Pacific:
  tzdata/Zones/Antarctica:
* tzdata/Areas: Europe
* tzdata/Zones/Etc: GMT+1
  tzdata/Zones/Indian:
  tzdata/Zones/Arctic:
  tzdata/Zones/US:
  tzdata/Zones/SystemV:
  tzdata/Zones/Africa:
  tzdata/Zones/America:
* tzdata/Zones/Europe: Paris
  tzdata/Zones/Atlantic:
  tzdata/Zones/Australia:
  tzdata/Zones/Asia:
#!/bin/sh
# Reset the System Clock to UTC if the hardware clock from which it
# was copied by the kernel was in localtime.

dev=$1

if [ -e /run/systemd/system ] ; then
exit 0
fi

if [ -e /run/udev/hwclock-set ]; then
exit 0
fi

if [ -f /etc/default/rcS ] ; then
. /etc/default/rcS
fi

# These defaults are user-overridable in /etc/default/hwclock
BADYEAR=no
HWCLOCKACCESS=yes
HWCLOCKPARS=
HCTOSYS_DEVICE=rtc0
if [ -f /etc/default/hwclock ] ; then
. /etc/default/hwclock
fi

echo "* hwclock-set" >> /run/udev/hwclock-set
hwclock -r --debug >> /run/udev/hwclock-set
date >> /run/udev/hwclock-set

if [ yes = "$BADYEAR" ] ; then
/sbin/hwclock --rtc=$dev --systz --badyear
/sbin/hwclock --rtc=$dev --hctosys --badyear
else
/sbin/hwclock --rtc=$dev --systz
echo "* hwclock-set: --systz" >> /run/udev/hwclock-set
hwclock -r --debug >> /run/udev/hwclock-set
date >> /run/udev/hwclock-set
/sbin/hwclock --rtc=$dev --hctosys
echo "* hwclock-set: --hctosys" >> /run/udev/hwclock-set
hwclock -r --debug >> /run/udev/hwclock-set
date >> /run/udev/hwclock-set
fi

# Note 'touch' may not be available in initramfs
#> /run/udev/hwclock-set
* hwclock-set
hwclock from util-linux 2.27.1
Using the /dev interface to the clock.
Last drift adjustment done at 1457178708 seconds after 1969
Last calibration done at 1457178708 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/03/05 12:52:21
Hw clock time : 2016/03/05 12:52:21 = 1457178741 seconds since 1969
Time since last adjustment is 33 seconds
Calculated Hardware Clock drift is -1.86 seconds
Sat Mar  5 12:52:20 2016  .140813 seconds
Sat Mar  5 13:52:21 CET 2016
* hwclock-set: --systz
hwclock from util-linux 2.27.1
Using the /dev interface to the clock.
Last drift adjustment done at 1457178708 seconds after 1969
Last calibration done at 1457178708 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/03/05 12:52:22
Hw clock time : 2016/03/05 12:52:22 = 1457178742 seconds since 1969
Time since last adjustment is 34 seconds
Calculated Hardware Clock drift is -1.85 seconds
Sat Mar  5 12:52:21 2016  .374139 seconds
Sat Mar  5 12:52:22 CET 2016
* hwclock-set: --hctosys
hwclock from util-linux 2.27.1
Using the /dev interface to the clock.
Last drift adjustment done at 

Processed: Re: Bug#816742: libc6: sem_post/sem_wait not working for 32bit to 64bit inter-process communication

[Debian Bug Tracking System]

Processing control commands:

> forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=17980
Bug #816742 [libc6] libc6: sem_post/sem_wait not working for 32bit to 64bit 
inter-process  communication
Set Bug forwarded-to-address to 
'https://sourceware.org/bugzilla/show_bug.cgi?id=17980'.

-- 
816742: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816742
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#816742: libc6: sem_post/sem_wait not working for 32bit to 64bit inter-process communication

[Aurelien Jarno]

control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=17980

On 2016-03-04 09:45, Markus Friedrich wrote:
> Package: libc6
> Version: 2.21
> Severity: critical
> Justification: breaks unrelated software
> 
> Inter-process communication between a 64bit and a 32bit process is not
> working. At least pthread named semaphores are not working.
> A sem_wait is not awaken if a corresponding sem_post is done on the other
> side, which generated a dead lock.
> 
> This problem only exists if a 64bit process communicates with a 32bit
> process but not for 32bit to 32bit communication or 64bit to 64bit
> communication.

This has been caused by a rewrite of the semaphore code:

| commit 042e1521c794a945edc43b5bfa7e69ad70420524
| Author: Carlos O'Donell 
| Date:   Wed Jan 21 00:46:16 2015 -0500
| 
| Fix semaphore destruction (bug 12674).
| 
| This commit fixes semaphore destruction by either using 64b atomic
| operations (where available), or by using two separate fields when only
| 32b atomic operations are available.  In the latter case, we keep a
| conservative estimate of whether there are any waiting threads in one
| bit of the field that counts the number of available tokens, thus
| allowing sem_post to atomically both add a token and determine whether
| it needs to call futex_wake.
| 
| See:
| https://sourceware.org/ml/libc-alpha/2014-12/msg00155.html

For the full commit, see:
https://sourceware.org/git/?p=glibc.git;a=commit;h=042e1521c794a945edc43b5bfa7e69ad70420524

It corresponds to upstream bug BZ 17980:
https://sourceware.org/bugzilla/show_bug.cgi?id=17980

> Moreover Debian 8.3 and all other tested distributions have no problem with
> 64bit to 32bit inter-process communication using pthread named semaphores.

Given the issue is due to an upstream commit and not to a Debian
specific change, all distributions with a glibc >= 2.21 are affected.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net