Bug#614708: libc6 could just Recommends libc-bin
tag 614708 + wontfix thanks On Tue, Feb 22, 2011 at 04:03:18PM -0800, Josh Triplett wrote: Package: libc6 Version: 2.11.2-11 Severity: wishlist Looking carefully at the contents of libc-bin, it appears that libc6 could just Recommends libc-bin, rather than having a Depends on it. Specifically, taking the contents of libc-bin piece by piece: /etc/bindresvport.blacklist Not required to run programs, just a workaround for a conflict between RPC and a handful of services. /etc/ld.so.conf.d/libc.conf Just adds /usr/local/lib; not a required component of a system. /etc/gai.conf While it is true, not having a dependency between the two makes very difficult to handle the Consists entirely of commented-out defaults. /sbin/ldconfig Maintaining ld.so.cache makes the system run faster, but the system will run without it. The only caveat: any library packages would need to only run it if it exists. Given that half of the packages does that in the postinst, that's a lot to change. Until they are all changed, that just makes this change totally impossible. /usr/bin/catchsegv Ok /usr/bin/getconf Required by POSIX /usr/bin/getent /usr/bin/iconv Required by POSIX /usr/bin/ldd Ok /usr/bin/localedef /usr/bin/locale Required by POSIX /usr/bin/tzselect /usr/bin/rpcinfo /usr/bin/zdump Ok None required for a running system, just generally useful. As said above, most of them are need for POSIX compliance, they have to stay on the system. /usr/lib /usr/lib/pt_chown Not required for a running system, just useful. Ok /usr/sbin/iconvconfig /usr/sbin/zic Ok Not required for a running system, just useful. /usr/share/man/* Helpful documentation but not required to run. Ok /usr/share/doc/libc-bin/* Helpful documentation but not required to run. Ok /usr/share/lintian/overrides/libc-bin Obviously not required. Ok So, in general, nothing in libc-bin has to exist for the system to work, and only one thing (ldconfig) needs some extra care to make sure the system can cope without its presence. Half of the tool are necessary for POSIX compliance. Also libc-bin 2.13 now provides a C.UTF-8 locale for Debian Policy compliance. While I agree it's possible to run a half-broken system without libc-bin, that doesn't mean you just want it to be recommended. libc-bin is less than 750kB when installed, if you really want to gain space, I would suggest you to start by looking at essential packages (or their dependencies) taking a few MB. That's simply a wontfix for now, just to leave you the right to answer. Otherwise I would just close this bug. Seriously if you want to make so small system that you don't want to install libc-bin, just have a look at emdebian or other solutions. On the flipside, though, libc-bin probably needs Depends: libc6, since it includes various programs that need libc6. (Related to this: neither libc6 nor libc-bin has Essential: yes, so programs already can't count on them without a dependency.) All that said, I agree that we should drop the dependency from libc6 to libc-bin (and add the dependency in the other direction), and just make libc-bin essential. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20110223195601.gb21...@volta.aurel32.net
Processed: Re: Bug#614708: libc6 could just Recommends libc-bin
Processing commands for cont...@bugs.debian.org: tag 614708 + wontfix Bug #614708 [libc6] libc6 could just Recommends libc-bin Added tag(s) wontfix. thanks Stopping processing here. Please contact me if you need assistance. -- 614708: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614708 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.129849099513118.transcr...@bugs.debian.org
RFC: use of shlib bump for libc dependency on new multiarch directories?
Dear release team, Although the paths in which libraries will ultimately be installed for multiarch is not yet entirely settled, one thing that is clear is that on i386, we almost certainly will not be using the path which has been enabled in glibc up to now, namely /lib/i486-linux-gnu.[1] We will most likely be using either /lib/i386-linux-gnu or /lib/x86-linux-glibc instead, depending on the outcome of various ongoing discussions; and libraries installing to either one of these paths are going to need to make sure the new libc is installed first, or they'll instantly become unavailable on upgrade. We can handle this one of two ways. We can either bump the minimal dependency of *all* packages against libc, by adjusting shlibs/symbols in the eglibc package; or we can make adding the dependency a part of the standard library multiarchification recipe. The first approach means that every library on the system will depend on the new libc as soon as it's rebuilt, whether or not it's installed to the multiarch library path. However, my handwavy estimate is that by the time wheezy is out we should have better than 80% library coverage with multiarch, so maybe that's not an issue at all. But it also may not be sufficient to ensure smooth upgrades either; dependencies don't guarantee unpack order, so what happens if a library needed by apt+dpkg to finish the unpack of the new libc gets disappeared out of the system path before libc itself gets unpacked? do we need to special-case the addition of pre-depends to any libraries that are needed by the package manager? Do we want pre-depends for *all* libraries, just in case? The second approach is going to be more error prone; it's one more step that has to be added to the process for converting a library package to multiarch, which means it's one more step that maintainers can forget and one of the easiest to go unnoticed for long periods in unstable/testing. We could mitigate this somewhat by having debhelper do something here by default when it sees multiarch paths in use, but that won't give us 100% archive coverage either (and oh, how the work I've been doing on my multiarch proof-of-concept bootstrap makes me wish it would :-). It also isn't viable anywhere we decide we need Pre-Depends, since most packages simply won't have a substitution in place for Pre-Depends that debhelper can hook into. Since this is an issue with high potential impact on squeeze-wheezy upgrades, Aurélien suggested that we solicit input from the release team here. Do you guys have any recommendations on how we should handle this, or any other concerns that I may have overlooked? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] i486 is an arbitrary name that happens to correspond to the base instruction set that was in use on Debian at the time multiarch was first formulated, but it doesn't match the current base instruction set on Debian (i586) or Ubuntu (i686), doesn't match the directory configured in the current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look weird to other distributions when we try to talk to them about this since they've also long since moved to i686 as their base compatibility. signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 01:52:35PM -0800, Steve Langasek wrote: [1] i486 is an arbitrary name that happens to correspond to the base instruction set that was in use on Debian at the time multiarch was first formulated, but it doesn't match the current base instruction set on Debian (i586) or Ubuntu (i686), doesn't match the directory configured in the current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look weird to other distributions when we try to talk to them about this since they've also long since moved to i686 as their base compatibility. Sorry to skip multiarch[1], but I need to comment on this one. Isn't the base instruction set still i486? I still haven't found any practical example of a change of ISA between i486 and i586. For all means they seem to be equivalent, with i686 being the next break. The only exception that might be is that 486 can actually lack FPUs, while Pentiums don't. But for all practically relevant cases I'd assume that they don't, and I'd be surprised if we'd cater for that. Out of curiosity: Where will optimized libraries be placed? Kind regards Philipp Kern [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 11:15:02PM +0100, Philipp Kern wrote: On Wed, Feb 23, 2011 at 01:52:35PM -0800, Steve Langasek wrote: [1] i486 is an arbitrary name that happens to correspond to the base instruction set that was in use on Debian at the time multiarch was first formulated, but it doesn't match the current base instruction set on Debian (i586) or Ubuntu (i686), doesn't match the directory configured in the current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look weird to other distributions when we try to talk to them about this since they've also long since moved to i686 as their base compatibility. Sorry to skip multiarch[1], but I need to comment on this one. Isn't the base instruction set still i486? I still haven't found any practical example of a change of ISA between i486 and i586. For all means they seem to be equivalent, with i686 being the next break. The only exception that might be is that 486 can actually lack FPUs, while Pentiums don't. But for all practically relevant cases I'd assume that they don't, and I'd be surprised if we'd cater for that. Ah, I don't know the details; I take this as gospel from the GCC maintainers that There Are Differences. Perhaps the differences are only optimization rather than compatibility; but regardless, given that most distros use i586-linux-gnu or i686-linux-gnu as their toolchain triplet, i486-linux-gnu is an odd bird to propose to standardize on. Out of curiosity: Where will optimized libraries be placed? Multiarch can be combined transparently with hwcaps; so you can have /lib/i386-linux-gnu/i686/cmov/, /lib/alpha-linux-gnu/ev67/, etc. Multiarch also does not require that the libraries installed to the base directory are backwards-compatible with anything that you don't care about, so it's fine to have i686 libraries directly in /lib/i386-linux-gnu on a distro whose baseline is i686, while they're in a hwcap directory for another distro. [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). Ok. I think that's certainly going to be more manageable than trying to add pre-depends to everything, anyway. Any concerns about bumping the dependency for all libraries via dpkg-shlibdeps? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
* Steve Langasek (vor...@debian.org) [110223 22:53]: We can handle this one of two ways. We can either bump the minimal dependency of *all* packages against libc, by adjusting shlibs/symbols in the eglibc package; or we can make adding the dependency a part of the standard library multiarchification recipe. Or third, we could add the new path to eglibc in a stable point update and into unstable, and either a) have a virtual package provided, and for the core utilities pre-depend on that virtual package (so that user systems are never broken by the upgrade), or b) don't multiarch the core utilities for the next stable release. Andi -- 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/20110223230318.gy15...@mails.so.argh.org
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 02:29:26PM -0800, Steve Langasek wrote: [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). Ok. I think that's certainly going to be more manageable than trying to add pre-depends to everything, anyway. Any concerns about bumping the dependency for all libraries via dpkg-shlibdeps? What's the timeframe for eglibc to be ready? If it's able to migrate to testing fairly soon and as it's just shlibdeps and as it's at the beginning of the cycle, I don't really see any. It should not be the primary blocker for migration for weeks, though. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#614882: {get,set}timeofday declared with incorrect '__nonnull' attribute
Package: libc6-dev
Version: 2.11.2-11
Severity: normal
On Linux it is valid to call {get,set}timeofday() with a null timeval
pointer and non-null timezone pointer. This will get or set the
kernel's local time offset, which is used for converting timestamps on
brain-dead filesystems like VFAT. settimeofday(NULL, tz) is also used
to fix the system time during the boot process if the RTC is set to
local time for compatibility with a similarly brain-dead operating
system.
Ben.
-- System Information:
Debian Release: wheezy/sid
APT prefers oldstable-proposed-updates
APT policy: (500, 'oldstable-proposed-updates'), (500, 'unstable'), (1,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.37-1-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 libc6-dev depends on:
ii libc-dev-bin 2.11.2-11 Embedded GNU C Library: Developmen
ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib
ii linux-libc-dev2.6.37-1 Linux support headers for userspac
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.4.5-2 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-29 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.5-4The GNU C compiler
ii gcc-4.4 [c-compiler] 4.4.5-12 The GNU C compiler
Versions of packages libc6-dev suggests:
ii glibc-doc 2.11.2-11 Embedded GNU C Library: Documentat
ii manpages-dev 3.27-1 Manual pages about using GNU/Linux
-- no debconf information
--
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/20110223230700.21441.37372.reportbug@localhost
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
* Steve Langasek (vor...@debian.org) [110223 23:29]: Ah, I don't know the details; I take this as gospel from the GCC maintainers that There Are Differences. Perhaps the differences are only optimization rather than compatibility; but regardless, given that most distros use i586-linux-gnu or i686-linux-gnu as their toolchain triplet, i486-linux-gnu is an odd bird to propose to standardize on. AFAIUI, we need the atomic locking the i386 and some early i486 don't have, we need an co-processor that not all i486 have (but that's an kernel issue - the math emulation code is instant root exploitable, and therefor not part of the kernel code), and that's it. However, we optimize for i586 IIRC. [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). Ok. I think that's certainly going to be more manageable than trying to add pre-depends to everything, anyway. Any concerns about bumping the dependency for all libraries via dpkg-shlibdeps? Yes, I don't like libary bumps, because that's annoying if we need backports of all packages just to make dpkg happy (and the other package would still work, but just dpkg would complain). But well, maybe still the best. Andi -- 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/20110223230957.gz15...@mails.so.argh.org
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote: we almost certainly will not be using the path which has been enabled in glibc up to now, namely /lib/i486-linux-gnu. I'd heard that, and was somewhat concerned about whether that'd block multiarch for yet another release cycle; I'm glad to hear it isn't. One possibility that occurred to me is adding a Pre-Depends on a new package (multiarch-enabler, perhaps) which is arch:any and just contains this file: # /etc/ld.so.conf.d/x86-linux-glibc.conf /lib/x86-linux-glibc /usr/lib/x86-linux-glibc Am I right in thinking that (probably only needed for the native architecture, even) would be enough to bootstrap support for the multiarch paths in the native architecture's linker far enough to perform the upgrade? A future libc6 could even Replace it or something. (It'd be a bit subtle by being transitively Essential, though.) S -- 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/20110223225551.ga17...@reptile.pseudorandom.co.uk
Bug#614883: Does not set local time offset for kernel
Package: tzdata
Version: 2011b-2
Severity: normal
The kernel maintains a local time offset which is used for some stupid
filesystems that are defined to store local times in their timestamps.
The offset is initialised by hwclock which is invoked at boot time by
/etc/init/hwclockfirst.sh.
The offset should also be updated whenever the system time zone is
reconfigured. This can be done by code along the following lines:
#define _BSD_SOURCE
#define _XOPEN_SOURCE
#include time.h
#include sys/time.h
int main(void)
{
struct timezone tz;
tzset();
tz.tz_minuteswest = timezone / 60;
tz.tz_dsttime = 0;
if (settimeofday(NULL, tz)) {
perror(settimeofday);
return 1;
}
return 0;
}
The local time offset should also be updated when DST begins and ends,
but this would be substantially harder to arrange.
Ben.
-- System Information:
Debian Release: wheezy/sid
APT prefers oldstable-proposed-updates
APT policy: (500, 'oldstable-proposed-updates'), (500, 'unstable'), (1,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.37-1-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 tzdata depends on:
ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy
tzdata recommends no packages.
tzdata suggests no packages.
-- debconf information excluded
--
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/20110223231003.20465.2158.reportbug@localhost
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 10:55:51PM +, Simon McVittie wrote: On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote: we almost certainly will not be using the path which has been enabled in glibc up to now, namely /lib/i486-linux-gnu. I'd heard that, and was somewhat concerned about whether that'd block multiarch for yet another release cycle; I'm glad to hear it isn't. One possibility that occurred to me is adding a Pre-Depends on a new package (multiarch-enabler, perhaps) which is arch:any and just contains this file: # /etc/ld.so.conf.d/x86-linux-glibc.conf /lib/x86-linux-glibc /usr/lib/x86-linux-glibc Am I right in thinking that (probably only needed for the native architecture, even) would be enough to bootstrap support for the multiarch paths in the native architecture's linker far enough to perform the upgrade? A future libc6 could even Replace it or something. (It'd be a bit subtle by being transitively Essential, though.) Currently I don't see any advantage of doing it this way, rather than having libc provide this file directly and have affected package pre-depend on libc. The only reason we might consider a separate binary package closer to release is if we wind up with circular dependencies that break upgrades from squeeze; so this is a good idea to keep in our back pocket as a fallback plan, but until it's shown to be needed I think it's unnecessary complexity that we should avoid. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Thu, Feb 24, 2011 at 12:03:18AM +0100, Andreas Barth wrote: * Steve Langasek (vor...@debian.org) [110223 22:53]: We can handle this one of two ways. We can either bump the minimal dependency of *all* packages against libc, by adjusting shlibs/symbols in the eglibc package; or we can make adding the dependency a part of the standard library multiarchification recipe. Or third, we could add the new path to eglibc in a stable point update and into unstable, and either a) have a virtual package provided, and for the core utilities pre-depend on that virtual package (so that user systems are never broken by the upgrade), or b) don't multiarch the core utilities for the next stable release. b) doesn't help. This is about libraries changing location and making sure that they're on the runtime linker's path; this will affect every core library on the system and there's no way to except the core /utilities/ from that. (If you want a multiarch X stack this cycle, you need a multiarch zlib. Guess what depends on zlib? :) A virtual package is a good idea, though - in fact, it's such a good idea that I remember now we discussed this back at DebConf and I'd subsequently forgotten about it. Thanks for jogging my memory! :) Yes, whether or not we add support in a stable point release, I think that if we don't go the dpkg-shlibdeps route we should use a 'multiarch' or 'multiarch-foo' virtual package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#614892: libc6: please apply upstream qsort() crash fix
Package: libc6 Version: 2.11.2-10 I noticed that msgmerge was randomly and intermittently dying with SIGFPE on multiple systems of mine. When I examined the core file, I saw that it was dying in qsort_r(). Some detective work showed that this was the following bug fixed in upstream glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=11655 with the following commit: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fb88ac72c2dcbbd979c8798e4ea497818bb3e171 Since it makes some threaded programs crash randomly, it'd be nice to get this fixed. Thanks, Ben. -- Ben Pfaff http://benpfaff.org -- 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/87k4gqjl3n@blp.benpfaff.org
Bug#614708: libc6 could just Recommends libc-bin
On Wed, Feb 23, 2011 at 08:56:01PM +0100, Aurelien Jarno wrote: On Tue, Feb 22, 2011 at 04:03:18PM -0800, Josh Triplett wrote: Package: libc6 Version: 2.11.2-11 Severity: wishlist Looking carefully at the contents of libc-bin, it appears that libc6 could just Recommends libc-bin, rather than having a Depends on it. Specifically, taking the contents of libc-bin piece by piece: /etc/bindresvport.blacklist Not required to run programs, just a workaround for a conflict between RPC and a handful of services. /etc/ld.so.conf.d/libc.conf Just adds /usr/local/lib; not a required component of a system. /etc/gai.conf While it is true, not having a dependency between the two makes very difficult to handle the Only if you want to customize it. Consists entirely of commented-out defaults. /sbin/ldconfig Maintaining ld.so.cache makes the system run faster, but the system will run without it. The only caveat: any library packages would need to only run it if it exists. Given that half of the packages does that in the postinst, that's a lot to change. Until they are all changed, that just makes this change totally impossible. Fair enough; that does seem like the biggest issue. Would you consider this change if those packages did so? Most packages don't do so by hand, so fixing the various package-building helper packages would get most of the way there. (Also briefly entertaining the notion of having some kind of divertable ldconfig - /bin/true link. :) There's also the long-standing discussion about triggerizing ldconfig, though I realize that proves fairly intricate.) /usr/bin/catchsegv Ok /usr/bin/getconf Required by POSIX /usr/bin/getent /usr/bin/iconv Required by POSIX /usr/bin/ldd Ok /usr/bin/localedef /usr/bin/locale Required by POSIX /usr/bin/tzselect /usr/bin/rpcinfo /usr/bin/zdump Ok None required for a running system, just generally useful. As said above, most of them are need for POSIX compliance, they have to stay on the system. I had no idea. That does seem to argue for the Essential: yes you suggest below, in which case reversing the dependency seems like the best solution. So, in general, nothing in libc-bin has to exist for the system to work, and only one thing (ldconfig) needs some extra care to make sure the system can cope without its presence. Half of the tool are necessary for POSIX compliance. Also libc-bin 2.13 now provides a C.UTF-8 locale for Debian Policy compliance. Oh, awesome. I had no idea. Thank you very much, I look forward to that. Any straightforward way for a script (.bashrc, for instance) to detect the existence of C.UTF-8 in order to use it in preference to en_US.UTF-8 if present? While I agree it's possible to run a half-broken system without libc-bin, that doesn't mean you just want it to be recommended. libc-bin is less than 750kB when installed, if you really want to gain space, I would suggest you to start by looking at essential packages (or their dependencies) taking a few MB. That's simply a wontfix for now, just to leave you the right to answer. Otherwise I would just close this bug. Seriously if you want to make so small system that you don't want to install libc-bin, just have a look at emdebian or other solutions. Might you consider moving the manpages to glibc-doc or similar, perhaps? On the flipside, though, libc-bin probably needs Depends: libc6, since it includes various programs that need libc6. (Related to this: neither libc6 nor libc-bin has Essential: yes, so programs already can't count on them without a dependency.) All that said, I agree that we should drop the dependency from libc6 to libc-bin (and add the dependency in the other direction), and just make libc-bin essential. Fair enough. That would prove more convenient, and I'd appreciate it greatly. Thanks, Josh Triplett -- 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/20110224015008.GF6727@feather
Bug#614892: libc6: please apply upstream qsort() crash fix
tags 614892 + upstream patch fixed-upstream fixed 614892 eglibc/2.13-0exp1 quit Ben Pfaff wrote: I noticed that msgmerge was randomly and intermittently dying with SIGFPE on multiple systems of mine. When I examined the core file, I saw that it was dying in qsort_r(). Some detective work showed that this was the following bug fixed in upstream glibc: Fixed by glibc-2.13~39 (Fix race in qsort_r initialization, 2010-12-09). Thanks for a pointer. -- 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/20110224020809.GA7970@elie
Processed: Re: libc6: please apply upstream qsort() crash fix
Processing commands for cont...@bugs.debian.org: tags 614892 + upstream patch fixed-upstream Bug #614892 [libc6] libc6: please apply upstream qsort() crash fix Added tag(s) upstream, fixed-upstream, and patch. fixed 614892 eglibc/2.13-0exp1 Bug #614892 [libc6] libc6: please apply upstream qsort() crash fix Bug Marked as fixed in versions eglibc/2.13-0exp1. quit Stopping processing here. Please contact me if you need assistance. -- 614892: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614892 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.129851331623598.transcr...@bugs.debian.org
Processed: tagging 614892
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 614892 + pending Bug #614892 [libc6] libc6: please apply upstream qsort() crash fix Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 614892: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614892 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.129853046723258.transcr...@bugs.debian.org
r4529 - glibc-package/branches/eglibc-2.13/debian
Author: aurel32 Date: 2011-02-24 06:54:11 + (Thu, 24 Feb 2011) New Revision: 4529 Modified: glibc-package/branches/eglibc-2.13/debian/changelog Log: Add bug number Modified: glibc-package/branches/eglibc-2.13/debian/changelog === --- glibc-package/branches/eglibc-2.13/debian/changelog 2011-02-22 01:02:35 UTC (rev 4528) +++ glibc-package/branches/eglibc-2.13/debian/changelog 2011-02-24 06:54:11 UTC (rev 4529) @@ -12,6 +12,7 @@ - Provide POSIX2008 compliant futimens(). Closes: #563724. - Fix auxilary cache file creation. Closes: 588218. - Fix POSIX2008 compliance. Closes: #610824. +- Fix qsort_r() crashes. Closes: #614892. - Update patches/locale/locale-print-LANGUAGE.diff. - Update patches/localedata/sort-UTF8-first.diff. - Remove patches/localedata/submitted-pt_BR.diff (merged upstream). -- 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/e1psv5b-00035l...@alioth.debian.org
Bug#614708: libc6 could just Recommends libc-bin
On Wed, Feb 23, 2011 at 05:50:08PM -0800, Josh Triplett wrote: Given that half of the packages does that in the postinst, that's a lot to change. Until they are all changed, that just makes this change totally impossible. Fair enough; that does seem like the biggest issue. Would you consider this change if those packages did so? Most packages don't do so by hand, so fixing the various package-building helper packages would get most of the way there. Probably not, I personally don't see the point of changing libc-bin to a recommends. It's going to cause to many problems, for so little gain. (Also briefly entertaining the notion of having some kind of divertable ldconfig - /bin/true link. :) There's also the long-standing discussion about triggerizing ldconfig, though I realize that proves fairly intricate.) /usr/bin/catchsegv Ok /usr/bin/getconf Required by POSIX /usr/bin/getent /usr/bin/iconv Required by POSIX /usr/bin/ldd Ok /usr/bin/localedef /usr/bin/locale Required by POSIX /usr/bin/tzselect /usr/bin/rpcinfo /usr/bin/zdump Ok None required for a running system, just generally useful. As said above, most of them are need for POSIX compliance, they have to stay on the system. I had no idea. That does seem to argue for the Essential: yes you suggest below, in which case reversing the dependency seems like the best solution. So, in general, nothing in libc-bin has to exist for the system to work, and only one thing (ldconfig) needs some extra care to make sure the system can cope without its presence. Half of the tool are necessary for POSIX compliance. Also libc-bin 2.13 now provides a C.UTF-8 locale for Debian Policy compliance. Oh, awesome. I had no idea. Thank you very much, I look forward to that. Any straightforward way for a script (.bashrc, for instance) to detect the existence of C.UTF-8 in order to use it in preference to en_US.UTF-8 if present? I have nothing ready, but you can probably try to set the locale, and look for errors. While I agree it's possible to run a half-broken system without libc-bin, that doesn't mean you just want it to be recommended. libc-bin is less than 750kB when installed, if you really want to gain space, I would suggest you to start by looking at essential packages (or their dependencies) taking a few MB. That's simply a wontfix for now, just to leave you the right to answer. Otherwise I would just close this bug. Seriously if you want to make so small system that you don't want to install libc-bin, just have a look at emdebian or other solutions. Might you consider moving the manpages to glibc-doc or similar, perhaps? No, that's against Policy 12.1. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20110224073628.gh6...@hall.aurel32.net
