glibc_2.31-0experimental2_source.changes ACCEPTED into experimental

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 19 May 2020 00:19:13 +0200
Source: glibc
Architecture: source
Version: 2.31-0experimental2
Distribution: experimental
Urgency: medium
Maintainer: GNU Libc Maintainers 
Changed-By: Aurelien Jarno 
Closes: 956418
Changes:
 glibc (2.31-0experimental2) experimental; urgency=medium
 .
   [ Aurelien Jarno ]
   * Add an explicit dependency on $(stamp)build_libc for the build-indep
 target. Currently the build is made during the binary-indep target
 instead.
   * debian/control.in/main: build-depends on gcc-10 (>= 10-20200431) on arm64
 to ensure that -moutline-atomics is enabled by default.  Closes: #956418.
   * debian/patches/git-updates.diff: update from upstream stable branch.
   * debian/debhelper.in/libc.NEWS: add an entry explaining the new trust-ad
 option in resolv.conf.
   * debian/patches/riscv64/local-asin-acos-raise-invalid.diff: new patch to
 workaround a GCC 10 bug on riscv64.
 .
   [ Samuel Thibault ]
   * debian/patches/hurd-i386/git-tst-udp.diff: New patch to fix
 sunrpc/tst-udp-* failures.
   * debian/sysdeps/hurd-i386.mk: Add -march=i686 to fix math issues until gcc
 is fixed to switch to i686 as was actually expected already.
   * debian/testsuite-xfail-debian.mk: Update hurd-i386 results.
Checksums-Sha1:
 6a6e40855dfdf228a99345069b01ae6eb40a2de5 8204 glibc_2.31-0experimental2.dsc
 8a883af347166d668050c272137f0137dffd4198 813300 
glibc_2.31-0experimental2.debian.tar.xz
 cf1e025ae12268b5e137fa9754aa558af63cc9e4 7557 
glibc_2.31-0experimental2_source.buildinfo
Checksums-Sha256:
 579aff7f1df7bb5f857578f480be2b467c679eaf2f3b554acf445cfc4750ce06 8204 
glibc_2.31-0experimental2.dsc
 1462d983b57dbbbc32ac1cc271248849b77a0ff4aac2ce71e72de81f5b440245 813300 
glibc_2.31-0experimental2.debian.tar.xz
 852a11165eee01d3e873f1515f3060f84781d574372d62b0be68f93a018744af 7557 
glibc_2.31-0experimental2_source.buildinfo
Files:
 0684c17e0fce3c8c833267d1c621edc4 8204 libs required 
glibc_2.31-0experimental2.dsc
 aa45f20450479c5f5e04a04552843840 813300 libs required 
glibc_2.31-0experimental2.debian.tar.xz
 98178ff1ba22af2b0a767aa14c2cff2f 7557 libs required 
glibc_2.31-0experimental2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAl7DCtYACgkQE4jA+Jno
M2t4sQ//Wrvl+g8fWlkViF/clkTmYCDFrlxwCYiAO09AQKBZn9UEfp4LIBnoldAx
cpmsjed14bijwGOuxAWJc5nLpnSSmBXMgTpOeo1fDv8RhNngsHK5sKDwszISWZCJ
/TW2xnHo6radjMg4EXC1t4CB1iJh1L3lPDZy6Lx/qqerq6P2dk68TqrFPRekCjFV
abwQdXkF2ekrfVPL0r7mQAW4YzTFeJUhIidw6jfthJ/Jqh1i7tz1L+3dpruGEU8t
PwuZdG4HLAWDP1IIc2BGFy+vBwdSF36Hd64U5PYTgzbQ4i0Vh6sFK0fvYq280ntC
7LUh4dTVUfHdYg6B8HNBl8lJ5kxY4wRsn+QQo1Wo4GU3gueyc7AaKw4Fb50EnTRo
0i1h6drVsuAfTjYFxnQeLvXowDgm9WLaXEmgccxT7V4qZnPYCllVnRWOZQlAr9sX
iGfaUSnTB+2VaXQQADEFDeAxzzizh5h43n3v9G3P58/CgPdZ/r+OpLuT2xv5n9cK
DS4HbUvgVJ3xmJ6FdpwBCPKSH9rFG0OWKj0NEkt0lypkITfWPZqXJiIRwvclcXYw
k0Bw101ooLMVtTRxjWjjuiIJ9iNy8iivxjmFelTpA8UFMosXuKv8Npx8WOq2krzA
WjUP6FB1hR9GvnluN6w+j8hUinold2CFtG6uGo1b4zBygqK0YWY=
=W0fD
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of glibc_2.31-0experimental2_source.changes

