Bug#975026: Use 公元 not 西元

2020-11-17 Thread Florian Weimer
* 積丹尼 Dan Jacobson: > I think this, > $ LC_TIME=zh_TW.UTF-8 date > 西元2020年11月18日 (週三) 12時39分44秒 CST > should say 公元 not 西元. Why do you think so? These Taiwanese newspapers appear to use 西元 for Gregorian years:

Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs

2020-10-23 Thread Florian Weimer
* Aurelien Jarno: > brk/sbrk is definitely something deprecated. But it is still part of the > API (especially for old architectures) and still used by software like > jemalloc, gcl or libgc. This is therefore important to keep this feature > in a good shape. > > It's also used by many less

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

2020-09-06 Thread Florian Weimer
* Aurelien DESBRIERES: > This is emacs and jedi-mode and much more elisp stuff to works with > emacs as python3 ide. > > Please update this glibc it seems to be outdated! That's simply not going to happen for the buster release. You will have to change the way you set up your pip environment.

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

2020-09-06 Thread Florian Weimer
* aurelien desbrieres: > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >try to use jedi-mode on emacs >* What exactly did you do (or not do) that was effective (or > ineffective)? >M-x jedi:install-server >

Bug#969618: getopt: optarg is NULL outside of loop

2020-09-06 Thread Florian Weimer
* John Scott: > #define _POSIX_C_SOURCE 200809L > #include > #include > #include > #include > int main(int argc, char *argv[]) { > int opt; > while((opt = getopt(argc, argv, "a:")) != -1) {} > assert(optarg != NULL); > } > > If this is invoked as './a.out -afoo', the inner

Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

2020-08-06 Thread Florian Weimer
* Aurelien Jarno: > On 2020-08-06 06:08, Jinpu Wang wrote: >> Hi Florian, >> >> On Wed, Aug 5, 2020 at 6:44 PM Florian Weimer wrote: >> > >> > * Jinpu Wang: >> > >> > > Dear Maintainer: >> > > >> > > Sorry, a

Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

2020-08-05 Thread Florian Weimer
* Jinpu Wang: > Dear Maintainer: > > Sorry, add some missing information below: > > After update to Buster, the systemd-sysusers are segfaulting every time. > After search around, I found following bugreport in glibc > https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01015.html > > I

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

2020-08-04 Thread Florian Weimer
* Florian Weimer: >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) > > I'm surprised to read this. ppc64el features prominently in the > toolchain work I do (thou

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

2020-07-09 Thread Florian Weimer
* Paul Gevers: > * Concern for armel and armhf: only secondary upstream support in GCC >(Raised by the GCC maintainer; carried over from stretch and buster) glibc upstream lately has trouble finding qualified persons to implement security fixes for the 32-bit Arm architecture. > * Concern

Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

2020-06-30 Thread Florian Weimer
* Petr Vorel: >> nss_compat no longer depends on libnsl in current glibc. It can be used >> without NIS, and some users do that. I don't think your patch changes >> this. > Interesting. I guess adding this would be worth then: > libnss_compat no longer depends on libnsl and can be used without

Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

2020-06-30 Thread Florian Weimer
* Petr Vorel: > Hi Florian, > > thank you for your review. I'll have time to send next version in second > half of July. If we merge new ports for glibc 2.32, it would be nice not include sunrpc in them. We'll figure something out. >> > diff --git a/grp/initgroups.c b/grp/initgroups.c >> >

Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

2020-06-24 Thread Florian Weimer
* Petr Vorel: > diff --git a/NEWS b/NEWS > index a660fc59a8..cfaf50c816 100644 > --- a/NEWS > +++ b/NEWS > @@ -33,6 +33,14 @@ Major new features: > > Deprecated and removed features, and other changes affecting compatibility: > > +* Remove configure option --enable-obsolete-nsl. libnsl is

Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

2020-06-24 Thread Florian Weimer
* Aurelien Jarno: >> This doesn't seem correct to me. Is there any documentation giving a >> rationale for this ? Is there a way to change this locally ? > > I do not know enough about apparmor and its threat model to know if it > should be considered or not. From the glibc point of view,

Re: [RFC PATCH v2 0/2] Remove --enable-obsolete-nsl --enable-obsolete-rpc

