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
Erro
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 succe
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 spe
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 pu
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
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 Infor
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 xulrunner
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
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 "lon
10 matches
Mail list logo
