Bug#926751: gcc-riscv64-linux-gnu: Doesn't work with all valid abi combinations.

2019-04-10 Thread Aurelien Jarno
control: tag -1 + wontfix

On 2019-04-10 07:29, Matthias Klose wrote:
> Control: reassign -1 src:glibc
> 
> these are glibc headers.
> 
> On 10.04.19 04:05, peterc wrote:
> > Package: gcc-riscv64-linux-gnu
> > Version: 4:8.3.0-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > 
> > My RISC V64 implementation doesn't have floating point, so I'm trying
> > to compile with
> >  -march=rv64imac -mabi=lp64
> > 
> > I see:
> > $  riscv64-linux-gnu-gcc -mabi=lp64 -march=rv64imac x.c
> > In file included from /usr/riscv64-linux-gnu/include/features.h:448,
> >  from 
> > /usr/riscv64-linux-gnu/include/bits/libc-header-start.h:3,
> >  from /usr/riscv64-linux-gnu/include/stdio.h:27,
> >  from x.c:1:
> > /usr/riscv64-linux-gnu/include/gnu/stubs.h:8:11: fatal error: 
> > gnu/stubs-lp64.h: No such file or directory
> >  # include 
> >  compilation terminated.
> > 
> > for a simple hello world program.
> > 
> > It looks as if only march=rv64imafdc/mabi=lp64d is supported; please
> > can the other valid combinations be supported as well?

The RISC-V Debian port indeed targets rv64gc/lp64d:

https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_choice

There is no plan to support other ABIs so far, so tagging this bug as
wontfix.

> > The current list is:
> > 
> > march=rv32i/mabi=ilp32
> > march=rv32im/mabi=ilp32
> > march=rv32iac/mabi=ilp32
> > march=rv32imac/mabi=ilp32
> > march=rv32imafc/mabi=ilp32f
> > march=rv64imac/mabi=lp64
> > march=rv64imafdc/mabi=lp64d

Note that upstream git glibc doesn't even support 32-bit ABIs.

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



Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

2019-04-09 Thread Aurelien Jarno
On 2019-04-09 12:27, Andreas Beckmann wrote:
> Package: libc6-x32,libc6-i386
> Version: 2.28-8
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts in a --merged-usr environment I noticed that
> installing, removing, and installing again a package shipping /lib32,
> /libx32 will actually unmerge that directory.
> The package will take ownership of the preexisting symlinks
> /lib{32,x32} -> /usr/lib{32,x32} that were created by debootstrap,
> remove them and create plain /usr/lib{32,x32} directories in the next
> installation.
> (/lib64 should be mostly safe due to /lib64/ld-linux-x86-64.so.2, but
> perhaps on !x86 architectures)

Hmm the only fault of the libc6-i386 and libc6-x32 packages (plus I
guess all the other bi/tri-arch ones on other architectures) is to be
the last user of those directory when being removed. They do not do
anything tricky in their directories.

> The preinst scripts could check whether the package is being installed
> in a --merged-usr environment and create (dangling) symlinks if
> /usr/lib{32,x32} is missing. And postrm remove could recreate them if
> they went missing.

This looks like an ugly workaround to me, and might not work if a
package start adding files there without depending on libc6. This looks
to me like a flaw in the usrmerge design. The base-files package is
designed to prevent directories or symlinks to be removed, so I wonder
if we need a usrmerge version of it.

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


signature.asc
Description: PGP signature


Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

2019-03-31 Thread Aurelien Jarno
This bug is very likely a bug present in old glibc versions. It has been
brought to light when enabling TLS support in openblas and not by a new
glibc version.

Right now the bug has been workarounded by disabling TLS support in
openblas. The way to handle this bug is to write a small testcase that
can be forwarded upstream. It's not an easy task though.

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


signature.asc
Description: PGP signature


Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-28 Thread Aurelien Jarno
Hi Florian,

On 2019-03-27 23:59, Florian Weimer wrote:
> retitle 924891 glibc: misc/tst-pkey fails due to cleared PKRU register after 
> signal in amd64 32-bit compat mode 
> thanks
> 
> * Lucas Nussbaum:
> 
> > On 27/03/19 at 08:48 +0100, Florian Weimer wrote:
> >> > If that's useful, I can easily provide access to an AWS VM to debug this
> >> > issue.
> >> 
> >> Oh, that would be quite helpful indeed.
> >
> > Can you send your SSH key? (I thought there was a way to get the SSH key
> > for a DD, but I cannot find it anymore)
> >
> > Then you will be able to ssh to root@18.184.55.40.
> > There's sbuild and schroot setup on the VM.
> >
> > When you are done, please 'poweroff' the machine, which will terminate
> > it.
> 
> The issue reproduces outside the chroot, with the stretch userland.
> 
> What happens is that once we get out of the SIGUSR1 signal handler,
> the PKRU register has value zero.  This happens around this code in
> the test:
> 
>   /* Check that in a signal handler, there is no access.  */
>   xsignal (SIGUSR1, _handler);
>   xraise (SIGUSR1);
>   xsignal (SIGUSR1, SIG_DFL);
>   TEST_COMPARE (sigusr1_handler_ran, 1);
> 
> I checked the following (via a breakpoint in pkey_get; I don't think
> GDB can read the PKRU register directly): Inside the SIGUSR1 signal
> handler, PKRU has value 0x5554, as expected for this kernel, but
> after the return, we get zero.  This is the first time a signal is
> delivered on the main thread, so it's consistent with fairly broken
> signal handling as far as the PKRU register is concerned.  I guess
> clearing PKRU in this way might even constitute a minor security bug
> (because the zero value means no restrictions).

Thanks a lot for investigating and for all the details.

> This commit looks highly relevant:
> 
> commit a4455082dc6f0b5d51a23523f77600e8ede47c79
> Author: Dave Hansen 
> Date:   Wed Jun 8 10:25:33 2016 -0700
> 
> x86/signals: Add missing signal_compat code for x86 features
> 
> The 32-bit siginfo is a different binary format than the 64-bit
> one.  So, when running 32-bit binaries on 64-bit kernels, we have
> to convert the kernel's 64-bit version to a 32-bit version that
> userspace can grok.
> 
> If the siginfo_t layout is incorrect (with regards to what the
> hardware writes), I expect that we might end up copying back the wrong
> PKRU value.

This commit is actually already in the 4.9 kernel.

> I'm not sure what to do here.  This really looks like a kernel bug.
> Maybe we should just verify that this is fixed in the buster kernel
> and move on?

I agree. I have been able to find a machine where I can temporarily run
a VM. I have found that the problem has been solved between kernel
4.10-rc6 and 4.10, more precisely between the following debian packages:
- linux-image-4.10.0-rc6-amd64-unsigned version 4.10~rc6-1~exp1
- linux-image-4.10.0-trunk-amd64-unsigned version 4.10-1~exp1

I gave a quick look at the commit logs, and I haven't identified a
commit. I'll look again and try to identify the commit fixing the issue
so that it can be backported in the stretch kernel. I'll then reassign
the bug there.

Regards,
Aurelien

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



[Git][glibc-team/tzdata] Pushed new tag debian/2019a-0+deb9u1

2019-03-27 Thread Aurelien Jarno


Aurelien Jarno pushed new tag debian/2019a-0+deb9u1 at GNU Libc Maintainers / 
tzdata

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/tree/debian/2019a-0+deb9u1
You're receiving this email because of your account on salsa.debian.org.



[Git][glibc-team/tzdata][stretch] 2 commits: New upstream version, affecting the following past and future timestamps:

2019-03-27 Thread Aurelien Jarno


Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / tzdata


Commits:
06d94d60 by Aurelien Jarno at 2019-03-27T20:34:12Z
New upstream version, affecting the following past and future timestamps:

* New upstream version, affecting the following past and future
  timestamps:
  - Palestine will not start DST until 2019-03-30, instead of 2019-03-23
as previously predicted.
  - Metlakatla ended its observance of Pacific standard time, rejoining
Alaska Time, on 2019-01-20 at 02:00.

- - - - -
aaea5de0 by Aurelien Jarno at 2019-03-27T20:34:26Z
releasing package tzdata version 2019a-0+deb9u1

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/d39cfe4198620b6848a3427b803fedfe3ca72bd9...aaea5de0249851dcd19398273e85611979df2dcd

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/d39cfe4198620b6848a3427b803fedfe3ca72bd9...aaea5de0249851dcd19398273e85611979df2dcd
You're receiving this email because of your account on salsa.debian.org.



[Git][glibc-team/tzdata][sid] 2 commits: New upstream version, affecting the following past and future timestamps:

2019-03-26 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / tzdata


Commits:
02ae8ee2 by Aurelien Jarno at 2019-03-26T22:05:56Z
New upstream version, affecting the following past and future timestamps:

* New upstream version, affecting the following past and future
  timestamps:
  - Palestine will not start DST until 2019-03-30, instead of 2019-03-23
as previously predicted.
  - Metlakatla ended its observance of Pacific standard time, rejoining
Alaska Time, on 2019-01-20 at 02:00.

- - - - -
8e37b3f9 by Aurelien Jarno at 2019-03-26T22:06:06Z
releasing package tzdata version 2019a-1

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/15662b52fffcb14a6f34b238f157d57d47aefd05...8e37b3f9034fee9cb83b377cc67dc56dc78242e6

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/15662b52fffcb14a6f34b238f157d57d47aefd05...8e37b3f9034fee9cb83b377cc67dc56dc78242e6
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata] Pushed new tag debian/2019a-1

2019-03-26 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2019a-1 at GNU Libc Maintainers / tzdata

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/tree/debian/2019a-1
You're receiving this email because of your account on salsa.debian.org.


Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-26 Thread Aurelien Jarno
On 2019-03-22 17:30, Florian Weimer wrote:
> > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > failed build was retried once to eliminate random failures.
> 
> I believe the actual test failure is tst-pkey.
> 
> Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
> know which model?  Do you have any information about the kernel and
> hypervisor used?
> 
> 32-bit protection key support has had issues from time to time.

Do you have some more details about the issue? Is it a glibc or a kernel
problem?

If we can't fix the issue easily on the libc side, I guess the way to
fix that is to XFAIL that test on 32-bit x86. 

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



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

2019-03-17 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
fc73ed51 by Aurelien Jarno at 2019-03-17T09:29:08Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - Fix heap-based buffer over-read in regular-expression matching
(CVE-2019-9169).  Closes: #924612.

- - - - -


2 changed files:

- debian/changelog
- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/fc73ed51f91c42b330942d36ad40739347db

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/fc73ed51f91c42b330942d36ad40739347db
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata] Pushed new tag debian/2018i-2

2019-02-28 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2018i-2 at GNU Libc Maintainers / tzdata

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/tree/debian/2018i-2
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata][sid] releasing package tzdata version 2018i-2

2019-02-28 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / tzdata


Commits:
15662b52 by Aurelien Jarno at 2019-02-28T21:56:15Z
releasing package tzdata version 2018i-2

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/15662b52fffcb14a6f34b238f157d57d47aefd05

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/15662b52fffcb14a6f34b238f157d57d47aefd05
You're receiving this email because of your account on salsa.debian.org.


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

2019-02-27 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
3c110531 by Aurelien Jarno at 2019-02-27T23:15:01Z
debian/patches/git-updates.diff: update from upstream stable branch.

- - - - -


1 changed file:

- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/3c110531bbb3b4bfde88cf6b30d353cbd3da268c

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/3c110531bbb3b4bfde88cf6b30d353cbd3da268c
You're receiving this email because of your account on salsa.debian.org.


Bug#704089: tzdata config script prevents non-interactive (re)configuration

2019-02-24 Thread Aurelien Jarno
On 2019-01-17 11:14, Adam Bolte wrote:
> On Wed, Jan 16, 2019 at 11:43:57AM +0100, Aurelien Jarno wrote:
> > I don't think the patch is correct. Debconf is not a registry, the
> > canonical location for the configuration is the configuration files, not
> > the debconf database. Quoting debconf-devel(7):
> > 
> > "The issue to watch out for here is that debconf is not intended to be,
> > and must not be used as a registry."
> > 
> > I think it also applies when DEBCONF_RECONFIGURE is set.
> 
> That's interesting, but also very confusing. If your assumption is
> correct, what is the point of being able to run dpkg-reconfigure in
> non-interactive mode?

Re-execute the postinst script with the new configuration. In the case
of postinst, it would mean for example:

$ echo Europe/London > /etc/timezone
$ dpkg-reconfigure -fnoninteractive tzdata

This ensures that the /etc/localtime symlink is correctly configured. If
you look a bit on a search engine, it looks like a very common method to
configure the timezone.

