Bug#568913: depends on nonexistent glibc-2.11-1

Package: locales Now there are TWO experimental packages. # apt-cache policy locales locales: Installed: 2.10.2-5 Candidate: 2.11-0exp4 Version table: 2.11-0exp4 0 990 http://ftp.tw.debian.org experimental/main Packages 2.11-0exp2 0 990

Bug#600667: eglibc: cve-2010-3847 dynamic linker expands $ORIGIN in setuid library search path

* Aurelien Jarno: I have just committed the fix, I am planning to do an upload soon to unstable. Do you think we should also fix it in stable? via a security release? FYI, I have uploaded eglibc 2.11.2-6+squeeze1 to testing-security. -- To UNSUBSCRIBE, email to

Re: glibc_2.7-18lenny6_source.changes REJECTED

* Debian FTP Masters: Reject Reasons: source only uploads are not supported. Notes: Mapping stable-security to proposed-updates. Ahem. Should I upload a newer version to stable-proposed-updates, or is this a spurious error message? -- To UNSUBSCRIBE, email to

squeeze upload for eglibc due to DSA-2122-2

I would like to make an upload of eglibc to address DSA-2122-2 (the first round of patches for the $ORIGIN/LD_AUDIT issue does not cover all corner cases, unfortunately). The changes match those in 2.7-18lenny7, which are based almost verbatim on the upstream patches (except for whitespace

Bug#609756: vsnprintf segfaults on second attempt with alloca

* Andrew Buckeridge: int vfprint(int fdout, const char *fmt, va_list ap) { int i=NONSTDBUF; i=vfnprint(fdout, i, fmt, ap); if(i-1) i=vfnprint(fdout, 1-i, fmt, ap); return i; } va_copy seems to be missing here. -- Florian Weimerfwei

Bug#609756: vsnprintf segfaults on second attempt with alloca

subsequent va_arg invocations in the caller. Does this break C89 and C90? Some systems have got __va_copy. There's probably an autoconf test for this. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D

Re: glibc's getaddrinfo() sort order

* Anthony Towns: I don't agree with making a decision to go against an IETF standard RFC 3484 is not an IETF standard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: glibc's getaddrinfo() sort order

* Clint Adams: On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote: glibc is the only implementation I know of that does this. I have heard, though not confirmed first-hand, that modern versions of FreeBSD, Windows, and Solaris do as well. FreeBSD 6.2-RELEASE doesn't do it. And

Bug#444597: mktime returns 0x7fffffff for the year 2057

reopen 444597 thanks * Tanaka Akira: Do you mean 0x7fff is -1 ? I don't think so. -1 is 0x, not 0x7fff. Oops, you a right. This is a real bug, then. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: getaddrinfo() behaviour

* Anthony Towns: Updating the proposed standard has not been tried. Just to give you an idea of the time scale involved: moving RFC 3484 to HISTORIC (which is the most likely result, at least for the Rule 9 part) will take at least a year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a

Bug#445682: Lack of cross-process mutexes on hppa

Package: libc6 Version: 2.6.1-5 On hppa, GNU libc does not support mutexes which can span multiple address spaces. The following test program prints pthread_condattr_setpshared(condattr, PTHREAD_PROCESS_SHARED) pthread_mutexattr_setpshared(mutexattr, PTHREAD_PROCESS_SHARED) indicating that

Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

* Colin Watson: [*] 1.0.0.0 isn't even a valid IP address, is it? Depends on the situation. You wouldn't want to give a host that address, Why not? Subnet zero is no longer reserved. The whole /8 is currently not assigned, but that's a different matter. but it might be quite reasonable

Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages

* Thibaut VARENE: I'm not sure I understand this correctly though: what's needed right now is a debian-packaged etch-supported kernel (ie, 2.6.18 if my memory serves me right?) that works on hppa? Is it any different that the kernel package shipped with etch? (I suspect it is since the latter

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

* brian m. carlson: The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA 1605. Since the vast majority of network-using programs use glibc as a resolver, this vulnerability affects virtually any network-using program, hence the severity. libc6 should not be released

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

* Aurelien Jarno: IMHO, the UDP randomization commit has to be backported to the etch kernel. The advantage of this solution, is that it potentially fixes other bugs/vulnerabilities in other protocols/programs using UDP. Currently, there is no suitable patch to backport. I hope that improved

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

* Aurelien Jarno: Currently, there is no suitable patch to backport. I hope that improved port randomization will be available shortly. You mean a patch for the kernel? Yes, one for the kernel, and one for the transaction ID generation in the libc resolver, too. (Oh, and shortly == next

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

reopen 491809 thanks * Pierre Habouzit: Kaminsky agrees confirm the issue, so I can say for sure that the glibc isn't vulnerable to the attack he describes, as it needs a resolver that caches additionnal RRs, which the glibc doesn't do. As of attacks that would use non randomized source

Bug#382175: Sun RPC libraries and other stories

* Simon Phipps: On Nov 5, 2008, at 23:23, Michael Banck wrote: - portmap.c /* @(#)portmap.c 2.3 88/08/11 4.0 RPCSRC static char sccsid[] = @(#)portmap.c 1.32 87/08/06 Copyr 1984 Sun Micro; */ This is portmap-6.0, from http://neil.brown.name/portmap/ Is this in any way related to

Bug#382175: Sun RPC libraries and other stories

* Simon Phipps: On Nov 18, 2008, at 03:52, Ben Hutchings wrote: Many of the functions in portmap.c seem to correspond to rpcbind (usr/src/cmd/rpcbind) in OpenSolaris: Is it just the function prototypes that are derived, or is there derived source defining them too? From our portmap.c: |

Bug#519774: libc6: causes many programs not to be able to resolve dns addresses

* Mark Kamichoff: Hi - The problem is that the DNS server of your ISP does not conform to the RFC and only answer to the query with a void answer. It never answer to the A query, so the glibc resolver can only conclude the whole query has no answer. Just a thought, many DNS ALGs on

Bug#414795: libpthread/NPTL: static linking seems to break raise(3), abort(3)

* Alex Pennace: A program that is statically linked to NPTL will fail at runtime when calling raise(3) (and, by extension, abort(3)): Statically linked executables simply do not support NPTL. If possible, a link-time warning should be generated, perhaps even an error. -- To UNSUBSCRIBE,

Bug#414795: libpthread/NPTL: static linking seems to break raise(3), abort(3)

* Alex Pennace: Is it the case that NPTL's design critera explicitly excluded static linking, or is that facility a work in progress? libc as a whole doesn't really support static linking anymore. For instance, gethostbyaddr and friends only work with the exact libc version you linked

Bug#414795: libpthread/NPTL: static linking seems to break raise(3), abort(3)

* Daniel Jacobowitz: Statically linked executables simply do not support NPTL. If possible, a link-time warning should be generated, perhaps even an error. Actually, I don't know that this is correct. Several mailing list postings strongly suggest that this is upstream's position. -- To

Bug#416442: libc6: Wrong groups applied to user

* Fabio Pugliese Ornellas: However, the bigger group name has 26 char only (as you can see on previous mesage)... still under 32. Should work, right? You're hitting the total number of groups limit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble?

Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed

* Sven Luther: As said, i see this on both an x86 box and my powerbook, but the complete code is more involved, having a pselect, as well as a SIGALRM handler, which both trigger the localtime_r, as well as a postgresql access and files access. localtime_r is not async-signal-safe, so this

Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed

* Sven Luther: On Thu, Apr 05, 2007 at 08:46:08AM +0200, Florian Weimer wrote: * Sven Luther: As said, i see this on both an x86 box and my powerbook, but the complete code is more involved, having a pselect, as well as a SIGALRM handler, which both trigger the localtime_r

Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed

* Sven Luther: Yes, i use localtime / getoftime / time from the signal handler, yes, i guess that is causing the problem i m seeing. Need to find another way to find the time from a handler. maybe using the timer_create thingy, but it is also undocumented. timer_gettime is async-signal-safe

Bug#419012: /lib/ld-2.5.so: Conditional jump or move depends on uninitialised value(s)

severity 419012 normal tags 419012 - security reassign 419012 valgrind thanks * Tobias Schlemmer: valgrind reports jumps depending on uninitialized valuse in /lib/ld-2.5.so. I found this bug using some gfortran 4.2, but I get it also using the standard gcc package (version 4:4.1.1-15). This

Bug#420301: libc6: IPv6 transport fails for resolver

* Tim: Is there anything I can do to debug this directly on my system? I don't see anything in my system logs, which I didn't really expect to. strace output might help to diagnose this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL

Bug#679828: libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC

* Matthew Grant: From my investigations this can only be enabled by recompiling each bit of software to set the RES_USE_DNSSEC flag in _res.options, as well as RES_USE_EDNS0. (Please see racoon bug #679483). The enablement method is from openssh 6.0p1, openbsd-compat/getrrsetbyname.c This

Bug#162576: marked as done (libc6-dev: errno is a function call in non-threaded program)

Herbert Xu [EMAIL PROTECTED] writes: Florian Weimer [EMAIL PROTECTED] wrote: The slowdown is a price to be paid, otherwise we would need a different set of almost all shared libraries for linking with multi-threading programs. I think we already had this situation, and it wasn't nice

Bug#166543: libc6-dev: using GCC pow(x,y); does not compile.

, by invoking gcc with the -lm parameter. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject

Bug#166543: libc6-dev: using GCC pow(x,y); does not compile.

, by invoking gcc with the -lm parameter. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898

Bug#181493: Is the Sun RPC License DFSG-free?

Andrew Suffield [EMAIL PROTECTED] writes: On Fri, Aug 22, 2003 at 06:39:47AM +, Brian M. Carlson wrote: Sun RPC is a product of Sun Microsystems, Inc. and is provided for unrestricted use provided that this legend is included on all tape media and as a part

Bug#296490: libc6: getgrnam segfault (using __nscd_getgrnam_r)

* Tom Parker: Calling getgrnam() with a NULL argument, with group in /etc/nsswitch.conf set to 'compat' can cause a segfault in __nscd_getgrnam_r due to a lack of a check for a NULL string before doing strlen(). Is there any standard that defines the behavior of getgrnam(NULL)? -- To

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

* Vesselin Peev: #include netdb.h int main() { gethostbyname(www.google.com); return 0; } number of leaked objects: 49 This is not a problem, unless this number grows with each gethostbyname invocation. The underlying programming pattern which causes this is quite common and

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

* Vesselin Peev: This is not a problem, unless this number grows with each gethostbyname invocation. The underlying programming pattern which causes this is quite common and perfectly harmless (if you get the threading issues right, of coruse). Just tested it in a loop, the leaks stay

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

* Vesselin Peev: I'm thinking of submitting a wish about better handling, You could reuse this bug report (downgrade it to wishlist, reassign if necessary). if possible with the mudflap architecture, of internal data allocated by libc. Proper handling should of course include no unaccessed

Bug#326832: libc6: valgrind reports use of uninitialized values

reassign 326832 valgrind thanks * Justin Pryzby: valgrind reports 13 instances of Conditional jump or move depends on uninitialised value(s) using the new libc6 in testing, for a trivial program which just calls exit(0). This is valgrind-2.4.0-3. This means that the valgrind suppression

Bug#335476: nscd: Caches old IP-address

* Dave Love: Yes, please turn off the default persistent caching of hosts (at least). I think this should also be done upstream. It can lead to lockout of logins in an obscure fashion -- at least it did on Fedora systems running what appears to be the same version of nscd with the same

Bug#335476: nscd: Caches old IP-address

* Dave Love: Florian Weimer [EMAIL PROTECTED] writes: The current code tries to honor TTLs. It might be sufficient to set a zero (or very low) TTL for entries coming from /etc/hosts. Does `current' mean in the latest Debian package? Yes. I can't see anything relevant in the changelog

Security-related patches for wheezy (and squeeze LTS)

I would like to send a few security-related backports frpm upstream your way. On the security side, we won't do a DSA for any of those (probably; I still haven't got a complete handle on what's missing). But it's certainly wheezy-updates material. Should I just send the patches, or do you want

Bug#717544: CVE-2013-2207: Remove pt_chown

* Samuel Thibault: Hello, Florian Weimer, le Thu 06 Aug 2015 07:15:01 +0200, a écrit : retitle 717544 CVE-2013-2207: Remove pt_chown thanks Can we please make another attempt at removing pt_chown, either completely or by removing the SUID bit? On linux ports only, please, kfreebsd

Bug#717544: CVE-2013-2207: Remove pt_chown

retitle 717544 CVE-2013-2207: Remove pt_chown thanks Can we please make another attempt at removing pt_chown, either completely or by removing the SUID bit? The current devpts file system is set up in such a way that this is not necessary. Fedora and Red Hat Enterprise Linux 7 already ship

Bug#802256: Backport tls_dtor_list hardening

Package: libc6 Version: 2.19-18+deb8u1 Please backport this upstream hardening patch to jessie (wheezy does not have this feature yet): https://sourceware.org/bugzilla/show_bug.cgi?id=19018 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f586e1328681b400078c995a0bb6ad301ef73549 Also

Bug#815974: Segmentation fault in libresolv triggered by php5-fpm

* Aurelien Jarno: > On 2016-02-26 13:31, Carlos O'Donell wrote: >> On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt >> wrote: >> > This is the correct output, the older one contains a test I thought was >> > in an endless loop but succeeded after a few minutes. >> >> The

Bug#783210: [PATCH] nscd_stat.c: make the build reproducible

On 03/09/2016 05:30 PM, Mike Frysinger wrote: would it be so terrible to properly marshall this data ? Ximin Luo and I discussed this and I wonder if it is possible to read out the libc.so.6 build ID if it is present. It should indirectly call all the layout dependencies and be reasonably

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Fernando Santagata: > One month ago everything worked fine on my Debian sid computer. > After an update/dist-upgrade cycle in which libc6 was updated I > started noticing some malfunctions. Did you upgrade the kernel at the same time?

Re: segfault in errx

* Florian Weimer: >> I can reproduce something like this with 2.24-3 on amd64. valgrind >> isn't very helpful. > > And it needs a UTF-8 locale (C.UTF-8 will do). Another multi-byte > locale may work as well. Bisecting this with the attached scr

Bug#824429: libc6: In certain locale combinations mbsrtowcs cannot recover from EILSEQ

tags 824429 upstream forwarded 824429 https://sourceware.org/bugzilla/show_bug.cgi?id=20617 thanks * Christoph Biedl: > It might be questionable whether this is a bug in glibc at all. But at > least it's surprising behaviour. > > The reproducer below calls mbstowcs two times, first time with >

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Aurelien Jarno: > On 2016-09-27 13:44, Florian Weimer wrote: >> * Aurelien Jarno: >> >> > Hmm, rsync doesn't use libpthread, so that clearly rules out a >> > libpthread issue. That said, all the example you gave fail to allocate >> > the memory correc

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Fernando Santagata: >> Usually it manifests in premature OOM killer invocations, but maybe >> something the reporter's system configuration changes that (perhaps it >> runs with vm.overcommit_memory=2?). > > That's it. I found this in /var/log/kern.log at the time I run a program > that

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Aurelien Jarno: > Hmm, rsync doesn't use libpthread, so that clearly rules out a > libpthread issue. That said, all the example you gave fail to allocate > the memory correctly, either through malloc (glibc) or mmap (kernel) > which returns -ENOMEM. This points to either a kernel issue, or a >

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Richard Laager: > Getting back to ZFS and /etc/hostid... I would think that a > randomly-generated /etc/hostid is probably sufficient. Whether that's > done in the libc, spl, or zfs package makes no difference to me. As I tried to explain, the risks of collisions without central coordination

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Michael Stone: > Other platforms have deprecated gethostid, that's the best way forward > for linux, IMO. I agree. It's the most likely outcome if this issue was reported to glibc upstream.

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Petter Reinholdtsen: > [Florian Weimer] >> That's not very different from /etc/machine-id, isn't it? > > Ah, thank you very much for bringing this systemd setting to my > attention. I was not aware of it. > > I agree that it seem very similar in pu

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Petter Reinholdtsen: > Something like this should work, I guess: > > if [ ! -f /etc/hostid ]; then >if [ -e /sys/class/dmi/id/product_uuid ]; then >sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid) >else > dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null >

Re: segfault in errx

* Michael Meskes: > I recently learned that ul (from bsdmainutils) segfaults when run > against the attached file. Some debugging shows that the segfault > happens when cleaning up in errx(): > > michael@feivel:~$ ul ul.segf > ul: unknown escape sequence in input: 33, 135 >

Re: segfault in errx

* Florian Weimer: > * Michael Meskes: > >> I recently learned that ul (from bsdmainutils) segfaults when run >> against the attached file. Some debugging shows that the segfault >> happens when cleaning up in errx(): >> >> michael@feivel:~$ ul ul.segf >>

Bug#839280: libc6: asprintf(, "%F", 1.0) puts 0.00000 in c on raspberry pi zero v1.3.

* Noah Williams: >* What led up to the situation? I was building a robot, and needed a > raspberry pi zero to send a floating point number formatted as a string to an > arduino. >* What exactly did you do (or not do) that was effective (or > ineffective)? I've tried passing bigger

Bug#858529: libc6: fgets repeats content after fork on stretch only

tags 858529 upstream forwarded 858529 https://sourceware.org/bugzilla/show_bug.cgi?id=20598 thanks * Neil Spring: > if(fork() == 0) { exit(1); } exit flushes the stdio buffers in the child. Upstream concluded that this leads to undefined behavior: | Yes, this is about the exit actually.

Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

* John Paul Adrian Glaubitz: > I would suggest filing a bug report to glibc upstream or posting on > their mailing list to ask for feedback. Upstream has since removed the PID cache:

Bug#879093: Segfault in libc6 while using xrdp-sesman on Stretch

* Gilles MOREL: > I repported this bug for the package libc6 because the kernel line let > me think the problem comes from libc6. It's much more likely that xrdp-sesman calls a glibc function on an invalid pointer. > If you want me to provide more log or debugging, please tell me, I > don't

Bug#897373: libc6: feof(file) always false when forking after read

* David Beniamine: > int do_fork() { > pid_t pid; > > switch (pid = fork()) { > case -1: > fprintf(stderr, "Fork failed\n"); > return -1; > case 0: > exit(-1); Does the issue go away when you call _exit instead of exit?

Bug#897373: libc6: feof(file) always false when forking after read

* David Beniamine: > On Thu, May 10, 2018 at 07:06:03PM +0200, Florian Weimer wrote: >> * David Beniamine: >> >> > int do_fork() { >> > pid_t pid; >> > >> > switch (pid = fork()) { >> > case -1: >> >

Bug#620887: Please add a shm_mkstemp() function

On 05/16/2018 10:25 PM, Jakub Wilk wrote: * Goswin von Brederlow , 2011-04-04, 23:33: int shm_mkstemp(char *template); FWIW, this function is available on OpenBSD: https://man.openbsd.org/shm_mkstemp.3 We have memfd_create nowadays. It's not exactly identical because it

Bug#900025: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header

* Aurelien Jarno: > Now I don't find this common/utils.c file in the simple-scan sources. This looks like a known hplip bug: https://bugzilla.redhat.com/show_bug.cgi?id=1347231 More recent sources try to load libm.so.6 as well. Note that shared objects which use libm (or any libc) functions

Bug#861116: Fixed in glibc 2.28

The issue should be fixed with this upstream commit: commit c402355dfa7807b8e0adb27c009135a7e2b9f1b0 Author: Florian Weimer Date: Tue Jun 26 10:24:52 2018 +0200 libio: Disable vtable validation in case of interposition [BZ #23313] <https://sourceware.org/git/gitweb.cgi?p=glibc.

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

* Luke Kenneth Casson Leighton: > that is not a surprise to hear: the massive thrashing caused by the > linker phase not being possible to be RAM-resident will be absolutely > hammering the drives beyond reasonable wear-and-tear limits. which is > why i'm recommending people try

Bug#880846: libc-bin: libnss_compat is deprecated and nsswitch should stop using it on new installation

* Laurent Bigonville: > According to the release note of 2.26, the nss_compat module is > deprecated[0]. > [0]https://sourceware.org/ml/libc-announce/2017/msg1.html I think we made changes so that it is no longer deprecated, by removing the hard NIS dependency. It shouldn't be used by

Bug#895981: please cleanup /var/cache/nscd on restart

* Harald Dunkel: > I am using both systemd and sysvinit-core, but I am not sure which one > was active when I ran into this problem. > > Consider a split DNS setup for a remote network. I had started an IPsec > connection to the remote side. /etc/resolv.conf was changed to include > the new

Bug#895981: please cleanup /var/cache/nscd on restart

* Carlos O'Donell: > Then each registered file, like /etc/resolv.conf, is watched via > inotify for any changes, and if a change is detected and > finfo->call_res_init was true (and it's true only for resolv.conf) > then we call res_init(). But res_init does not flush the nscd cache, doesn't it?

Bug#887169: libc6: recent upgrade to 2.26-3 broke Steam games (Civ5)

On 01/15/2018 12:22 AM, Aurelien Jarno wrote: I don't think it is actually the consensus, only Arch Linux has chosen this solution, and building the whole glibc with this option will have an impact of the performances for all binaries, not only the broken Steam ones. I therefore don't think it's

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

* Paul Gevers: > Hi Florian, > > On 29-07-18 13:26, Florian Weimer wrote: >> I'm not sure why it is necessary to build glibc three times (unless >> it's impossible to get multi-arch packages into the buildroot). > > I am not sure if I understand what you mean, but

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

* Paul Gevers: > On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer wrote: >> > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours >> > built on amd64, the glibc takes around 20 minutes to build and the >> > testsuite around 2h to run. >>

Bug#902851: libc-bin: ldd stopped working with 32-bit binaries on amd64 machine

* Alexandra N. Kossovsky: > Please close this bug. I definitely saw the issue yesterday, but it has > somehow gone today. I'll return to you if I see it again and understand > what triggers it. The related Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1596312 appears to have

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

* Aurelien Jarno: > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours > built on amd64, the glibc takes around 20 minutes to build and the > testsuite around 2h to run. This is still rather slow. I see native builds on relatively current hardware taking 2 minutes, plus 12

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

* Niels Thykier: > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] Fedora is facing an issue running armhf under virtualization on arm64:

Bug#761300: libc6: Printf("%c",'x') does not follow stdio

* Sven Joachim: > This result is rather surprising. After all, "putchar('x')" is supposed > to do the same as "putc('x', stdout)", but here it does not. Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3? Or on something else besides armhf?

Bug#912665: (geen onderwerp)

* Frederik Himpe: > FYI, this is where it crashes: > > #0 0x7fc0172239c6 in _IO_fgets (buf=0x7ffc9b2b1640 " > /dev/aivmhost3-vg/ceph-node1-storage:ceph-ff35163d-b03f-4dbf-a6ce-155730069dc0:4194304:-1:8:8:-1:4096:511:0:511:ZNexTV-ylVb-ltMP-T8Zu-ZklU-cN1I-dETf5o\n", > n=1024, fp=0x1a90030) >

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

* Андрей Доценко: > The problem occurs only when using semaphores in a library that is not > linked against pthread. Yes, that's expected. Sorry I didn't see this earlier—we have an upstream bug about this: In general, underlinking

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

* 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

Bug#761300: libc6: putchar does not follow stdio

* Sven Joachim: > Am 14.10.2018 um 13:38 schrieb Florian Weimer: > >> * Sven Joachim: >> >>> This result is rather surprising. After all, "putchar('x')" is supposed >>> to do the same as "putc('x', stdout)", but here it does not. >&g

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Laurent Bigonville: > Le 19/03/19 à 19:43, Florian Weimer a écrit : >> * Laurent Bigonville: >> >>> Package: libc6-dev >>> Version: 2.28-8 >>> Severity: serious >>> >>> Hi, >>> >>> The crypt.3 manp

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

* Lucas Nussbaum: > On 26/03/19 at 23:10 +0100, Aurelien Jarno wrote: >> 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

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

* Christoph Berg: > with the update to glibc 2.28, collation aka sort ordering is > changing: > > $ echo $LANG > de_DE.utf8 > $ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort > > stretch: > aa > a a > a-a > a+a > > buster: > a a > a+a > a-a > aa > > A vast number of

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

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 >>

Bug#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

* Joël Krähemann: > This happens as you call pthread_cond_destroy() twice on the very same > cond variable. Surely that's an application bug. Why do you think this is a glibc issue? Thanks, Florian

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Laurent Bigonville: > Package: libc6-dev > Version: 2.28-8 > Severity: serious > > Hi, > > The crypt.3 manpage, state that _XOPEN_SOURCE should be define for > crypt() to be available. > > But it looks that it's currently the opposite, if _XOPEN_SOURCE is > defined, the function cannot be

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

> 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

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: >> Is there a way to reproduce your results easily? Upstream, we're >> looking for workloads which are difficult to handle for glibc's malloc >> and its default settings, so that we hopefully can improve things >> eventually. > > This way of the ready builds of the

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

* Pavel Matěja: > The strange means they appear only on 2 servers out of 6. > Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon > E3-1220 v6 produced crashes. > It did not matter if the host Debian was Stretch or Buster. Do you see crashes on stretch as well? What does the

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Francesco Poli: > Hello everyone, > I am sorry to ask, but... I cannot understand what's the status of > [this bug report]. > > [this bug report]: > > A serious bug for libc6-dev without any apparent activity since last > March? Sure there must have been some

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

* Pavel Matěja: > Sorry for late answer. > > On 17. 08. 19 22:18, Florian Weimer wrote: >> * Pavel Matěja: >> >>> The strange means they appear only on 2 servers out of 6. >>> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon >

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: > Initial condition of the problem representing is a program in the > single source code, built on-and for Debian 7, 8, 9, 10 with a result > in the Live disks. I think glibc 2.13 as shipped by Debian was not built with --enable-experimental-malloc, so it doesn't use arenas.

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: > Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have > got the memory effectivity some better even than in Debian 7! Is there a way to reproduce your results easily? Upstream, we're looking for workloads which are difficult to handle for glibc's malloc and

Re: Options for 64-bit time_t support on 32-bit architectures

* Simon McVittie: > On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote: >> Remaining usecases of i386 will be old binaries, some old Linux binaries >> but especially old software (including many games) running in Wine. >> Old Linux binaries will still need the old 32bit time_t. > > Based

Options for 64-bit time_t support on 32-bit architectures

There is an effort under way to enhance glibc so that it can use the Y2038 support in the kernel. The result will be that more 32-bit architectures can use a 64-bit time_t. (Currently, it's x86-64 x32 only.) Originally, the plan was to support both ABIs in glibc for building new applications,

Re: Options for 64-bit time_t support on 32-bit architectures

* Adrian Bunk: > [ only speaking for myself ] > > On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote: >>... >> The consequence is that in order to build 32-bit-time_t libraries >> (Gtk, for example), an old glibc needs to be kept around. In >>

Re: Options for 64-bit time_t support on 32-bit architectures

* Adrian Bunk: > On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: >> * Adrian Bunk: >>... >> For comparison, the original plan was to provide a macro, perhaps >> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI >> set is used (

  1   2   >