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#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#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#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#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#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#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_CHECK_LIB([usb],