[Debian FTP Masters]

glibc_2.31-0experimental2_source.changes uploaded successfully to localhost
along with the files:
  glibc_2.31-0experimental2.dsc
  glibc_2.31-0experimental2.debian.tar.xz
  glibc_2.31-0experimental2_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#956418: marked as done (src:glibc: Please provide optimized builds for ARMv8.1)

[Debian Bug Tracking System]

Your message dated Mon, 18 May 2020 22:33:45 +
with message-id 
and subject line Bug#956418: fixed in glibc 2.31-0experimental2
has caused the Debian Bug report #956418,
regarding src:glibc: Please provide optimized builds for ARMv8.1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
956418: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956418
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:glibc
Version: 2.30-4
Severity: wishlist
X-Debbugs-CC: debian-...@lists.debian.org

The ARMv8.1 spec, as implemented by the ARM Neoverse N1 processor,
introduces a set of instructions [1] that result in significant performance
improvements for multithreaded applications.  Sample code demonstrating the
performance improvements is attached.  When run on a 16-core Neoverse N1
host with glibc 2.30-4, runtimes vary significantly, ranging from lows
around 250ms to highs around 15 seconds.  When linked against glibc rebuilt
with support for these instructions, runtimes are consistently <50ms.
Significant performance impact has also been observed in less contrived
cases (MariaDB and Postgres), but I don't have a repro to share.

Gcc provides two ways to enable support for these instructions at build
time.  The simplest, and least disruptive, is to enable -moutline-atomics
globally in the arm64 glibc build.  As described at [2], this option enables
runtime checks for the availability of the atomic instructions.  If found,
they are used, otherwise ARMv8.0 compatible code is used.  The drawback of
this option is that the check happens at runtime, thus introducing some
overhead on all arm64 installations.

The second option is to provide libraries built with explicit support for
the ARM v8.1a spec via the -march=armv8.1-a flag.  This option is also
described at [2].  This build would be incompatible with earlier versions of
the spec, so it would need to be provided in a location where the linker
will automatically discover it if it is usable (e.g.
/lib/aarch64-linux-gnu/atomics/).  This does not incur any runtime overhead,
but obviously involves an additional libc build, and the corresponding
complixity and disk space utilization.  I'm not sure if this is an option
that the glibc maintainers are interested in pursuing.

I've tested both options and found them to be acceptable on v8.1a (Neoverse
N1) and v8a (Cortex A72) CPUs.  I can provide bulk test run data of the
various different configuration permutations if you'd like to see additional
data.

I can provide patches or merge requests implementing either option, at least
for a starting point, if you'd like to see them.

Thanks!
noah

1. https://static.docs.arm.com/ddi0557/a/DDI0557A_b_armv8_1_supplement.pdf
   Section B1
2. https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
/*
 * Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License"). You may
 * not use this file except in compliance with the License. A copy of the
 * License is located at
 *
 *  http://aws.amazon.com/apache2.0/
 *
 * or in the "license" file accompanying this file. This file is distributed
 * on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
 * express or implied. See the License for the specific language governing
 * permissions and limitations under the License.
*/

/* Build with:
 * gcc -O2 -o a.out a.c -lpthread -DITER=1000 -DTHREADS=64
*/

#include 
#include 
#include 
#include 

