Bug#516725: version is incorrect
Package: libcolamd-3.2.0 Version: 1:3.2.0-3 Followup-For: Bug #516725 Hi, libcolamd-3.2.0 now contains versioned Conflicts: and Replaces: headers, but the version information is incorrect. libsuitesparse-3.2.0 has an epoch... The correct headers would be Conflicts: libsuitesparse-3.2.0 (= 1:3.2.0-1) Replaces: libsuitesparse-3.2.0 (= 1:3.2.0-1) -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libcolamd-3.2.0 depends on: ii libc6 2.9-3 GNU C Library: Shared libraries libcolamd-3.2.0 recommends no packages. libcolamd-3.2.0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511261: CVE-2008-0049: Inproper certificate validation
On Sun, Jan 11, 2009 at 05:18:35PM +0200, George Danchev wrote:
Hello Wouter,
I'm not quite familiar with your app internals, but it seems your fix makes
no
big difference between 0 and 1 return codes. You really want to use
EVP_VerifyFinal as openssl guys did it [1], and provide the above functioning
level with the all possible returns. Their doc suggests the same:
EVP_VerifyFinal() returns:
1 for a correct signature
0 for verfication failure
-1 if some other error occurred.
This is a short code snippet from openssl: apps/dgst.c around line ~458.
i = EVP_VerifyFinal(ctx, sigin, (unsigned int)siglen, key);
if(i 0)
BIO_printf(out, Verified OK\n);
else if(i == 0)
{
BIO_printf(out, Verification Failure\n);
return 1;
}
else
{
BIO_printf(bio_err, Error Verifying Data\n);
ERR_print_errors(bio_err);
return 1;
}
Yes, I know; the code base has two more calls, where the return value is
evaluated in the above sense.
However, the point is that this particular piece of code is a library
call. It wants to return a value that includes all information on the
EVP_VerifyFinal call. Previously, the '!EVP_VerifyFinal' piece
introduced a loss of information; however, the patch I proposed should
remedy that.
I just asked upstream to look at it; I was also recently informed that
the 3.5 code should (eventually) be available in source form, once
government bureaucracy has decided on a license.
--
Lo-lan-do Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511261: CVE-2008-0049: Inproper certificate validation
Hi Moritz, hi security team,
On Thu, Jan 08, 2009 at 10:30:14PM +0100, Moritz Muehlenhoff wrote:
CVE-2009-0049:
Yay. And 3.5.0 isn't even in source form anymore; I'm not even sure
whether they actually are going to publish source for that. *sigh*.
Belgian eID middleware (eidlib) 2.6.0 and earlier does not properly check the
return value from the OpenSSL EVP_VerifyFinal function, which allows remote
attackers to bypass validation of the certificate chain via a malformed
SSL/TLS signature, a similar vulnerability to CVE-2008-5077.
Since there appears to be no patch, AFAICS:
wou...@country:~/debian/eID/belpic-2.6.0$ grep -r 'EVP_VerifyFinal' *
src/newpkcs11/src/pkcs11/openssl.c: * finishing with EVP_VerifyFinal().
src/newpkcs11/src/pkcs11/openssl.c: res = EVP_VerifyFinal(md_ctx,
signat, signat_len, pkey);
src/newpkcs11/src/pkcs11/openssl.c: sc_debug(context,
EVP_VerifyFinal() returned %d\n, res);
src/newpkcs11/src/tools/pkcs11-tool.c: err = EVP_VerifyFinal(md_ctx, sig1,
sigLen1, pkey);
src/eidlib/Verify.cpp:iRet = 2*iDiffRNCert + !EVP_VerifyFinal(cmd_ctx,
(unsigned char *)pucSig, ulSigLen, pKey);
The first two files are okay. In both cases, the return value is sent to
a variable that is then properly checked using an if() {} else if() {} else {}
block for the three possible return values of EVP_VerifyFinal().
The third appears to be somewhat more conspicious. Looking around in the
code a bit, this is what it's *supposed* to return:
/* Signature validation return codes */
#define BEID_SIGNATURE_NOT_VALIDATED-2 /* The signature is not valid
ated */
#define BEID_SIGNATURE_PROCESSING_ERROR-1 /* Error verifying the
signature. */
#define BEID_SIGNATURE_VALID0 /* The signature
is valid. */
#define BEID_SIGNATURE_INVALID 1 /* The
signature is not valid. */
#define BEID_SIGNATURE_VALID_WRONG_RRNCERT 2 /* The signature is
valid and wrong RRN certificate. */
#define BEID_SIGNATURE_INVALID_WRONG_RRNCERT3 /* The signature is not
valid and wrong RRN certificate. */
(that's from eiddefines.h)
So the patch should be something like:
--- Verify.cpp.orig 2009-01-09 03:48:56.0 +0100
+++ Verify.cpp 2009-01-09 03:42:44.0 +0100
@@ -1013,6 +1013,7 @@
unsigned char *pucRNCert = NULL;
unsigned long ulRNCertLen = 0;
BEID_Certif_Check tCertifs = {0};
+int evp_ret;
if(m_pCertifManager == NULL)
{
@@ -1084,7 +1085,11 @@
EVP_VerifyInit(cmd_ctx, EVP_sha1());
EVP_VerifyUpdate(cmd_ctx, pucData, ulDataLen);
-iRet = 2*iDiffRNCert + !EVP_VerifyFinal(cmd_ctx, (unsigned char *)pucSig,
ulSigLen, pKey);
+evp_ret = EVP_VerifyFinal(cmd_ctx, (unsigned char *)pucSig, ulSigLen,
pKey);
+if(evp_ret = 0) {
+ evp_ret = 1 - evp_ret;
+}
+iRet = 2*iDiffRNCert + evp_ret;
EVP_PKEY_free(pKey);
X509_free(pX509);
return iRet;
Given that this is me guessing what the issue really is based on a
description and some documentation that I'm not 100% sure I correctly
parsed, I'd appreciate it if someone could verify and peer-review this
before I upload it to unstable.
Thanks,
--
Lo-lan-do Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507555: Bugzilla3 fails to install without extensive hand-holding
: bugzilla3/dbconfig-reinstall: false * bugzilla3/bugzilla_admin_real_name: Wouter Verhelst bugzilla3/remote/port: * bugzilla3/bugzilla_admin_name: [EMAIL PROTECTED] bugzilla3/dbconfig-upgrade: true bugzilla3/purge: false bugzilla3/database-type: mysql bugzilla3/remove-error: abort * bugzilla3/dbconfig-install: false bugzilla3/internal/reconfiguring: false bugzilla3/remote/newhost: bugzilla3/internal/skip-preseed: true bugzilla3/remote/host: bugzilla3/install-error: abort bugzilla3/upgrade-backup: true bugzilla3/mysql/admin-user: root bugzilla3/upgrade-error: abort bugzilla3/db/app-user: bugzilla3 bugzilla3/mysql/method: unix socket -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494385: prerm doesn't work if openct isn't running
Package: openct Version: 0.6.14-2 Severity: serious Hi, If openct isn't running, the openct init script exits with a non-zero exit state. The prerm doesn't catch this condition, and fails. That shouldn't happen. I'm not entirely sure whether exiting an initscript with a non-zero exit state is allowed in this case either, but I'll leave that for others to decide ;-) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-1-powerpc Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openct depends on: ii adduser 3.109 add and remove users and groups ii dpkg 1.14.20 Debian package management system ii libc62.7-13 GNU C Library: Shared libraries ii libltdl3 1.5.26-4A system independent dlopen wrappe ii libopenct1 0.6.14-2middleware framework for smart car ii libusb-0.1-4 2:0.1.12-12 userspace USB programming library Versions of packages openct recommends: ii udev 0.125-4/dev/ and hotplug management daemo openct suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457962: closed by Raphael Hertzog [EMAIL PROTECTED] (Re: Bug#457962: dpkg_1.14.13(m68k/unstable): Missing dependency on IO/String.pm)
On Thu, Dec 27, 2007 at 03:27:04PM +, Debian Bug Tracking System wrote: Yep, this was already known and is the reason of the quick 1.14.14 upload.. Oops -- sorry. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443722: Not an f-spot bug
severity 443722 normal I hadn't been able to trigger this bug at the time when I reported it using anything but f-spot, no matter how I tried; and it had happened about 30 times (off the back of my head). Last weekend, however, I did reproduce this bug using digiKam; so either some library that is shared by both digiKam and f-spot is at fault, or something else entirely. Since I'm no longer sure which package is at fault, it's not really fair to leave this as an RC bug on f-spot, so changing the severity. Since I don't (yet) know what is really causing this, however, and since I still saw this happening most while using f-spot, I'm not going to reassign or close it just yet. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452511: --ignore-missing-info should be the default for now
Package: dpkg-dev
Version: 1.14.10
Severity: serious
Tags: patch
Hi,
The recent change to check missing shlibdeps files and to error out if
not makes some packages insta-buggy where they otherwise wouldn't be. A
good example is in libm; there is no shlibdeps file for libm, which
makes dpkg-shlibdeps bail out at the moment. However, it's pretty hard
to link to libm while not linking to libc, which is in the same package,
and which *does* have a slibdeps file.
You really shouldn't do this. The following patch makes
--ignore-missing-info the default:
diff -ruN dpkg-1.14.10.orig/man/dpkg-shlibdeps.1
dpkg-1.14.10/man/dpkg-shlibdeps.1
--- dpkg-1.14.10.orig/man/dpkg-shlibdeps.1 2007-11-19 07:28:45.0
+0100
+++ dpkg-1.14.10/man/dpkg-shlibdeps.1 2007-11-23 12:26:44.0 +0100
@@ -173,11 +173,13 @@
package. This option can be used multiple times to exclude several
packages.
.TP
+.BI \-\-no\-ignore\-missing\-info
.BI \-\-ignore\-missing\-info
-Do not fail if dependency information can't be found for a shared library.
+Do (do not) fail if dependency information can't be found for a shared library.
Usage of this option is discouraged, all libraries should provide
dependency information (either with shlibs files, or with symbols files)
-even if they are not yet used by other packages.
+even if they are not yet used by other packages. The default is to ignore
+missing info.
.TP
.BI \-\-admindir= dir
Change the location of the \fBdpkg\fR database. The default location is
diff -ruN dpkg-1.14.10.orig/scripts/dpkg-shlibdeps.pl
dpkg-1.14.10/scripts/dpkg-shlibdeps.pl
--- dpkg-1.14.10.orig/scripts/dpkg-shlibdeps.pl 2007-11-23 03:42:51.0
+0100
+++ dpkg-1.14.10/scripts/dpkg-shlibdeps.pl 2007-11-23 12:25:30.0
+0100
@@ -32,7 +32,7 @@
my $dependencyfield= 'Depends';
my $varlistfile= 'debian/substvars';
my $varnameprefix= 'shlibs';
-my $ignore_missing_info= 0;
+my $ignore_missing_info= 1;
my $debug= 0;
my @exclude = ();
@@ -68,6 +68,8 @@
$exec{$1} = $dependencyfield;
} elsif (m/^--ignore-missing-info$/) {
$ignore_missing_info = 1;
+} elsif (m/^--no-ignore-missing-info$/) {
+ $ignore_missing_info = 0;
} elsif (m/^-t(.*)$/) {
$packagetype = $1;
} elsif (m/^-v$/) {
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.22-3-powerpc
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg-dev depends on:
ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina
ii cpio2.9-6GNU cpio -- a program to manage ar
ii dpkg1.14.9 package maintenance system for Deb
ii make3.81-3 The GNU version of the make util
ii patch 2.5.9-4 Apply a diff file to an original
ii perl [perl5]5.8.8-12 Larry Wall's Practical Extraction
ii perl-modules5.8.8-12 Core Perl modules
Versions of packages dpkg-dev recommends:
ii bzip2 1.0.3-7high-quality block-sorting file co
ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-15 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.6-6The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-17 The GNU C compiler
ii gcc-4.2 [c-compiler] 4.2.2-3The GNU C compiler
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452100: Log for failed build of olsrd_0.5.4-1 (dist=unstable)
Package: olsrd Version: 0.5.4-1 Severity: serious Hi, (apologies if this bug has already been filed, but I'm in offline mode right now) Your build loops over make install. From the build log: Automatic build of olsrd_0.5.4-1 on arrakis by sbuild/m68k 98 Build started at 20071118-1330 ** [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 5), quilt, bison, flex [...] gcc -Wl,-export-dynamic -o olsrd src/build_msg.o src/duplicate_set.o src/generate_msg.o src/hashing.o src/hna_set.o src/hysteresis.o src/interfaces.o src/ipc_frontend.o src/link_set.o src/local_hna_set.o src/lq_avl.o src/lq_list.o src/lq_mpr.o src/lq_packet.o src/lq_route.o src/main.o src/mantissa.o src/mid_set.o src/mpr.o src/mpr_selector_set.o src/neighbor_table.o src/net_olsr.o src/olsr.o src/packet.o src/parser.o src/plugin_loader.o src/plugin_util.o src/print_packet.o src/process_package.o src/process_routes.o src/rebuild_packet.o src/routing_table.o src/scheduler.o src/socket_parser.o src/tc_set.o src/two_hop_neighbor_table.o src/linux/apm.o src/linux/kernel_routes.o src/linux/link_layer.o src/linux/net.o src/unix/ifnet.o src/unix/log.o src/unix/misc.o src/cfgparser/oscan.o src/cfgparser/oparse.o src/cfgparser/olsrd_conf.o src/builddata.o -ldl -lpthread make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' touch build-stamp fakeroot debian/rules binary-arch dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/olsrd. /usr/bin/make DESTDIR=/build/buildd/olsrd-0.5.4/debian/olsrd install STRIP=: make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' make[1]: Entering directory `/build/buildd/olsrd-0.5.4' make[1]: Leaving directory `/build/buildd/olsrd-0.5.4' [...] etc, ad nauseam. As usual, a full build log can be found through http://buildd.debian.org -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425450: beid-tools: Get error: Failed to load pkcs11 module
reassign 425450 libbeidlibopensc2 severity 425450 important thanks On Mon, May 21, 2007 at 08:32:00PM +0200, Antoine Cailliau wrote: Package: beid-tools Version: 2.5.9-8 Severity: grave Justification: renders package unusable After installing beid-tools I'm unable to read my eid card. My SC reader work fine because I can read other smartcard without problems. Here is the error I got beid-pkcs11-tool --test error: Failed to load pkcs11 module Aborting. There is currently still an issue with libbeidlibopensc2, which tries to find libbeidpkcs11.so where it should look for libbeidpkcs11.so.SONAME. As a workaround, you can install libbeidlibopensc2-dev. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376812: -fno-strict-aliasing didn't work
On Thu, Feb 22, 2007 at 05:18:46AM +0200, Guillem Jover wrote: Hey, On Sun, 2007-02-18 at 22:05:01 +0100, Wouter Verhelst wrote: I rebuilt the package using -fno-strict-aliasing and -g (which took quite some time), and ran it inside an etch chroot on a sarge box; the kernel was a stock sarge kernel with the sarge 3dfx module. That didn't fix the problem. Thanks for testing! Ok, could you try the packages at: http://people.debian.org/~guillem/glide/ Yes, these do work. You may want to change the version number, though, because I got a message from dpkg that I was downgrading the package. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376812: -fno-strict-aliasing didn't work
Hi, I rebuilt the package using -fno-strict-aliasing and -g (which took quite some time), and ran it inside an etch chroot on a sarge box; the kernel was a stock sarge kernel with the sarge 3dfx module. That didn't fix the problem. An strace of /usr/lib/glide2/test00 is available at http://grep.be/~wouter/test00.strace; an ltrace at .../test00.ltrace. (If it matters, the strace was made with the original package that comes from the archive, while the ltrace was made with the package built with the above options. I don't think it does matter, but I'll be happy to retry either with the other package if it turns out to matter). -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406963: nbd-server: postinst script breaks custom server options
On Mon, Jan 15, 2007 at 02:25:51AM -0800, J.P. Larocque wrote: On what perhaps should be filed in a separate bug report: Why aren't the NBD_SERVER_OPTS* lines configurable with debconf? Debconf is not a registry. This type of thing really is advanced configuration already, and I don't think it's horribly bad if it's impossible to configure from debconf. Granted, the argument to the -l parameter might be interesting to be configurable from debconf. In any case, though, the 2.9 release (which is out upstream, but not mature enough yet for inclusion in etch---that's lenny material) will have its own configuration file format that I'll have to support, which will require rewriting the debconf configuration anyway; so I won't modify the way things work currently anymore. I'm currently working on a new Debian release of nbd, which includes your patch. Thanks! -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Bug#405996: Fails to configure
On Mon, Jan 08, 2007 at 09:20:49AM +0100, Martin v. Löwis wrote: Wouter, can you please run python -v and report its output? Attached -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 Script started on Mon Jan 8 10:38:21 2007 # installing zipimport hook import zipimport # builtin # installed zipimport hook # /usr/lib/python2.4/site.pyc matches /usr/lib/python2.4/site.py import site # precompiled from /usr/lib/python2.4/site.pyc # /usr/lib/python2.4/os.pyc matches /usr/lib/python2.4/os.py import os # precompiled from /usr/lib/python2.4/os.pyc import posix # builtin # /usr/lib/python2.4/posixpath.pyc matches /usr/lib/python2.4/posixpath.py import posixpath # precompiled from /usr/lib/python2.4/posixpath.pyc # /usr/lib/python2.4/stat.pyc matches /usr/lib/python2.4/stat.py import stat # precompiled from /usr/lib/python2.4/stat.pyc # /usr/lib/python2.4/UserDict.pyc matches /usr/lib/python2.4/UserDict.py import UserDict # precompiled from /usr/lib/python2.4/UserDict.pyc # /usr/lib/python2.4/copy_reg.pyc matches /usr/lib/python2.4/copy_reg.py import copy_reg # precompiled from /usr/lib/python2.4/copy_reg.pyc # /usr/lib/python2.4/types.pyc matches /usr/lib/python2.4/types.py import types # precompiled from /usr/lib/python2.4/types.pyc # /usr/lib/python2.4/warnings.pyc matches /usr/lib/python2.4/warnings.py import warnings # precompiled from /usr/lib/python2.4/warnings.pyc # /usr/lib/python2.4/linecache.pyc matches /usr/lib/python2.4/linecache.py import linecache # precompiled from /usr/lib/python2.4/linecache.pyc import encodings # directory /usr/lib/python2.4/encodings # /usr/lib/python2.4/encodings/__init__.pyc matches /usr/lib/python2.4/encodings/__init__.py import encodings # precompiled from /usr/lib/python2.4/encodings/__init__.pyc # /usr/lib/python2.4/codecs.pyc matches /usr/lib/python2.4/codecs.py import codecs # precompiled from /usr/lib/python2.4/codecs.pyc import _codecs # builtin # /usr/lib/python2.4/encodings/aliases.pyc matches /usr/lib/python2.4/encodings/aliases.py import encodings.aliases # precompiled from /usr/lib/python2.4/encodings/aliases.pyc # /usr/lib/python2.4/encodings/ascii.pyc matches /usr/lib/python2.4/encodings/ascii.py import encodings.ascii # precompiled from /usr/lib/python2.4/encodings/ascii.pyc Python 2.4.4 (#2, Oct 20 2006, 00:23:25) [GCC 4.1.2 20061015 (prerelease) (Debian 4.1.1-16.1)] on linux2 Type help, copyright, credits or license for more information. dlopen(/usr/lib/python2.4/lib-dynload/readline.so, 2); import readline # dynamically loaded from /usr/lib/python2.4/lib-dynload/readline.so # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # clear sys.path_hooks # clear sys.path_importer_cache # clear sys.meta_path # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] site # cleanup[1] encodings # cleanup[1] _codecs # cleanup[1] zipimport # cleanup[1] warnings # cleanup[1] encodings.ascii # cleanup[1] codecs # cleanup[1] readline # cleanup[1] types # cleanup[1] signal # cleanup[1] linecache # cleanup[1] posix # cleanup[1] encodings.aliases # cleanup[1] exceptions # cleanup[2] copy_reg # cleanup[2] posixpath # cleanup[2] os.path # cleanup[2] stat # cleanup[2] UserDict # cleanup[2] os # cleanup sys # cleanup __builtin__ # cleanup ints: 7 unfreed ints in 1 out of 3 blocks # cleanup floats Script done on Mon Jan 8 10:38:23 2007
Bug#405996: Fails to configure
Package: python-gnome2-desktop Version: 2.14.0-3 Severity: serious rock:~# LC_ALL=C dpkg --configure -a Setting up python-gnome2-desktop (2.14.0-3) ... INFO: using old version '/usr/bin/python2.3' 'import site' failed; use -v for traceback Traceback (most recent call last): File /usr/bin/py_compilefiles, line 106, in ? exit_status = int(not main()) File /usr/bin/py_compilefiles, line 98, in main elif not compile_files(files, ddir, force, rx, quiet): File /usr/bin/py_compilefiles, line 24, in compile_files if os.path.isdir(fullname): AttributeError: 'module' object has no attribute 'path' pycentral: pycentral pkginstall: error byte-compiling files (13) pycentral pkginstall: error byte-compiling files (13) dpkg: error processing python-gnome2-desktop (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of deskbar-applet: deskbar-applet depends on python-gnome2-desktop; however: Package python-gnome2-desktop is not configured yet. dpkg: error processing deskbar-applet (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: python-gnome2-desktop deskbar-applet -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (200, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages python-gnome2-desktop depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.12.3-1 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-3 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-5 The Bonobo UI library ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.1-2 generic font configuration library ii libgconf2-42.16.0-3 GNOME configuration database syste ii libglade2-01:2.6.0-4 library to load .glade files at ru ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgnome-keyring0 0.6.0-3 GNOME keyring services library ii libgnome-media02.14.2-4 runtime libraries for the GNOME me ii libgnome2-02.16.0-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeprint2.2-0 2.12.1-7 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.12.1-4 GNOME 2.2 print architecture User ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.2-4 GNOME virtual file-system (runtime ii libgtk2.0-02.8.20-3 The GTK+ graphical user interface ii libgtksourceview1.0-0 1.8.2-1 shared libraries for the GTK+ synt ii libgtop2-7 2.14.4-2 gtop system monitoring library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libmetacity0 1:2.14.5-2library of lightweight GTK2 based ii libnautilus-burn3 2.14.3-6 Nautilus Burn Library - runtime ve ii liborbit2 1:2.14.3-0.1 libraries for ORBit2 - a CORBA ORB ii libpanel-applet2-0 2.14.3-4 library for GNOME 2 panel applets ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio ii libpopt0 1.10-3lib for parsing cmdline parameters ii libsm6 1:1.0.1-3 X11 Session Management library ii libtotem-plparser1 2.16.4-2 Totem Playlist Parser library - ru ii libwnck18 2.14.3-1 Window Navigator Construction Kit ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxml22.6.27.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii python 2.4.4-2 An interactive high-level object-o ii python-central 0.5.12register and build utility for Pyt ii python-gtk22.8.6-8 Python bindings for the GTK+ widge ii python-pyorbit 2.0.1-5 A Python language binding for the ii zlib1g
Bug#376812: I have a Voodoo2 card...
Hi, I have such a card, but it's sitting in a machine that runs Sarge (and I'm not going to update it to etch before that's released). If it would help, I'd be willing to run some tests on that box. Just tell me what you want me to do and what information you need back, and I'll do so. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391181: cron.d script does not check whether the package is still installed
Package: pdbv Version: 2.0.10.1 Severity: serious Hi, I just received a mail from cron that it couldn't find /usr/bin/pdbv. Which is expected, since it's no longer installed. However, the cron.d script does not check that. I'd recommend adding at least a [ -x /usr/bin/pdbv ] in front of whatever you're running. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-2-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages pdbv depends on: ii coreutils [fileutils] 5.97-5 The GNU core utilities ii debconf 1.5.5 Debian configuration management sy ii liblocale-gettext-perl1.05-1 Using libc functions for internati pn libtie-ixhash-perlnone (no description available) ii perl-base 5.8.8-6.1 The Pathologically Eclectic Rubbis ii perl-modules 5.8.8-6.1 Core Perl modules Versions of packages pdbv recommends: ii popularity-contest1.34 Vote for your favourite packages a ii procps1:3.2.7-3 /proc file system utilities -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339344: Patch for wrong pointer type
On Tue, Jul 25, 2006 at 01:21:44PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: tags 339344 - patch thanks On Mon, Jul 17, 2006 at 09:56:10AM +0200, Goswin Brederlow wrote: Package: belpic Followup-For: Bug #339344 Hi, attached is a patch for the pointer conversion error. It doesn't actually work, though; you can't change the definition of a class which is rather central in the entire class hierarchy and hope that things still compile. Also, this implies an API change, which is a Very Bad Thing(TM). Worked fine here on amd64. What error do you get? The exact reverse of what you got on amd64 without the fix. Unfixed, the code assumed that size_t == unsigned int, and that one cast broke on architectures where this is not true. Your fix basically assumed that size_t == unsigned long (the code refers to that modified data later on as size_t anyway). It also happened to change the ABI (not just the API) of the library, which would have required me to do a SONAME bump (the function was part of an abstract class, and many child classes reimplement it). The right fix is simpler: rather than trying to cast unsigned long to unsigned int, one should cast unsigned long to size_t (which happens to be the same thing on 32bit architectures, but nowhere else). That isn't right. That might just be working on the relevant systems. Sorry, after looking at the code for over three hours, I came to the conclusion that it is. Please check the patch and prove to me that it is wrong, or it will stay the way it is now. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339344: Patch for wrong pointer type
tags 339344 - patch thanks On Mon, Jul 17, 2006 at 09:56:10AM +0200, Goswin Brederlow wrote: Package: belpic Followup-For: Bug #339344 Hi, attached is a patch for the pointer conversion error. It doesn't actually work, though; you can't change the definition of a class which is rather central in the entire class hierarchy and hope that things still compile. Also, this implies an API change, which is a Very Bad Thing(TM). The right fix is simpler: rather than trying to cast unsigned long to unsigned int, one should cast unsigned long to size_t (which happens to be the same thing on 32bit architectures, but nowhere else). -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374783: seems to be broken in SSL only
On Sun, Jul 02, 2006 at 11:42:56AM -0400, Jaldhar H. Vyas wrote: On Fri, 23 Jun 2006, Wouter Verhelst wrote: I'm seeing the same issue; however, while IMAPS does indeed not work, netstat -tl shows me that dovecot does properly listen to port 143, i.e., the regular IMAP port. Hi Johnathan and Wouter, Upstream thinks this is fixed in 1.0rc1 which is in unstable. Can you try it and confirm? It's working for me too, now. Sorry for the late reply. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374185: mkvmlinuz: syntax errors in script
Package: mkvmlinuz
Version: 22
Severity: grave
Justification: make package in question unusable
Hi,
mkvmlinuz currently fails to work at all. There are a number of syntax
errors in the script, which would need to be fixed before it can ever
hope to run successfully. Did whoever uploaded this actually test it
before uploading?
Anyway. Patch follows:
--- mkvmlinuz.orig 2006-06-17 20:03:05.0 +0200
+++ /usr/sbin/mkvmlinuz 2006-06-17 20:13:40.0 +0200
@@ -60,7 +60,7 @@
esac
# use non-option arguments as release version and kernel image file if needed
-shift $((OPTIND-1))
+shift $(( $OPTIND - 1 ))
if test -z $release -a -n $1; then
release=$1
fi
@@ -115,7 +115,8 @@
if test -z $noinitrd -a -z $initrd; then
# guess the location of an initrd, but don't try too hard
-if initrd=${kernel/vmlinux/initrd.img}; test -r $initrd; then
+initrd=$(echo $kernel | sed -e 's/vmlinux/initrd.img/')
+if test -r $initrd; then
:
else
initrd=
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-2-powerpc
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages mkvmlinuz depends on:
ii binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina
ii debconf [debconf-2.0 1.5.2 Debian configuration management sy
mkvmlinuz recommends no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361396: FTBFS with G++ 4.1: extra qualification co
On Sun, Jun 11, 2006 at 01:47:16AM +0200, Steinar H. Gunderson wrote: On Sat, Apr 08, 2006 at 02:30:12PM +0200, Martin Michlmayr wrote: But then I get the following, which I'm not sure is a bug in wxwidgets-2.6 or your package (I thought I had a patches wxwidgets installed so either it needs more patching or your package needs another fix): [...] Config.cpp:112: error: ambiguous overload for 'operator+' in 'CConfig::GetGlobalDir()() + BEID.conf' [...] Config.cpp:117: error: cannot convert 'const wxChar*' to 'const char*' for argument '2' to 'int NCONF_load(CONF*, const char*, long int*)' This looks like a Unicode-vs-non-Unicode mismatch; NCONF_load should probably take a const wxChar* (which probably maps to wchar_t, as I'd guess you compile against the Unicode build of wxWidgets) instead of const char *, and then move from there. Similiarily CONFFILE_BEID should probably read _T(foo) instead of foo, or line 112 should include the _T() macro. Optionally, the entire thing could be compiled against the non-Unicode build of wxWidgets... (Or perhaps upstream solved these bugs as well? I see the bug was tagged fixed-upstream, but I'm not sure if this includes the wxWidgets bugs.) The new version compiles just fine with G++ 4.*. I've got a package mostly ready, I'm only waiting for upstream to release the official version before I upload the Debian package (as they've asked me); hopefully that won't take too long anymore. This is a government body though :-) I haven't checked whether the new version has unicode-related warning or errors, but I do know that the unicode corruption which occurs in the previous version of the eidviewer seems gone in the new version. Whether this is because they fixed the code, or because QT (which they've decided to include...) is more flexible regarding unicode, I don't know. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364098: mumble, mumble
-- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 Applying patch localedata/locale-de_CH.diff patching file localedata/locales/de_CH Applying patch locale-ru_RU.diff patching file intl/locale.alias Applying patch localedata/locale-eo_EO.diff patching file localedata/locales/eo patching file localedata/SUPPORTED Applying patch localedata/locale-no_NO.diff patching file localedata/locales/no_NO Applying patch glibc-i686-timing.diff patching file sysdeps/generic/ldsodefs.h Hunk #1 succeeded at 451 (offset 193 lines). Hunk #2 succeeded at 662 (offset 200 lines). patching file sysdeps/i386/hp-timing.h patching file elf/dl-altinit.c patching file elf/Makefile Hunk #1 succeeded at 23 with fuzz 2. Applying patch glibc-sparc-timing.diff patching file sysdeps/sparc/sparc32/hp-timing.h Applying patch makeconfig.diff patching file Makeconfig Hunk #1 succeeded at 544 (offset 3 lines). Applying patch ldconfig.diff patching file elf/ldconfig.c Hunk #1 succeeded at 992 (offset 20 lines). Applying patch ldd.diff patching file elf/ldd.bash.in Applying patch fhs-linux-paths.diff patching file sysdeps/unix/sysv/linux/paths.h Hunk #1 succeeded at 67 (offset -4 lines). Applying patch glibc22-nss-upgrade.diff patching file nss/nsswitch.c Hunk #1 succeeded at 344 (offset 11 lines). Applying patch sparc64-fixups.diff patching file elf/ldconfig.c Hunk #1 succeeded at 320 (offset 33 lines). Applying patch glibc22-ttyname-devfs.diff patching file sysdeps/unix/sysv/linux/ttyname_r.c Hunk #5 succeeded at 150 (offset 7 lines). patching file sysdeps/unix/sysv/linux/ttyname.c Hunk #1 succeeded at 33 with fuzz 2 (offset 3 lines). Hunk #2 succeeded at 42 (offset 3 lines). Hunk #3 succeeded at 58 (offset 3 lines). Hunk #4 succeeded at 81 (offset 3 lines). Hunk #5 succeeded at 115 (offset 5 lines). Hunk #6 succeeded at 152 (offset 5 lines). Applying patch powerpc-sysconf.diff patching file sysdeps/unix/sysv/linux/powerpc/getsysstats.c Applying patch glibc23-hppa-Rminkernel.diff patching file sysdeps/unix/sysv/linux/configure.in Hunk #1 succeeded at 69 (offset 4 lines). patching file sysdeps/unix/sysv/linux/configure Hunk #1 succeeded at 109 (offset 3 lines). Applying patch glibc23-asserth-decls.diff patching file assert/assert.h Applying patch glibc23-cmov.diff patching file sysdeps/i386/dl-procinfo.h Applying patch hurd-enable-ldconfig.diff patching file sysdeps/mach/hurd/configure Hunk #1 succeeded at 90 with fuzz 2 (offset -25 lines). patching file sysdeps/mach/hurd/configure.in patching file elf/ldconfig.c Hunk #1 succeeded at 57 (offset 8 lines). patching file sysdeps/mach/hurd/dl-cache.c Applying patch sparcv8-target.diff patching file configure Hunk #1 succeeded at 1798 (offset 2 lines). patching file configure.in Hunk #1 succeeded at 307 (offset -30 lines). Applying patch 50_glibc232-arm-dwarf2-buildfix.diff patching file sysdeps/arm/framestate.c patching file sysdeps/arm/unwind-pe.c Applying patch 50_glibc232-m68k-dwarf2-buildfix.diff patching file sysdeps/m68k/framestate.c patching file sysdeps/m68k/unwind-pe.c Applying patch glibc-2.3.2-ldconfig-tls.diff patching file elf/cache.c Applying patch 90_glibc233_tcsetaddr.diff patching file sysdeps/unix/sysv/linux/tcsetattr.c Hunk #1 succeeded at 48 (offset -7 lines). Hunk #2 succeeded at 85 (offset -7 lines). Applying patch localedef-fix-trampoline.diff patching file locale/programs/3level.h Hunk #1 succeeded at 202 (offset -2 lines). Applying patch localedata/locale-eu_FR.diff patching file localedata/locales/eu_FR patching file localedata/SUPPORTED Hunk #1 succeeded at 163 with fuzz 1 (offset -3 lines). patching file localedata/locales/[EMAIL PROTECTED] Applying patch glibc23-mips-lazy-eval.diff patching file elf/do-lookup.h Hunk #1 succeeded at 192 (offset -17 lines). Applying patch glibc235-gcc4-wcstol_l.diff patching file sysdeps/wordsize-64/strtol_l.c patching file sysdeps/wordsize-64/wcstol_l.c Applying patch glibc235-gcc4-ppc-procfs.diff Patch glibc235-gcc4-ppc-procfs.diff does not exist
Bug#356190: Does not work
Package: zd1211-source Version: 0.0.0.svnr59-1 Severity: grave Justification: makes package in question unusable Hi, Building zd1211-source against vanilla 2.6.15.6 works, but the resulting driver does not seem to work; it loads, it associates, but I don't get a DHCP reply that works. Downgrading to the version in testing, rebuilding, and reloading the driver fixes this. (Not too sure about 'grave' severity; if you feel something else is better, please change as appropriate) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.6 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages zd1211-source depends on: ii bzip2 1.0.3-2high-quality block-sorting file co ii cdbs 0.4.35 common build system for Debian pac ii debhelper 5.0.24 helper programs for debian/rules ii gawk 1:3.1.5-2 GNU awk, a pattern scanning and pr ii kernel-package10.036 A utility for building Linux kerne ii module-assistant 0.10.2 tool to make module package creati ii quilt 0.42-2 Tool to work with series of patche zd1211-source recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353277: Please reject to rule on the ndiswrapper question
On Sat, Mar 04, 2006 at 04:47:17PM -0800, Steve Langasek wrote: If you think that Debian policy's definition of these archive sections, or the ftp team's implementation of it, is incompatible with the Social Contract, that is indeed not a technical question and it would be inappropriate for the TC to overrule another developer's understanding of the Social Contract; a matter such as that ought to be settled by GR instead. But that's not the question that has been put before us. Actually, I believe it is. But it's not my authority to force that upon you, you have to make your own decision in that regard. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353277: Please reject to rule on the ndiswrapper question
Hi, I hereby appeal to the technical committee to reject to rule on this request, on the grounds that this is not a technical matter, and therefore falls outside the authority of the technical committee. The question at hand is whether the statement this package is not useful without non-free software, even though it will run without non-free software is relevant wrt the requirement which is in Policy that no package in main must require any package outside of main to be built or executed. This is not a technical issue; it is simply a matter of interpretation of the social contract--which is clearly not a technical issue. The correct way to proceed would seem to be a ruling by a body authorized to make authoritative interpretations of the Social Contract, or, failing that (since I believe we have no such body), a General Resolution. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Bug#353277: ndiswrapper in main
On Sun, Feb 19, 2006 at 11:11:32AM +0100, Robert Millan wrote: On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote: On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow The availability to do this is enough even if there are other (possibly better) ways to do the same. One free driver _in_ Debian and the package should stay in main. But does the cipe-source build or ship the windows driver for use with ndiswraper? I doubt that. Which means you need some software (even if it is free) from outside Debian for ndiswraper. That makes it contrib imho. Are there any free MSWord files in main ? No ? Then please move antiword and similar tools to contrib. You're turning this into non-sense. An NDIS wrapper is OBVIOUSLY for the exclussive purpose of using non-free Windows drivers. It is so obvious because nobody has written [1] free GPLed NDIS drivers. EVER. It has nothing to do with Wine and MSWord [2]. So, stop throwing unrelated points to this matter. Just fix the bug. Move this to contrib, with all the other warez wrappers. [1] Written, not ported. I know someone ported that CIPE thing from Linux to Windows, but the sole idea of porting something to Windows in order to emulate it from Linux makes me laugh. The sole idea to run Internet Explorer under Wine on Linux makes _me_ laugh. But I've seen people do it. And they were not amused by my laughing. The fact that there is at least one GPL driver for ndiswrapper means that it is possible to use ndiswrapper for useful purposes without non-free software. And since cipe is not part of the kernel yet, that might be a good idea anyway if the native driver doesn't work with the kernel which you're using for some reason while ndiswrapper does. Which is not _that_ strange, I've seen it often enough with out-of-(vanilla)-kernel modules. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 01:42:38PM +0100, Robert Millan wrote: On Sat, Feb 18, 2006 at 12:49:48PM +0100, Wouter Verhelst wrote: On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. Does the lack of a free driver which can be used with ndiswrapper mean that it is impossible to use ndiswrapper with such a free driver, should one eventually be written? You can apply this argument to every single package in contrib. No, that's not true. ndiswrapper is an environment for running software, much in the same way as wine is an environment for running software. Heck, even much in the same way that a PC is an environment for running software. Wine is something that was written to make the use of Windows binary software possible on Linux. The fact that you'd do it this way, rather than recompiling the application for Linux and running such a recompiled version instead is a serious indication that the software you're trying to run is, most likely, not a free application. But does that mean that wine requires the use of non-free software? I say it does not. Because there is a major difference between an application that requires the use of a library that is non-free, and a library that allows or facilitates the use of non-free software. Wine and ndiswrapper are in the latter category; a GPL'ed application which is written in Java that requires the use of a non-free API is not, and is in a completely different ballpark. If a free driver/datafile/whatever existed, it would be possible to run Foo without requiring non-free stuff, therefore it belongs to main Is your point that contrib should therefore be empty and has no reason for existance? No. Please don't put words in my mouth if what I said can't be used to make your point. It is already possible to use ndiswrapper without having any non-free software installed. Granted, it doesn't do much useful that way, but a) neither the DFSG nor the SC say anything about usefulness, and b) if a free library package exists in main which no other free package uses it, we don't move the free library package to contrib either. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. Does the lack of a free driver which can be used with ndiswrapper mean that it is impossible to use ndiswrapper with such a free driver, should one eventually be written? If there is a brand shiny new file format of which the spec has been fully disclosed and published in an RFC, though no free editors exist (yet) for the format, does that make the format non-free? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346148: (fwd) Bug#346148: [Pkg-sysvinit-devel] Bug#346148: checkroot.sh: does not properly handle fsck exit states
On Thu, Jan 05, 2006 at 10:37:14PM -0200, Henrique de Moraes Holschuh wrote: On Fri, 06 Jan 2006, Wouter Verhelst wrote: I just noticed that my laptop, at bootup, started an fsck for the root filesystem, claiming that it was a filesystem with errors. When it was about 20% done, it exited, and told me to rerun it manually. I expected a prompt for my root password and to be put in single-user mode, but this did not happen; instead, my system did a normal boot. This means fsck returned error codes 2 or 3. If fsck needs to be re-run manually, it should have something else (bit 1 should not be set, bit 2 should be set, and I am not sure about bit 3. Other bits should be unset). What is your root filesystem? ext3 -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346148: checkroot.sh: does not properly handle fsck exit states
Package: initscripts Version: 2.86.ds1-6 Severity: critical Justification: may cause data loss Hi, I just noticed that my laptop, at bootup, started an fsck for the root filesystem, claiming that it was a filesystem with errors. When it was about 20% done, it exited, and told me to rerun it manually. I expected a prompt for my root password and to be put in single-user mode, but this did not happen; instead, my system did a normal boot. This should _never_ happen! If the fsck fails, all sorts of bad things might have happened with the file system; continueing the boot at that point is a very good way to lose all your data. I was lucky to have spotted it... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.4 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages initscripts depends on: ii coreutils 5.93-5 The GNU core utilities ii dpkg 1.13.11package maintenance system for Deb ii e2fsprogs 1.38+1.39-WIP-2005.12.10-1 ext2 file system utilities and lib ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii lsb-base 3.0-13 Linux Standard Base 3.0 init scrip ii util-linux2.12r-2Miscellaneous system utilities initscripts recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345975: FTBFS: wenglish no longer exists
Package: bsdgames Version: 2.17-4 Severity: serious Hi, bsdgames build-depends on wenglish. However, this package no longer exists; you may want to modify that to say wbritish or wamerican instead. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.4 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages bsdgames depends on: ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libncurses5 5.5-1 Shared libraries for terminal hand ii libstdc++64.0.2-5The GNU Standard C++ Library v3 ii wamerican [wordlist] 6-2American English dictionary words ii wbritish [wordlist] 6-2British English dictionary words f ii wdutch [wordlist] 1:0.1e-41 list of Dutch words bsdgames recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339344: acknowledged by developer (Bug#339344: fixed in belpic 2.3.13.full-5)
On Mon, Nov 21, 2005 at 05:11:49PM +0100, Bastian Blank wrote: reopen 339344 thank * Fix unsigned int/size_t confusion in eidlib/CertifManager.cpp (Closes: #339344). This was only one occurance of this conversion. I was afraid you'd do that :-) Could you please install the build dependencies in the unstable chroot on raptor? I'll go through it and fix them as I go, then. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327736: This isn't tk8.4's fault
reassign 327746 tk8.4 severity 327746 grave reassign 327736 tk8.4 severity 327736 grave merge 327736 327746 retitle 327736 tk8.4: needs to be rebuilt on m68k tags 327736 + pending thanks Hi, It appears tk8.4 was built with binutils 2.16.1cvs20050902, which is utterly broken on m68k, in that it produces corrupt ELF binaries (see #327780 for details). I've queued tk8.4 for a binNMU on m68k, and registered ocaml as dep-waiting on a higher-than-current version of tk8.4. Feel free to close this once a rebuilt version of tk8.4 has been uploaded. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327780: [EMAIL PROTECTED]: Re: [Bug ld/1775] New: Invalid code in PLT section]
Seems there's a fix already... - Forwarded message from Alan Modra [EMAIL PROTECTED] - Date: Wed, 2 Nov 2005 09:25:55 +1030 From: Alan Modra [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Bug ld/1775] New: Invalid code in PLT section Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.4i X-Spam-Level: X-Spam-Status: No, score=0.3 required=4.0 tests=BAYES_00,SUBJECT_DRUG_GAP_VIC autolearn=no version=3.0.3 On Tue, Nov 01, 2005 at 02:14:45PM -, wouter at grep dot be wrote: As discussed in Debian bug#327780 (http://bugs.debian.org/327780), binutils are currently broken on m68k. The culprit seems to be revision 1.74 of src/elf32-m68k.c, which adds ColdFire V4E PLT support but somehow breaks regular m68k PLT support in doing so. A quick glance over the rev 1.74 patch shows up the following lack of parentheses. * elf32-m68k.c (elf_m68k_finish_dynamic_symbol): Add required parentheses. Index: bfd/elf32-m68k.c === RCS file: /cvs/src/src/bfd/elf32-m68k.c,v retrieving revision 1.83 diff -u -p -r1.83 elf32-m68k.c --- bfd/elf32-m68k.c6 Oct 2005 19:21:14 - 1.83 +++ bfd/elf32-m68k.c1 Nov 2005 22:52:20 - @@ -1871,7 +1871,7 @@ elf_m68k_finish_dynamic_symbol (output_b + got_offset - (splt-output_section-vma + h-plt.offset -+ CFV4E_FLAG (output_bfd) ? 8 : 2), ++ (CFV4E_FLAG (output_bfd) ? 8 : 2)), splt-contents + h-plt.offset + plt_off1); bfd_put_32 (output_bfd, plt_index * sizeof (Elf32_External_Rela), @@ -1884,7 +1884,7 @@ elf_m68k_finish_dynamic_symbol (output_b (splt-output_section-vma + splt-output_offset + h-plt.offset - + CFV4E_FLAG (output_bfd) ? 12 : 8), + + (CFV4E_FLAG (output_bfd) ? 12 : 8)), sgot-contents + got_offset); /* Fill in the entry in the .rela.plt section. */ -- Alan Modra IBM OzLabs - Linux Technology Centre - End forwarded message - -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327780: Some info
To at least give someone a start to track down this bug... I played a bit with objdump today, trying to find out what the hell is going wrong. According to gdb, this is what happens when I try to run an application compiled with the broken binutils: #0 0x82e0 in ?? () (gdb) I then did 'objdump -D binary', and got the following at that address (section .plt): 82e0: 4efb 0171 8000 jmp %pc@(28b6 _init-0x7fffd9fa)@() 82e6: 25d4 whereas the exact same source compiled with working binutils produces this (different address, but it's also the sixth instruction in the .plt section): 8380: 4efb 0171 jmp %pc@(8000267c _GLOBAL_OFFSET_TABLE_+0xc)@() 8386: 22fa I think it's clear that the first is totally wrong in that it tries to jump to an address outside the code section. If required, I can send the binaries (both the broken and the working one) and a core file. I'll try to further identify the bug myself, but I don't know much about binutils' internals or the ELF file format, so don't expect much luck... -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327780: Cause
tags 327780 + patch
thanks
Hi,
With a little help from my friends (on IRC)...
I've identified the cause of this bug to be part of revision 1.74 of
bfd/elf32-m68k.c in the binutils source. I confirmed that it works by
producing a cross-binutils on my (powerpc) laptop from the binutils
source package with only that revision reversed.
I'm building a native binutils right now to verify, but I don't expect
any problems there.
The patch that I applied follows. Note that this completely removes the
PLT support for the ColdFire V4E (i.e., it's a verbatim reversion of
revision 1.74), so it's not really suitable for upstream; but since
Debian doesn't support the V4E (yet), this should do for the moment --
unless someone identifies the bug Real Soon and fixes it :-)
--- elf32-m68k.c.orig 2005-08-31 05:27:29.0 +0200
+++ elf32-m68k.c2005-10-31 20:25:40.0 +0100
@@ -217,37 +217,6 @@
0, 0, 0, 0 /* replaced with offset to start of .plt. */
};
-
-#define CFV4E_PLT_ENTRY_SIZE 24
-
-#define CFV4E_FLAG(abfd) (elf_elfheader (abfd)-e_flags EF_CFV4E)
-
-static const bfd_byte elf_cfv4e_plt0_entry[CFV4E_PLT_ENTRY_SIZE] =
-{
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to .got + 4. */
- 0x2f, 0x3b, 0x08, 0xfa, /* move.l (%pc,addr),-(%sp) */
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to .got + 8. */
- 0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
- 0x4e, 0xd0, /* jmp (%a0) */
- 0x4e, 0x71 /* nop */
-};
-
-/* Subsequent entries in a procedure linkage table look like this. */
-
-static const bfd_byte elf_cfv4e_plt_entry[CFV4E_PLT_ENTRY_SIZE] =
-{
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to symbol's .got entry. */
- 0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
- 0x4e, 0xd0, /* jmp (%a0) */
- 0x2f, 0x3c, /* move.l #offset,-(%sp) */
- 0, 0, 0, 0, /* Replaced with offset into relocation table. */
- 0x60, 0xff, /* bra.l .plt */
- 0, 0, 0, 0 /* Replaced with offset to start of .plt. */
-};
-
#define CPU32_FLAG(abfd) (elf_elfheader (abfd)-e_flags EF_CPU32)
#define PLT_CPU32_ENTRY_SIZE 24
@@ -1013,8 +982,6 @@
{
if (CPU32_FLAG (dynobj))
s-size += PLT_CPU32_ENTRY_SIZE;
- else if (CFV4E_FLAG (dynobj))
- s-size += CFV4E_PLT_ENTRY_SIZE;
else
s-size += PLT_ENTRY_SIZE;
}
@@ -1036,8 +1003,6 @@
/* Make room for this entry. */
if (CPU32_FLAG (dynobj))
s-size += PLT_CPU32_ENTRY_SIZE;
- else if (CFV4E_FLAG (dynobj))
- s-size += CFV4E_PLT_ENTRY_SIZE;
else
s-size += PLT_ENTRY_SIZE;
@@ -1823,19 +1788,17 @@
corresponds to this symbol. This is the index of this symbol
in all the symbols for which we are making plt entries. The
first entry in the procedure linkage table is reserved. */
- if (CPU32_FLAG (output_bfd))
-plt_index = (h-plt.offset / PLT_CPU32_ENTRY_SIZE) - 1;
- else if (CFV4E_FLAG (output_bfd))
- plt_index = (h-plt.offset / CFV4E_PLT_ENTRY_SIZE) - 1;
+ if ( CPU32_FLAG (output_bfd))
+plt_index = h-plt.offset / PLT_CPU32_ENTRY_SIZE - 1;
else
-plt_index = (h-plt.offset / PLT_ENTRY_SIZE) - 1;
+plt_index = h-plt.offset / PLT_ENTRY_SIZE - 1;
/* Get the offset into the .got table of the entry that
corresponds to this function. Each .got entry is 4 bytes.
The first three are reserved. */
got_offset = (plt_index + 3) * 4;
- if (CPU32_FLAG (output_bfd))
+ if ( CPU32_FLAG (output_bfd))
{
/* Fill in the entry in the procedure linkage table. */
memcpy (splt-contents + h-plt.offset, elf_cpu32_plt_entry,
@@ -1844,14 +1807,6 @@
plt_off2 = 12;
plt_off3 = 18;
}
- else if (CFV4E_FLAG (output_bfd))
-{
- memcpy (splt-contents + h-plt.offset, elf_cfv4e_plt_entry,
- CFV4E_PLT_ENTRY_SIZE);
- plt_off1 = 2;
- plt_off2 = 14;
- plt_off3 = 20;
- }
else
{
/* Fill in the entry in the procedure linkage table. */
@@ -1864,12 +1819,11 @@
/* The offset is relative to the first extension word. */
bfd_put_32 (output_bfd,
- sgot-output_section-vma
- + sgot-output_offset
- + got_offset
- - (splt-output_section-vma
-+ h-plt.offset
-+ CFV4E_FLAG (output_bfd) ? 8 : 2),
+ (sgot-output_section-vma
+ + sgot-output_offset
+ + got_offset
+ - (splt-output_section-vma
+ + h-plt.offset + 2)),
splt-contents + h-plt.offset + plt_off1);
bfd_put_32 (output_bfd, plt_index * sizeof (Elf32_External_Rela),
@@
Bug#334030: fix up SNAFU
submitter 334030 ! retitle 334030 perl_5.8.7-6(m68k/unstable): FTBFS: failed test suite t/op/rand.t thanks I seriously fucked up with this one. LaMon gave me his scripts that he uses to handle bug reports, and this was the first time I tried the 'bug' feature of those things. When I found that a) it still said lamont rather than wouter, and b) it did not include the test at all, I wanted to abort -- which failed miserably. Sorry 'bout that. Anyway; the 'make test' is now running -- I'll let you know what happens after that. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330466: New revision
On Sat, Oct 01, 2005 at 12:52:12PM +0200, Davide Puricelli wrote: Hi, I prepared a new revision of xchat 2.4.5 that should fix the issues on powerpc, you can grab it from http://people.debian.org/~evo/upload Please provide me with feedback about it, I don't have powerpc hardware to test it. Yeah, that one works. Thanks. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330466: does not parse server replies correctly anymore
Package: xchat Version: 2.4.5-1 Severity: grave Justification: Makes the package unusable by most or all users Hi, Since two or three days, I cannot use xchat on my machine anymore. It will start, it will connect to the FreeNode and OFTC network's servers correctly, and it will even join channels; however, it will not correctly parse the server's replies when those joins have been successful (marking them as 'GARBAGE' instead); as a result, xchat will think I'm not in any channel, requiring me to type '/msg #channel something' if I want to say anything to that channel. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.2 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages xchat depends on: ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libglib2.0-0 2.8.1-1The GLib library of C routines ii libgtk2.0-0 2.6.10-1 The GTK+ graphical user interface ii libpango1.0-0 1.8.2-2Layout and rendering of internatio ii libperl5.85.8.7-5Shared Perl library ii libssl0.9.7 0.9.7g-2 SSL shared libraries ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii python2.3 2.3.5-8An interactive high-level object-o ii tcl8.48.4.11-1 Tcl (the Tool Command Language) v8 ii xchat-common 2.4.5-1Common files for X-Chat ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m xchat recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328975: Please ignore libcrypto++5.2.1c2-6
On Sun, Sep 25, 2005 at 09:52:00PM +0200, Adeodato Simó wrote: * Jens Peter Secher [Sun, 25 Sep 2005 13:47:20 +0200]: Wouter Verhelst [EMAIL PROTECTED] writes: On Sat, Sep 24, 2005 at 09:55:43AM +0200, Jens Peter Secher wrote: libcrypto++5.2.1c2-6 is in needs-build state, but I am pretty sure it won't build cleanly, since it didn't on other architectures using GCC 3.4, so please remove it from the build queue. Sorry, I see that libcrypto++ previously failed to build with an internal compiler error. Did you try to build it with GCC 3.4 for that reason? If so, you can revert that change -- gcc 4.0 has seen a recent update which should fix those ICEs. Are you positive about this, Wouter? I have confirmed that five builds which previously failed now complete successfully (the three upstream PRs I filed plus flac and zlib). Does that mean they'll all succeed? Maybe not; but as this change lets 40 previously-failing tests from the test suite now succeed, I'm pretty sure many of them will now work. libcrypto++ suffered the famous in cp_expr_size, at cp/cp-objcp-common.c:101 ICE that affects arm, m68k and hppa; this is Debian Bug#323133 and upstream PR21123, which doesn't seem at all like fixed? Okay, then I've probably been too optimistic about it in this particular case. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond
Bug#329068: Segfaults at startup
Package: wml Version: 2.0.8-11 Severity: grave Hi, wml segfaults at startup on my (powerpc) laptop. Typical scenario: [EMAIL PROTECTED]:~/debian/webwml$ make install make -C english install make[1]: Entering directory `/home/wouter/debian/webwml/english' make -C po install make[2]: Entering directory `/home/wouter/debian/webwml/english/po' make[2]: Nothing to be done for `install'. make[2]: Leaving directory `/home/wouter/debian/webwml/english/po' wml -q -D CUR_YEAR=2005 -o UNDEFuEN:[EMAIL PROTECTED] contact.wml sh: line 1: 4342 Segmentation fault /usr/lib/wml/exec/wml_p3_eperl -dWML_TMPDIR=/tmp/wml.LRECGK -dWML_VERSION=2.0.8 (30-Oct-2001) -dWML_LOC_MANDIR=/usr/share/man -dWML_LOC_DATADIR=/usr/share/wml -dWML_LOC_LIBDIR=/usr/lib/wml -dWML_LOC_BINDIR=/usr/bin -dWML_LOC_PREFIX=/usr -dWML_GEN_HOSTNAME=country -dWML_GEN_REALNAME=Wouter Verhelst -dWML_GEN_USERNAME=wouter -dWML_GEN_GMT_ISOTIME=2005-09-19 08:52:36 -dWML_GEN_GMT_CTIME=Mon Sep 19 08:52:36 2005 -dWML_GEN_ISOTIME=2005-09-19 10:52:36 -dWML_GEN_CTIME=Mon Sep 19 10:52:36 2005 -dWML_GEN_TIME=1127119956 -dWML_SRC_REALNAME=Wouter Verhelst -dWML_SRC_USERNAME=wouter -dWML_SRC_GMT_ISOTIME=2003-05-26 18:27:45 -dWML_SRC_GMT_CTIME=Mon May 26 18:27:45 2003 -dWML_SRC_ISOTIME=2003-05-26 20:27:45 -dWML_SRC_CTIME=Mon May 26 20:27:45 2003 -dWML_SRC_TIME=1053973665 -dWML_SRC_BASENAME=contact -dWML_SRC_FILENAME=contact.wml -dWML_SRC_DIRNAME=/home/wouter/debian/webwml/english -dHOME=. -dWML_SRC_USERNAME=webmaster -dSEARCH=http://search.debian.org/; -dWML_GEN_HOSTNAME=debian.org -dCUR_YEAR=2005 -dVOTE=vote -dDOC=doc -dBUGS=Bugs -dCUR_ISO_LANG=en -dDISTRIB=distrib -dPICS=Pics -dCUR_LANG=English -dHTMLDIR=../../debian.org -dENGLISHDIR=../english -dCHARSET=iso-8859-1 -dINTRO=intro -dWML_SRC_REALNAME=Debian Webmaster -dMISC=misc -dDEVEL=devel -dSTYLE=style -dCHINESE=intl/zh -P -k -B ':' -E ':' /tmp/wml.LRECGK/wml.4328.tmp1.wml /tmp/wml.LRECGK/wml.4328.tmp2.wml ** WML:Break: Error in Pass 3 (rc=139). make[1]: *** [contact.en.html] Error 1 make[1]: Leaving directory `/home/wouter/debian/webwml/english' make: *** [english-install] Error 2 [EMAIL PROTECTED]:~/debian/webwml$ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages wml depends on: ii eperl 2.2.14-12 Embedded Perl 5 Language ii iselect 1.2.0-12 An interactive line selection tool ii libbit-vector-perl6.4-4 Perl and C library for bit vectors ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libimage-size-perl2.992-2determine the size of images in se ii libterm-readkey-perl 2.30-2 A perl module for simple terminal ii m41.4.3-2a macro processing language ii mp4h 1.3.1-2Macro processor for HTML documents ii perl 5.8.7-5Larry Wall's Practical Extraction ii perl-base [perlapi-5.8.4] 5.8.7-5The Pathologically Eclectic Rubbis ii slice 1.3.8-6Extract out pre-defined slices of Versions of packages wml recommends: pn libhtml-clean-perlnone (no description available) pn linklint none (no description available) pn tidy none (no description available) pn txt2html none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327780: current gcc-4.0 is utterly useless on m68k
Package: gcc-4.0
Version: 4.0.1-6
Severity: grave
Justification: renders package unusable
Hi,
Script started on Mon Sep 12 08:22:21 2005
[EMAIL PROTECTED]: /home/wouter~$ cat foo.c
int main() {
;
return 0;
}
[EMAIL PROTECTED]:~$ gcc -o foo foo.c
[EMAIL PROTECTED]:~$ ./foo
Segmentation fault
[EMAIL PROTECTED]:~$
Since this is exactly what configure-scripts try to compile to see
whether the C compiler works, nothing will compile on m68k anymore.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: m68k
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-mvme16x
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages gcc-4.0 depends on:
ii binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii cpp-4.0 4.0.1-6 The GNU C preprocessor
ii gcc-4.0-base 4.0.1-6 The GNU Compiler Collection (base
ii libc62.3.5-6 GNU C Library: Shared libraries an
ii libgcc2 4.0.1-6 GCC support library
Versions of packages gcc-4.0 recommends:
ii libc6-dev 2.3.5-6GNU C Library: Development Librari
pn libmudflap0-dev none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327780: Too hasty
reassign 327780 binutils found 327780 2.16.1cvs20050902-1 thanks Sorry, I was a bit too hasty. Current gcc is quite some time in the archive already, so it's unlikely it's at fault. Binutils, OTOH, has seen a recent upload. Downgrading it to the previous version indeed fixes the segfault issues. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317738: libccscript: FTBFS: missing b-dep on doxygen
Package: libccscript Version: 2.5.7-4 Severity: serious Hi, There was an error trying to autobuild your package. From the build log: Automatic build of libccscript_2.5.7-4 on kiivi by sbuild/m68k 27 Build started at 20050711-0736 ** [...] Build-Depends: debhelper ( 3.0.0), libcommoncpp2-dev (= 1.3.10-4), libxml2-dev Checking for already installed source dependencies... debhelper: already installed (4.9.3 3.0.0 is satisfied) libcommoncpp2-dev: missing libxml2-dev: missing [...] make[2]: Leaving directory `/build/buildd/libccscript-2.5.7' (cd doc ; doxygen Doxyfile) /bin/sh: doxygen: command not found make[1]: *** [doxy] Error 127 make[1]: Leaving directory `/build/buildd/libccscript-2.5.7' make: *** [install] Error 2 It would appear you need to add a build-dependency to doxygen; also note that if it's used in the 'build' target of the debian/rules file, you need to add it to build-depends rather than build-depends-indep. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
On Fri, Jul 01, 2005 at 04:34:54PM -0400, Glenn Maynard wrote: The fact that you're trying to coerce a maintainer to include a work instead of attempting to address his reasons for doing so, is enough for me to agree with Joey's decision. That doesn't actually seem to me to be what he's doing. Rather, the DIG maintainer saw his HOWTO, liked it, and incorporated it in the install guide. There's a major difference. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
On Fri, Jul 01, 2005 at 11:15:36PM -0400, David Nusinow wrote: Ok, change committed. You are now attributed in the administrivia section. Thanks for the great doc. You suck. You know you just ended a potentially great and entertaining flamewar by leaving one side without arguments? ;-) (jk, of course. Thanks for doing the reasonable thing) -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306375: gnome-python/experimental/m68k: FTBFS: insufficient build-dependency on gconf
Package: gnome-python Version: 2.10.0-1 Severity: serious Hi, There was an error trying to autobuild your package. From the build log: Automatic build of gnome-python_2.10.0-1 on quickstep by sbuild/m68k 1.170.5 Build started at 20050425-2025 ** [...] Build-Depends: debhelper (= 4.2.28), dpatch, gnome-pkg-tools, python2.3-dev, python-gtk2-dev (= 2.4), python2.3-pyorbit (= 2.0.1), libgconf2-dev (= 2.0), libgtk2.0-dev (= 2.4), libgnome2-dev (= 2.8), libgnomeui-dev (= 2.8), libgnomecanvas2-dev (= 2.0), libgnomevfs2-dev (= 2.0), libbonobo2-dev (= 2.6), libbonoboui2-dev (= 2.0), librsvg2-dev (= 2.0), libgnome-desktop-dev (= 2.0), python (= 2.3) [...] checking GNOMECANVAS_LIBS... -Wl,--export-dynamic -lgnomecanvas-2 -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 checking for gnome-vfs-2.0 = 2.9.0 pyorbit-2 = 2.0.1... checking for gconf-2.0 = 2.9.0... configure: error: gconf-2.0 is required. make: *** [build-2.3/config.status] Error 1 It would seem that you need to modify your build-dependency on libgconf2-dev to specify at least that version. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306383: synaptic/experimental/m68k: FTBFS: undeclared variable
Package: synaptic Version: 0.55+cvs20050325-1.1 Severity: serious Hi, There was an error trying to autobuild your package. From the build log: Automatic build of synaptic_0.55+cvs20050325-1.1 on quickstep by sbuild/m68k 1.170.5 Build started at 20050426-0421 ** [...] if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/apt-pkg -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libglade-2.0 -I/usr/include/libxml2 -DSYNAPTICLOCALEDIR=\/usr/share/locale\ -DSYNAPTICSTATEDIR=\/var/lib/synaptic\-g -O2 -MT rpackage.o -MD -MP -MF .deps/rpackage.Tpo \ -c -o rpackage.o `test -f 'rpackage.cc' || echo './'`rpackage.cc; \ then mv -f .deps/rpackage.Tpo .deps/rpackage.Po; \ else rm -f .deps/rpackage.Tpo; exit 1; \ fi rpackage.cc: In member function `bool RPackage::isTrusted()': rpackage.cc:697: error: `IsTrusted' undeclared (first use this function) rpackage.cc:697: error: (Each undeclared identifier is reported only once for each function it appears in.) make[3]: *** [rpackage.o] Error 1 [...] For your convenience, a full build log can be found through http://experimental.ftbfs.de/ -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306381: python-cherrypy/experimental/m68k: FTBFS: missing b-dep on python
Package: python-cherrypy Version: 2.0.0b-1 Severity: serious Hi, There was an error when trying to autobuild your package. From the build log: Automatic build of python-cherrypy_2.0.0b-1 on quickstep by sbuild/m68k 1.170.5 Build started at 20050426-0408 ** [...] Build-Depends: cdbs, debhelper (= 4.1.0) [...] python setup.py clean -a make: python: Command not found [...] cd . python setup.py build --build-base=./build /bin/sh: python: command not found make: *** [common-build-impl] Error 127 Looks like you're missing a build-dependency on python. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299471: FTBFS: config.sub not executable
Package: grip Version: 3.2.0-4 Severity: serious Justification: no longer builds from source Hi, There was an error trying to build your package from source. From the build log: Automatic build of grip_3.2.0-4 on kiivi by sbuild/m68k 1.170.5 Build started at 20050313-2154 ** [...] checking sun/audioio.h usability... no checking sun/audioio.h presence... no checking for sun/audioio.h... no configure: error: cannot run /bin/sh ./config.sub make: *** [config.status] Error 1 [...] As usual, a full build log can be found on http://buildd.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
