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

2020-05-16 Thread Aurelien Jarno
Hi Mike,

On 2020-05-16 10:57, Mike Przybylski wrote:
> Hi, Aurelien,
> 
> Thank you for looking into this.  I really appreciate it.
> 
> > Which nameserver do you use?
> 
> Google DNS ( 8.8.8.8 and 8.8.4.4 )
> 
> > As the answer is probably large, it might
> > be interesting to check if it supports TCP connections as a fallback.
> > Alternative you might want to enable edns0 if it's not already done.
> 
> I will definitely look into that.
> 
> > Could you try with other nameservers, there are many public DNS servers
> > available to test.
> 
> I’m sorry that I didn’t think of that.  Everything works fine with OpenDNS ( 
> 208.67.222.222 and  208.67.220.220 ).
> 
> > Finally would it be possible to get a tcpdump trace of the issue? That
> > would likely help to understand the issue.
> 
> Please see the attached pcap file.

Thanks a lot for the pcap file. I got a look at it, and there is indeed
something fishy:
- 10.0.2.15 asks 8.8.8.8/UDP for A download.docker.com (query 0xd009)
- 10.0.2.15 asks 8.8.8.8/UDP for  download.docker.com (query 0x710a)
- 8.8.8.8 answers query 0xd009
- 8.8.8.8 answers query 0x710a but marks it as truncated as it it too
  big.

Up to there all looks normal. As expected the  query 0x710a is
retried using TCP:
- 10.0.2.15 asks 8.8.8.8/TCP for  download.docker.com (query 0x710a)
- 8.8.8.8 answers to query *0xd009* with the *A* records. This is
  totally unexpected.

The glibc resolvers therefore retries with the second name server:
- 10.0.2.15 asks 8.8.8.4/TCP for  download.docker.com (query 0x710a)
- 8.8.8.4 answers to query *0xd009* with the *A* records, the same way
  as 8.8.8.8. This is again totally unexpected.

As both TCP queries failed, glibc concludes there is a server error.

I have no idea what could explain that, it seems there is something
between the Google DNS servers and you host mangling the answers. 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?

Regards,
Aurelien

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



Processed: Bug#960783 marked as pending in tzdata

2020-05-16 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 pending
Bug #960783 [tzdata] tzdata: [INTL:de] updated German debconf translation
Added tag(s) pending.

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



Bug#960529: marked as done (libc6: After update the integrated camera (uvcvideo) is not longer detected)

2020-05-16 Thread Debian Bug Tracking System
Your message dated Sat, 16 May 2020 23:10:48 +0200
with message-id <20200516211048.gd2...@aurel32.net>
and subject line Re: Bug#960529: Info received (Bug#960529: libc6: After update 
the integrated camera (uvcvideo) is not longer detected)
has caused the Debian Bug report #960529,
regarding libc6: After update the integrated camera (uvcvideo) is not longer 
detected
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.)


-- 
960529: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960529
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.30-7
Severity: normal

After running this morning an upgrade, the camera integrated into my Laptop 
(Thinkpad T530) is not longer available.




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

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

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1  10.1.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
pn  glibc-doc  
ii  libc-l10n  2.30-7
ii  locales2.30-7

-- debconf information:
  glibc/restart-services:
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/disable-screensaver:
* libraries/restart-without-asking: true
  glibc/restart-failed:
  glibc/kernel-not-supported:
--- End Message ---
--- Begin Message ---
On 2020-05-13 21:57, Reiner Nix wrote:
> Hi,
> 
> now, I have tried again to start a video conference (just to check connecting 
> zoom to an alternative device) ... and this laptop works with zoom and jitsi 
> without any further config change. Very strange.
> 
> I guess that this ticket can be closed and apologize for any inconvenience 
> caused by the ticket.

No problem, closing it with that mail.

Aurelien

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


[Git][glibc-team/tzdata][sid] Update German debconf translation, by Helge Kreutzmann. Closes: #960783.

2020-05-16 Thread Aurelien Jarno


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


Commits:
b5b37b39 by Aurelien Jarno at 2020-05-16T23:12:31+02:00
Update German debconf translation, by Helge Kreutzmann.  Closes: #960783.

- - - - -


2 changed files:

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


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

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




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

2020-05-16 Thread Mike Przybylski
Hi, Aurelien,

