Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sun, 06 Nov 2016, Adrian Bunk wrote:
> On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > > supposed to be disabled via a microcode update.  I don't know whether
> > > glibc avoids using it on these processors if the microcode update is
> > > not applied.  (Linux doesn't appear to hide the feature flags.)
> > 
> > It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> > TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> > 
> > But anything else *will* attempt to use it, people query cpuid directly
> > for these things.  You need a hypervisor that filters cpuid().
> 
> All users who are using intel-microcode from non-free instead of running 
> outdated microcode with known errata should be OK here?

Last time I checked, it looked like an yes for Skylake as far as Intel
TSX is concerned.

I don't know about the other processors, such as Broadwell-E.

-- 
  Henrique Holschuh

Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Adrian Bunk]

On Sun, Nov 06, 2016 at 08:04:39AM +0100, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > And what should we do about Debian stretch, then?
> 
> I believe a good start would be to add an assert() in a test version of
> glibc and then run all the autopkgtest scripts on the packages in the
> archive to see how widespread the problem is.  It will not cover all
> packages, but at least a significant portion of the archive.
> 
> I suspect we are too close to the Stretch freeze to try to modify all
> the packages affected by the problem,
>...

This discussion sounds as if all this would be future hardware,
but hardware with working (and not disabled) TSX is available
in nearly every computer shop in the world for over a year now 
(the first fixed Intel CPUs were released in 2014).

Please don't make it sound as if TSX would be a huge problem for 
stretch - it is not.

Every nontrivial piece of software has bugs.

If anyone wants to search specifically for this class of bugs that
is appreciated, just like searching for any other class of bugs is
appreciated.

Running stretch on hardware with TSX available and enabled
is working fine for many users for quite some time now.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

[glibc] branch sid updated (fd76a49 -> ee6ffab)

[Aurelien Jarno]

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

aurel32 pushed a change to branch sid
in repository glibc.

  from  fd76a49   hurd: Restore march version _pthread_spin_lock
   new  ee6ffab   debian/patches/git-updates.diff: update from upstream 
stable branch:

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|  1 +
 debian/patches/git-updates.diff | 72 +++--
 2 files changed, 71 insertions(+), 2 deletions(-)

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

Processed: Bug#841304 marked as pending

[Debian Bug Tracking System]

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

> tag 841304 pending
Bug #841304 [glibc] invalid code in glibc tests
Added tag(s) pending.
> thanks
Stopping processing here.

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

[glibc] 01/01: debian/patches/git-updates.diff: update from upstream stable branch:

[Aurelien Jarno]

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

aurel32 pushed a commit to branch sid
in repository glibc.

commit ee6ffabef0baa307624c273367706d1bc261770e
Author: Aurelien Jarno 
Date:   Sun Nov 6 22:08:07 2016 +0100

debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
 - Fix flexible array usage in gconv.h.  Closes: #841304.
---
 debian/changelog|  1 +
 debian/patches/git-updates.diff | 72 +++--
 2 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c16da4f..93d0f09 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,7 @@ glibc (2.24-6) UNRELEASED; urgency=medium
   [ Aurelien Jarno ]
   * debian/patches/git-updates.diff: update from upstream stable branch:
 - Fix pread/pwrite syscalls on SH4.
+- Fix flexible array usage in gconv.h.  Closes: #841304.
 
  -- Aurelien Jarno   Tue, 18 Oct 2016 23:17:42 +0200
 
diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff
index b8f5f85..106df6b 100644
--- a/debian/patches/git-updates.diff
+++ b/debian/patches/git-updates.diff
@@ -1,10 +1,27 @@
 GIT update of git://sourceware.org/git/glibc.git/release/2.24/master from 
glibc-2.24
 
 diff --git a/ChangeLog b/ChangeLog
-index c44c926..b2f6372 100644
+index c44c926..a51771c 100644
 --- a/ChangeLog
 +++ b/ChangeLog
