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 y
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
===
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
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 qsor
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
> wor
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 l
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:
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 c
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
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 offs
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
* 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
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. se
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 lib
* 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 multiarc
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
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) o
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 wil
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
D
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.
> Sp
20 matches
Mail list logo
