Bug#722348: libc6: compile without --enable-lock-elision=no

2016-08-11 Thread Fabio Andrijauskas 
Package: libc6
Version: 2.19-18+deb8u4
Followup-For: Bug #722348



-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/56 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:4.9.2-10

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.56
pn  glibc-doc  
ii  locales2.19-18+deb8u4

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = "en_US.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
  glibc/restart-services:
  glibc/restart-failed:
  libraries/restart-without-asking: false
  glibc/disable-screensaver:
  glibc/upgrade: true


Was necessary to recompile glibc with --enable-lock-elision=no, i believe is a 
bug on intel xeon microcode.

The backtrace from pbs_sever

#0  __lll_unlock_elision (lock=0x5100480, private=0) at 
../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
#1  0x00495a0d in unlock_ji_mutex (pjob=0x5115fd0, id=0x510160 
 "svr_enquejob", 
msg=0x50eb85 "1", logging=0) at svr_jobfunc.c:4011
#2  0x0048f31e in svr_enquejob (pjob=0x5115fd0, has_sv_qs_mutex=1, 
prev_job_id=0x0, have_reservation=false, being_recovered=true)
at svr_jobfunc.c:421
#3  0x0045340a in pbsd_init_reque (pjob=0x5115fd0, change_state=0) at 
pbsd_init.c:2785
#4  0x00452de1 in pbsd_init_job (pjob=0x5115fd0, type=1) at 
pbsd_init.c:2623
#5  0x004513f9 in handle_job_recovery (type=1) at pbsd_init.c:1764
#6  0x00451f10 in handle_job_and_array_recovery (type=1) at 
pbsd_init.c:2061
#7  0x004525be in pbsd_init (type=1) at pbsd_init.c:2277
#8  0x004591ff in main (argc=2, argv=0x7fffdec8) at pbsd_main.c:1883

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

2016-08-11 Thread Vincent Lefevre 
On 2016-08-11 23:33:30 +0200, Vincent Lefevre wrote:
[...]
> I wondered whether this was a bug from gnupg, until I tried:
> 
> zira:~> ping keys.gnupg.net
> ping: keys.gnupg.net: Temporary failure in name resolution
> zsh: exit 2 ping keys.gnupg.net
> 
> which I always get. Ditto with telnet.
[...]

I'd add that there's no such name resolution failure under Android
(same network, same name server 192.168.0.1).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

2016-08-11 Thread Vincent Lefevre 
Package: libc6
Version: 2.23-4
Severity: normal

I always get the folloing error on this machine:

zira:~> gpg --keyserver-options verbose,debug --keyserver hkp://keys.gnupg.net 
--recv-key 
gpg: requesting key  from hkp server keys.gnupg.net
gpgkeys: curl version = GnuPG curl-shim
* HTTP proxy is "null"
* HTTP URL is 
"http://keys.gnupg.net:11371/pks/lookup?op=get&options=mr&search=0x";
* SRV tag is "pgpkey-http": host and port may be overridden
* HTTP auth is "null"
* HTTP method is GET
?: keys.gnupg.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: keyserver unreachable
gpg: keyserver communications error: public key not found
gpg: keyserver receive failed: public key not found
zsh: exit 2 gpg --keyserver-options verbose,debug --keyserver 
hkp://keys.gnupg.net  

even though the host exists:

zira:~> host keys.gnupg.net
keys.gnupg.net is an alias for pool.sks-keyservers.net.
pool.sks-keyservers.net has address 5.9.50.141
pool.sks-keyservers.net has address 91.143.92.136
pool.sks-keyservers.net has address 108.18.103.116
pool.sks-keyservers.net has address 131.155.141.70
pool.sks-keyservers.net has address 85.10.205.199
pool.sks-keyservers.net has address 163.172.29.20
pool.sks-keyservers.net has address 104.236.209.43
pool.sks-keyservers.net has address 84.200.66.125
pool.sks-keyservers.net has address 5.9.143.170
pool.sks-keyservers.net has address 185.95.216.79
pool.sks-keyservers.net has IPv6 address 2607:5300:60:490f:1::19
pool.sks-keyservers.net has IPv6 address 2604:a880:800:10::227:e001
pool.sks-keyservers.net has IPv6 address 2001:41d0:2:55c2:5054:ff:fe12:3
pool.sks-keyservers.net has IPv6 address 2a01:4f8:a0:4024::2:0
pool.sks-keyservers.net has IPv6 address 2a02:180:a:65:2456:6542:1101:1010
pool.sks-keyservers.net has IPv6 address 2a01:4f8:d16:24c1::2
pool.sks-keyservers.net has IPv6 address 2a01:7c8:aabc:45a:5054:ff:fe9b:59a3
pool.sks-keyservers.net has IPv6 address 2001:470:d:367::555
pool.sks-keyservers.net has IPv6 address 2a01:4f8:161:4283:1000::203
pool.sks-keyservers.net has IPv6 address 2001:4c80:40:628:5c70:d1ff:fe44:1424

