[glibc] branch sid updated (59ea7d2 -> 0a94d5f)

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a change to branch sid
in repository glibc.

  from  59ea7d2   New changelog entry
   new  0a94d5f   debian/patches/git-updates.diff: update from upstream 
stable branch:

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 debian/changelog|  4 ++-
 debian/patches/git-updates.diff | 77 ++---
 2 files changed, 75 insertions(+), 6 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Processed: Bug#882794 marked as pending

[Debian Bug Tracking System]

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

> tag 882794 pending
Bug #882794 [src:glibc] glibc: Please backport fix for assertion failure in 
posix_spawn()
Added tag(s) pending.
> thanks
Stopping processing here.

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

[glibc] 01/01: debian/patches/git-updates.diff: update from upstream stable branch:

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch sid
in repository glibc.

commit 0a94d5f3ce5785b07372a810f011c62679be910e
Author: Aurelien Jarno 
Date:   Mon Nov 27 00:22:30 2017 +0100

debian/patches/git-updates.diff: update from upstream stable branch:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - Fix assertion failure in posix_spawn().  Closes: #882794.
---
 debian/changelog|  4 ++-
 debian/patches/git-updates.diff | 77 ++---
 2 files changed, 75 insertions(+), 6 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index a3b635a..3f530fd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
 glibc (2.25-3) UNRELEASED; urgency=medium
 
-  * 
+  [ Aurelien Jarno ]
+  * debian/patches/git-updates.diff: update from upstream stable branch:
+- Fix assertion failure in posix_spawn().  Closes: #882794.
 
  -- Aurelien Jarno   Wed, 22 Nov 2017 00:21:54 +0100
 
diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff
index e2d3970..8676cb5 100644
--- a/debian/patches/git-updates.diff
+++ b/debian/patches/git-updates.diff
@@ -1,10 +1,22 @@
 GIT update of git://sourceware.org/git/glibc.git/release/2.25/master from 
glibc-2.25
 
 diff --git a/ChangeLog b/ChangeLog
-index f140ee67de..d3c5570239 100644
+index f140ee67de..c1df219b61 100644
 --- a/ChangeLog
 +++ b/ChangeLog
