Package: libstdc++6
Version: 4.6.0-2
Severity: normal
update-menus: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol:
_ZNSt8messagesIcE2idE, version GLIBCXX_3.4
dpkg: error processing menu (--unpack):
subprocess installed post-installation script returned error exit status 127
Package: libgcj-common
Version: 1:4.3-1
Severity: normal
Preparing to replace gjdoc 0.7.8-8 (using .../gjdoc_0.7.8-9_armel.deb) ...
Unpacking replacement gjdoc ...
gcj-dbtool-4.2 succeeded unexpectedly
gcj-dbtool-4.2 succeeded unexpectedly
gcj-dbtool-4.3 succeeded unexpectedly
gcj-dbtool-4.3
Package: gcc-4.2
Version: 4.2.1-5
Severity: normal
Tags: d-i
To fix #433874, we needed to make mklibs aware of symbol versioning. In
the process of doing this, some weird behavior with -u and versioned
symbols was discovered.
Frans Pop found out that [EMAIL PROTECTED] could be used to force a
Package: gcj-4.1
Version: 4.1.2-14
Severity: normal
lrwxrwxrwx 1 root root 38 Jul 30 13:45 /etc/alternatives/native2ascii -
/usr/lib/jvm/java-gcj/bin/native2ascii
lrwxrwxrwx 1 root root 48 Jul 30 13:45 /etc/alternatives/native2ascii.1.gz -
/usr/lib/jvm/java-gcj/man/man1/native2ascii.1.gz
Both
Matthias Klose wrote:
please check if the alternatives are in manual mode, and if yes,
update them. or run update-java-alternatives to update all java
related alternatives. not sure if this is a bug at all, and if, how to
handle the upgrade.
It's in manual mode but I don't remember ever
Package: gcc-3.4
Version: 3.4.6-5
Severity: normal
[EMAIL PROTECTED]:~man gcc-3.4|cat
GCC(1)GNU GCC(1)
gcc-3.4.6 2007-01-01GCC(1)
I think this should be removed.
-- System
Package: gij-4.1
Version: 4.1.1-13
Severity: grave
sh-3.1# gcj-dbtool-4.1 -n /var/lib/gcj-4.1/classmap.db
Segmentation fault
This happens on arm, and, according to vorlon, hppa. The postinst runs this
if /var/lib/gcj-4.1/classmap.db doesn't exist.
This is breaking various builds, like
dann frazier wrote:
If for no other reason, upstream release process changes will likely
make this much more difficult. As I'm sure you know, 2.6 is being
actively developed indefinitely, as opposed to the previous method of
branching off and stabalising a development tree. Since there is no
I just wanted to comment on the 2.4 is deprecated thing. Just because
the kernel team is muttering[1] about not supporting the 2.4 kernel does
not mean that Debian as a project has decided not to support users using
their own versions of this kernel. As Steve notes in #361024, we have to
support
Package: libgcc0
Version: N/A; reported 2001-05-03
Severity: normal
libgcc0 - Shared libgcc.
That is a pretty bad peice of work, just barely borderline for a short
description. It even repeats the base of the package name in the
descripotion, a no-no.
Shared libgcc.
For an extended, aka
10 matches
Mail list logo