> You can only reconfigure a package that is already installed, so (as I
> understand it) if the debconf registry is supposed to be clobbered by
> whatever the actual system configuration is before use, that would
> mean `dpkg-reconfigure -fnoninteractive ` is a completely
> useless and pointless command.
> 
> Let's look at the dash package
> 
> $ sudo debconf-get-selections | grep dash
> # Use dash as the default system shell (/bin/sh)?
> dash  dash/sh boolean true
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Jan 24  2017 /bin/sh -> dash
> $ echo dash dash/sh boolean false | sudo debconf-set-selections
> $ sudo debconf-get-selections | grep dash
> # Use dash as the default system shell (/bin/sh)?
> dash  dash/sh boolean false
> $ sudo dpkg-reconfigure -fnoninteractive dash
> Removing 'diversion of /bin/sh to /bin/sh.distrib by dash'
> Adding 'diversion of /bin/sh to /bin/sh.distrib by bash'
> Removing 'diversion of /usr/share/man/man1/sh.1.gz to 
> /usr/share/man/man1/sh.distrib.1.gz by dash'
> Adding 'diversion of /usr/share/man/man1/sh.1.gz to 
> /usr/share/man/man1/sh.distrib.1.gz by bash'
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Jan 17 10:55 /bin/sh -> bash
> $ 
> 
> The dash package reconfiguration has no issues modifying the system
> configuration based on debconf. I would expect tzdata to behave in a
> consistent manner with other packages.

Let's look at another example, the locales package prefers debconf to the
file configuration, just like to ask for tzdata. People consider that as
a bug, see for example bug #793368.

It doesn't seem to be possible to support both reconfiguration from
preseed and from a config file at the same time. It seems some people
expect one to work the other expect the other. I therefore prefer to not
change the current behavior and keep the status quo. Also the current
behavior implemented in tzdata seems to more or less match the "debconf
... must not be used as a registry".

Aurelien

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


signature.asc
Description: PGP signature


[Git][glibc-team/tzdata][sid] Update Danish debconf translation, by Joe Hansen. Closes: #923061.

2019-02-24 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / tzdata


Commits:
3a10787f by Aurelien Jarno at 2019-02-24T13:30:00Z
Update Danish debconf translation, by Joe Hansen.  Closes: #923061.

- - - - -


2 changed files:

- debian/changelog
- debian/po/da.po


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/3a10787f51840f69fcd6b201dcda67e4dcb3ba09

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/3a10787f51840f69fcd6b201dcda67e4dcb3ba09
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] Update Danish debconf translation, by Joe Hansen. Closes: #923055.

2019-02-24 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
63b8b872 by Aurelien Jarno at 2019-02-24T13:24:49Z
Update Danish debconf translation, by Joe Hansen.  Closes: #923055.

- - - - -


2 changed files:

- debian/changelog
- debian/po/da.po


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/63b8b872d554cdfecf62b80b1c9049f4bf16c4e0

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/63b8b872d554cdfecf62b80b1c9049f4bf16c4e0
You're receiving this email because of your account on salsa.debian.org.


Bug#921913: locales: character map file `C' not found: No such file or directory

2019-02-21 Thread Aurelien Jarno
On 2019-02-21 22:01, Helge Kreutzmann wrote:
> Hello Aurelien,
> On Wed, Feb 20, 2019 at 09:14:15PM +0100, Aurelien Jarno wrote:
> > On 2019-02-10 08:48, Helge Kreutzmann wrote:
> > > Package: locales
> > > Version: 2.28-6
> > > Severity: minor
> > > 
> > > In todays upgrade in my sid chroot I see the following messages
> > > locales (2.28-6) wird eingerichtet ...
> > > Generating locales (this might take a while)...
> > >   de_DE.ISO-8859-1... done
> > >   de_DE.UTF-8... done
> > >   en_GB.UTF-8... done
> > >   en_US.UTF-8... done
> > >   C.C...[error] character map file `C' not found: No such file or 
> > > directory
> > >  done
> > > Generation complete.
> > > 
> > > I don't know if this is new or older or if this poses a problem. I can 
> > > provide you with mor details if necessary.
> > > 
> > 
> > The list of locales to be generated is defined by /etc/locale.gen, it
> > looks like there is someting wrong there. Could you please send me a
> > copy of this file?
> 
> I attached the file.

The issue is the "C C" line in that file. Now I have no idea how it
ended up there, as it's not one of the value offered by default in the
debconf template. It only appears there if it is found in the
/etc/locale.gen config file.

Aurelien

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


signature.asc
Description: PGP signature


Bug#921913: locales: character map file `C' not found: No such file or directory

2019-02-20 Thread Aurelien Jarno
On 2019-02-10 08:48, Helge Kreutzmann wrote:
> Package: locales
> Version: 2.28-6
> Severity: minor
> 
> In todays upgrade in my sid chroot I see the following messages
> locales (2.28-6) wird eingerichtet ...
> Generating locales (this might take a while)...
>   de_DE.ISO-8859-1... done
>   de_DE.UTF-8... done
>   en_GB.UTF-8... done
>   en_US.UTF-8... done
>   C.C...[error] character map file `C' not found: No such file or directory
>  done
> Generation complete.
> 
> I don't know if this is new or older or if this poses a problem. I can 
> provide you with mor details if necessary.
> 

The list of locales to be generated is defined by /etc/locale.gen, it
looks like there is someting wrong there. Could you please send me a
copy of this file?

Thanks,
Aurelien

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


signature.asc
Description: PGP signature


Bug#921913: locales: character map file `C' not found: No such file or directory

2019-02-20 Thread Aurelien Jarno
Hi,

On 2019-02-19 08:03, Harald Dunkel wrote:
> Metoo.
> 
> Hopefully this is not too difficult to fix before Buster?

First we have to understand the issue, I am not able to reproduce the
issue and I do not see any recent change that can explain that problem.

Could you please send the content of the /etc/locale.gen file on your
system? It looks like one entry is broken there.

Thanks,
Aurelien

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



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

2019-02-18 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
c8826fa8 by Aurelien Jarno at 2019-02-19T07:46:58Z
debian/patches/git-updates.diff: update from upstream stable branch.

- - - - -


1 changed file:

- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/c8826fa8e3b3733848c7a12bc3bd5bcaaeef8b7b

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/c8826fa8e3b3733848c7a12bc3bd5bcaaeef8b7b
You're receiving this email because of your account on salsa.debian.org.


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

2019-02-18 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
5d4665e8 by Aurelien Jarno at 2019-02-18T08:16:42Z
debian/patches/git-updates.diff: update from upstream stable branch.

- - - - -


2 changed files:

- debian/changelog
- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/5d4665e8a514538ddd9a6756f8f8408aebb7b3a0

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/5d4665e8a514538ddd9a6756f8f8408aebb7b3a0
You're receiving this email because of your account on salsa.debian.org.


Bug#918823: Update on your bug report

2019-02-16 Thread Aurelien Jarno
Hi Richard,

On 2019-02-15 17:03, Richard Hartmann wrote:
> Hi Leopold,
> 
> did you have a chance to run the commands requested by Aurelien? This
> bug is marked critical, but has been stale for more than a month, now.

Leopold answered me privately, I am sorry to not have provided a summary
to the bug log earlier. There was an issue on the system with a
/usr/local/lib/libvirt-lxc.so.0 symlink but it turned out to not be the
issue.

I am personally out of ideas, if someone is able to reproduce the issue
or have ideas about what causes the issue, please don't hesitate to tell
it here.

Aurelien

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



Bug#922213: locales-all: Doesn't provide en_DE.UTF-8

2019-02-14 Thread Aurelien Jarno
Hi,

On 2019-02-13 11:41, Charlemagne Lasse wrote:
> Package: locales-all
> Version: 2.28-6
> Severity: normal
> X-Debbugs-CC: debian-qt-...@lists.debian.org, 
> debian-tex-ma...@lists.debian.org
> 
> 
> 
> It is possible under KDE to change the locale to en_DE.UTF-8/German
> for some specific parts (e.g. time) but it seems to be missing on the
> system even when locales-all is installed.

The en_DE locale doesn't exit in Debian, nor in upstream GNU libc. It's
not going to happen, the en_DK locale exists, but it has been
acknowledged that it was a mistake to create it.

In that precise case, I am not even sure what en_DE means for LC_TIME.
It is supposed to be the way to write the time in English in Germany?
Should it be in the form day/month/year or month/day/year? 12h format
or 24h format?

The locale system has been defined so that you can choose the locale for
a single category. That way you can choose if you want to display the
time in English with the Australian or New-Zeland convention, while
using a different convention for collation or monetary.

> This breaks various things - here for example when I install
> tex-common (via texlive package) and have LC_TIME set to en_DE.UTF-8:

In general KDE should not offer to configure a locale that is not
available on the system. That just creates issues like this one. In
addition the list of available locales can evolve.

I am therefore just tempted to reassign the bug to KDE.

Aurelien

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



Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

2019-02-08 Thread Aurelien Jarno
On 2019-02-08 14:33, Roman Mamedov wrote:
> On Fri, 8 Feb 2019 10:21:41 +0100
> Aurelien Jarno  wrote:
> 
> > What is the content of /etc/default/locale? it looks like you have an
> > additional entry than the LANG one set by dpkg-reconfigure locales.
> 
> "dpkg-reconfigure locales" only writes LANG=C.UTF-8 (or any other accordingly)
> to that file. This results in the "locale" output that I posted above
> (including after a relogin or reboot). There were no lines aside from that
> in /etc/default/locale.

Yes, that's normal that only LANG is set, as it's the one with less
priority. That said there was clearly something setting LC_ALL to
en.US-UTF-8 before, you might want to grep /etc for that. When only LANG
is set, you should get and output like this one:

LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

Note how LC_ALL is unset.

Aurelien

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



Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

2019-02-08 Thread Aurelien Jarno
On 2019-02-07 14:55, Roman Mamedov wrote:
> So for those of us (the entire world), who have been relying on this behavior:
> 
> > * en_US (.UTF-8) is used as the default English locale for all places that
> >   don't have a specific variant (and often even then).  Generally, technical
> >   users use English as a system locale

Please note that the en_US.UTF-8 locale had the 12-hour time for more
than 20 years, for all applications but the date utility. Therefore this
locale was not a reliable way to get a 24-hour time format.

> How do we roll-back what you have done here, and still get en_US.UTF-8 while
> retaining the proper 24-hour time?
> 
> dpkg-reconfigure locales does not list "C.UTF-8" in the main "locales to
> generate" list, but does offer it on the next screen as "Default locale for 
> the
> system environment". After selecting it, we get:
> 
> # locale
> LANG=C.UTF-8
> LANGUAGE=
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=en_US.UTF-8

What is the content of /etc/default/locale? it looks like you have an
additional entry than the LANG one set by dpkg-reconfigure locales.

Also note that you can edit that file and chose a different locale for
each entry, so you can have for example a POSIX way of representing the
time, using a Turkish collation and with a Chilean monetary symbol.

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



[Git][glibc-team/glibc] Pushed new tag debian/2.24-11+deb9u4

2019-02-06 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2.24-11+deb9u4 at GNU Libc Maintainers / 
glibc

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/tree/debian/2.24-11+deb9u4
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][stretch] releasing package glibc version 2.24-11+deb9u4

2019-02-06 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / glibc


Commits:
831185c5 by Aurelien Jarno at 2019-02-06T21:17:48Z
releasing package glibc version 2.24-11+deb9u4

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/831185c5b13dd145e027c3aafd4b0d619a306f75

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/831185c5b13dd145e027c3aafd4b0d619a306f75
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc] Pushed new tag debian/2.28-6

2019-02-05 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2.28-6 at GNU Libc Maintainers / glibc

-- 
View it on GitLab: https://salsa.debian.org/glibc-team/glibc/tree/debian/2.28-6
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] releasing package glibc version 2.28-6

2019-02-05 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
d6442395 by Aurelien Jarno at 2019-02-05T18:55:47Z
releasing package glibc version 2.28-6

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/d6442395e428b674a964701d5d501f1a91543898

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/d6442395e428b674a964701d5d501f1a91543898
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] 2 commits: debian/patches/any/git-libio-stdout-putc.diff: fix puts and putchar output...

2019-02-05 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
80bf3b8b by Aurelien Jarno at 2019-02-05T18:55:19Z
debian/patches/any/git-libio-stdout-putc.diff: fix puts and putchar output with 
change stdout pointer.  Closes: #761300.

- - - - -
76aa4cbf by Aurelien Jarno at 2019-02-05T18:55:19Z
debhelper.in/locales.bug-presubj: drop obsolete file, the dependency mechanism 
for locales has been changes a lot of time ago.

- - - - -


5 changed files:

