Bug#405849: [INTL:nl] Updated dutch po-debconf translation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: phppgadmin Version: 4.0.1-3 Severity: wishlist Tags: patch l10n Please find attached the updated dutch po-debconf translation. This translation has been vetted by the review process of the debian-l10n-dutch team. Please add it to your next package revision, it should be inserted in your package build-tree as debian/po/nl.po, TIA - -- Cheers, Kurt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFn/AnLJnDdKPNTXoRArmlAJ9E6BtLmNCiHdYfBtCcfPBIQfaQMwCfS/sY 9/X2ACfRd89yG9exl+WwlQk= =ZaWD -END PGP SIGNATURE- # translation of phppgadmin_4.0.1-3_templates.po to debian-l10n-dutch # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans# #Developers do not need to manually edit POT or PO files. # # Kurt De Bree <[EMAIL PROTECTED]>, 2006. # This is an unofficial translation # msgid "" msgstr "" "Project-Id-Version: phppgadmin_4.0.1-3_templates\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2006-12-07 08:06+0100\n" "PO-Revision-Date: 2006-12-28 23:50+0200\n" "Last-Translator: Kurt De Bree <[EMAIL PROTECTED]>\n" "Language-Team: debian-l10n-dutch \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.10.2\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #. Type: select #. Choices #: ../phppgadmin.templates:1001 msgid "Apache" msgstr "Apache" #. Type: select #. Choices #: ../phppgadmin.templates:1001 msgid "Apache-SSL" msgstr "Apache-SSL" #. Type: select #. Choices #: ../phppgadmin.templates:1001 msgid "Apache-Perl" msgstr "Apache-Perl" #. Type: select #. Choices #: ../phppgadmin.templates:1001 msgid "Apache2" msgstr "Apache2" #. Type: select #. Choices #: ../phppgadmin.templates:1001 msgid "None" msgstr "Geen" #. Type: select #. Description #: ../phppgadmin.templates:1002 msgid "Web server to reconfigure automatically:" msgstr "Automatisch te herconfigureren webserver:" #. Type: select #. Description #: ../phppgadmin.templates:1002 msgid "" "phpPgAdmin supports any web server that PHP4 does, but this automatic " "configuration process only supports Apache servers." msgstr "" "phpPgAdmin ondersteunt elke webserver die ook door php4 wordt ondersteund, " "maar dit automatische configuratieproces ondersteunt uitsluitend Apache " "servers."
Bug#405848: [INTL:nl] Updated dutch po-debconf translation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: netselect Version: 0.3.ds1-9 Severity: wishlist Tags: patch l10n Please find attached the updated dutch po-debconf translation. This translation has been vetted by the review process of the debian-l10n-dutch team. Please add it to your next package revision, it should be inserted in your package build-tree as debian/po/nl.po, TIA - -- Cheers, Kurt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFn+9eLJnDdKPNTXoRAmAIAJ4+lUTAKEz7+qqiIfmm4dB1glF7twCeKhNP 5igPXIQATa90zc9r60nm5zo= =HirT -END PGP SIGNATURE- # Translation of netselect_0.3.ds1-9_templates.po to Dutch # # This file is distributed under the same license as the netselect package. # Please see debian/copyright. # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans# #Developers do not need to manually edit POT or PO files. # msgid "" msgstr "" "Project-Id-Version: netselect_0.3.ds1-9_nl\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2006-12-06 16:46+0100\n" "PO-Revision-Date: 2006-12-28 23:40+0200\n" "Last-Translator: Kurt De Bree \n" "Language-Team: Dutch \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.10.2\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Do you want netselect to be installed setuid root?" msgstr "Wilt u netselect installeren met de 'set-user-id' bit als root?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Netselect can be installed with the set-user-id bit set, so that it will run " "with the permissions of the 'root' user. Since netselect needs these " "permissions to work properly, ordinary users cannot run it unless it is " "installed this way." msgstr "" "Netselect kan geïnstalleerd worden met de 'set-user-id' bit als root " "waardoor het als root wordt uitgevoerd (en dus met beheerdersrechten). Daar " "netselect deze rechten nodig heeft om correct te werken, kunnen gewone " "gebruikers deze niet gebruiken, tenzij het op deze wijze geïnstalleerd is" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Enabling this feature may be a security risk, so it is disabled by default. " "If in doubt, it is suggested to leave it disabled." msgstr "" "Standaard is deze optie uitgeschakeld, aangezien het inschakelen een " "veiligheidsrisico kan zijn. Bij twijfel is het aangeraden deze optie " "uitgeschakeld te laten."
Bug#353346: libtool_1.9+20051221-1(hppa/experimental): FTBFS: segv in test
On Fri, Feb 17, 2006 at 06:00:17PM +0100, Ralf Wildenhues wrote: > Hi Frank, > > * Frank Lichtenheld wrote on Fri, Feb 17, 2006 at 05:19:37PM CET: > > Package: libtool > > Version: 1.9+20051221-1 > > Severity: serious > > This looks like the test suite failed, but not like the source failed to > build. Is a successful `make check' prerequisite for a successful > build? If yes: is the gcj compiler broken on hppa or did I simply mess > up with the very little java foo I have (look at tests/convenience.at, > search for "Java convenience archives")? Yes, the make check must run without errors before it's considered a good build. I also think this is a problem of the hppa gcj. I think hppa was having all kind of weird problems, and have no idea if they're resolved. I'll try to look at this later. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347650: libtool: Incorrect argument reordering
On Sat, Feb 18, 2006 at 09:07:19PM +0100, Loïc Minier wrote: > On mer, jan 11, 2006, Kurt Roeckx wrote: > > I suggest if you create a convience library, you don't link any > > libraries to it at that time. Instead, when you are linking in > > the convience libraries to something, at that point you should > > add those libraries. This will avoid libtool from adding all the > > depedency libraries on the command line. > > Unfortunately, the convenience library depends on another libtool > archive which is not a convenience lib, but a real library. Beside, > that convenience libcommon.la is used in some places, and it would be > inconvenient to change that (ie. upstream probably wouldn't like it). > > I'm not sure why libtool has to link all dependency_libs of a > convenience library. When you create a convenience library, and at that time you tell it to link to some libraries, it will add all the those libraries you had on the command line, and all the ones that those depend on, to dependency_libs, like it always does. When you then link something to that convenience library, it will add the libraries in the dependency_libs to the link line. It's doing this because you told that the library needs symbols from the libraries you had on the command line, and it's also linking in all the libraries required by those. One solution to this would be to only store the libraries that were on the command line in dependency_libs, and I've suggested that to upstream, but they see problems with it, and we're working on it. A workaround is not telling it which libraries the convenience library needs, so you end up with an empty dependency_libs. And then when linking to the convenience library you also link to those that it requires. This might require some changes, but it's the only workaround I know that would solve your problems in the short turn. Kurt
Bug#338006: [Pkg-openssl-devel] Bug#338006: Postfix problem still there
On Mon, Feb 20, 2006 at 12:32:38PM +0100, Martin Sebald wrote: > Hello Kurt, > > will/could the changes in 0.9.8a-7 have any effect on the postfix issues > I'm experiencing? Is it worth a try? It might be. It seems that postfix is using the BIO interface, so it might be your problem. It never hurts to check, so we can rule things out. > If you need any detailed information about the postfix configuration I'm > running I will be happy to hand it over to you. What I need is a way to reproduce it. I don't think having your setup is going to help me, but feel free to send me the details. Maybe I should look at setting up postfix with ssl myself. Can you reproduce it when using s_client? Like: openssl s_client -starttls smtp -crlf -connect localhost:25 -bugs -no_ssl2 Try playing with some options, like adding -ssl3/-no_ssl3 or -tls1. Also see man s_client(1). Also try the same thing several times, it might work with some luck, and might fail the next time. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353346: gcj can't make shared libs on hppa.
reassign 353346 gcj-4.0
retitle 353346 gcj can't make shared libs on hppa.
thanks
Hi,
It seems that gcj can't make proper shared libs on hppa, or is
doing something else strange.
This is tested with gcj-4.0 4.0.2-9
[EMAIL PROTECTED]:~/libtool-1.9+20051221/tests/testsuite.dir/12/test$ cat
A1.java
public class A1 {
};
[EMAIL PROTECTED]:~/libtool-1.9+20051221/tests/testsuite.dir/12/test$ cat
foo2.java
public class foo2 {
public static void main(String[] argv) {
}
}
$ gcj -g -O2 -c A1.java -fPIC -o A1.o
$ ar cru liba1.a A1.o
$ ranlib liba1.a
$ gcj -g -O2 -c foo2.java -o foo2.o
$ gcj -shared -Wl,--whole-archive ./liba1.a -Wl,--no-whole-archive -Wl,-soname
-Wl,liba1.so.0 -o liba1.so.0.0.0
$ ln -s liba1.so.0.0.0 liba1.so.0
$ gcj -g -O2 --main=foo2 -o main foo2.o ./liba1.so.0
$ LD_LIBRARY_PATH=. ./main
Segmentation fault (core dumped)
$ LD_LIBRARY_PATH=. gdb ./main core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "hppa-linux"...Using host libthread_db library
"/lib/libthread_db.so.1".
Program terminated with signal 11, Segmentation fault.
Reading symbols from
/home/kroeckx/libtool-1.9+20051221/tests/testsuite.dir/12/test/liba1.so.0...done.
Loaded symbols for ./liba1.so.0
Reading symbols from /lib/libgcc_s.so.2...done.
Loaded symbols for /lib/libgcc_s.so.2
Reading symbols from /usr/lib/libgcj.so.6...done.
Loaded symbols for /usr/lib/libgcj.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
#0 0x4fd23f00 in ?? ()
(gdb) bt
#0 0x4fd23f00 in ?? ()
Cannot find bounds of current function (@0x0), unwinding will fail.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
On Wed, Feb 22, 2006 at 02:45:20PM +0100, Andreas Jochens wrote: > > To fix this, I suggest to add the missing symlink /usr/lib64 -> /usr/lib > to the 'libc6-udeb' package in debian/sysdeps/amd64.mk in a similar > way as it is done for the 'libc6' package. The /lib64 -> lib symlink on d-i is created by the rootskel.udeb. Please atleast keep things in the same package. I wouldn't have a problem with moving this to the glibc package, and I think we should do that. But we should probably coordinate this with the d-i people. Anyway, I think we shouldn't need a /usr/lib64. The only reason we need a /lib64 is because that is where the dynamic linker is. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354048: doc++: Fails to install: trying to overwrite `/usr/share/locale/locale.alias', which is also in package locales
Package: doc++ Version: 3.4.10-3.2+b1 Severity: serious After the binNMU of doc++, I get the following error: Preparing to replace doc++ 3.4.10-3.2 (using .../doc++_3.4.10-3.2+b1_amd64.deb) ... Unpacking replacement doc++ ... dpkg: error processing /var/cache/apt/archives/doc++_3.4.10-3.2+b1_amd64.deb (--unpack): trying to overwrite `/usr/share/locale/locale.alias', which is also in package locales Errors were encountered while processing: /var/cache/apt/archives/doc++_3.4.10-3.2+b1_amd64.deb It should not be shipping an locale.alias. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354161: libx11: FTBFS in experimental: Missing .pc files.
Package: libx11 Version: 2:1.0.0-1 Severity: serious Tags: experimental Hi, Your package is failing to build with the following error: checking for BIGREQS... yes checking for XPROTO... yes checking for X11... configure: error: Package requirements (xextproto xtrans xau xcmiscproto) were not met: No package 'xau' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables X11_CFLAGS and X11_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [build-stamp] Error 1 libxau-dev is installed, and is version 6.9.0.dfsg.1-4, but it seems to need a .pc file, which only seems to be present in 1:1.0.0. It seems you need to require atleast the following versions: libxau-dev (>= 1:1.0.0) libxdmcp-dev (>= 1:1.0.0) (This has still some other 6.9 version installed, but seems to build without problems with those.) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354165: x11proto-core-dev: Wrong version requirement for x11-common.
Package: x11proto-core-dev Version: 7.0.4-1 Severity: serious Hi, You have a lot of packages with a Pre-Dependency on x11-common, but all with the wrong version. It says things like: Pre-Depends: x11-common (>= 0.99) Or: Pre-Depends: x11-common (>= 1.0) Which can be satisfied by 6.9.0.dfsg.1-4. It should be using 1:1.0 instead. Could you please fix this in all the packages without me having to submit a bug to each package? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354165: x11proto-core-dev: Wrong version requirement for x11-common.
merge 351779 354165 thanks Looks like they're the same, and I seem to have picked the same random one as Frank to report it against. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354167: libxext: FTBFS in experimental: Missing build dependency.
Package: libxext Version: 1:1.0.0-1 Severity: serious Tags: experimental Hi, Your package is failing to build with the following error: checking for XEXT... configure: error: Package requirements (xproto x11 xextproto xau) were not met: Package inputproto was not found in the pkg-config search path. Perhaps you should add the directory containing `inputproto.pc' to the PKG_CONFIG_PATH environment variable Package 'inputproto', required by 'X11', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables XEXT_CFLAGS and XEXT_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [build-stamp] Error 1 This seems to be a missing build dependency on x11proto-input-dev. It also can't find the xdmcp.pc, which looks like a missing build dependency on libxdmcp-dev, but please make sure it has a version requirement to have a version with a .pc file in it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354167: libxext: FTBFS in experimental: Missing build dependency.
reassign 354167 libx11-dev 1.0.0-1 thanks On Thu, Feb 23, 2006 at 09:49:42PM +0100, Kurt Roeckx wrote: > This seems to be a missing build dependency on > x11proto-input-dev. > > It also can't find the xdmcp.pc, which looks like a missing build > dependency on libxdmcp-dev, but please make sure it has a > version requirement to have a version with a .pc file in it. Both actually seem to be missing depedencies of libx11-dev. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: Postfix problem still there
On Mon, Feb 20, 2006 at 12:32:38PM +0100, Martin Sebald wrote: > Hello Kurt, > > will/could the changes in 0.9.8a-7 have any effect on the postfix issues > I'm experiencing? Is it worth a try? A new postfix version has been uploaded to unstable, which has as changelog entry: * New upstream, fixes various TLS/SASL bugs. I suggest you try that. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354825: Openntpd init script returns an error on shutdown.
On Wed, Mar 01, 2006 at 12:09:08PM +, Andrew Glen-Young wrote: > On running the init script with the 'stop' argument the script returns an > error: > # /etc/init.d/openntpd stop > Stopping openntpd: start-stop-daemon: warning: failed to kill 759: No > such process > ntpd. > > This also seems to affect later versions. I can't confirm this, but I > have looked through the Debian patches in 'unstable' and 'testing' and > they both seem to have the same problem. > > SOLUTION: > > I modified the init script to create a pidfile in the > /var/run/openntpd directory (which is created on install). That directory is supposed to be an empty directory. Nothing should be put in it. If you're going to create pid files, please just put in it /var/run/. Anyway, the problem is that there are 2 processes running, and start-stop-daemon tries to kill them both. This is how a strace looks: [pid 9136] 20:50:03.208773 kill(9130, SIGTERM) = 0 [pid 9136] 20:50:03.209378 kill(9129, SIGTERM) = -1 ESRCH (No such process) Doing the same with kill: 20:52:55.346234 kill(9168, SIGTERM) = 0 20:52:55.346899 kill(9167, SIGTERM) = -1 ESRCH (No such process) kill just doesn't complain about it. I agree it's an annoyance, you might think it didn't get stopped while it did. Also, it's just a warning, the script behaves like it is killed. Anyway, you could agrue that it's a bug in start-stop-daemon that it shouldn't give that warning in case you use the --quiet option, since it says it will only print error messages in that case. > Modified line 30 to read: > start-stop-daemon --start --quiet --make-pidfile > --pidfile=/var/run/openntpd/ntpd.pid --exec $DAEMON -- $DAEMON_OPTS Have you actually tried that? The pid file generated actually has the wrong pid in it. The problem is that ntpd does an other fork(), so your pid is ussually off by 1. (The manpage actually warns about this.) Also, you need to use the same pidfile when you stop it, or creating the pid file doesn't help at all. And if you do that, it doesn't get killed at all, since it has the wrong pid in it. Anyway, it seems you only get the message some times. Atleast, trying this alot of times, I only get it a few times. Which might appear as that your patch worked, while it actually didn't change a thing. The proper way to fix this would be to have ntpd create it's own pid file, and then use that when using --stop. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#287519: [pkg-mad-maintainers] Bug#287519: Assertion failed; buffer overflow
On Wed, Mar 01, 2006 at 02:37:09PM -0500, Justin Pryzby wrote: > Can I expect to see this bug fixed for etch? > > http://bugs.debian.org/287519 If someone comes up with a good patch, yes. I've looked at it, I can reproduce it, but I have to admit I don't understand enough about the code yet to be able to come up with a good fix. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#231609: lynx: SSL sites don't work with the gnutls library.
Hi, This seems to be a difference between how the openssl and the gnutls library return the name of the subject. For instance, for nm.debian.org, for the subject you get: /C=US/ST=Indiana/L=Indianapolis/O=Debian/OU=NM/CN=nm.debian.org/[EMAIL PROTECTED] While with gnutls you get: C=, ST=Indiana, L=Indianapolis, O=Debian, OU=NM, CN=nm.debian.org/[EMAIL PROTECTED] (I wonder why the C= doesn't say US in case of gnutls though.) So a version build with openssl is working without problems. Anyway, the openssl manpage says: NOTES The functions X509_NAME_oneline() and X509_NAME_print() are legacy functions which produce a non standard output form, they don't handle multi character fields and have various quirks and inconsistencies. Their use is strongly discouraged in new applications. Looking at the openssl library, I think it's best to use X509_NAME_get_index_by_NID/OBJ()/X509_NAME_get_entry(), and then go over the list of common names. But it looks like gnutls doesn't support that? The gnutls equivalent would be something like gnutls_x509_crt_get_issuer_dn_by_oid? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348133: [Pkg-openssl-devel] Processed: tagging patch
tags 348133 - patch thanks On Sun, Jan 15, 2006 at 12:03:04AM -0800, Debian Bug Tracking System wrote: > > tags 348133 patch There is no patch in the bug report, and even if there was, it's wrong. openssl.dirs already contains a etc/ssl/certs. I suggest you either close this bug, or reassign it to some other package. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348133: [Pkg-openssl-devel] Bug#348133: openssl: doesn't cleanup properly when uninstalling
On Sun, Jan 15, 2006 at 07:09:05AM +0100, Bart Martens wrote: > Package: openssl > Version: 0.9.8a-5 > Severity: minor > > The package openssl doesn't cleanup properly when uninstalling. Please > add debian/dirs and put etc/ssl/certs in debian/dirs. [EMAIL PROTECTED]:~# ls -l /etc/ssl/ ls: /etc/ssl/: No such file or directory [EMAIL PROTECTED]:~# apt-get install openssl Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: libssl0.9.8 Suggested packages: ca-certificates The following NEW packages will be installed: libssl0.9.8 openssl 0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded. Need to get 0B/1868kB of archives. After unpacking 4497kB of additional disk space will be used. Do you want to continue [Y/n]? y debconf: delaying package configuration, since apt-utils is not installed Selecting previously deselected package libssl0.9.8. (Reading database ... 11592 files and directories currently installed.) Unpacking libssl0.9.8 (from .../libssl0.9.8_0.9.8a-5_amd64.deb) ... Selecting previously deselected package openssl. Unpacking openssl (from .../openssl_0.9.8a-5_amd64.deb) ... Creating directory /etc/ssl Setting up libssl0.9.8 (0.9.8a-5) ... Setting up openssl (0.9.8a-5) ... [EMAIL PROTECTED]:~# ls -l /etc/ssl/ total 20 drwxr-xr-x 2 root root 4096 Jan 15 14:08 certs -rw-r--r-- 1 root root 9374 Dec 15 02:31 openssl.cnf drwx-- 2 root root 4096 Jan 15 14:08 private [EMAIL PROTECTED]:~# dpkg --purge libssl0.9.8 openssl (Reading database ... 11978 files and directories currently installed.) Removing openssl ... Purging configuration files for openssl ... Removing libssl0.9.8 ... Purging configuration files for libssl0.9.8 ... [EMAIL PROTECTED]:~# ls -l /etc/ssl/ ls: /etc/ssl/: No such file or directory Please explain me what is wrong with this. Note that the /etc/ssl/certs directory is empty, and you'll need the ca-certificates package to place files in it. Installing ca-certificates, openssl and libssl0.9.8, and then removing it: [EMAIL PROTECTED]:~# apt-get remove openssl libssl0.9.8 Reading package lists... Done Building dependency tree... Done The following packages will be REMOVED: ca-certificates libssl0.9.8 openssl 0 upgraded, 0 newly installed, 3 to remove and 1 not upgraded. Need to get 0B of archives. After unpacking 5050kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 12092 files and directories currently installed.) Removing ca-certificates ... Removing hash symlinks in /etc/ssl/certs ...done. Removing openssl ... Removing libssl0.9.8 ... [EMAIL PROTECTED]:~# dpkg --purge openssl (Reading database ... 11590 files and directories currently installed.) Removing openssl ... Purging configuration files for openssl ... dpkg - warning: while removing openssl, directory `/etc/ssl/certs' not empty so not removed. dpkg - warning: while removing openssl, directory `/etc/ssl' not empty so not removed. [EMAIL PROTECTED]:~# dpkg --purge ca-certificates (Reading database ... 11587 files and directories currently installed.) Removing ca-certificates ... Purging configuration files for ca-certificates ... [EMAIL PROTECTED]:~# ls -l /etc/ssl/ total 8 drwxr-xr-x 2 root root 8192 Jan 15 14:13 certs [EMAIL PROTECTED]:~# ls -l /etc/ssl/certs/ total 0 I don't see how this can be a bug in the openssl package at all. Maybe you want to file a bug against ca-certificates instead. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348181: mysql-query-browser: FTBFS: error: no matching function for call to 'MGResultSetModel::get_value(const Gtk::TreeIter&, int&, void*&, guint&) const'
Package: mysql-query-browser Version: 1.1.18-1 Severity: serious Hi, Your package is failing to build with the following error: MGResultSetModel.cc: In member function 'virtual void MGResultSetModel::get_value_vfunc(const Gtk::TreeIter&, int, Glib::ValueBase&) const': MGResultSetModel.cc:402: error: no matching function for call to 'MGResultSetModel::get_value(const Gtk::TreeIter&, int&, void*&, guint&) const' MGResultSetModel.cc:259: note: candidates are: bool MGResultSetModel::get_value(const Gtk::TreeIter&, unsigned int, void*&, size_t&) const make[4]: *** [MGResultSetModel.o] Error 1 make[4]: Leaving directory `/build/buildd/mysql-query-browser-1.1.18/mysql-quer y-browser/source/linux' make[3]: *** [all] Error 2 The problem seems to be that it accepts a size_t, which is an unsigned integer value, but depending on the arch it's either an int or a long. So a guint is the wrong type. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#287519: libmad: Assertion failed; buffer overflow
Hi, I've been trying to reproduce this bug with Glenn's testfile but was unable to do it. It gives all kind of error messages, but that is about all it does. Can someone still reproduce this problem? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: libssl0.9.8: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling - possible workaround
On Sun, Jan 15, 2006 at 04:15:53PM +0100, Sebastiaan wrote: > Hi, > > this bug broke my apache2/courier-imapd-ssl/squirrelmail configuration, > but I found a workaround posted somewhere in this list: > > http://lists.andrew.cmu.edu/pipermail/jeaton-test/2005-November.txt > > I used openssl_0.9.8a.orig.tar.gz and openssl_0.9.8a-5.diff.gz. In > debian/rules, change CONFARGS to: > CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl no-idea no-rc5 shared This does 3 things: - Add shared - Remove zlib - Remove no-mdc2 shared: I don't see how that would solve anything. It already builds a shared module. It builds a version with no-shared and 1 or more with shared depending on the arch. zlib: This will break things. See #334920, #333896, #335512. - no-mdc2: mdc2 is disabled because it's not free. (#65368) I also fail to see how adding it will make your problems go away. So I fail to see how this solves anything. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: libssl0.9.8: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling - possible workaround
On Sun, Jan 15, 2006 at 05:04:05PM +0100, Kurt Roeckx wrote: > On Sun, Jan 15, 2006 at 04:15:53PM +0100, Sebastiaan wrote: > > Hi, > > > > this bug broke my apache2/courier-imapd-ssl/squirrelmail configuration, > > but I found a workaround posted somewhere in this list: > > > > http://lists.andrew.cmu.edu/pipermail/jeaton-test/2005-November.txt To quote a part from that email: > You were right. If I change: > no-idea no-rc5 shared > > to: > zlib no-idea no-rc5 shared > > and rebuild, cyrus-imapd gives me that "bad record mac" error with the > resulting openssl. Removing "zlib" makes it go away. So it seem we have 2 things that conflict here. If we have zlib, it breaks applications, if we don't, it breaks others. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: libssl0.9.8: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling - possible workaround
On Sun, Jan 15, 2006 at 05:15:20PM +0100, Kurt Roeckx wrote: > To quote a part from that email: > > You were right. If I change: > > no-idea no-rc5 shared > > > > to: > > zlib no-idea no-rc5 shared > > > > and rebuild, cyrus-imapd gives me that "bad record mac" error with the > > resulting openssl. Removing "zlib" makes it go away. > > So it seem we have 2 things that conflict here. If we have zlib, > it breaks applications, if we don't, it breaks others. I should correct myself. We have 3 options for zlib: - no-zlib - zlib - zlib-dynamic Package breaks if we use zlib-dynamic and zlib1-dev is not installed, which is why we used zlib instead. Build with any of those options it fails with the "decryption failed or bad record mac" error. If either the server or the client do not support zlib, things work. And it seems that the 0.9.7 server doesn't use zlib, even though it was build with zlib support. I'm still not sure if this is a bug in the server or the client. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344662: cpufrequtils: FTBFS on amd64: tries to staticly link to sysfs.
Hi, The sysfsutils maintainer has removed the .la file, and now cpufrequtils has build succesfully. I think you can close this bug now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: libssl0.9.8: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling - possible workaround
On Sun, Jan 15, 2006 at 04:03:33PM -0800, Steve Langasek wrote: > > I should correct myself. We have 3 options for zlib: > > - no-zlib > > - zlib > > - zlib-dynamic > > > Package breaks if we use zlib-dynamic and zlib1-dev is not > > installed, which is why we used zlib instead. > > Fix zlib-dynamic to use /usr/lib/libz.so.1 properly instead of > /usr/lib/libz.so? > > > Build with any of those options it fails with the "decryption failed or > > bad record mac" error. > > "any of those options" means all of no-zlib, zlib, and zlib-dynamic? No, zlib or zlib-dynamic. So if there is support for zlib compression. > > If either the server or the client do not support zlib, things > > work. > > > And it seems that the 0.9.7 server doesn't use zlib, even though > > it was build with zlib support. > > > I'm still not sure if this is a bug in the server or the client. > > So what breaks if using no-zlib? You said "it breaks other [applications]; > which ones and how? I can't remember off hand, but I can look look for some. Basicly they use COMP_zlib. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345362: nut: mge-shut driver goes stale every 5 minutes.
On Mon, Jan 16, 2006 at 04:49:18PM +0100, Arnaud Quette wrote: > Hi Kurt, > > yup, better but still not fixed! > What are your current MAXAGE and DEADTIME values? They're the default values. So I think MAXAGE is 15. I can't find anything about DEADTIME in the documentation. > Please also send me an "upsc" output. $ upsc [EMAIL PROTECTED] battery.charge: 100 battery.charge.low: 30 battery.runtime: 01715 driver.name: mge-shut driver.parameter.port: /dev/ttyS0 driver.version: 2.0.2 driver.version.internal: 0.64 outlet.0.desc: Main Outlet outlet.0.id: 1 outlet.0.switchable: 0 outlet.1.autoswitch.charge.low: 80 outlet.1.desc: PowerShare Outlet 1 outlet.1.id: 2 outlet.1.switch: 1 outlet.1.switchable: 1 output.voltage: 230 ups.delay.shutdown: -1 ups.delay.start: -1 ups.load: 30 ups.mfr: MGE UPS SYSTEMS ups.model: ellipse 1200 ups.power.nominal: 1200 ups.serial: unknown ups.status: OL CHRG Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306106: openntpd: probably fails to adjust local clock
On Mon, Jan 16, 2006 at 03:52:47PM +, Andrew Stribblehill wrote:
> Package: openntpd
> Version: 3.7p1-1
> Followup-For: Bug #306106
>
> I see the same symptoms as the original submitter. However, when running
> it under strace, I see:
>
> write(2, "adjusting local clock by 0.17380"..., 35) = 35
> adjtimex({modes=32769, offset=171689, freq=0, maxerror=16384000,
> esterror=16384000, status=64, constant=2, precision=1,
> tolerance=33554432, time={1137426537, 876854}}) = 5
Note that openntpd does not call adjtimex(), but glibc wraps the
call adjtime() to adjtimex().
So modes is 0x8001 (32769):
#define ADJ_OFFSET_SINGLESHOT 0x8001 /* old-fashioned adjtime() */
> man 2 adjtimex tells me that a return code of 5 is:
>
> #define TIME_BAD 5 /* clock not synchronized */
>
> If nothing else, this is confusing behaviour.
That is because is it's syncrhonized, because it's using the
ADJ_OFFSET_SINGLESHOT. It doesn't mean there is an error.
Also note that on error it returns -1, and not 5.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#274367: glibc: [amd64] New GLIBC pass to create 32bit libc6-i386 and libc6-dev-i386 packages
Hi, Could someone please give an update of the status of this request? It seems to be open for a long time, and it would be nice to get rid of ia32-libs. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348754: kaffe: FTBFS on amd64: ecj problems?
Package: kaffe Version: 2:1.1.6.91-1 Severity: important Hi, Kaffe is failing to build on amd64 with the following error: 2. ERROR in /build/buildd/kaffe-1.1.6.91/build-tree/kaffe-1.1.6.91/libraries/ja valib/external/classpath/java/lang/Double.java (at line 72) public static final double MIN_VALUE = 5e-324; ^^ The literal 5e-324 of type double is out of range The full buildd log is available at: http://amd64.ftbfs.de/fetch.php?&pkg=kaffe&ver=2%3A1.1.6.91-1&arch=amd64&stamp=1137537824&file=log&as=raw This also looks alot like: http://bugs.debian.org/327407 PS: Maybe someone should clone or reassign this to ecj-bootstrap? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346958: xpad: FTBFS: undefined references
found 346958 2.10-2 thanks Hi, Your package is failing to build with error message like: xpad-session-manager.o: In function `xpad_session_manager_stop_interact':/build/buildd/xpad-2.10/src/xpad-session-manager.c:168: undefined reference to `SmcInteractDone' xpad-session-manager.o: In function `xpad_session_manager_ice_connection_watch' :/build/buildd/xpad-2.10/src/xpad-session-manager.c:175: undefined reference to `IceConnectionNumber' This looks like you're not linking to libraries you should. It might also mean that you're missing a few build depedencies. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348754: kaffe: FTBFS on amd64: ecj problems?
clone 348754 -1 reassign -1 ecj-bootstrap 3.0.1-5 thanks Cloning + reassigning this to ecj-bootstrap. Note that the last attempt was made with 3.1.1-4, but atleast 3.0.1-5 had the same problem. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [openssl.org #1204]: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Hi,
It seems to me that tls1_enc() is setting
SSL_OP_TLS_BLOCK_PADDING_BUG, while the other side does
not have that bug.
The code looks like this:
/* First packet is even in size, so check */
if ((memcmp(s->s3->read_sequence,
"\0\0\0\0\0\0\0\0",8) == 0) && !(ii &
1))
s->s3->flags|=TLS1_FLAGS_TLS_PADDING_BUG;
The 0.9.8 code seems to compress by default in case that
zlib compression has been added, while 0.9.7 doesn't.
This seems to generate a (compressed) package of size 45
in most cases, but 44 in some cases, depending on the
message being send.
In case it's 45, ii is set to 2 and i to 3, like it
should, but the flags get set to
TLS1_FLAGS_TLS_PADDING_BUG, and i gets decreased to 2. So
the lenth gets sets to 46 instead of 45.
I can not find a good way to always make sure this
workaround for that bug works proplery, but I think we
should assume there is no bug. So I propose the attached
patch to fix it. This should have as effect that in most
case that the bug is present, it still sets the flag, but
it won't in the case were the last byte just happens to be the
same as the padding byte.
This patch fixes it for me, so that two versions with
0.9.8 with zlib compression support can talk to each
other without errors.
Kurt
--- ssl/t1_enc.c.old2006-01-19 21:52:40.0 +0100
+++ ssl/t1_enc.c2006-01-19 21:59:26.0 +0100
@@ -632,7 +632,9 @@
{
/* First packet is even in size, so check */
if ((memcmp(s->s3->read_sequence,
- "\0\0\0\0\0\0\0\0",8) == 0) && !(ii &
1))
+ "\0\0\0\0\0\0\0\0",8) == 0) &&
+ !(ii & 1) &&
+ rec->data[l-i] != ii)
s->s3->flags|=TLS1_FLAGS_TLS_PADDING_BUG;
if (s->s3->flags & TLS1_FLAGS_TLS_PADDING_BUG)
i--;
Bug#348998: Hard drive detection failure
Package: Installer Version: x64 The current (unofficial) x64 release fails to detect my hard drive, system specs as follows: Gigabyte GA-K8NS-Pro motherboard (nForce 3 chipset) Ath-64 3200+ (754) 1GB RAM nVidia FX5200 graphics 128MB additional LAN RT 8139 12GB HDD (primary master) DVD-ROM (primary slave) DVD-RW (secondary master) Seagate 250GB SATA HDD on 3rd master Seagate 250GB SATA HDD on 4th master Initially it would only detect the 12GB drive (has 98se on it). I then tried disabling 1st and 3rd master under BIOS as I intended to install it on the 4th master, after which it would detect the drives I'd disabled but not the one I wanted to install it on. I then tried disconnecting the drives physically, with the result that it wouldn't detect any drives (also moved 4th to 3rd master, no diff). -- Kurt-theBeast-Frank, who swears that he will "Get-A-Life" just as soon as it can be mathematically proven to be better than what he has now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349252: kmymoney2: FTBFS: /usr/share/cdbs/1/class/autotools.mk: No such file or directory
Package: kmymoney2 Version: 0.8.2-1 Severity: serious Hi, Your package is failing to build with the following error: fakeroot debian/rules clean debian/rules:7: /usr/share/cdbs/1/class/autotools.mk: No such file or directory debian/rules:8: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory debian/rules:9: /usr/share/cdbs/1/rules/simple-patchsys.mk: No such file or directory debian/rules:10: /usr/share/cdbs/1/class/kde.mk: No such file or directory make: *** No rule to make target `/usr/share/cdbs/1/class/kde.mk'. Stop. This is probably caused by missing build dependencies. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349268: gcc-4.0: ICE building clisp on amd64.
Package: gcc-4.0
Version: 4.0.2-7
Severity: important
Hi,
When building clisp on amd64, I'm getting the following error:
gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-d
eclarations -Wno-sign-compare -O -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.
-fPIC -I.. -c calls.m.c -o calls.o
calls.c: In function 'get_block':
calls.c:843: error: unrecognizable insn:
(insn 173 172 174 0 (set (reg/f:DI 91)
(plus:DI (reg:DI 133)
(const_int 1125899906842624 [0x4]))) -1
(insn_list:REG_DEP_TRUE 172 (nil))
(expr_list:REG_DEAD (reg:DI 133)
(expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI
("symbol_tab_data") [flags 0x40] )
(const_int 1125899906842624 [0x4])))
(nil
calls.c:843: internal compiler error: in extract_insn, at recog.c:2020
Please submit a full bug report,
It needs both -O and -fPIC to trigger this bug.
I've reduce the code in question to:
int x;
static void ** STACK;
static void get_block () {
while (1)
{
STACK[0] = (void *)(&x+(1L<<48));
}
}
Which gives me this error:
$ gcc -O -fPIC test5.i -c -o test.o
test5.i: In function 'get_block':
test5.i:9: error: unrecognizable insn:
(insn 38 37 33 0 (set (reg/f:DI 58 [ D.1466 ])
(plus:DI (reg:DI 63)
(const_int 1125899906842624 [0x4]))) -1
(insn_list:REG_DEP_TRUE 37 (nil))
(expr_list:REG_DEAD (reg:DI 63)
(expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("x") )
(const_int 1125899906842624 [0x4])))
(nil
test5.i:9: internal compiler error: in extract_insn, at recog.c:2020
gcc-3.4 3.4.5-1 gives the same error, gcc-4.1 4.1-0exp6
seems to compile this without problems.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345611: openoffice.org: [64bit] Making OpenOffice src compile
It seems that it's still failing to build because of java problems. I get errors such as: HelpContent.java: In class 'com.sun.star.help.HelpContent': HelpContent.java: In constructor '(com.sun.star.help.HelpProvider,com.sun.star.help.HelpContentIdentifier)': HelpContent.java:25: error: final field 'm_xIdentifier' may not have been initialized HelpContent.java:26: error: final field 'm_xParameter' may not have been initialized HelpContent.java:27: error: final field 'm_xProvider' may not have been initialized HelpURLConnection.java: In class 'com.sun.star.help.HelpURLConnection': HelpURLConnection.java: In constructor '(java.net.URL,byte[])': HelpURLConnection.java:17: error: final field '_helpURL' may not have been initialized HelpURLConnection.java:18: error: final field '_doc' may not have been initialized [...] After changing the build depedency related to java to be the same as for sparc, and setting ENABLE_JAVA to n, it build completly, but failed after creating most of the .deb packages with: # install the javadoc stuff manually cp -r ooo-build/build/ooa680-m1/odk/unxlngx6.pro/bin/odk680/docs/java \ debian/openoffice.org-dev-doc/usr/lib/openoffice/sdk/docs cp: cannot stat `ooo-build/build/ooa680-m1/odk/unxlngx6.pro/bin/odk680/docs/java': No such file or directory Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349268: gcc-4.0: ICE building clisp on amd64.
On Sun, Jan 22, 2006 at 01:42:52PM +0100, Bastian Blank wrote:
> On Sat, Jan 21, 2006 at 10:57:13PM +0100, Kurt Roeckx wrote:
> > I've reduce the code in question to:
> > int x;
> > static void ** STACK;
>
> Two uninitialized variables.
>
> > static void get_block () {
> > while (1)
> > {
> > STACK[0] = (void *)(&x+(1L<<48));
>
> - Dereference of an uninitialized variable aka undefined behaviour.
> - Producing a pointer which is outside of an object. Don't know if this
> is UB also.
>
> > }
> > }
>
In the original, both where actually extern.
So it more looked like:
extern int x;
extern void ** STACK;
static void get_block () {
while (1)
{
STACK[0] = (void *)(&x+(1L<<48));
}
}
The original line of code actually looks like:
extern gcv_object_t* STACK;
[...]
extern struct symbol_tab_ {
symbol_ S_nil;
symbol_ S_t;
[...]
symbol_ S_foreign_call_in;
} symbol_tab_data;
[...]
static void get_block (char block[64], object vector) {
while (!tint)((oint)(vector) >> 48)) & ~(1L<<(3))) == (( (1L<<(4)) ) +
((3)<<0) + ((3)&((1L<<(0+1))-(1L<<(1 + ((3)&((1L<<(1+1))-(1L<<(2))
|| vector_length(vector) != 8) {
((STACK[-1-(sintP)(-1)]) =
(((gcv_object_t)(((UBYTE*)((&symbol_tab_data.S_nil))+((oint)(tint)(( (1L<<(2))
))<<48), STACK -= -1);
((STACK[-1-(sintP)(-1)]) = (vector), STACK -= -1);
((STACK[-1-(sintP)(-1)]) =
(module__syscalls__object_tab._object__28vector_20_28unsigned_byte_208_29_208_29),
STACK -= -1);
((STACK[-1-(sintP)(-1)]) = (((STACK[-1-(sintP)(0)]))), STACK -= -1);
((STACK[-1-(sintP)(-1)]) = (vector), STACK -= -1);
((STACK[-1-(sintP)(-1)]) = (((Subr)(((0==0) && oint)(tint)((
(1L<<(0 << 48) & ~0UL) == 0) ? (void*)(aint)(oint)(back_trace->bt_function)
: (void*)(aint)((void*)((aint)((oint)(back_trace->bt_function)) &
((aint)0xUL | ~~0UL))) )))->name), STACK -= -1);
check_value(type_error,clgettext("~S: ~S is not of type ~S"));
vector = mv_space[0];
}
[...]
I do have to agree that the creating of that pointer is
probably undefined behaviour, and it might have more
undefined behaviour with how it's accessing that STACK and
things like that.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349355: libusb: FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
Package: libusb Version: 2:0.1.11-1 Severity: serious Hi, Your package is failing to build on a few arches with the following error: gcc -DHAVE_CONFIG_H -I. -Werror -Wall -g -O2 -MT linux.lo -MD -MP -MF .deps/linux.Tpo -c ../linux.c -fPIC -DPIC -o .libs/linux.o cc1: warnings being treated as errors ../linux.c: In function 'usb_os_determine_children': ../linux.c:568: warning: format '%d' expects type 'int', but argument 3 has typ e 'long unsigned int' make[3]: *** [linux.lo] Error 1 It's trying to print a sizeof(), which is a size_t. The proper way to print a size_t is either "%zd" or "%zu". Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347036: pente: FTBFS: build-depends on removed xlibs-dev
found 347036 2.2.5-5 thanks Hi, pente is now failing to build with the following error: checking for X... no [...] cd wmslib/src/abut; gcc -O2 -fomit-frame-pointer -I/build/buildd/pente-2.2.5/wm slib/src -I/build/buildd/pente-2.2.5/obj-x86_64-Linux -g -Wall -O2 -c abut.c In file included from /build/buildd/pente-2.2.5/wmslib/src/but/but.h:27, from abut.c:8: /build/buildd/pente-2.2.5/wmslib/src/but/rcur.h:37: error: syntax error before 'Pixmap' /build/buildd/pente-2.2.5/wmslib/src/but/rcur.h:37: warning: no semicolon at en d of struct or union [...] The problem is that the AC_PATH_X macro looks for something in libxt-dev. This has been solved in the Debian version of autoconf since 2.59a-4. So you have a few options: - Rebuild the configure scritps - Add a build dependency on libxt-dev - Use --x-includes and --x-libraries options to configure. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: Postfix problem still there
On Sun, Jan 22, 2006 at 09:23:13PM +0100, Martin Sebald wrote: > Hello! > > > We believe that the bug you reported is fixed in the latest version of > > openssl, which is due to be installed in the Debian FTP archive: > > Was this meant for me? Otherwise sorry for spamming around... ;-) > > I upgraded to openssl 0.9.8a-6 but the Postfix errors stayed. It's the client that needs to upgrade to 0.9.8a-6. And did your postfix get restarted? It's probably not a bad idea to restart it manually to make sure it's running with the lastest version of the library. > I also got a mail from a nice guy named Yari about my Postfix problem: > > > As I had the same problem, the workaround I've found is the following: in > > the main.cf configuration file add this directive for openssl: > > > smtpd_tls_cipherlist = SSLv2:-LOW:-EXPORT:RC4+RSA > > > in this way it works always, with TLS v1 and RC4 128 bit. > > > Best Regards > > Yari Melzani > > Because I did not know what he wanted to say when talking about "TLS v1 and > RC4 128 bit" (I need this to work with all TLS connections, not only some) > I did not try it yet. That will basicly reduce the encryption level and protocol in such a way that the bug doesn't show up. I don't recommend this, but it will probably work. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: Postfix problem still there
On Sun, Jan 22, 2006 at 11:20:10PM +0100, Martin Sebald wrote: > > I tried it after Yari wrote again (I attached his mail at the bottom of > this mail). And it works. I also do not think it is the best solution but I > think it is a workaround until the bug in OpenSSL is fixed. The default cipher list used by openssl is: $ openssl ciphers DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:RC4-64-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5 Or: $ openssl ciphers 'ALL:!ADH:+RC4:@STRENGTH' DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:RC4-64-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5 The suggested workaround by Yari gives: $ openssl ciphers 'SSLv2:-LOW:-EXPORT:RC4+RSA' DES-CBC3-MD5:RC2-CBC-MD5:RC4-MD5:EXP1024-RC4-SHA:EXP1024-RC4-MD5:RC4-SHA:RC4-MD5:EXP-RC4-MD5:RC4-64-MD5:EXP-RC4-MD5 Order by stregth: $ openssl ciphers 'SSLv2:-LOW:-EXPORT:RC4+RSA:@STRENGTH' DES-CBC3-MD5:RC2-CBC-MD5:RC4-MD5:RC4-SHA:RC4-MD5:RC4-64-MD5:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-RC4-MD5:EXP-RC4-MD5 Restricting it to only tls1: openssl ciphers -tls1 'SSLv2:-LOW:-EXPORT:RC4+RSA' EXP1024-RC4-SHA:EXP1024-RC4-MD5:RC4-SHA:RC4-MD5:EXP-RC4-MD5 The default restricted to tls1: openssl ciphers -tls1 DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5 You might also want to add a -v to that if you want to know more about them, and see man ciphers(1) for more. When trying a connection to the server with the default, I get this: SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA When using it on the server side (as his suggestion), I get: SSL-Session: Protocol : TLSv1 Cipher: RC4-SHA With Yari's suggestion on the client side get: SSL-Session: Protocol : TLSv1 Cipher: EXP1024-RC4-SHA After ordering it by strength on the client side I get this again: SSL-Session: Protocol : TLSv1 Cipher: RC4-SHA The ciphers: DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 EXP1024-RC4-SHA SSLv3 Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export Some more fun trying things: If it's using -no_ssl2 on the client, it will end up with using compression, not using -no_ssl2 will not give compression, so will result in a connection that works. I really can't recommend using ssl2, so -no_ssl2 is actually a good option. In my case wether using the -no_ssl2 option or not, both end up with TLSv1 connection. Using the -no_tls1 options on either client or server also generates a working connection, using SSLv3 in my case. So using -no_ssl2 and -no_tls1 on the server side would also be an option. This even generates a compressed link that works if the client is also using -no_ssl2. I think the -no_tls1 in combination with -no_ssl2 on the server side might actually be the best workaround. I don't know if you can do something like that in the postfix configuration though. If I use Yari's cipher list on the server side, I also get a working TLSv1 connection, just with a different cipher as shown above. When the client uses -no_ssl2 it's with compression. I'm not sure why sometimes using compression is a problem and sometimes not. I guess in those cases it's not at sequence 0 anymore so it works. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
tags 348558 + patch pending thanks On Sun, Feb 05, 2006 at 12:08:34PM +0100, Ralf Wildenhues wrote: > Hi Bob, > > I have applied the patch (removed the now-obsolete change to > testsuite.at, added a `libtool' testsuite keyword) to HEAD, and the > corresponding change to branch-1-5; both patches are attached. > > I guess the tag pending would be appropriate for the Debian bugreport > now. Thanks for all the work Ralf. I'll probably upload this if you make a new 1.5 release, or I have an other reason to upload a new 1.5 version. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351564: mesa: FTBFS: No makedepend
Package: mesa Version: 6.4.1-0.2 Severity: serious Hi, Your package is failing to build on the auto builders with the following error: E: Couldn't find package makedepend The problem is the order of the build dependencies. It has: makedepend | xutils sbuild will always pick the first one, and when that doesn't exist, it fails. Please change the order to read: xutils | makedepend Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340791: python2.3 - FTBFS: build-depends against removed package: tix8.1-dev
Hi, Has there been any progress on fixing this? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351566: warped: FTBFS: configure: error: Could not find PCCTS headers.
Package: warped Version: 20051029-2 Severity: serious Hi, Your package is failing to build with the following error: checking for PCCTS includes... /usr/include/pccts checking AParser.h usability... no checking AParser.h presence... no checking for AParser.h... no configure: error: Could not find PCCTS headers. Please specify the correct location with the --with-pccts-headers option. make: *** [configure-stamp] Error 1 This looks like a missing build dependency on pccts. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351567: librmagick-ruby: FTBFS: debian/rules:11: *** target file `unpatch' has both : and :: entries. Stop.
Package: librmagick-ruby Version: 1.10.0-1 Severity: serious Hi, Your package is failing to build with the following error: fakeroot debian/rules clean debian/rules:11: *** target file `unpatch' has both : and :: entries. Stop. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351568: prelude-manager: FTBFS: checking for libprelude - version >= 0.9.4... no
Package: prelude-manager Version: 0.9.2-1 Severity: serious Hi, Your package is failing to build with the following error: checking for libprelude-config... /usr/bin/libprelude-config checking for libprelude - version >= 0.9.4... no *** An old version of LIBPRELUDE (0.9.0) was found. *** You need a version of LIBPRELUDE newer than 0.9.4. The latest version of *** LIBPRELUDE is always available from http://www.prelude-ids.org/download/releases. *** *** If you have already installed a sufficiently new version, this error *** probably means that the wrong copy of the libprelude-config shell script is *** being found. The easiest way to fix this is to remove the old version *** of LIBPRELUDE, but you can also set the LIBPRELUDE_CONFIG environment to point to the *** correct copy of libprelude-config. (In this case, you will have to *** modify your LD_LIBRARY_PATH enviroment variable, or edit /etc/ld.so.conf *** so that the correct libraries are found at run-time)) configure: error: Cannot find libprelude: Is libprelude-config in the path? make: *** [configure-stamp] Error 1 Please change your libprelude-dev build dependency's version to need atleast version 0.9.4. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351572: libgpevtype0-dev: Missing dependencies.
Package: libgpevtype0-dev Version: 0.11-1 Severity: serious Hi, Your libgpevtype.pc file states: Requires: glib-2.0, mimedir-1.0 You should be adding dependencies for those packages to your -dev package in case they really are required. This seems to mean you need to add a depends on libglib2.0-dev and libmimedir-gnome0-dev. It seems your header files also include both of them. You might also consider using Requires.private instead of Requires. This will prevent other package using pkg-config from linking libraries they don't need. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221689: [Pkg-openssl-devel] Bug#221689: openssl: s_client's starttls smtp option broken
On Tue, Feb 07, 2006 at 07:32:10PM +0100, Andreas Metzler wrote: > On 2005-05-09 Christoph Martin <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] schrieb: > > >Package: openssl > > >Version: 0.9.7c-5 > > > >I start s_client like this: > > >openssl s_client -connect localhost:25 -cert /etc/ssl/user.pem \ > > > -key /etc/ssl/user.key -starttls smtp > > > The current version (0.9.7e) works perfectly with sendmail. Can you > > please check the latest version with exim and let me know, if the bug is > > fixed? > > Nope. Same breakage with 0.9.7e-3sarge1. I guess sendmail simply > accepts more garbage. This might be of interrest: http://www.mail-archive.com/openssl-dev@openssl.org/msg20600.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352047: [Pkg-openssl-devel] Bug#352047: BIO_s_connect patch pending next 0.9.8 release
severity 352047 serious thanks On Thu, Feb 09, 2006 at 02:27:19PM +0100, Gabriel Forté wrote: > On Thu, Feb 09, 2006 at 03:08:01AM -0800, Steve Langasek wrote: > > On Thu, Feb 09, 2006 at 11:39:29AM +0100, Gabriel Forté wrote: > > > Package: libssl0.9.8 > > > Version: 0.9.8a-6 > > > Severity: critical > > > > > the following openssl-dev mailing-list thread documents a regression bug > > > in libssl which will be fixed in the upcoming upstream release (0.9.8b): > > > > > http://www.mail-archive.com/openssl-dev@openssl.org/msg20804.html > > > > None of which explains why this is "critical". > > maybe this post later in the same thread is a better explanation: > > http://www.mail-archive.com/openssl-dev@openssl.org/msg20815.html > > > to me this breaks unrelated software using this feature in the library > (or maybe am I wrong about the "unrelated" definition) >From the documentation: critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. serious is a severe violation of Debian policy (roughly, it violates a "must" or "required" directive), or, in the package maintainer's opinion, makes the package unsuitable for release. important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. Unrelated in this case would mean something that is not linked to libssl. I think critical isn't the right severity. Since you're about the first person to have a problem, I think serious is the right severity. > I'm currently forced to rebuild the package with that patch each time a > new release comes out in order to work around this problem, > which triggers a critical functional regression in something as trivial as > establishing a TCP connection over the BIO API, and had to for about two > months as of this day (the upstream maintainer didn't react about it until > a few days ago). Upstream isn't always that responsive. I'll try and upload a fixed version shortly. Kurt
Bug#338006: [Pkg-openssl-devel] Bug#338006: Postfix problem still there
On Thu, Feb 09, 2006 at 01:29:37PM +0100, Martin Sebald wrote: > Hello again, > > I'm sorry, but looking into the logs the last days and trying a few thing I > have to say the following: Are you sure both sides of the connection have a fixed version? Things work without problems here, and I can't reproduce the problem anymore. I will need a way to reproduce this before I can look at it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: [Pkg-openssl-devel] Bug#338006: Doesn't seem to fix the problems with Nessus
On Sat, Feb 11, 2006 at 10:35:07PM +0100, Javier Fernández-Sanguino Peña wrote:
>
> The latest OpenSSL version (0.9.8-6) does not seem to fix the problem with
> Nessus, actually, it makes it work since now the workaround of using a
> restricted set of ciphers no longer works either:
Are you sure the server has been restarted since the upgrade of
libssl0.9.8?
> If you try to connect the Nessus client with the server you get this:
> [26753] SSL_connect: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
> handshake failure
> nessus : SSL error
>
> And using the standard OpenSSL client:
>
> $ openssl s_client -connect localhost:1241 -ssl3 -CAfile \
> /var/lib/nessus/CA/cacert.pem -bugs -no_ssl2
> CONNECTED(0003)
> 26745:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
> failure:s3_pkt.c:1057:SSL alert number 40
> 26745:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
> failure:s3_pkt.c:534:
There are various reasons why this can happen. One reason
is that the client only uses ssl3 (as you did with -ssl3)
and that the server doesn't allow ssl3 connections. I can
perfectly connect to it witout problems if I drop the
-ssl3 from the s_client parameters.
The server has this code in it:
#define SSL_VER_DEF_NAME"TLSv1"
#define SSL_VER_DEF_METHTLSv1_server_method
[...]
if (strcasecmp(ssl_ver, "SSLv2") == 0)
ssl_mt = SSLv2_server_method();
else if (strcasecmp(ssl_ver, "SSLv3") == 0)
ssl_mt = SSLv3_server_method();
else if (strcasecmp(ssl_ver, "SSLv23") == 0)
ssl_mt = SSLv23_server_method();
else if (strcasecmp(ssl_ver, "TLSv1") == 0)
ssl_mt = TLSv1_server_method();
else
{
fprintf(stderr, "Unknown SSL version \"%s\"\nSwitching to default
" SSL_VER_DEF_NAME "\n", ssl_ver);
ssl_ver = SSL_VER_DEF_NAME;
ssl_mt = SSL_VER_DEF_METH();
}
So it looks normal to me that if you use -ssl3 that it doesn't work.
(The client has the same code.)
Can you reproduce your problem using a combination of s_server and
s_client? I've been trying to reproduce other problems, but I can't.
> So it seems that the fix introduced a different behaviour [1], but it's still
> broken.
>
> Should be easy to reproduce, just install Nessus, make a certificate and try
> to connect to the Nessus server...
So I "just installed" nessus and nessusd, it seems to
connect without problems, it even asks me to validate the
certificate, but for some reason I can't log in.
I get:
[Sun Feb 12 14:13:15 2006][7916] Client requested protocol version 12.
[Sun Feb 12 14:13:15 2006][7916] bad login attempt from 127.0.0.1
So it seems to me the ssl part is working perfectly.
Kurt
Bug#352530: perl-modules: should depend on perl (>= 5.8.8-2)
Package: perl-modules Version: 5.8.8-2 Severity: serious Hi, You moved overload.pm to perl-base, which breaks partial upgrades. If you have perl-modules 5.8.8-2 with perl 5.8.8-1 things that use overload.pm will break because it's not available anymore. Please change the Depends from: Depends: perl (>= 5.8.8-1) To: Depends: perl (>= 5.8.8-2) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352726: eclipse: FTBFS: Missing build dependency on bzip2
severity 352726 serious thanks Failing to build is an RC bug. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323669: baycomusb: FTBFS: error: 'USBDEVFS_URB_ISO_ASAP' undeclared
On Sat, Dec 10, 2005 at 07:45:30PM +0100, Joop PG4I wrote: > Hello again Kurt, > > Baycomusb still seems to build just fine on my Debian/unstable box. Can you > please check if USBDEVFS_URB_ISO_ASAP is defined in > /usr/include/linux/usbdevice_fs.h on your system? You have this code: #ifdef HAVE_LINUX_USBDEVICE_FS_H #include #include #else #include "usbdevice_fs.h" #endif And "usbdevice_fs.h" doesn't contain it. >From the buildd log: checking for linux/usbdevice_fs.h... no >From config.log: configure:2738: gcc -E conftest.c >/dev/null 2>conftest.out In file included from /usr/include/asm-x86_64/div64.h:1, from /usr/include/asm/div64.h:8, from /usr/include/linux/jiffies.h:9, from /usr/include/linux/sched.h:12, from /usr/include/asm-x86_64/compat.h:8, from /usr/include/asm/compat.h:8, from /usr/include/linux/compat.h:15, from /usr/include/linux/usbdevice_fs.h:35, from configure:2734: /usr/include/asm-generic/div64.h:54:3: error: #error do_div() does not yet support the C64 [...] This seems to be #326561, and amd64 specific. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342874: [pkg-mad-maintainers] Bug#342874: madplay: Madplay should provide mp3-decoder
On Sun, Dec 11, 2005 at 02:55:52PM +0100, Romain Beauxis wrote: > Package: madplay > Version: 0.15.2b-4 > Severity: wishlist > > > Hi all! > > It would be nice if madplay could provide the virtual package > mp3-decoder. > Obviously it is an mp3-decoder, and in some situation, it is one of the > better, so I think it would deserve it! I don't believe there should be a virtual package for an mp3-decoder. This would require that they all have some common interface, which they don't. But on the other hand the policy defines an mp3-decoder as a virtual package, only saying "an MP3 decoder package", and the bug requesting it (#64006) doesn't provide much information either. Should something like libmad0 then also be an mp3-decoder, because that is the part that does the decoding. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323669: baycomusb: FTBFS: error: 'USBDEVFS_URB_ISO_ASAP' undeclared
severity 323669 important severity 326561 important reassign 323669 linux-kernel-headers merge 323669 326561 thanks > I am unfamiliar with these issues. > Does this mean I can close this bug and/or re-assign it to 326561? I've just merged them. But you can probably work around this by fixing your local copy of the header file. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#102604: autoconf-wrapper's --version output depends on the current directory.
Hi,
I'm submitting this to this bug, since it seems to be related.
The autoconf wrapper currently has this in it:
if (defined ($infile)) {
# Assume an input file ending in .ac is 2.50,
# because that extension was introduced after 2.13.
if ($infile =~ /\.ac$/) {
ac250 ();
}
Which means depending on the precense of an configure.ac in the
current directory, it reports either 2.13 or 2.59, for both
--version and --help.
I think it would be better if you could instead let it say that
it's a wrapper, so it's actually clear you're using a wrapper.
I always assumed that the alternative system would either point
autoconf to autoconf2.13 or autoconf2.50, but it's a wrapper
instead.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343512: prelude-lml: FTBFS: prelude-lml: Should build depends on libprelude-dev >= 0.9
Package: prelude-lml Version: 0.9.0-1 Severity: serious Hi, Your package is failing to build with the following error: checking for libprelude-config... /usr/bin/libprelude-config checking for libprelude - version >= 0.9.0... Usage: libprelude-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--libs] [--pthread-cflags] [--cflags] Usage: libprelude-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--libs] [--pthread-cflags] [--cflags] no *** Could not run libprelude test program, checking why... [...] >From config.log: conftest.c:69:32: error: libprelude/prelude.h: No such file or directory I assume that that is a new header from 0.9.0. Also, since the configure script checks for that version, I think you your build dependencies should reflect that requirement. This was attempted to get build using libprelude-dev version 0.8.10-1. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276399: ghdl: FTBFS on amd64
Hi, It seems that the current 0.20 package seems to try and build a 32 bit version of ghdl. The build log ends with: checking for x86_64-linux-gnu-gcc... /build/buildd/ghdl-0.20/gcc-4.0.2/build/gcc/xgcc -B/build/buildd/ghdl-0.20/gcc-4.0.2/build/gcc/ -B/usr/lib/ghdl/x86_64-linux-gnu/bin/ -B/usr/lib/ghdl/x86_64-linux-gnu/lib/ -isystem /usr/lib/ghdl/x86_64-linux-gnu/include -isystem /usr/lib/ghdl/x86_64-linux-gnu/sys-include -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-target-libmudflap] Error 1 I don't like that -m32 there. If it doesn't work on a 64 bit arch, just disable it for them until you can get it actually fixed (0.21?), and don't go and hide it by trying to make a 32 bit version of it. If I wanted a 32 bit version, I can install a 32 bit version instead. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343522: wmkbd: Support for more arches?
Package: wmkbd Hi, It seems your package currently only supports i386. Is there a reason it only build on i386 and can't be used on any of the others? Nothing in the description or source seems to suggest this is i386 only. You might need to look for 64 bit portability issues however, it's giving the following warnings: option.c: In function `void set_keysym_num(GtkWidget*, void*)': option.c:175: warning: cast from pointer to integer of different size option.c: In function `void set_keysym_num1(GtkWidget*, void*)': option.c:180: warning: cast from pointer to integer of different size option.c: In function `void set_keysym(GtkWidget*)': option.c:438: warning: int format, different type arg (arg 3) option.c: In function `void save_keysym_def(GtkWidget*, void*)': option.c:593: warning: cast to pointer from integer of different size option.c:603: warning: cast to pointer from integer of different size option.c:613: warning: cast to pointer from integer of different size option.c:623: warning: cast to pointer from integer of different size option.c: In function `void clist_category_select(GtkWidget*, gint, gint, GdkEventButton*, void*)': option.c:638: warning: int format, pointer arg (arg 3) option.c: In function `void set_keysym_from_db(GtkWidget*, void*)': option.c:655: warning: int format, pointer arg (arg 3) option.c: In function `void load_keymap_editor(GtkWidget*, int)': option.c:1084: warning: int format, pointer arg (arg 3) Casting a pointer to a integer will cause problems in most cases. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#254720: masqmail: FTBFS on amd64: configure check for res_search/__res_search fails
Hi,
Here is a patch against configure.ac (you need to run autoconf)
that should fix the problem, by checking an other time for
res_search with AC_TRY_LINK, and using an include of
this time.
Kurt
--- configure.ac.old2005-11-07 20:21:39.0 +0100
+++ configure.ac2005-12-15 21:41:52.0 +0100
@@ -38,10 +38,23 @@
dnl if not, it is probably libc6 and we need libresolv
AC_CHECK_LIB(c, res_search, need_resolv=no, need_resolv=yes)
if test "$need_resolv" = yes; then
- AC_CHECK_LIB(resolv, res_search,has_resolv=yes,AC_MSG_ERROR("no
libresolv"))
- RESOLV_LIBS='-lresolv'
- else
- RESOLV_LIBS=''
+ AC_CHECK_LIB(resolv, res_search,
+ has_resolv=yes; RESOLV_LIBS="-lresolv",
+ has_resolv=no)
+ if test "$has_resolv" = no; then
+ saved_LIBS="$LIBS"
+ LIBS="$LIBS -lresolv"
+ AC_MSG_CHECKING(for res_search in -lresolv)
+ AC_TRY_LINK([#include ],
+ [res_search (0, 0, 0, 0, 0);],
+ RESOLV_LIBS="-lresolv"; has_resolv=yes;
AC_MSG_RESULT(yes),
+ AC_MSG_RESULT(no));
+ LIBS="$saved_LIBS"
+ fi
+ if test "$has_resolv" = no; then
+ AC_MSG_ERROR("no libresolv")
+ RESOLV_LIBS=''
+ fi
fi
else
RESOLV_LIBS=''
Bug#343710: wvstreams: FTBFS on 64 bit arches: wvhash.cc:33: error: cast from 'const void*' to 'unsigned int' loses precision
Package: wvstreams Version: 4.2-1 Severity: serious Hi, Your package is failing to build on 64 bit arches with the following error: utils/wvhash.cc: In function 'unsigned int WvHash(const void*)': utils/wvhash.cc:33: error: cast from 'const void*' to 'unsigned int' loses precision make[1]: *** [utils/wvhash.o] Error 1 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343712: gcl: FTBFS: ./configure: line 2413: syntax error near unexpected token `('
Package: gcl
Version: 2.6.7-12
Severity: serious
Hi,
Your package is failing to build on most arches with the
following error:
checking for text start... _start
checking system version (for dynamic loading)... checking for makeinfo...
makeinfo
./configure: line 2413: syntax error near unexpected token `('
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326466: mesa: FTBFS: Missing Build-Depends on 'xutils, xlibmesa-gl-dev'
Hi, It seems there isn't any progress on this at all for a long time. Could someone please shed some light on what is going on with this? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315059: heimdal: Kerberos 4 support should be dropped
Hi, Is there any ETA when we can get this in unstable? Are there some reason you don't wish to upload this to unstable yet? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343746: dbus: FTBFS: error: conversion from 'long int' to 'QVariant' is ambiguous
Package: dbus Version: 0.60-1 Severity: serious Hi, Your package is failing to build (on amd64) with the following error: ../qt/qdbusmarshall.cpp: In function 'QVariant qFetchParameter(DBusMessageIter*)': ../qt/qdbusmarshall.cpp:72: error: conversion from 'long int' to 'QVariant' is ambiguous /usr/include/qt4/QtCore/qvariant.h:151: note: candidates are: QVariant::QVariant(const char*) /usr/include/qt4/QtCore/qvariant.h:150: note: QVariant::QVariant(double) [...] /usr/include/qt4/QtCore/qvariant.h:137: note: QVariant::QVarian t(QVariant::Type) ../qt/qdbusmarshall.cpp:74: error: conversion from 'long unsigned int' to 'QVariant' is ambiguous Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335199: cupsys: FTBFS: Not using -fPIC to make shared lib.
found 335199 1.1.99.b1.r4876-1 thanks It seems this bug is back now, it didn't show up in version from 1.1.99.b1.r4748-2 to 1.1.99.b1.r4841-1, but it's back with 1.1.99.b1.r4876-1. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343822: xorg-x11: FTBFS: manifest differences
Package: xorg-x11 Version: 6.8.99.903.dfsg.1-1 Severity: serious Tags: experimental Hi, Your package is failing to build on amd64 with the following error: --- debian/MANIFEST.amd64 2005-12-17 22:22:20.0 +0100 +++ debian/MANIFEST.amd64.new 2005-12-17 22:22:20.0 +0100 @@ -479 +478,0 @@ -usr/X11R6/bin/pclcomp @@ -1158 +1156,0 @@ -usr/X11R6/lib/X11/doc/html/Xprint_FAQ.html @@ -1743 +1740,0 @@ -usr/X11R6/man/man1/pclcomp.1x MANIFEST check failed; please see debian/README make: *** [stampdir/check-manifest] Error 1 I think this applies to more than just amd64, since it seems to have been removed for being non-free, and other manifest files still mention it. I'm not sure about the Xprint_FAQ.html though. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343888: svgalib: FTBFS on amd64: /vm86.h:8:3: error: #error This header is not available for x86_64
Package: svgalib Version: 1:1.9.23-1 Severity: important Hi, Your package is failing to build on amd64 with the following error: In file included from lrmi.c:16: /usr/include/asm/vm86.h:8:3: error: #error This header is not available for x86_64 lrmi.c:182: error: field 'vm' has incomplete type lrmi.c: In function 'get_int_seg': [...] The amd64 (x86_64) kernel does not support the vm86() system call, so does not support running 16 bit code. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343890: control-center: FTBFS: `./debian/tmp/usr/bin/gnome-display-properties': No such file or directory
Package: control-center Version: 1:2.12.1-1 Severity: serious Tags: experimental Hi, When building your package from experimental I get the following error: dh_install -pgnome-control-center cp: cannot stat `./debian/tmp/usr/bin/gnome-display-properties': No such file or directory dh_install: command returned error code 256 make: *** [binary-install/gnome-control-center] Error 1 PS: You have 2 build dependencies on libgnome-menu-dev with different versions, once >= 2.10.1, once >= 2.12.0. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343895: evolution: FTBFS: make[3]: *** No rule to make target `/usr/share/gtkhtml-3.8/Editor.idl', needed by `Editor.h'. Stop.
Package: evolution
Version: 2.4.1-3
Severity: serious
Hi,
Your package is failing to build with the following error:
make[3]: Entering directory `/usr/src/evolution-2.4.1/composer'
make[3]: *** No rule to make target `/usr/share/gtkhtml-3.8/Editor.idl', needed
by `Editor.h'. Stop.
make[3]: Leaving directory `/usr/src/evolution-2.4.1/composer'
make[2]: *** [all-recursive] Error 1
This seems to come from:
/usr/lib/pkgconfig/libgtkhtml-3.8.pc:gtkhtml_datadir=${prefix}/share/gtkhtml-3.8
/usr/share/gtkhtml-3.8 seems to be in the gtkhtml3.8
package, which you have no build dependency on, only
libgtkhtml3.8-dev.
I'm not sure which package should get fixed, please
reassign as needed.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340786: discover1 - FTBFS: grep: configure: No such file or directory
On Sat, Nov 26, 2005 at 12:29:49AM +0100, Bastian Blank wrote: > > sh debian/check-configure.sh > > grep: configure: No such file or directory > > You must run autogen.sh first! CVS IDs do not match. The actual error is: sh autogen.sh autogen.sh: line 6: libtoolize: command not found autogen.sh: line 7: aclocal-1.7: command not found autogen.sh: line 8: autoheader: command not found autogen.sh: line 9: automake-1.7: command not found autogen.sh: line 10: autoconf: command not found Which then get followed by your error message. This look like missing build dependencies. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340849: grub: FTBFS on amd64: GRUB requires a working absolute objcopy
Package: grub Version: 0.97-1 Severity: important Hi, grub is failing to build on amd64 with the following error: checking whether objcopy works for absolute addresses... no configure: error: GRUB requires a working absolute objcopy; upgrade your binutils I've reported this ages ago to binutils: http://bugs.debian.org/244498 Afaik, the reason we didn't have a problem with this is that we had a 32 bit version of grub. There is no reason why a 32 bit version shouldn't work. This seems to have been changed by Manolo Díaz's (CC'd) request in #337288, and I think he should just enable ia32 emulation support in his kernel. I don't mind having a 64 bit version of this, but please let someone test that it actually works before you upload it. Kurt
Bug#340850: units: FTBFS: makeinfo: Command not found
Package: units Version: 1.85-1 Severity: serious Hi, Your package is failing to build on a few arches with the following error: gcc -o units units.o parse.tab.o getopt.o getopt1.o -lm -lreadline -lncurses ./texi2man units.texinfo > units.man sed [EMAIL PROTECTED]@!/usr/share/misc/units.dat! ./units.man > units.1 makeinfo ./units.texinfo make[1]: makeinfo: Command not found make[1]: *** [units.info] Error 127 I'm guessing this is a timestamp skew issues. I suggest you look at /usr/share/doc/autotools-dev/README.Debian.gz about it. Note that since linux 2.6, it keeps sub-second timestamps for files (as long as they're in memory) which triggers more of those bugs. Other buildd's show this instead: gcc -o units units.o parse.tab.o getopt.o getopt1.o -lm -lreadline -lncurses sed [EMAIL PROTECTED]@!/usr/share/misc/units.dat! ./units.man > units.1 make[1]: Leaving directory `/build/buildd/units-1.85' texi2html -monolithic units.texinfo Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329185: hwinfo: FTBFS (amd64): suffix or operands invalid for `push'
found 329185 8.38-4 thanks It seems you didn't apply the patch for amd64, so it's still failing with the same error. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#244498: Absolute objcopy not working on amd64?
Hi, There doesn't seem to have been any progress on this? Would if help if I forward this to upstream myself? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340849: grub: FTBFS on amd64: GRUB requires a working absolute objcopy
On Sat, Nov 26, 2005 at 09:55:08AM -0200, Otavio Salvador wrote: > > Well, I sent a message to debian-devel asking for testing. Just two > people replied it. I didn't see that request, I don't have the time to follow everything on -devel. > Also, if you're interested to help to maintain grub > you're welcome. I did notice the RFH (#248397), but I'm not really interested in the package. > I left the package ready for a while waiting for testing and nobody > wondered to do it. I won't wait forever. I understand. If you ever need some amd64 specific tests, please mail me or the amd64 list (debian-amd64@lists.debian.org). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340852: gpsd: FTBFS: undefined reference to `floor'
Package: gpsd Version: 2.30-1 Severity: serious Hi, Your package is failing to build with the following error: gpxlogger.o: In function `signal_handler':/build/buildd/gpsd-2.30/gpxlogger.c:6 7: undefined reference to `floor' collect2: ld returned 1 exit status make[2]: *** [gpxlogger] Error 1 You will need to link with -lm Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340858: belpic: FTBFS on amd64: Thread.cpp:224: error: 'pthread_kill' was not declared in this scope
Package: belpic Version: 2.3.13.full-4 Severity: important Hi, Your package is failing to build on amd64 with the following error: ../ObjectsMultiPlatform/Src/Base/Thread.cpp: In member function 'void CThread::Kill()': ../ObjectsMultiPlatform/Src/Base/Thread.cpp:224: error: 'pthread_kill' was not declared in this scope make[2]: *** [Thread.lo] Error 1 The problem is probably a missing incluce for . On amd64, we use nptl by default, and there doesn't include Note that the manpage says you need to include both. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340864: gcc-4.1: FTBFS on amd64: Can't find libssp.*
Package: gcc-4.1 Version: 4.1ds0-0exp0 Severity: important Hi, Your package is failing to build on amd64 with the following error: dh_movefiles: debian/tmp/usr//libssp.a not found (supposed to put it in libssp0-dev) dh_movefiles: debian/tmp/usr//libssp.la not found (supposed to put it in libssp0-dev) dh_movefiles: debian/tmp/usr//libssp.so not found (supposed to put it in libssp0-dev) dh_movefiles: debian/tmp/usr//libssp_nonshared.a not found (supposed to put it in libssp0-dev) dh_movefiles: debian/tmp/usr//libssp_nonshared.la not found (supposed to put it in libssp0-dev) In the debian dir, those files exists: ./debian/tmp/usr/lib32/libssp.a ./debian/libssp0-dev/usr/lib/libssp.a And it the build dir: ./build/x86_64-linux-gnu/32/libssp/.libs/libssp.a ./build/x86_64-linux-gnu/libssp/.libs/libssp.a (The same goes for all those files.) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340868: rezound: FTBFS: CAboutDialog.cpp:73: error: unknown escape sequence '\R'
Package: rezound Version: 0.12.2beta-1 Severity: serious Hi, g++ -DHAVE_CONFIG_H -I. -I. -I../../config -I../../src/misc -I../../src/misc/missing/generated -I../../src/PoolFile -g -Wall -Wno-unused-function -Wno-unused-variable -Wno-unused -I/usr/include -I/usr/include -I/usr/include -MT CAboutDialog.lo -MD -MP -MF .deps/CAboutDialog.Tpo -c CAboutDialog.cpp -o CAboutDialog.o CAboutDialog.cpp: In constructor 'CAboutDialog::CAboutDialog(FX::FXWindow*)': CAboutDialog.cpp:73: error: unknown escape sequence '\R' CAboutDialog.cpp:73: error: unknown escape sequence '\R' CAboutDialog.cpp:73: error: unknown escape sequence '\R' Looks like you either need to remove the \ before ReZound, or add a newline before it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339389: glibc: FTBFS on amd64: sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
I'm planning on doing an NMU for this tommorrow. We currently don't have a libc6 in testing because of this. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340953: linux-2.6: oops when asking ipv6 route when no public address?
Package: linux-image-2.6.12-1-amd64-k8
Version: 2.6.12-10
Hi,
I do have the ipv6 module loaded, have a (default) link local
address assigned, but don't have any global ipv6 addresses.
This is basicly just loading the ipv6 module and doing nothing
else.
When I did the following command:
ip route get 2001:14b0:202:1::a7
I got an oops:
Unable to handle kernel NULL pointer dereference at RIP:
{:ipv6:ipv6_get_saddr+14}
PGD 6472f067 PUD 2e201067 PMD 0
Oops: [1]
CPU 0
Modules linked in: md5 ipv6 parport_pc parport floppy evdev pcspkr i2c_amd756
hw_random i2c_amd8111 i2c_core amd74xx tpm_nsc tpm_atmel tpm shpchp pci_hotplug
ohci_hcd tg3 ext2 rtc psmouse ide_generic ide_disk ide_cd cdrom ide_core ext3
jbd
mbcache sd_mod sata_sil libata scsi_mod raid0 md unix fbcon tileblit font
bitblit vesafb cfbcopyarea cfbimgblt cfbfillrect softcursor
Pid: 13701, comm: ip Not tainted 2.6.12-1-amd64-k8
RIP: 0010:[] {:ipv6:ipv6_get_saddr+14}
RSP: 0018:81006f839a10 EFLAGS: 00010282
RAX: RBX: 81006f839a48 RCX:
RDX: 81006f839a48 RSI: 81006f839ac0 RDI: 881dae20
RBP: 810006514680 R08: R09: 0018
R10: R11: 81006f839ac0 R12: 881dae20
R13: 8100309d20b8 R14: R15: 81006f839ac0
FS: 2af15d40() GS:8040f940() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: CR3: 4e43b000 CR4: 06e0
Process ip (pid: 13701, threadinfo 81006f838000, task 81007e6569e0)
Stack: 881aa538 810006514680 0296
881abc48 0246 81006f839ad0 81007e6569e0
00030282 810006514680
Call Trace:{:ipv6:rt6_fill_node+712}
{:ipv6:ip6_route_output+1256}
{:ipv6:inet6_rtm_getroute+353}
{rtnetlink_rcv+623}
{netlink_data_ready+18}
{netlink_sendskb+46}
{netlink_sendmsg+759}
{sock_sendmsg+283}
{autoremove_wake_function+0}
{autoremove_wake_function+0}
{buffered_rmqueue+536}
{__alloc_pages+188}
{move_addr_to_kernel+37}
{sys_sendmsg+586}
{do_page_fault+1171} {do_brk+498}
{system_call+126}
Code: 48 8b 00 48 89 c7 e9 b7 fd ff ff 66 66 66 90 66 66 90 48 81
RIP {:ipv6:ipv6_get_saddr+14} RSP
CR2:
I assume it's trying to get the source address, and there
isn't any that can reach that host, because I don't have
any global ipv6 address assigned.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339389: glibc: FTBFS on amd64: sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
On Sun, Nov 27, 2005 at 12:06:15AM -0500, Daniel Jacobowitz wrote: > On Sat, Nov 26, 2005 at 04:35:45PM +0100, Kurt Roeckx wrote: > > I'm planning on doing an NMU for this tommorrow. We currently > > don't have a libc6 in testing because of this. > > I assume you mean that amd64 doesn't. 2.3.5-8 migrated to testing just > fine. It's not our fault that the archive scripts and the separate > amd64 archive don't get along. The archive scripts have some problems with this, and you could agrue that they should get fixed to handle it. I think it's a useless effort. > The patch in this bug is fine, if you want to do the NMU. I don't have > time for another glibc upload and someone _needs_ to look at sparc64 > before the next one anyway. Patch for the NMU is attached. Kurt diff -u glibc-2.3.5/debian/patches/00list glibc-2.3.5/debian/patches/00list --- glibc-2.3.5/debian/patches/00list +++ glibc-2.3.5/debian/patches/00list @@ -93,0 +94 @@ +amd64_sem_trywait diff -u glibc-2.3.5/debian/changelog glibc-2.3.5/debian/changelog --- glibc-2.3.5/debian/changelog +++ glibc-2.3.5/debian/changelog @@ -1,3 +1,12 @@ +glibc (2.3.5-8.1) unstable; urgency=low + + * Non-maintainer upload. + * Rename sem_trywait to __new_sem_trywait in amd64 nptl code +so the alias works properly, and it can be build. +(Closes: #339389) + + -- Kurt Roeckx <[EMAIL PROTECTED]> Sun, 27 Nov 2005 11:22:03 +0100 + glibc (2.3.5-8) unstable; urgency=low * Add missing build dependency on libc6-dev-ppc64 on powerpc. only in patch2: unchanged: --- glibc-2.3.5.orig/debian/patches/amd64_sem_trywait.dpatch +++ glibc-2.3.5/debian/patches/amd64_sem_trywait.dpatch @@ -0,0 +1,35 @@ +#! /bin/sh -e + +# DP: Give sem_trywait a different name, so we can add an +# DP: alias to it. + +if [ $# -ne 2 ]; then +echo >&2 "`basename $0`: script expects -patch|-unpatch as argument" +exit 1 +fi +case "$1" in +-patch) patch -d "$2" -f --no-backup-if-mismatch -p1 < $0;; +-unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p1 < $0;; +*) +echo >&2 "`basename $0`: script expects -patch|-unpatch as argument" +exit 1 +esac +exit 0 + + +--- glibc-2.3.5/nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S.old 2005-11-15 23:09:31.0 +0100 glibc-2.3.5/nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S 2005-11-15 23:10:09.0 +0100 +@@ -29,10 +29,10 @@ + + .text + +- .globl sem_trywait +- .type sem_trywait,@function ++ .globl __new_sem_trywait ++ .type __new_sem_trywait,@function + .align 16 +-sem_trywait: ++__new_sem_trywait: + movl(%rdi), %eax + 2:testl %eax, %eax + jz 1f
Bug#335912: libssl0.9.8: openssl upgrade causes segfault on openssh client on sparc64
severity 335912 grave tags 335912 + patch thanks It seems everybody reports that the mentioned patch fixes the problem. I'll try to do an upload for this soon. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338006: libssl0.9.8: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
severity 338006 serious forwarded 338006 http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1204 tags 338006 + help thanks Various programs seem to be having problems with this. I'd love for someone to take a look at this. Also see: http://lists.debian.org/debian-security/2005/11/msg00057.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341147: libg2c0-dev: Has file in /usr/lib32 instead of /emul/ia32-linux/usr/lib
Package: libg2c0-dev Version: 3.4.4-10 Severity: serious Hi, libg2c0-dev installs files in /usr/lib32, which conflict with the symlink from ia32-libs. It should be putting the files in /emul/ia32-linux/usr/lib instead. Note that this works as long as you install ia32-libs before libg2c0-dev, but breaks when you do it the other way around, or try to upgrade ia32-libs when libg2c0-dev is installed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341186: valgrind: FTBFS on amd64: missing build depdnency
Package: valgrind Version: 1:3.1.0-1 Severity: important Hi, valgrind is failing to build on amd64 with the following error: dh_shlibdeps: Compatibility levels before 4 are deprecated. /usr/bin/ldd: line 171: /lib/ld-linux.so.2: No such file or directory ldd: /lib/ld-linux.so.2 exited with unknown exit code (127) dpkg-shlibdeps: failure: ldd on `debian/valgrind/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so' gave error exit status 1 dh_shlibdeps: command returned error code 256 make: *** [binary-arch] Error 1 If I understand things correctly, it shouldn't have any dependencies at all, not even to libc6 anymore. The 32 bit version of the dynamic linker can be found in ia32-libs, so you will either need to build-depend on that (or the -dev package), or not call dh_shlibdeps if you're 100% sure you don't need it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341614: qt-x11-free: FTBFS on amd64: amd64 not in arch list.
Package: qt-x11-free Version: 3:3.3.5-2 Severity: important Hi, Your changelog said: * Build the InterBase plugin on amd64, now that firebird2 works there. But it seems you forgot to change the control file to say that libqt3-mt-ibase should get build on amd64 which results in the following error: dh_gencontrol -a dpkg-gencontrol: error: current build architecture amd64 does not appear in package's list (i386 hurd-i386 kfreebsd-i386 knetbsd-i386 netbsd-i386) dh_gencontrol: command returned error code 65280 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341614: qt-x11-free: FTBFS on amd64: amd64 not in arch list.
On Thu, Dec 01, 2005 at 02:09:31PM -0500, Christopher Martin wrote: > Argh, that my my fault. Given that amd64 is still separate from the main > archive, can you fix the problem for amd64 with an amd64-specific update, > or would you much rather have a new upload from us? We do not patch anything in our archive. I should get very convincing reasons to do it otherwise. (This also happens to be a required to a release candidate). I could do an NMU of this if you want, but I prefer not to. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341614: qt-x11-free: FTBFS on amd64: amd64 not in arch list.
On Thu, Dec 01, 2005 at 03:30:12PM -0500, Christopher Martin wrote: > On December 1, 2005 15:14, you wrote: > > On Thu, Dec 01, 2005 at 02:09:31PM -0500, Christopher Martin wrote: > > > Argh, that my my fault. Given that amd64 is still separate from the > > > main archive, can you fix the problem for amd64 with an amd64-specific > > > update, or would you much rather have a new upload from us? > > > > We do not patch anything in our archive. I should get very > > convincing reasons to do it otherwise. (This also happens to > > be a required to a release candidate). > > > > I could do an NMU of this if you want, but I prefer not to. > > No, I'll make an upload to fix it later today. Sorry about the FUBAR. Thank you. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341766: firefox: FTBFS: Not using -fPIC to make shared lib.
Package: firefox Version: 1.4.99+1.5rc3.dfsg-2 Severity: serious Hi, Your package is failing to build on a few arches because it's not using -fPIC to make a shared library. On amd64: gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pthread -pipe -DNDEBUG -DTRIMMED -pipe -w -O2 -fPIC -shared -Wl,-h -Wl,libmozjs.so -o libmozjs.so jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o jsxml.o prmjtime.o-lm -ldl -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: jsapi.o: relocation R_X86_64_PC32 against `memset@@GLIBC_2.2.5' ca n not be used when making a shared object; recompile with -fPIC Or hppa: c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -pipe -w -O2 -fPIC -shared -Wl,-h -Wl,libunixprintplugin.so -o libunixprintplugin.so npshell.o printplugin.o npunix.o -L../../../../dist/bin -lxpcom -lxpcom_core -L../../../../dist/bin -L../../../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lXt -lSM -lICE -L/usr/X11R6/lib -lX11 -ldl -lm /usr/bin/ld: /usr/X11R6/lib/libXt.a(Event.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libXt.a: could not read symbols: Bad value But in this case I have to wonder why it's picking the static libXt instead of the shared version. Note that the 3 objects (npshell.o printplugin.o npunix.o) all seem to come from .c files, but for some reason it's linking it with c++? An other interesting error (on powerpc) is: gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pthread -pipe -DNDEBUG -DTRIMMED -pipe -w -O2 -o xpt_dump xpt_dump.o -L../../../../dist/bin -L../../../../dist/lib ../../../../dist/lib/libxpt.a -ldl -lm ../../../../dist/lib/libxpt.a(xpt_arena.o): In function `XPT_ArenaStrDup':xpt_arena.c:(.text+0x1f4): undefined reference to `memcpy@@GLIBC_2.0' ../../../../dist/lib/libxpt.a(xpt_struct.o): In function `XPT_InterfaceDescriptorAddTypes':xpt_struct.c:(.text+0x840): undefined reference to `memcpy@@GLIBC_2.0' ../../../../dist/lib/libxpt.a(xpt_struct.o): In function `XPT_InterfaceDescriptorAddMethods':xpt_struct.c:(.text+0x900): undefined reference to `memcpy@@GLIBC_2.0' ../../../../dist/lib/libxpt.a(xpt_struct.o): In function `XPT_InterfaceDescript orAddConsts':xpt_struct.c:(.text+0x9c0): undefined reference to `memcpy@@GLIBC_2.0' ../../../../dist/lib/libxpt.a(xpt_xdr.o): In function `GrowPool':xpt_xdr.c:(.text+0x560): undefined reference to `memcpy@@GLIBC_2.0' ../../../../dist/lib/libxpt.a(xpt_xdr.o):xpt_xdr.c:(.text+0x86c): more undefine d references to `memcpy@@GLIBC_2.0' follow collect2: ld returned 1 exit status Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341766: firefox: FTBFS: Not using -fPIC to make shared lib.
On Sat, Dec 03, 2005 at 09:49:33AM +0100, Mike Hommey wrote: > On Fri, Dec 02, 2005 at 10:08:09PM +0100, Kurt Roeckx <[EMAIL PROTECTED]> > > > > Your package is failing to build on a few arches because it's not > > using -fPIC to make a shared library. > > If you look closely at the command line, you'll see the -fPIC. The > problem is more likely to be with the visibility hidden thing. Right, I should have seen that. And I've seen those problems with visibility hidding before. There are your bug report #330279 and #331460, but there is also mine: #324290 Then there are still things like #307207. And upstream said they weren't going to fix those bugs in 4.0, since it's not a regression from previous version (that didn't support visibility attributes). I would stay away from it until atleast 4.1. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341826: libtagcoll-dev: c2a abi transition.
Package: libtagcoll-dev Version: 1.5.1-1 Severity: serious Hi, It seems your package is still using the c2 ABI instead of the c2a ABI. They have rescheduled binNMU's of your reverse dependencies but missed that you also need to do the ABI change first. I guess it didn't show up because you olny have a static library and don't have a dependency on libstdc++6. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341856: sbcl: FTBFS: fatal error encountered in SBCL
Package: sbcl Version: 1:0.9.7.1-1 Severity: serious Hi, Your package is failing to build with the following error: //entering make-host-1.sh //building cross-compiler, and doing first genesis fatal error encountered in SBCL pid 29839: can't find core file make: *** [build-arch-stamp] Error 1 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341857: gimp-gap: FTBFS: Not using -fPIC to make a shared lib.
Package: gimp-gap Version: 2.2.0-1 Severity: serious Hi, Your package is failing to build because it's not using -fPIC to make a shared library: cc -O3 -g -Wall -Wno-switch -g -Wall -O2 -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET _BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o bitstream.o bitstream.c [...] cc -shared -o libavcodec.so bitstream.o utils.o mem.o allcodecs.o mpegvideo.o jrevdct.o jfdctfst.o jfdctint.o mpegaudio.o ac3enc.o mjpeg.o resample.o resample2.o dsputil.o motion_est.o imgconvert.o imgresample.o mpeg12.o mpegaudiodec.o pcm.o simple_idct.o ratecontrol.o adpcm.o eval.o dv.o error_resilience.o fft.o mdct.o mace.o huffyuv.o cyuv.o raw.o h264.o golomb.o vp3.o asv1.o 4xm.o cabac.o ffv1.o ra144.o ra288.o vcr1.o cljr.o roqvideo.o dpcm.o interplayvideo.o xan.o rpza.o cinepak.o msrle.o msvideo1.o vqavideo.o idcinvideo.o adx.o rational.o faandct.o 8bps.o smc.o parser.o flicvideo.o truemotion1.o vmdav.o lcl.o qtrle.o g726.o flac.o vp3dsp.o integer.o snow.o tscc.o sonic.o ulti.o h264idct.o qdrw.o xl.o rangecoder.o png.o pnm.o qpeg.o vc9.o h263.o h261.o msmpeg4.o h263dec.o svq1.o rv10.o wmadec.o indeo3.o shorten.o loco.o alac.o wnv1.o ws-snd1.o aasc.o a52dec.o liba52/bit_allocate.o liba52/bitstream.o liba52/downmix.o liba52/imdct.o liba52/parse.o liba52/crc.o liba52/resample.o -lm -lz -ldl -Wl,--warn-comm on -rdynamic /usr/bin/ld: bitstream.o: relocation R_X86_64_32 against `a local symbol' can n ot be used when making a shared object; recompile with -fPIC bitstream.o: could not read symbols: Bad value Anyway, is there a reason you're not build depending on libavcodec-dev instead of building your own version of the library? It seems to contain the whole ffmpeg source? Kurt
Bug#333103: liferea: [gnome 2.12 transition] build-depend on dbus changes
reopen 333103 thanks Build depending on libdbus-glib-1-dev | dbus-glib-1-dev does not work. Neither apt nor sbuild is able to install the build dependencies. Either you need to get the new dbus name in unstable, keep this all to experimental, or reverse order of libdbus-glib-1-dev and dbus-glib-1-dev. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333103: liferea: [gnome 2.12 transition] build-depend on dbus changes
On Sat, Dec 03, 2005 at 09:30:24PM +0200, Martin-Éric Racine wrote: > la, 2005-12-03 kello 20:06 +0100, Kurt Roeckx kirjoitti: > > > Build depending on libdbus-glib-1-dev | dbus-glib-1-dev does not > > work. Neither apt nor sbuild is able to install the build > > dependencies. > > Figuring out WHY neither can would be useful. Because that's the way it works. You need to specify the package it should install first. It's the only thing that sbuild will consider. And please do not make it a virtual package. > > Either you need to get the new dbus name in unstable, keep this > > all to experimental, or reverse order of libdbus-glib-1-dev and > > dbus-glib-1-dev. > > Reversing the order sounds like counter-productive since we WANT to > prefer the new name, which is why it shows as the first alternative. The current version in unstable has an shlibs adding a dependency on dbus-glib-1 (>= 0.23.4), which I think is getting renamed to libdbus-glib-1? This means you will need to do some transition in any case. Having the build dependency support that now isn't going to make it much easier. The only thing it could have as advantage is that maybe it could be done as binNMUs instead of a sourceful upload. PS: Is the release team aware of those plans? Kurt
