A conversation with aurel32:
pabs do you know if the glibc team plan to get glibc with dpkg symbol
stuff into lenny, or is that a lenny+1 thing (#462444)?
aurel32 glibc is frozen
aurel32 so that won't happen for lenny
pabs ah, bummer
aurel32 OTOH, I won't see why we should absolutely need that in
Package: libc6-dbg
Version: 2.7-12
Severity: wishlist
libc6-dbg doesn't contain debug symbols for /lib/i686/cmov/libc.so.6 and
other stuff from libc6-i686. It does contain some of the debug symbols
though, but not all of them and unfortunately not the i686 libc ones.
$ dpkg -L libc6-dbg | grep
On Tue, 2008-07-22 at 15:03 +0200, Aurelien Jarno wrote:
Any news on that?
Sorry, didn't receive your earlier email.
I guess this is a gdb issue then, since it doesn't seem to be able to
find symbols for libc.
Hmmm, it can't even find the libc.so.6 symbols when I purge libc6-i686
and copy
On Thu, 2008-07-24 at 17:45 -0400, Daniel Jacobowitz wrote:
I believe symbols for libc are deliberately not shipped, just enough
to backtrace. So GDB is likely behaving as expected.
In that case, this bug (gdb shows no debug info for libc6/libc6-i386
with libc6-dbg installed) is wontfix. I
On Wed, Oct 22, 2008 at 12:54 AM, Robert Millan [EMAIL PROTECTED] wrote:
On Tue, Oct 21, 2008 at 05:50:40PM +0200, Aurelien Jarno wrote:
An example of such a package is glibc (bug#382175). I don't think that
removing SUNRPC support (and with it NIS, NFS and more) is a suitable
choice (unless
Package: libc6
Version: 2.3.6-15
Severity: wishlist
https://launchpad.net/distros/ubuntu/+source/glibc/+bug/51884
Right now, calling setlocale (which is called by most libgnome using
programs via gnome_program_init) causes ~ 70 kb of allocations.
These allocations could be saved by generating
Control: clone -1 -2
Control: reassign -2 libc6-x32
Control: retitle -2 ld-linux-x32.so.2 --verify segfaults on non-ELF files
Control: severity -2 normal
For the eglibc maintainers; ld-linux-x32.so.2 --verify segfaults on
non-ELF files like shell, python or perl scripts.
On Tue, 2013-05-07 at
Package: libc-bin
Version: 2.18-4
Followup-For: Bug #710521
Control: usertags -1 + bittenby
I also experienced this issue (thanks to adequate), here is a backtrace.
# ldd -r /usr/bin/go
linux-vdso.so.1 (0x7fffc21b9000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
On Tue, Jul 15, 2014 at 1:18 PM, Aurelien Jarno wrote:
It's a huge work for Debian, maybe not for other distribution, as it
basically means we have to rebootstrap everything. This includes manual
bootstrapping of self-dependent languages (haskell, gnat, ...) and
manual handling of some
On Fri, Aug 8, 2014 at 7:22 AM, Emmanuel Bourg wrote:
1. Do nothing. The timezone data will be updated with the quarterly
updates of OpenJDK.
Sounds like OpenJDK has an embedded copy of tzdata? Can we get
upstream to disentangle that, at least for their source releases?
2. Copy the sources
Source: tzdata
Severity: wishlist
X-Debbugs-CC: debian-ad...@lists.debian.org
User: debian-ad...@lists.debian.org
Usertags: needed-by-DSA-Team
DSA currently have a copy of the leap seconds data in dsa-puppet.git for
servers that are timeservers. tzdata also contains a copy of this data.
It should
Source: tzdata
Severity: important
The leap seconds data is outdated. This issue only affects the source
package but I think it should get fixed in all Debian suites in case
people are modifying the source package to install the leap seconds file
on their servers.
On Fri, Aug 5, 2016 at 5:33 PM, Andrew Lee wrote:
> Description : timezone data for tzinfo
>
>This tzinfo-data contains data from the IANA Time Zone database
>packaged as Ruby modules for use with TZInfo.
Folks have been trying to get embedded copies of the tzdata removed
from
Package: nocache/1.0-1,libc6/2.28-2
Severity: critical
Justification: breaks unrelated software
Usertags: hang
The upgrade from libc6 2.27-8 to 2.28-2 breaks nocache; some programs,
when run under it (but not all of them), hang in a call to read/futex:
# nocache sleep 1
# apt show nowcache &>
Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc.
Will this happen in glibc upstream or just in Debian?
> Today, ld.so can be used to activate preloading, for example.
> Compared to LD_PRELOAD, the difference is that it's specific to one
> process, and won't be
15 matches
Mail list logo