2020-06-05 Thread Florian Weimer
* Petr Vorel: >> I'm still having issues with elf/tst-ldconfig-ld_so_conf-update when >> running with both commits (it's ok when running only first commit). > > OK, I noticed core dump (can be reproduced): > systemd-coredump[26018]: Process 26016 (ld-linux-x86-64) of user 1000 dumped > core. > >

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-30 Thread Florian Weimer
* Florian Weimer: > I raised the matter of compiler defaults on the GCC list: > > <https://gcc.gnu.org/pipermail/gcc/2020-April/232261.html> The link is now: <https://gcc.gnu.org/pipermail/gcc/2020-April/000491.html>

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-29 Thread Florian Weimer
I raised the matter of compiler defaults on the GCC list: Thanks, Florian

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-22 Thread Florian Weimer
* Noah Meyerhans: > On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: >> > Significant performance impact has also been observed in less contrived >> > cases (MariaDB and Postgres), but I don't have a repro to share. >> >> But indeed what counts is number on real workloads. It

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Florian Weimer
* Noah Meyerhans: > On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote: >> > At least if I'm reading the code right (which I may very well not be >> > doing, being generally unfamiliar with gcc internals), -mtune=generic >> > enables the equivalent of

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Florian Weimer
* Noah Meyerhans: > On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote: >> > 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

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Florian Weimer
* Noah Meyerhans: > 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. Shouldn't GCC do this by default, at least for -mtune=generic?

Bug#954715: glibc: FTBFS: tests failed: signal/tst-minsigstksz-1 signal/tst-minsigstksz-2

2020-03-22 Thread Florian Weimer
* Lucas Nussbaum: > Source: glibc > Version: 2.30-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200322 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. >> FAIL:

Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

2020-03-13 Thread Florian Weimer
* Matthias Klose: > ok, now removing that leads to: > > $ cat foo.c > #include > > $ gcc -c foo.c > In file included from foo.c:1: > /usr/include/limits.h:124:26: error: no include path in which to search for > limits.h > 124 | # include_next > | ^ > >

Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

2020-03-04 Thread Florian Weimer
* Matthias Klose: > On 3/4/20 9:33 AM, Florian Weimer wrote: >> * Matthias Klose: >> >>> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >>> least on s390x, you get a non-wrorking compiler, which at least cannot glibc >>&g

Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling

2020-02-16 Thread Florian Weimer
* Aurelien Jarno: >> I've been running into this myself a lot lately and wonder if >> anything has happened regarding this since 2014, after all it's >> been six years. >> I'm surprised so few people seem to be taking interest in this >> considering the amount of tools that rely on frame

Bug#951191: Backport /proc-based lchmod/fchmodat emulation

2020-02-12 Thread Florian Weimer
Unfortunately, this change tickles an XFS bug:

Bug#951191: Backport /proc-based lchmod/fchmodat emulation

2020-02-12 Thread Florian Weimer
consists of these patches: commit 173ec37bb2af6e30892a141d74d42db5957ddd36 Author: Florian Weimer Date: Sun Feb 9 11:50:44 2020 +0100 support: Add the xlstat function commit f6233ab412c3bebebacf65745e775e01506dd58d Author: Florian Weimer Date: Sun Feb 9 11:51:08 2020 +0100 Linux

Bug#948396: New glibc broke existing app due to historic stack alignment

2020-01-14 Thread Florian Weimer
* Petr Vandrovec: > Florian Weimer wrote on 1/7/2020 9:31 PM: >> * Petr Vandrovec: >> >>> As far as I can tell, while x86-64 ABI requires stack to be aligned >>> on entry to the functions, x86 ABI does not have any such >>> requirement, and so g

Bug#948396: New glibc broke existing app due to historic stack alignment

2020-01-07 Thread Florian Weimer
* Petr Vandrovec: > As far as I can tell, while x86-64 ABI requires stack to be aligned > on entry to the functions, x86 ABI does not have any such > requirement, and so glibc should align stack itself if it wants to > use XMM instructions that require aligned values. The i386 ABI was changed

Bug#941277: dispatch function missing in header file generated for RPC service

2019-09-27 Thread Florian Weimer
* Simon Richter: > while implementing an RPC service (in 2019, no less!) I found out that the > dispatch function generated by rpcgen is not listed in the generated header > file, so if the service is generated without a main function or inetd > interface, the code using it needs to create its

Bug#874160: Fedora has C.UTF-8

2019-09-27 Thread Florian Weimer
* Adam Borowski: > Looks like Fedora has C.UTF-8 now, and even backported this change to their > stable releases: > > https://bugzilla.redhat.com/show_bug.cgi?id=902094 > > They're not upstream, but a good part of distros that are not downstream > from Debian are downstream from Fedora. This

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

2019-08-27 Thread Florian Weimer
* 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#924712: crypt() not available _XOPEN_SOURCE is defined

2019-08-25 Thread Florian Weimer
* 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

2019-08-17 Thread Florian Weimer
* 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#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

2019-08-14 Thread Florian Weimer
* 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#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

2019-08-09 Thread Florian Weimer
* 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

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

2019-08-07 Thread Florian Weimer
* 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.

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

2019-07-21 Thread Florian Weimer
* 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

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

2019-07-19 Thread Florian Weimer
* 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 (

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

2019-07-19 Thread Florian Weimer
* 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 >>

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

2019-07-18 Thread Florian Weimer
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,

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

2019-03-27 Thread Florian Weimer
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#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

2019-03-27 Thread Florian Weimer
* 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?)

2019-03-25 Thread Florian Weimer
* 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

