Bug#351469: empty program triggers valgrind, too

GCC support library libc6 recommends no packages. -- debconf information: glibc/restart-failed: glibc/restart-services: -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg

Bug#534548: libc6: rt-tests FTBFS on sparc, s390, ia64 and hppa

] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=tid_fix_s390_ia64.patch;att=2;bug=534352 -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions| http://www.pengutronix.de/ | -- To UNSUBSCRIBE, email to debian

Bug#788799: libc6: pthread_cond_broadcast issue when surrounded by PTHREAD_PRIO_INHERIT mutex on ARM

Package: libc6 Version: 2.21-0experimental0 Severity: normal Tags: upstream fixed-upstream Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=18463 Hello, the attached program fails with an error on ARM platforms. (I only tested armhf, but I think armel is affected, too.) The problem is

Bug#854302: libc6: AI_ADDRCONFIG is not in all situations a useful default

Package: libc6 Version: 2.24-8 Severity: normal Tags: upstream Hello, quoting getaddrinfo(3): According to POSIX.1-2001, specifying hints as NULL should cause ai_flags to be assumed as 0. The GNU C library instead assumes a value of (AI_V4MAPPED | AI_ADDRCONFIG)

Bug#854301: libc6: getaddrinfo with AF_UNSPEC and AI_ADDRCONFIG should not return results on offline machine

Package: libc6 Version: 2.24-8 Severity: normal Tags: upstream patch Hello, for ease of reproducibility I show my examples in Python, but I verified that the problem is in glibc and not in Python: On a machine without network access I get: >>> import socket >>>

Bug#780294: Attempts to resolve IPv6 even when only link-local IPv6 addresses configured

On Wed, Mar 11, 2015 at 10:59:40AM -0700, Josh Triplett wrote: > Package: libc6 > Version: 2.19-15 > Severity: important > > I'm on a network that has somewhat broken DNS: attempts to resolve > records for some hosts produce long timeouts. > > As I understand it, glibc is supposed to check

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

Hello, On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote: > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] > > [DSA Sprint report]: >

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

Hello Julien, On 06/29/2018 11:23 AM, Julien Cristau wrote: >> If the concerns are mostly about the hardware not being rackable, there >> is a rackable NAS by Netgear: >> >> >> https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs >> >> with an armhf cpu. Not