Bug#960739: libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query returns a large number of A and AAAA records.
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
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)
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.
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.
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
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 Sy
Bug#960739: libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query returns a large number of A and AAAA records.
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.
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
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
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
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