- debian/changelog
- − debian/debhelper.in/locales.bug-presubj
- + debian/patches/any/git-libio-stdout-putc.diff
- debian/patches/series
- debian/rules


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/93c923f3ec4ea754d70fd76cf8bd5a0c33b26a9c...76aa4cbf69427af2620c787048a0fc1b250b7d02

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/93c923f3ec4ea754d70fd76cf8bd5a0c33b26a9c...76aa4cbf69427af2620c787048a0fc1b250b7d02
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] 3 commits: Update Russian debconf translation, by Lev Lamberov. Closes: #921165.

2019-02-04 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
fbdc09ed by Aurelien Jarno at 2019-02-04T21:15:43Z
Update Russian debconf translation, by Lev Lamberov.  Closes: #921165.

- - - - -
219b2f5f by Aurelien Jarno at 2019-02-04T21:15:43Z
debian/patches/any/local-ldso-disable-hwcap.diff: only check for 
/etc/ld.so.nohwcap on alpha, hurd-i386 and i386. Based on a patch from Josh 
Triplett.  Closes: #908928.

- - - - -
93c923f3 by Aurelien Jarno at 2019-02-04T23:11:24Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - Reject IP addresses with trailing characters (CVE-2016-10739).  Closes:
#920047.
  - Fix wrong return value for memcmp on amd64 and x32 due to mishandling
of most significant bit (CVE-2019-7309).

- - - - -


4 changed files:

- debian/changelog
- debian/patches/any/local-ldso-disable-hwcap.diff
- debian/patches/git-updates.diff
- debian/po/ru.po


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/d440750ee1d35a2625a5a6f3b539a35602d28478...93c923f3ec4ea754d70fd76cf8bd5a0c33b26a9c

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/d440750ee1d35a2625a5a6f3b539a35602d28478...93c923f3ec4ea754d70fd76cf8bd5a0c33b26a9c
You're receiving this email because of your account on salsa.debian.org.


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

2019-02-02 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
d440750e by Aurelien Jarno at 2019-02-02T11:05:38Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - Fix a buffer overflow in string/memory functions on x32 (CVE-2019-6488).

- - - - -


2 changed files:

- debian/changelog
- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/d440750ee1d35a2625a5a6f3b539a35602d28478

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/d440750ee1d35a2625a5a6f3b539a35602d28478
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata][sid] 2 commits: Update Dutch debconf translation, by Frans Spiesschaert. Closes: #920427.

2019-02-02 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / tzdata


Commits:
52608fb1 by Aurelien Jarno at 2019-02-02T11:07:49Z
Update Dutch debconf translation, by Frans Spiesschaert.  Closes: #920427.

- - - - -
71d81b18 by Aurelien Jarno at 2019-02-02T11:10:01Z
Update Russian debconf translation, by Lev Lamberov.  Closes: #920598.

- - - - -


3 changed files:

- debian/changelog
- debian/po/nl.po
- debian/po/ru.po


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/5c4730639dfa75910e9d879130b4848764f7a523...71d81b1817ae8eba595ba405ba0c24494a55909b

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/5c4730639dfa75910e9d879130b4848764f7a523...71d81b1817ae8eba595ba405ba0c24494a55909b
You're receiving this email because of your account on salsa.debian.org.


Bug#920047: glibc: CVE-2016-10739: getaddrinfo should reject IP addresses with trailing characters

2019-01-24 Thread Aurelien Jarno
On 2019-01-21 22:17, Florian Weimer wrote:
> * Salvatore Bonaccorso:
> 
> > CVE-2016-10739[0]:
> > | In the GNU C Library (aka glibc or libc6) through 2.28, the getaddrinfo
> > | function would successfully parse a string that contained an IPv4
> > | address followed by whitespace and arbitrary characters, which could
> > | lead applications to incorrectly assume that it had parsed a valid
> > | string, without the possibility of embedded HTTP headers or other
> > | potentially dangerous substrings.
> >
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> >
> > For further information see:
> >
> > [0] https://security-tracker.debian.org/tracker/CVE-2016-10739
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10739
> > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20018
> >
> > Please adjust the affected versions in the BTS as needed.
> 
> Would it help if I put a backport on the 2.24 upstream branch?
> 

That would indeed help, then we can just pull that branch for the
stretch package. Note that there is already an upload in the pipeline
(bug #917620), I guess we should get that one into stretch first.

Thanks,
Aurelien

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



Bug#704089: tzdata config script prevents non-interactive (re)configuration

2019-01-16 Thread Aurelien Jarno
On 2019-01-15 12:40, Adam Bolte wrote:
> Package: tzdata
> Version: 2018i-0+deb9u1
> Followup-For: Bug #704089
> 
> Dear Maintainer,
> 
> This is still a problem 4 years later, and I unexpectedly found myself
> spending time to track it down when doing configuration
> management. Can we please get the above patch applied *before* the
> Buster soft-freeze on 2019-02-12 (just over a month away)?

I don't think the patch is correct. Debconf is not a registry, the
canonical location for the configuration is the configuration files, not
the debconf database. Quoting debconf-devel(7):

"The issue to watch out for here is that debconf is not intended to be,
and must not be used as a registry."

I think it also applies when DEBCONF_RECONFIGURE is set.

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


signature.asc
Description: PGP signature


[Git][glibc-team/glibc][sid] releasing package glibc version 2.28-5

2019-01-12 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
49767c9f by Aurelien Jarno at 2019-01-12T17:50:29Z
releasing package glibc version 2.28-5

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/49767c9f7de4828220b691b29de0baf60d8a54ec

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/49767c9f7de4828220b691b29de0baf60d8a54ec
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc] Pushed new tag debian/2.28-5

2019-01-12 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2.28-5 at GNU Libc Maintainers / glibc

-- 
View it on GitLab: https://salsa.debian.org/glibc-team/glibc/tree/debian/2.28-5
You're receiving this email because of your account on salsa.debian.org.


Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture

2019-01-11 Thread Aurelien Jarno
On 2019-01-11 16:50, Андрей Доценко wrote:
> >
> > On your side, have you been able to reproduce the problem *without*
> > ASAN, even on a bigger codebase? I wonder if it is actually a side
> > effect of ASAN.
> >
> 
> All *sem_timedwait* calls do not work in the codebase of our project
> without ASAN. So we cannot use i386 hardware in our embedded systems.
> Codebase is about 1000 source files. But the minimal test passes without
> ASAN so I cannot determine what affects sem_timedwait in our project. Any
> thoughts?

Do you use semaphores between 32- and 64-bit processes? That's not
something supported and used to work by chance in older glibc version
(prior to 2.21 IIRC).

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



Bug#918823: libc6: [24945.428485] libvirtd[12553]: segfault at 8 ip 00007fb0f515ba63 sp 00007fff86e08370 error 4 in ld-2.24.so[7fb0f514b000+23000]

2019-01-09 Thread Aurelien Jarno
Hi,

On 2019-01-09 16:25, leopoldotosi wrote:
> 
> Package: libc6
> Version: 2.24-11+deb9u3
> Severity: critical
> Tags: d-i
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> I can not work libvirtd ?-:-(

I am sorry about that.
 
> Reading symbols from virsh...(no debugging symbols found)...done.
> (gdb) set pagination 8
> "on" or "off" expected.
> (gdb) run
> Starting program: /usr/bin/virsh
> 
> Program received signal SIGSEGV, Segmentation fault.
> match_symbol (name=0x7fffe89d "/usr/bin/virsh", ns=0,
> hash=160186580, string=0xaf0b "LIBVIRT_QEMU_0.9.4",
> map=0x77ff69a8,
> verbose=verbose@entry=1, weak=0) at dl-version.c:77
> 77dl-version.c: File o directory non esistente.

The crash happens very early when loading /usr/bin/virsh and resolving
the dependencies. It's not impossible that some files are corrupted.
Which version of libvirt are you using, the one from Debian Stretch?

In order to better understand the problem, would it be possible to send
us the output of the following commands:

- ldd /usr/bin/virsh
- LD_DEBUG=all /usr/bin/virsh

That should help us to better understand the problem.

Thanks,
Aurelien

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



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

2019-01-08 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
7e739b22 by Aurelien Jarno at 2019-01-08T20:19:23Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - any/submitted-workaround-math-errno-gcc-bug.diff: upstreamed.

- - - - -


4 changed files:

- debian/changelog
- − debian/patches/any/submitted-workaround-math-errno-gcc-bug.diff
- debian/patches/git-updates.diff
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/7e739b22185b5aedf6a82f8a5f9d1427da759f11

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/7e739b22185b5aedf6a82f8a5f9d1427da759f11
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/patches/localedata/git-en_US-date_fmt.diff: backport from upstream...

2019-01-07 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
0483616b by Aurelien Jarno at 2019-01-07T22:03:18Z
debian/patches/localedata/git-en_US-date_fmt.diff: backport from upstream 
support for date_fmt for the en_US locale. Closes: #877900.

- - - - -


3 changed files:

- debian/changelog
- + debian/patches/localedata/git-en_US-date_fmt.diff
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/0483616b77a117378a8f5dd3f66c01126d94b90b

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/0483616b77a117378a8f5dd3f66c01126d94b90b
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/control.in/libc: fix nocache Breaks, set it to (<< 1.1-1~). Closes: #918583.

2019-01-07 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
fd8b13cb by Aurelien Jarno at 2019-01-07T21:58:37Z
debian/control.in/libc: fix nocache Breaks, set it to ( 1.1-1~). 
Closes: #918583.

- - - - -


3 changed files:

- debian/changelog
- debian/control
- debian/control.in/libc


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/fd8b13cb1bc71e29115e757646c8499f12cae74c

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/fd8b13cb1bc71e29115e757646c8499f12cae74c
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata][sid] Update German debconf translation, by Holger Wansing. Closes: #918455.

2019-01-07 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / tzdata


Commits:
5c473063 by Aurelien Jarno at 2019-01-07T21:54:30Z
Update German debconf translation, by Holger Wansing.  Closes: #918455.

- - - - -


2 changed files:

- debian/changelog
- debian/po/de.po


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/5c4730639dfa75910e9d879130b4848764f7a523

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/5c4730639dfa75910e9d879130b4848764f7a523
You're receiving this email because of your account on salsa.debian.org.


Bug#877434: Acknowledgement (glibc: [INTL:de] updated German man page translation)

2019-01-04 Thread Aurelien Jarno
On 2019-01-04 18:41, Helge Kreutzmann wrote:
> Hello Aurelien,
> On Fri, Jan 04, 2019 at 06:33:55PM +0100, Aurelien Jarno wrote:
> > On 2019-01-04 15:51, Helge Kreutzmann wrote:
> > > Hello Aurelien,
> > > On Thu, Dec 27, 2018 at 08:17:38PM +0100, Aurelien Jarno wrote:
> > > > On 2018-12-26 22:00, Helge Kreutzmann wrote:
> > > > > Hello Glibc maintainers,
> > > > > more than one year ago I submitted the updated German man page
> > > > 
> > > > Sorry this has been missed, that will be in the next upload.
> > > 
> > > Thanks.
> > > 
> > > > > translation. As the freeze is approaching I (and probably other German
> > > > > speaking users) would be very happy if you could include it in your
> > > > > package so that it is part of the next stable release.
> > > > 
> > > > Note that your update only changes some fuzzy strings, so the German
> > > > translated files will be unchanged.
> > > 
> > > Fixing fuzzy strings (i.e. they are not fuzzy anymore) recompletes the
> > > German translation. I just checked, everything looks fine. Or are
> > 
> > My point is that while the fuzzy is removed from the po file, the
> > resulting German translation is unchanged as it was already correct.
> > Therefore there is no user visible changes.
> 
> Oh, I see what you mean. The change was a pure english one - it did
> not affect the translation. Therefore the correct action (which could
> have been done by you as maintainers as well) was to simply remove the
> "fuzzy" marker. The change *is* user visible, however. With the fuzzy
> marker, the english string is shown, without the translated (German)
> one. 

Except that the English and the translated strings are exactly the same
in that case.

Regards,
Aurelien

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


signature.asc
Description: PGP signature


Bug#877434: Acknowledgement (glibc: [INTL:de] updated German man page translation)

2019-01-04 Thread Aurelien Jarno
Hi,

On 2019-01-04 15:51, Helge Kreutzmann wrote:
> Hello Aurelien,
> On Thu, Dec 27, 2018 at 08:17:38PM +0100, Aurelien Jarno wrote:
> > On 2018-12-26 22:00, Helge Kreutzmann wrote:
> > > Hello Glibc maintainers,
> > > more than one year ago I submitted the updated German man page
> > 
> > Sorry this has been missed, that will be in the next upload.
> 
> Thanks.
> 
> > > translation. As the freeze is approaching I (and probably other German
> > > speaking users) would be very happy if you could include it in your
> > > package so that it is part of the next stable release.
> > 
> > Note that your update only changes some fuzzy strings, so the German
> > translated files will be unchanged.
> 
> Fixing fuzzy strings (i.e. they are not fuzzy anymore) recompletes the
> German translation. I just checked, everything looks fine. Or are