2019-03-22 Thread Florian Weimer
> 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#924712: crypt() not available _XOPEN_SOURCE is defined

2019-03-21 Thread Florian Weimer
* 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#924712: crypt() not available _XOPEN_SOURCE is defined

2019-03-19 Thread Florian Weimer
* 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#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

2019-03-06 Thread Florian Weimer
* 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#920047: glibc: CVE-2016-10739: getaddrinfo should reject IP addresses with trailing characters

2019-01-21 Thread Florian Weimer
* 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#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture

2019-01-16 Thread Florian Weimer
* Андрей Доценко: > 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#761300: libc6: putchar does not follow stdio

2018-12-28 Thread Florian Weimer
* 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#912665: (geen onderwerp)

2018-11-02 Thread Florian Weimer
* 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#761300: libc6: Printf("%c",'x') does not follow stdio

2018-10-14 Thread 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. Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3? Or on something else besides armhf?

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

2018-07-30 Thread Florian Weimer
* 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

2018-07-29 Thread Florian Weimer
* 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

2018-07-07 Thread Florian Weimer
* 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#861116: Fixed in glibc 2.28

2018-07-01 Thread Florian Weimer
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)

2018-06-29 Thread Florian Weimer
* 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

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

2018-06-28 Thread Florian Weimer
* 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#880846: libc-bin: libnss_compat is deprecated and nsswitch should stop using it on new installation

2018-06-20 Thread Florian Weimer
* 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#900025: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header

2018-05-25 Thread Florian Weimer
* 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#620887: Please add a shm_mkstemp() function

2018-05-18 Thread Florian Weimer
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#897373: libc6: feof(file) always false when forking after read

2018-05-10 Thread Florian Weimer
* 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#897373: libc6: feof(file) always false when forking after read

2018-05-10 Thread Florian Weimer
* 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#895981: please cleanup /var/cache/nscd on restart

2018-04-30 Thread Florian Weimer
* 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#895981: please cleanup /var/cache/nscd on restart

2018-04-29 Thread Florian Weimer
* 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#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

2018-04-02 Thread Florian Weimer
* 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

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

2018-01-15 Thread Florian Weimer
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#879093: Segfault in libc6 while using xrdp-sesman on Stretch

2017-10-24 Thread Florian Weimer
* 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#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

2017-03-23 Thread Florian Weimer
* 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#858529: libc6: fgets repeats content after fork on stretch only

2017-03-23 Thread Florian Weimer
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#839280: libc6: asprintf(, "%F", 1.0) puts 0.00000 in c on raspberry pi zero v1.3.

2016-10-01 Thread Florian Weimer
* 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#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

2016-09-29 Thread Florian Weimer
* 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

2016-09-28 Thread Florian Weimer
* 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.

Re: segfault in errx

2016-09-28 Thread Florian Weimer
* 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

Re: segfault in errx

2016-09-28 Thread Florian Weimer
* 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 >>

Re: segfault in errx

2016-09-28 Thread 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 > ul: unknown escape sequence in input: 33, 135 >

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

2016-09-28 Thread Florian Weimer
* 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

2016-09-28 Thread Florian Weimer
* 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 >

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

2016-09-27 Thread Florian Weimer
* 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.

2016-09-27 Thread Florian Weimer
* 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.

2016-09-27 Thread Florian Weimer
* 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#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

2016-09-26 Thread Florian Weimer
* 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?

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

2016-09-18 Thread Florian Weimer
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#783210: [PATCH] nscd_stat.c: make the build reproducible

2016-07-28 Thread Florian Weimer
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#815974: Segmentation fault in libresolv triggered by php5-fpm

2016-03-01 Thread Florian Weimer
* 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#802256: Backport tls_dtor_list hardening

2015-10-18 Thread Florian Weimer
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#717544: CVE-2013-2207: Remove pt_chown

2015-08-23 Thread Florian Weimer
* 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

2015-08-05 Thread Florian Weimer
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

Security-related patches for wheezy (and squeeze LTS)

2014-08-31 Thread Florian Weimer
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#679828: libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC

2012-07-02 Thread Florian Weimer
* 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#609756: vsnprintf segfaults on second attempt with alloca

2011-01-12 Thread Florian Weimer
* 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

2011-01-12 Thread Florian Weimer
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

squeeze upload for eglibc due to DSA-2122-2

2011-01-11 Thread Florian Weimer
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#600667: eglibc: cve-2010-3847 dynamic linker expands $ORIGIN in setuid library search path

2010-10-22 Thread Florian Weimer
* 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

2010-10-22 Thread Florian Weimer
* 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

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

2010-02-10 Thread Florian Weimer
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#519774: libc6: causes many programs not to be able to resolve dns addresses

2009-03-17 Thread Florian Weimer
* 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#382175: Sun RPC libraries and other stories

2008-11-18 Thread Florian Weimer
* 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

2008-11-18 Thread Florian Weimer
* 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#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

2008-07-25 Thread Florian Weimer
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

  1   2   >