Thank you for looking into this.  I really appreciate it.

> Which nameserver do you use?

Google DNS ( 8.8.8.8 and 8.8.4.4 )

> As the answer is probably large, it might
> be interesting to check if it supports TCP connections as a fallback.
> Alternative you might want to enable edns0 if it's not already done.

I will definitely look into that.

> Could you try with other nameservers, there are many public DNS servers
> available to test.

I’m sorry that I didn’t think of that.  Everything works fine with OpenDNS ( 
208.67.222.222 and  208.67.220.220 ).

> Finally would it be possible to get a tcpdump trace of the issue? That
> would likely help to understand the issue.

Please see the attached pcap file.



bad-gdns-lookups.pcap
Description: Binary data

Please let me know if there is any other data I can provide.

Kindest regards,
Mike Przybylski

Bug#960783: tzdata: [INTL:de] updated German debconf translation

2020-05-16 Thread Helge Kreutzmann
Package: tzdata
Version: 2020a-1
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for tzdata
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of tzdata debconf templates to German
# Copyright (C) Helge Kreutzmann , 2007, 2008.
# Copyright (C) Holger Wansing , 2010, 2011, 2013, 
2016, 2017.
# This file is distributed under the same license as the tzdata package.
# Holger Wansing , 2019.
msgid ""
msgstr ""
"Project-Id-Version: tzdata 2020a-20a-1\n"
"Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
"POT-Creation-Date: 2020-04-24 21:28+0200\n"
"PO-Revision-Date: 2020-05-16 17:58+0200\n"
"Last-Translator: Holger Wansing \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Lokalize 2.0\n"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Africa"
msgstr "Afrika"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "America"
msgstr "Amerika"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Antarctica"
msgstr "Antarktis"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Australia"
msgstr "Australien"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Arctic"
msgstr "Arktis"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Asia"
msgstr "Asien"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Atlantic"
msgstr "Atlantik"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Europe"
msgstr "Europa"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Indian"
msgstr "Indien"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:1001 ../tzdata.templates:13001
msgid "Pacific"
msgstr "Pazifik"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "SystemV"
msgstr "SystemV"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "US"
msgstr "US"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per 

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

2020-05-16 Thread Aurelien Jarno
control: reassign -1 libc6

Hi,

On 2020-05-15 21:24, Michael Przybylski wrote:
> 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

From here, I see a different set of IPs, but the number of returned IPs
is the same. However I am not able to reproduce the problem with curl or
ping, it works even without using the -4 option.

> 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

That means the DNS server you use is returning a temporary error, it's
just passed to the callers.

Which nameserver do you use? As the answer is probably large, it might
be interesting to check if it supports TCP connections as a fallback.
Alternative you might want to enable edns0 if it's not already done.

Could you try with other nameservers, there are many public DNS servers
available to test.

Finally would it be possible to get a tcpdump trace of the issue? That
would likely help to understand the issue.

Thanks,
Aurelien

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



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

2020-05-16 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 libc6
Bug #960739 [libc-bin] libc-bin: getaddrinfo() fails with EAI_AGAIN when the 
DNS query returns a large number of A and  records.
Bug reassigned from package 'libc-bin' to 'libc6'.
No longer marked as found in versions glibc/2.30-7.
Ignoring request to alter fixed versions of bug #960739 to the same values 
previously set

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



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

2020-05-16 Thread Aurelien Jarno
Hi,

On 2020-05-13 19:06, José Antonio Jiménez Madrid wrote:
> Package: locales
> Version: 2.28-10
> Severity: minor
> Tags: l10n
> 
> Hi,
> 
> I upgraded yesterday to Buster and in the process of upgrading packages I got
> the following perl warning in several packages:
> 
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "es_ES.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> 
> 
> In some places I have found "a way to fix it", but this not works for me. I
> followed the steps.
> 
> export LANGUAGE=es_ES.UTF-8
> export LANG=es_ES.UTF-8
> export LC_ALL=es_ES.UTF-8
> locale-gen
> dpkg-reconfigure locales
> 
> 
> selecting the generation of all locales and to use es_ES.UTF-8 in the debconf
> window. But the problem persists.
> Also I have tried to change to another locales, like
> 
> en_US.UTF-8
> 
> but LANGUAGE and LC_ALL keep unset. Coming back to my original locale does not
> fix the problem.
> 
> I do not know whether this can be related with bugs:
> 
> #687522