My point is that while the fuzzy is removed from the po file, the
resulting German translation is unchanged as it was already correct.
Therefore there is no user visible changes.

> there some other issues (e.g. new strings I missed) which you want to
> point out?

No, everything is fine.

Regards,
Aurelien

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


signature.asc
Description: PGP signature


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

2019-01-03 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
72b6c62e by Aurelien Jarno at 2019-01-03T15:17:55Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - debian/patches/arm/submitted-gcc-8-kernel-assisted-atomics.diff:
upstreamed.

- - - - -


4 changed files:

- debian/changelog
- − debian/patches/arm/submitted-gcc-8-kernel-assisted-atomics.diff
- debian/patches/git-updates.diff
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/72b6c62e7178f3003b539bf28da223e5a577aae6

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/72b6c62e7178f3003b539bf28da223e5a577aae6
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/debhelper.in/libc.postrm: suidmanager is long gone, remove support for it.

2018-12-31 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
d20a979e by Aurelien Jarno at 2018-12-31T12:57:27Z
debian/debhelper.in/libc.postrm: suidmanager is long gone, remove support for 
it.

- - - - -


2 changed files:

- debian/changelog
- debian/debhelper.in/libc.postrm


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/d20a979e690bd72edb4b06f6146b0c33c01e917e

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/d20a979e690bd72edb4b06f6146b0c33c01e917e
You're receiving this email because of your account on salsa.debian.org.


Bug#910923: $PLATFORM is no longer expanded.

2018-12-31 Thread Aurelien Jarno
On 2018-10-15 00:49, Roman Lebedev wrote:
> On Sun, Oct 14, 2018 at 10:51 PM Aurelien Jarno  wrote:
> >
> > control: severity -1 normal
> > control: retitle -1 libc6: broken support for curly braces DST
> >
> > On 2018-10-13 16:13, Roman Lebedev wrote:
> > > Source: glibc
> > > Version: 2.27-6
> > > Severity: important
> > >
> > > Reproduction:
> > > $ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat
> > > execve("/bin/cat", ["/bin/cat"], 0x55ddc6b820f0 /* 64 vars */) = 0
> > > brk(NULL)   = 0x56046d9c1000
> > > access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
> > > directory)
> > > readlink("/proc/self/exe", "/bin/cat", 4096) = 8
> > > openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
> > > such file or directory)
> Hm actually wait, i think i'm confused here.
> Both the ${PLATFORM} and $PLATFORM seem to expand just fine.
> 
> $ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat | grep PLATFORM
> ...
> openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22},
> {iov_base="/sss/${PLATFORM}/", iov_len=21}, {iov_base="' from ",
> iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be
> preloaded (", iov_len=22}, {iov_base="cannot open shared object file",
> iov_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so:
> object '/sss/${PLATFORM}/' from LD_PRELOAD cannot be preloaded
> (cannot open shared object file): ignored.
> ) = 124
> 
> $ strace -ELD_PRELOAD='/sss/$PLATFORM/'  -s300  /bin/cat | grep PLATFORM
> ...
> openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22},
> {iov_base="/sss/$PLATFORM/", iov_len=19}, {iov_base="' from ",
> iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be
> preloaded (", iov_len=22}, {iov_base="cannot open shared object file",
> io
> v_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so:
> object '/sss/$PLATFORM/' from LD_PRELOAD cannot be preloaded
> (cannot open shared object file): ignored.
> ) = 122
> 
> It clearly expanded PLATFORM to x86_64 in both cases, do you agree?
> 
> So whatever i'm seeing is something else, might be caused by docker.
> 

I agree that both are correctly expanded. I also looked again calmly on
my system, and I confirm that both are expanded. So it looks like there
is no bug there.

Aurelien

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



Bug#917871: Wrong translation in the German glibc translation

2018-12-31 Thread Aurelien Jarno
Dear German translation team,

Alexander Barton has reported through the Debian BTS an issue in the
German translation of the GNU libc, most precisely on the nscd program.
Both "positive" and "negative" are translated by "positiven". You can
find the details here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917871

Regards,
Aurelien

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


signature.asc
Description: PGP signature


[Git][glibc-team/tzdata] Pushed new tag debian/2018i-0+deb9u1

2018-12-31 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2018i-0+deb9u1 at GNU Libc Maintainers / 
tzdata

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/tree/debian/2018i-0+deb9u1
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata][stretch] releasing package tzdata version 2018i-0+deb9u1

2018-12-31 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / tzdata


Commits:
d39cfe41 by Aurelien Jarno at 2018-12-31T09:44:03Z
releasing package tzdata version 2018i-0+deb9u1

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/d39cfe4198620b6848a3427b803fedfe3ca72bd9

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/commit/d39cfe4198620b6848a3427b803fedfe3ca72bd9
You're receiving this email because of your account on salsa.debian.org.


Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install

2018-12-30 Thread Aurelien Jarno
On 2017-10-07 13:47, Steve Langasek wrote:
> On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote:
> > Control: reassign -1 locales
> 
> > On Fri, Oct 06, 2017 at 05:29:20PM -0400, debianuser2017_ wrote:
> > > When Debian 9 is installed with the en-us locale selected, the clock 
> > > defaults
> > > to 24 hour time in the resulting install. This is odd because the normal 
> > > means
> > > of representing the time in the area covered by en-us is to separate the 
> > > day
> > > into two 12-hour segments. (localization issue)



> No, this is a nonsense argument.  The en_US.UTF-8 locale must reflect the
> actual usage in the US.  "Well, systems use it as a default, so we're going
> to overload it" would be idiotic.

Totally correct, the locales should reflect the actual usage in a country
and language, which is not always something easy to do and often
controversial.

> There's also no reason to believe that's actually what has happened here.

Now that things have calm down, let's ignore the various hypothesis and
let's look at the code. The two constants from LC_TIME representing the
time, as defined by POSIX and ISO/IEC 14652 are:

- D_T_FMT: String for formatting date and time.
- T_FMT: Time format string.

| $ LC_TIME=en_US.UTF-8 locale -c LC_TIME -k | egrep '^t_fmt=|^d_t_fmt='
| d_t_fmt="%a %d %b %Y %r %Z"
| t_fmt="%r"

In both cases the "%r" format specification is used which correspond to
the time in a.m. or p.m. notation. This two constants correspond in
strftime(3) respectively to the "%c" format specification (The preferred
date and time representation for the current locale) and the "%X" format
specification (The preferred time representation for the current locale
without the date). This can be confirmed with the date utility:

| $ LC_TIME=C.UTF-8 date +%c
| Sun Dec 30 23:21:57 2018
| $ LC_TIME=en_GB.UTF-8 date +%c
| Sun 30 Dec 2018 23:21:57 CET
| $ LC_TIME=en_US.UTF-8 date +%c
| Sun 30 Dec 2018 11:21:57 PM CET
| $ LC_TIME=C.UTF-8 date +%X
| 23:21:57
| $ LC_TIME=en_GB.UTF-8 date +%X
| 23:21:57
| $ LC_TIME=en_US.UTF-8 date +%X
| 11:21:57 PM

In addition to POSIX and ISO/IEC 14652, the GNU libc also defines the 
"date_fmt" constant, which is use by the date(1) utility to display the
date and time. It's an optional field, which defaults to
"%a %b %e %H:%M:%S %Z %Y" if not defined. For what I understand the
goal of this new constant is to always display the timezone, as the
default way of displaying the time usually does not contain it for
countries no spanning multiple time zones.


 
> As to the actual bug, I don't know if this represents a deliberate change or
> if it's accidental.  Speaking for myself as an American, I can confirm the
> described behavior... and can say that it completely escaped my notice,
> because I prefer 24h time whenever given the option.  Nevertheless, if this
> bug is to be deemed 'wontfix', it must be done solely with respect to what
> is correct for the *US* locale.

The "date_fmt" constant has been added back in 2000, and the en_US
locale never got it defined. Actually not that many locales define this
constant as the default is often sane. It should only be used by date(1)
so other applications should correctly display the time in 12h format.

For me the proper way to fix this bug would be to define "date_fmt" for
the en_US locale. I don't think this should be controversial given both
"t_fmt" and "d_t_fmt" are already in 12 hours format. I will propose a
patch upstream in that regard, as I prefer to avoid diverging on locales
aspect.

Regards,
Aurelien

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


signature.asc
Description: PGP signature


Bug#909047: libc6.preinst: possible typo in 's/\bsamaba\b/smbd/g'

2018-12-30 Thread Aurelien Jarno
On 2018-09-17 22:30, Ansgar Burchardt wrote:
> Package: libc6
> Version: 2.27-6
> Severity: normal
> 
> libc6.preinst includes:
> 
>   -e's/\bsamaba\b/smbd/g'
> 
> This looks like a typo to me.  I assume it should be samba instead of
> samaba?

Good catch thanks. It will be fixed in the next upload.

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



[Git][glibc-team/glibc][sid] debian/script.in/nsscheck.sh: fix a typo s/samaba/samba/. Closes: #909047.

2018-12-30 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
593a2a58 by Aurelien Jarno at 2018-12-30T19:46:01Z
debian/script.in/nsscheck.sh: fix a typo s/samaba/samba/. Closes: #909047.

- - - - -


2 changed files:

- debian/changelog
- debian/script.in/nsscheck.sh


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/593a2a5821c13dca9b56482cc42213711bc0412e

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/593a2a5821c13dca9b56482cc42213711bc0412e
You're receiving this email because of your account on salsa.debian.org.


Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture

2018-12-30 Thread Aurelien Jarno
Hi,

On 2018-08-22 13:02, Андрей Доценко wrote:
> Package: libc6
> Version: 2.24-11+deb9-u3
> 
> Using sem_timedwait on i686 gives random results. In out proprietary
> software semaphore used by two processes and located in shared memory
> mapped with mmap. All works under amd64 architecture and under another some
> distibutions. But under Debian Stretch amd64 sem_timedwait always blocks
> for timeout and returns ETIMEOUT error. Meanwhile it acquires the lock
> decreasing semaphore value.
> 
> I've tried to make test for this bug. Test reproduces bug only with ASAN
> enabled. Without ASAN enabled it always passes. I've attached test but
> without ASAN support to show that I don't miss anything. I can modify test
> to enable ASAN support but if somebody ask.

Thanks, I have been able to reproduce the problem here, even with glibc
2.29. I have attached a version which doesn't need cmake nor check. 

On your side, have you been able to reproduce the problem *without*
ASAN, even on a bigger codebase? I wonder if it is actually a side
effect of ASAN.

> I've discovered that symbols used by i686 are different from those from
> amd64. On amd64 symbols are:
> ~$ nm "${PROJ_PATH}/Docker/debian/9/amd64/test-bugs/test-bugs"  | grep sem_
>  U sem_destroy@@GLIBC_2.2.5
>  U sem_getvalue@@GLIBC_2.2.5
>  U sem_init@@GLIBC_2.2.5
>  U sem_post@@GLIBC_2.2.5
>  U sem_timedwait@@GLIBC_2.2.5
> 004019b0 t test_process_sem_timedwait
> 004011c0 t test_process_sem_timedwait_nolock
> 
> But under i686 symbols are different:
> ~$ nm "${PROJ_PATH}/Docker/debian/9/i386/test-bugs/test-bugs"  | grep sem_
>  U sem_destroy@@GLIBC_2.1
>  U sem_getvalue@@GLIBC_2.1
>  U sem_init@@GLIBC_2.1
>  U sem_post@@GLIBC_2.1
>  U sem_timedwait@@GLIBC_2.2
> 08049f50 t test_process_sem_timedwait
> 08048ee0 t test_process_sem_timedwait_nolock
> 
> As you can see symbols are different for i686. Version of sem_init,
> sem_wait, sem_post, sem_destroy and sem_getvalue is GLIBC_2.1, but version
> of sem_timedwait is GLIBC_2.2.

This is perfectly normal. glibc 2.2.5 is the first glibc version that
supported the amd64 architecture.

> Replacing sem_timedwait with sem_wait makes all work on i686 architecture.
> So sem_wait is ok, but sem_timedwait is not.