This seems to be a known issue:

  https://lists.gnupg.org/pipermail/gnupg-users/2015-October/054532.html

(searching for "keys.gnupg.net: Host not found" gives much more
examples).

I wondered whether this was a bug from gnupg, until I tried:

zira:~> ping keys.gnupg.net
ping: keys.gnupg.net: Temporary failure in name resolution
zsh: exit 2 ping keys.gnupg.net

which I always get. Ditto with telnet.

An excerpt of the strace for gnupg:

30419 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
30419 socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
30419 connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.0.1")}, 16) = 0
30419 poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
30419 sendmmsg(4, {{{msg_name(0)=NULL, 
msg_iov(1)=[{"\343\376\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\1\0\1", 32}], 
msg_controllen=0, msg_flags=0}, 32}, {{msg_name(0)=NULL, 
msg_iov(1)=[{"'J\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\34\0\1", 32}], 
msg_controllen=0, msg_flags=0}, 32}}, 2, MSG_NOSIGNAL) = 2
30419 poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
30419 ioctl(4, FIONREAD, [500]) = 0
30419 recvfrom(4, 
"'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 
[16]) = 500
30419 close(4)  = 0
30419 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
30419 connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
30419 close(4)  = 0
30419 socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
30419 connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.0.1")}, 16) = 0
30419 poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
30419 sendmmsg(4, {{{msg_name(0)=NULL, 
msg_iov(1)=[{"\227\30\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\1\0\1", 32}], 
msg_controllen=0, 
msg_flags=MSG_RST|MSG_ERRQUEUE|MSG_NOSIGNAL|MSG_MORE|MSG_WAITFORONE|MSG_BATCH|MSG_FASTOPEN|0x8c7a},
 32}, {{msg_name(0)=NULL, 
msg_iov(1)=[{"\347\360\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\34\0\1", 32}], 
msg_controllen=0, 
msg_flags=MSG_OOB|MSG_PEEK|MSG_CTRUNC|MSG_WAITALL|MSG_FIN|MSG_SYN|MSG_CONFIRM|MSG_WAITFORONE|MSG_BATCH|MSG_FASTOPEN|0x85b0},
 32}}, 2, MSG_NOSIGNAL) = 2
30419 poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
30419 ioctl(4, FIONREAD, [500]) = 0
30419 recvfrom(4, 
"\347\360\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 
[16]) = 500
30419 close(4)

Bug#834083: libc-bin: essential tag

2016-08-11 Thread Aurelien Jarno 
On 2016-08-11 22:12, Javier Serrano Polo wrote:
> X-Debbugs-CC: cl...@debian.org, aure...@debian.org, adcon...@0c3.net, 
> sthiba...@debian.org
> 
> El dj 11 de 08 de 2016 a les 21:55 +0200, Aurelien Jarno va escriure:
> > On 2016-08-11 21:32, Javier Serrano Polo wrote:
> > > libc-bin is tagged essential since 2.13-10. Old systems based on Squeeze
> > > can work without libc-bin, with a dpkg that does not require ldconfig.
> > 
> > No they can't. In squeeze, the binaries from libc-bin were included in
> > libc6. The package has been split as part of the switch to multiarch.
> 
> This is not correct:
> https://archive.debian.net/squeeze/libc-bin

Indeed I was wrong. Looking at the history we had to do that in multiple
steps to be able to provide and upgrade path and have libc-bin depends on
libc6 and not the other way around.

This has been done with the following steps:
- libc6 was de facto essential (essential packages depending on it), but
  it was not possible to mark it as essential as it is a library.