That's a different issue that prevents using debconf to select the
locales to build. It seems you are able to to that, even if they do not
seem to be regenerated.

> #724456

That's a temporary problem only happening during the upgrade. Your
problem seems to be permanent.

> 
> I can make test, send log files,... to find what is causing this problem.

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 output of the "locales" command

* The content of the "/usr/lib/locale/" directory.

As an alternative, does installing locales-all, which contains already
all locales already compiled does fix your problem?

Thanks,
Aurelien

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



Bug#91815: Patch to add memusage and memusagestat

2020-05-16 Thread Aurelien Jarno
Hi Stephen, hi Helmut,

On 2020-05-09 12:27, Helmut Grohne wrote:
> Hi Stephen,
> 
> Thank you for not dropping the ball after my initial "it's not that
> easy" reply.
> 
> On Sat, May 09, 2020 at 10:53:10AM +0200, Stephen Kitt wrote:
> > There’s another part of the transition which bothers me: if we add memusage
> > to a package which is depended upon (albeit temporarily) by libc-dev-bin, it
> > becomes part of build-essential, and adding memusage means adding libgd3,
> > libfontconfig1, libfreetype6, etc. to all builds...
> > 
> > It occurred to me that there is however a way to add memusage while
> > transitioning cleanly, over a few years. It seems to me that the binaries in
> > libc-dev-bin can be split into two categories: binaries that are expected as
> > build tools (gencat and rpcgen), and binaries that are useful as tools for
> > understanding programs but not building them (memusage, memusagestat, 
> > mtrace,
> > sotruss, sprof). How about the following?
> > 
> > * We add a new package, say libc-devtools, containing the second type of
> >   tools (mtrace, sotruss, sprof). For transition purposes, libc-dev-bin
> >   depends on that in Bullseye.
> > * We add another package, memusage, containing memusage and memusagestat.
> >   That’s the package which ends up with all the annoying extra dependencies,
> >   but nothing depends on it.
> > * In Bookworm, libc-dev-bin can drop the dependency on libc-devtools, and we
> >   can merge memusage into libc-devtools.
> > 
> > Does that make sense?

Yes, with the points raised by Helmut, I think it makes sense.
Unfortunately many changes in glibc requires transitions lasting many
years...

I just wonder if we should call it libc-devtools or libc-dev-tools to
match the pattern from libc-dev-bin. But that's a minor detail over the
whole plan.

> All of what you write here makes very much sense to me and the
> trade-offs seem good to me. What you propose will result in making the
> bootstrapping/profile stuff simpler/better. That said, I am not a glibc
> maintainer. I don't see the full picture.
> 
> I have two minor remarks:
>  * Should libc-devtools maybe recommend memusage already?

It's something we can do, I think it mostly depends if we basically want
libc-dev-bin to recommends memusage.

>  * We cannot simply have libc-devtools absorb memusage in bookworm.
>Doing so would break upgrades when someone has memusage, but not
>libc-devtools installed. Therefore memusage likely needs to be a
>transitional dummy package in bookworm and can only be removed one
>release later. I'm wondering whether this could be avoided if we had
>memusage depend on libc-devtools.

I agree with that.

> Neither of these touch the core of your thoughts.

Another faster alternative that came to my mind is to rely n the fact
that recommends are enabled by default, but not used to resolve
build-dependencies. In that case we can already create libc-devtools
with memstatusage and also move mtrace, sotruss, sprof there. Those 3
binaries are very unlikely to be used to build packages, so I don't
expect breakages. From the user point of view, it's just like if (part
of) a dependency has been demoted to a recommends. It's something that
is often done for other packages, and it seems we accept that even if it
causes breakages (latest example that comes to my mind is util-linux
dropping the dependency on fdisk). I guess adding an entry in NEWS would
be necessary though.

I don't know if it's something that's acceptable. What do you think?
Maybe we should ask the release team?

Aurelien

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



Processed: affects 960739

2020-05-16 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> affects 960739 curl apt
Bug #960739 [libc-bin] libc-bin: getaddrinfo() fails with EAI_AGAIN when the 
DNS query returns a large number of A and  records.
Added indication that 960739 affects curl and apt
> thanks
Stopping processing here.

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