#ifndef ITER
# define ITER 1000
#endif
#ifndef THREADS
# define THREADS 3
#endif

#if THREADS < 1
# error "THREADS is supposed to be at least 1"
#endif

static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
static int shared_ptr = 0;

typedef struct stats_s {
  uint64_t min, max;
  int times;
  uint64_t total;
  uint64_t flips;
} stats_t;

stats_t stats[THREADS + 1];
pthread_t threads[THREADS];

#ifdef __aarch64__
static uint64_t cpu_shift() {
  uint64_t shift = 0;
  __asm__ __volatile__ ("mrs %0,cntfrq_el0; clz %w0, %w0":"="(shift));
  return shift;
}
#endif

static uint64_t gettime() {
#ifdef __aarch64__
  uint64_t ret = 0;
  __asm__ __volatile__ ("isb; mrs %0,cntvct_el0":"=r"(ret));
  return ret << cpu_shift();

#elif defined __x86_64__
  uint64_t a, d;
  __asm__ __volatile__ ("rdtsc" : "=a" (a), "=d" (d));
  return ((uint64_t)a + ((uint64_t)d << 32));
#endif

  return 0;
}

static void init_stats() {
  int i;
  for (i = 0; i <= THREADS; i++) {
stats_t *s = [i];
s->min = 100;
s->max = 0;
s->times = 0;
s->total = 0;
s->flips = 0;
  }
}

static 

[Git][glibc-team/glibc] Pushed new tag debian/2.31-0experimental2

[Aurelien Jarno]

Aurelien Jarno pushed new tag debian/2.31-0experimental2 at GNU Libc 
Maintainers / glibc

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

[Git][glibc-team/glibc][glibc-2.31] releasing package glibc version 2.31-0experimental2

[Aurelien Jarno]

Aurelien Jarno pushed to branch glibc-2.31 at GNU Libc Maintainers / glibc


Commits:
dff7faa9 by Aurelien Jarno at 2020-05-19T00:19:19+02:00
releasing package glibc version 2.31-0experimental2

- - - - -


1 changed file:

- debian/changelog


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

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

Re: Bug#960739: libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query returns a large number of A and AAAA records.

[Aurelien Jarno]

[ Continuing the discussion on the list instead of the bug report ]

On 2020-05-18 20:22, Florian Weimer wrote:
> * Mike Przybylski:
> 
> > Since you’ve pointed out pretty clearly from the pcap that Google
> > and VirtualBox are having some bizarre interaction, I think we can
> > close this as “not a bug.”  I apologize for taking up your time with
> > it.
> 
> It's the DNS implementation in Virtualbox that's broken, particularly
> in the area of TCP support.  Upstream glibc occasionally receives bug
> reports about it, too.

Thanks for the confirmation. We have seen many cases of broken TCP
fallback in the Debian BTS too, sometimes for good reasons, sometimes
because the resolver is just adding additional records where it should
not.

That makes me wonder if enabling EDNS(0) by default would actually fix
more issues than it creates. It seems to be compatible with RFC 6891
which describe the fallback with a "MAY":

| 6.2.2.  Fallback
| 
|If a requestor detects that the remote end does not support EDNS(0),
|it MAY issue queries without an OPT record.  It MAY cache this
|knowledge for a brief time in order to avoid fallback delays in the
|future.  However, if DNSSEC or any future option using EDNS is
|required, no fallback should be performed, as these options are only
|signaled through EDNS.  If an implementation detects that some
|servers for the zone support EDNS(0) while others would force the use
|of TCP to fetch all data, preference MAY be given to servers that
|support EDNS(0).  Implementers SHOULD analyse this choice and the
|impact on both endpoints.

Aurelien

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

Bug#960739: marked as done (libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query returns a large number of A and AAAA records.)

[Debian Bug Tracking System]