- libc-bin has been split from libc6. libc6 got added a dependency on
  libc-bin. libc-bin therefore became de facto essential.
- libc-bin has been marked Essential
- libc6 dropped the dependency on libc-bin. libc-bin added a dependency
  on libc6.

As per policy permission to make libc-bin essential has been asked on
debian-devel. You'll find the mail there:

https://lists.debian.org/debian-devel/2011/07/msg6.html

> > > Could anyone explain why libc-bin is essential?
> > 
> > Because it provides binaries and configuration files essential for the
> > system: ldconfig, getent, ld.so.conf, nsswitch.conf, C.UTF-8 locale, etc.
> 
> These elements are very useful, but a system based on Squeeze can work
> without them. Is there any other reason in a Sid system?

ldconfig is definitely necessary, it is called in all postinst scripts.
If you don't have it, packages fail to configure:

| (squeeze-amd64)root@ohm:~# dpkg-reconfigure libpcre3 ; echo $?
| debconf: unable to initialize frontend: Dialog
| debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
75.)
| debconf: falling back to frontend: Readline
| /var/lib/dpkg/info/libpcre3.postinst: 6: ldconfig: not found
| 127

Further more you can't install a package:

| (squeeze-amd64)root@ohm:~# apt-get install -y dialog
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| The following extra packages will be installed:
|   libncursesw5
| The following NEW packages will be installed:
|   dialog libncursesw5
| 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
| Need to get 684 kB of archives.
| After this operation, 2367 kB of additional disk space will be used.
| Get:1 http://localhost/debian-archive/ squeeze/main libncursesw5 amd64 
5.7+20100313-5 [390 kB]
| Get:2 http://localhost/debian-archive/ squeeze/main dialog amd64 
1.1-20100428-1 [295 kB]
| Fetched 684 kB in 0s (63.2 MB/s)
| debconf: delaying package configuration, since apt-utils is not installed
| dpkg: warning: 'ldconfig' not found in PATH or not executable.
| dpkg: 1 expected program not found in PATH or not executable.
| NB: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.
| E: Sub-process /usr/bin/dpkg returned an error code (2)

So it is clearly not correct to say that a squeeze or a sid system can
work without them. And I am sure many of the other binaries are
necessary to make the system working given what the policy says:

| Packages may assume that functionality provided by essential packages
| is always available without declaring explicit dependencies.

Some of them are even required by POSIX.

Regards,
Aurelien

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


signature.asc
Description: Digital signature

Bug#722348: libc6: pbs_server generating general protection

2016-08-11 Thread Fabio Andrijauskas 
Package: libc6
Version: 2.19-18+deb8u4
Followup-For: Bug #722348



-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/56 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/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:4.9.2-10

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.56
pn  glibc-doc  
ii  locales2.19-18+deb8u4

-- debconf information:
  glibc/restart-services:
  libraries/restart-without-asking: false
  glibc/disable-screensaver:
  glibc/upgrade: true
  glibc/restart-failed:


 I am trying to install torque 6.0.2 on Debian 8.5 on a Intel Xeon E5-2620v4. 
However, when i try start pbs_server i returned a segment fault, with gdb:

#1  0x00440ab6 in container::item_container::unlock 
(this=0xb5d900 ) at ../../src/include/container.hpp:537
#2  0x004b787f in mom_hierarchy_handler::nextNode (this=0x4e610c0 
, iter=0x7fff98b8) at mom_hierarchy_handler.cpp:122
#3  0x004b7a7d in mom_hierarchy_handler::make_default_hierarchy 
(this=0x4e610c0 ) at mom_hierarchy_handler.cpp:149
#4  0x004b898d in mom_hierarchy_handler::loadHierarchy (this=0x4e610c0 
) at mom_hierarchy_handler.cpp:433
#5  0x004b8ae8 in mom_hierarchy_handler::initialLoadHierarchy 
(this=0x4e610c0 ) at mom_hierarchy_handler.cpp:472
#6  0x0045262a in pbsd_init (type=1) at pbsd_init.c:2299
#7  0x004591ff in main (argc=2, argv=0x7fffdec8) at pbsd_main.c:1883