I confirm that.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
/* Build with: gcc -o bug906917 bug906917.c -pthread -fsanitize=address */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
	sem_t *sem =
	mmap(NULL, sizeof(*sem), PROT_READ | PROT_WRITE,
		 MAP_SHARED | MAP_ANONYMOUS, -1, 0);
	int r;
	r = sem_init(sem, 1, 0);
	if (r == -1) {
		perror("sem_init");
	}
	assert(r == 0);

	pid_t pid = fork();
	if (pid == 0) {
		r = sem_post(sem);
		if (r == -1) {
			exit(1);
		}
		exit(0);
	}
	assert(pid > 0);

	int exit_status;
	pid_t child_pid;
	do {
		child_pid = waitpid(pid, _status, 0);
	}
	while ((child_pid == -1) && (errno == EINTR));
	if (child_pid == -1) {
		perror("waitpid");
	}
	assert(child_pid == pid);
	assert(WIFEXITED(exit_status));
	assert(WEXITSTATUS(exit_status) == 0);

	struct timespec abstime;
	r = clock_gettime(CLOCK_REALTIME, );
	assert(r == 0);
	abstime.tv_sec += 5;

	int value = -1;
	sem_getvalue(sem, );
	assert(value == 1);

	do {
		r = sem_timedwait(sem, );
	}
	while ((r == -1) && (errno == EINTR));
	if (r == -1) {
		perror("sem_timedwait");
	}
	assert(r == 0);

	value = -1;
	sem_getvalue(sem, );
	assert(value == 0);

	sem_destroy(sem);

	return 0;
}


Bug#914999: [libc6] Locking problems into libc6

2018-12-30 Thread Aurelien Jarno
On 2018-12-12 17:11, Roman Savochenko wrote:
> Hello, Aurelien
> 
> On 12/4/18 1:24 PM, Roman Savochenko wrote:
> > On 11/29/18 9:13 PM, Aurelien Jarno wrote:
> > > > 1. For my program, I was needed to create extra locking about
> > > > the function
> > > > getaddrinfo(), but that resolved the problem only for my calls
> > > > but for the
> > > > external libraries like to MySQL, MariaDB I yet have the crashes and it
> > > > cannot be fixed at all.
> > > Can you give more details about the issue, the symptoms, possible crash
> > > backtrace, way to reproduce it. Without this details, there are very few
> > > chances to be able to fix the bug.
> > 
> > Yes, I had there a crash, but it appeared next as a problem into
> > libMariaDB (Bug#915515). Also I had early observed differences into real
> > address passed to getaddrinfo() and taken from the real connection, what
> > I have not observed now. So this item I remove from causes to GLibC
> > problems while.
> 
> Vice versa, the first problem is actual one for GLibC since:
> 
>  * I have observed twice the difference, please see on the included
>screenshot.

I indeed see two different IPs circled in red. Now I don't get what they
are, if they should be different or not and how that relates to glibc.

>  * Also I have seen once for very long locking into the function
>getaddrinfo()->poll() for some VPN (FortiClient in the case), see to
>the crash report, got after the program termination by SIGSEGV.

poll() has nothing to do with locking, it just hang there waiting for an
answer to a DNS request sent by the functions called through
getaddrinfo(). According to the trace, the timeout is set to about 5
seconds. The others thread waiting for poll() are called from
libglib-2.0 and from libxcb.so.1.

As for the segmentation fault, it happens in pthread_cond_timedwait.S
called directly from libQt5Core.so.5. Without more info, it's difficult
to say if it's due to a bug in glibc or if the argument passed to this
function are corrupted, for example because the data pointed by QMutex*
are corrupted. Do you have another way to reproduce the issue that is
actually easier than using openscada?

> > There are thousands of packages in different versions between Debian 8
> > > and Debian 9. You have found it's not related to the kernel, but I fail
> > > to see how that shows it's a libc6 issue. For example when you have
> > > tried the kernel from Debian 9 in Debian 8, have you also tried with the
> > > rtl8192 firmware from Debian 9?
> > I will compare the firmware, thanks.
> I have installed of equal package firmware-realtek 20161130-4 on Debian 9
> and this problem is actual yet.
> > > Anyway if we want to know that the problem is related with glibc, please
> > > try to install glibc packages (libc*, possibly locales* and nscd if
> > > needed) from Debian 9 onto a working Debian 8 installation and see if
> > > the problem appears.
> > I going to try that also, thanks.
> 
> I have updated the package libc6 up to version 2.24 on Debian 8 and both of
> the two last item, RTL8192eu and WIFI HotSpot, continue to work.
> 
> Where can I move then the problems with RTL8192eu and WIFI HotSpot on Debian
> 9?

The best would be to look the logs in /var/log/syslog to check what is
the issue. It could be a dhcp issue, a network-manager issue or a
wpasupplicant issue depending what you are using.

Regards,
Aurelien

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



[Git][glibc-team/tzdata] Pushed new tag debian/2018h-0+deb9u1

2018-12-30 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2018h-0+deb9u1 at GNU Libc Maintainers / 
tzdata

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/tree/debian/2018h-0+deb9u1
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata][stretch] 3 commits: New upstream version, affecting the following past and future timestamps:

2018-12-30 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / tzdata


Commits:
965ce358 by Aurelien Jarno at 2018-12-30T13:04:00Z
New upstream version, affecting the following past and future timestamps:

* New upstream version, affecting the following past and future
  timestamps:
  - Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21. A new
zone Asia/Qostanay has been added, because Qostanay, Kazakhstan
didnt move.
  - Metlakatla, Alaska observes PST this winter only.

- - - - -
b9fb92a8 by Aurelien Jarno at 2018-12-30T13:11:29Z
Import templates and translations

- - - - -
707e3753 by Aurelien Jarno at 2018-12-30T13:11:39Z
releasing package tzdata version 2018h-0+deb9u1

- - - - -


30 changed files:

- debian/changelog
- debian/po/be.po
- debian/po/bg.po
- debian/po/ca.po
- debian/po/cs.po
- debian/po/da.po
- debian/po/de.po
- debian/po/en.po
- debian/po/es.po
- debian/po/eu.po
- debian/po/fi.po
- debian/po/fr.po
- debian/po/gl.po
- debian/po/gu.po
- debian/po/he.po
- debian/po/hr.po
- debian/po/hu.po
- debian/po/id.po
- debian/po/it.po
- debian/po/ja.po
- debian/po/ku.po
- debian/po/lt.po
- debian/po/ml.po
- debian/po/nl.po
- debian/po/pl.po
- debian/po/pt.po
- debian/po/pt_BR.po
- debian/po/ru.po
- debian/po/sk.po
- debian/po/sq.po


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/3b7e89d9a730e9f1d1b6021d12b53fdca18694fd...707e375349fc83b7800ac9f9609de637c106e634

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/3b7e89d9a730e9f1d1b6021d12b53fdca18694fd...707e375349fc83b7800ac9f9609de637c106e634
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata] Pushed new tag debian/2018h-1

2018-12-29 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2018h-1 at GNU Libc Maintainers / tzdata

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/tree/debian/2018h-1
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/tzdata][sid] 3 commits: New upstream version, affecting the following past and future timestamps:

2018-12-29 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / tzdata


Commits:
39acdb6c by Aurelien Jarno at 2018-12-29T23:10:32Z
New upstream version, affecting the following past and future timestamps:

* New upstream version, affecting the following past and future
  timestamps:
  - Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21. A new
zone Asia/Qostanay has been added, because Qostanay, Kazakhstan
didnt move.
  - Metlakatla, Alaska observes PST this winter only.

- - - - -
25967b02 by Aurelien Jarno at 2018-12-29T23:14:07Z
Import templates and translations

- - - - -
5bd05419 by Aurelien Jarno at 2018-12-29T23:14:36Z
releasing package tzdata version 2018h-1

- - - - -


30 changed files:

- debian/changelog
- debian/po/be.po
- debian/po/bg.po
- debian/po/ca.po
- debian/po/cs.po
- debian/po/da.po
- debian/po/de.po
- debian/po/en.po
- debian/po/es.po
- debian/po/eu.po
- debian/po/fi.po
- debian/po/fr.po
- debian/po/gl.po
- debian/po/gu.po
- debian/po/he.po
- debian/po/hr.po
- debian/po/hu.po
- debian/po/id.po
- debian/po/it.po
- debian/po/ja.po
- debian/po/ku.po
- debian/po/lt.po
- debian/po/ml.po
- debian/po/nl.po
- debian/po/pl.po
- debian/po/pt.po
- debian/po/pt_BR.po
- debian/po/ru.po
- debian/po/sk.po
- debian/po/sq.po


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/2d157aa790f2f67beb172b91e335a436032121d3...5bd05419dd4a79a4039b11cdd6197ef8b5917fda

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/2d157aa790f2f67beb172b91e335a436032121d3...5bd05419dd4a79a4039b11cdd6197ef8b5917fda
You're receiving this email because of your account on salsa.debian.org.


Bug#911822: dpkg: cycle found while processing triggeres of libc-bin package

2018-12-29 Thread Aurelien Jarno
control: tag -1 + moreinfo

Hi,

On 2018-10-25 23:18, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2018-10-25 at 09:52:38 +0200, Giacomo wrote:
> > Package: libc-bin
> > Version: 2.27-6
> 
> > I upgraded from debian stable (strecth) to debian testing, and now when I
> > execute apt-get upgrade I always get this error:
> > Processing triggers for libc-bin (2.27-6) ...
> > 
> > dpkg: cycle found while processing triggers:
> >  chain of packages whose triggers are or may be responsible:
> >   libc-bin -> man-db
> >  packages' pending triggers which are or may be unresolvable:
> >   man-db: /usr/share/man
> >   libc-bin: ldconfig
> > dpkg: error processing package man-db (--configure):
> >  triggers looping, abandoned
> > Processing triggers for libc-bin (2.27-6) ...
> > Processing triggers for libc-bin (2.27-6) ...
> > dpkg: cycle found while processing triggers:
> >  chain of packages whose triggers are or may be responsible:
> >   libc-bin -> libc-bin -> libc-bin
> >  packages' pending triggers which are or may be unresolvable:
> >   libc-bin: ldconfig
> > dpkg: error processing package libc-bin (--configure):
> >  triggers looping, abandoned
> > Errors were encountered while processing:
> >  man-db
> >  libc-bin
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Could you run «dpkg --audit». And then send that output and a tarball
> with some of the dpkg database files, generated like this:
> 
>   $ tar -caf dpkg-911822.tar.xz /var/lib/dpkg/{status,triggers,updates}
> 
> Take into account this might perhaps contain sensitive information, so
> you might want to make sure before sending it to the BTS that it does
> not, the BTS might even reject it if it's too big, or alternatively
> send it directly to me.
> 
> Does, running just «dpkg --configure --pending» solve the issue?

Any news on this issue? Without the requested details, it will be
difficult to debug it as it is not reproducible.

Thanks,
Aurelien

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



[Git][glibc-team/glibc][stretch] debian/debhelper.in/libc.postinst, script.in/nsscheck.sh: check for postgresql...

2018-12-29 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / glibc


Commits:
c8de3337 by Aurelien Jarno at 2018-12-29T11:42:08Z
debian/debhelper.in/libc.postinst, script.in/nsscheck.sh: check for postgresql 
in NSS check.  Closes: #710275.

- - - - -


3 changed files:

- debian/changelog
- debian/debhelper.in/libc.postinst
- debian/script.in/nsscheck.sh


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/c8de333774c51e48246ff284004fb8ae0668f4f1

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/c8de333774c51e48246ff284004fb8ae0668f4f1
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc] Pushed new tag debian/2.28-4

2018-12-29 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2.28-4 at GNU Libc Maintainers / glibc

-- 
View it on GitLab: https://salsa.debian.org/glibc-team/glibc/tree/debian/2.28-4
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] releasing package glibc version 2.28-4

2018-12-29 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
83052f1d by Aurelien Jarno at 2018-12-29T10:04:36Z
releasing package glibc version 2.28-4

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/83052f1d39821677ffc796fe38d1bf1326aae8b6

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/83052f1d39821677ffc796fe38d1bf1326aae8b6
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] 4 commits: debian/patches/submitted-gcc-8-kernel-assisted-atomics.diff: fix kernel...

2018-12-28 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
2d7f9eee by Aurelien Jarno at 2018-12-29T00:55:54Z
debian/patches/submitted-gcc-8-kernel-assisted-atomics.diff: fix kernel 
assisted atomics on armel with GCC 8.

- - - - -
7f7b36d1 by Aurelien Jarno at 2018-12-29T00:56:56Z
debian/control.in/main, debian/sysdeps/armel.mk: build with GCC 8 on armel.

- - - - -
a70d38fe by Aurelien Jarno at 2018-12-29T01:07:21Z
debian/patches/any/submitted-workaround-math-errno-gcc-bug.diff: workaround GCC 
bug BZ #88576 / Debian #917115 by not using -fmath-errno outside of libm.  
Closes: #916779.

- - - - -
b6b46b45 by Aurelien Jarno at 2018-12-29T01:08:39Z
debian/patches/riscv64/git-thread-debugging.diff: fix thread debugging in gdb 
on riscv64.