-@@ -1,3 +1,168 @@
+@@ -1,3 +1,185 @@
++2016-11-03  Joseph Myers  
++
++  * conform/Makefile ($(linknamespace-header-tests)): Also depend on
++  $(linknamespace-symlists-tests).
++
++2016-11-06  Aurelien Jarno  
++
++  * iconv/gconv.h (__gconv_info): Define __data element using a
++  zero-length array.
++
++2016-10-25  Joseph Myers  
++
++  * sysdeps/powerpc/powerpc32/power6/memset.S (memset): Use cmplwi
++  instead of cmpli.
++  * sysdeps/powerpc/powerpc64/power6/memset.S (memset): Use cmpldi
++  instead of cmpli.
++
 +2016-10-24  Adhemerval Zanella  
 +
 +  * sysdeps/unix/sysv/linux/pread.c (__libc_pread): Use SYSCALL_LL_PRW.
@@ -303,6 +320,31 @@ index e67bbef..7cb5a69 100644
 +__END_DECLS
  
  #endif /* argp.h */
+diff --git a/conform/Makefile b/conform/Makefile
+index 32a0937..762aac9 100644
+--- a/conform/Makefile
 b/conform/Makefile
+@@ -229,6 +229,7 @@ $(linknamespace-symlist-stdlibs-tests): 
$(objpfx)symlist-stdlibs-%: \
+ 
+ $(linknamespace-header-tests): $(objpfx)%/linknamespace.out: \
+  linknamespace.pl \
++ $(linknamespace-symlists-tests) \
+  $(linknamespace-symlist-stdlibs-tests)
+   (set -e; std_hdr=$*; std=$${std_hdr%%/*}; hdr=$${std_hdr#*/}; \
+mkdir -p $(@D)/scratch; \
+diff --git a/iconv/gconv.h b/iconv/gconv.h
+index 8d8ce58..a870280 100644
+--- a/iconv/gconv.h
 b/iconv/gconv.h
+@@ -139,7 +139,7 @@ typedef struct __gconv_info
+ {
+   size_t __nsteps;
+   struct __gconv_step *__steps;
+-  __extension__ struct __gconv_step_data __data __flexarr;
++  __extension__ struct __gconv_step_data __data[0];
+ } *__gconv_t;
+ 
+ /* Transliteration using the locale's data.  */
 diff --git a/malloc/arena.c b/malloc/arena.c
 index 229783f..4e16593 100644
 --- a/malloc/arena.c
@@ -1786,6 +1828,19 @@ index 526d8ed..ac589bd 100644
return ret;
  }
  #endif
+diff --git a/sysdeps/powerpc/powerpc32/power6/memset.S 
b/sysdeps/powerpc/powerpc32/power6/memset.S
+index b2a222e..d5dbe83 100644
+--- a/sysdeps/powerpc/powerpc32/power6/memset.S
 b/sysdeps/powerpc/powerpc32/power6/memset.S
+@@ -394,7 +394,7 @@ L(cacheAlignedx):
+ /* A simple loop for the longer (>640 bytes) lengths.  This form limits
+the branch miss-predicted to exactly 1 at loop exit.*/
+ L(cacheAligned512):
+-  cmpli   cr1,rLEN,128
++  cmplwi  cr1,rLEN,128
+   blt cr1,L(cacheAligned1)
+   dcbz0,rMEMP
+   addirLEN,rLEN,-128
 diff --git a/sysdeps/powerpc/powerpc32/power9/multiarch/Implies 
b/sysdeps/powerpc/powerpc32/power9/multiarch/Implies
 index 4393b56..1a46ef0 100644
 --- a/sysdeps/powerpc/powerpc32/power9/multiarch/Implies
@@ -1793,6 +1848,19 @@ index 4393b56..1a46ef0 100644
 @@ -1 +1 @@
 -powerpc/powerpc32/power8/fpu/multiarch
 +powerpc/powerpc32/power8/multiarch
+diff --git a/sysdeps/powerpc/powerpc64/power6/memset.S 
b/sysdeps/powerpc/powerpc64/power6/memset.S
+index c2d1c4e..d445b1e 100644
+--- a/sysdeps/powerpc/powerpc64/power6/memset.S
 b/sysdeps/powerpc/powerpc64/power6/memset.S