dmesg:

 traps: pbs_server[22249] general protection ip:7f9c08a7a2c8 sp:7ffe520b5238 
error:0 in libpthread-2.19.so[7f9c08a69000+18000]

valgrind:

==22381== Memcheck, a memory error detector
==22381== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==22381== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==22381== Command: pbs_server
==22381==
==22381==
==22381== HEAP SUMMARY:
==22381== in use at exit: 18,051 bytes in 53 blocks
==22381==   total heap usage: 169 allocs, 116 frees, 42,410 bytes allocated
==22381==
==22382==
==22382== HEAP SUMMARY:
==22382== in use at exit: 19,755 bytes in 56 blocks
==22382==   total heap usage: 172 allocs, 116 frees, 44,114 bytes allocated
==22382==
==22381== LEAK SUMMARY:
==22381==definitely lost: 0 bytes in 0 blocks
==22381==indirectly lost: 0 bytes in 0 blocks
==22381==  possibly lost: 0 bytes in 0 blocks
==22381==still reachable: 18,051 bytes in 53 blocks
==22381== suppressed: 0 bytes in 0 blocks
==22381== Rerun with --leak-check=full to see details of leaked memory
==22381==
==22381== For counts of detected and suppressed errors, rerun with: -v
==22381== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==22383==
==22383== Process terminating with default action of signal 11 (SIGSEGV)
==22383==  General Protection Fault
==22383==at 0x72192CB: __lll_unlock_elision (elision-unlock.c:33)
==22383==by 0x4E7E1A: unlock_node(pbsnode*, char const*, char const*, int) 
(u_lock_ctl.c:268)
==22383==by 0x4B7A66: mom_hierarchy_handler::make_default_hierarchy() 
(mom_hierarchy_handler.cpp:164)
==22383==by 0x4B898C: mom_hierarchy_handler::loadHierarchy() 
(mom_hierarchy_handler.cpp:433)
==22383==by 0x4B8AE7: mom_hierarchy_handler::initialLoadHierarchy() 
(mom_hierarchy_handler.cpp:472)
==22383==by 0x452629: pbsd_init(int) (pbsd_init.c:2299)
==22383==by 0x4591FE: main (pbsd_main.c:1883)
==22382== LEAK SUMMARY:
==22382==definitely lost: 0 bytes in 0 blocks
==22382==indirectly lost: 0 bytes in 0 blocks
==22382==  possibly lost: 0 bytes in 0 blocks
==22382==still reachable: 19,755 bytes in 56 blocks
==22382== suppressed: 0 bytes in 0 blocks
==22382== Rerun with --leak-check=full to see details of leaked memory
==22382==
==22382== For counts of detected and suppressed errors, rerun with: -v
==22382== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==22383==
==22383== HEAP SUMMARY:
==22383== in use at exit: 325,348 bytes in 186 blocks
==22383==   total heap usage: 297 allocs, 111 frees, 442,971 bytes allocated
==22383==
==22383== LEAK SUMMARY:
==22383==definitely lost: 134 bytes in 6 blocks
==22383==indirectly lost: 28 bytes in 3 blocks
==22383==  possibly lost: 524 bytes in 17 blocks
==22383==still reachable: 324,662 bytes in 160 blocks
==22383== suppressed: 0 bytes in 0 blocks
==22383== Rerun with --leak-check=full to see details of leaked memory
==22383==
==22383== For counts of detected and suppressed errors, rerun with: -v
==22383== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
~

 No other software have this behavior, i tested the ma

Bug#834083: marked as done (libc-bin: essential tag)

2016-08-11 Thread Debian Bug Tracking System 
Your message dated Thu, 11 Aug 2016 21:55:57 +0200
with message-id <20160811195557.ga1...@aurel32.net>
and subject line Re: Bug#834083: libc-bin: essential tag
has caused the Debian Bug report #834083,
regarding libc-bin: essential tag
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.)


-- 
834083: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834083
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc-bin
Version: 2.23-4
Severity: wishlist
X-Debbugs-CC: cl...@debian.org, aure...@debian.org, adcon...@0c3.net, 
sthiba...@debian.org

libc-bin is tagged essential since 2.13-10. Old systems based on Squeeze
can work without libc-bin, with a dpkg that does not require ldconfig.
Could anyone explain why libc-bin is essential?


smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
--- Begin Message ---
On 2016-08-11 21:32, Javier Serrano Polo wrote:
> Package: libc-bin
> Version: 2.23-4
> Severity: wishlist
> X-Debbugs-CC: cl...@debian.org, aure...@debian.org, adcon...@0c3.net, 
> sthiba...@debian.org
> 
> libc-bin is tagged essential since 2.13-10. Old systems based on Squeeze
> can work without libc-bin, with a dpkg that does not require ldconfig.

No they can't. In squeeze, the binaries from libc-bin were included in
libc6. The package has been split as part of the switch to multiarch.

> Could anyone explain why libc-bin is essential?

Because it provides binaries and configuration files essential for the
system: ldconfig, getent, ld.so.conf, nsswitch.conf, C.UTF-8 locale, etc.

Question answered, so I am closing the bug.

Regards,
Aurelien

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


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

Processed: [bts-link] source package glibc

2016-08-11 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package glibc
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian.org (was 
bts-link-de...@lists.alioth.debian.org).
> # remote status report for #833558 (http://bugs.debian.org/833558)
> # Bug title: libc0.3: [hurd] recvmsg: PF_LOCAL sockets and msg_name lead to 
> SIGLOST
> #  * http://sourceware.org/bugzilla/show_bug.cgi?id=20444
> #  * remote status changed: (?) -> RESOLVED
> #  * remote resolution changed: (?) -> FIXED
> #  * closed upstream
> tags 833558 + fixed-upstream
Bug #833558 [libc0.3] libc0.3: [hurd] recvmsg: PF_LOCAL sockets and msg_name 
lead to SIGLOST
Added tag(s) fixed-upstream.
> usertags 833558 + status-RESOLVED resolution-FIXED
There were no usertags set.
Usertags are now: resolution-FIXED status-RESOLVED.
> thanks
Stopping processing here.

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

Bug#833995: gridengine: embedded tcsh copy uses deprecated BSD union wait type

2016-08-11 Thread Aurelien Jarno 
Source: gridengine
Version: 8.1.9+dfsg-1
Severity: important
Tags: patch upstream

Dear Maintainer,

glibc 2.24 has removed the deprecated BSD union wait type if favor of
the POSIX 1 interface using W* macros from  (such as
WEXITSTATUS).

