Bug#931574: nftables: kernel BUG at lib/list_debug.c:53
Control: reassign -1 linux
(reassigning to the linux package because it's a kernel bug)
On sunday 7 july 2019 21:26:40 CEST, Tim Duesterhus wrote:
I performed a test upgrade of a cloud VM running Debian Stretch
to buster. After the upgrade the VM does not boot any longer if
the `nftables.service` is enabled and the 4.19 kernel is used,
because a kernel assertion is violated.
The old 4.9 kernel from stretch works fine.
Same here. I tried to update a VM with a moderatly complex firewall (and an
untainted kernel), and it randomly crashs when loading nftables rules with
a similar trace. No problems with 4.9. Fails with 4.19 from backports.
[...]
It looks like (one of) the two `flow table` lines are at fault,
but I am not able to confirm this for sure, because the assertion
is not 100% reliably triggered.
I can reproduce your crash quite reliably, maybe because I have kernel
hardening enabled (page_poison=1 slab_nomerge).
Can you try removing the anonymous sets from your configuration ?
Replacing "tcp dport { 22 }" with "tcp dport 22" in your example seems
to resolve the crash.
Unfortunatly, doing the same in my config is almost a full rewrite ...
I think it's fixed by this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/plain/releases/4.19.38/netfilter-nf_tables-fix-set-double-free-in-abort-pat.patch
https://bugzilla.kernel.org/show_bug.cgi?id=203039
There were some critical bugfixes for nftables in 4.19.38 and 4.19.44,
but buster is still using 4.19.37.
I tried building a vanilla 4.19.59 and excepting a (harmless ?) warning
("WARNING: CPU: 0 PID: 176 at net/netfilter/nf_tables_api.c:3588
nft_set_destroy+0x45/0x50 [nf_tables]) when the nf_tables_set module
is not loaded before using nftables, everything seems to work fine.
Kernel team: can we get an update in testing/s-p-u/... before the next
point
release to confirm it's fixed for good ? nftables is almost unusable with
anything but the most simple configuration right now.
Thanks.
Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another
On Tuesday 16 July 2019 23:11:24 Florian Weimer wrote: > * Nicholas D. Steeves: > > Package name: fuidshift > > Version : 3.0 > > Upstream Author : Name > > URL : https://github.com/lxc/lxd/tree/master/fuidshift > > License : Apache 2.0 > > Programming Lang: Go > > Description : remap a filesystem tree to shift one set of UID/GID > > ranges to another ... > How does this compare to (or interact with) newuidmap and newgidmap > from uidmap? They do very different things. Let me try a short description : newuidmap - set the uid mapping of a user namespace (from manpage) fuidshift - shift the uid/gid of files *on disk* fuidshift is basically a recursive chown $(( $(stat -c '%u' "$path") + $uidshift )) "$path" It does not use or configure user namespaces or containers. It's useful for the creation of containers images, for example when the container root filesystem is read-only (squashfs) and the container engine can't change the uids at runtime (see for example systemd-nspawn --private- users=pick / --private-users-chown). So fuidshift may be used to prepare a directory for later use by newuidmap, but that's about it. > There's a push to force uidmap on everyone, with tight integration > into NSS. If there's a competing scheme, it would be helpful to know > about it.
Bug#929067: reopen
Hi,
The patch enable-md-clear.patch in the deb9u6 update for stretch is wrong.
It defines md-clear to the 26th bit of FEAT_6_EAX instead of the 10th bit
of FEAT_7_0_EDX because the offset is wrong in the patch and the first line
does not match.
Result: the guest does not see the cpu flag:
# dmesg | grep -i mds
[0.131153] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
# grep md_clear /proc/cpuinfo
# cat /sys/devices/system/cpu/vulnerabilities/mds
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
Please find a fixed patch attached. With my patch:
# dmesg | grep -i mds
[0.132439] MDS: Mitigation: Clear CPU buffers
# grep md_clear /proc/cpuinfo
flags : [...] md_clear
# cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT Host state unknown
A correctly patched target-i386/cpu.c should look like this around line 452:
[FEAT_7_0_EDX] = {
.feat_names = {
NULL, NULL, "avx512-4vnniw", "avx512-4fmaps",
NULL, NULL, NULL, NULL,
NULL, NULL, "md-clear", NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, "spec-ctrl", NULL,
NULL, NULL, NULL, "ssbd",
},
.cpuid_eax = 7,
.cpuid_needs_ecx = true, .cpuid_ecx = 0,
.cpuid_reg = R_EDX,
.tcg_features = TCG_7_0_EDX_FEATURES,
},
How to test:
With libvirt, you have to patch /usr/share/libvirt/cpu_map.xml to add the
feature:
Add the feature to the virtual machine xml:
...
qemu will now start with the flag (or will not start if the microcode is not
patched):
qemu-system-x86_64 ... -cpu ...,+md-clear ...
Then, check for the presence of the cpu flag and mds status in an up to date
virtual machine.
Thanks.From: Paolo Bonzini
Date: Fri, 1 Mar 2019 21:40:52 +0100
Subject: target/i386: define md-clear bit
Bug-Debian: http://bugs.debian.org/929067
md-clear is a new CPUID bit which is set when microcode provides the
mechanism to invoke a flush of various exploitable CPU buffers by invoking
the VERW instruction. Add the new feature, and pass it down to
Hypervisor.framework guests.
Signed-off-by: Paolo Bonzini
[Backported to qemu 2.8 mjt]
CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
---
target-i386/cpu.c | 2 +-
target-i386/cpu.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index de1f30eeda6..bbb4526a043 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -449,7 +449,7 @@ static FeatureWordInfo feature_word_info
.feat_names = {
NULL, NULL, "avx512-4vnniw", "avx512-4fmaps",
NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, NULL, "md-clear", NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index c6057240227..c9c7f60a54d 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -632,6 +632,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
#define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural Network Instructions */
#define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation Single Precision */
+#define CPUID_7_0_EDX_MD_CLEAR (1U << 10) /* Microarchitectural Data Clear */
#define CPUID_7_0_EDX_SPEC_CTRL (1U << 26) /* Speculation Control */
#define CPUID_7_0_EDX_SPEC_CTRL_SSBD (1U << 31) /* Speculative Store Bypass Disable */
--
2.11.0
Bug#911259: ruby-httpclient: Please use the system ca-certificates instead of bundling one
Package: ruby-httpclient
Version: 2.8.3-1
Severity: normal
Dear Maintainer,
ruby-httpclient bundles a copy of the root certificate authorities:
$ dpkg -L ruby-httpclient | grep pem
/usr/lib/ruby/vendor_ruby/httpclient/cacert.pem
/usr/lib/ruby/vendor_ruby/httpclient/cacert1024.pem
...
Thus, the local CAs configured by the local system administrator (by adding
a .crt file in /usr/local/share/ca-certificates/) are ignored, the
explicitly
untrusted CAs are still valid, etc ...
Test (with ca-cacert installed):
$ ruby -rhttpclient -e 'p HTTPClient.get("https://www.cacert.org";)'
...
/usr/lib/ruby/vendor_ruby/httpclient/ssl_socket.rb:103:in `connect':
SSL_connect returned=1 errno=0 state=error: certificate verify failed
(unable to get local issuer certificate) (OpenSSL::SSL::SSLError)
Expected:
$ curl https://www.cacert.org
Please find attached a debdiff to use the system CA bundle instead.
Some comments:
- the file "cacert1024.pem" is not used by the code: removed
- the ca-certificates package is already pulled by rubygems-integration,
but a direct dependency may be better
Thanks.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ruby-httpclient depends on:
ii ruby1:2.5.1
ii ruby-http-cookie1.0.2-1
ii ruby2.1 [ruby-interpreter] 2.1.5-4
ii ruby2.2 [ruby-interpreter] 2.2.4-1
ruby-httpclient recommends no packages.
ruby-httpclient suggests no packages.
-- no debconf information
diff -Nru ruby-httpclient-2.8.3/debian/changelog ruby-httpclient-2.8.3/debian/changelog
--- ruby-httpclient-2.8.3/debian/changelog 2017-07-31 16:40:48.0 +0200
+++ ruby-httpclient-2.8.3/debian/changelog 2018-10-17 19:30:30.0 +0200
@@ -1,3 +1,9 @@
+ruby-httpclient (2.8.3-2) UNRELEASED; urgency=medium
+
+ * Unbundle the root CA list, use the one from ca-certificates
+
+ -- Vincent Tondellier Wed, 17 Oct 2018 19:30:30 +0200
+
ruby-httpclient (2.8.3-1) unstable; urgency=medium
* Team upload
diff -Nru ruby-httpclient-2.8.3/debian/ruby-httpclient.links ruby-httpclient-2.8.3/debian/ruby-httpclient.links
--- ruby-httpclient-2.8.3/debian/ruby-httpclient.links 1970-01-01 01:00:00.0 +0100
+++ ruby-httpclient-2.8.3/debian/ruby-httpclient.links 2018-10-17 13:32:19.0 +0200
@@ -0,0 +1 @@
+usr/lib/ssl/certs/ca-certificates.crt usr/lib/ruby/vendor_ruby/httpclient/cacert.pem
diff -Nru ruby-httpclient-2.8.3/debian/rules ruby-httpclient-2.8.3/debian/rules
--- ruby-httpclient-2.8.3/debian/rules 2017-07-31 16:40:48.0 +0200
+++ ruby-httpclient-2.8.3/debian/rules 2018-10-17 13:32:13.0 +0200
@@ -6,3 +6,8 @@
%:
dh $@ --buildsystem=ruby --with ruby
+
+override_dh_auto_install:
+ dh_auto_install
+ rm -f debian/ruby-httpclient/usr/lib/ruby/vendor_ruby/httpclient/cacert1024.pem
+ rm -f debian/ruby-httpclient/usr/lib/ruby/vendor_ruby/httpclient/cacert.pem
Bug#764738: sendfax fails with "ALLO: Command not implemented" with recent perl
Package: libfax-hylafax-client-perl Version: 1.02-2 Severity: important Hello, When using the sendfax function with perl 5.20, an error is returned: "Fax::Hylafax::Client: Communication error: ALLO: Command not implemented." This is due to this change in Net::FTP : https://github.com/steve-m-hay/perl-libnet/commit/0d616e68 It was fixed recently by https://github.com/steve-m-hay/perl-libnet/commit/d3f979bc I tested the patch, and can confirm that the fix works also for Hylafax. perl-modules is the package that needs to be fixed, but libfax-hylafax-client-perl is broken and may also need a Conflicts:, so I am filling the bug on libfax-hylafax-client-perl. Feel free to reassign if needed. Severity important because sendfax is an important functionality of the package. Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libfax-hylafax-client-perl depends on: ii perl 5.20.1-1 libfax-hylafax-client-perl recommends no packages. libfax-hylafax-client-perl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741667: oops in nf_nat_setup_info
Hello, I got the same oops on 3.12, 3.13, and 3.14 (bpo), without fglrx and xtables-addons : http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/52821 But 3.11.10-1~bpo70+1 works for me. It's unrelated to r8169. Can you try this patch : http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/plain/queue-3.14/netfilter-nf_conntrack-reserve-two-bytes-for-nf_ct_ext-len.patch or 3.15-rc7 (in experimental) ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503152: icemon (in icecc-monitor) displays nothing when compiled with icecc 0.9.0
Package: icecc
Version: 0.9.1-1
Severity: normal
Tags: patch
The problem is in the libicecc.a: the function
DiscoverSched::try_get_scheduler always return NULL because connect
always returns EINPROGRESS (the socket is non-blocking).
With the attached patch, we use a blocking sockect to connect to
scheduler. Tested on a 25 nodes cluster with no problems.
This bug is present in icecc-monitor=1.1-3 (compiled against icecc 0.9)
but was not present in icecc-monitor=1.1-2 (compiled against icecc 0.8).
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable'), (550, 'testing'), (25, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages icecc depends on:
ii adduser 3.110 add and remove users and groups
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii dpkg 1.14.22Debian package management system
ii g++ [c++-compiler]4:4.3.2-2 The GNU C++ compiler
ii g++-4.3 [c++-compiler]4.3.2-2~exp1 The GNU C++ compiler
ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.2-2~exp1 The GNU C compiler
ii libc6 2.8+20080809-2 GNU C Library: Shared libraries
ii libgcc1 1:4.3.2-2~exp1 GCC support library
ii libstdc++64.3.2-2~exp1 The GNU Standard C++ Library v3
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
icecc recommends no packages.
Versions of packages icecc suggests:
ii icecc-monitor 1.1-3 icecc monitor for KDE
-- debconf information excluded
*** 12_fix_nonblocking_sockets_for_icemon.diff
--- icecc-0.9.1.orig/services/comm.cpp 2008-05-12 19:57:14.0 +0200
+++ icecc-0.9.1/services/comm.cpp 2008-10-20 15:43:23.0 +0200
@@ -1160,14 +1160,21 @@
if (ask_fd >= 0)
{
+ fcntl(ask_fd, F_SETFL, 0);
int status = connect (ask_fd, (struct sockaddr*) &remote_addr,
sizeof(remote_addr) );
- if (status == 0 || (status < 0 && errno == EISCONN))
+ int connect_errno = errno;
+ fcntl(ask_fd, F_SETFL, O_NONBLOCK);
+ if (status == 0 || (status < 0 && connect_errno == EISCONN))
{
int fd = ask_fd;
ask_fd = -1;
return Service::createChannel(fd,
(struct sockaddr*) &remote_addr, sizeof(remote_addr));
}
+ else
+{
+ log_error() << "connect failed : " << strerror(connect_errno) <<
endl;
+}
}
return 0;
}
--- icecc-0.9.1.orig/services/comm.cpp 2008-05-12 19:57:14.0 +0200
+++ icecc-0.9.1/services/comm.cpp 2008-10-20 15:43:23.0 +0200
@@ -1160,14 +1160,21 @@
if (ask_fd >= 0)
{
+ fcntl(ask_fd, F_SETFL, 0);
int status = connect (ask_fd, (struct sockaddr*) &remote_addr,
sizeof(remote_addr) );
- if (status == 0 || (status < 0 && errno == EISCONN))
+ int connect_errno = errno;
+ fcntl(ask_fd, F_SETFL, O_NONBLOCK);
+ if (status == 0 || (status < 0 && connect_errno == EISCONN))
{
int fd = ask_fd;
ask_fd = -1;
return Service::createChannel(fd,
(struct sockaddr*) &remote_addr, sizeof(remote_addr));
}
+ else
+{
+ log_error() << "connect failed : " << strerror(connect_errno) <<
endl;
+}
}
return 0;
}
Bug#459020: [php-maint] Bug#459020: 043-recode_size_t.patch is invalid for recent php versions
Steve Langasek wrote: > On Wed, Feb 06, 2008 at 08:41:22PM +0100, Vincent Tondellier wrote: >> The patch 043-recode_size_t.patch is broken. > >> req_len and str_len should be integers, but are size_t >> (zend_parse_parameters wants pointers to int). This is a problem for 64 >> bits arches since a part of the variables is not initialized >> (sizof(size_t) != sizeof(int)), and recode_buffer_to_buffer is called >> with funny values that makes librecode eat all the system's memory. > > So then, PHP isn't capable of passing values whose length exceeds UINT_MAX? > That's an annoyingly arbitrary limitation. > PHP isn't designed to do large memory allocations ... > But yes, your analysis here looks correct to me. > >> An updated version of the patch witch fixes the problem for me is >> attached to this mail and should be, IMO, applied as a security fix for >> etch. > > I don't see any evidence that this is a security issue, but it should be > applied as a stable release update. > I think this is a security issue since it can cause a Denial Of Service by eating all the server memory. I had the problem on one of my servers (2GB RAM / 3GB swap) and it took at least 10min for oom_killer to kill the process, and in another case the kernel crashed (I didn't change the memory limit settings in /etc/security/limits.conf). And you can trigger the bug remotely by sending a mail like Sebastian Göbel said above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459020: 043-recode_size_t.patch is invalid for recent php versions
The patch 043-recode_size_t.patch is broken.
req_len and str_len should be integers, but are size_t
(zend_parse_parameters wants pointers to int). This is a problem for 64
bits arches since a part of the variables is not initialized
(sizof(size_t) != sizeof(int)), and recode_buffer_to_buffer is called
with funny values that makes librecode eat all the system's memory.
The patch was messed up during the conversion from php4 (r301 of the
pkg-kde svn repository).
This patch is not needed in testing/unstable and should be removed since
the bug for this patch (PHP#41765) was fixed upstream in php 5.2.4, but
a fixed version is needed for etch.
An updated version of the patch witch fixes the problem for me is
attached to this mail and should be, IMO, applied as a security fix for
etch.
--- php-5.2.0/ext/recode/recode.c.orig 2008-02-06 19:58:51.0 +0100
+++ php-5.2.0/ext/recode/recode.c 2008-02-06 19:59:13.0 +0100
@@ -132,7 +132,7 @@
{
RECODE_REQUEST request = NULL;
char *r = NULL;
- int r_len = 0, r_alen = 0;
+ size_t r_len = 0, r_alen = 0;
int req_len, str_len;
char *req, *str;
Bug#443669: fixed with last wxwidgets update
Package: amule Version: 2.1.3-4 I cannot reproduce this bug with wxwidgets 2.6.3.2.2-1. See bug #441766 for more informations. --- System information. --- Architecture: i386 Kernel: Linux 2.6.23-rc8 Debian Release: lenny/sid 990 unstableftp.de.debian.org 550 testing ftp.u-picardie.fr 500 unstablewww.debian-multimedia.org 25 experimentalftp.fr.debian.org --- Package information. --- Depends(Version) | Installed -+-== amule-common (= 2.1.3-4) | 2.1.3-4 libc6 (>= 2.6-1) | 2.6.1-5 libcrypto++6 | 5.5-4 libgcc1 (>= 1:4.2-20070516) | 1:4.3-20070902-1 libstdc++6 (>= 4.2-20070516) | 4.3-20070902-1 libwxbase2.6-0 (>= 2.6.3.2.1.5) | 2.6.3.2.2-1 libwxgtk2.6-0 (>= 2.6.3.2.1.5) | 2.6.3.2.2-1 zlib1g (>= 1:1.2.3.3.dfsg-1) | 1:1.2.3.3.dfsg-6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425166: Missing dependency on libyaml-perl
Package: ttf2tex Version: 0.70-8 Severity: important $ ttf2tex-mkpkg Can't locate YAML.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/bin/ttf2tex-mkpkg line 18. Installing libyaml-perl solves the problem. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.21.1-ck2 Debian Release: lenny/sid 991 unstablewww.debian-multimedia.org 990 unstableftp.fr.debian.org 25 experimentalftp2.fr.debian.org --- Package information. --- Depends (Version) | Installed =-+-=== freetype1-tools | 1.4pre.20050518-0.5 tetex-bin | OR texlive-font-utils| 2007-7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398462: libomniorb4c2: problem with float values in 4.0.6, please update to 4.0.7
Package: libomniorb4c2 Version: 4.0.6-2.2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is a problem with omniorb 4.0.6 and floats. See this message for a testcase and an explanation : http://www.omniorb-support.com/pipermail/omniorb-list/2006-May/027745.html Updating omniorb to 4.0.7 and python-omniorb2 to 2.7 fixes the problem. - -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (550, 'testing'), (25, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.1-ck1 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages libomniorb4c2 depends on: ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-19 GCC support library ii libomnithread3c24.0.6-2.2omniORB4 - CORBA ORB - libomnithre ii libssl0.9.8 0.9.8c-3 SSL shared libraries ii libstdc++6 4.1.1-19 The GNU Standard C++ Library v3 libomniorb4c2 recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFWO1SZmUHKLzaTmIRAhV8AJ9zS8PO7zQtCIfKBNZeFQWRqufNtwCgioeX BR6xk+QpKKTZVkIBE1ilkwM= =vAn4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398463: python-omniorb2: problem with float values in 2.6, please update to 2.7
Package: python-omniorb2 Version: 2.6-3.1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is a problem with python-omniorb 2.6 and floats. See this message for a testcase and an explanation : http://www.omniorb-support.com/pipermail/omniorb-list/2006-May/027745.html Updating omniorb to 4.0.7 and python-omniorb2 to 2.7 fixes the problem. - -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (550, 'testing'), (25, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.1-ck1 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages python-omniorb2 depends on: ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-19 GCC support library ii libomniorb4c2 4.0.6-2.2omniORB4 - CORBA ORB - libomniorb4 ii libomnithread3c24.0.6-2.2omniORB4 - CORBA ORB - libomnithre ii libstdc++6 4.1.1-19 The GNU Standard C++ Library v3 ii python 2.4.4-1 An interactive high-level object-o ii python-central 0.5.10 register and build utility for Pyt python-omniorb2 recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFWO36ZmUHKLzaTmIRArOdAJ49hNrAs8RyS7jXqwqzPIOH6TelggCglIY7 F3Rb64Az6hq7x+QtuHYCZxw= =OoVd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383532: python-svn: FTBFS when locale != C
Package: python-svn
Version: 1.4.2-2
Severity: serious
Tags: patch
Justification: no longer builds from source
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When LC_ALL != C and there is a subversion translation available, the
build system tries to compare a translated string (here 'exporté')
against the english word ('exported') (see Builder/brand_version.py
line 28).
The attached patch fix the problem.
The exact error message is:
/usr/bin/python2.3 ../Builder/brand_version.py ../Builder/version.info
pysvn_version.hpp.template
Info: revision exporté
Traceback (most recent call last):
File "../Builder/brand_version.py", line 31, in ?
revision, modifiers = re.compile( '(\d+)(.*)' ).search( build_revision
).groups()
AttributeError: 'NoneType' object has no attribute 'groups'
- -- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (550, 'testing'), (500, 'stable'), (25,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-beyond2
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to fr_FR.UTF-8)
Versions of packages python-svn depends on:
ii libapr0 2.0.55-4.1 The Apache Portable Runtime Librar
ii libc6 2.3.6-19 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-10 GCC support library
ii libstdc++6 4.1.1-10 The GNU Standard C++ Library v3
ii libsvn0 1.3.2-5+b1 Shared libraries used by Subversio
ii libuuid11.39-1 universally unique id library
ii python 2.4.3-11 An interactive high-level object-o
ii python-central 0.5.5register and build utility for Pyt
python-svn recommends no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE5NaOZmUHKLzaTmIRAra+AJ9GJ915I3HPpjho+pI7vLluGbFQMQCfU7ub
aNTzfy6gD4NY8Tf4gcruRhc=
=/8Sy
-END PGP SIGNATURE-
--- pysvn-1.4.2.orig/debian/rules 2006-08-17 22:37:19.0 +0200
+++ pysvn-1.4.2/debian/rules 2006-08-17 22:37:44.0 +0200
@@ -15,6 +15,7 @@
# This has to be exported to make some magic below work.
export DH_OPTIONS
+export LC_ALL=C
CFLAGS = -Wall -g #-fvisibility=hidden -fvisibility-inlines-hidden
Bug#383525: pysvn contains non-free material in Kit/Win32/vc6redist/
Package: pysvn Severity: serious Justification: Policy 2.2.1 The directory Kit/Win32/vc6redist/ in the tarball contains msvcirt.dll, msvcp60.dll and msvcrt.dll. These files are copyrighted by microsoft and does not meet the DFSG. Please remove them. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (550, 'testing'), (500, 'stable'), (25, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-beyond2 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) signature.asc Description: OpenPGP digital signature
Bug#383518: pysvn contains non-free material in Kit/Win32/vc6redist/
Package: pysvn Severity: serious Justification: Policy 2.2.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The directory Kit/Win32/vc6redist/ in the tarball contains msvcirt.dll, msvcp60.dll and msvcrt.dll. These files are copyrighted by microsoft and does not meet the DFSG. Please remove them. - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (550, 'testing'), (500, 'stable'), (25, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-beyond2 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE5NC9ZmUHKLzaTmIRAu1gAJ49k7Q34TX5PeDF88PnSdFyN6177wCeK/oe HeGZySr/GEIMEIZgVJmhWLY= =Ht/4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381505: avarice must not link with the shared version of libbfd
Package: avarice
Version: 2.4-2
Severity: grave
Tags: patch
Justification: renders package unusable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
avarice is linked with the shared version of libbfd, but the
binutils-dev says :
"Note that building Debian packages which depend on the shared libbfd is
Not Allowed."
This results in a broken package in current debian unstable :
$ avarice
avarice: error while loading shared libraries: libbfd-2.16.91.so: cannot
open shared object file: No such file or directory
A fix for the problem is attached. The check for libbfd is from the Lush
project
(http://lush.cvs.sourceforge.net/*checkout*/lush/lush/configure.ac)
Remember to run autoreconf.
I've not reported this bug to upstream.
- -- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (550, 'testing'), (25, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to fr_FR.UTF-8)
Versions of packages avarice depends on:
ii binutils2.17-2 The GNU assembler, linker and bina
ii libc6 2.3.6-18 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-10 GCC support library
ii libstdc++6 4.1.1-10 The GNU Standard C++ Library v3
ii libusb-0.1-42:0.1.12-2 userspace USB programming library
Versions of packages avarice recommends:
ii gdb-avr 6.4-1 The GNU Debugger for avr
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE08OKZmUHKLzaTmIRAiz6AJ9YQtvo93TeXnLkBY8zDwJjobirvgCfdqF/
m6iSgK5Qfks9FT8U5bjr9jU=
=qEUx
-END PGP SIGNATURE-
--- avarice-2.4.orig/configure.ac 2006-01-11 19:16:03.0 +0100
+++ avarice-2.4/configure.ac2006-08-04 22:11:54.0 +0200
@@ -64,13 +64,82 @@
fi
AC_CHECK_LIB([intl], [dcgettext])
AC_CHECK_LIB([iberty], [xmalloc])
-AC_CHECK_LIB([bfd], [bfd_init], , [ac_found_bfd=no])
-AC_CHECK_LIB([usb], [usb_get_string_simple])
+# bfd
+
+BFD_YES=''
+has_bfd=yes
+AC_CHECK_LIB(iberty, xmalloc)
+if test $ac_cv_lib_iberty_xmalloc = no; then
+ AC_CHECK_LIB(mmalloc, mmalloc)
+ AC_CHECK_LIB(iberty, xcalloc)
+fi
+AC_CHECK_HEADER(bfd.h,,has_bfd=no)
+AC_CHECK_LIB(bfd, bfd_init,,[has_bfd=no])
+AC_SUBST(BFD_YES)
+
+# Check if it compiles
+if test x$has_bfd = xyes ; then
+n_LIBS=$LIBS
+has_intl=
+AC_CHECK_LIB(intl, dcgettext, [has_intl=yes],[has_intl=no])
+i_LIBS=`echo $n_LIBS | sed -e 's/-liberty/& -lintl/'`
+sn_LIBS=`echo $n_LIBS | sed -e 's/-lbfd\( -liberty\)*/-Wl,-Bstatic &
-Wl,-Bdynamic/'`
+si_LIBS=`echo $i_LIBS | sed -e 's/-lbfd\( -liberty\)*/-Wl,-Bstatic &
-Wl,-Bdynamic/'`
+LIBS=$sn_LIBS
+AC_MSG_CHECKING([whether bfd works with -Bstatic])
+AC_TRY_LINK([#include "bfd.h"],
+[bfd_openr("junk1","default"); ],
+ [okay_bfd=yes],[okay_bfd=no]);
+AC_MSG_RESULT($okay_bfd)
+if test x$okay_bfd = xno ; then
+ if test x$has_intl = xyes ; then
+ LIBS=$si_LIBS
+ AC_MSG_CHECKING([whether bfd works with -Bstatic and -lintl])
+ AC_TRY_LINK([#include "bfd.h"],
+ [bfd_openr("junk1","default"); ],
+ [okay_bfd=yes],[okay_bfd=no]);
+ AC_MSG_RESULT($okay_bfd)
+ fi
+ if test x$okay_bfd = xno ; then
+ LIBS=$n_LIBS
+ AC_MSG_CHECKING([whether bfd works alone])
+ AC_TRY_LINK([#include "bfd.h"],
+ [bfd_openr("junk1","default"); ],
+ [okay_bfd=yes],[okay_bfd=no]);
+ AC_MSG_RESULT($okay_bfd)
+ if test x$okay_bfd = xno ; then
+ if test x$has_intl = xyes ; then
+ LIBS=$i_LIBS
+ AC_MSG_CHECKING([whether bfd works with -lintl])
+ AC_TRY_LINK([#include "bfd.h"],
+ [bfd_openr("junk1","default"); ],
+ [okay_bfd=yes],
+ [okay_bfd=no]);
+ AC_MSG_RESULT($okay_bfd)
+ fi
+ if test x$okay_bfd = xno ; then
+ LIBS=$n_LIBS
+ fi
+ fi
+ fi
+fi
+if test x$okay_bfd = xno ; then
+ has_bfd=no
+fi
+fi
-if test "x$ac_found_bfd" = "xno"; then
- AC_MSG_ERROR([You need to install libbfd.a from binutils.])
+if test x$has_bfd = xno ; then
+AC_MSG_ERROR([Unable to locate BFD development files.
+-
+We were unable to locate required GNU binutils files.
+- Some Linux distributions do not install these by default.
+ You need to install the 'libbinutils-devel' package.
+- On other platforms, get GNU binutils on www.fsf.org.
+-])
fi
+AC_CHEC