+@@ -251,7 +251,7 @@ L(cacheAlignedx):
+ /* A simple loop for the longer (>640 bytes) lengths.  This form limits
+the branch miss-predicted to exactly 1 at loop exit.*/
+ L(cacheAligned512):
+-  cmpli   cr1,rLEN,128
++  cmpldi  cr1,rLEN,128
+   blt

Re: libc recently more aggressive about pthread locks in stable ?

[Aurelien Jarno]

On 2016-11-06 01:12, Henrique de Moraes Holschuh wrote:
> On Sat, 05 Nov 2016, Ian Jackson wrote:
> > Looking at the code, I think that gs in jessie is plainly violating
> > the rules about the use of pthread locks.  On my partner's machine,
> 
> Per logs from message #15 on bug #842796:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15
> 
> SIGSEGV on __lll_unlock_elision is a signature (IME with very high
> confidence) of an attempt to unlock an already unlocked lock while
> running under hardware lock elision.
> 
> 
> Well, unlocking an already unlocked lock is a pthreads API rule
> violation, and it is going to crash the process on something that
> implements hardware lock elision.
> 
> These would be Intel x86 processors with TSX enabled[1] for Debian
> 8/jessie.  For Debian 9/stretch and for unstable, I believe it also
> includes IBM Power8, and s390x systems -- AFAIK they won't forgive an
> attempt to unlock an unlocked lock any more than Intel TSX does.
> 
> [1] Broadwell-E, Skylake, and later processors, as well as Xeon *v5
> processors.  I am not sure if we blacklisted any of the Xeon *v4
> or not, and too tired to look their model numbers up right now.
> 
> Unfortunately, when hardware lock elision support was added to glibc
> upstream, libpthreads was *not* changed to properly assert() this
> forbidden condition on the non-hardware-elision codepaths.  Such an
> assert() would have given us consistent behavior, thus flushing the bugs
> out in the open... at the cost of a performance hit (I have no idea how
> severe), and much screaming.

This has not been done has it would have a severe performance hit. That
said error checking mutexes also exist in GLIBC, and have been designed
exactly for that, ie they trade performance for correctness.

> To be fair: it is likely nobody upstream had any idea of just how much
> code got libpthreads usage wrong... and we certainly didn't know better
> in Debian, either.  Well, now we're going to find out :-(
> 
> BTW, AFAIK libpthreads still doesn't have any such assert(), so there's
> likely a lot of such buggy code in unstable still.  This is going to
> cause trouble for Debian stretch, too.

I don't expect it to be worse than jessie, actually probably better as
some of the bugs have been fixed by the various upstreams in the
meantime. Also remember that TSX is just making the bug more visible. It
means that users without TSX might experience hangs instead. There are
actually two "hang bugs" reporting against ghostscript, that could be
fixed by fixing the TSX bug.

[...]

> If the problem is too widespread and too hard to fix on a large number
> of packages, I suppose we could ask the glibc maintainers to consider
> disabling hardware lock elision support in stable through a stable
> update.
> 
> Such a change to glibc would likely requires some patches to ensure it
> *really* disabled Intel TSX opcode/instruction insertion, but I think we
> already ship all of them as part of the Intel TSX blacklist.  The result
> would need real-world testing on an up-to-date Skylake box as well as
> objdump inspection to ensure *no* TSX-related instructions leaked into
> the binaries.

We can disable multiarch by passing "--enable-lock-elision". There is no
risk that the instructions are leaked into the binaries except of course
for static binaries. That said so far we talk about a few packages only.
A lot of bugs have already been fixed during the jessie release cycle, I
remember sending patches for that.

> And what should we do about Debian stretch, then?

As said above disabling TSX in glibc is just hidding issues to users. We
should instead try to detect as many bugs as possible (possibly fixing
the corresponding bugs in jessie). One way would be to get a box with
TSX instructions and use it for the reproducible builds and/or the
autopkgtests.

Aurelien

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