Your message dated Mon, 18 May 2020 20:22:48 +0200
with message-id <87lflp85mv@mid.deneb.enyo.de>
and subject line Re: Bug#960739: libc-bin: getaddrinfo() fails with EAI_AGAIN 
when the DNS query returns a large number of A and  records.
has caused the Debian Bug report #960739,
regarding libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query 
returns a large number of A and  records.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
960739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960739
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc-bin
Version: 2.30-7
Severity: important
Tags: ipv6

Dear Maintainer,

When attempting to follow the instructions for installing the latest version of 
Docker Engine at 
https://docs.docker.com/engine/install/debian/ I noticed that 'apt-get update' 
and curl were both
failing to resolve download.docker.com.  The error message from both ping and 
curl was 
"Temporary failure in name resolution"

However, running 'host download.docker.com' yielded the following results:

download.docker.com is an alias for d2h67oheeuigaw.cloudfront.net.
d2h67oheeuigaw.cloudfront.net has address 13.227.73.43
d2h67oheeuigaw.cloudfront.net has address 13.227.73.44
d2h67oheeuigaw.cloudfront.net has address 13.227.73.95
d2h67oheeuigaw.cloudfront.net has address 13.227.73.15
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:c00:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:5000:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:7a00:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:9200:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:9600:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:9c00:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:a200:3:db06:4200:93a1
d2h67oheeuigaw.cloudfront.net has IPv6 address 
2600:9000:2202:f600:3:db06:4200:93a1

After examining the source code for iputils-ping, I was able to determine that 
the cause of the
error message was getaddrinfo() returning EAI_AGAIN

The following workarounds were effective:

* curl -4 https://download.docker.com/... (Forcing curl to use IPv4 only)
* ping -4 download.docker.com (Forcing IPv4 ping to use IPv4 only)
* Forcing apt to use IPv4 by adding 'Acquire::ForceIPv4 "true";' to apt.conf

It is also noteworthy that not all hostnames with both A and  records 
trigger this bug. In fact,
hostnames with a low total record count like www.google.com have no problem 
whatsoever


root@sandbox:~# host www.google.com
www.google.com has address 172.217.6.36
www.google.com has IPv6 address 2607:f8b0:4005:809::2004
...
root@sandbox:~# ping www.google.com
PING www.google.com (172.217.6.36) 56(84) bytes of data.
64 bytes from sfo03s08-in-f4.1e100.net (172.217.6.36): icmp_seq=1 ttl=63 
time=29.6 ms
...
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 29.572/37.733/42.045/5.774 ms


Please note that this bug also affects libc-bin 2.28-10 in buster.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc-bin depends on:
ii  libc6  2.30-7

Versions of packages libc-bin recommends:
ii  manpages  5.06-1

libc-bin suggests no packages.

-- Configuration Files:
/etc/gai.conf changed [not included]

-- no debconf information
--- End Message ---
--- Begin Message ---
* Mike Przybylski:

> Since you’ve pointed out pretty clearly from the pcap that Google
> and VirtualBox are having some bizarre interaction, I think we can
> close this as “not a bug.”  I apologize for taking up your time with
> it.

It's the DNS implementation in Virtualbox that's broken, particularly
in the area of TCP support.  Upstream glibc occasionally receives bug
reports about it, too.--- End Message ---

Bug#960739: libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query returns a large number of A and AAAA records.

[Mike Przybylski]

Hello, Aurelien,

Interestingly, this doesn’t happen on a native Debian 10 box running libc-bin 
2.28-10, (which was also having trouble with Google DNS in the VirtualBox 
guests on my mac).

Since you’ve pointed out pretty clearly from the pcap that Google and 
VirtualBox are having some bizarre interaction, I think we can close this as 
“not a bug.”  I apologize for taking up your time with it.

Kindest regards,
Mike Przybylski