- - - - -


8 changed files:

- debian/changelog
- debian/control
- debian/control.in/main
- + debian/patches/any/submitted-workaround-math-errno-gcc-bug.diff
- + debian/patches/arm/submitted-gcc-8-kernel-assisted-atomics.diff
- + debian/patches/riscv64/git-thread-debugging.diff
- debian/patches/series
- debian/sysdeps/armel.mk


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/4b7dcaa2b7e36526076a842e5f68a7b8d2d0e8d0...b6b46b45200f65fa0ac54e0edf58208d90d7a823

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/4b7dcaa2b7e36526076a842e5f68a7b8d2d0e8d0...b6b46b45200f65fa0ac54e0edf58208d90d7a823
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][stretch] Fix a use after free in pthread_create(). Closes: #916925.

2018-12-28 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / glibc


Commits:
c1781508 by Aurelien Jarno at 2018-12-29T00:43:32Z
Fix a use after free in pthread_create().  Closes: #916925.

- - - - -


2 changed files:

- debian/changelog
- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/c17815083577c75136fc7a1c4052a655d20fee7f

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/c17815083577c75136fc7a1c4052a655d20fee7f
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/testsuite-xfail-debian.mk: whitelist tests that sometimes fail in a...

2018-12-28 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
4b7dcaa2 by Aurelien Jarno at 2018-12-29T00:30:09Z
debian/testsuite-xfail-debian.mk: whitelist tests that sometimes fail in a 
riscv64 QEMU VM, but not on a HiFive Unleashed board.

- - - - -


2 changed files:

- debian/changelog
- debian/testsuite-xfail-debian.mk


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/4b7dcaa2b7e36526076a842e5f68a7b8d2d0e8d0

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/4b7dcaa2b7e36526076a842e5f68a7b8d2d0e8d0
You're receiving this email because of your account on salsa.debian.org.


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

2018-12-28 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / glibc


Commits:
618bb769 by Aurelien Jarno at 2018-12-28T22:41:59Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - Fix stack guard size accounting and reduce stack usage during
unwinding to avoid segmentation faults on CPUs with AVX512-F.  Closes:
#903554.

- - - - -


2 changed files:

- debian/changelog
- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/618bb769243cf1069a64dd0e56cddfa584735aea

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/618bb769243cf1069a64dd0e56cddfa584735aea
You're receiving this email because of your account on salsa.debian.org.


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

2018-12-28 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
0a2f47ae by Aurelien Jarno at 2018-12-28T10:54:33Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - debian/patches/any/submitted-sigaction-sa-restorer.diff: upstreamed.

- - - - -


4 changed files:

- debian/changelog
- − debian/patches/any/git-sigaction-sa-restorer.diff
- debian/patches/git-updates.diff
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/0a2f47aee88c7f7a4678ee981784b5be6196c8cd

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/0a2f47aee88c7f7a4678ee981784b5be6196c8cd
You're receiving this email because of your account on salsa.debian.org.


Bug#877434: Acknowledgement (glibc: [INTL:de] updated German man page translation)

2018-12-27 Thread Aurelien Jarno
On 2018-12-26 22:00, Helge Kreutzmann wrote:
> Hello Glibc maintainers,
> more than one year ago I submitted the updated German man page

Sorry this has been missed, that will be in the next upload.

> translation. As the freeze is approaching I (and probably other German
> speaking users) would be very happy if you could include it in your
> package so that it is part of the next stable release.

Note that your update only changes some fuzzy strings, so the German
translated files will be unchanged.

Aurelien

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


signature.asc
Description: PGP signature


