Bug#808181: libc6: Upgrade can make the linker unusable

[Christophe]

I am not sure to understand correctly...
I currently have the same behavior with Stretch without sid/experimental
repository, and I see binutils is not ready to migrate from testing, so no
partial updates here I think.
I  do not understand how libc6-dev came built with an unavailable binutils
version on Stretch.

Christophe

Bug#808181: libc6: Upgrade can make the linker unusable

[Emmanuel Charpentier]

Dear developers,

I've just got bitten by this bug. About 3 millimeters from my carotid
artery...

This bugs effectively renders my system unusable for compilation
purposes : even extremely mundane uses, such as upgradng some R
packages, is now impossible.

Suggestions :

1) The gravity of this bug should be elevated : it renders the system
unusable at least for some mundane uses.
2) The upgrade to glibc should be conditioned to the upgrade of
binutils
3) A workaround should be posted on this bug report as soon as possible
(upgrade to unstable's binutils ?), and possibly publicized by larger
means (finding this bug is not obvious for pedestrian users like
me...).

Sincerely yours,

--
Emmanuel Charpentier

Bug#808205: libc6: Unrecognized relocation when compiling

[John Aston]

Package: libc6
Version: 2.21-4
Severity: important

Dear Maintainer,

When attempting to compile a simple C program, the link stage fails with an 
unrecognized relocation error.

This problem seems to have appeared in the latest version, 2.21-4 (and is also 
present in 2.22-0experimental which I tested before submitting); it was not 
present in 2.19-22 which I was using prior to tonight.  When using 2.19-22 
(pinned to that version after installing the package from a CD), it works 
normally.  When upgraded, it fails as per below.

The problem manifested in a much more complicated build process, but I can 
duplicate it with a program as simple as this:

#include 
int main() {
fprintf(stdout, "Hello, world.\n");
return(0);
}

When compiling, the following error happens: 

$ gcc hello.c -o hello
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: 
unrecognized relocation (0x2a) in section `.init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

The expected behavior is for the program to compile normally without error.


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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:5.2.1-23

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.58
pn  glibc-doc  
ii  libc-l10n  2.22-0experimental1
ii  locales2.21-4

-- debconf information:
  glibc/disable-screensaver:
  glibc/restart-services:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true
  glibc/restart-failed:
  glibc/upgrade: true
  glibc/kernel-too-old:

Processed: Re: Bug#808181: libc6: Upgrade can make the linker unusable

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #808181 [libc6] libc6: Upgrade can make the linker unusable
Severity set to 'important' from 'normal'
> tags -1 stretch
Bug #808181 [libc6] libc6: Upgrade can make the linker unusable
Added tag(s) stretch.

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

Bug#808181: libc6: Upgrade can make the linker unusable

[Vlad Orlov]

Control: severity -1 important
Control: tags -1 stretch


Hi,

Just stumbled upon this today in Testing (Stretch) - after today's libc6 
upgrade.
This issue breaks compilation of ANY autotools-based project as ld fails early 
in the configure phase:

configure:3441: checking whether the C compiler works
configure:3463: gcc -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c  >&5
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: 
unrecognized relocation (0x2a) in section `.init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status


The system has been updated with the usual dist-upgrade, so I don't understand 
the mentioning
of some partial upgrades above (and completely don't understand the part about 
"ignore the problem").

Processed: Re: Bug#808181: libc6: Upgrade can make the linker unusable

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 808181 libc6-dev
Bug #808181 [libc6] libc6: Upgrade can make the linker unusable
Bug reassigned from package 'libc6' to 'libc6-dev'.
Ignoring request to alter found versions of bug #808181 to the same values 
previously set
Ignoring request to alter fixed versions of bug #808181 to the same values 
previously set
> reassign 808205 libc6-dev
Bug #808205 [libc6] libc6: Unrecognized relocation when compiling
Bug reassigned from package 'libc6' to 'libc6-dev'.
No longer marked as found in versions glibc/2.21-4.
Ignoring request to alter fixed versions of bug #808205 to the same values 
previously set
> forcemerge 808181 808205
Bug #808181 [libc6-dev] libc6: Upgrade can make the linker unusable
Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling
Added tag(s) stretch.
Merged 808181 808205
> forcemerge 808181 808206
Bug #808181 [libc6-dev] libc6: Upgrade can make the linker unusable
Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling
Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling
Marked as found in versions glibc/2.21-4.
Marked as found in versions glibc/2.21-4.
Bug #808206 [libc6-dev] unsupported reloc 42 against global symbol 
__gmon_start__
Severity set to 'important' from 'normal'
Added tag(s) stretch.
Merged 808181 808205 808206
> severity 808181 serious
Bug #808181 [libc6-dev] libc6: Upgrade can make the linker unusable
Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling
Bug #808206 [libc6-dev] unsupported reloc 42 against global symbol 
__gmon_start__
Severity set to 'serious' from 'important'
Severity set to 'serious' from 'important'
Severity set to 'serious' from 'important'
> thanks
Stopping processing here.

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

Bug#808181: libc6: Upgrade can make the linker unusable

[Aurelien Jarno]

reassign 808181 libc6-dev
reassign 808205 libc6-dev
forcemerge 808181 808205
forcemerge 808181 808206
severity 808181 serious
thanks

On 2015-12-16 23:36, Aurelien Jarno wrote:
> On 2015-12-16 13:15, Dima Kogan wrote:
> > Package: libc6
> > Severity: normal
> > 
> > Hi. I had
> > 
> >   libc6= 2.19-22
> >   binutils = 2.25-4
> > 
> > and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in
> > sid). As a result, even the most basic build-time linking would fail.
> > For instance, with a trivial hello-world program:
> > 
> >   $ gcc-5 -o tst tst.c
> > 
> >   /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: 
> > unrecognized relocation (0x2a) in section `.init'
> >   /usr/bin/ld: final link failed: Bad value
> >   collect2: error: ld returned 1 exit status
> > 
> > This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would
> > fix it. After some fiddling I realized that upgrading to binutils =
> > 2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the
> > latest libc6 and the latest binutils packages things work.
> 
> The problem is not introduced by the glibc, but just by the fact that
> it has been built with a recent binutils version which adds new
> relocation types on i386 and amd64. This means that ALL static libraries
> are affected by this problem.
> 
> > Can the broken combination be prevented with some Conflicts: tags?
> > Currently this is a trap for the unwary.
> 
> I therefore don't think we need to fix that at the glibc level. Either
> we just ignore the problem saying we don't support partial upgrades or
> we try to find a global way to fix the dependencies for all libraries.

We are working to migrate binutils version 2.25.90.20151209-1 into
testing asap. If everything goes well it should be the case after the
13:52 UTC dinstall run, so a few hours after that on the mirrors.

In the meantime fetching and installing this version from sid, should
solve the issue.

Aurelien

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

Bug#808206: unsupported reloc 42 against global symbol __gmon_start__

[Max Kellermann]

Package: libc6-dev
Version: 2.21-4

$ gcc -x c -  

Bug#691371: marked as done (Broken COPY relocation with UNIQUE symbols (upstream #12510))

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:47:47 +0100
with message-id <20151217184747.ga16...@aurel32.net>
and subject line Re: Bug#691371: Broken COPY relocation with UNIQUE symbols 
(upstream #12510)
has caused the Debian Bug report #691371,
regarding Broken COPY relocation with UNIQUE symbols (upstream #12510)
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.)


-- 
691371: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691371
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.13-35

I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in my 
application. Fixed by 
http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c

Attached is the test-case I came up with before I found the commit that fixes 
it, and then the upstream bug.

This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate 
UNIQUE symbols (at least for this case), AND the old dynamic linker seems to 
not have this bug.

The actual code part of that upstream patch applies cleanly to wheezy's libc 
and fixes the problem. ISTM that it'd be a good idea to backport, given that 
wheezy isn't going to upgrade to a new upstream release.

 test.h 
template
class Foo {
public:
static const char foo[];
};

 test1.cpp 
#include "test.h"

// Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to
// create a WEAK symbol instead.
template
const char Foo::foo[] = "string";
template class Foo;

const char * getone() {
// Creates a R_X86_64_GLOB_DAT relocation
return Foo::foo;
}

 test2.cpp 
#include "test.h"
#include 
#include 

int main() {
// Reference creates a R_X86_64_COPY relocation
if (strcmp(Foo::foo, "string")) {
printf("'%s'\n", Foo::foo);
return 1;
}
return 0;
}


 test.sh 
g++ -fPIC -shared -o test.so test1.cpp
g++ -o test test2.cpp ./test.so
./test
--- End Message ---
--- Begin Message ---
Version: 2.17-1

On 2012-10-24 16:12, James Y Knight wrote:
> Package: libc6
> Version: 2.13-35
> 
> I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in 
> my application. Fixed by 
> http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c
> 
> Attached is the test-case I came up with before I found the commit that fixes 
> it, and then the upstream bug.
> 
> This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate 
> UNIQUE symbols (at least for this case), AND the old dynamic linker seems to 
> not have this bug.
> 
> The actual code part of that upstream patch applies cleanly to wheezy's libc 
> and fixes the problem. ISTM that it'd be a good idea to backport, given that 
> wheezy isn't going to upgrade to a new upstream release.
> 
>  test.h 
> template
> class Foo {
> public:
> static const char foo[];
> };
> 
>  test1.cpp 
> #include "test.h"
> 
> // Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to
> // create a WEAK symbol instead.
> template
> const char Foo::foo[] = "string";
> template class Foo;
> 
> const char * getone() {
> // Creates a R_X86_64_GLOB_DAT relocation
> return Foo::foo;
> }
> 
>  test2.cpp 
> #include "test.h"
> #include 
> #include 
> 
> int main() {
> // Reference creates a R_X86_64_COPY relocation
> if (strcmp(Foo::foo, "string")) {
>   printf("'%s'\n", Foo::foo);
> return 1;
> }
> return 0;
> }
> 
> 
>  test.sh 
> g++ -fPIC -shared -o test.so test1.cpp
> g++ -o test test2.cpp ./test.so
> ./test

This bug has been fixed in upstream glibc 2.14. I am therefore closing
the bug.

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

Bug#742965: marked as done (libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:47:05 +0100
with message-id <20151217184705.ga9...@aurel32.net>
and subject line Re: Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd 
>=9.0
has caused the Debian Bug report #742965,
regarding libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0
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.)


-- 
742965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742965
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc0.1
Version: 2.18-4
Severity: normal


If a process has a handler for SIGCHLD, openpty() fails on kfreebsd with 9.x
kernels.  It worked ok on 8.x, and works on "real" (ie, no glibc) FreeBSD.

A reduced test case attached; when commenting out the sigaction line,
openpty() starts working again.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 9.2-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc0.1 depends on:
ii  libgcc1  1:4.8.2-16

libc0.1 recommends no packages.

Versions of packages libc0.1 suggests:
ii  debconf [debconf-2.0]  1.5.52
pn  glibc-doc  
ii  locales2.18-4

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-services:
  glibc/restart-failed:
  libraries/restart-without-asking: false
// Link with -lutil
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void sigchild(int dummy)
{
while (waitpid(-1,0,WNOHANG)>0);
}

int main()
{
int master, slave;

struct sigaction act;
sigemptyset(_mask);
act.sa_flags=SA_RESTART;
act.sa_handler=sigchild;
sigaction(SIGCHLD,,0);

if (openpty(, , 0, 0, 0))
{
printf("Failed: %s\n", strerror(errno));
return 1;
}
printf("Ok!\n");
return 0;
}
--- End Message ---
--- Begin Message ---
On 2014-04-04 09:35, Petr Salinger wrote:
> >I wonder how to fix it.  Merely documenting the restriction isn't really
> >anoption, as no widespread system has it.  Saving the signal handler,
> >disabling it then restoring would work but introduces a slight race
> >condition (a child process can exit while we're in grantpt()).
> 
> In fact, it is documented:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/grantpt.html
> 
>   The behavior of the grantpt() function is unspecified if the application
>   has installed a signal handler to catch SIGCHLD signals.

Indeed this is a possible behaviour of this function. The same will
happen on a GNU/Linux system if /dev/pts is mounted with the wrong
permissions.

I am therefore closing this bug.

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

Bug#510819: marked as done (libc6: printf incorrectly shows argument with value 0 on conversion %#04hhx and related)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:47:58 +0100
with message-id <20151217184758.ga20...@aurel32.net>
and subject line Re: Bug#510819: libc6: printf incorrectly shows argument with 
value 0 on conversion %#04hhx and related
has caused the Debian Bug report #510819,
regarding libc6: printf incorrectly shows argument with value 0 on conversion 
%#04hhx and related
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.)


-- 
510819: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510819
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.7-16
Severity: normal


Conversion %#04hhx in printf means "convert the argument to a uint8_t (hh) and 
show it as an hexadecimal number (x) with leading zeros if necessary (0) and a 
leading 0x prefix (#) in a field of 
total lenght four (4), that is, two places for 0x and two for the argument 
value".

If the argument is 0 the expected behaviour is to show 0x00 but it shows 

With other arguments it works ok.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1   1:4.3.2-1  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  glibc-doc 2.7-16 GNU C Library: Documentation
ii  libc6-i6862.7-16 GNU C Library: Shared libraries [i
ii  locales   2.7-16 GNU C Library: National Language (

-- debconf information:
  glibc/upgrade: true
  glibc/restart-failed:
  glibc/restart-services:


--- End Message ---
--- Begin Message ---
On 2009-01-05 04:50, Noel David Torres Taño wrote:
> Package: libc6
> Version: 2.7-16
> Severity: normal
> 
> 
> Conversion %#04hhx in printf means "convert the argument to a uint8_t (hh) 
> and show it as an hexadecimal number (x) with leading zeros if necessary (0) 
> and a leading 0x prefix (#) in a field of 
> total lenght four (4), that is, two places for 0x and two for the argument 
> value".
> 
> If the argument is 0 the expected behaviour is to show 0x00 but it shows 
> 
> With other arguments it works ok.

printf has the correct behaviour as the value 0 is a special case.
Quoting POSIX [1]:

| #
| Specifies that the value is to be converted to an alternative form.
| For o conversion, it increases the precision (if necessary) to force
| the first digit of the result to be zero. For x or X conversion
| specifiers, a non-zero result shall have 0x (or 0X) prefixed to it.
| For a, A, e, E, f, F, g , and G conversion specifiers, the result
| shall always contain a radix character, even if no digits follow the
| radix character. Without this flag, a radix character appears in the
| result of these conversions only if a digit follows it. For g and G
| conversion specifiers, trailing zeros shall not be removed from the
| result as they normally are. For other conversion specifiers, the
| behavior is undefined.
| 0.

As you can see the '0x' prefix is added only for a non-zero value.
That is why '' is the correct output here.

I am therefore closing the bug.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html 

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

Bug#699321: marked as done (libc6: statvfs() calling stat() unnecessarily (2.6.36))

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:47:29 +0100
with message-id <20151217184729.ga16...@aurel32.net>
and subject line Re: Bug#699321: libc6: statvfs() calling stat() unnecessarily 
(2.6.36)
has caused the Debian Bug report #699321,
regarding libc6: statvfs() calling stat() unnecessarily (2.6.36)
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.)


-- 
699321: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699321
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.13-37
Severity: normal

Running statvfs() my machine still results in stat() being called, and from
what I can tell, it's being called _before_ __statvfs_getflags() is called.   I
have not yet determined where stat() is called, but strace on my C program (see
below) confirms stat() is called after statfs(), but before the fprintf() I
added in sysdeps/unix/sysv/linux/internal_statvfs.c:

  /*
   * I added the following fprintf() in my local build and confirmed
   * ST_VALID (0x20) is set here by my 3.7.5 kernel:
   */
   fprintf(stderr, "f_flags: 0x%lx\n", fsbuf->f_flags);

#ifndef __ASSUME_STATFS_F_FLAGS
  if ((fsbuf->f_flags & ST_VALID) == 0)
/* Determining the flags is tricky.  We have to read /proc/mounts or
   the /etc/mtab file and search for the entry which matches the given
   file.  The way we can test for matching filesystem is using the
   device number.  */
buf->f_flag = __statvfs_getflags (name, fsbuf->f_type, st);
  else
#endif
buf->f_flag = fsbuf->f_flags ^ ST_VALID;

Here is my trivial C program I straced to confirm stat() being called
after statfs():

/* gcc -o statvfs -Wall statvfs.c */
#include 
int main(void)
{
struct statvfs svf;
statvfs("/mnt", );
return 0;
}


I do not expect stat() to be called with statvfs(), since ST_VALID helps
avoid this expensive check.  stat() also has detrimental effects on
unreachable/slow network mounts.

-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.7.5 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.13-37
ii  libgcc1   1:4.7.2-5

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.49
ii  glibc-doc  2.13-37
ii  locales2.13-37

-- debconf information excluded
--- End Message ---
--- Begin Message ---
Version: 2.21-1

On 2013-01-30 08:33, Eric Wong wrote:
> Package: libc6
> Version: 2.13-37
> Severity: normal
> 
> Running statvfs() my machine still results in stat() being called, and from
> what I can tell, it's being called _before_ __statvfs_getflags() is called.   
> I
> have not yet determined where stat() is called, but strace on my C program 
> (see
> below) confirms stat() is called after statfs(), but before the fprintf() I
> added in sysdeps/unix/sysv/linux/internal_statvfs.c:
> 
>   /*
>* I added the following fprintf() in my local build and confirmed
>* ST_VALID (0x20) is set here by my 3.7.5 kernel:
>*/
>fprintf(stderr, "f_flags: 0x%lx\n", fsbuf->f_flags);
> 
> #ifndef __ASSUME_STATFS_F_FLAGS
>   if ((fsbuf->f_flags & ST_VALID) == 0)
> /* Determining the flags is tricky.  We have to read /proc/mounts or
>the /etc/mtab file and search for the entry which matches the given
>file.  The way we can test for matching filesystem is using the
>device number.  */
> buf->f_flag = __statvfs_getflags (name, fsbuf->f_type, st);
>   else
> #endif
> buf->f_flag = fsbuf->f_flags ^ ST_VALID;
> 
> Here is my trivial C program I straced to confirm stat() being called
> after statfs():
> 
> /* gcc -o statvfs -Wall statvfs.c */
> #include 
> int main(void)
> {
>   struct statvfs svf;
>   statvfs("/mnt", );
>   return 0;
> }
> 
> 
> I do not expect stat() to be called with statvfs(), since ST_VALID helps
> avoid this expensive check.  stat() also has detrimental effects on
> unreachable/slow network mounts.

This bug has been fixed in glibc version 2.20. I am therefore closing
the bug.

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

Bug#694964: marked as done (libc6:amd64: binary debian target fails - /usr/include/locale.h cannot be removed)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:47:39 +0100
with message-id <20151217184739.ga16...@aurel32.net>
and subject line Re: Bug#694964: libc6:amd64: binary debian target fails - 
/usr/include/locale.h cannot be removed
has caused the Debian Bug report #694964,
regarding libc6:amd64: binary debian target fails - /usr/include/locale.h 
cannot be removed
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.)


-- 
694964: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694964
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.16-0experimental1
Severity: normal

Dear Maintainer,
A local dpkg-buildpackage of the 2.16 package leads to this error:
make[3]: Entering directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale'
/usr/bin/install -c -m 644 locale.h /usr/include/locale.h
/usr/bin/install: cannot remove '/usr/include/locale.h': Permission denied
make[3]: *** [/usr/include/locale.h] Error 1
make[3]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale'
make[2]: *** [locale/subdir_install] Error 2
make[2]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16'
make[1]: *** [install] Erreur 2
make[1] : on quitte le répertoire « 
/home/prahal/checkout/glibc6/eglibc-2.16/build-tree/amd64-libc »
make: *** [/home/prahal/checkout/glibc6/eglibc-2.16/stamp-dir/install_libc] 
Erreur 2
dpkg-buildpackage: erreur: fakeroot debian/rules binary a produit une erreur de 
sortie de type 2

It turns out the locale/Makefile is missing:
include ../Makeconfig

Attached patch fixes that issue.
Regards,
Alban


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.7.0-rc4test0-00020-g0e4a43e (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6:amd64 depends on:
ii  debconf [debconf-2.0]  1.5.46
ii  libgcc11:4.7.2-12

libc6:amd64 recommends no packages.

Versions of packages libc6:amd64 suggests:
pn  glibc-doc  
pn  locales

-- debconf information:
* glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: spamassassin ssh saslauthd samba openbsd-inetd mysql 
exim4 cups cron atd apache2
* libraries/restart-without-asking: false
--- locale/Makefile.orig	2012-12-02 19:28:18.071115539 +0100
+++ locale/Makefile	2012-12-02 10:45:54.588268235 +0100
@@ -23,6 +23,8 @@
 
 subdir	:= locale
 
+include ../Makeconfig
+
 headers		= locale.h bits/locale.h langinfo.h xlocale.h
 # catnames is needed by OPTION_EGLIBC_LOCALE_CODE and by the 'intl' code.
 # If we put the latter in an option group, too, we can omit catnames
--- End Message ---
--- Begin Message ---
Version: 2.21

On 2012-12-02 19:32, Alban Browaeys wrote:
> Package: libc6
> Version: 2.16-0experimental1
> Severity: normal
> 
> Dear Maintainer,
> A local dpkg-buildpackage of the 2.16 package leads to this error:
> make[3]: Entering directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale'
> /usr/bin/install -c -m 644 locale.h /usr/include/locale.h
> /usr/bin/install: cannot remove '/usr/include/locale.h': Permission denied
> make[3]: *** [/usr/include/locale.h] Error 1
> make[3]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale'
> make[2]: *** [locale/subdir_install] Error 2
> make[2]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16'
> make[1]: *** [install] Erreur 2
> make[1] : on quitte le répertoire « 
> /home/prahal/checkout/glibc6/eglibc-2.16/build-tree/amd64-libc »
> make: *** [/home/prahal/checkout/glibc6/eglibc-2.16/stamp-dir/install_libc] 
> Erreur 2
> dpkg-buildpackage: erreur: fakeroot debian/rules binary a produit une erreur 
> de sortie de type 2
> 
> It turns out the locale/Makefile is missing:
> include ../Makeconfig

This has been fixed upstream in version 2.20. I am therefore closing the
bug.

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

Bug#687545: marked as done (libc6: Incorrect decimal printf output of tiny long double values on PowerPC)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:47:53 +0100
with message-id <20151217184753.ga17...@aurel32.net>
and subject line Re: Bug#687545: libc6: Incorrect decimal printf output of tiny 
long double values on PowerPC
has caused the Debian Bug report #687545,
regarding libc6: Incorrect decimal printf output of tiny long double values on 
PowerPC
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.)


-- 
687545: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687545
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.13-35
Severity: normal

The minimum positive long double value is not output correctly by
printf with the decimal conversion specifiers (e, f, g) on PowerPC
(where long double is implemented with a double-double arithmetic).
See the testcase below. There may be the same problem with other
tiny values.

#include 
#include 

int main (void)
{
  double d;
  long double e;

  d = nextafter (0.0, 1.0);
  printf ("d = %e = %f = %g = %a\n", d, d, d, d);
  e = d;
  printf ("e = %Le = %Lf = %Lg = %La\n", e, e, e, e);
  d = e;
  printf ("d = %e = %f = %g = %a\n", d, d, d, d);
  printf ("d = %.330f\n", d);
  printf ("e = %.330Lf\n", e);
  return 0;
}

I get:

d = 4.940656e-324 = 0.00 = 4.94066e-324 = 0x0.1p-1022
e = 4.450148e-308 = 0.00 = 4.45015e-308 = 0x0.1p-1022
d = 4.940656e-324 = 0.00 = 4.94066e-324 = 0x0.1p-1022
d = 
0.0004940656
e = 
0.00044501477170144027661805

Note that 4.450148e-308 / 4.940656e-324 is about 2^53, where 53 is the
precision of a double. I suspect that the glibc code doesn't handle
small values such that one of the double's in the representation is 0.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.26-1-powerpc
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libc-bin  2.13-35
ii  libgcc1   1:4.7.1-7

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.46
pn  glibc-doc  
ii  locales2.13-35

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
* glibc/restart-failed:
* glibc/restart-services: spamassassin openbsd-inetd exim4 cron atd
* libraries/restart-without-asking: true

-- debsums errors found:
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 5250 package 
'inn2':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 8462 package 
'libgdbmg1':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 11058 
package 'libnewt0':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 13393 
package 'docbook-mathml':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 22784 
package 'libpcd':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 31190 
package 'inn2-inews':
 missing architecture
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 33324 
package 'libisc4':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 5250 
package 'inn2':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 8462 
package 'libgdbmg1':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 11058 
package 'libnewt0':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 13393 
package 'docbook-mathml':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 22784 
package 'libpcd':
 missing architecture
dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 31190 
package 'inn2-inews':
 missing 

Bug#800523: nscd netgroup cache occasionally not updated, nscd -i netgroup hangs

[Aurelien Jarno]

On 2015-09-30 12:29, Mike Gabriel wrote:
> Package: nscd
> Severity: important
> Version: 2.19-18+deb8u1
> Tags: patch
> Usertags: debian-edu
> User: debian-...@lists.debian.org
> X-Debbugs-Cc: debian-...@lists.debian.org
> 
> Dear maintainers,
> 
> the Debian Edu main server in jessie heavily relies on working netgroups
> code in glibc / nscd for allowing NFS access from hosts on the network.
> 
> The setup is:
> 
> /etc/nsswitch.conf:
> 
> """
> netgroup:files ldap
> """
> 
> The LDAP nss provider is libnss-ldapd via nslcd. NIS netgroups are only
> configured in LDAP, no local /etc/netgroup file is present. NIS netgroup
> caching in nscd.conf is enabled.
> 
> In some cases (unclear what triggers it) the following is observed:
> 
>   o add a new host to the NIS netgroup "workstation-hosts"
>   o wait for a while (i.e., we even tried days...)
>   o "getent netgroup workstation-hosts" does not list the new host as
> netgroup member
>   o trying
> 
> $ innetgr -h  workstation-hosts || echo FALSE
> 
> echoes "FALSE" on the terminal.
>   o sometimes there even is a difference between what getent netgroup
>  gives
> as a result and what innetgr returns as a result (a host tripled is
> listed in
> getent netgroup , but when querying for that host via innetgr).
>   o Attempting cache clean-up (nscd -i netgroup) fails, the command hangs and
> does not return to a command prompt
> 
> The behaviour occurs very often on Debian Edu jessie main server
> installations (and also on a vanilla Debian jessie server using a similar
> NIS netgroup / NFS setup). It does not occur always. Note, that I always
> have host netgroups that are full with host triplets (long strings!!!
> several lines on a normal 80x25 terminal).
> 
> From looking at debdiffs between glibc in unstable and jessie
> (2.19-18+deb8u1), the issue is probably also present in Debian unstable, but
> may have been fixed in glibc 2.21 (currently in experimental).

Given I don't have a test setup to reproduce the issue, and now that
2.21 is in testing, it would be nice if you can give a try with this
version to see if it improves things. That will at least tell us if we
have to look at patches to backports or at writing patches to fix the
issues.

> The debdiff between glibc in wheezy (2.13-38+deb7u8) and jessie
> (2.19-18+deb8u1) alludes that the changes around the netgroup caching code
> (there have been quite some nscd caching changes between those two version)
> may have caused this issue between glibc 2.13 and 2.19.
> 
> The above issue is definitely not present in glibc from Debian squeeze (we
> have many servers running that versions) and probably neither present in
> Debian wheezy (only one test server deployed), but really really bites us
> (the Debian Edu team) on Debian Edu jessie.
> 
> The workaround at the moment is: disable nscd netgroup caching in nscd.conf.
> This is by far suboptimal.
> 
> Upstream observed issues with (LDAP and) netgroup caching, as well, recently:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=16878
>   Patch: 
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=c3ec475c5dd16499aa040908e11d382c3ded9692;hp=aa2f176d6f75b86b91e544c2e494066ac8f88cbd

This has already been backported to jessie.

>   https://sourceware.org/bugzilla/show_bug.cgi?id=16760
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=dd3022d75e6fb8957843d6d84257a5d8457822d5

This one is actually from BZ 16759

> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ea7d8b95e2fcb81f68b04ed7787a3dbda023991a

It looks indeed a good idea to backport them.

>   https://sourceware.o rg/bugzilla/show_bug.cgi?id=16695
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c44496df2f090a56d3bf75df930592dac6bba46f

This has already been backported to jessie.
 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=16758
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fbd6b5a4052316f7eb03c4617eebfaafc59dcc06
> 
> Especially BZ #16878 looks like being a good candidate to fix this. My
> recommendation is considering backporting all of the above patches as by
> reading those bug reports, glibc 2.19 seems quite buggy regarding netgroup
> caching in nscd.

I will try to backport them for the next point release.

Aurelien

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


signature.asc
Description: Digital signature

Bug#661760: typo in patch for de_AT translation of February

[Aurelien Jarno]

Version: eglibc/2.13-38+deb7u2

On 2013-01-18 15:45, Thomas Schwinge wrote:
> Hi!
> 
> Thanks for the report and patch!
> 
> On Fri, 18 Jan 2013 14:58:39 +0100, Gerfried Fuchs  wrote:
> > --- a/localedata/locales/de_AT
> > +++ b/localedata/locales/de_AT
> > @@ -102,7 +102,7 @@
> > "";"";/
> > "";""
> >  mon "";/
> > -   "";/
> > +   "";/
> > "";/
> > "";/
> > "";/
> 
> Please see upstream glibc commit b44d43a01620a29c0ee7b25fe994adb22fa511d5
> and BZ #13758; this has been fixed already:
> 
> localedata/
> 2012-10-19  Florian Pritz  
> 
>   [BZ #13758]
>   * locales/de_AT (LC_TIME): Change month name from "FebruAr" to
>   "Februar".
> 
> 
> diff --git localedata/locales/de_AT localedata/locales/de_AT
> index e566eed..c36913b 100644
> --- localedata/locales/de_AT
> +++ localedata/locales/de_AT
> @@ -100,7 +100,7 @@ abmon   "";"";/
>   "";"";/
>   "";""
>  mon "";/
> - "";/
> + "";/
>   "";/
>   "";/
>   "";/
> 

This has been fixed in version 2.13-38+deb7u2. I am therefore closing
the bug.

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


signature.asc
Description: PGP signature

Bug#572746: marked as done (libm: sinf/cosf performance is awful on amd64)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:35:14 +0100
with message-id <20151217183514.ga22...@aurel32.net>
and subject line Re: Bug#572746: libm: sinf/cosf performance is awful on amd64
has caused the Debian Bug report #572746,
regarding libm: sinf/cosf performance is awful on amd64
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.)


-- 
572746: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572746
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.10.2-6
Severity: normal

Hi,

After many tests and research I've come to the conclusion that the float 
variants 
of
sin/cos (and maybe others) are anormaly slow Debian amd64.
The performance loss is really impressive (around 8 to 9 times slower).
I've attached the prog used to make my experiments and used it in the following 
cases.

+ Lenny-amd64: sinf/cosf is really slow
+ Lenny-i386: float performance is ok (faster than the cos/sin using double)
+ Sid-amd64: sinf/cosf slow
+ Lenny-amd64 using lenny-i386 binary and 32bits libs: float performance is OK.

+ OpenSuse 64 bits (10.3 and 11.1): using the binary compiled on lenny-amd64, 
the tests run fine !
=> The problem is not compiler related.

There seems to be a problem with the way libm is compiled for the amd64 
architecture on Debian.
This is why the OpenSuse test was run: the problem is somewhere in the compile 
chain or debian specific patches.

We're extensively using these for calculations and this is a real problem. 
Using 
cos/sin as
a temporary workaround would do the trick but this is still slower than the 
sinf/cosf 
implementations that works so well on 32 bits computers...

Thank you

Jerome

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

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libc-bin  2.10.2-6   Embedded GNU C Library: Binaries
ii  libgcc1   1:4.4.3-3  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.28 Debian configuration management sy
pn  glibc-doc  (no description available)
ii  locales   2.10.2-6   Embedded GNU C Library: National L

-- debconf information excluded
CC=gcc
CFLAGS=-DNDEBUG -O3 -D_ISOC99_SOURCE -Wall -Wextra
LDFLAGS=-lm

all: test_trig

clean:
	rm test_trig

test_trig: test_trig.c
#include 
#include 
#include 




int main(void) 
{
  const int nbElement_i = 1000;
  int i=0;
  float f1=0.0f, f2=0.0f, f3=0.0f;
  
  struct timeval tv1, tv2; 

  printf("Testing %d sinf and cosf... ", nbElement_i);
  fflush(stdout);
  
  gettimeofday(, NULL);

  for(i=0; i Package: libc6
> Version: 2.10.2-6
> Severity: normal
> 
> Hi,
> 
> After many tests and research I've come to the conclusion that the float 
> variants 
> of
> sin/cos (and maybe others) are anormaly slow Debian amd64.
> The performance loss is really impressive (around 8 to 9 times slower).
> I've attached the prog used to make my experiments and used it in the 
> following 
> cases.
> 
> + Lenny-amd64: sinf/cosf is really slow
> + Lenny-i386: float performance is ok (faster than the cos/sin using double)
> + Sid-amd64: sinf/cosf slow
> + Lenny-amd64 using lenny-i386 binary and 32bits libs: float performance is 
> OK.
> 
> + OpenSuse 64 bits (10.3 and 11.1): using the binary compiled on lenny-amd64, 
> the tests run 

Bug#665408: marked as done (tzdata: San Luis and Cairo wrongly show UTC)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:35:42 +0100
with message-id <20151217183542.ga17...@aurel32.net>
and subject line Re: Bug#665408: tzdata: San Luis and Cairo wrongly show UTC
has caused the Debian Bug report #665408,
regarding tzdata: San Luis and Cairo wrongly show UTC
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.)


-- 
665408: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665408
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tzdata
Version: 2011n-0lenny1
Severity: normal

On a server with tzdata 2009l-0lenny1:

dsatow@mercury11:~$ LANG= TZ=America/Argentina/San_Luis date
Thu Mar 22 21:41:43 WART 2012
dsatow@mercury11:~$ LANG= TZ=Africa/Cairo date
Fri Mar 23 03:41:55 EET 2012
dsatow@mercury11:~$

On a server with 2011n-0llenny1:

martind@whitewater:~$ LANG= TZ=America/Argentina/San_Luis date
Fri Mar 23 18:30:10 UTC 2012
martind@whitewater:~$ LANG= TZ=Africa/Cairo date
Fri Mar 23 18:30:11 UTC 2012
martind@whitewater:~$ 

"WART" and "EET" change to "UTC".  I believe this to be incorrect.

This does not happen with the Squeeze libc and the same Lenny tzdata.
I suspect that this was the fix:

http://cygwin.com/ml/libc-alpha/2009-06/msg00102.html

This demonstrates that the problem applies to many zones:

for zone in `find /usr/share/zoneinfo/ -type f`
do
echo $zone; zdump -v $zone | tail -3 | head -1
done | grep UTC' isdst'

Most such zones will only be affected tens of years in the future.
The only zones, as of tzdata 2011k-0lenny1, that are currently affected are
San Luis, Cairo and Egypt.

All the affected zonefiles end with \x0A\x0A.
But not all the zonefiles ending in such a way are affected.
This casts doubt on my suspected fix.
All such exceptions are under the right/ tree:

martind@whitewater:~$ TZ=/usr/share/zoneinfo/right/America/Argentina/San_Luis 
date
Fri Mar 23 17:30:06 WARST 2012
martind@whitewater:~$ hexdump -C 
/usr/share/zoneinfo/right/America/Argentina/San_Luis | tail -2
0640  00 00 00 0a 0a|.|
0645
martind@whitewater:~$ 

I suspect, though, that the reason that appears to work is another bug, fixed 
here:

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6355c99740c91ed5a7fa14e378f74950e09f5f48

I think that would prevent the empty tzspec from being read, except in the case
where num_leaps is zero, explaining why that only afflicts the right/ tree.

Returning to the original bug, this came to afflict San Luis in 2010j-0lenny1.
2010f-0lenny1 didn't exhibit the problem.
It was a tzdata update, then, that led me to trip over the problem,
which is part of the reason for my reporting a libc6 bug against tzdata.
I don't expect, or even hope, for this to be fixed in Lenny.
I would just like the report available to search engines so that the next person
doesn't spend so long on it.
I'd also like to raise awareness of the (small) risk of updating tzdata without
updating libc6's tzfile code.

-- System Information:
Debian Release: 5.0.10
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
  tzdata/Zones/Australia:
  tzdata/Zones/Asia:
  tzdata/Zones/SystemV:
  tzdata/Zones/Pacific:
  tzdata/Zones/Atlantic:
  tzdata/Zones/US:
  tzdata/Zones/Etc:
  tzdata/Zones/Arctic:
  tzdata/Zones/Antarctica:
* tzdata/Zones/Europe: Paris
  tzdata/Zones/Africa:
* tzdata/Zones/America: Los_Angeles
* tzdata/Areas: America
  tzdata/Zones/Indian:


--- End Message ---
--- Begin Message ---
Version: 2.10.1-1

On 2012-10-19 16:59, Aurelien Jarno wrote:
> reassign 665408 libc6
> fixed 665408 2.10.1-1
> thanks
> 
> On Fri, Mar 23, 2012 at 02:40:36PM -0700, Martin Dorey wrote:
> > Package: tzdata
> > Version: 2011n-0lenny1
> > Severity: normal
> > 
> > On a server with tzdata 2009l-0lenny1:
> > 
> > dsatow@mercury11:~$ LANG= TZ=America/Argentina/San_Luis date
> > Thu Mar 22 21:41:43 WART 2012
> > dsatow@mercury11:~$ LANG= TZ=Africa/Cairo date
> > Fri Mar 23 03:41:55 EET 2012
> > dsatow@mercury11:~$
> > 
> > On a server with 2011n-0llenny1:
> > 
> > martind@whitewater:~$ LANG= TZ=America/Argentina/San_Luis date
> > Fri Mar 23 18:30:10 UTC 2012
> > martind@whitewater:~$ LANG= TZ=Africa/Cairo date
> > Fri Mar 23 

Bug#800682: marked as done (libc6: nscd reports bogus result for ipv6-only requests)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:35:24 +0100
with message-id <20151217183524.ga8...@aurel32.net>
and subject line Re: Bug#800682: libc6: nscd reports bogus result for ipv6-only 
requests
has caused the Debian Bug report #800682,
regarding libc6: nscd reports bogus result for ipv6-only requests
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.)


-- 
800682: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800682
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.19-20
Severity: normal
Tags: upstream fixed-upstream patch

Hello,

without nscd:
$ ping6 -n kamino
PING kamino(2001:db8:210::20) 56 data bytes
64 bytes from 2001:db8:210::20: icmp_seq=1 ttl=64 time=0.303 ms

with nscd:
$ ping6 -n kamino
PING kamino(a00:d214:2001:db8:210::) 56 data bytes

(0x0a.0x00.0xd2.0x14 happens to be the IPv4 of kamino)

This is due to a missing commit backport for Bug#798515.  I have pushed
the missing commit in the upstream 2.19 branch (8dc9751 cherry-picked as
b0f0937).  We can either upload a 2.19-23 to get it fixed, or just wait
for 2.21 (which already has the fix) to get uploaded.

Samuel

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.2 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
...
 et Ctrl alt F2 pour aller sous console
 mais c koi pour passer d'un bureau a un autre !
 au fait c koi le raccourci pour passer d'un bureau a un autre 'question 
stupide"
 ça dépend du window manager et de ta conf
 ce qui fonctionne toujours c'est CTRL-ALT-BCKSP
-:- SignOff rv_: #linuxfr (Read error: EOF from client)
-:- rv_ [~rv@217.11.166.169] has joined #linuxfr
 Firebird: MEURT...
commit 8dc9751764eb1bedf06d19695524b31a16773413
Author: Andreas Schwab 
Date:   Wed May 7 11:47:20 2014 +0200

Fix parsing of getai result from nscd for IPv6-only request

diff --git a/ChangeLog b/ChangeLog
index 6c50016..cb09dd7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,7 +1,13 @@
+2014-05-07  Andreas Schwab  
+
+   * sysdeps/posix/getaddrinfo.c (gaih_inet): Advance address pointer
+   when skipping over non-matching result from nscd.
+
 2014-05-07  Ondřej Bílka  
 
[BZ #16876]
* nptl/sockperf.c (client): Check socket return value.
+
[BZ #16877]
* nscd/selinux.c (nscd_request_avc_has_perm): Check if there is
nscd security class.
diff --git a/sysdeps/posix/getaddrinfo.c b/sysdeps/posix/getaddrinfo.c
index 3385bed..6258330 100644
--- a/sysdeps/posix/getaddrinfo.c
+++ b/sysdeps/posix/getaddrinfo.c
@@ -710,16 +710,20 @@ gaih_inet (const char *name, const struct gaih_service 
*service,
  struct gaih_addrtuple *addrfree = addrmem;
  for (int i = 0; i < air->naddrs; ++i)
{
+ socklen_t size = (air->family[i] == AF_INET
+   ? INADDRSZ : IN6ADDRSZ);
+
  if (!((air->family[i] == AF_INET
 && req->ai_family == AF_INET6
 && (req->ai_flags & AI_V4MAPPED) != 0)
|| req->ai_family == AF_UNSPEC
|| air->family[i] == req->ai_family))
-   /* Skip over non-matching result.  */
-   continue;
+   {
+ /* Skip over non-matching result.  */
+ addrs += size;
+ continue;
+   }
 
- socklen_t size = (air->family[i] == AF_INET
-   ? INADDRSZ : IN6ADDRSZ);
  if (*pat == NULL)
{
  *pat = addrfree++;
--- End Message ---
--- Begin Message ---
Version: 2.21-1

On 2015-10-02 13:57, Samuel Thibault wrote:
> Package: libc6
> Version: 2.19-20
> Severity: normal
> Tags: upstream fixed-upstream patch
> 
> Hello,
> 
> without nscd:
> $ ping6 -n kamino
> PING kamino(2001:db8:210::20) 56 data bytes
> 64 bytes from 2001:db8:210::20: icmp_seq=1 ttl=64 time=0.303 ms
> 
> with nscd:
> $ ping6 -n kamino
> PING kamino(a00:d214:2001:db8:210::) 56 data 

Bug#661760: marked as done (locales: The month 'February' must be 'Februar' in the locale de_AT, not 'Feber'.)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:36:16 +0100
with message-id <20151217183616.ga17...@aurel32.net>
and subject line Re: Bug#661760: typo in patch for de_AT translation of February
has caused the Debian Bug report #661760,
regarding locales: The month 'February' must be 'Februar' in the locale de_AT, 
not 'Feber'.
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.)


-- 
661760: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661760
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: locales
Version: 2.11.3-3
Severity: normal



While the exotic form "Feber" does exist in parts of Austria and southern 
Germany, it is by no means the standard. Some old folks still know it exists, 
hardly anybody in Austria actually uses it. It must be "Februar".

This causes me pain, because date-formatting is heavily used in our publishing 
company. PostgreSQL relies on the system locale and I have to special case the 
month every time. I fix /usr/share/i18n/locales/de_AT locally and run 
locale-gen. But it won't stick. The file is overwritten with every locale 
update - and I do want those updates.

So, could this be fixed for good? Would be among the simplest bugfix ever:

s/"";/"";/

Regards
Erwin


-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages locales depends on:
ii  debconf [debconf-2.0] 1.5.36.1   Debian configuration management sy
ii  libc6 [glibc-2.11-1]  2.11.3-3   Embedded GNU C Library: Shared lib

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/default_environment_locale: de_AT.UTF-8
* locales/locales_to_be_generated: de_AT.UTF-8 UTF-8, en_US.UTF-8 UTF-8


--- End Message ---
--- Begin Message ---
Version: eglibc/2.13-38+deb7u2

On 2013-01-18 15:45, Thomas Schwinge wrote:
> Hi!
> 
> Thanks for the report and patch!
> 
> On Fri, 18 Jan 2013 14:58:39 +0100, Gerfried Fuchs  wrote:
> > --- a/localedata/locales/de_AT
> > +++ b/localedata/locales/de_AT
> > @@ -102,7 +102,7 @@
> > "";"";/
> > "";""
> >  mon "";/
> > -   "";/
> > +   "";/
> > "";/
> > "";/
> > "";/
> 
> Please see upstream glibc commit b44d43a01620a29c0ee7b25fe994adb22fa511d5
> and BZ #13758; this has been fixed already:
> 
> localedata/
> 2012-10-19  Florian Pritz  
> 
>   [BZ #13758]
>   * locales/de_AT (LC_TIME): Change month name from "FebruAr" to
>   "Februar".
> 
> 
> diff --git localedata/locales/de_AT localedata/locales/de_AT
> index e566eed..c36913b 100644
> --- localedata/locales/de_AT
> +++ localedata/locales/de_AT
> @@ -100,7 +100,7 @@ abmon   "";"";/
>   "";"";/
>   "";""
>  mon "";/
> - "";/
> + "";/
>   "";/
>   "";/
>   "";/
> 

This has been fixed in version 2.13-38+deb7u2. I am therefore closing
the bug.

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


signature.asc
Description: PGP signature
--- End Message ---

Processed: fixed 661760 in eglibc/2.17-1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 661760 eglibc/2.17-1
Bug #661760 {Done: Aurelien Jarno } [locales] locales: 
The month 'February' must be 'Februar' in the locale de_AT, not 'Feber'.
Marked as fixed in versions eglibc/2.17-1.
> thanks
Stopping processing here.

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

Bug#710521: marked as done ("ldd -r /usr/bin/go" segfaults)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:48:20 +0100
with message-id <20151217184820.ga15...@aurel32.net>
and subject line Bug#710521: "ldd -r /usr/bin/go" segfaults
has caused the Debian Bug report #710521,
regarding "ldd -r /usr/bin/go" segfaults
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.)


-- 
710521: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710521
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: libc6
Version: 2.17-3

Running "ldd -r" on /usr/bin/go (shipped by golang-go 2:1.1-1) causes a 
segfault:


$ ldd -r /usr/bin/go
linux-gate.so.1 (0xf7757000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7738000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000)
/lib/ld-linux.so.2 (0xf7758000)
/usr/bin/ldd: line 116:  8528 Segmentation fault  LD_TRACE_LOADED_OBJECTS=1 
LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libgcc1  1:4.8.0-9

Versions of packages libc6 recommends:
pn  libc6-i686  

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.50
pn  glibc-doc  
pn  locales

--
Jakub Wilk
--- End Message ---
--- Begin Message ---
Version: eglibc/2.19-1

On 2013-05-31 17:35, Jakub Wilk wrote:
> Package: libc6
> Version: 2.17-3
> 
> Running "ldd -r" on /usr/bin/go (shipped by golang-go 2:1.1-1) causes a
> segfault:
> 
> $ ldd -r /usr/bin/go
>   linux-gate.so.1 (0xf7757000)
>   libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7738000)
>   libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000)
>   /lib/ld-linux.so.2 (0xf7758000)
> /usr/bin/ldd: line 116:  8528 Segmentation fault  
> LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes 
> LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"

I can reproduce the problem with eglibc 2.18-4, but not with 2.19-1 and
later versions. I therefore believe the problem has been fixed and I am
closing the bug with this mail.

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

Bug#760902: marked as done (libc6: ld-linux-x86-64.so.2 segfaults with LD_BIND_NOW=yes on some binaries generated by golang)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 19:48:20 +0100
with message-id <20151217184820.ga15...@aurel32.net>
and subject line Bug#710521: "ldd -r /usr/bin/go" segfaults
has caused the Debian Bug report #710521,
regarding libc6: ld-linux-x86-64.so.2 segfaults with LD_BIND_NOW=yes on some 
binaries generated by golang
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.)


-- 
710521: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710521
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: aptly
Version: 0.5-4
Severity: normal

Dear Maintainer,
 I was curious about aptly and hence installed it. While installing it
came across the following :-

$ sudo aptitude install aptly
The following NEW packages will be installed:
  aptly
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,703 kB of archives. After unpacking 9,068 kB will be used.
Get: 1 http://debian.ec.as6453.net/debian/ unstable/main aptly amd64
0.5-4 [1,703 kB]
Fetched 1,703 kB in 48s (35.1 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
D01: ensure_diversions: new, (re)loading
D01: ensure_statoverrides: new, (re)loading
Selecting previously unselected package aptly.
(Reading database ... 561585 files and directories currently installed.)
Preparing to unpack .../archives/aptly_0.5-4_amd64.deb ...
D01: process_archive oldversionstatus=not installed
Unpacking aptly (0.5-4) ...
D01: process_archive updating info directory
D01: generating infodb hashfile
Processing triggers for debian-security-support (2014.07.31) ...
D01: cmpversions a='0:1.17.13' b='0:1.16' r=1
D01: cmpversions a='0:1.17.13' b='0:1.16' r=1
D01: ensure_diversions: same, skipping
Processing triggers for man-db (2.6.7.1-1) ...
D01: ensure_diversions: same, skipping
D01: ensure_diversions: new, (re)loading
Setting up aptly (0.5-4) ...
D01: deferred_configure updating conffiles
ldd -r: failed at /usr/bin/adequate line 812, <$ldd> line 4.
E: Problem executing scripts DPkg::Post-Invoke 'adequate --help
>/dev/null 2>&1 || exit 0; DEBIAN_FRONTEND=readline exec adequate
--debconf --user nobody --pending'
E: Sub-process returned an error code
Failed to perform requested operation on package.  Trying to recover:
D01: ensure_diversions: new, (re)loading

The relevant error seems to be at

ldd -r: failed at /usr/bin/adequate line 812, <$ldd> line 4.
E: Problem executing scripts DPkg::Post-Invoke 'adequate --help
>/dev/null 2>&1 || exit 0; DEBIAN_FRONTEND=readline exec adequate
--debconf --user nobody --pending'
E: Sub-process returned an error code
Failed to perform requested operation on package.  Trying to recover:
D01: ensure_diversions: new, (re)loading

I use adequate to figure out issues with packages and those options
help make sure that the errors are known without my screen glowing and
things like that.

Please let me know if any more information is needed from my end.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'testing-updates'), (1,
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aptly depends on:
ii  libc6  2.19-10

aptly recommends no packages.

aptly suggests no packages.

-- no debconf information
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8
--- End Message ---
--- Begin Message ---
Version: eglibc/2.19-1

On 2013-05-31 17:35, Jakub Wilk wrote:
> Package: libc6
> Version: 2.17-3
> 
> Running "ldd -r" on /usr/bin/go (shipped by golang-go 2:1.1-1) causes a
> segfault:
> 
> $ ldd -r /usr/bin/go
>   linux-gate.so.1 (0xf7757000)
>   libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7738000)
>   libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000)
>   /lib/ld-linux.so.2 (0xf7758000)
> /usr/bin/ldd: line 116:  8528 Segmentation fault  
> LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes 
> LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"

I can reproduce the problem with eglibc 2.18-4, but not with 2.19-1 and
later versions. I therefore believe the problem has been fixed and I am
closing the bug with this mail.

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

Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."

[Samuel Thibault]

Please always keep the bug mail in Cc, not just the random developper
who happened to answer.

"Антоша ;)", on Thu 17 Dec 2015 19:35:21 +0300, wrote:
> $ gdb qtcreator
> .
> Reading symbols from qtcreator...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /home/lukash/Qt5.5.1/Tools/QtCreator/bin/qtcreator
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffec5cb700 (LWP 5363)]
> [New Thread 0x7fffd832c700 (LWP 5366)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, reloc=
> 0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0,
> version=0x30, sym=0x7fffdcf191d8, map=0x722f30) at ../sysdeps/x86_64/
> dl-machine.h:277
> 277 ../sysdeps/x86_64/dl-machine.h: No such file or directory.

Please provide the result of the backtrace command in gdb too.

Samuel

Bug#808180: Re[2]: Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."

[Антоша ;)]

 libc6-dbg amd64 2.21-4 

$ gdb qtcreator
.
Reading symbols from qtcreator...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/lukash/Qt5.5.1/Tools/QtCreator/bin/qtcreator 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec5cb700 (LWP 5363)]
[New Thread 0x7fffd832c700 (LWP 5366)]

Program received signal SIGSEGV, Segmentation fault.
0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, 
reloc=0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0, 
    version=0x30, sym=0x7fffdcf191d8, map=0x722f30) at 
../sysdeps/x86_64/dl-machine.h:277
277 ../sysdeps/x86_64/dl-machine.h: No such file or directory.





-- 
Антоша ;)

>Среда, 16 декабря 2015, 22:23 +01:00 от Samuel Thibault :
>
>Hello,
>
>lukash, on Wed 16 Dec 2015 23:49:47 +0300, wrote:
>> (gdb) run
>> Starting program: ~/Qt5.5.1/Tools/QtCreator/bin/qtcreator
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7fffec5cb700 (LWP 1282)]
>> [New Thread 0x7fffd831b700 (LWP 1285)]
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x77de72c6 in ?? () from /lib64/ld-linux-x86-64.so.2
>
>Could you install libc6-dbg so we get much better feedback from gdb?
>
>Thanks,
>Samuel

Bug#737079: marked as done (nscd crashes on netgroup lookups)

[Debian Bug Tracking System]

Your message dated Thu, 17 Dec 2015 23:07:42 +0100
with message-id <20151217220742.ga4...@aurel32.net>
and subject line Re: Bug#737079: nscd crashes on netgroup lookups
has caused the Debian Bug report #737079,
regarding nscd crashes on netgroup lookups
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.)


-- 
737079: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737079
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nscd
Version: 2.17-97
Severity: important

I can reasonably consistently crash nscd with netgroup lookups. Below is
the simplest configuration I can reproduce this with:

/etc/nsswitch.conf:
netgroup: files

/etc/netgroup :
tst5netgroup(foo, , ) (bar, , ) tst6netgroup tst7netgroup
tst7netgroup(baz, , )

(/etc/nscd.conf is attached, no /var/cache/nscd present)

When running the following lookup nscd crashes.

getent netgroup tst5netgroup
tst5netgroup  (foo,,) (bar,,) (baz,,)

Attached is output of running nscd under valgrind with just the one
lookup. I also built nscd from source (built 2.17-97, though not
particularly clean build environment and used built source directory to
run nscd) to get the debug symbols included. Attached also valgrind and
gdb output from the crashes with this version also.

Thanks,

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nscd depends on:
ii  libaudit11:2.3.3-3
ii  libc62.17-97
ii  libcap2  1:2.22-1.2
ii  libselinux1  2.2.2-1

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
#
# /etc/nscd.conf
#
# An example Name Service Cache config file.  This file is needed by nscd.
#
# Legal entries are:
#
#   logfile 
#   debug-level 
#   threads 
#   max-threads 
#   server-user 
#   server-user is ignored if nscd is started with -S parameters
#   stat-user   
#   reload-countunlimited|
#   paranoia
#   restart-interval
#
#   enable-cache 
#   positive-time-to-live
#   negative-time-to-live
#   suggested-size   
#   check-files  
#   persistent   
#   shared   
#   max-db-size  
#   auto-propagate   
#
# Currently supported cache names (services): passwd, group, hosts, services
#


#   logfile /var/log/nscd.log
#   threads 4
#   max-threads 32
#   server-user nobody
#   stat-user   somebody
debug-level 0
#   reload-count5
paranoiano
#   restart-interval3600

enable-cachepasswd  yes
positive-time-to-live   passwd  600
negative-time-to-live   passwd  20
suggested-size  passwd  211
check-files passwd  yes
persistent  passwd  yes
shared  passwd  yes
max-db-size passwd  33554432
auto-propagate  passwd  yes

enable-cachegroup   yes
positive-time-to-live   group   3600
negative-time-to-live   group   60
suggested-size  group   211
check-files group   yes
persistent  group   yes
shared  group   yes
max-db-size group   33554432
auto-propagate  group   yes

enable-cachehosts   yes
positive-time-to-live   hosts   3600
negative-time-to-live   hosts   20
suggested-size  hosts   211
check-files hosts   yes
persistent  hosts   yes
shared  hosts   yes
max-db-size hosts   33554432

enable-cacheservicesyes
positive-time-to-live   services28800

Bug#808180: Re[2]: Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."

[Антоша ;)]

 $ gdb qtcreator 
..
(gdb) run
Starting program: /home/lukash/Qt5.5.1/Tools/QtCreator/bin/qtcreator  
[Thread debugging using libthread_db enabled] 
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 
[New Thread 0x7fffec5cb700 (LWP 14948)] 
[New Thread 0x7fffd8422700 (LWP 14951)] 

Program received signal SIGSEGV, Segmentation fault. 
0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, 
reloc=0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0,  
   version=0x30, sym=0x7fffdcf191d8, map=0x723350) at 
../sysdeps/x86_64/dl-machine.h:277 
277 ../sysdeps/x86_64/dl-machine.h: No such file or directory. 
(gdb) backtrace  
#0  0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, 
reloc=0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0,  
   version=0x30, sym=0x7fffdcf191d8, map=0x723350) at 
../sysdeps/x86_64/dl-machine.h:277 
#1  elf_dynamic_do_Rela (skip_ifunc=0, lazy=, 
nrelative=, relsize=, reladdr=,  
   map=0x723350) at do-rel.h:137 
#2  _dl_relocate_object (scope=, reloc_mode=reloc_mode@entry=0, 
consider_profiling=,  
   consider_profiling@entry=0) at dl-reloc.c:258 
#3  0x77dee831 in dl_open_worker (a=a@entry=0x7fffcfe8) at 
dl-open.c:429 
#4  0x77dea114 in _dl_catch_error 
(objname=objname@entry=0x7fffcfd8, 
errstring=errstring@entry=0x7fffcfe0,    
   mallocedp=mallocedp@entry=0x7fffcfd7, 
operate=operate@entry=0x77dee4e0 , 
args=args@entry=0x7fffcfe8)  
   at dl-error.c:187    
 
#5  0x77dedf63 in _dl_open (file=0x756930ab "libGL.so.1", 
mode=-2147483390, caller_dlopen=0x7565d308, nsid=-2,    
   argc=, argv=, env=0x7fffe1f8) at 
dl-open.c:653  
#6  0x745c0f09 in dlopen_doit (a=a@entry=0x7fffd200) at dlopen.c:66 
  
#7  0x77dea114 in _dl_catch_error (objname=0x634980, 
errstring=0x634988, mallocedp=0x634978, operate=0x745c0eb0 ,   
 
   args=0x7fffd200) at dl-error.c:187   
 
#8  0x745c14d9 in _dlerror_run (operate=operate@entry=0x745c0eb0 
, args=args@entry=0x7fffd200) at dlerror.c:163  
#9  0x745c0fa1 in __dlopen (file=, mode=) 
at dlopen.c:87    
#10 0x7565d308 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1   
  
#11 0x75660275 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1   
  
#12 0x756388c4 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1   
  
#13 0x756346b7 in glXGetFBConfigs () from 
/usr/lib/x86_64-linux-gnu/libGL.so.1 
#14 0x75635972 in glXChooseFBConfigSGIX () from 
/usr/lib/x86_64-linux-gnu/libGL.so.1 
#15 0x7fffeb9bc86e in ?? () from 
/home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
 
#16 0x7fffeb9b9ab2 in ?? () from 
/home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
 
#17 0x7fffeb9b873b in ?? () from 
/home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
 
#18 0x7fffedc09a71 in 
QXcbIntegration::createPlatformOpenGLContext(QOpenGLContext*) const () 
  from 
/home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/platforms/../../lib/libQt5XcbQpa.so.5
 
#19 0x766876ed in QOpenGLContext::create() () from 
/home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/Qt/lib/libQt5Gui.so.5 
#20 0x776fa495 in Utils::HostOsInfo::canCreateOpenGLContext(QString*) 
() 
  from /home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libUtils.so.1 
#21 0x7fffdd53ae4c in 
QmlDesigner::QmlDesignerPlugin::initialize(QStringList const&, QString*) () 
  from 
/home/lukash/Qt5.5.1/Tools/QtCreator/lib/qtcreator/plugins/libQmlDesigner.so 
#22 0x77bbd006 in 
ExtensionSystem::Internal::PluginSpecPrivate::initializePlugin() () 
  from 
/home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1
 
#23 0x77bb52df in 
ExtensionSystem::Internal::PluginManagerPrivate::loadPlugin(ExtensionSystem::PluginSpec*,
 ExtensionSystem::PluginSp
ec::State) () from 
/home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1
 
#24 0x77bb7670 in 
ExtensionSystem::Internal::PluginManagerPrivate::loadPlugins() () 
  from 
/home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1
 
#25 0x00409b40 in ?? () 
#26 0x747e4870 in __libc_start_main 

Upcoming stable point release (8.3)

[Adam D. Barratt]

Hi,

The next point release for "jessie" (8.3) is scheduled for Saturday,
January 23rd. Processing of new uploads into jessie-proposed-updates
will be frozen during the preceding weekend.

Regards,

Adam

Re: Fixing the armhf linker path

[Steve McIntyre]

On Thu, Dec 17, 2015 at 11:04:47AM +, Steve McIntyre wrote:
>On Wed, Dec 16, 2015 at 11:30:53PM +0100, Aurelien Jarno wrote:
>>At the beginning of the armhf port the hard-float dynamic linker has
>>been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it
>>has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have
>>changed it in Debian, and added a patch to the glibc [2] to temporarily
>>support both paths, until all the packages have been rebuilt with the
>>new path.
>>  
>>However we failed to do it for Wheezy. We also failed to do it for
>>Jessie. So let's do it for Stretch, so that we can drop the glibc
>>patches in Buster, and ensure binary compatibility with other
>>distributions.
>>
>>For that we first need to binNMU the packages which have not been
>>rebuilt since the dynamic linker change in unstable (see the list at
>>the end of the mail). Then we can have a look at getting all of them 
>>migrated to testing.
>>
>>Any comments or objections?
>
>ACK, this makes sense. I spoke with Adam a while back about doing
>this. I promised I'd scan the archive for any packages still relying
>on the old linker path, but I've not got to it yet - sorry. :-/

And I did today. Scanning all the armhf debs in stretch and sid for
linker path suggests the following binary packages needing
updating/rebuilding:

  stretch   sid

main   741  771
contrib  34
non-free 34

Logs of the found wrong linker paths (by binary package and binary)
are attached.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


stretch-out-main.gz
Description: application/gzip


stretch-out-contrib.gz
Description: application/gzip


stretch-out-non-free.gz
Description: application/gzip


sid-out-main.gz
Description: application/gzip


sid-out-contrib.gz
Description: application/gzip


sid-out-non-free.gz
Description: application/gzip

Bug#808181: Re[2]: Bug#808181: libc6: Upgrade can make the linker unusable

[Vlad Orlov]

Hi,

> We are working to migrate binutils version 2.25.90.20151209-1 into
> testing asap. If everything goes well it should be the case after the
> 13:52 UTC dinstall run, so a few hours after that on the mirrors.
> 
> In the meantime fetching and installing this version from sid, should
> solve the issue.

Thanks, that version solved the issue indeed. Compilation goes fine now.

Re: Fixing the armhf linker path

[Steve McIntyre]

On Wed, Dec 16, 2015 at 11:30:53PM +0100, Aurelien Jarno wrote:
>At the beginning of the armhf port the hard-float dynamic linker has
>been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it
>has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have
>changed it in Debian, and added a patch to the glibc [2] to temporarily
>support both paths, until all the packages have been rebuilt with the
>new path.
>  
>However we failed to do it for Wheezy. We also failed to do it for
>Jessie. So let's do it for Stretch, so that we can drop the glibc
>patches in Buster, and ensure binary compatibility with other
>distributions.
>
>For that we first need to binNMU the packages which have not been
>rebuilt since the dynamic linker change in unstable (see the list at
>the end of the mail). Then we can have a look at getting all of them 
>migrated to testing.
>
>Any comments or objections?

ACK, this makes sense. I spoke with Adam a while back about doing
this. I promised I'd scan the archive for any packages still relying
on the old linker path, but I've not got to it yet - sorry. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

r6824 - in glibc-package/branches/glibc-branch-jessie/debian: . patches patches/any

[Aurelien Jarno]

Author: aurel32
Date: 2015-12-17 18:45:34 + (Thu, 17 Dec 2015)
New Revision: 6824

Added:
   
glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff
Modified:
   glibc-package/branches/glibc-branch-jessie/debian/changelog
   glibc-package/branches/glibc-branch-jessie/debian/patches/series
Log:
patches/any/cvs-strxfrm-buffer-overflows.diff: new patch from upstream
to fix memory allocations issues that can lead to buffer overflows on
the stack.  Closes: #803927.

Modified: glibc-package/branches/glibc-branch-jessie/debian/changelog
===
--- glibc-package/branches/glibc-branch-jessie/debian/changelog 2015-12-15 
23:00:10 UTC (rev 6823)
+++ glibc-package/branches/glibc-branch-jessie/debian/changelog 2015-12-17 
18:45:34 UTC (rev 6824)
@@ -14,6 +14,9 @@
 unconditionally disable LD_POINTER_GUARD.  Closes: #798316, #801691.
   * patches/any/cvs-mangle-tls_dtor_list.diff: new patch from upstream to
 mangle function pointers in tls_dtor_list.  Closes: #802256.
+  * patches/any/cvs-strxfrm-buffer-overflows.diff: new patch from upstream
+to fix memory allocations issues that can lead to buffer overflows on
+the stack.  Closes: #803927.
 
   [ Henrique de Moraes Holschuh ]
   * Replace patches/amd64/local-blacklist-on-TSX-Haswell.diff by 

Added: 
glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff
===
--- 
glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff
 (rev 0)
+++ 
glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff
 2015-12-17 18:45:34 UTC (rev 6824)
@@ -0,0 +1,670 @@
+2015-01-13  Leonhard Holz  
+
+   [BZ #16009]
+   * string/strxfrm_l.c (STRXFRM): Allocate fixed size cache for
+   weights and rules. Use do_xfrm_cached if data fits in cache,
+   do_xfrm otherwise.  Moved former main loop to...
+   * (do_xfrm_cached): New function.
+   * (do_xfrm): Non-caching version of do_xfrm_cached. Uses
+   find_idx, find_position and stack_push.
+   * (find_idx): New function.
+   * (find_position): Likewise.
+   * localedata/sort-test.sh: Added test run for do_xfrm.
+   * localedata/xfrm-test.c (main): Added command line option
+   -nocache to run the test with strings that are too large for
+   the STRXFRM cache.
+
+--- a/localedata/sort-test.sh
 b/localedata/sort-test.sh
+@@ -49,11 +49,17 @@
+${common_objpfx}localedata/xfrm-test $id < $cns.in \
+> ${common_objpfx}localedata/$cns.xout || here=1
+   cmp -s $cns.in ${common_objpfx}localedata/$cns.xout || here=1
++  LOCPATH=${common_objpfx}localedata GCONV_PATH=${common_objpfx}/iconvdata \
++   LC_ALL=$l ${run_program_prefix} \
++   ${common_objpfx}localedata/xfrm-test $id -nocache < $cns.in \
++   > ${common_objpfx}localedata/$cns.nocache.xout || here=1
++  cmp -s $cns.in ${common_objpfx}localedata/$cns.nocache.xout || here=1
+   if test $here -eq 0; then
+ echo "$l xfrm-test OK"
+   else
+ echo "$l xfrm-test FAIL"
+ diff -u $cns.in ${common_objpfx}localedata/$cns.xout | sed 's/^/  /'
++diff -u $cns.in ${common_objpfx}localedata/$cns.nocache.xout | sed 's/^/  
/'
+ status=1
+   fi
+ done
+--- a/localedata/xfrm-test.c
 b/localedata/xfrm-test.c
+@@ -23,7 +23,10 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
++/* Keep in sync with string/strxfrm_l.c.  */
++#define SMALL_STR_SIZE 4095
+ 
+ struct lines
+ {
+@@ -37,6 +40,7 @@
+ main (int argc, char *argv[])
+ {
+   int result = 0;
++  bool nocache = false;
+   size_t nstrings, nstrings_max;
+   struct lines *strings;
+   char *line = NULL;
+@@ -44,7 +48,18 @@
+   size_t n;
+ 
+   if (argc < 2)
+-error (1, 0, "usage: %s ", argv[0]);
++error (1, 0, "usage: %s  [-nocache]", argv[0]);
++
++  if (argc == 3)
++{
++  if (strcmp (argv[2], "-nocache") == 0)
++  nocache = true;
++  else
++  {
++printf ("Unknown option %s!\n", argv[2]);
++exit (1);
++  }
++}
+ 
+   setlocale (LC_ALL, "");
+ 
+@@ -59,9 +74,9 @@
+ 
+   while (1)
+ {
+-  char saved, *newp;
+-  int needed;
+-  int l;
++  char saved, *word, *newp;
++  size_t l, line_len, needed;
++
+   if (getline (, , stdin) < 0)
+   break;
+ 
+@@ -83,10 +98,35 @@
+ 
+   saved = line[l];
+   line[l] = '\0';
+-  needed = strxfrm (NULL, line, 0);
++
++  if (nocache)
++  {
++line_len = strlen (line);
++word = malloc (line_len + SMALL_STR_SIZE + 1);
++if (word == NULL)
++  {
++printf ("malloc failed: %m\n");
++exit (1);
++  }
++memset (word, ' ', SMALL_STR_SIZE);
++memcpy (word + SMALL_STR_SIZE, line, line_len);
++word[line_len + SMALL_STR_SIZE]