> On May 17, 2020, at 8:19 PM, Mike Przybylski 
>  wrote:
> 
> Hi, Aurelien,
> 
> Well spotted.  This is a Debian 11, (formerly 10), guest in VirtualBox on a 
> Mac host running Catalina.  Let me see if I can reproduce this on a native 
> Debian box.  I will update with my results one way or another.
> 
> Kindest regards,
> Mike Przybylski
> 
>> On May 16, 2020, at 3:45 PM, Aurelien Jarno > > wrote:
>> 
>> I
>> noticed that the IP of your host is 10.0.2.15. Could it be a QEMU or
>> Virtualbox VM running with the user mode network stack?
> 

Désinfectants

[Cecylia Lazar]

Bonjour

Je contacte au nom du fabricant de savons, liquides et gels pour la 
désinfection des mains et les produits de nettoyage.

Je voudrais vous offrir des produits de désinfection inodores qui nettoient et 
désinfectent efficacement la peau, éliminant les virus et les bactéries de vos 
mains. Les produits de désinfection sont destinés à un usage général et 
professionnel (hôpitaux, salles de traitement, laboratoires et autres).

Nous proposons également des savons liquides efficaces avec une large gamme de 
parfums, gels douche, shampooings et revitalisants capillaires, et des 
détergents concentrés qui se distinguent sur le marché avec des performances 
élevées.

Nos produits sont sans danger pour tous les types de peau, destinés à un usage 
quotidien, ils ne contiennent ni silicones ni parabènes.

En raison du bon rapport qualité-prix, les cosmétiques et les produits de 
lavage sont très populaires sur les marchés européens.

Puis-je présenter une offre?


Cordialement

Cecylia Lazar
Responsable du développement commercial

Bug#960536: locales: $LANGUAGE and $LC_ALL are not set

[Samuel Thibault]

Hello,

José Antonio Jiménez Madrid, le lun. 18 mai 2020 13:43:07 +0200, a ecrit:
> Unfortunately $LANGUAGE and $LC_ALL are still unset.

Just to be clear: that is completely expected. One only has to set LANG,
and locales will normally work.

The question was rather: with the locales-all package installed, is perl
still emitting the locale warning?

Samuel

Bug#960536: locales: $LANGUAGE and $LC_ALL are not set

[José Antonio Jiménez Madrid]

Hi Aurelien,

thank you so much for your quick reply. I have installed locales-all but
$LANGUAGE and $LC_ALL are still unset.
I noticed that I had locales-all:i386 installed, now it the amd64 package
is installed in my system.
Also, this computer started with Debian 5. I am removing all config files
from time to time, maybe there is an old config file producing the problem.
I have looked for this old file but
I have found nothing related with locales.

Besides, I have seen that I had "es_ES.utf8" in my local user and
"es_ES.UTF-8" for root. Now both have "es_ES.UTF-8".


El sáb., 16 may. 2020 a las 13:41, Aurelien Jarno ()
escribió:

> Hi,
>
>
> There are two things to look at. First we need understand if the locale
> is correctly generated. Then we also need to understand if the
> environment variables are correctly set.
>
> Could you please send:
>
> * The content of "/etc/default/locale"
>

The content of my "/etc/default/locale"  is:

$ more /etc/default/locale
LANG=es_ES.UTF-8




>
> * The output of the "locales" command
>
>
$ locale
LANG=es_ES.UTF-8
LANGUAGE=
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=

(locale as root produces the same output)




> * The content of the "/usr/lib/locale/" directory.
>
>
I am enclosing two files with the output of "ls -lha /usr/lib/locale/"

1.- localeFolder  (this file is before installing locales-all:amd64)
2.- localeFolder+locales-all   (this file is after the installation
of locales-all:amd64, when I noticed that the i386 package was installed in
my system).

the only differences I can see are the modification dates and the file
"locale-archive" which  size 211M has been removed.




> As an alternative, does installing locales-all, which contains already
> all locales already compiled does fix your problem?
>
>
> Unfortunately $LANGUAGE and $LC_ALL are still unset. At least I have the
same locales for all users in my system now.
Any idea to keep investigating this weird behaviour ???

Thank you so much,

Jose


localeFolder
Description: Binary data


localeFolder+locales-all
Description: Binary data