signature.asc
Description: PGP signature

Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Petter Reinholdtsen]

[Jeff Epler]
> I believe that similar bugs have been afflicting hurd and kfreebsd
> debian ports for some time.  In retrospect, it's too bad these reports
> weren't given more attention, because it could have made things better
> for Linux platforms as well.  :-/

Yeah, too bad. :/

On the other hand, it make me glad to have yet another example of the
value of the less popular architectures. :)

Does this mean that running the autopkgtest scripts on hurd or kfreebsd
would expose these problems?  Do we have any idea how widespread the
problem is?

-- 
Happy hacking
Petter Reinholdtsen

Re: libc recently more aggressive about pthread locks in stable ?

[Adrian Bunk]

On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > It's worth noting that TSX is broken in 'Haswell' processors and is
> > supposed to be disabled via a microcode update.  I don't know whether
> > glibc avoids using it on these processors if the microcode update is
> > not applied.  (Linux doesn't appear to hide the feature flags.)
> 
> It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> 
> But anything else *will* attempt to use it, people query cpuid directly
> for these things.  You need a hypervisor that filters cpuid().

All users who are using intel-microcode from non-free instead of running 
outdated microcode with known errata should be OK here?

Running outdated microcode is a bad idea, and noone is making 
Debian-specific workarounds for all the other CPU errata.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: libc recently more aggressive about pthread locks in stable ?

[Ian Jackson]

Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive about 
pthread locks in stable ?"):
> Per logs from message #15 on bug #842796:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15
> 
> SIGSEGV on __lll_unlock_elision is a signature (IME with very high
> confidence) of an attempt to unlock an already unlocked lock while
> running under hardware lock elision.

I don't know anything about hardware lock elision...

> Well, unlocking an already unlocked lock is a pthreads API rule
> violation, and it is going to crash the process on something that
> implements hardware lock elision.

... but you are of course correct about this.  I debugged the problem
with ghostscript, and it was indeed violating the pthreads rules.  I
have filed #843324 with a patch for Debian to backport the
corresponding upstream fix.  I don't understand the wider logic in
ghostscript; the bug was in the colour space management code and
occurred when a function was called with two pointer arguments which
were actually aliases of the same colourspace-related data structure.
Converting ghostscript to use recursive mutexes was IMO clearly
correct and fixed the bug.

> If the problem is too widespread and too hard to fix on a large number
> of packages, I suppose we could ask the glibc maintainers to consider
> disabling hardware lock elision support in stable through a stable
> update.

I think this would be a good idea.

ogg123 and ghostscript are hardly obscure programs.  It's difficult to
know how bad this problem is, but we would like stable to be useful
even on recent hardware.

> And what should we do about Debian stretch, then?

Perhaps we could add the assert you suggest, on non-lock-elision
hardware.  Whether to do that would depend on its performance impact.

TBH I wonder whether we really want to be giving an evidently shonky
codebase boobytrapped mutexes by default.  We could change the default
mutex type to recursive and make all of these bugs go away.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sun, 06 Nov 2016, Ben Hutchings wrote:
> It's worth noting that TSX is broken in 'Haswell' processors and is
> supposed to be disabled via a microcode update.  I don't know whether
> glibc avoids using it on these processors if the microcode update is
> not applied.  (Linux doesn't appear to hide the feature flags.)

It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
TSX use [in libpthreads] on all of Haswell and much of Broadwell.

But anything else *will* attempt to use it, people query cpuid directly
for these things.  You need a hypervisor that filters cpuid().

-- 
  Henrique Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

[Jeff Epler]

[resending with correct Cc:]

I believe that similar bugs have been afflicting hurd and kfreebsd debian ports
for some time.  In retrospect, it's too bad these reports weren't given more
attention, because it could have made things better for Linux platforms as well.
:-/

see e.g.,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671785#48

Jeff

Re: libc recently more aggressive about pthread locks in stable ?

[Ben Hutchings]

On Sat, 2016-11-05 at 20:32 +0100, Christian Seiler wrote:
> On 11/05/2016 08:13 PM, Ian Jackson wrote:
> > I have just been debugging a ghostscript segfault on jessie amd64.
> > 
> > Looking at the code, I think that gs in jessie is plainly violating
> > the rules about the use of pthread locks.  On my partner's machine,
> > this makes it segfault on termination (with some input files, at
> > least).  On my machine it works just fine.  The code in sid is better.
> > 
> > I recently encountered what seems to be a similar bug in ogg123 in
> > stable.  #842796.
> > 
> > Has something changed in jessie's libc recently ?  I find it difficult
> > to imagine that these bugs would have been missed earlier during the
> > life of jessie.
> 
> Recently Frank Fegert discovered a problem with locking in open-iscsi
> that only occurs on new hardware. The code previously was wrong, but
> earlier CPUs were more forgiving when it came to this error and it
> couldn't be triggered.
> 
> Frank wrote about the problem in his blog in great detail:
> http://www.bityard.org/blog/2016/08/05/debugging_segfaults_open-iscsi_iscsiuio_intel_broadwell
[...]

This is not really a case of older CPUs being 'more forgiving'; they
had no locking operations[*] and nothing to forgive.  However, glibc
uses transactional memory (TSX) on the newer CPUs that implement it,
and that new code does result in the CPU detecting some locking errors.

It's worth noting that TSX is broken in 'Haswell' processors and is
supposed to be disabled via a microcode update.  I don't know whether
glibc avoids using it on these processors if the microcode update is
not applied.  (Linux doesn't appear to hide the feature flags.)

* The LOCK prefix is for 'bus locking' during a single instruction,
i.e. making it atomic.  The CPU can't know what higher-level operation
it's being used for.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.



signature.asc
Description: This is a digitally signed message part

[tzdata] 03/03: Release to wheezy-security

[Aurelien Jarno]

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

aurel32 pushed a commit to branch wheezy
in repository tzdata.

commit 4b55a9ab023aaa129bcbfb0e47e0773b19dfe02b
Author: Emilio Pozuelo Monfort 
Date:   Sun Nov 6 11:12:30 2016 +0100

Release to wheezy-security
---
 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 60f2d82..bb2464d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-tzdata (2016i-0+deb7u1) UNRELEASED; urgency=medium
+tzdata (2016i-0+deb7u1) wheezy-security; urgency=medium
 
   * New upstream version, affecting the following past and future timestamps:
 - Pacific/Tongatapu (DST starting on 2016-11-06 at 02:00).
@@ -7,7 +7,7 @@ tzdata (2016i-0+deb7u1) UNRELEASED; urgency=medium
 - Antarctica/Casey (switched from +08 to +11 on 2016-10-22).
   * Update templates and translations.
 
- -- Emilio Pozuelo Monfort   Sun, 06 Nov 2016 11:09:47 +0100
+ -- Emilio Pozuelo Monfort   Sun, 06 Nov 2016 11:12:23 +0100
 
 tzdata (2016h-0+deb7u1) wheezy-security; urgency=medium
 

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

[tzdata] 01/03: New upstream version

[Aurelien Jarno]

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

aurel32 pushed a commit to branch wheezy
in repository tzdata.

commit eb649b86267bdbfc03e37fc86b8c34e05dcc7203
Author: Emilio Pozuelo Monfort 
Date:   Sun Nov 6 11:11:17 2016 +0100

New upstream version

New upstream version, affecting the following past and future timestamps:
- Pacific/Tongatapu (DST starting on 2016-11-06 at 02:00).
- Northern Cyprus is now +03 year round, the Asia/Famagusta zone has
  been added.
- Antarctica/Casey (switched from +08 to +11 on 2016-10-22).
---
 debian/changelog | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 57c0bcb..3272022 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+tzdata (2016i-0+deb7u1) UNRELEASED; urgency=medium
+
+  * New upstream version, affecting the following past and future timestamps:
+- Pacific/Tongatapu (DST starting on 2016-11-06 at 02:00).
+- Northern Cyprus is now +03 year round, the Asia/Famagusta zone has
+  been added.
+- Antarctica/Casey (switched from +08 to +11 on 2016-10-22).
+
+ -- Emilio Pozuelo Monfort   Sun, 06 Nov 2016 11:09:47 +0100
+
 tzdata (2016h-0+deb7u1) wheezy-security; urgency=medium
 
   * New upstream version, affecting the following future time stamps:

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

[tzdata] branch wheezy updated (71c268e -> 4b55a9a)

[Aurelien Jarno]

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

aurel32 pushed a change to branch wheezy
in repository tzdata.

  from  71c268e   Release to wheezy-security
   new  eb649b8   New upstream version
   new  514d42f   Update templates and translations.
   new  4b55a9a   Release to wheezy-security

The 3 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| 11 +++
 debian/po/be.po | 18 +-
 debian/po/bg.po | 18 +-
 debian/po/ca.po | 18 +-
 debian/po/cs.po | 18 +-
 debian/po/da.po | 18 +-
 debian/po/de.po | 18 +-
 debian/po/en.po | 18 +-
 debian/po/es.po | 18 +-
 debian/po/eu.po | 18 +-
 debian/po/fi.po | 18 +-
 debian/po/fr.po | 18 +-
 debian/po/gl.po | 18 +-
 debian/po/gu.po | 18 +-
 debian/po/he.po | 18 +-
 debian/po/hr.po | 18 +-
 debian/po/hu.po | 18 +-
 debian/po/id.po | 18 +-
 debian/po/it.po | 18 +-
 debian/po/ja.po | 18 +-
 debian/po/ku.po | 18 +-
 debian/po/lt.po | 18 +-
 debian/po/ml.po | 18 +-
 debian/po/nl.po | 18 +-
 debian/po/pl.po | 18 +-
 debian/po/pt.po | 18 +-
 debian/po/pt_BR.po  | 18 +-
 debian/po/ru.po | 18 +-
 debian/po/sk.po | 18 +-
 debian/po/sq.po | 18 +-
 debian/po/sv.po | 18 +-
 debian/po/templates.pot | 16 +++-
 debian/po/th.po | 18 +-
 debian/po/tr.po | 18 +-
 debian/po/vi.po | 18 +-
 debian/po/wo.po | 18 +-
 debian/tzdata.templates |  2 +-
 37 files changed, 605 insertions(+), 36 deletions(-)

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

[tzdata] 02/03: Update templates and translations.

[Aurelien Jarno]

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

aurel32 pushed a commit to branch wheezy
in repository tzdata.

commit 514d42f50d22fcfd7c9fa3d962cfebe1093aa303
Author: Aurelien Jarno 
Date:   Sat Nov 5 23:44:36 2016 +0100

Update templates and translations.
---
 debian/changelog|  1 +
 debian/po/be.po | 18 +-
 debian/po/bg.po | 18 +-
 debian/po/ca.po | 18 +-
 debian/po/cs.po | 18 +-
 debian/po/da.po | 18 +-
 debian/po/de.po | 18 +-
 debian/po/en.po | 18 +-
 debian/po/es.po | 18 +-
 debian/po/eu.po | 18 +-
 debian/po/fi.po | 18 +-
 debian/po/fr.po | 18 +-
 debian/po/gl.po | 18 +-
 debian/po/gu.po | 18 +-
 debian/po/he.po | 18 +-
 debian/po/hr.po | 18 +-
 debian/po/hu.po | 18 +-
 debian/po/id.po | 18 +-
 debian/po/it.po | 18 +-
 debian/po/ja.po | 18 +-
 debian/po/ku.po | 18 +-
 debian/po/lt.po | 18 +-
 debian/po/ml.po | 18 +-
 debian/po/nl.po | 18 +-
 debian/po/pl.po | 18 +-
 debian/po/pt.po | 18 +-
 debian/po/pt_BR.po  | 18 +-
 debian/po/ru.po | 18 +-
 debian/po/sk.po | 18 +-
 debian/po/sq.po | 18 +-
 debian/po/sv.po | 18 +-
 debian/po/templates.pot | 16 +++-
 debian/po/th.po | 18 +-
 debian/po/tr.po | 18 +-
 debian/po/vi.po | 18 +-
 debian/po/wo.po | 18 +-
 debian/tzdata.templates |  2 +-
 37 files changed, 595 insertions(+), 36 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 3272022..60f2d82 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,7 @@ tzdata (2016i-0+deb7u1) UNRELEASED; urgency=medium
 - Northern Cyprus is now +03 year round, the Asia/Famagusta zone has
   been added.
 - Antarctica/Casey (switched from +08 to +11 on 2016-10-22).
+  * Update templates and translations.
 
  -- Emilio Pozuelo Monfort   Sun, 06 Nov 2016 11:09:47 +0100
 
diff --git a/debian/po/be.po b/debian/po/be.po
index 51308f3..a7226c5 100644
--- a/debian/po/be.po
+++ b/debian/po/be.po
@@ -21,7 +21,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: tzdata_2008i-2_be\n"
 "Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
-"POT-Creation-Date: 2016-04-20 20:30+0200\n"
+"POT-Creation-Date: 2016-11-05 23:41+0100\n"
 "PO-Revision-Date: 2013-12-24 23:13+0100\n"
 "Last-Translator: Pavel Piatruk \n"
 "Language-Team: Belarusian (Official spelling) \n"
@@ -2079,6 +2079,13 @@ msgstr "Душанбэ"
 #. Choices
 #. Translators: do not translate underscores. You can use spaces instead.
 #: ../tzdata.templates:7001
+msgid "Famagusta"
+msgstr ""
+
+#. Type: select
+#. Choices
+#. Translators: do not translate underscores. You can use spaces instead.
+#: ../tzdata.templates:7001
 msgid "Gaza"
 msgstr "Газа"
 
@@ -2505,6 +2512,15 @@ msgstr "Якуцк"
 #. Choices
 #. Translators: do not translate underscores. You can use spaces instead.
 #: ../tzdata.templates:7001
+#, fuzzy
+#| msgid "Rangoon"
+msgid "Yangon"
+msgstr "Рангун"
+
+#. Type: select
+#. Choices
+#. Translators: do not translate underscores. You can use spaces instead.
+#: ../tzdata.templates:7001
 msgid "Yekaterinburg"
 msgstr "Екацерынбург"
 
diff --git a/debian/po/bg.po b/debian/po/bg.po
index c7dc431..0fdcf6d 100644
--- a/debian/po/bg.po
+++ b/debian/po/bg.po
@@ -17,7 +17,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: bg\n"
 "Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
-"POT-Creation-Date: 2016-04-20 20:30+0200\n"
+"POT-Creation-Date: 2016-11-05 23:41+0100\n"
 "PO-Revision-Date: 2013-12-24 23:13+0100\n"
 "Last-Translator: Yavor Doganov \n"
 "Language-Team: Bulgarian \n"
@@ -2072,6 +2072,13 @@ msgstr "Душанбе"
 #. Choices
 #. Translators: do not translate underscores. You can use spaces instead.
 #: ../tzdata.templates:7001
+msgid "Famagusta"
+msgstr ""
+
+#. Type: select
+#. Choices
+#. Translators: do not translate underscores. You can use spaces instead.
+#: ../tzdata.templates:7001
 msgid "Gaza"
 msgstr "Газа"
 
@@ -2498,6 +2505,15 @@ msgstr "Якутск"
 #. Choices
 #. Translators: do not translate underscores. You can use spaces instead.
 #: ../tzdata.templates:7001
+#, fuzzy
+#| msgid "Rangoon"
+msgid "Yangon"
+msgstr "Рангун"
+
+#. Type: select
+#. Choices
+#. Translators: do not translate 

[glibc] branch sid updated (a5a376f -> fd76a49)

[Samuel Thibault]

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

sthibault pushed a change to branch sid
in repository glibc.

  from  a5a376f   hurd: Drop spurious pthread_spin_lock aliases
   new  fd76a49   hurd: Restore march version _pthread_spin_lock

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:
 .../hurd-i386/tg-libpthread-gsync-spin.diff| 45 --
 1 file changed, 7 insertions(+), 38 deletions(-)

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

[glibc] 01/01: hurd: Restore march version _pthread_spin_lock

[Samuel Thibault]

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

sthibault pushed a commit to branch sid
in repository glibc.

commit fd76a49313eb7dbe51a86304e067be5913c0b190
Author: Samuel Thibault 
Date:   Sun Nov 6 13:39:07 2016 +0100

hurd: Restore march version _pthread_spin_lock

to further reduce the disruption of using gsync in pthread_spin_lock
---
 .../hurd-i386/tg-libpthread-gsync-spin.diff| 45 --
 1 file changed, 7 insertions(+), 38 deletions(-)

diff --git a/debian/patches/hurd-i386/tg-libpthread-gsync-spin.diff 
b/debian/patches/hurd-i386/tg-libpthread-gsync-spin.diff
index 7436286..0462e4f 100644
--- a/debian/patches/hurd-i386/tg-libpthread-gsync-spin.diff
+++ b/debian/patches/hurd-i386/tg-libpthread-gsync-spin.diff
@@ -1,4 +1,4 @@
-commit eccb1958dd0f8eb9d4ce15d7350ef16c0608d4f2
+commit 2d2ca1268f863437bad07c6abbbc23f33bbfe9f1
 Author: Agustina Arzille 
 Date:   Tue Oct 18 00:20:45 2016 +0200
 
@@ -239,44 +239,13 @@ index 5ae81e1..000
 -
 -#endif /* bits/spin-lock.h */
 diff --git a/libpthread/sysdeps/mach/pt-spin.c 
b/libpthread/sysdeps/mach/pt-spin.c
-deleted file mode 100644
-index d9a2a32..000
+index d9a2a32..0f49ca3 100644
 --- a/libpthread/sysdeps/mach/pt-spin.c
-+++ /dev/null
-@@ -1,36 +0,0 @@
--/* Spin locks.  Mach version.
--   Copyright (C) 2002, 2004 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 Library General Public License as
--   published by the Free Software Foundation; either version 2 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
--   Library General Public License for more details.
--
--   You should have received a copy of the GNU Library General Public
--   License along with the GNU C Library; see the file COPYING.LIB.  If not,
--   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
--   Boston, MA 02111-1307, USA.  */
--
--#include 
--#include 
--
--/* In glibc.  */
--extern void __spin_lock_solid (__pthread_spinlock_t *lock);
--
--/* Lock the spin lock object LOCK.  If the lock is held by another
--   thread spin until it becomes available.  */
--int
--_pthread_spin_lock (__pthread_spinlock_t *lock)
--{
--  __spin_lock_solid (lock);
--  return 0;
--}
 b/libpthread/sysdeps/mach/pt-spin.c
+@@ -31,6 +31,3 @@ _pthread_spin_lock (__pthread_spinlock_t *lock)
+   __spin_lock_solid (lock);
+   return 0;
+ }
 -
 -weak_alias (_pthread_spin_lock, pthread_spin_lock);
 -weak_alias (_pthread_spin_lock, __pthread_spin_lock);

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

Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Petter Reinholdtsen]

[Henrique de Moraes Holschuh]
> And what should we do about Debian stretch, then?

I believe a good start would be to add an assert() in a test version of
glibc and then run all the autopkgtest scripts on the packages in the
archive to see how widespread the problem is.  It will not cover all
packages, but at least a significant portion of the archive.

I suspect we are too close to the Stretch freeze to try to modify all
the packages affected by the problem, and if so we should probably
disable the more strict code for Stretch too, and make it an RC issue in
unstable after the freeze in February.  A problem is that it will be
hard to test all the packages in time, as such locking issue might not
trigger on every run.

Is there already, or can you create, a wiki page to collect the details
on this problem?  You seem to have more grasp of the issue than me,
otherwise I would have started one myself.

I assume other distributions are affected too.  What are they doing to
handle it?

-- 
Happy hacking
Petter Reinholdtsen