glibc 2.24 is already available in experimental and will plan to upload
it to sid in the next days/weeks. The embedded tcsh copy will fail to
build (see bug#833965), causing in turn gridengine to fail to build from
source. You will find attached a patch taken from upstream tcsh to fix
the issue.

Please also note that this will not break the existing binaries, just
building the package from source.

Thanks,
Aurelien

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

Kernel: Linux 4.6.0-1-amd64 (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)
--- gridengine-8.1.9+dfsg.orig/source/3rdparty/qtcsh/sh.proc.c
+++ gridengine-8.1.9+dfsg/source/3rdparty/qtcsh/sh.proc.c
@@ -47,7 +47,7 @@ RCSID("$tcsh: sh.proc.c,v 3.109 2009/06/
 # define HZ 16
 #endif /* aiws */
 
-#if defined(_BSD) || (defined(IRIS4D) && __STDC__) || defined(__lucid) || defined(linux) || defined(__GNU__) || defined(__GLIBC__)
+#if defined(_BSD) || (defined(IRIS4D) && __STDC__) || defined(__lucid)
 # define BSDWAIT
 #endif /* _BSD || (IRIS4D && __STDC__) || __lucid || glibc */
 #ifndef WTERMSIG

[glibc] branch sid updated (ebd03da -> 5bce109)

2016-08-11 Thread Samuel Thibault 
This is an automated email from the git hooks/post-receive script.

sthibault pushed a change to branch sid
in repository glibc.

  from  ebd03da   Fix recvmsg on PF_LOCAL sockets with msg_name != NULL
   new  5bce109   hurd: Really fix pthread_setcancelstate aliasing

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 |  2 +
 debian/patches/hurd-i386/libpthread_version.diff | 51 ++--
 2 files changed, 31 insertions(+), 22 deletions(-)

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

[glibc] 01/01: hurd: Really fix pthread_setcancelstate aliasing

2016-08-11 Thread Samuel Thibault 
This is an automated email from the git hooks/post-receive script.

sthibault pushed a commit to branch sid
in repository glibc.

commit 5bce109f6d0ae1b591cdd26ec0749b885b1a5d85
Author: Samuel Thibault 
Date:   Thu Aug 11 07:54:44 2016 +

hurd: Really fix pthread_setcancelstate aliasing
---
 debian/changelog |  2 +
 debian/patches/hurd-i386/libpthread_version.diff | 51 ++--
 2 files changed, 31 insertions(+), 22 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 653b41f..67d928c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ glibc (2.23-5) UNRELEASED; urgency=medium
 
   * patches/hurd-i386/git-recvmsg.diff: New patch, fixes recvmsg on PF_LOCAL
 sockets with msg_name != NULL.  Closes: #833558.
+  * hurd-i386/libpthread_version.diff: Really fix pthread_setcancelstate
+aliasing.
 
  -- Samuel Thibault   Tue, 09 Aug 2016 01:45:00 +0200
 
diff --git a/debian/patches/hurd-i386/libpthread_version.diff 
b/debian/patches/hurd-i386/libpthread_version.diff
index f5ef1f5..3965deb 100644
--- a/debian/patches/hurd-i386/libpthread_version.diff
+++ b/debian/patches/hurd-i386/libpthread_version.diff
@@ -117,7 +117,7 @@ once packages are rebuilt against 2.21.
 +#endif
 --- a/libpthread/forward.c
 +++ b/libpthread/forward.c
-@@ -23,20 +23,37 @@
+@@ -20,20 +23,42 @@
  #include 
  #include 
  
@@ -127,30 +127,33 @@ once packages are rebuilt against 2.21.
  struct pthread_functions __libc_pthread_functions attribute_hidden;
  int __libc_pthread_functions_init attribute_hidden;
  
--
++# define FORWARD2_NOVERSION(name, rettype, decl, params, defaction) \
++rettype   
  \
++__##name decl   \
++{   \
++  if (!__libc_pthread_functions_init)   \
++defaction;
  \
++\
++  return PTHFCT_CALL (ptr_##name, params);  \
++} \
+ 
  # define FORWARD2(name, rettype, decl, params, defaction) \
++  FORWARD2_NOVERSION(name, rettype, decl, params, defaction) \
++versioned_symbol (libc, __##name, name, GLIBC_2_21); \
++
++#if SHLIB_COMPAT (libc, GLIBC_2_13, GLIBC_2_21)
++# define FORWARD2_NOCOMPAT(name, rettype, decl, params, defaction) \
  rettype   
  \
 -name decl   \
-+__##name decl   \
++__##name##_2_13 decl\
  {   \
if (!__libc_pthread_functions_init)   \
  defaction;
  \
  \
return PTHFCT_CALL (ptr_##name, params);  \
--}
-+} \
-+versioned_symbol (libc, __##name, name, GLIBC_2_21); \
-+
-+#if SHLIB_COMPAT (libc, GLIBC_2_13, GLIBC_2_21)
+ }
 +# define FORWARD2_COMPAT(name, rettype, decl, params, defaction) \
-+rettype   
  \
-+__##name##_2_13 decl\
-+{   \
-+  if (!__libc_pthread_functions_init)   \
-+defaction;
  \
-+\
-+  return PTHFCT_CALL (ptr_##name, params);  \
-+} \
++  FORWARD2_NOCOMPAT(name, rettype, decl, params, defaction) \
 +compat_symbol (libc, __##name##_2_13, name, GLIBC_2_13_DEBIAN_31);
 +#else
 +# define FORWARD2_COMPAT(name, rettype, decl, params, defaction)
@@ -158,7 +161,7 @@ once packages are rebuilt against 2.21.
  
  /* Same as FORWARD2, only without return.  */
  # define FORWARD_NORETURN(name, rettype, decl, params, defaction) \
-@@ -47,10 +64,19 @@ name decl  
  \
+@@ -47,10 +69,22 @@ name decl  
  \
  defaction;
  \
  \
PTHFCT_CALL (ptr_##name, params); \
@@ -176,10 +179,13 @@ once packages are rebuilt against 2.21.
 -  FORWARD2 (name, int, decl, params, return defretval)
 +  FORWARD2 (name, int, decl, params, return defre