-@@ -1,3 +1,597 @@
+@@ -1,3 +1,609 @@
++2017-10-23  Adhemerval Zanella  
++
++  * sysdeps/unix/sysv/linux/spawni.c (__spawnix): Use 0 instead of
++  WNOHANG in waitpid call.
++
++2017-10-20  Adhemerval Zanella  
++
++  [BZ #22273]
++  * sysdeps/unix/sysv/linux/spawni.c (__spawnix): Handle the case where
++  the auxiliary process is terminated by a signal before calling _exit
++  or execve.
++
 +2017-08-09  Andreas Schwab  
 +
 +  * nptl/Makefile (tests) [$(build-shared) = yes]: Add
@@ -9961,10 +9973,18 @@ index 00..094e05124b
 +# endif
 +#endif
 diff --git a/sysdeps/unix/sysv/linux/spawni.c 
b/sysdeps/unix/sysv/linux/spawni.c
-index 2daf0c5ef0..29d8f25ab5 100644
+index 2daf0c5ef0..ee09fb762b 100644
 --- a/sysdeps/unix/sysv/linux/spawni.c
 +++ b/sysdeps/unix/sysv/linux/spawni.c
-@@ -61,17 +61,18 @@
+@@ -17,7 +17,6 @@
+.  */
+ 
+ #include 
+-#include 
+ #include 
+ #include 
+ #include 
+@@ -61,17 +60,18 @@
  #define SPAWN_ERROR   127
  
  #ifdef __ia64__
@@ -9988,7 +10008,15 @@ index 2daf0c5ef0..29d8f25ab5 100644
  #endif
  
  
-@@ -318,6 +319,11 @@ __spawnix (pid_t * pid, const char *file,
+@@ -265,7 +265,6 @@ __spawni_child (void *arguments)
+   __sigprocmask (SIG_SETMASK, (attr->__flags & POSIX_SPAWN_SETSIGMASK)
+? >__ss : >oldmask, 0);
+ 
+-  args->err = 0;
+   args->exec (args->file, args->argv, args->envp);
+ 
+   /* This is compatibility function required to enable posix_spawn run
+@@ -318,6 +317,11 @@ __spawnix (pid_t * pid, const char *file,
  
/* Add a slack area for child's stack.  */
size_t argv_size = (argc * sizeof (void *)) + 512;
@@ -1,6 +10028,45 @@ index 2daf0c5ef0..29d8f25ab5 100644
size_t stack_size = ALIGN_UP (argv_size, GLRO(dl_pagesize));
void *stack = __mmap (NULL, stack_size, prot,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0);
+@@ -331,7 +335,7 @@ __spawnix (pid_t * pid, const char *file,
+ 
+   /* Child must set args.err to something non-negative - we rely on
+  the parent and child sharing VM.  */
+-  args.err = -1;
++  args.err = 0;
+   args.file = file;
+   args.exec = exec;
+   args.fa = file_actions;
+@@ -354,12 +358,26 @@ __spawnix (pid_t * pid, const char *file,
+   new_pid = CLONE (__spawni_child, STACK (stack, stack_size), stack_size,
+  CLONE_VM | CLONE_VFORK | SIGCHLD, );
+ 
++  /* It needs to collect the case where the auxiliary process was created
++ but failed to execute the file (due either any preparation step or
++ for execve itself).  */
+   if (new_pid > 0)
+ {
++  /* Also, it handles the unlikely case where the auxiliary process was
++   terminated before calling execve as if it was successfully.  The
++   args.err is set to 0 as default and changed to a positive value
++   only in case of failure, so in case of premature termination
++   due a signal args.err will remain zeroed and it will be up to
++   caller to actually collect it.  */
+   ec = args.err;
+-  assert (ec >= 0);
+-  if (ec != 0)
+-__waitpid (new_pid, NULL, 0);
++  if (ec > 0)
++  /* There still an unlikely case where the child is cancelled after
++ setting args.err, due to a positive error value.  Also there is
++ possible pid reuse race (where the kernel allocated the same pid
++ to 

Bug#419467: marked as done (New version uninstallable on kernel 2.4 systems because NPTL)

[Debian Bug Tracking System]

Your message dated Mon, 27 Nov 2017 00:04:56 +0100
with message-id <20171126230456.33uq4daph3p7e...@aurel32.net>
and subject line Bug#419467: New version uninstallable on kernel 2.4 systems 
because NPTL
has caused the Debian Bug report #419467,
regarding New version uninstallable on kernel 2.4 systems because NPTL
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.)


-- 
419467: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419467
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: libc6
Version: 2.5-1
Severity: important

The new libc6 is uninstallable on systems with kernel 2.4. As there is
still many systems which are only efficient with kernle 2.4 this is a
very big problem.

- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 
'oldstable'), (60, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.4.34
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to 
de_DE)

Versions of packages libc6 depends on:
ii  tzdata2007b-1Time Zone and Daylight Saving Time

libc6 recommends no packages.

- -- no debconf information

- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRiKQh5+OKpjRpO3lAQLhDgf+Jh1o8qPmEZMV+tPyHaOrTJJhtudwl+iF
Vio/hUhiAfsarypViDQ9u6qMKG2n0ULp9uFppHOsU4UA0Mvdcdw/0xbOz3ya28GJ
IdvjnNiaVGEAz0fk9IVDxP+PzRU94yOleplA9xN8wVMsW3DVyliiif89JvaFFEd9
gERULqi7UHREiBzdjc8L2Gd9auYCkH8gDs5vhG2mdkgueyCdbyVyoF9iUJaN1i0A
lvH/ffuoemiC134zThWnvVCgMgg5Fgi3hDuWIY3R3lz/z8sM1/Jy1tsOY4HDpLKk
/R1kXM87ausjpCnUrbUSJj6zAkrIfFAumk5s9ykxfdkqNVcVO+vd2w==
=tWmI
-END PGP SIGNATURE-

--- End Message ---
--- Begin Message ---
On 2007-04-15 22:52, Klaus Ethgen wrote:
> Package: libc6
> Version: 2.5-1
> Severity: important
> 
> The new libc6 is uninstallable on systems with kernel 2.4. As there is
> still many systems which are only efficient with kernle 2.4 this is a
> very big problem.

2.4 kernels are definitely dead. Closing the bug now.

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


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

Bug#550780: eglibc: please provide support for cross tools

[Aurelien Jarno]

On 2009-10-12 23:19, Hector wrote:
> Package: eglibc
> Severity: wishlist
> 
> 
> Hello,
> 
>   We would like to be able to have cross toolchains in the Debian archive. 
> Currently, at emdebian.org we provide precompiled binaries but we need a way 
> for the autobuilders to understand how to build it.
> 
>   The eglibc bit needed is a dpkg-cross -a$(DEB_HOST_ARCH) -b for the 
> libraries and headers of a foreign architecture, that maybe you maintainers 
> could provide as the regular build, but taking into account that it is a 
> mid-hack until multiarch is ready and able to provide a nicer solution for 
> this problem. As an alternative, we could upload a source package build 
> depending on eglibc-source and trying to do all this magic. This can be 
> somehow tricky as you probably already know libc and libgcc have circular 
> dependencies, which prevents us from bootstrapping the compiler 100% from 
> source.
> 
>   Comments are welcome, as I am unsure which it is the cleaner and nicer way 
> of providing what libc{6,6.1}-$(DEB_HOST_ARCH)-cross provides and have the 
> autobuilder happy.
> 

glibc now supports being cross built, and cross compiled version for
major architectures are available in the archive. I therefore think this
bug can be closed.

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

Bug#836541: marked as done (libc6-dev: res_query does not use external nameservers when set)

[Debian Bug Tracking System]

Your message dated Sun, 26 Nov 2017 23:51:15 +0100
with message-id <20171126225115.ak7gnwxeblmzx...@aurel32.net>
and subject line Re: Bug#794336: [e]glibc breaks res_init() functionality
has caused the Debian Bug report #794336,
regarding libc6-dev: res_query does not use external nameservers when set
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.)


-- 
794336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794336
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-dev
Version: 2.19-18+deb8u4
Severity: important

Dear Maintainer,

Regarding the resolver library, when nameservers are explicitly
specified after the call to res_init and before the actual call
to res_query, the res_query code uses internal resolution first
rather than the specified nameservers.

Example code attached below.

#include 
#include 
#include 
#include 
#include 
#include 

#define N 4096

/* - */
/* CODE BEGINS   */
/* - */

int main (int argc, char *argv[]) {
u_char nsbuf[N];
char dispbuf[N];
ns_msg msg;
ns_rr rr;
int i, l;

if (argc < 2) {
printf ("Usage: %s \n", argv[0]);
exit (1);
}

/* Initialize to use the Google nameservers */
 res_init();
 _res.nscount = 2;
 _res.nsaddr_list[0].sin_family = AF_INET;
 _res.nsaddr_list[0].sin_addr.s_addr = inet_addr("8.8.8.8");
 _res.nsaddr_list[0].sin_port = htons(53);
 _res.nsaddr_list[1].sin_family = AF_INET;
 _res.nsaddr_list[1].sin_addr.s_addr = inet_addr("8.8.4.4");
 _res.nsaddr_list[1].sin_port = htons(53);

printf("Domain:   %s\n\n", argv[1]);

 /* Print the A record return or the error code */
printf("A record(s):\n");

l = res_query(argv[1], ns_c_any, ns_t_a, nsbuf, sizeof(nsbuf));
if (l < 0) perror(argv[1]);
ns_initparse(nsbuf, l, );
l = ns_msg_count(msg, ns_s_an);
for (i = 0; i < l; i++) {
  ns_parserr(, ns_s_an, i, );
  ns_sprintrr(, , NULL, NULL, dispbuf, sizeof(dispbuf));
  printf("\t%s \n", dispbuf);
}

// NS RECORD
printf("\nNS record(s):\n");
l = res_query(argv[1], ns_c_any, ns_t_ns, nsbuf, sizeof(nsbuf));
if (l < 0) perror(argv[1]);
ns_initparse(nsbuf, l, );
l = ns_msg_count(msg, ns_s_an);
for (i = 0; i < l; i++) {
  ns_parserr(, ns_s_an, 0, );
  ns_sprintrr(, , NULL, NULL, dispbuf, sizeof(dispbuf));
  printf("\t%s \n", dispbuf);
}
return 0;
}

When the test program is run it incorrectly returns the LAN address
of the host from resolv.conf.  It should return the internet address
of the host from the external nameservers, as seen below.

sysmgr@www:~$ ./a.out www.somewhere.com
Domain: www.somewhere.com

A record(s):
www.somewhere.com. 6H IN A 192.168.0.209

NS record(s):
www.somewhere.com. 6H IN NS localhost.



-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 4.4.0-kirkwood-tld-1 (PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.19-18+deb8u4
ii  libc6   2.19-18+deb8u4
ii  linux-libc-dev  3.16.7-ckt25-2+deb8u2

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
pn  manpages-dev  

-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 2.26-0experimental0

On 2015-08-02 01:16, Joshua Rogers wrote:
> package: glibc
> 
> I don't know whether this is still relevant or not, as I know Debian has
> switched back to the original glibc, which does not contain this bug, but...
> 
> A patch to Debian's glibc, introduced here:
> https://lists.debian.org/debian-glibc/2006/06/msg00154.html contains a
> bug, which breaks the functionality of res_init().
> 
> res_init() is supposed to initalize the _res struct, and then allow for
> modifications to the _res struct by the user, before resolving something
> using res_query().
> 
> The introduction of the 'last_mtime' stat struct was used to determine
> whether or not the _res struct had to be re-initalized, as the last
> modification time of /etc/resolv.conf had changed. However, res_query()
> uses __res_maybe_init() to determine whether or not to reset _res, but
> res_init() does not set statbuf. So, calling res_init() effectively does
> nothing, since all the changes will be overwritten by the first call to
> res_query(), 

Bug#794336: marked as done ([e]glibc breaks res_init() functionality)

[Debian Bug Tracking System]

Your message dated Sun, 26 Nov 2017 23:51:15 +0100
with message-id <20171126225115.ak7gnwxeblmzx...@aurel32.net>
and subject line Re: Bug#794336: [e]glibc breaks res_init() functionality
has caused the Debian Bug report #794336,
regarding [e]glibc breaks res_init() functionality
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.)


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

I don't know whether this is still relevant or not, as I know Debian has
switched back to the original glibc, which does not contain this bug, but...

A patch to Debian's glibc, introduced here:
https://lists.debian.org/debian-glibc/2006/06/msg00154.html contains a
bug, which breaks the functionality of res_init().

res_init() is supposed to initalize the _res struct, and then allow for
modifications to the _res struct by the user, before resolving something
using res_query().

The introduction of the 'last_mtime' stat struct was used to determine
whether or not the _res struct had to be re-initalized, as the last
modification time of /etc/resolv.conf had changed. However, res_query()
uses __res_maybe_init() to determine whether or not to reset _res, but
res_init() does not set statbuf. So, calling res_init() effectively does
nothing, since all the changes will be overwritten by the first call to
res_query(), because res_query() runs __res_maybe_init().


Ubuntu report here, for reference:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1432378/comments/4


Thanks!

(Apologies if this has done through twice. I haven't used Debian's bug tracking 
for awhile.)

-- 
-- Joshua Rogers 



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Version: 2.26-0experimental0

On 2015-08-02 01:16, Joshua Rogers wrote:
> package: glibc
> 
> I don't know whether this is still relevant or not, as I know Debian has
> switched back to the original glibc, which does not contain this bug, but...
> 
> A patch to Debian's glibc, introduced here:
> https://lists.debian.org/debian-glibc/2006/06/msg00154.html contains a
> bug, which breaks the functionality of res_init().
> 
> res_init() is supposed to initalize the _res struct, and then allow for
> modifications to the _res struct by the user, before resolving something
> using res_query().
> 
> The introduction of the 'last_mtime' stat struct was used to determine
> whether or not the _res struct had to be re-initalized, as the last
> modification time of /etc/resolv.conf had changed. However, res_query()
> uses __res_maybe_init() to determine whether or not to reset _res, but
> res_init() does not set statbuf. So, calling res_init() effectively does
> nothing, since all the changes will be overwritten by the first call to
> res_query(), because res_query() runs __res_maybe_init().
> 
> 
> Ubuntu report here, for reference:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1432378/comments/4

This bug has been fixed in glibc 2.26, as way to reload /etc/resolv.conf
rewritten and merged differently upstream. Marking the bug as closed for
this version.

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


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

Bug#373555: marked as done (Can't use pthread_cleanup_push with non-GCC compiler)

[Debian Bug Tracking System]

Your message dated Sun, 26 Nov 2017 23:46:02 +0100
with message-id <20171126224602.irhdjgyqx7ffy...@aurel32.net>
and subject line Bug#373555: Can't use pthread_cleanup_push with non-GCC 
compiler
has caused the Debian Bug report #373555,
regarding Can't use pthread_cleanup_push with non-GCC compiler
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.)


-- 
373555: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373555
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-dev
Version: 2.3.6-15

When trying to compile a small pthread code with the Portland compiler
the pthread.h gives me code that uses gcc builtins.

System is a x86_64 machine with nptl based pthread.

Code:
#include 
int
main ()
{
pthread_t th=pthread_self();
pthread_join(th, 0);
pthread_attr_init(0);
pthread_cleanup_push(0, 0);
pthread_create(0,0,0,0);
pthread_cleanup_pop(0);
return 0;
}

When compiled with PGI i get
$ pgcc -o ptest ptest.c -lpthread
ptest.c:
ptest.o: In function `main':
ptest.c:(.text+0x46): undefined reference to `__builtin_expect'

This seems to be caused by the following sequence of #if defined in
pthread.h

...
#if defined __GNUC__ && defined __EXCEPTIONS
# ifdef __cplusplus
...
# define pthread_cleanup_push(routine, arg) \
  do { \
__pthread_cleanup_class __clframe (routine, arg)
...
# else
# define pthread_cleanup_push(routine, arg) \
   do { \
struct __pthread_cleanup_frame __clframe \
  __attribute__ ((__cleanup__ (__pthread_cleanup_routine))) \
  = { .__cancel_routine = (routine), .__cancel_arg = (arg), \
  .__do_it = 1 };
...
# endif
#else
# define pthread_cleanup_push(routine, arg) \
  do { \
__pthread_unwind_buf_t __cancel_buf; \
void (*__cancel_routine) (void *) = (routine); \
void *__cancel_arg = (arg); \
int not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) \
  __cancel_buf.__cancel_jmp_buf, 0);
\
if (__builtin_expect (not_first_call, 0)) \
...
#endif

I.e. it uses __builtin_expect when __GCC__ is not defined.

All of this seems to be a bit too GCC centric.


--- End Message ---
--- Begin Message ---
Version: 2.16-0experimental0

On 2006-06-14 11:06, Åke Sandgren wrote:
> Package: libc6-dev
> Version: 2.3.6-15
> 
> When trying to compile a small pthread code with the Portland compiler
> the pthread.h gives me code that uses gcc builtins.
> 
> System is a x86_64 machine with nptl based pthread.
> 
> Code:
> #include 
> int
> main ()
> {
> pthread_t th=pthread_self();
> pthread_join(th, 0);
> pthread_attr_init(0);
> pthread_cleanup_push(0, 0);
> pthread_create(0,0,0,0);
> pthread_cleanup_pop(0);
> return 0;
> }
> 
> When compiled with PGI i get
> $ pgcc -o ptest ptest.c -lpthread
> ptest.c:
> ptest.o: In function `main':
> ptest.c:(.text+0x46): undefined reference to `__builtin_expect'
> 
> This seems to be caused by the following sequence of #if defined in
> pthread.h
> 
> ...
> #if defined __GNUC__ && defined __EXCEPTIONS
> # ifdef __cplusplus
> ...
> # define pthread_cleanup_push(routine, arg) \
>   do { \
> __pthread_cleanup_class __clframe (routine, arg)
> ...
> # else
> # define pthread_cleanup_push(routine, arg) \
>do { \
> struct __pthread_cleanup_frame __clframe \
>   __attribute__ ((__cleanup__ (__pthread_cleanup_routine))) \
>   = { .__cancel_routine = (routine), .__cancel_arg = (arg), \
>   .__do_it = 1 };
> ...
> # endif
> #else
> # define pthread_cleanup_push(routine, arg) \
>   do { \
> __pthread_unwind_buf_t __cancel_buf; \
> void (*__cancel_routine) (void *) = (routine); \
> void *__cancel_arg = (arg); \
> int not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) \
>   __cancel_buf.__cancel_jmp_buf, 0);
> \
> if (__builtin_expect (not_first_call, 0)) \
> ...
> #endif
> 
> I.e. it uses __builtin_expect when __GCC__ is not defined.
> 
> All of this seems to be a bit too GCC centric.
> 

This bug has been fixed in upstream glibc 2.16, which first appeared in
debian as eglibc 2.16-0experimental0. Closing the bug.

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

Processed: bug 373555 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=14188

[Debian Bug Tracking System]

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

> forwarded 373555 https://sourceware.org/bugzilla/show_bug.cgi?id=14188
Bug #373555 [libc6-dev] Can't use pthread_cleanup_push with non-GCC compiler
Set Bug forwarded-to-address to 
'https://sourceware.org/bugzilla/show_bug.cgi?id=14188'.
> thanks
Stopping processing here.

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

Bug#663948: marked as done (Wrong resolver behavior (ipv6) after squeeze point release)

[Debian Bug Tracking System]

Your message dated Sun, 26 Nov 2017 23:35:29 +0100
with message-id <20171126223529.czdreu3tkkb6z...@aurel32.net>
and subject line Bug#663948: Wrong resolver behavior (ipv6) after squeeze point 
release
has caused the Debian Bug report #663948,
regarding Wrong resolver behavior (ipv6) after squeeze point release
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.)


-- 
663948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663948
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.11.3-3
Severity: important
Tags: squeeze ipv6

After last glibc6 update 2.11.2-10 -> 2.11.3-2 resolver changed its behavior.

My setup (nothing strange):
ipv6 enabled, but no special settings for it and my local DNS zone has only A 
records.

How 2.11.2-10 works:
When I type
$ getent hosts mailsrv
it get domain name from /etc/resolv.conf and do the following requests:

12:00:56.678524 IP standvm-squeeze.lvknet.33570 > ns.lvknet.domain: 41768+ 
? mailsrv.lvknet. (32)
12:00:56.679161 IP ns.lvknet.domain > standvm-squeeze.lvknet.33570: 41768* 
0/1/0 (76)
12:00:56.679478 IP standvm-squeeze.lvknet.50893 > ns.lvknet.domain: 16915+ A? 
mailsrv.lvknet. (32)
12:00:56.679857 IP ns.lvknet.domain > standvm-squeeze.lvknet.50893: 16915* 
1/1/1 A 192.168.132.4 (81)

Ok, It tries ipv6 first, I dont need this, but no problem, at least my dns 
server knows the answer.

But after upgrade to 2.11.3-2 it's behavior changed:

11:19:42.200667 IP standvm-squeeze.lvknet.54095 > ns.lvknet.domain: 17176+ 
? mailsrv.lvknet. (32)
11:19:42.201110 IP ns.lvknet.domain > standvm-squeeze.lvknet.54095: 17176* 
0/1/0 (76)
11:19:42.201228 IP standvm-squeeze.lvknet.48952 > ns.lvknet.domain: 2218+ ? 
mailsrv. (25)
11:19:42.202883 IP ns.lvknet.domain > standvm-squeeze.lvknet.48952: 2218 
NXDomain 0/1/0 (100)
11:19:42.203028 IP standvm-squeeze.lvknet.54867 > ns.lvknet.domain: 364+ A? 
mailsrv.lvknet. (32)
11:19:42.203337 IP ns.lvknet.domain > standvm-squeeze.lvknet.54867: 364* 1/1/1 
A 192.168.132.4 (81)

It tries fqdn for ipv6 address, then just hostname without domain for ipv6 and
only after that it asks for ipv4 address.

I don't know why did upstream do this, but I see at least two problems:

My DNS server knows my zone (lvknet. in my case), but when someone asks him for 
hostname. it will
translate this request to my provider's DNS server (I use bind whith forward in 
my settings, nothing strange).

1.My provider will see every hosts request withing my network. This is security 
flow, I'm sure.
2.If I have connectivity problem with my provider,
$ getent hosts validhostnamemyDNSserverknowsabout
will hang for about a minute.


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

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

Versions of packages libc6 depends on:
ii  libc-bin  2.11.3-3   Embedded GNU C Library: Binaries
ii  libgcc1   1:4.4.5-8  GCC support library

Versions of packages libc6 recommends:
ii  libc6-i6862.11.3-3   Embedded GNU C Library: Shared lib

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

-- debconf information:
* glibc/restart-services: cron
  glibc/disable-screensaver:
  glibc/restart-failed:
  glibc/upgrade: true


--- End Message ---
--- Begin Message ---
On 2012-03-14 12:22, Alexander Gerasiov wrote:
> Package: libc6
> Version: 2.11.3-3
> Severity: important
> Tags: squeeze ipv6
> 
> After last glibc6 update 2.11.2-10 -> 2.11.3-2 resolver changed its behavior.
> 
> My setup (nothing strange):
> ipv6 enabled, but no special settings for it and my local DNS zone has only A 
> records.
> 
> How 2.11.2-10 works:
> When I type
> $ getent hosts mailsrv
> it get domain name from /etc/resolv.conf and do the following requests:
> 
> 12:00:56.678524 IP standvm-squeeze.lvknet.33570 > ns.lvknet.domain: 41768+ 
> ? mailsrv.lvknet. (32)
> 12:00:56.679161 IP ns.lvknet.domain > standvm-squeeze.lvknet.33570: 41768* 
> 0/1/0 (76)
> 12:00:56.679478 IP standvm-squeeze.lvknet.50893 > ns.lvknet.domain: 16915+ A? 
> mailsrv.lvknet. (32)
> 12:00:56.679857 IP ns.lvknet.domain > standvm-squeeze.lvknet.50893: 16915* 
> 1/1/1 A 192.168.132.4 

Bug#657528: marked as done (Please enable hardened build flags)

[Debian Bug Tracking System]

Your message dated Sun, 26 Nov 2017 23:33:16 +0100
with message-id <20171126223316.ylkucrrbitx2s...@aurel32.net>
and subject line Bug#657528: Please enable hardened build flags
has caused the Debian Bug report #657528,
regarding Please enable hardened build flags
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.)


-- 
657528: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657528
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: eglibc
Severity: important

Please enable hardened build flags through dpkg-buildflags
for the userspace tools like nscd and libc6-bin.

Cheers,
Moritz


--- End Message ---
--- Begin Message ---
Version: 2.24-1

On 2012-01-26 21:19, Moritz Muehlenhoff wrote:
> Package: eglibc
> Severity: important
> 
> Please enable hardened build flags through dpkg-buildflags
> for the userspace tools like nscd and libc6-bin.

Even if recent glibc versions still do not use dpkg-buildflags, the
whole libc and userspace tools are now built with -Wall -Werror, 
-D_FORTIFY_SOURCE=2, -fstack-protector-strong and -Wl,-z,relro. 

This is the case since at least glibc 2.24, which is in stretch. As such
I therefore consider this bug can be closed.

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

Bug#882794: [Debian-ports-devel] Bug#882794: glibc: Please backport fix for assertion failure in posix_spawn()

[John Paul Adrian Glaubitz]

On 11/26/2017 10:13 PM, John Paul Adrian Glaubitz wrote:
> This was introduced with [1] and reported in [2]. A QEMU bug report
> has also been opened [3]. I'm currently rebuilding glibc for m68k with
> the attached patch which should fix the issue. Would be great if it
> could be included in one of the next uploads provided that it fixes
> the issue which I am going to find out soon.

Hmm, ok, seems that the patch is unrelated. It doesn't help with QEMU.
Guess we'll have to wait for QEMU to be fixed then.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Processed: found 882794 in glibc/2.25-1

[Debian Bug Tracking System]

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

> found 882794 glibc/2.25-1
Bug #882794 [src:glibc] glibc: Please backport fix for assertion failure in 
posix_spawn()
Marked as found in versions glibc/2.25-1.
> thanks
Stopping processing here.

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

Processed: notfound 882794 in glibc/2.24-11+deb9u1

[Debian Bug Tracking System]

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

> notfound 882794 glibc/2.24-11+deb9u1
Bug #882794 [src:glibc] glibc: Please backport fix for assertion failure in 
posix_spawn()
Ignoring request to alter found versions of bug #882794 to the same values 
previously set
> thanks
Stopping processing here.

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

Processed: notfound 882794 in 2.24-11+deb9u1

[Debian Bug Tracking System]

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

> notfound 882794 2.24-11+deb9u1
Bug #882794 [src:glibc] glibc: Please backport fix for assertion failure in 
posix_spawn()
No longer marked as found in versions glibc/2.24-11+deb9u1.
> thanks
Stopping processing here.

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

Bug#870257: Add conflicts for multilib development packages

[Aurelien Jarno]

control: tag -1 - patch

On 2017-07-31 13:36, Matthias Klose wrote:
> Package: src:glibc
> Version: 2.24-12
> Tags: patch
> 
> Please add conflicts for the multilib development packages. There are bug
> reports with foreign architectures that try to install both libc6-dev-i386 and
> libc6-dev-amd64 packages, and then failing because of conflicts in 
> /usr/include.
>  This patch adds the conflicts for all the known multilib pairs/triples.

>   * Add conflicts for multilib development packages.
>  
> diff -Nru glibc-2.24/debian/control.in/amd64 
> glibc-2.24/debian/control.in/amd64
> --- glibc-2.24/debian/control.in/amd642017-06-18 16:13:52.0 
> +0200
> +++ glibc-2.24/debian/control.in/amd642017-07-31 13:03:42.0 
> +0200
> @@ -16,6 +16,15 @@
>  Depends: libc6-amd64 (= ${binary:Version}), libc6-dev (= ${binary:Version}), 
> ${misc:Depends}
>  Recommends: gcc-multilib
>  Provides: lib64c-dev
> +Conflicts: libc6-dev-i386,
> + libc6-dev-mips32,
> + libc6-dev-mips64,
> + libc6-dev-mipsn32,
> + libc6-dev-powerpc,
> + libc6-dev-ppc64,
> + libc6-dev-sparc,
> + libc6-dev-sparc64,
> + libc6-dev-x32
>  Build-Profiles: 
>  Description: GNU C Library: 64bit Development Libraries for AMD64
>   Contains the symlinks and object files needed to compile and link programs

If libc6-dev-amd64:i386 conflicts with libc6-dev-x32:i386, how do you
plan to get a package like gcc-7-multilib, which depends on both
packages to be kept installable?

Of course libc6-dev-x32:i386 can be dropped from the conflicts list, but
it defeats the purpose of your patch as on amd64 libc6-dev-x32 and
libc6-dev-amd64 will be failing to install on amd64 because of conflicts
in /usr/include.

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

Processed: Re: Bug#870257: Add conflicts for multilib development packages

[Debian Bug Tracking System]

Processing control commands:

> tag -1 - patch
Bug #870257 [src:glibc] Add conflicts for multilib development packages
Removed tag(s) patch.

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

Bug#882794: glibc: Please backport fix for assertion failure in posix_spawn()

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.24-11+deb9u1
Severity: important
Tags: patch upstream

Hello!

With glibc 2.25, an upstream change was introduced with causes an
assertion failure on current versions of QEMU:

dpkg: warning: ignoring pre-dependency problem!
Preparing to unpack .../archives/bash_4.4-5_m68k.deb ...
preinst: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 
0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
dpkg: error processing archive /var/cache/apt/archives/bash_4.4-5_m68k.deb 
(--unpack):
 new bash package pre-installation script subprocess was killed by signal 
(Aborted)
 Selecting previously unselected package bsdutils.
 dpkg: regarding .../bsdutils_1%3a2.30.2-0.1_m68k.deb containing bsdutils, 
pre-dependency problem:
  bsdutils pre-depends on libsystemd0
libsystemd0 is not installed.

This was introduced with [1] and reported in [2]. A QEMU bug report
has also been opened [3]. I'm currently rebuilding glibc for m68k with
the attached patch which should fix the issue. Would be great if it
could be included in one of the next uploads provided that it fixes
the issue which I am going to find out soon.

Adrian

> [1] 
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4b4d4056bb154603f36c6f8845757c1012758158;hp=8d3bd947483f50b57aee7c35c07dc1927d6e8a27
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22273
> [3] https://bugs.launchpad.net/qemu/+bug/1673976

--
  .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix improper assert in Linux posix_spawn (BZ#22273)
 Fixes assertion failure on qemu-user.
 .
Origin: upstream
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22273
Last-Update: 2017-11-26

--- glibc-2.25.orig/sysdeps/unix/sysv/linux/spawni.c
+++ glibc-2.25/sysdeps/unix/sysv/linux/spawni.c
@@ -17,7 +17,6 @@
.  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -266,7 +265,6 @@ __spawni_child (void *arguments)
   __sigprocmask (SIG_SETMASK, (attr->__flags & POSIX_SPAWN_SETSIGMASK)
 ? >__ss : >oldmask, 0);
 
-  args->err = 0;
   args->exec (args->file, args->argv, args->envp);
 
   /* This is compatibility function required to enable posix_spawn run
@@ -337,7 +335,7 @@ __spawnix (pid_t * pid, const char *file
 
   /* Child must set args.err to something non-negative - we rely on
  the parent and child sharing VM.  */
-  args.err = -1;
+  args.err = 0;
   args.file = file;
   args.exec = exec;
   args.fa = file_actions;
@@ -360,12 +358,26 @@ __spawnix (pid_t * pid, const char *file
   new_pid = CLONE (__spawni_child, STACK (stack, stack_size), stack_size,
   CLONE_VM | CLONE_VFORK | SIGCHLD, );
 
+  /* It needs to collect the case where the auxiliary process was created
+ but failed to execute the file (due either any preparation step or
+ for execve itself).  */
   if (new_pid > 0)
 {
+  /* Also, it handles the unlikely case where the auxiliary process was
+terminated before calling execve as if it was successfully.  The
+args.err is set to 0 as default and changed to a positive value
+only in case of failure, so in case of premature termination
+due a signal args.err will remain zeroed and it will be up to
+caller to actually collect it.  */
   ec = args.err;
-  assert (ec >= 0);
-  if (ec != 0)
- __waitpid (new_pid, NULL, 0);
+  if (ec > 0)
+   /* There still an unlikely case where the child is cancelled after
+  setting args.err, due to a positive error value.  Also due a
+  possible pid reuse race (where the kernel allocated the same pid
+  to unrelated process) we need not to undefinitely hang expecting
+  an invalid pid.  In both cases an error is returned to the
+  caller.  */
+   __waitpid (new_pid, NULL, WNOHANG);
 }
   else
 ec = -new_pid;

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-26 09:21, Bastian Blank wrote:
> On Sun, Nov 26, 2017 at 09:13:52AM +0100, Bastian Blank wrote:
> > It seems that ldconfig does not force the collation to a value that
> > would make it use the claimed sorting.

This is indeed correct, that said it's not true for the locale of the
reporter, ie cz_CZ.utf8, so I am afraid there is another bug there,
probably related though.

> ldconfig:
> -> setlocale (LC_ALL, "")

This is done for ldconfig to be able to display localized messages.

> -> glob()
>-> qsort(strcoll-equiv)
> 
> Other occurances of similar bugs: https://bugs.debian.org/600310

I see two way of fixing this issue:
- make sure the directories are sorted in a locale independent way
- update debian/patches/any/local-ldconfig-multiarch.diff to add
  standard search paths before the configured ones.

While this is definitely a bug, I still believe that we should not allow
the installation of libc6:amd64 and libc6-amd64:i386 together and that
gcc should be able to use the multiarch library as an alternative to the
multilib one, so that users are not forced to install two almost
identical libc on their systems, with the consequences we see.

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

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Bastian Blank]

On Sun, Nov 26, 2017 at 09:13:52AM +0100, Bastian Blank wrote:
> It seems that ldconfig does not force the collation to a value that
> would make it use the claimed sorting.

ldconfig:
-> setlocale (LC_ALL, "")
-> glob()
   -> qsort(strcoll-equiv)

Other occurances of similar bugs: https://bugs.debian.org/600310

Bastian

-- 
One does not thank logic.
-- Sarek, "Journey to Babel", stardate 3842.4

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Bastian Blank]

On Sun, Nov 26, 2017 at 01:03:58AM +0100, Aurelien Jarno wrote:
> I am still unable to reproduce this problem. On my system
> lib/x86_64-linux-gnu/ is preferred over lib64. ldconfig uses glob to to
> interpret the "*.conf" in /etc/ld.so.conf, so the files are sorted
> alphabetically and thus the zz_amd64-biarch-compat.conf should appear
> last.
 
There exists locales where this claim is false:

| $ LC_COLLATE=et_EE.UTF-8 ls -al /etc/ld.so.conf.d
| total 20
| drwxr-xr-x  2 root root 4096 Nov 26 08:07 .
| drwxr-xr-x 82 root root 4096 Nov 21 09:34 ..
| -rw-r--r--  1 root root   38 Jun 26  2016 fakeroot-x86_64-linux-gnu.conf
| -rw-r--r--  1 root root   44 Mär 20  2016 libc.conf
| -rw-r-  1 root root0 Nov 26 08:07 zz.conf
| -rw-r--r--  1 root root   68 Jul 26  2016 x86_64-linux-gnu.conf

It seems that ldconfig does not force the collation to a value that
would make it use the claimed sorting.

Bastian

-- 
Actual war is a very messy business.  Very, very messy business.
-- Kirk, "A Taste of Armageddon", stardate 3193.0