[Git][glibc-team/glibc][sid] 2 commits: debian/local/manpages/*: remove manpages that are not installed in the binary packages.

2018-12-27 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
72b7a85e by Aurelien Jarno at 2018-12-27T19:08:30Z
debian/local/manpages/*: remove manpages that are not installed in the binary 
packages.

- - - - -
8eb70102 by Aurelien Jarno at 2018-12-27T19:19:59Z
debian/local/manpages/po/de.po: update German manpages translations, by Helge 
Kreutzmann. Closes: #877434.

- - - - -


10 changed files:

- debian/changelog
- − debian/local/manpages/gai.conf.5
- − debian/local/manpages/glibcbug.1
- − debian/local/manpages/ld.so.8
- − debian/local/manpages/ldconfig.8
- − debian/local/manpages/ldd.1
- − debian/local/manpages/nscd_nischeck.8
- debian/local/manpages/po/de.po
- − debian/local/manpages/zdump.1
- − debian/local/manpages/zic.8


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/aab1a90d7938322ab6f70b58c7846ddab1d0759d...8eb70102892fde2d2a5ef68d4e2a0f282a55fea2

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/aab1a90d7938322ab6f70b58c7846ddab1d0759d...8eb70102892fde2d2a5ef68d4e2a0f282a55fea2
You're receiving this email because of your account on salsa.debian.org.


Bug#916415: nocache broken with glibc 2.28: several programs just hang in call to futex(..., FUTEX_WAIT_PRIVATE, 2, NULL)

2018-12-22 Thread Aurelien Jarno
control: reassign -1 nocache
control: tag -1 + patch

On 2018-12-14 07:44, Aurelien Jarno wrote:
> control: forwarded -1 https://github.com/Feh/nocache/issues/34
> 
> On 2018-12-14 13:33, Paul Wise wrote:
> > Package: nocache/1.0-1,libc6/2.28-2
> > Severity: critical
> > Justification: breaks unrelated software
> > Usertags: hang
> > 
> > The upgrade from libc6 2.27-8 to 2.28-2 breaks nocache; some programs,
> > when run under it (but not all of them), hang in a call to read/futex:
> 
> I haven't looked at it in details, but at least accorded to the upstream
> bug, it seems to be an issue on the nocache side:
> 
> https://github.com/Feh/nocache/issues/34

There is now an upstream commit fixing the issue on the nocache side:

https://github.com/Feh/nocache/commit/e4e77a48528739188dccbdbd8b4d2d2d49aa0d99


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


signature.asc
Description: PGP signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
control: clone 916779 -1
control: reassign -1 gcc-8
control: retitle -1 gcc-8: --fno-math-errno causes GCC to consider that malloc 
does not set errno
control: submitted -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576

On 2018-12-22 13:37, Aurelien Jarno wrote:
> This is not what happens, errno is not set to ENOMEM in strerror_() but
> in strerror(). The problem is that the malloc implementation when run
> under QEMU sets errno to ENOMEM, despite successfully allocating the
> memory. errno is supposed to be saved around the malloc call:
> 
>   saved_errno = errno;
>   if (buf == NULL) 
> buf = malloc (1024);
>   __set_errno (saved_errno); 
> 
> That said, when compiled with -fno-math-errno, GCC optimizes out
> saving and restoring errno around the malloc call. I am not sure if this
> is a GCC bug or a bug in the GCC documentation.

This has been confirmed to be a GCC bug, here is the upstream bug
report:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576

As this bug is likely going to be workarounded in glibc, I am cloning
this bug and reassigning the clone to the gcc-8 package. I'll close the
glibc one when adding the workaround or a bumped build-dependency on
gcc-8.

Regards,
Aurelien

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


signature.asc
Description: PGP signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-22 19:42, Tim Rühsen wrote:
> On 22.12.18 16:56, Aurelien Jarno wrote:
> > The problem is that qemu-arm does not provide a heap to the program, so
> > glibc fails to alloc memory through brk. This causes malloc to switch to
> > mmap based memory allocation, and this also sets errno to ENOMEM.
> > 
> > printf also calls malloc, so the malloc implementation switches to
> > mmap based memory allocation at this moment. This is remembered through
> > the life of the program. When strerror then calls malloc(1024), the
> > allocation is done directly through mmap and errno is not set to ENOMEM.

Setting errno to ENOMEM happens during the call to MORECORE/sbrk in 
malloc/malloc.c in the following lines of the sysmalloc function:

|  if (size > 0)
|{
|  brk = (char *) (MORECORE (size));
|  LIBC_PROBE (memory_sbrk_more, 2, brk, size);
|}

Note however that clobbering errno is allowed even in case of success,
unless the contrary is specifically documented.

> > That's why you do not see the issue.
> > 
> > To reproduce the issue, you therefore need the following conditions:
> > - The kernel or QEMU does not provide a heap to the program
> > - malloc is not called (implicitly or explicitly) before the call to
> >   strerror
> > - strerror is called with an invalid error number.
> > 
> > If all of this 3 conditions are not met, the bug does not appear.
> 
> That is a good explanation and makes sense to me, thank you, Aurelien.
> 
> At least we can work around that issue now.
> 
> BTW, how do you debug cross-compiled executables ? There is no cross-gdb
> packaged in debian (or is there ?). Building that from scratch seems too
> time-intensive...

I have been rebuilding glibc, directly modifying the code being
debugged. ccache is really useful in that case.

Regards,
Aurelien

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


signature.asc
Description: PGP signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-22 16:24, Tim Rühsen wrote:
> On 22.12.18 13:37, Aurelien Jarno wrote:
> > On 2018-12-21 12:58, Tim Rühsen wrote:
> >> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> >>> On 2018-12-21 11:51, Tim Rühsen wrote:
> >>>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> >>>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
> >>>>>> On 2018-12-18 21:34, Aurelien Jarno wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
> >>>>>>>> Package: libc6-armhf-cross
> >>>>>>>> Version: 2.28-2cross2
> >>>>>>>> Severity: normal
> >>>>>>>>
> >>>>>>>> Dear Maintainer,
> >>>>>>>>
> >>>>>>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> >>>>>>>>
> >>>>>>>> The expected errno value would be either EINVAL or not touching errno
> >>>>>>>> at all.
> >>>>>>>>
> >>>>>>>> This behavior is relatively new and causes some CI cross builds to 
> >>>>>>>> fail.
> >>>>>>>> The failing test is a gnulib test (test-strerror.c).
> >>>>>>>>
> >>>>>>>
> >>>>>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> >>>>>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> >>>>>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> >>>>>>> think it's a qemu bug.
> >>>>>>
> >>>>>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> >>>>>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> >>>>>
> >>>>> It seems to have been caused by this upstream patch:
> >>>>>
> >>>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> >>>>> | Author: Wilco Dijkstra 
> >>>>> | Date:   Thu Mar 15 17:57:03 2018 +
> >>>>> | 
> >>>>> | Add support for sqrt asm redirects
> >>>>> | 
> >>>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
> >>>>> in GLIBC.
> >>>>> | The goal is to enable GCC to do the inlining, and if this fails 
> >>>>> call the
> >>>>> | __ieee754_sqrt function.  This is done by internally declaring 
> >>>>> sqrt with asm
> >>>>> | redirects.  The compat symbols and sqrt wrappers need to disable 
> >>>>> the redirect.
> >>>>> | The redirect is also disabled if there are already redirects 
> >>>>> defined when
> >>>>> | using -ffinite-math-only.
> >>>>> | 
> >>>>> | All math functions (but not math tests, non-library code and 
> >>>>> libnldbl) are
> >>>>> | built with -fno-math-errno which means GCC will typically inline 
> >>>>> sqrt as a
> >>>>> | single instruction.  This means targets are no longer forced to 
> >>>>> add a special
> >>>>> | inline for sqrt.
> >>>>> | 
> >>>>> | * include/math.h (sqrt): Declare with asm redirect.
> >>>>> | (sqrtf): Likewise.
> >>>>> | (sqrtl): Likewise.
> >>>>> | (sqrtf128): Likewise.
> >>>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but 
> >>>>> build testsuite,
> >>>>> | nonlib and libnldbl with -fmath-errno.
> >>>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> >>>>> | * math/w_sqrt_template.c: Likewise.
> >>>>> | * math/w_sqrtf_compat.c: Likewise.
> >>>>> | * math/w_sqrtl_compat.c: Likewise.
> >>>>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> >>>>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> >>>>> | * sysdeps/generic/math-type-macros-float128.h: Remove 
> >>>>> math.h and
> >>>>> | 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-21 12:19, Tim Rühsen wrote:
> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> > On 2018-12-21 11:51, Tim Rühsen wrote:
> >> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> >>> On 2018-12-18 22:11, Aurelien Jarno wrote:
> >>>> On 2018-12-18 21:34, Aurelien Jarno wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
> >>>>>> Package: libc6-armhf-cross
> >>>>>> Version: 2.28-2cross2
> >>>>>> Severity: normal
> >>>>>>
> >>>>>> Dear Maintainer,
> >>>>>>
> >>>>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> >>>>>>
> >>>>>> The expected errno value would be either EINVAL or not touching errno
> >>>>>> at all.
> >>>>>>
> >>>>>> This behavior is relatively new and causes some CI cross builds to 
> >>>>>> fail.
> >>>>>> The failing test is a gnulib test (test-strerror.c).
> >>>>>>
> >>>>>
> >>>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> >>>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> >>>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> >>>>> think it's a qemu bug.
> >>>>
> >>>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> >>>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> >>>
> >>> It seems to have been caused by this upstream patch:
> >>>
> >>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> >>> | Author: Wilco Dijkstra 
> >>> | Date:   Thu Mar 15 17:57:03 2018 +
> >>> | 
> >>> | Add support for sqrt asm redirects
> >>> | 
> >>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
> >>> in GLIBC.
> >>> | The goal is to enable GCC to do the inlining, and if this fails 
> >>> call the
> >>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> >>> with asm
> >>> | redirects.  The compat symbols and sqrt wrappers need to disable 
> >>> the redirect.
> >>> | The redirect is also disabled if there are already redirects 
> >>> defined when
> >>> | using -ffinite-math-only.
> >>> | 
> >>> | All math functions (but not math tests, non-library code and 
> >>> libnldbl) are
> >>> | built with -fno-math-errno which means GCC will typically inline 
> >>> sqrt as a
> >>> | single instruction.  This means targets are no longer forced to add 
> >>> a special
> >>> | inline for sqrt.
> >>> | 
> >>> | * include/math.h (sqrt): Declare with asm redirect.
> >>> | (sqrtf): Likewise.
> >>> | (sqrtl): Likewise.
> >>> | (sqrtf128): Likewise.
> >>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> >>> testsuite,
> >>> | nonlib and libnldbl with -fmath-errno.
> >>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> >>> | * math/w_sqrt_template.c: Likewise.
> >>> | * math/w_sqrtf_compat.c: Likewise.
> >>> | * math/w_sqrtl_compat.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> >>> | * sysdeps/generic/math-type-macros-float128.h: Remove 
> >>> math.h and
> >>> | complex.h.
> >>>
> >>> And more precisely by building libc with -fno-math-errno.
> >>
> >> Thanks for looking into it.
> >>
> >> How is the proceeding ? Is there enough info to fix (or report upstream)
> >> ? If not, what has to be done ?
> > 
> > No it's not enough to fix it or report it upstream. We still have to
> > understand the exact issue. For me it's not yet clear if the bug is in
> > QEMU or in glibc. The fact that it works fine on real hardware would
> > go towards a QEMU bug, but there is no proof yet.
> 
> I think it's pretty clear: Under no circumstances must strerror() set
> errno to ENOMEM because this is against the specs [1].

I fully agree with that.

> That makes it pretty likely an upstream issue. Not sure about any Debian
> patches playing a role.

I disagree with that. This is a glibc upstream issue if the source code
is properly translated into binary code and if it is correctly executed
by the (virtual) CPU. I am still not convinced about both here.

Regards,
Aurelien

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


signature.asc
Description: PGP signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-21 12:58, Tim Rühsen wrote:
> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> > On 2018-12-21 11:51, Tim Rühsen wrote:
> >> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> >>> On 2018-12-18 22:11, Aurelien Jarno wrote:
> >>>> On 2018-12-18 21:34, Aurelien Jarno wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
> >>>>>> Package: libc6-armhf-cross
> >>>>>> Version: 2.28-2cross2
> >>>>>> Severity: normal
> >>>>>>
> >>>>>> Dear Maintainer,
> >>>>>>
> >>>>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> >>>>>>
> >>>>>> The expected errno value would be either EINVAL or not touching errno
> >>>>>> at all.
> >>>>>>
> >>>>>> This behavior is relatively new and causes some CI cross builds to 
> >>>>>> fail.
> >>>>>> The failing test is a gnulib test (test-strerror.c).
> >>>>>>
> >>>>>
> >>>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> >>>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> >>>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> >>>>> think it's a qemu bug.
> >>>>
> >>>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> >>>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> >>>
> >>> It seems to have been caused by this upstream patch:
> >>>
> >>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> >>> | Author: Wilco Dijkstra 
> >>> | Date:   Thu Mar 15 17:57:03 2018 +
> >>> | 
> >>> | Add support for sqrt asm redirects
> >>> | 
> >>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
> >>> in GLIBC.
> >>> | The goal is to enable GCC to do the inlining, and if this fails 
> >>> call the
> >>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> >>> with asm
> >>> | redirects.  The compat symbols and sqrt wrappers need to disable 
> >>> the redirect.
> >>> | The redirect is also disabled if there are already redirects 
> >>> defined when
> >>> | using -ffinite-math-only.
> >>> | 
> >>> | All math functions (but not math tests, non-library code and 
> >>> libnldbl) are
> >>> | built with -fno-math-errno which means GCC will typically inline 
> >>> sqrt as a
> >>> | single instruction.  This means targets are no longer forced to add 
> >>> a special
> >>> | inline for sqrt.
> >>> | 
> >>> | * include/math.h (sqrt): Declare with asm redirect.
> >>> | (sqrtf): Likewise.
> >>> | (sqrtl): Likewise.
> >>> | (sqrtf128): Likewise.
> >>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> >>> testsuite,
> >>> | nonlib and libnldbl with -fmath-errno.
> >>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> >>> | * math/w_sqrt_template.c: Likewise.
> >>> | * math/w_sqrtf_compat.c: Likewise.
> >>> | * math/w_sqrtl_compat.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> >>> | * sysdeps/generic/math-type-macros-float128.h: Remove 
> >>> math.h and
> >>> | complex.h.
> >>>
> >>> And more precisely by building libc with -fno-math-errno.
> >>
> >> Thanks for looking into it.
> >>
> >> How is the proceeding ? Is there enough info to fix (or report upstream)
> >> ? If not, what has to be done ?
> > 
> > No it's not enough to fix it or report it upstream. We still have to
> > understand the exact issue. For me it's not yet clear if the bug is in
> > QEMU or in glibc. The fact that it works fine on real hardware would
> > go towards a QEMU bug, but there is no proof yet.
> 
> Looking at glibc's string/strerror.c, it calls __strerror_r() before
> saving 

[Git][glibc-team/glibc][stretch] patches/any/local-condvar-do-not-use-requeue-for-pshared-condvars.patch: patch…

2018-12-21 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / glibc


Commits:
2565c182 by Aurelien Jarno at 2018-12-21T21:15:34Z
patches/any/local-condvar-do-not-use-requeue-for-pshared-condvars.patch: patch 
to fix pthread_cond_wait() in the pshared case on non-x86.  Closes: #904158.

- - - - -


3 changed files:

- debian/changelog
- + 
debian/patches/any/local-condvar-do-not-use-requeue-for-pshared-condvars.patch
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/2565c1821a4faf26c3f88cccb8c767924474c872

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/2565c1821a4faf26c3f88cccb8c767924474c872
You're receiving this email because of your account on salsa.debian.org.


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-21 Thread Aurelien Jarno
On 2018-12-21 11:51, Tim Rühsen wrote:
> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> > On 2018-12-18 22:11, Aurelien Jarno wrote:
> >> On 2018-12-18 21:34, Aurelien Jarno wrote:
> >>> Hi,
> >>>
> >>> On 2018-12-18 15:15, Tim Ruehsen wrote:
> >>>> Package: libc6-armhf-cross
> >>>> Version: 2.28-2cross2
> >>>> Severity: normal
> >>>>
> >>>> Dear Maintainer,
> >>>>
> >>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> >>>>
> >>>> The expected errno value would be either EINVAL or not touching errno
> >>>> at all.
> >>>>
> >>>> This behavior is relatively new and causes some CI cross builds to fail.
> >>>> The failing test is a gnulib test (test-strerror.c).
> >>>>
> >>>
> >>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> >>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> >>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> >>> think it's a qemu bug.
> >>
> >> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> >> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> > 
> > It seems to have been caused by this upstream patch:
> > 
> > | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> > | Author: Wilco Dijkstra 
> > | Date:   Thu Mar 15 17:57:03 2018 +
> > | 
> > | Add support for sqrt asm redirects
> > | 
> > | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
> > GLIBC.
> > | The goal is to enable GCC to do the inlining, and if this fails call 
> > the
> > | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> > with asm
> > | redirects.  The compat symbols and sqrt wrappers need to disable the 
> > redirect.
> > | The redirect is also disabled if there are already redirects defined 
> > when
> > | using -ffinite-math-only.
> > | 
> > | All math functions (but not math tests, non-library code and 
> > libnldbl) are
> > | built with -fno-math-errno which means GCC will typically inline sqrt 
> > as a
> > | single instruction.  This means targets are no longer forced to add a 
> > special
> > | inline for sqrt.
> > | 
> > | * include/math.h (sqrt): Declare with asm redirect.
> > | (sqrtf): Likewise.
> > | (sqrtl): Likewise.
> > | (sqrtf128): Likewise.
> > | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> > testsuite,
> > | nonlib and libnldbl with -fmath-errno.
> > | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> > | * math/w_sqrt_template.c: Likewise.
> > | * math/w_sqrtf_compat.c: Likewise.
> > | * math/w_sqrtl_compat.c: Likewise.
> > | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> > | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> > | * sysdeps/generic/math-type-macros-float128.h: Remove math.h 
> > and
> > | complex.h.
> > 
> > And more precisely by building libc with -fno-math-errno.
> 
> Thanks for looking into it.
> 
> How is the proceeding ? Is there enough info to fix (or report upstream)
> ? If not, what has to be done ?

No it's not enough to fix it or report it upstream. We still have to
understand the exact issue. For me it's not yet clear if the bug is in
QEMU or in glibc. The fact that it works fine on real hardware would
go towards a QEMU bug, but there is no proof yet.

Aurelien

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


signature.asc
Description: PGP signature


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

2018-12-20 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / glibc


Commits:
ae220df6 by Aurelien Jarno at 2018-12-20T23:50:21Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - Fix a data corruption in SSE2-optimized memmove implementation for
i386 (CVE-2017-18269).
  - Fix a stack-based buffer overflow in the realpath function
(CVE-2018-11236).  Closes: #899071.
  - Fix a buffer overflow in the AVX-512-optimized implementation of the
mempcpy function (CVE-2018-11237).  Closes: #899070.

- - - - -


2 changed files:

- debian/changelog
- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/ae220df6e2c06c6f1ba8ce747f1d0b1591ffe621

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/ae220df6e2c06c6f1ba8ce747f1d0b1591ffe621
You're receiving this email because of your account on salsa.debian.org.


Bug#882255: libc6-dev: #define _SC_PAGESIZE _SC_PAGESIZE in /usr/include/x86_64-linux-gnu/bits/confname.h

2018-12-20 Thread Aurelien Jarno
control: notfound -1 glibc/2.28-2

On 2018-12-20 09:55, Florin Iucha wrote:
> Package: libc6-dev
> Version: 2.28-2
> Followup-For: Bug #882255

Please do not reuse unrelated bug for reporting new ones.

> Trying to compile a personal project using Clang7 and maximum warning
> settings, it produced the following warning:
> 
> error: disabled expansion of recursive macro
> [-Werror,-Wdisabled-macro-expansion]
> 
> /usr/include/x86_64-linux-gnu/bits/confname.h:134:24: note: expanded
> from macro '_SC_PAGESIZE' 
>
> #define _SC_PAGESIZE_SC_PAGESIZE
> 
> I think the confname.h has that line as a result of a mis-merge. There's
> no point in defining X as X.

No this is not a merge issue and it is correct. It is there to define
_SC_PAGESIZE both as an enum value and a defined value that can be
tested with #ifdef.

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



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

2018-12-19 Thread Aurelien Jarno
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / glibc


Commits:
5d3a9bc5 by Aurelien Jarno at 2018-12-19T22:19:23Z
debian/patches/git-updates.diff: update from upstream stable branch

- - - - -


1 changed file:

- debian/patches/git-updates.diff


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/5d3a9bc5e817329fd5470d8080822f3c3063178c

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/5d3a9bc5e817329fd5470d8080822f3c3063178c
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/sysdeps/riscv64.mk: increase TIMEOUTFACTOR to 100 on riscv64.

2018-12-19 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
aab1a90d by Aurelien Jarno at 2018-12-19T15:48:39Z
debian/sysdeps/riscv64.mk: increase TIMEOUTFACTOR to 100 on riscv64.

- - - - -


2 changed files:

- debian/changelog
- debian/sysdeps/riscv64.mk


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/aab1a90d7938322ab6f70b58c7846ddab1d0759d

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/aab1a90d7938322ab6f70b58c7846ddab1d0759d
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/patches/any/submitted-sigaction-sa-restorer.diff: replace by final…

2018-12-19 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
b910497a by Aurelien Jarno at 2018-12-19T15:29:59Z
debian/patches/any/submitted-sigaction-sa-restorer.diff: replace by final 
upstream version and rename to git-sigaction-sa-restorer.diff.

- - - - -


3 changed files:

- debian/changelog
- debian/patches/any/submitted-sigaction-sa-restorer.diff → 
debian/patches/any/git-sigaction-sa-restorer.diff
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/b910497ad89c368307be615310bdc1c0f32ad224

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/b910497ad89c368307be615310bdc1c0f32ad224
You're receiving this email because of your account on salsa.debian.org.


Re: Buster / GCC 7.4 Problem

2018-12-19 Thread Aurelien Jarno
On 2018-12-19 09:15, Hagen Paul Pfeifer wrote:
> > On December 19, 2018 at 2:44 AM Matthias Klose  wrote:
> > 
> > this is unrelated to GCC, but happens with glibc 2.28.
> 
> Thank you Matthias! It happens with the "visual" gcc update, sry for that.
> 
> glibc folks: do you need any more information? Should I test/verify
> anything?

No, we do not need more information the problem is known, and is on the
gnulib side. It uses glibc internal defines, and therefore breaks when
internal things changes. A patch has been committed upstream back in
March, but hasn't propagated yet to all projects having an embedded
copy:

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4af4a4a71827c0bc5e0ec67af23edef4f15cee8e

It is not perfect has it replaces one internal define by another, but
should do the trick for now.

Aurelien

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



Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-18 Thread Aurelien Jarno
On 2018-12-18 22:11, Aurelien Jarno wrote:
> On 2018-12-18 21:34, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2018-12-18 15:15, Tim Ruehsen wrote:
> > > Package: libc6-armhf-cross
> > > Version: 2.28-2cross2
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> > > 
> > > The expected errno value would be either EINVAL or not touching errno
> > > at all.
> > > 
> > > This behavior is relatively new and causes some CI cross builds to fail.
> > > The failing test is a gnulib test (test-strerror.c).
> > > 
> > 
> > I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> > qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> > hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> > think it's a qemu bug.
> 
> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.

It seems to have been caused by this upstream patch:

| commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
| Author: Wilco Dijkstra 
| Date:   Thu Mar 15 17:57:03 2018 +
| 
| Add support for sqrt asm redirects
| 
| This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
GLIBC.
| The goal is to enable GCC to do the inlining, and if this fails call the
| __ieee754_sqrt function.  This is done by internally declaring sqrt with 
asm
| redirects.  The compat symbols and sqrt wrappers need to disable the 
redirect.
| The redirect is also disabled if there are already redirects defined when
| using -ffinite-math-only.
| 
| All math functions (but not math tests, non-library code and libnldbl) are
| built with -fno-math-errno which means GCC will typically inline sqrt as a
| single instruction.  This means targets are no longer forced to add a 
special
| inline for sqrt.
| 
| * include/math.h (sqrt): Declare with asm redirect.
| (sqrtf): Likewise.
| (sqrtl): Likewise.
| (sqrtf128): Likewise.
| * Makeconfig: Add -fno-math-errno for libc/libm, but build 
testsuite,
| nonlib and libnldbl with -fmath-errno.
| * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
| * math/w_sqrt_template.c: Likewise.
| * math/w_sqrtf_compat.c: Likewise.
| * math/w_sqrtl_compat.c: Likewise.
| * sysdeps/i386/fpu/w_sqrt.c: Likewise.
| * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
| * sysdeps/generic/math-type-macros-float128.h: Remove math.h and
| complex.h.

And more precisely by building libc with -fno-math-errno.

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



Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-18 Thread Aurelien Jarno
On 2018-12-18 21:34, Aurelien Jarno wrote:
> Hi,
> 
> On 2018-12-18 15:15, Tim Ruehsen wrote:
> > Package: libc6-armhf-cross
> > Version: 2.28-2cross2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> > 
> > The expected errno value would be either EINVAL or not touching errno
> > at all.
> > 
> > This behavior is relatively new and causes some CI cross builds to fail.
> > The failing test is a gnulib test (test-strerror.c).
> > 
> 
> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> think it's a qemu bug.

Hmm, I am wrong, I can actually reproduce it with qemu-user-static
version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.

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



Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-18 Thread Aurelien Jarno
Hi,

On 2018-12-18 15:15, Tim Ruehsen wrote:
> Package: libc6-armhf-cross
> Version: 2.28-2cross2
> Severity: normal
> 
> Dear Maintainer,
> 
> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> 
> The expected errno value would be either EINVAL or not touching errno
> at all.
> 
> This behavior is relatively new and causes some CI cross builds to fail.
> The failing test is a gnulib test (test-strerror.c).
> 

I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
think it's a qemu bug.

Do you have some other tests showing it's linked to the new upstream
glibc version?

Aurelien

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



[Git][glibc-team/glibc][sid] debian/testsuite-xfail-debian.mk: whitelist math/test-fenv on riscv64. This…

2018-12-17 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
b9f98eee by Aurelien Jarno at 2018-12-17T22:28:33Z
debian/testsuite-xfail-debian.mk: whitelist math/test-fenv on riscv64. This 
failure is also due to a kernel bug.

- - - - -


2 changed files:

- debian/changelog
- debian/testsuite-xfail-debian.mk


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/b9f98eee97f62a3daa931f1b769ebc14b2211cd9

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/b9f98eee97f62a3daa931f1b769ebc14b2211cd9
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] releasing package glibc version 2.28-3

2018-12-16 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
5b0eebfa by Aurelien Jarno at 2018-12-16T17:26:16Z
releasing package glibc version 2.28-3

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/5b0eebfaf19394f6ef5f5b687a9554449ca17052

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/5b0eebfaf19394f6ef5f5b687a9554449ca17052
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc] Pushed new tag debian/2.28-3

2018-12-16 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2.28-3 at GNU Libc Maintainers / glibc

-- 
View it on GitLab: https://salsa.debian.org/glibc-team/glibc/tree/debian/2.28-3
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] 2 commits: debian/patches/submitted-sigaction-sa-restorer.diff: fix a regression in…

2018-12-16 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
530d9c62 by Aurelien Jarno at 2018-12-16T13:30:35Z
debian/patches/submitted-sigaction-sa-restorer.diff: fix a regression in 
sigaction on m68k.  Closes: #915958.

- - - - -
db9fb276 by Aurelien Jarno at 2018-12-16T13:49:10Z
debian/script.in/nsscheck.sh: drop direct support for file-rc and always run 
invoke-rc.d instead. invoke-rc.d in stretch has support for file-rc. Closes: 
#916588.

- - - - -


4 changed files:

- debian/changelog
- + debian/patches/any/submitted-sigaction-sa-restorer.diff
- debian/patches/series
- debian/script.in/nsscheck.sh


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/02ba9194c909d58981eae156db9249485ef105f7...db9fb27698ad3e2383f0cd993f8d03e7cbb0ad56

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/02ba9194c909d58981eae156db9249485ef105f7...db9fb27698ad3e2383f0cd993f8d03e7cbb0ad56
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] Add a pointer to the x32 preadvwritev2 issue

2018-12-15 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
02ba9194 by Aurelien Jarno at 2018-12-15T22:48:30Z
Add a pointer to the x32 preadvwritev2 issue

- - - - -


1 changed file:

- debian/testsuite-xfail-debian.mk


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/02ba9194c909d58981eae156db9249485ef105f7

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/02ba9194c909d58981eae156db9249485ef105f7
You're receiving this email because of your account on salsa.debian.org.


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

2018-12-15 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
978eac9c by Aurelien Jarno at 2018-12-15T22:44:00Z
debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - debian/patches/riscv64/submitted-start-cfi.diff: upstreamed.

- - - - -


4 changed files:

- debian/changelog
- debian/patches/git-updates.diff
- − debian/patches/riscv64/submitted-start-cfi.diff
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/978eac9c6909644c6e5c73cae2da021bfe692508

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/978eac9c6909644c6e5c73cae2da021bfe692508
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] 5 commits: debian/testsuite-xfail-debian.mk: whitelist misc/tst-preadvwritev2,…

2018-12-15 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
9791dbb5 by Aurelien Jarno at 2018-12-15T21:50:52Z
debian/testsuite-xfail-debian.mk: whitelist misc/tst-preadvwritev2, 
misc/tst-preadvwritev64v2 and test-xfail-tst-setcontext7 on hppa.  Closes: 
#915676.

- - - - -
7161ac82 by Aurelien Jarno at 2018-12-15T21:57:01Z
debian/testsuite-xfail-debian.mk: whitelist math/test-float64x-float128-mul on 
sparc64.  Closes: #916124.

- - - - -
b3742561 by Aurelien Jarno at 2018-12-15T21:58:13Z
debian/control.in/libc: add a Breaks: nocache ( 1.0-1 ) to @libc@ as it 
doesnt work with glibc 2.28.

- - - - -
f048512a by Aurelien Jarno at 2018-12-15T22:09:14Z
debian/testsuite-xfail-debian.mk: whitelist math/test-fpucw, 
math/test-fpucw-ieee, math/test-fpucw-ieee-static and math/test-fpucw-static on 
riscv64. Thoses failures are due to a kernel bug.

- - - - -
5ab6a8b7 by Aurelien Jarno at 2018-12-15T22:12:58Z
debian/sysdeps/riscv64.mk: increase TIMEOUTFACTOR to 50 on riscv64.

- - - - -


5 changed files:

- debian/changelog
- debian/control
- debian/control.in/libc
- + debian/sysdeps/riscv64.mk
- debian/testsuite-xfail-debian.mk


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/a903bdf66089e75d7fe2b1b2ea2256b47e844e92...5ab6a8b70f3d6ed6a6b96f4ad94f35b98ac6

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/a903bdf66089e75d7fe2b1b2ea2256b47e844e92...5ab6a8b70f3d6ed6a6b96f4ad94f35b98ac6
You're receiving this email because of your account on salsa.debian.org.


Bug#916415: nocache broken with glibc 2.28: several programs just hang in call to futex(..., FUTEX_WAIT_PRIVATE, 2, NULL)

2018-12-13 Thread Aurelien Jarno
control: forwarded -1 https://github.com/Feh/nocache/issues/34

On 2018-12-14 13:33, Paul Wise wrote:
> Package: nocache/1.0-1,libc6/2.28-2
> Severity: critical
> Justification: breaks unrelated software
> Usertags: hang
> 
> The upgrade from libc6 2.27-8 to 2.28-2 breaks nocache; some programs,
> when run under it (but not all of them), hang in a call to read/futex:

I haven't looked at it in details, but at least accorded to the upstream
bug, it seems to be an issue on the nocache side:

https://github.com/Feh/nocache/issues/34

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


signature.asc
Description: PGP signature


[Git][glibc-team/glibc] Pushed new tag debian/2.28-2

2018-12-05 Thread Aurelien Jarno
Aurelien Jarno pushed new tag debian/2.28-2 at GNU Libc Maintainers / glibc

-- 
View it on GitLab: https://salsa.debian.org/glibc-team/glibc/tree/debian/2.28-2
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] releasing package glibc version 2.28-2

2018-12-05 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
a903bdf6 by Aurelien Jarno at 2018-12-05T18:50:27Z
releasing package glibc version 2.28-2

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/a903bdf66089e75d7fe2b1b2ea2256b47e844e92

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/a903bdf66089e75d7fe2b1b2ea2256b47e844e92
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/debhelper.in/locales.postinst: fix regexp checking for installed locales…

2018-12-05 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
6322d9a5 by Aurelien Jarno at 2018-12-05T18:50:13Z
debian/debhelper.in/locales.postinst: fix regexp checking for installed locales 
package.  Closes: #903964.

- - - - -


2 changed files:

- debian/changelog
- debian/debhelper.in/locales.postinst


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/6322d9a55035c0850ad0198b31b9ff3a6f23a332

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/6322d9a55035c0850ad0198b31b9ff3a6f23a332
You're receiving this email because of your account on salsa.debian.org.


[Git][glibc-team/glibc][sid] debian/testsuite-xfail-debian.mk: whitelist elf/tst-execstack-needed on riscv64,…

2018-12-05 Thread Aurelien Jarno
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
4fd017a8 by Aurelien Jarno at 2018-12-05T18:43:50Z
debian/testsuite-xfail-debian.mk: whitelist elf/tst-execstack-needed on 
riscv64, it is similar to the already whitelisted test 
elf/test-xfail-tst-execstack.

- - - - -


2 changed files:

- debian/changelog
- debian/testsuite-xfail-debian.mk


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/4fd017a8d90361ac5fd5b9671baa665dad227474

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/commit/4fd017a8d90361ac5fd5b9671baa665dad227474
You're receiving this email because of your account on salsa.debian.org.


  1   2   3   4   5   6   7   8   9   10   >