Bug#708504: src:eglibc: drop always satisfied build-dependency sed
Package: src:eglibc Version: 2.17-2 Severity: wishlist Could you drop sed from Build-Depends? Rationale: * Currently it is sed (= 4.0.5-4). The version required is satisfied in old old stable and the package itself is essential. * sed lacks Multi-Arch foreign (#693872), so this makes cross building eglibc a little harder. Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130516054558.ga21...@alf.mars
Bug#667023: 2.15 brings x32 support
block 667023 by 672934 thanks x32 support has been merged into the 2.15 version of glibc. Since carrying x32 patches ourselves seems like a useless waste of time, I mark the x32 bug as being blocked by the new upstream version. Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120527093302.ga11...@alf.mars
Bug#667023: src:eglibc: please provide a binary package for the x32 sub architecture on amd64
Package: src:eglibc Version: 2.13-27 Severity: normal Tags: upstream Blocks: 667005 gcc-4.7 and binutils (2.22) already provide support for the x32 abi. The missing piece to producing x32 binaries is a c library. Patches are available at git://github.com/hjl-tools/glibc.git. An aspect that makes supporting x32 more difficult is that glibc is currently compiled using gcc-4.4 whereas the x32 abi requires at least gcc-4.7. Switching compiler version is not a lightly taken decision and especially not this late in the freeze process. I estimate the diff between 2.13 and 2.13+x32 to be around 202 files changed, 3967 insertions, 218 deletions, and 568 modifications. Due to the ongoing multiarch transition another question should be asked: Should the new package be libc6-x32:amd64 or libc6:x32? Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403130210.GA17099@localhost
Bug#286825: fixed in experimental
tags 286825 = fixed-in-experimental thanks This bug seems to be fixed in experimental. Helmut Grohne signature.asc Description: Digital signature
Bug#310445: More information needed
tag 310445 moreinfo severity 310445 normal thanks There are new versions of glibc available. Could you perhaps recheck whether this bug is reproducible? Furthermore the source for that binary would be helpful if available. Helmut Grohne signature.asc Description: Digital signature
Bug#336843: adduser: removes user from group if /etc/group file ends with :
tags 336843 wontfix thanks Judged that : is the field separator in /etc/group, and that /etc/group might change its format to include more fields, and that a colon is not a valid character in a user name (it would wreck havoc in /etc/passwd), I would expect that perl would consider the : a delimiter here and not return it as part of the group name. perl doesn't parse /etc/group directly, it just calls libc's getgrname, which returns a list as gr_mem (the last entry of which has a trailing colon in this case). There is specified behaviour on invalid passwd files, so whatever glibc does here is within the specs. The function could also segfault at that point. This could maybe reported to the upstream but they'll probably think the same way. Helmut Grohne signature.asc Description: Digital signature
Bug#331405: Accidential activation of nscd is too simple
reassign 331405 libpam-ldap tags 331405 patch thanks It would be libpam-ldap which suggests libnss-ldap in my case. But running apt-rdepends and analyzing it's output suggests that there are 35 packages which depends on nscd in etch today. That's depends as in any of the relationships that drags a package along, either directly or as a consequence of a second or higer order dependency. The package description of nscd clearly states when nscd should be installed. A wrong dependency on nscd is no bug with nscd, but with the software depending on it. Most packages seem to have changed their behaviour since there are only 5 packages in apt-cache rdepends nscd of which at least one is a conflict. So maybe libpam-ldap could suggest nscd instead of recommending it. Otherwise this bug should be tagged wontfix. Helmut Grohne signature.asc Description: Digital signature
Bug#352139: getopt optional arg does not work as documented
tag 352139 -wontfix reassign 352139 manpages-dev thanks Now. This case is difficult. The string hello could also be just a normal filename argument. I think the glibc handles this case correctly and thus mark the bug as wontfix. Actually it would be even better if the documentation could be adapted. Thanks to Aurelien Jarno for pointing this out. Helmut Grohne signature.asc Description: Digital signature
Bug#352139: getopt optional arg does not work as documented
tag 352139 wontfix thanks However, this does not seem to be the case. Actually it works quite similar. When run: [EMAIL PROTECTED]:/tmp$ a.out -a a arg is: (null) Correct behaviour. $ ./a.out -afoo a arg is: foo [EMAIL PROTECTED]:/tmp$ a.out -a hello a arg is: (null) Now. This case is difficult. The string hello could also be just a normal filename argument. I think the glibc handles this case correctly and thus mark the bug as wontfix. Helmut signature.asc Description: Digital signature
Bug#160683: date: long timezone offset sighlently changed
tag 160683 moreinfo thanks On Thu, Sep 12, 2002 at 12:10:48PM -0700, Blars Blarson wrote: Gnu date apperently siglently limits the timezone offset to 23, so the above command will SOMETIMES show todays date instead with no error message. (The SOMETIMES makes this even harder to debug.) This breaks portable and older shell scripts. (I realize there are better ways of doing this using Gnu date, but they don't work on solaris or aix.) Could you be more precise on SOMETIMES and maybe include steps to reproduce? Does it only happen for specific dates? Which? Does it depend on the architecture? Which? Helmut signature.asc Description: Digital signature
Bug#373779: libc6: assertion failure in gconv_db.c with smbclient
Package: libc6 Version: 2.3.999.2-4 Severity: normal # smbclient smbclient: gconv_db.c:232: __gconv_release_step: Assertion `step-__end_fct == ((void *)0)' failed. Aborted # This does not happen with 2.3.6-9. The bug seems to occur while loading shared libraries as different options to smbclient don't change the behaviour and strace shows some library loading stuff before. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libc6 depends on: ii tzdata2006g-2Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
