Bug#632666: valgrind: Valgrind aborts on any problem with DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a
tag 632666 + wontfix thanks gcc-4.6 isn't in squeeze. Nor are the binutils that generate such dwarf operations. If you want to support a post-squeeze toolchain, please use a post-squeeze valgrind. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640152: acknowledged by developer (closing 640152)
tag 640152 + experimental thanks On Wed, Dec 21, 2011 at 04:36:48PM +0100, Philipp Kern wrote: Hi Pierre, am Wed, Dec 21, 2011 at 03:27:18PM + hast du folgendes geschrieben: This is an automatic notification regarding your Bug report #640152: FTBFS: needs build-dep on automake, which was filed against the valgrind package. It has been marked as closed by one of the developers, namely Pierre Habouzit madco...@debian.org. You should be hearing from them with a substantive response shortly, in case you haven't already. If not, please contact them directly. apart from close being deprecated: that's not how version tracking in the BTS works. You need to state versions that actually exist(ed) somewhere in the changelog. Otherwise it can't figure out where it got fixed. (Like a bug being re-introduced in a maintainer upload that didn't include a previous NMU, for instance.) It's a bug that isn't fixed by any package because it was a bogus upload in experimental, that is fixed because the 3.7.0 has been rerolled. It's transient, and doesn't warrant a Close in the 3.7.0 changelog that doesn't even come from the same git branch at all. It made no sense. (when I rolled the snapshot tarball for experimental I ran autoconf without the --copy flag and it had symlinks instead of copies of the autocrap stuff). I've closed this bug because it's just spurious, and never existed in the unstable branches. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640152: acknowledged by developer (closing 640152)
On Wed, Dec 21, 2011 at 09:39:20PM +0100, Philipp Kern wrote: Pierre, am Wed, Dec 21, 2011 at 07:14:36PM +0100 hast du folgendes geschrieben: It's a bug that isn't fixed by any package because it was a bogus upload in experimental, that is fixed because the 3.7.0 has been rerolled. It's transient, and doesn't warrant a Close in the 3.7.0 changelog that doesn't even come from the same git branch at all. It made no sense. (when I rolled the snapshot tarball for experimental I ran autoconf without the --copy flag and it had symlinks instead of copies of the autocrap stuff). ok, if the new upload doesn't have the old experimental changelog in it, it won't be affecting experimental anymore anyway and you could indeed just close it, but… I've closed this bug because it's just spurious, and never existed in the unstable branches. we're tracking more than unstable in the BTS, though. So I would've waited until a fixed package hits experimental, I guess. the experimental package was a pre 3.7.0 release, which has been released and uploaded to unstable, the experimental package will go away and I don't plan any experimental upload for a long time. But okay, next time I'll close from the changelog, I thought it made more sense, it wasn't a lapse, I made it on purpose to avoid cluttering the changelog with orthogonal stuff :) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652444: pulseaudio-module-raop: pulseaudio expects its modules in /usr/lib/pulse-1.1.0 they are in pulse-1.0
Package: pulseaudio-module-raop Version: 1.1-2 Severity: grave Justification: renders package unusable Launch paprefs you'll see it's impossible to use any PA modules because those are installed in the wrong directory. I've no clue why. As a quick hack, a symlink pulse-1.1.0 - pulse-1.0 works around the issue. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640495: Bug#564576: Package completely fails to support IPv6
On Fri, Oct 21, 2011 at 09:16:20PM +0200, Philipp Kern wrote: severity 640496 serious severity 640495 serious thanks On Mon, Sep 05, 2011 at 12:05:55PM +0200, Philipp Kern wrote: On Wed, Feb 16, 2011 at 09:56:32AM -0500, Scott Kitterman wrote: I replied directly, rather than to the bug by mistake. I will contact the maintainers of the two rdepends (spfmilter and whitelister) to see if they will fix libspf0, port their packages to libspf2 (which does support IPv6), or have them removed. Given that the orphan bug is already quite old (2007, #433108) and that it causes data loss, let's get rid of it. Filing bugs against its reverse dependencies because the library is going away. I'll try to remember to ask for its removal in a few weeks and upgrade those bugs to serious then. Upgrading now. I'll ask for libspf0's removal at the end of the month. Kind regards Philipp Kern You can remove whitelsiter, I don't maintain (upstream) it anymore. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638817: gnome-settings-daemon: here is a backtrace
Package: gnome-settings-daemon Version: 3.0.3-2 Followup-For: Bug #638817 gdb =gnome-settings-daemon [...] (gdb) r Starting program: /usr/bin/gnome-settings-daemon [Thread debugging using libthread_db enabled] [New Thread 0x71dc2700 (LWP 8366)] [New Thread 0x715c1700 (LWP 8367)] [New Thread 0x7fffebfff700 (LWP 8368)] [New Thread 0x7fffeb7fe700 (LWP 8369)] ** (gnome-settings-daemon:8362): WARNING **: Ignoring unknown module 'org.gnome.settings-daemon.plugins.gconf' [Thread 0x71dc2700 (LWP 8366) exited] (gnome-settings-daemon:8362): GLib-CRITICAL **: g_variant_get_va: assertion `value != NULL' failed Program received signal SIGSEGV, Segmentation fault. 0x767499a2 in g_atomic_int_exchange_and_add () from /lib/libglib-2.0.so.0 (gdb) bt #0 0x767499a2 in g_atomic_int_exchange_and_add () from /lib/libglib-2.0.so.0 #1 0x767aceb2 in g_variant_unref () from /lib/libglib-2.0.so.0 #2 0x7fffdd4483f2 in ?? () from /usr/lib/gnome-settings-daemon-3.0/libupdates.so #3 0x76e588f0 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #4 0x76e36f9c in ?? () from /usr/lib/libgobject-2.0.so.0 #5 0x76e39f42 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #6 0x76e3ab0c in g_object_new () from /usr/lib/libgobject-2.0.so.0 #7 0x7fffdd448be2 in gsd_updates_refresh_new () from /usr/lib/gnome-settings-daemon-3.0/libupdates.so #8 0x7fffdd44cc5c in gsd_updates_manager_start () from /usr/lib/gnome-settings-daemon-3.0/libupdates.so #9 0x7fffdd44778c in ?? () from /usr/lib/gnome-settings-daemon-3.0/libupdates.so #10 0x0040595d in gnome_settings_plugin_info_activate () #11 0x004048e5 in _start () (gdb) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640152: FTBFS: needs build-dep on automake
On Fri, Sep 02, 2011 at 11:58:05PM +0200, Philipp Kern wrote: Package: valgrind Version: 1:3.6.99svn12003-1 Severity: serious The version of valgrind in experimental FTBFS'es on all architectures because a build-dep on automake is missing: ~/valgrind-3.6.99svn12003# ls -al install-sh lrwxrwxrwx 1 root root 35 Aug 28 21:11 install-sh - /usr/share/automake-1.11/install-sh This is actually dangling until you install the current automake, which provides automake1.11. yeah I noticed that it's rather that the tarball I rolled was badly generated with symlinks instead of copies :/ -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632666: Acknowledgement (valgrind: Valgrind aborts on any problem with DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a)
On Tue, Jul 05, 2011 at 10:34:12AM +0100, Derick Rethans wrote: Hi! This is fixed upstream now: https://bugs.kde.org/show_bug.cgi?id=277045 cheers, Derick Thanks, I'll try to backport that then. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626170: libstrongswan: dependencies aren't tight enough
Package: libstrongswan Version: 4.4.1-5.1 Severity: serious [25294.276350] charon[22317] general protection ip:7f0e621ecaf7 sp:7fff00632380 error:0 in libstrongswan.so.0.0.0[7f0e621d+3] If you only upgrade libstrongswan from unstable into squeeze, charon segfaults at startup, probably because the dependencies aren't tight enough. (actually in order to test if #626169 is present in 4.4.1 from squeeze I didn't downgrade it unlike strongswan* and dpkg didn't complain). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625521: glibc: causes segfault in Xorg
On Thu, May 05, 2011 at 09:56:03AM +0200, sean finney wrote: Maybe valgrind already does checks like this [...] It does. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624851: cnetworkmanager: doesn't work
Package: cnetworkmanager Version: 0.21.1-1.1 Severity: grave Justification: renders package unusable cnetworkmanager just doesn't work, for example: $ cnetworkmanager -a Traceback (most recent call last): File /usr/bin/cnetworkmanager, line 178, in module aap = dev[ActiveAccessPoint] File /usr/lib/pymodules/python2.6/dbusclient/__init__.py, line 174, in __getitem__ value = super(DBusClient, self).__getitem__(key) File /usr/lib/pymodules/python2.6/dbusclient/__init__.py, line 77, in __getitem__ return pmi.Get(iface, key, byte_arrays=True) File /usr/lib/pymodules/python2.6/dbus/proxies.py, line 68, in __call__ return self._proxy_method(*args, **keywords) File /usr/lib/pymodules/python2.6/dbus/proxies.py, line 140, in __call__ **keywords) File /usr/lib/pymodules/python2.6/dbus/connection.py, line 630, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Property ActiveAccessPoint of interface org.freedesktop.NetworkManager.Device isn't exported (or may not exist) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612291: [Pkg-utopia-maintainers] Bug#612291: Bug#612291: Acknowledgement (network-manager and network-manager-gnome must be of the same version)
On Sun, Mar 06, 2011 at 05:08:24PM +0100, Michael Biebl wrote: Am 07.02.2011 17:09, schrieb Michael Biebl: On 07.02.2011 14:32, Pierre Habouzit wrote: Btw, the bug is on nm because it has /at least/ to be updated with a Breaks: network-manager-gnome 0.8.2 To be compatible with what is in squeeze. That is one possibility. Ideally 0.8.1 nm-applet should continue to work with nm 0.8.2, though. I'll try to reproduce the problem locally and see what' going on. Here are my test results so far: Today I've setup a squeeze installation with nm 0.8.1 and nm-applet 0.8.1. I created a VPN (PPTP) connection, a DHCP, DHCP (addresses only) and static configuration for my wireless interface. Then I upgraded network-manager to 0.8.2 and kept nm-applet at 0.8.1. Everything continued to work fine. I went back to nm 0.8.1 and created a connection for my ethernet interface. I then upgraded nm to 0.8.2 I indeed got a failure. NetworkManager --log-level=debug does not output anything interesting. I noticed though, that when starting nm-applet 0.8.1, I get the following output: ** (nm-applet:24735): WARNING **: Unhandled setting property type (read): '802-3-ethernet/s390-subchannels' : 'GPtrArray_gchararray_' ** (nm-applet:24735): WARNING **: Invalid connection /system/networking/connections/5: 'NMSettingWired' / 's390-options' invalid: 1 And as a result the wireless connection I created is not shown in the context menu of nm-applet and no connection is activated. If I upgrade nm-applet to 0.8.2 and restart it, the two warnings are gone and nm-applet successfully establishes the connection via ethernet. Afaics, the s390 options for ethernet were indeed added between 0.8.1 and 0.8.2. I don't quite understand the mechanisms here. Dan, are those s390 options now mandatory and need to be passed from the client to NetworkManager? Why does nm-applet fail here? Are new API additions / options supposed to create problems on the client side? Is this maybe actually a client / nm-applet problem? Dan, are nm-applet and nm really supposed to be of the exact same version or do you try to keep them compatible during stable revisions? FWIW, as I need to get a few fixes into testing I'll add the Breaks: to network-manager for now, so the package can migrate. Hopefully we can find a different solution, which doesn't impose such strict version requirements and I'd lift the Breaks later again. Okay, it's good that you've been able to reproduce, I've been sick and at the hospital for some time and wasn't able to reproduce. Have a nice day. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612291: [Pkg-utopia-maintainers] Bug#612291: Bug#612291: Acknowledgement (network-manager and network-manager-gnome must be of the same version)
I'm in vacation, I'll come back to you when I come back. Cheers. On Tue, Feb 22, 2011 at 09:10:07PM +0100, Michael Biebl wrote: Hi Pierre, talked to upstream. He would like to see a full debug log and ~/.xsession-errors. The debug log can be obtained by running NetworkManager --no-daemon --log-level=debug Thanks, Michael -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613345: libapache2-mod-php5: gc_probability set to 0
Package: libapache2-mod-php5 Version: 5.3.3-7 Severity: grave The last php5 upload sets session.gc_probability to 0, which means that sessions aren't GC'ed anymore which is a possible source for DOSes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613345: [php-maint] Bug#613345: libapache2-mod-php5: gc_probability set to 0
reopen 613345 retitle 613345 please document session.gc_maxlifetime being set to 0 in NEWS.Debian severity 613345 normal thanks On Mon, Feb 14, 2011 at 01:03:44PM +0100, Ondřej Surý wrote: close 613345 thank you From php5-common.README.Debian: Session storage --- Session files are stored in /var/lib/php5. For security purposes, this directory is unreadable by non-root users. This means that php5 running from apache2, for example, will not be able to clean up stale session files. Instead, we have a cron job run every 30 mins that cleans up stale session files; /etc/cron.d/php5. You may need to modify how often this runs, if you've modified session.gc_maxlifetime in your php.ini; otherwise, it may be too lax or overly aggressive in cleaning out stale session files. Andres Salomon dilin...@debian.org Fri, 03 Sep 2004 03:12:54 -0400 Why wasn't it put in NEWS.Debian ? I watch this file and wouldn't have raised the bug if I had seen that. This is a disruptive change that should go there. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612291: network-manager and network-manager-gnome must be of the same version
Package: network-manager Version: 0.8.2-5 Severity: grave Justification: renders package unusable With network-manager-gnome 0.8.1 I'm unable to let NM activate the ethernet connection (wifi works fine though). Upgrading to nm-applet 0.8.2 from experimental works around the problem. This is either a bug from nm that should understand nm-applet from 0.8.1, or nm-applet that should require the exact same version for nm, and in that case please reassign the bug. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612291: Acknowledgement (network-manager and network-manager-gnome must be of the same version)
Btw, the bug is on nm because it has /at least/ to be updated with a Breaks: network-manager-gnome 0.8.2 To be compatible with what is in squeeze. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612291: [Pkg-utopia-maintainers] Bug#612291: network-manager and network-manager-gnome must be of the same version
On Mon, Feb 07, 2011 at 04:51:29PM +0100, Michael Biebl wrote: On 07.02.2011 14:23, Pierre Habouzit wrote: Package: network-manager Version: 0.8.2-5 Severity: grave Justification: renders package unusable With network-manager-gnome 0.8.1 I'm unable to let NM activate the ethernet connection (wifi works fine though). Upgrading to nm-applet 0.8.2 from experimental works around the problem. This is either a bug from nm that should understand nm-applet from 0.8.1, or nm-applet that should require the exact same version for nm, and in that case please reassign the bug. Please send me the output of running NetworkManager --no-daemon when you try to activate the connection via nm-applet 0.8.1 Right away sir! Here are the bits with 0.8.1: NetworkManager[23895]: info NetworkManager (version 0.8.2) is starting... NetworkManager[23895]: info Read config file /etc/NetworkManager/NetworkManager.conf NetworkManager[23895]: info VPN: loaded org.freedesktop.NetworkManager.openvpn NetworkManager[23895]: info VPN: loaded org.freedesktop.NetworkManager.vpnc NetworkManager[23895]: info trying to start the modem manager... NetworkManager[23895]: info monitoring kernel firmware directory '/lib/firmware'. [... skipping boring stuff related to my wifi being on kill switch ...] NetworkManager[23895]: info Networking is enabled by state file NetworkManager[23895]: info (eth0): carrier is OFF NetworkManager[23895]: info (eth0): new Ethernet device (driver: 'e1000e' ifindex: 2) NetworkManager[23895]: info (eth0): exported as /org/freedesktop/NetworkManager/Devices/0 NetworkManager[23895]: info (eth0): now managed NetworkManager[23895]: info (eth0): device state change: 1 - 2 (reason 2) NetworkManager[23895]: info (eth0): bringing up device. NetworkManager[23895]: info (eth0): preparing device. NetworkManager[23895]: info (eth0): deactivating device (reason: 2). NetworkManager[23895]: info (wlan0): driver supports SSID scans (scan_capa 0x01). NetworkManager[23895]: info (wlan0): new 802.11 WiFi device (driver: 'iwlagn' ifindex: 3) NetworkManager[23895]: info (wlan0): exported as /org/freedesktop/NetworkManager/Devices/1 NetworkManager[23895]: info (wlan0): now managed NetworkManager[23895]: info (wlan0): device state change: 1 - 2 (reason 2) NetworkManager[23895]: info (wlan0): bringing up device. NetworkManager[23895]: info (wlan0): deactivating device (reason: 2). /sbin/ifup: interface lo already configured NetworkManager[23895]: warn bluez error getting default adapter: No such adapter NetworkManager[23895]: info (eth0): carrier now ON (device state 2) NetworkManager[23895]: info (eth0): device state change: 2 - 3 (reason 40) NetworkManager[23895]: user_connection_updated_cb: assertion `old_connection != NULL' failed NetworkManager[23895]: info Activation (eth0) starting connection 'Auto Ethernet' NetworkManager[23895]: info (eth0): device state change: 3 - 4 (reason 0) NetworkManager[23895]: info Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager[23895]: info Activation (eth0) Stage 1 of 5 (Device Prepare) started... NetworkManager[23895]: info Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager[23895]: info Activation (eth0) Stage 1 of 5 (Device Prepare) complete. NetworkManager[23895]: info Activation (eth0) Stage 2 of 5 (Device Configure) starting... NetworkManager[23895]: info (eth0): device state change: 4 - 5 (reason 0) NetworkManager[23895]: info Activation (eth0) Stage 2 of 5 (Device Configure) successful. NetworkManager[23895]: info Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled. NetworkManager[23895]: info Activation (eth0) Stage 2 of 5 (Device Configure) complete. NetworkManager[23895]: info Activation (eth0) Stage 3 of 5 (IP Configure Start) started... NetworkManager[23895]: info (eth0): device state change: 5 - 7 (reason 0) NetworkManager[23895]: info Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds) NetworkManager[23895]: info dhclient started with pid 23901 NetworkManager[23895]: info Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ NetworkManager[23895]: info (eth0): DHCPv4 state changed nbi - preinit NetworkManager[23895]: info (eth0): device state change: 7 - 3 (reason 0) NetworkManager[23895]: info (eth0): deactivating device (reason: 0). NetworkManager[23895]: info (eth0): canceled DHCP transaction, DHCP client pid 23901 NetworkManager[23895]: info Activation (eth0) starting connection 'Auto Ethernet' NetworkManager[23895]: info (eth0): device state change: 3 - 4
Bug#612291: [Pkg-utopia-maintainers] Bug#612291: Acknowledgement (network-manager and network-manager-gnome must be of the same version)
On Mon, Feb 07, 2011 at 05:09:21PM +0100, Michael Biebl wrote: On 07.02.2011 14:32, Pierre Habouzit wrote: Btw, the bug is on nm because it has /at least/ to be updated with a Breaks: network-manager-gnome 0.8.2 To be compatible with what is in squeeze. That is one possibility. Ideally 0.8.1 nm-applet should continue to work with nm 0.8.2, though. Sure, that's what I expected, I only tried the nm-applet from experimental as a last measure test, and was surprised it did fix the issue. I'll try to reproduce the problem locally and see what' going on. If that helps, I have a non standard eth0 setting, namely in the IP4 settings: * automatic (DHCP) addresses only * DNS server is forced to 127.0.0.1 (I have my own cache) * search is set to corp madism.org I've not changed anything from the defaults for the rest. Despite similar chages on my wifi interfaces and an openvpn connection, I've not tweaked NM in any kind of fashion wrt the default install. Cheers, -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606319: irssi crashes when changing window
tag 606319 + patch
thanks
I'm almost sure this is
http://bugs.irssi.org/index.php?do=detailstask_id=669
Attached is a patch that seems to fix it for me.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
From f124a50beee43665ade240058836098c2418fa24 Mon Sep 17 00:00:00 2001
From: Pierre Habouzit madco...@debian.org
Date: Thu, 9 Dec 2010 23:20:08 +0100
Subject: [PATCH] Avoid segfault in with cumode_space
Signed-off-by: Pierre Habouzit madco...@debian.org
---
src/irc/core/irc-expandos.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/irc/core/irc-expandos.c b/src/irc/core/irc-expandos.c
index 0c0da64..1c3a353 100644
--- a/src/irc/core/irc-expandos.c
+++ b/src/irc/core/irc-expandos.c
@@ -106,7 +106,14 @@ static char *expando_cumode_space(SERVER_REC *server, void *item, int *free_ret)
return ;
ret = expando_cumode(server, item, free_ret);
- return *ret == '\0' ? : ret;
+if (*ret == '\0') {
+if (*free_ret) {
+g_free(ret);
+*free_ret = FALSE;
+}
+ret = ;
+}
+return ret;
}
static void event_join(IRC_SERVER_REC *server, const char *data,
--
1.7.3.2.633.gba590
Bug#606319: irssi crashes when changing window
Package: irssi Version: 0.8.15-1 Severity: grave Justification: renders package unusable Here is a backtrace. I just send irssi, hit alt-7 which does basically /win 7 and it crashes /window 7 crashes in the same fashion Program received signal SIGSEGV, Segmentation fault. 0xb7a8ab99 in free () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7a8ab99 in free () from /lib/i686/cmov/libc.so.6 #1 0xb7d80c56 in g_free () from /lib/libglib-2.0.so.0 #2 0x0809e9ae in theme_format_expand_data () #3 0x0809e7a7 in theme_format_expand_data () #4 0x08066c04 in statusbar_item_default_handler () #5 0x08066ec0 in ?? () #6 0x08067c83 in statusbar_item_redraw () #7 0x08067e72 in ?? () #8 0x080e0ace in ?? () #9 0x080e10bc in signal_emit () #10 0x080a454f in window_set_active () #11 0x080a0bc8 in ?? () #12 0x080e0ace in ?? () #13 0x080e10bc in signal_emit () #14 0x0805f214 in ?? () #15 0x080e0ace in ?? () #16 0x080e10bc in signal_emit () #17 0x08099543 in key_pressed () #18 0x0805f044 in ?? () #19 0x080e0ace in ?? () #20 0x080e10bc in signal_emit () #21 0x08062048 in ?? () #22 0x080d268e in ?? () #23 0xb7dbc6db in ?? () from /lib/libglib-2.0.so.0 #24 0xb7d78305 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #25 0xb7d7bfe8 in ?? () from /lib/libglib-2.0.so.0 #26 0xb7d7c1c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #27 0x08071e1c in main () -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606319: irssi crashes when changing window
On Wed, Dec 08, 2010 at 12:34:32PM +0100, Pierre Habouzit wrote: Package: irssi Version: 0.8.15-1 Severity: grave Justification: renders package unusable Here is a backtrace. I just send irssi, hit alt-7 which does basically /win 7 and it crashes /window 7 crashes in the same fashion I did a debug build for a full stack and it yields: #0 0xb7a8ab99 in free () from /lib/i686/cmov/libc.so.6 #1 0xb7d80c56 in g_free () from /lib/libglib-2.0.so.0 #2 0x0809eade in data_is_empty (theme=0x8134000, format=0xb7b5cff4, default_fg=110 'n', default_bg=110 'n', save_last_fg=0xbfffc69d nnnL\356\020\b\352N\020\b\310\306\377\277\060\350V\b\210R\033\bP\321]\b\b\307\377\277\064l\006\b, save_last_bg=0xbfffc69c L\356\020\b\352N\020\b\310\306\377\277\060\350V\b\210R\033\bP\321]\b\b\307\377\277\064l\006\b, flags=value optimized out) at themes.c:294 #3 theme_format_expand_abstract (theme=0x8134000, format=0xb7b5cff4, default_fg=110 'n', default_bg=110 'n', save_last_fg=0xbfffc69d nnnL\356\020\b\352N\020\b\310\306\377\277\060\350V\b\210R\033\bP\321]\b\b\307\377\277\064l\006\b, save_last_bg=0xbfffc69c L\356\020\b\352N\020\b\310\306\377\277\060\350V\b\210R\033\bP\321]\b\b\307\377\277\064l\006\b, flags=value optimized out) at themes.c:370 #4 theme_format_expand_data (theme=0x8134000, format=0xb7b5cff4, default_fg=110 'n', default_bg=110 'n', save_last_fg=0xbfffc69d nnnL\356\020\b\352N\020\b\310\306\377\277\060\350V\b\210R\033\bP\321]\b\b\307\377\277\064l\006\b, save_last_bg=0xbfffc69c L\356\020\b\352N\020\b\310\306\377\277\060\350V\b\210R\033\bP\321]\b\b\307\377\277\064l\006\b, flags=value optimized out) at themes.c:484 #5 0x0809e8d7 in theme_format_expand_abstract (theme=0x8134000, format=0xbfffc718, default_fg=110 'n', default_bg=110 'n', save_last_fg=0x0, save_last_bg=0x0, flags=value optimized out) at themes.c:427 #6 theme_format_expand_data (theme=0x8134000, format=0xbfffc718, default_fg=110 'n', default_bg=110 'n', save_last_fg=0x0, save_last_bg=0x0, flags=value optimized out) at themes.c:484 #7 0x08066c34 in statusbar_item_default_handler (item=0x8162b78, get_size_only=1, str=0x816d306 , data=0x80fe434 , escape_vars=1) at statusbar.c:692 #8 0x08066ef0 in statusbar_item_default_func (item=0x8162b78, get_size_only=1) at statusbar.c:737 #9 0x08067cb3 in statusbar_item_redraw (item=0x8162b78) at statusbar.c:349 #10 0x08067ea2 in statusbar_update_item () at statusbar.c:749 #11 0x080e0c3e in signal_emit_real (rec=0x8139d70, params=value optimized out, va=0x80f0ed9 , first_hook=0x8162a78) at signals.c:242 #12 0x080e122c in signal_emit (signal=0x80f13cd window changed, params=2) at signals.c:286 #13 0x080a466f in window_set_active (window=0x81b5288) at fe-windows.c:159 #14 0x080a0cf8 in cmd_window_goto (data=0x81665f8 7) at window-commands.c:348 #15 0x080e0c3e in signal_emit_real (rec=0x8134748, params=value optimized out, va=0x80f0ed9 , first_hook=0x8139e78) at signals.c:242 #16 0x080e122c in signal_emit (signal=0x80f6ab6 command window goto, params=3) at signals.c:286 #17 0x0805f204 in key_change_window (data=0x81665f8 7) at gui-readline.c:699 #18 0x080e0c3e in signal_emit_real (rec=0x8151ea0, params=value optimized out, va=0x80f0ed9 , first_hook=0x8151ec0) at signals.c:242 #19 0x080e122c in signal_emit (signal=0x85f59d8 key change_window, params=3) at signals.c:286 #20 0x08099673 in key_emit_signal (keyboard=0x8151120, key=0xbfffcaa4 7) at keyboard.c:538 #21 key_pressed (keyboard=0x8151120, key=0xbfffcaa4 7) at keyboard.c:594 #22 0x0805f034 in sig_gui_key_pressed (keyp=0x37) at gui-readline.c:406 #23 0x080e0c3e in signal_emit_real (rec=0x8162370, params=value optimized out, va=0x80f0ed9 , first_hook=0x81625e8) at signals.c:242 #24 0x080e122c in signal_emit (signal=0x80f0a82 gui key pressed, params=1) at signals.c:286 #25 0x08062038 in sig_input () at gui-readline.c:664 #26 0x080d277e in irssi_io_invoke (source=0x81506f0, condition=135204561, data=0x80f0ed9) at misc.c:54 #27 0xb7dbc6db in ?? () from /lib/libglib-2.0.so.0 #28 0xb7d78305 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #29 0xb7d7bfe8 in ?? () from /lib/libglib-2.0.so.0 #30 0xb7d7c1c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #31 0x08071e4c in main (argc=1, argv=0xbfffcf24) at irssi.c:356 -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598492: linux-image-2.6.35-trunk-amd64: suspend/hibernate is totally fucked up
Package: linux-2.6 Version: 2.6.35-1~experimental.3 Severity: grave With the 2.6.35 kernel, suspend and hibernation result is various kind of issues on a random basis at exit time, meaning that sometimes the suspend/hibernation doesn't put the machine to sleep, but instead I've gotten: - 100% CPUs instead of stopping the machine; - blank screens with nothing able to wake up the machine (not even sysrqs); - kernel errors (for hibernation), though for some reason this wasn't logged to /var/log. In addition to that, for some reason, when I come back from suspend, my keyboard mapping in X is lost, which doesn't happen if I boot a .32 kernel. -- Package-specific info: ** Version: Linux version 2.6.35-trunk-amd64 (Debian 2.6.35-1~experimental.3) (m...@debian.org) (gcc version 4.4.5 20100902 (prerelease) (Debian 4.4.4-13) ) #1 SMP Mon Sep 6 15:15:26 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.35-trunk-amd64 root=/dev/mapper/ssd-root ro quiet i915.modeset=1 ** Not tainted ** Kernel log: [ 1788.609537] PM: Saving platform NVS memory [ 1788.610392] PM: Saving platform NVS memory [ 1788.611095] Disabling non-boot CPUs ... [ 1788.716024] CPU 1 is now offline [ 1788.716026] SMP alternatives: switching to UP code [ 1788.720681] Extended CMOS year: 2000 [ 1788.720763] PM: Creating hibernation image: [ 1788.724006] PM: Need to copy 128129 pages [ 1788.724006] PM: Normal pages needed: 128129 + 1024, available pages: 908063 [ 1788.724006] PM: Restoring platform NVS memory [ 1788.724006] Extended CMOS year: 2000 [ 1788.724006] Enabling non-boot CPUs ... [ 1788.724006] SMP alternatives: switching to SMP code [ 1788.725136] Booting Node 0 Processor 1 APIC 0x1 [ 1788.840807] CPU1 is up [ 1788.841542] ACPI: Waking up from system sleep state S4 [ 1788.917419] e1000e :00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10a) [ 1788.917434] e1000e :00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0xefe1) [ 1788.917438] e1000e :00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xf6adb000) [ 1788.917443] e1000e :00:19.0: restoring config space at offset 0x4 (was 0x0, writing 0xf6ae) [ 1788.917450] e1000e :00:19.0: restoring config space at offset 0x1 (was 0x10, writing 0x100107) [ 1788.917634] HDA Intel :00:1b.0: restoring config space at offset 0x1 (was 0x100106, writing 0x100102) [ 1788.918111] ahci :00:1f.2: restoring config space at offset 0x1 (was 0x2b00403, writing 0x2b00407) [ 1788.918327] firewire_ohci :03:01.0: proprietary Ricoh MMC controller disabled (via firewire function) [ 1788.918328] firewire_ohci :03:01.0: MMC cards are now supported by standard SDHCI controller [ 1788.933015] sdhci-pci :03:01.1: BAR 0: set to [mem 0xf65ff600-0xf65ff6ff] (PCI address [0xf65ff600-0xf65ff6ff] [ 1788.933041] sdhci-pci :03:01.1: restoring config space at offset 0x3 (was 0x80, writing 0x804010) [ 1788.933047] sdhci-pci :03:01.1: restoring config space at offset 0x1 (was 0x210, writing 0x2100106) [ 1788.933136] PM: early restore of devices complete after 15.789 msecs [ 1788.966805] i915 :00:02.0: setting latency timer to 64 [ 1788.966843] pci:00: wake-up capability disabled by ACPI [ 1788.966848] e1000e :00:19.0: PME# disabled [ 1788.966923] e1000e :00:19.0: irq 44 for MSI/MSI-X [ 1788.968978] uhci_hcd :00:1a.0: setting latency timer to 64 [ 1788.969003] usb usb2: root hub lost power or was reset [ 1788.969050] uhci_hcd :00:1a.1: setting latency timer to 64 [ 1788.969087] usb usb3: root hub lost power or was reset [ 1788.969106] uhci_hcd :00:1a.2: setting latency timer to 64 [ 1788.969143] usb usb4: root hub lost power or was reset [ 1788.969159] ehci_hcd :00:1a.7: setting latency timer to 64 [ 1788.969180] usb usb1: root hub lost power or was reset [ 1788.973056] ehci_hcd :00:1a.7: cache line size of 64 is not supported [ 1788.973071] uhci_hcd :00:1d.0: setting latency timer to 64 [ 1788.973108] usb usb5: root hub lost power or was reset [ 1788.973126] uhci_hcd :00:1d.1: setting latency timer to 64 [ 1788.973163] usb usb6: root hub lost power or was reset [ 1788.973181] uhci_hcd :00:1d.2: setting latency timer to 64 [ 1788.973219] usb usb7: root hub lost power or was reset [ 1788.973237] ehci_hcd :00:1d.7: setting latency timer to 64 [ 1788.973251] usb usb8: root hub lost power or was reset [ 1788.977145] ehci_hcd :00:1d.7: cache line size of 64 is not supported [ 1788.977157] pci :00:1e.0: setting latency timer to 64 [ 1788.977169] ahci :00:1f.2: setting latency timer to 64 [ 1788.977266] iwlagn :0c:00.0: RF_KILL bit toggled to disable radio. [ 1788.977271] sdhci-pci :03:01.1: PCI INT C - GSI 18 (level, low) - IRQ 18 [ 1788.978344] HDA Intel :00:1b.0: PCI INT A - GSI 21 (level, low) - IRQ 21 [ 1788.978350] HDA Intel :00:1b.0: setting latency timer to 64 [ 1788.978385] HDA Intel :00:1b.0: irq 47 for
Bug#558034: oss4-source: does not ship udev rules for creating device files
retitle 558034 oss4-kernel stuff should depends oss4-base severity 558034 grave thanks On Thu, Nov 26, 2009 at 11:55:40AM +0900, Norbert Preining wrote: Package: oss4-source Version: 4.2-build2000-1 Severity: important $ cat /proc/opensound/devfiles sndstat 249 0 midi 249 1 mixer 249 2 oss/oss_hdaudio0/mix0 248 3 oss/oss_hdaudio0/pcm0 248 4 oss/oss_hdaudio0/pcm1 248 6 oss/oss_hdaudio0/pcm2 248 8 oss/oss_hdaudio0/spdout0 248 10 oss/oss_hdaudio0/pcmin0 248 12 oss/oss_hdaudio0/pcmin1 248 14 oss/oss_hdaudio0/pcmin2 248 16 oss/oss_hdaudio0/pcmin3 248 18 $ ls /dev/pcm* /dev/snd* ls: cannot access /dev/pcm*: No such file or directory ls: cannot access /dev/snd*: No such file or directory This is because you loaded oss modules by hand and have not oss4-base installed. The base of the problem is that oss4-kernel-modules doesn't depend upon oss4-base. Moreover, it should even restart /etc/init.d/oss4-base from its postinst. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584341: FTBFS: configure: error: Valgrind requires glibc version 2.2 - 2.10
Package: valgrind Version: 1:3.5.0-3 Severity: normal see http://lists.ibiblio.org/pipermail/sm-commit/2010-March/028429.html I've tried the patch (crudely) on the debian package, and it lets valgrind build. Though, the .supp file for glibc2.11 should probably be updated as well, as lots of errors for strcmp_sse3 and GI_strlen occur (those being false positives due to the optimistic implementations of those functions but correct memory-wise). I'm not yet aware of an available glibc.supp file for 2.11, but it may have been commited to valgrind upstream since last time I checekd. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages valgrind depends on: ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libc6-dbg 2.11.1-3 Embedded GNU C Library: detached d Versions of packages valgrind recommends: ii gdb 7.1-1 The GNU Debugger Versions of packages valgrind suggests: pn alleyoop none (no description available) pn kcachegrind none (no description available) pn valkyrie none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582966: bogofilter FTBFS on s390
Package: bogofilter Severity: serious All is in the title, fwiw it prevents tokyocabinet to migrate into testing... -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555540: any news on tokyocabinet's FTBFS?
On Tue, May 18, 2010 at 03:47:58AM +0300, Faidon Liambotis wrote: Finally, while you mentioned that the bug is in linux-2.6, I couldn't find any This was a mixup with another bug affecting arm, which is now closed. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555540: any news on tokyocabinet's FTBFS?
On Tue, May 18, 2010 at 10:32:13AM +0200, Bastian Blank wrote: On Tue, May 18, 2010 at 03:47:58AM +0300, Faidon Liambotis wrote: It seems that on consecutive runs of the test case[1] in question, it aborts at different points each time and even succeeds in one in five runs or so. Moreover, while the combined assert() condition fails, separate assert() calls for each of the condition succeed while their combination still fail(!) Does tokyocabinet use multi-threading or some other means of concurrency? Yes it does heavily in the test-suite. For me this looks like race conditions. I agree with this. They may live in the glibc, as there were some fixes in this area lately. The fact that no other architecture has ever shown the same failures indeed points towards multithreading issues on 390 in the kernel or glibc. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555540: any news on tokyocabinet's FTBFS?
reassign 40 libc6 retitle 40 [s390] synchronization/locking issues severity 40 important thanks On Tue, May 18, 2010 at 10:32:13AM +0200, Bastian Blank wrote: On Tue, May 18, 2010 at 03:47:58AM +0300, Faidon Liambotis wrote: It seems that on consecutive runs of the test case[1] in question, it aborts at different points each time and even succeeds in one in five runs or so. Moreover, while the combined assert() condition fails, separate assert() calls for each of the condition succeed while their combination still fail(!) Does tokyocabinet use multi-threading or some other means of concurrency? For me this looks like race conditions. They may live in the glibc, as there were some fixes in this area lately. Bastian For now I've disabled pthread support on s390 and the testsuite passed on zelenka just fine. I'm reassigning this bug to the glibc as it is *very* likely to be a synchronization issue, not unlike the missing memory constraints we had 2 years ago. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555540: any news on tokyocabinet's FTBFS?
On Tue, May 11, 2010 at 10:52:09PM +0200, Serafeim Zanikolas wrote: Hi Pierre, Here's a ping for #40, which is blocking the transition of bogofilter (for quite a while now). It'd be sad to have to drop bogofilter support for tokyocabinet. This ftbfs is random and only on s390, you're welcome to track it down, I've not been able to. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576111: gcc-4.4 miscompiles __builtin_expect in -O0
Package: gcc-4.4
Version: 4.4.3-4
Severity: grave
Since gcc-4.4 version 4.4.3-4 (and yes -5 is still affected), gcc miscompiles
__builtin_expect when no optimization is set (at least).
Test case:
int foo(int t) {
if (__builtin_expect(t 0x100, 0))
return 0;
return 1;
}
Bad assembly:
gcc -O0 -S -o /dev/stdout a.c
.file a.c
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
movq%rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl%edi, -4(%rbp)
movl-4(%rbp), %eax
cltq
andl$256, %eax
movzbl %al, %eax-
testq %rax, %rax
je .L2
movl$0, %eax
jmp .L3
.L2:
movl$1, %eax
.L3:
leave
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident GCC: (Debian 4.4.3-5) 4.4.3
.section.note.GNU-stack,,@progbits
The buggy line is marked with the arrow.
gcc-4.4 version 4.4.3-3 is correct and doesn't perform the buggy movzbl.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576111: gcc-4.4 miscompiles __builtin_expect in -O0
For what it's worth, there is at least _another_ regression introduced
by the -4 or -5 revision in -O0, that I've not been able to track down
yet. I mean that when I remove all my uses of __builtin_expect in the
code that lead me to find out about this bug, I still have (at least)
another issue that pops up at the -O0 level that never shows up with any
other gcc release. And I deeply trust the mentioned code to be correct.
The code in question uses a lot of gcc __builtin_* functions if that
helps (ctz, clz, bswap among other).
On Thu, Apr 01, 2010 at 01:38:20AM +0200, Pierre Habouzit wrote:
Package: gcc-4.4
Version: 4.4.3-4
Severity: grave
Since gcc-4.4 version 4.4.3-4 (and yes -5 is still affected), gcc miscompiles
__builtin_expect when no optimization is set (at least).
Test case:
int foo(int t) {
if (__builtin_expect(t 0x100, 0))
return 0;
return 1;
}
Bad assembly:
gcc -O0 -S -o /dev/stdout a.c
.file a.c
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
movq%rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl%edi, -4(%rbp)
movl-4(%rbp), %eax
cltq
andl$256, %eax
movzbl %al, %eax-
testq %rax, %rax
je .L2
movl$0, %eax
jmp .L3
.L2:
movl$1, %eax
.L3:
leave
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident GCC: (Debian 4.4.3-5) 4.4.3
.section.note.GNU-stack,,@progbits
The buggy line is marked with the arrow.
gcc-4.4 version 4.4.3-3 is correct and doesn't perform the buggy movzbl.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558324: valgrind: 558324: works for me
On Sun, Mar 14, 2010 at 01:54:11PM +0700, Paul Wise wrote: On a Debian squeeze amd64 system with Linux 2.6.33 from experimental, the upstream testcase does not trigger the issue for me. MadCoder, can you try upgrading to a newer kernel and testing again? It doesn't for me either, though I have an extensive codebase I should check before. You can lower the severity of the bug meanwhile. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573905: /usr/bin/opreport: libbfd not found
Package: oprofile Version: 0.9.6-1 Severity: grave File: /usr/bin/opreport Justification: renders package unusable $ opreport: error while loading shared libraries: libbfd-2.20.so: cannot open shared object file: No such file or directory -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages oprofile depends on: ii binutils 2.20.1-2 The GNU assembler, linker and bina ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.3-3 GCC support library ii libpopt0 1.15-1 lib for parsing cmdline parameters ii libstdc++64.4.3-3The GNU Standard C++ Library v3 oprofile recommends no packages. Versions of packages oprofile suggests: pn oprofile-gui none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558324: Works for me
I fail to reproduce it with minimal testcases. Though it is known
upstream:
https://bugs.kde.org/show_bug.cgi?id=204484
I have very similar backtraces here.
On Sun, Feb 14, 2010 at 12:51:10PM +0100, Moritz Muehlenhoff wrote:
On Sat, Jan 30, 2010 at 04:12:18PM -0500, Jean-Baptiste Wons wrote:
[Adding Pierre to CC]
Package: valgrind
Severity: normal
I tried on version 1:3.5.0-3, and it does work for me.
This is my test program:
#define _GNU_SOURCE
#include sys/mman.h
#include stdio.h
#include stdlib.h
int main()
{
void *someMem = malloc(1);
void *aligned = (void*)((long)someMem ~4095L);
((char*)aligned)[1000] = 'H';
void *remapedPtr = mremap(aligned, 4096, 1024 * 512, MREMAP_MAYMOVE);
printf(%smoved : %lx - %lx : %c\n, (remapedPtr == aligned)? not :
, aligned, remapedPtr, ((char*)remapedPtr)[1000]);
((char*)remapedPtr)[25000] = 'K';
void *backToAligned = mremap(remapedPtr, 1024 * 512, 4096,
MREMAP_MAYMOVE | MREMAP_FIXED, aligned);
printf(%smoved back : %lx - %lx : %c\n, (backToAligned == aligned)?
: not , remapedPtr, backToAligned, ((char*)backToAligned)[1000]);
free(someMem);
return 0;
}
And this is the valgrind result:
w...@celine:~/debian-fix/valgrind-test% valgrind ./mremap
==11380== Memcheck, a memory error detector
==11380== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==11380== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
copyright info
==11380== Command: ./mremap
==11380==
moved : 517a000 - 4045000 : H
moved back : 4045000 - 517a000 : H
==11380==
==11380== HEAP SUMMARY:
==11380== in use at exit: 0 bytes in 0 blocks
==11380== total heap usage: 1 allocs, 1 frees, 10,000 bytes allocated
==11380==
==11380== All heap blocks were freed -- no leaks are possible
==11380==
==11380== For counts of detected and suppressed errors, rerun with: -v
==11380== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
w...@celine:~/debian-fix/valgrind-test%
Do you have a small example that will reproduce the problem ?
Regards,
JB
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages valgrind depends on:
ii libc6 2.10.2-5 Embedded GNU C Library: Shared
lib
ii libc6-dbg 2.10.2-5 Embedded GNU C Library:
detached d
Versions of packages valgrind recommends:
ii gdb 7.0-1 The GNU Debugger
Versions of packages valgrind suggests:
pn alleyoop none (no description available)
ii kcachegrind 4:4.3.2-1 visualisation tool for the
Valgrin
pn valkyrie none (no description available)
-- no debconf information
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100215145001.gc16...@madism.org
Bug#555540: tokyocabinet - FTBFS: tcbdbgethistleaf: Assertion `bdb kbuf ksiz = 0 id 0' failed.
On Sun, Feb 07, 2010 at 07:29:19PM +, Antonio Radici wrote: Hi Pierre, is this fixed? if it is then the bug should be closed, otherwise, I suppose, the package in testing won't be upgraded. I don't know, it's reassigned to linux-2.6. Since it's a linux bug, I've disabled the testsuite on armel for the time being. We, as mutt maintainers, would like to switch from gdbm to tokyocabinet but we need a stable and up-to-date version in testing to do so :-) Well, it remains an issue on hppa sadly :/ -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558324: valgrind support for mremap is broken
Package: valgrind
Version: 1:3.5.0-2
Severity: grave
Justification: renders package unusable
Valgrind 3.5 doesn't know that mremap may move the map address anymore
which make valgrind totally unusable as soon mremap has been used,
because the mremap related errors poison the output making it pretty
much useless.
Meanwhile the following code can be used, but it's impractical as it means you
have to rebuild everything using the mremap syscall.
#include valgrind/valgrind.h
#include valgrind/memcheck.h
static inline void *
mremap_for_valgrind(void *old_address, size_t old_size, size_t new_size,
int flags)
{
void *mres = mremap(old_address, old_size, new_size, flags);
if (mres != MAP_FAILED) {
VALGRIND_MAKE_MEM_NOACCESS(old_address, old_size);
VALGRIND_MAKE_MEM_DEFINED(mres, new_size);
}
return mres;
}
#define mremap(...) mremap_for_valgrind(__VA_ARGS__)
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages valgrind depends on:
ii libc6 2.10.1-3 GNU C Library: Shared libraries
Versions of packages valgrind recommends:
ii gdb 7.0-1 The GNU Debugger
Versions of packages valgrind suggests:
pn alleyoop none (no description available)
pn kcachegrind none (no description available)
ii libc6-dbg 2.10.1-3 GNU C Library: detached debugging
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557806: mysql-server-5.1: missing Replaces on libmysqlclient-dev
Package: mysql-server-5.1 Version: 5.1.41-2 Severity: serious Preparing to replace mysql-server-5.1 5.1.41-1 (using .../mysql-server-5.1_5.1.41-2_amd64.deb) ... Stopping MySQL database server: mysqld. Stopping MySQL database server: mysqld. Unpacking replacement mysql-server-5.1 ... dpkg: error processing /var/cache/apt/archives/mysql-server-5.1_5.1.41-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/mysql/plugin/ha_innodb_plugin.so.0.0.0', which is also in package libmysqlclient-dev 0:5.1.41-1 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545528: comgt: missing Replaces + Conflicts probably
On Tue, Sep 08, 2009 at 03:45:58PM +0200, Andreas Gredler wrote: On Mon, Sep 07, 2009 at 09:50:13PM +0200, Pierre Habouzit wrote: Package: comgt Severity: serious Justification: asd dpkg: error processing /var/cache/apt/archives/comgt_0.32-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/sigmon.1.gz', which is also in package gcom 0:0.3-1.1+b1 Well, the package already has the Conflicts and Replaces Fields filled out: Replaces: gcom (= 0.3-1.1) Conflicts: gcom (= 0.3-1.1) But the amd64 and alpha build have version 0:0.3-1.1+b1 :-( I'm going to fix this, ASAP. Thx for your report. You should use gcom = 0.32-1~ or similar to avoid the problem with possible binNMUs ;) Supposing that 0.32-1 is the first version that can be installed along comgt. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Bug#545527: cupt: fails with numerous errors
Package: cupt Version: 0.6.3 Severity: grave Justification: renders package unusable namely: $ sudo cupt install mktemp Name Cupt::Cache::Package::o_binary_architecture used only once: possible typo at /usr/bin/cupt line 66. E: bad config in file '/etc/apt/apt.conf.d/90debsums' W: skipped configuration file '/etc/apt/apt.conf.d/90debsums' W: attempt to set wrong option 'apt::get::show-upgraded' W: attempt to set wrong option 'apt::get::automaticremove' W: attempt to set wrong option 'apt::get::purge' Building the package cache... E: bad version '2.2.4-47978_Debian_lenny' E: error parsing system status file '/var/lib/dpkg/status' E: error while creating package cache FWIW the 2.2.4-47978_Debian_lenny comes from: $ grep-dctrl -FVersion 2.2.4-47978_Debian_lenny /var/lib/dpkg/status Package: virtualbox-2.2 Status: install ok installed Priority: optional Section: misc Installed-Size: 78376 Maintainer: Sun Microsystems, Inc. i...@virtualbox.org Architecture: amd64 Version: 2.2.4-47978_Debian_lenny Replaces: virtualbox Provides: virtualbox Depends: libc6 (= 2.7-1), libgcc1 (= 1:4.1.1), libqt4-network (= 4.4.3), libqtcore4 (= 4.4.3), libqtgui4 (= 4.4.3), libsdl1.2debian (= 1.2.10-1), libssl0.9.8 (= 0.9.8f-5), libstdc++6 (= 4.2.1), libx11-6, libxcursor1 ( 1.1.2), libxext6, libxml2 (= 2.6.27), libxmu6, libxslt1.1 (= 1.1.18), libxt6, python2.5 (= 2.5), zlib1g (= 1:1.1.4), psmisc, adduser Pre-Depends: debconf (= 1.1) | debconf-2.0 Recommends: libasound2, libpulse0, libsdl-ttf2.0-0, linux-headers, gcc, make, binutils, libhal1 (= 0.5), pdf-viewer, libgl1 Conflicts: virtualbox Conffiles: /etc/init.d/vboxdrv 89e824b94bb9e044a343aa22ce90f6f2 Description: Sun VirtualBox VirtualBox is a powerful PC virtualization solution allowing you to run a wide range of PC operating systems on your Linux system. This includes Windows, Linux, FreeBSD, DOS, OpenBSD and others. VirtualBox comes with a broad feature set and excellent performance, making it the premier virtualization software solution on the market. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cupt depends on: ii libcupt-perl 0.6.4 alternative front-end for dpkg -- ii perl 5.10.0-25 Larry Wall's Practical Extraction ii sensible-utils0.0.1 Utilities for sensible alternative cupt recommends no packages. Versions of packages cupt suggests: pn libterm-readline-gnu-perl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545528: comgt: missing Replaces + Conflicts probably
Package: comgt Severity: serious Justification: asd dpkg: error processing /var/cache/apt/archives/comgt_0.32-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/sigmon.1.gz', which is also in package gcom 0:0.3-1.1+b1 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545527: cupt: fails with numerous errors
On Mon, Sep 07, 2009 at 11:10:29PM +0300, Eugene V. Lyubimkin wrote: Pierre Habouzit wrote: Package: cupt Version: 0.6.3 Severity: grave Justification: renders package unusable namely: $ sudo cupt install mktemp Name Cupt::Cache::Package::o_binary_architecture used only once: possible typo at /usr/bin/cupt line 66. E: bad config in file '/etc/apt/apt.conf.d/90debsums' W: skipped configuration file '/etc/apt/apt.conf.d/90debsums' W: attempt to set wrong option 'apt::get::show-upgraded' W: attempt to set wrong option 'apt::get::automaticremove' W: attempt to set wrong option 'apt::get::purge' Building the package cache... E: bad version '2.2.4-47978_Debian_lenny' E: error parsing system status file '/var/lib/dpkg/status' E: error while creating package cache FWIW the 2.2.4-47978_Debian_lenny comes from: Hi Pierre. Firstly, 2.2.4-47978_Debian_lenny fails to comply with Debian Policy, however Cupt support underscores in version revisions since 0.6.0. Given also with very strange message about o_binary_architecture - didn't you run 'sudo cupt ...' from a directory with old Cupt sources? No I didn't have any Cupt checkout. wrt the version with underscores, I know it's a policy violation, sadly there are packages out there, and dpkg/apt the reference implementations work with it fine, so you sadly have to support them ;) FWIW it still doesn't work in 0.6.4 here: $ sudo cupt version Name Cupt::Cache::Package::o_binary_architecture used only once: possible typo at /usr/bin/cupt line 66. W: attempt to set wrong option 'apt::get::show-upgraded' W: attempt to set wrong option 'apt::get::automaticremove' W: attempt to set wrong option 'apt::get::purge' E: bad version '2.2.4-47978_Debian_lenny' E: error parsing system status file '/var/lib/dpkg/status' E: error while creating package cache $ which cupt /usr/bin/cupt $ dpkg-query -W cupt cupt 0.6.4 Once I purge virtualbox, this works again: $ sudo cupt version Name Cupt::Cache::Package::o_binary_architecture used only once: possible typo at /usr/bin/cupt line 66. W: attempt to set wrong option 'apt::get::show-upgraded' W: attempt to set wrong option 'apt::get::automaticremove' W: attempt to set wrong option 'apt::get::purge' cupt: 0.6.4 libcupt-perl: 0.6.4 -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Bug#364491: RM: gxset/testing -- ROM; No upstream, Buggy: segfaults immediately after [apply] button press
On Fri, Aug 07, 2009 at 10:30:53PM +0300, Jari Aalto wrote: Please remove gxset from testing. Package has severe memory malloc/free bug that causes it to segfault and it has no upstream. A request sent separately to unstable too. Well then it'll get removed from testing when the RoM from unstable will be done, there is no need to act for testing. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Bug#531993: tokyocabinet_1.4.23-1 (hppa/unstable): FTBFS: FAILED: ./tchtest remove -rc 50 -xm 500000 -df 5 casket
On Fri, Jun 05, 2009 at 05:44:57PM +0200, Philipp Kern wrote: Package: tokyocabinet Version: 1.4.23-1 Severity: serious I do see the following in dmesg: [17233166.004000] tcutest(2135): unaligned access to 0x0002138c at ip=0x000176bb [17233166.004000] tcutest(2135): unaligned access to 0x0002133c at ip=0x00017707 [17233166.004000] tcutest(2135): unaligned access to 0x000213bc at ip=0x000176bb [17233166.008000] tcutest(2135): unaligned access to 0x000212f4 at ip=0x00017707 [17233166.012000] tcutest(2135): unaligned access to 0x0002141c at ip=0x000176bb [17233166.016000] tcutest(2135): unaligned access to 0x00021264 at ip=0x00017707 [17233166.02] tcutest(2135): unaligned access to 0x0002144c at ip=0x000176bb [17233166.072000] tcutest(2135): unaligned access to 0x00021204 at ip=0x00017707 That's not tchtest, though. THANKS _That_ is useful, it's probably the same issue for sparc. Now that I know what really breaks, it'll be easier to track down ! -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Bug#524003: FTBFS on armel
On Tue, Apr 14, 2009 at 07:50:18AM +, Riku Voipio wrote: Package: tokyocabinet Severity: serious Version: 1.4.14-2 User: debian-...@lists.debian.org Usertag: eabi Package testsuite failed with the following error: LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Random Concatenating Test seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0 omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1 .make[2]: *** [check-fdb] Segmentation fault make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make[1]: *** [check] Error 2 make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 Yes, I saw that, OTOH it built fine on the experimental buildds, so I'm kind of lost here. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpzSoEQd7xfz.pgp Description: PGP signature
Bug#524003: FTBFS on armel
On Tue, Apr 14, 2009 at 09:20:41PM +, Riku Voipio wrote: On Tue, Apr 14, 2009 at 11:13:43PM +0200, Pierre Habouzit wrote: Package testsuite failed with the following error: LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Random Concatenating Test seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0 omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1 .make[2]: *** [check-fdb] Segmentation fault make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make[1]: *** [check] Error 2 make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 Yes, I saw that, OTOH it built fine on the experimental buildds, so I'm kind of lost here. Same error on experimental build: http://experimental.debian.net/fetch.php?pkg=tokyocabinetver=1.4.14-1arch=armelstamp=1239671928file=logas=raw Damn okay, I was pretty sure it built fine, sorry, I'll try to look into it. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpilKiW6sQ16.pgp Description: PGP signature
Bug#524003: FTBFS on armel
forwarded 524003 mi...@users.sourceforge.net
thanks
On Tue, Apr 14, 2009 at 07:50:18AM +, Riku Voipio wrote:
Package: tokyocabinet
Severity: serious
Version: 1.4.14-2
User: debian-...@lists.debian.org
Usertag: eabi
Package testsuite failed with the following error:
LD_LIBRARY_PATH=. ./tcftest rcat -pn 500 -ru casket 5000 500
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded: ignored.
Random Concatenating Test
seed=4294967295 path=casket rnum=5000 width=500 limsiz=-1 mt=0
omode=0 pnum=500 dai=0 dad=0 rl=0 ru=1
.make[2]: *** [check-fdb] Segmentation fault
make[2]: Leaving directory `/build/buildd/tokyocabinet-1.4.14'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/build/buildd/tokyocabinet-1.4.14'
make: *** [build-arch-stamp] Error 2
dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave
error exit status 2
Hi Mikio, I'm the Debian maintainer of tokyocabinet, I wanted to report
to you that tokyocabinet seems to have issues on armel (and also hppa).
You can see the full build logs here:
https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=armelver=1.4.14-2stamp=1239676884file=logas=raw
https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=hppaver=1.4.14-2stamp=1239662413file=logas=raw
I'm really unsure what is going on, so if you have any idea of how I can
debug this, I'd be glad.
For the armel one, I do have a backtrace though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4001fd80 (LWP 7696)]
0x4007258c in tcfdbputimpl (fdb=value optimized out,
id=4612214096449045504, vbuf=0xbee56661, vsiz=-1, dmode=0) at tcfdb.c:2060
2060 char *nvbuf = procptr-proc(rp, osiz, nvsiz,
procptr-op);
(gdb) bt full
#0 0x4007258c in tcfdbputimpl (fdb=value optimized out,
id=4612214096449045504, vbuf=0xbee56661, vsiz=-1, dmode=0) at tcfdb.c:2060
procptr = (FDBPDPROCOP *) 0x8e5677c
nvsiz = value optimized out
nvbuf = value optimized out
wp = value optimized out
rec = (unsigned char *) 0x40314322
nsiz = value optimized out
rp = (unsigned char *) 0x40314324 \001
osiz = 4
snum = 0
lnum = 1074397736
wp = value optimized out
__PRETTY_FUNCTION__ = tcfdbputimpl
__func__ = tcfdbputimpl
#1 0x40073674 in tcfdbputproc (fdb=0x1a008, id=100, vbuf=0x0, vsiz=0,
proc=0xa55c pdprocfunc, op=0x1) at tcfdb.c:1291
procop = {proc = 0xa55c pdprocfunc, op = 0x0}
procptr = (FDBPDPROCOP *) 0xbee5677c
stack =
|gå¾145\000\000\000\000l\217\000\000\000\000\000\000Dgå¾\230\231\000@,\222\...@hà\001@\000\000\000\000þ3ª\a\001\000\000\000\000\000\000\000
\002\...@\234©\002@hà\...@\000p\002@\000`\...@\000ð\035@\030xå¾\214\f\001\000¨gå¾Øfå¾\b \001\000\000\000\000\000\030xå¾Ðfå¾
ç\...@`ë\016@\000\000\000\000,\222\...@\001\200û\030xå¾\030xå¾\030xå¾\030xå¾\033xå¾\030xå¾,
'\0' repeats 20 times,
:\...@\000\000\000\000\000\000\000\000\000\000\a@\000\000\000\000\000\000\000\000\b \001\000\000\000\000...
rv = value optimized out
__PRETTY_FUNCTION__ = tcfdbputproc
__func__ = tcfdbputproc
#2 0xa3a8 in procrcat (path=value optimized out, rnum=5000,
width=value optimized out, limsiz=0, mt=value optimized out, omode=0,
pnum=500, dai=false, dad=false, rl=71, ru=200) at tcftest.c:668
id = value optimized out
kbuf =
209\000\001\000\000\000\...@\177@\004}å¾\000\000\000\000\000\000\000\000\...@\177@l\00...@\000\000\000\000\000\000\000\000\000@\...@Ø\004\t@
ksiz = 3
i = 105
err = false
stime = 1239752343.776659
fdb = (TCFDB *) 0x1a008
#3 0xf9c4 in main (argc=1, argv=0xbee57b14) at tcftest.c:356
rv = value optimized out
(gdb) p *procptr
Cannot access memory at address 0x8e5677c
(gdb)
Please tell me if you need more informations.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
pgpMaptNugBMb.pgp
Description: PGP signature
Bug#517975: pdnsd: package update overrides configuration
On Tue, Mar 17, 2009 at 06:40:17PM +, Alexander Gattin wrote: Hello, On Tue, Mar 17, 2009 at 06:50:46AM +0100, Christian Perrier wrote: Quoting Alexander Gattin (xr...@yandex.ru): P.S. Christian, what's your opinion on the issue? I should have one? :-) It would be nice if you do :). Maybe you faced similar discussions in the past? I see no reason to bring Christian in the loop, he's (AFAICT) not even a user of the package. I generally trust Pierre's advice and experience on many issues, so I don't feel like interfering in your discussion which I don't have the background for...would be a good idea. [snip rehashing arguments] you won't convince anyone here, if you're still not convinced, play the just bring it to the ctte and please let us be done with it, it's annoying, it's a mere loss of time to me. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpU9ScAvCxTD.pgp Description: PGP signature
Bug#517975: pdnsd: package update overrides configuration
On Sun, Mar 08, 2009 at 11:07:44PM +, Alexander Gattin wrote: On Sun, Mar 08, 2009 at 11:03:17PM +0100, Pierre Habouzit wrote: FWIW I talked with several DD who all believed you're wrong. Any package that ships themes e.g. does that. probably, this whole argument does not deserve an attention of Technical Committee... mwahahaha you're somehow pathetic. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpBwHm1MRUMC.pgp Description: PGP signature
Bug#517975: pdnsd: package update overrides configuration
On Sun, Mar 08, 2009 at 01:15:31PM +, Alexander Gattin wrote: I do not understand why did you introduce the AUTO_MODE at all? Probably, you wanted to help users configuring pdnsd by making it accomplishable through dpkg-reconfigure pdnsd? If so, then amount of behavoiur which is exposed to dpkg-reconfigure pdnsd is obviously insufficient (server_ip? proxy_only?). Oh boy, you absolutely don't get it. I give the two most used configurations for free, namely: * local cache, slave to your ISP or dhcp servers, through the resolvconf facilities ; * local recursive cache server. If you're not in those cases that probably match 95% of the pdnsd uses cases, then you chose Manual during the install and you're done. Again the debconf templates _TELLS YOU_ to chose Manual when you have to change server_ip. On the other end, having the four configuration files: * /etc/default/pdnsd * /etc/pdnsd.conf * /usr/share/pdnsd/pdnsd-recurse.conf * /usr/share/pdnsd/pdnsd-resolvconf.conf instead of just one is very confusing. No there are two configuration files: * /etc/default/pdnsd * /etc/pdnsd.conf If you use another dns server e.g., installing pdnsd miserably fails since it will want to bind on port 53 as well. So /etc/default/pdnsd is required to deal with that, and have pdnsd disabled by default. /etc/pdnsd.conf is the default configuration file. When you're lucky enough so that the two possible builtin configuration I did suit your needs, debconf allow you to simplify that work and do all by itself, touching only /etc/default/pdnsd. It's dead simple, not confusing at all. Many pdnsd users don't know about DNS at all, they just know their ISP DNS suck, and they want an easy install. That's what I provide. If you're using kvm or needing server_ip/proxy_only settings, then you should know about DNS, and are an advanced user, you should do it all by yourself and chose Manual. Full stop. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgp3ayd7xxhHj.pgp Description: PGP signature
Bug#517975: pdnsd: package update overrides configuration
On Sun, Mar 08, 2009 at 07:32:08PM +, Alexander Gattin wrote: As I've said earlier, it's OK with me to choose resolvconf mode. Yet I'd be grateful to pdnsd to allow me (1) to choose a mode, (2) make small modifications to its behaviour and (3) to keep them across upgrades. It's what it does, cp /usr/share/pdnsd/pdnsd-resolvconf.conf /etc/pdnsd.conf, chose manual, and done. And if you are really afraid that this file changes often (and I can tell you it doesn't), you can also do: cp /usr/share/pdnsd/pdnsd-resolvconf.conf /etc/pdnsd-resolvconf.conf so that when you get a new package you can update your /etc/pdnsd.conf using diff3. have fun. I think, if you opted to _generate_ /etc/pdnsd.conf from one of the resolvconf/resurse templates (depending on debconf parameter), this would fit the (1)-(2)-(3) scenario. Current solution is dead inflexible though... It's not, many packages do the same, In the next upload I'll make it very clear in the /usr files that those are not meant to be edited by the user, and will be overwritten by an upgrade, since some people do not get it. FWIW I talked with several DD who all believed you're wrong. Any package that ships themes e.g. does that. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpF44mjk9YZG.pgp Description: PGP signature
Bug#517975: pdnsd: package update overrides configuration
On Fri, Mar 06, 2009 at 09:21:15AM +, Alexander Gattin wrote: Hello, Pierre, you have totally screwed up the Policy's definitions and intentions: regardless of whether it's a conffile or Config File, local changes must be preserved during a package upgrade. I'm speechless... No I'm not supposed to preserve local change to internal files of a package. The place to modify if you want your change kept are changes to the stuff under /etc. If you modify any other file of the package, well, then you're on your own. If you want them to be preserved, use dpkg-divert. _That_ is what the policy says. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpZ7KfXsxaBw.pgp Description: PGP signature
Bug#517371: /usr/bin/nm-connection-editor: nm-connection-editor crashes when I try to edit any kind of connection
Package: network-manager-gnome Version: 0.7.0.97-1 Severity: grave File: /usr/bin/nm-connection-editor Justification: renders package unusable When I try to edit a connection, the dialog disappears. When running it from the console, I see: $ nm-connection-editor (nm-connection-editor:3879): GLib-CRITICAL **: g_hash_table_foreach: assertion `hash_table != NULL' failed ** Message: nm_connection_list_new: failed to load VPN plugins: Couldn't read VPN .name files directory /etc/NetworkManager/VPN. [WARN 3879] polkit-error.c:143:polkit_error_get_error_message(): error != NULL Not built with -rdynamic so unable to print a backtrace ** (nm-connection-editor:3879): WARNING **: Failed to initialize PolicyKit context: (null) [WARN 3879] polkit-error.c:156:polkit_error_free(): error != NULL Not built with -rdynamic so unable to print a backtrace [1]3879 segmentation fault nm-connection-editor -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages network-manager-gnome depends on: ii libc6 2.9-3 GNU C Library: Shared libraries ii libdbus-1-3 1.2.12-1 simple interprocess messaging syst ii libdbus-glib-1-2 0.80-3 simple interprocess messaging syst ii libgconf2-4 2.24.0-7 GNOME configuration database syste ii libglade2-0 1:2.6.3-1 library to load .glade files at ru ii libglib2.0-0 2.18.4-2 The GLib library of C routines ii libgnome-keyring0 2.22.3-2 GNOME keyring services library ii libgtk2.0-0 2.12.12-1 The GTK+ graphical user interface ii libnm-glib-vpn0 0.7.0.97-1 network management framework (GLib ii libnm-glib0 0.7.0.97-1 network management framework (GLib ii libnm-util1 0.7.0.97-1 network management framework (shar ii libnotify1 [libnotify1-gtk2.1 0.4.4-3sends desktop notifications to a n ii libpango1.0-0 1.22.4-2 Layout and rendering of internatio ii libpolkit-gnome0 0.9-2 PolicyKit-gnome library ii libpolkit20.9-3 library for accessing PolicyKit ii network-manager 0.7.0.97-1 network management framework daemo Versions of packages network-manager-gnome recommends: pn libpam-keyringnone (no description available) ii notification-daemon 0.3.7-1+b1 a daemon that displays passive pop pn policykit-gnome none (no description available) Versions of packages network-manager-gnome suggests: pn network-manager-openvpn-gnome none (no description available) pn network-manager-pptp-gnomenone (no description available) pn network-manager-vpnc-gnomenone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517182: tcl8.5: no I _really_ don't want my alternatives to get messed up.
Package: tcl8.5, tk8.5 Version: 8.5.6-2 Severity: serious During today's upgrade: Preparing to replace tcl8.5 8.5.3-2 (using .../tcl8.5_8.5.6-2_amd64.deb) ... Removing manually selected alternative - switching to auto mode Unpacking replacement tcl8.5 ... Preparing to replace tk8.5 8.5.3-4 (using .../tk8.5_8.5.6-2_amd64.deb) ... Removing manually selected alternative - switching to auto mode And of course wish/tclsh pointing to the 8.5 versions are gone and my gitk is ugly again. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511687: Policy violation git-daemon-run must provide a init.d script and not a symlink to /usr/bin
# and to be frank I believe this bug is just plain invalid
severity 511687 normal
thanks
On Tue, Jan 13, 2009 at 02:06:36PM +, Bastien ROUCARIES wrote:
Package: git-daemon-run
Version: 1:1.5.6.5-2
Severity: serious
Seveirty serious because it is a policy violation: according to section 9.3
of debian policy.
Please add a script, and document correctly dependancy using
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
Regards
No it doesn't _need_ to, the very standard way to use git-daemon is
usually through a super-server. git-daemon-run is just a way to enable
git-daemon into runit, which is the packager choice and has nothing to
do with the policy as-is.
git-daemon is part of git-core and it would make really no sense to
enable git-daemon as an init script part of this package.
As an example, I serve git-daemon through xinetd on my server, and I
just had to write this:
$ cat /etc/xinetd.d/git-daemon
# description: The git server offers access to git repositories
service git
{
disable = no
type= UNLISTED
port= 9418
socket_type = stream
wait= no
user= nobody
server = /usr/bin/git-daemon
flags = IPv6
server_args = --inetd --export-all --base-path=/git/public
--user-path=public_git
log_on_failure += USERID
}
Arguably the packager could document this or a way to enable git-daemon through
the usual inetd servers, but that's it IMNSHO.
Cheers,
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
pgpeYwjF1baW9.pgp
Description: PGP signature
Bug#511687: Policy violation git-daemon-run must provide a init.d script and not a symlink to /usr/bin
On Thu, Jan 15, 2009 at 02:26:18PM +, roucaries bastien wrote: On Thu, Jan 15, 2009 at 2:44 PM, Pierre Habouzit madco...@debian.org wrote: # and to be frank I believe this bug is just plain invalid severity 511687 normal thanks No the bug is not really invalid it shoke insserver because git-daemon-run is a binary file, it does not crash but report loundly that it can not read the file git-daemon-run. Ok it is not a bug per se, but admin could personnalize init.d script. So ? The fact that it is a symlink doesn't prevent you from changing it to a script. No it doesn't _need_ to, the very standard way to use git-daemon is usually through a super-server. git-daemon-run is just a way to enable git-daemon into runit, which is the packager choice and has nothing to do with the policy as-is. Yes but put a symlink to a binary file in /etc/init.d is not really nice. According to section 9.3, /etc/init.d MUST be script. symlink is bad usage at least. I'm not sure it must, but what it should and does not, is declaring /etc/init.d/git-daemon as: (1) a conffile (2) not remove it on removal (3) not overwrite it on install I believe that this package provide the standalone daemon because it wrote to /etc/init.d :( You believe or believe*d* ? because afaict git-daemon is part of git-core. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpGuSaefHuHV.pgp Description: PGP signature
Bug#505171: tokyocabinet_1.3.15-1(sparc/experimental): FTBFS: error: /home/buildd/include: Permission denied
On Mon, Nov 10, 2008 at 07:09:21AM +, Frank Lichtenheld wrote:
Package: tokyocabinet
Version: 1.3.15-1
Severity: serious
Hi,
your package failed to build from source. config.log says:
configure:2319: checking for C compiler default output file name
configure:2346: sparc-linux-gnu-gcc -g -Wall -Wextra -O2 -Wl,-z,defs
conftes
t.c 5
cc1: error: /home/buildd/include: Permission denied
configure:2349: $? = 1
configure:2387: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME tokyocabinet
| #define PACKAGE_TARNAME tokyocabinet
| #define PACKAGE_VERSION 1.3.15
| #define PACKAGE_STRING tokyocabinet 1.3.15
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2394: error: C compiler cannot create executables
huh, it builds fine here, and it seems it broke on _every_ buildd out
there, have you any clue what is happening ?
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpIK8Tt7ddG1.pgp
Description: PGP signature
Bug#505171: tokyocabinet_1.3.15-1(sparc/experimental): FTBFS: error: /home/buildd/include: Permission denied
On Mon, Nov 10, 2008 at 10:41:52PM +, Frank Lichtenheld wrote:
On Mon, Nov 10, 2008 at 04:41:43PM +0100, Luk Claes wrote:
Pierre Habouzit wrote:
On Mon, Nov 10, 2008 at 07:09:21AM +, Frank Lichtenheld wrote:
your package failed to build from source. config.log says:
configure:2293: s390-linux-gnu-gcc -V 5
s390-linux-gnu-gcc: '-V' option must have argument
configure:2296: $? = 1
configure:2319: checking for C compiler default output file name
Nah, that's another check entirely.
configure:2319: checking for C compiler default output file name
configure:2346: sparc-linux-gnu-gcc -g -Wall -Wextra -O2 -Wl,-z,defs
conftes
t.c 5
cc1: error: /home/buildd/include: Permission denied
configure:2349: $? = 1
configure:2387: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME tokyocabinet
| #define PACKAGE_TARNAME tokyocabinet
| #define PACKAGE_VERSION 1.3.15
| #define PACKAGE_STRING tokyocabinet 1.3.15
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2394: error: C compiler cannot create executables
huh, it builds fine here, and it seems it broke on _every_ buildd out
there, have you any clue what is happening ?
Ok, it breaks because of this insanity from configure.in:
--- snip ---
# Building flags
MYCFLAGS=-std=c99 -Wall -fPIC -fsigned-char -O2
MYCPPFLAGS=-I. -I\$(INCLUDEDIR) -I$HOME/include -I/usr/local/include
-DNDEBUG -D_GNU_SOURCE=1
MYLDFLAGS=-L. -L\$(LIBDIR) -L$HOME/lib -L/usr/local/lib
MYCMDLDFLAGS=
MYRUNPATH=\$(LIBDIR)
MYLDLIBPATHENV=LD_LIBRARY_PATH
MYPOSTCMD=true
# Building paths
pathtmp=$PATH
PATH=$HOME/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
PATH=$PATH:/usr/ccs/bin:/usr/ucb:/usr/xpg4/bin:/usr/xpg6/bin:$pathtmp
LIBRARY_PATH=$HOME/lib:/usr/local/lib:$LIBRARY_PATH
LD_LIBRARY_PATH=$HOME/lib:/usr/local/lib:$LD_LIBRARY_PATH
CPATH=$HOME/include:/usr/local/include:$CPATH
PKG_CONFIG_PATH=$HOME/lib/pkgconfig:/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
export PATH LIBRARY_PATH LD_LIBRARY_PATH CPATH PKG_CONFIG_PATH
--- snip ---
The reason it only fails on buildds is because they often have a
/home/buildd that is not readable/writable by user buildd (exactly
to catch such stuff).
OOOh nice catch, I'll fix that, thanks.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpfA5b9eh0Jy.pgp
Description: PGP signature
Bug#468793: Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
reassign 468793 glibc forcemerge 479952 468793 thanks On Mon, Nov 03, 2008 at 09:59:28AM +, Martin Schwidefsky wrote: On Thu, 2008-10-30 at 14:12 +0100, Pierre Habouzit wrote: On Thu, Oct 30, 2008 at 12:44:35PM +, Martin Schwidefsky wrote: On Mon, 2008-10-27 at 19:59 +0100, Julien Danjou wrote: At 1225129482 time_t, Moritz Muehlenhoff wrote: Maybe we could forward this bug to Martin Schwidefsky [EMAIL PROTECTED], who is the glibc s390 maintainer and who works for IBM on the s390 Linux port. Why not. Martin, do you have any clue about bug #479952? http://bugs.debian.org/479952 This does look familiar, I've seen this some years ago with broken locking primivites in the nptl lowlevellock implementation. Could you check your copy of glibc to verify if the locking inline assemblies in nptl/sysdeps/unix/sysv/linux/s390/lowlevellock.h all have the memory clobber? This has been the bug last time. Just for information I'm currently on travel and will read my mail only randomly. They all have the memory constraint. In the meantime Michael Matz from Novell found the problem: the __lll_lock Funktion uses atomic_compare_and_exchange_bool_acq which uses the __arch_compare_and_exchange_val_32_acq function which does NOT have a memory clobber. The patch below should fix the problem Wonderful, thanks a lot to him ! -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpA8E7qxhAQ6.pgp Description: PGP signature
Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Thu, Oct 30, 2008 at 12:44:35PM +, Martin Schwidefsky wrote: On Mon, 2008-10-27 at 19:59 +0100, Julien Danjou wrote: At 1225129482 time_t, Moritz Muehlenhoff wrote: Maybe we could forward this bug to Martin Schwidefsky [EMAIL PROTECTED], who is the glibc s390 maintainer and who works for IBM on the s390 Linux port. Why not. Martin, do you have any clue about bug #479952? http://bugs.debian.org/479952 This does look familiar, I've seen this some years ago with broken locking primivites in the nptl lowlevellock implementation. Could you check your copy of glibc to verify if the locking inline assemblies in nptl/sysdeps/unix/sysv/linux/s390/lowlevellock.h all have the memory clobber? This has been the bug last time. Just for information I'm currently on travel and will read my mail only randomly. They all have the memory constraint. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpFcsIlV9u29.pgp Description: PGP signature
Bug#502760: Processed: Re: Re: Is this really in ldapscripts?
On Thu, Oct 30, 2008 at 05:06:16PM +, Richard A Nelson wrote: On Thu, 30 Oct 2008, Debian Bug Tracking System wrote: reassign 502760 libnss-ldap Bug#502760: ldapscripts: piuparts test fails: invoke-rc.d: unknown initscript, /etc/init.d/nscd not found. Bug reassigned from package `ldapscripts' to `libnss-ldap'. retitle 502760 libnss-ldap calls nscd init script w/o checking its existance Bug#502760: ldapscripts: piuparts test fails: invoke-rc.d: unknown initscript, /etc/init.d/nscd not found. Changed Bug title to `libnss-ldap calls nscd init script w/o checking its existance' from `ldapscripts: piuparts test fails: invoke-rc.d: unknown initscript, /etc/init.d/nscd not found.'. Interesting... the postinst does not check for /etc/init.d/nscd, but *does* check for /usr/sbin/nscd How did the system wind up in a state where the binary exists, but the initscript doesn't ? the user deleted it ? which he is totally allowed to do as it is a conffile. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpC30dI3yHAE.pgp Description: PGP signature
Bug#502959: general: raff.debian.org uses non-free software
On Tue, Oct 21, 2008 at 11:38:31AM +, Aurelien Jarno wrote: Romain Beauxis a écrit : Le Tuesday 21 October 2008 13:10:28 Peter Clifton, vous avez écrit : Having no source-code for firmware is hardly that different to having a completely open-source driver which does un-told magic by poking un-documented registers in a complex chip. Think Intel graphics before they released documentation for (some of) their chips. Agreed, though it does not restrain us from asking for free firmware. If I recall well, one of the origin of the GNU fondation was the fact that having free drivers alowed one to actually *fix* issues he may have with his *own* hardware. Then, the very same reasoning can apply to binary firmware. So, yes this is a brand new issue, that comes from the new way of designing hardware. But that doesn't mean we should give up and remain behind the line that was drawn 20 (or so) years ago. We now should also ask for open source firmware for the very same reason that this huge effort toward free drivers was done. If we did it for drivers, there's no reason we can't suceed for firmwares. And we should delay the release by 5 years until we have them... I fear the hardware will be old at that time… -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpy7cd2FqSWv.pgp Description: PGP signature
Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Sun, Oct 19, 2008 at 07:18:49AM +, Hideki Yamane wrote: On Sat, 18 Oct 2008 17:55:29 +0200 Pierre Habouzit [EMAIL PROTECTED] wrote: It is likely to _not_ be a tokyocabinet bug but a libc one. According to http://buildd.debian.org/pkg.cgi?pkg=tokyocabinet tokyocabinet has been built on s390 now: s3901.2.1-1 Installed 2008 Oct 16 11:54:52 Has this been fixed by changes inside glibc? Can this bug be closed? Not that I'm aware of (with my glibc-packager hat on). That sounds good thing! :) # and apologize to you for making some noise. And is there any porter machine for non-DD (upstream)? Not that I'm aware of, and it's probably a bug in s390 assembly, and actually not a tokyocabinet bug _at all_. So unless upstream knows s390 assembly... I don't think he can help a lot :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSD5XzWewoE.pgp Description: PGP signature
Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Sat, Oct 18, 2008 at 03:09:00PM +, Moritz Muehlenhoff wrote: On Fri, Oct 10, 2008 at 09:52:19AM +0200, Pierre Habouzit wrote: On Thu, Oct 09, 2008 at 06:40:00PM +, Hideki Yamane wrote: Hi, Just a question. Does this bug stay with upstream version? It is likely to _not_ be a tokyocabinet bug but a libc one. According to http://buildd.debian.org/pkg.cgi?pkg=tokyocabinet tokyocabinet has been built on s390 now: s3901.2.1-1 Installed 2008 Oct 16 11:54:52 Has this been fixed by changes inside glibc? Can this bug be closed? Not that I'm aware of (with my glibc-packager hat on). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpZbMPkwaZmM.pgp Description: PGP signature
Bug#502440: [pkg-lighttpd] Bug#502440: lighttpd: Debian-specific config file changes cause strange behaviour
severity 502440 minor thanks On Thu, Oct 16, 2008 at 02:02:15PM +, Tobias Nissen wrote: Package: lighttpd Version: 1.4.19-5 Severity: grave Justification: renders package unusable The implementation of the Debian policy (regarding /doc and /images) in the default config file makes it impossible to declare even simple aliases such as alias.url += ( /test = /home/user/foo/ ) Visiting http://localhost/test/ (with or without index.html) just gives an HTTP 404 error. After completely removing the Debian specific part in question, the alias works as expected. It does, there is a bug about this, and how come something that can be overcomed in 3 lines can be a grave problem ? please, get a grip. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLcmmhDawVm.pgp Description: PGP signature
Bug#501021: jasper: diff for NMU version 1.900.1-5.1
tags 501021 + patch
thanks
Dear maintainer,
I've prepared an NMU for jasper (versioned as 1.900.1-5.1) and uploaded it
to DELAYED/02.
Regards.
diff -u jasper-1.900.1/debian/changelog jasper-1.900.1/debian/changelog
--- jasper-1.900.1/debian/changelog
+++ jasper-1.900.1/debian/changelog
@@ -1,3 +1,13 @@
+jasper (1.900.1-5.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * add patches/02_security.dpatch to fix various CVEs (Closes: #501021):
+ + CVE-2008-3522[0]: Buffer overflow.
+ + CVE-2008-3521[1]: unsecure temporary files handling.
+ + CVE-2008-3520[2]: Multiple integer overflows.
+
+ -- Pierre Habouzit [EMAIL PROTECTED] Sun, 12 Oct 2008 21:40:59 +0200
+
jasper (1.900.1-5) unstable; urgency=low
* Added GeoJP2 patch by Sven Geggus [EMAIL PROTECTED]
diff -u jasper-1.900.1/debian/patches/00list
jasper-1.900.1/debian/patches/00list
--- jasper-1.900.1/debian/patches/00list
+++ jasper-1.900.1/debian/patches/00list
@@ -1,0 +2 @@
+02_security.dpatch
only in patch2:
unchanged:
--- jasper-1.900.1.orig/debian/patches/02_security.dpatch
+++ jasper-1.900.1/debian/patches/02_security.dpatch
@@ -0,0 +1,983 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+##
+## All lines beginning with `## DP:' are a description of the patch.
+
[EMAIL PROTECTED]@
+
+diff -Nurad jasper-1.900.1.orig/src/libjasper/base/jas_cm.c
jasper-1.900.1.new/src/libjasper/base/jas_cm.c
+--- jasper-1.900.1.orig/src/libjasper/base/jas_cm.c2007-01-19
22:43:05.0 +0100
jasper-1.900.1.new/src/libjasper/base/jas_cm.c 2008-10-03
14:17:55.0 +0200
+@@ -704,8 +704,7 @@
+ {
+ jas_cmpxform_t **p;
+ assert(n = pxformseq-numpxforms);
+- p = (!pxformseq-pxforms) ? jas_malloc(n * sizeof(jas_cmpxform_t *)) :
+-jas_realloc(pxformseq-pxforms, n * sizeof(jas_cmpxform_t *));
++ p = jas_realloc2(pxformseq-pxforms, n, sizeof(jas_cmpxform_t *));
+ if (!p) {
+ return -1;
+ }
+@@ -889,13 +888,13 @@
+ jas_cmshapmatlut_cleanup(lut);
+ if (curv-numents == 0) {
+ lut-size = 2;
+- if (!(lut-data = jas_malloc(lut-size * sizeof(jas_cmreal_t
++ if (!(lut-data = jas_alloc2(lut-size, sizeof(jas_cmreal_t
+ goto error;
+ lut-data[0] = 0.0;
+ lut-data[1] = 1.0;
+ } else if (curv-numents == 1) {
+ lut-size = 256;
+- if (!(lut-data = jas_malloc(lut-size * sizeof(jas_cmreal_t
++ if (!(lut-data = jas_alloc2(lut-size, sizeof(jas_cmreal_t
+ goto error;
+ gamma = curv-ents[0] / 256.0;
+ for (i = 0; i lut-size; ++i) {
+@@ -903,7 +902,7 @@
+ }
+ } else {
+ lut-size = curv-numents;
+- if (!(lut-data = jas_malloc(lut-size * sizeof(jas_cmreal_t
++ if (!(lut-data = jas_alloc2(lut-size, sizeof(jas_cmreal_t
+ goto error;
+ for (i = 0; i lut-size; ++i) {
+ lut-data[i] = curv-ents[i] / 65535.0;
+@@ -953,7 +952,7 @@
+ return -1;
+ }
+ }
+- if (!(invlut-data = jas_malloc(n * sizeof(jas_cmreal_t
++ if (!(invlut-data = jas_alloc2(n, sizeof(jas_cmreal_t
+ return -1;
+ invlut-size = n;
+ for (i = 0; i invlut-size; ++i) {
+diff -Nurad jasper-1.900.1.orig/src/libjasper/base/jas_icc.c
jasper-1.900.1.new/src/libjasper/base/jas_icc.c
+--- jasper-1.900.1.orig/src/libjasper/base/jas_icc.c 2007-01-19
22:43:05.0 +0100
jasper-1.900.1.new/src/libjasper/base/jas_icc.c2008-10-03
14:17:55.0 +0200
+@@ -373,7 +373,7 @@
+ jas_icctagtab_t *tagtab;
+
+ tagtab = prof-tagtab;
+- if (!(tagtab-ents = jas_malloc(prof-attrtab-numattrs *
++ if (!(tagtab-ents = jas_alloc2(prof-attrtab-numattrs,
+ sizeof(jas_icctagtabent_t
+ goto error;
+ tagtab-numents = prof-attrtab-numattrs;
+@@ -522,7 +522,7 @@
+ }
+ if (jas_iccgetuint32(in, tagtab-numents))
+ goto error;
+- if (!(tagtab-ents = jas_malloc(tagtab-numents *
++ if (!(tagtab-ents = jas_alloc2(tagtab-numents,
+ sizeof(jas_icctagtabent_t
+ goto error;
+ tagtabent = tagtab-ents;
+@@ -743,8 +743,7 @@
+ {
+ jas_iccattr_t *newattrs;
+ assert(maxents = tab-numattrs);
+- newattrs = tab-attrs ? jas_realloc(tab-attrs, maxents *
+-sizeof(jas_iccattr_t)) : jas_malloc(maxents * sizeof(jas_iccattr_t));
++ newattrs = jas_realloc2(tab-attrs, maxents, sizeof(jas_iccattr_t));
+ if (!newattrs)
+ return -1;
+ tab-attrs = newattrs;
+@@ -999,7 +998,7 @@
+
+ if (jas_iccgetuint32(in, curv-numents))
+ goto error;
+- if (!(curv-ents = jas_malloc(curv-numents * sizeof(jas_iccuint16_t
++ if (!(curv-ents = jas_alloc2(curv-numents, sizeof
Bug#501021: jasper: diff for NMU version 1.900.1-5.1
tags 501021 + patch
thanks
Dear maintainer,
I've prepared an NMU for jasper (versioned as 1.900.1-5.1) and uploaded it
to DELAYED/02.
PS: for some reason the previous nmudiff was broken, here is the proper one.
Regards.
reverted:
--- jasper-1.900.1/src/libjasper/jpc/jpc_cs.c
+++ jasper-1.900.1.orig/src/libjasper/jpc/jpc_cs.c
@@ -982,10 +982,7 @@
compparms-numstepsizes = (len - n) / 2;
break;
}
+ if (compparms-numstepsizes 0) {
- if (compparms-numstepsizes 3 * JPC_MAXRLVLS + 1) {
- jpc_qcx_destroycompparms(compparms);
-return -1;
-} else if (compparms-numstepsizes 0) {
compparms-stepsizes = jas_malloc(compparms-numstepsizes *
sizeof(uint_fast16_t));
assert(compparms-stepsizes);
reverted:
--- jasper-1.900.1/src/libjasper/jpc/jpc_dec.c
+++ jasper-1.900.1.orig/src/libjasper/jpc/jpc_dec.c
@@ -1069,12 +1069,12 @@
/* Apply an inverse intercomponent transform if necessary. */
switch (tile-cp-mctid) {
case JPC_MCT_RCT:
+ assert(dec-numcomps == 3);
- assert(dec-numcomps == 3 || dec-numcomps == 4);
jpc_irct(tile-tcomps[0].data, tile-tcomps[1].data,
tile-tcomps[2].data);
break;
case JPC_MCT_ICT:
+ assert(dec-numcomps == 3);
- assert(dec-numcomps == 3 || dec-numcomps == 4);
jpc_iict(tile-tcomps[0].data, tile-tcomps[1].data,
tile-tcomps[2].data);
break;
diff -u jasper-1.900.1/debian/changelog jasper-1.900.1/debian/changelog
--- jasper-1.900.1/debian/changelog
+++ jasper-1.900.1/debian/changelog
@@ -1,3 +1,13 @@
+jasper (1.900.1-5.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * add patches/02_security.dpatch to fix various CVEs (Closes: #501021):
+ + CVE-2008-3522[0]: Buffer overflow.
+ + CVE-2008-3521[1]: unsecure temporary files handling.
+ + CVE-2008-3520[2]: Multiple integer overflows.
+
+ -- Pierre Habouzit [EMAIL PROTECTED] Sun, 12 Oct 2008 21:40:59 +0200
+
jasper (1.900.1-5) unstable; urgency=low
* Added GeoJP2 patch by Sven Geggus [EMAIL PROTECTED]
diff -u jasper-1.900.1/debian/patches/00list
jasper-1.900.1/debian/patches/00list
--- jasper-1.900.1/debian/patches/00list
+++ jasper-1.900.1/debian/patches/00list
@@ -1,0 +2 @@
+02_security.dpatch
only in patch2:
unchanged:
--- jasper-1.900.1.orig/debian/patches/02_security.dpatch
+++ jasper-1.900.1/debian/patches/02_security.dpatch
@@ -0,0 +1,978 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+##
+## All lines beginning with `## DP:' are a description of the patch.
+
[EMAIL PROTECTED]@
+
+diff --git a/src/libjasper/base/jas_cm.c b/src/libjasper/base/jas_cm.c
+index 77514dd..e63a6d2 100644
+--- a/src/libjasper/base/jas_cm.c
b/src/libjasper/base/jas_cm.c
+@@ -704,8 +704,7 @@ static int jas_cmpxformseq_resize(jas_cmpxformseq_t
*pxformseq, int n)
+ {
+ jas_cmpxform_t **p;
+ assert(n = pxformseq-numpxforms);
+- p = (!pxformseq-pxforms) ? jas_malloc(n * sizeof(jas_cmpxform_t *)) :
+-jas_realloc(pxformseq-pxforms, n * sizeof(jas_cmpxform_t *));
++ p = jas_realloc2(pxformseq-pxforms, n, sizeof(jas_cmpxform_t *));
+ if (!p) {
+ return -1;
+ }
+@@ -889,13 +888,13 @@ static int jas_cmshapmatlut_set(jas_cmshapmatlut_t *lut,
jas_icccurv_t *curv)
+ jas_cmshapmatlut_cleanup(lut);
+ if (curv-numents == 0) {
+ lut-size = 2;
+- if (!(lut-data = jas_malloc(lut-size * sizeof(jas_cmreal_t
++ if (!(lut-data = jas_alloc2(lut-size, sizeof(jas_cmreal_t
+ goto error;
+ lut-data[0] = 0.0;
+ lut-data[1] = 1.0;
+ } else if (curv-numents == 1) {
+ lut-size = 256;
+- if (!(lut-data = jas_malloc(lut-size * sizeof(jas_cmreal_t
++ if (!(lut-data = jas_alloc2(lut-size, sizeof(jas_cmreal_t
+ goto error;
+ gamma = curv-ents[0] / 256.0;
+ for (i = 0; i lut-size; ++i) {
+@@ -903,7 +902,7 @@ static int jas_cmshapmatlut_set(jas_cmshapmatlut_t *lut,
jas_icccurv_t *curv)
+ }
+ } else {
+ lut-size = curv-numents;
+- if (!(lut-data = jas_malloc(lut-size * sizeof(jas_cmreal_t
++ if (!(lut-data = jas_alloc2(lut-size, sizeof(jas_cmreal_t
+ goto error;
+ for (i = 0; i lut-size; ++i) {
+ lut-data[i] = curv-ents[i] / 65535.0;
+@@ -953,7 +952,7 @@ static int jas_cmshapmatlut_invert(jas_cmshapmatlut_t
*invlut,
+ return -1;
+ }
+ }
+- if (!(invlut-data = jas_malloc(n * sizeof(jas_cmreal_t
++ if (!(invlut-data = jas_alloc2(n, sizeof(jas_cmreal_t
+ return -1;
+ invlut-size = n
Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Thu, Oct 09, 2008 at 06:40:00PM +, Hideki Yamane wrote: Hi, Just a question. Does this bug stay with upstream version? It is likely to _not_ be a tokyocabinet bug but a libc one. As I requested #489784, Tokyo Cabinet is updated, and now released 1.3.11 at 2008-09-23 (more than 10days ago). Yes but I can't push a full new upstream to Debian. That's why I did nothing. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpV0gjZDjzHp.pgp Description: PGP signature
Bug#501539: iceweasel: firefox $url is broken
Package: iceweasel Version: 3.0.3-1 Severity: serious When using firefox $some_url from the command line, firefox prior to this version reused an instance, unless you pass -no-remote to it. Since 3.0.3 it's unable to contact other instances, I get a popup saying: Iceweasel is already running, but is not responding. To open a new window, you must first close the existing Iceweasel process, or restart your system. This is utterly annoying and render Iceweasel pretty useless to me (clicking on links from applications does that e.g.). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500910: CVE-2008-4194 denial of service
On Thu, Oct 02, 2008 at 04:25:54PM +, Christian Perrier wrote: Quoting Nico Golde ([EMAIL PROTECTED]): Package: pdnsd Severity: grave Tags: security Hi, the following CVE (Common Vulnerabilities Exposures) id was published for pdnsd. If someone fixes this, fixing #490047 would be much appreciated as well by the l10n folks (and this is certainly not invasive). This becomes an habit :P But Yes I'll fix those at the same time. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp73hAhVA9zv.pgp Description: PGP signature
Bug#499761: remove fcmp from lenny?
On Tue, Sep 30, 2008 at 03:37:54PM +, Thomas Viehmann wrote: Hi, as Frank Lichtenheld noted in #499761, fcmp exists for the exclusive benefit of freecraft, which is not scheduled to be released with lenny. As such fcmp should probably be pulled as well. I hope there is an RC bug to maintain it out from testing (I've not checked). removed. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4VVCMvlV8K.pgp Description: PGP signature
Bug#500555: tries to access not existing/usr/var/run
On Tue, Sep 30, 2008 at 10:54:11AM +, Y Giridhar Appaji Nag wrote: Hi release-team, On 08/09/29 12:26 +0200, Rene Engelhard said ... Package: libdaemon0 Version: 0.10-1 Severity: grave Since 0.13 is already in sid and this bug affects 0.12-1 (in Lenny) I would like to upload 0.12-1lenny1 to testing-proposed-updates. Please do let me know if that is OK. Please do. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpBt8gcOI768.pgp Description: PGP signature
Bug#499469: #499469 llvm-examples: binNMU-unsafe dependency on llvm-dev
On Tue, Sep 30, 2008 at 09:32:13AM +, Evgeni Golov wrote:
Hi,
while looking at our RC bugs, I discovered this one and thought I could
fix it by loosing the Dependency on llvm-dev to = ${source:Version},
but after looking at the package, I wondered if the Dependency is
needed at all.
The package contains only example sourcecode, which I would understand
as a kind of documentation. The code is still readable and
understandable without the llvm-dev package (even if not complileable).
Thus I think llvm-examples should only recommend llvm-dev without
any version (or does llvm break it's API with every release?).
It does. Or at least often.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgphNFnHvGSWT.pgp
Description: PGP signature
Bug#496419: please remove convirt and cgiwrap from testing
On Sun, Sep 28, 2008 at 08:45:30AM +, Thijs Kinkhorst wrote: Hi, Here's a request to remove two security-bugged packages from testing: convirt: * Has security issue spread around the code. There's a patch but it's necessarily invasive and untested. * No maintainer response to the security bug or any other open bug. * Package not in stable, doesn't seem a good idea to introduce it into stable when it's unmaintained. cgiwrap: * Security issue with no adequate patch available. * Security sensitive application but unmaintained; last maintainer upload in 2005. * Many newer upstreams available. done pgpbkbIHSWKOu.pgp Description: PGP signature
Bug#489906: glibc: tst-regex fails on hppa
On lun, jui 28, 2008 at 09:28:09 +, Petr Salinger wrote: __libc_setlocale_lock is defined differently on different places, it have been changed into rwlock in intl and locale subdirs, but it remains plain lock in time/alt_digit.c time/era.c wcsmbs/wcsmbsload.c Also the order of unlocking is not reverse order of locking order w.r.t __libc_setlocale_lock and nl_state. So it might help to move __libc_rwlock_rdlock(__libc_setlocale_lock) after __libc_rwlock_rdlock(_nl_state_lock) in intl/dcigettext.c and transform remaining __libc_setlocale_lock into rwlock. But none of these bugs should be hppa specific. Well I'm not surprised, hppa is one of the sole architecture still using linuxthreads, and probably rwlock/mutexes are different enough so that seeing one of them like the other makes odd things, whereas NPTL has some kind of overlapping semantics on both that if it doesn't do the right thing, doesn't break mutexes too much ;) (I'm just guessing the the overlapping bits, but I really mean that hppa *is* different wrt locking). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGE7CIsluTH.pgp Description: PGP signature
Bug#489906: glibc: tst-regex fails on hppa
On lun, jui 28, 2008 at 04:54:29 +, Petr Salinger wrote: Well I'm not surprised, hppa is one of the sole architecture still using linuxthreads, Not exactly, kfreebsd-i386 and kfreebsd-amd64 also use linuxthreads add-on, there is no problem shown on them. and probably rwlock/mutexes are different enough so that seeing one of them like the other makes odd things, whereas NPTL has some kind of overlapping semantics on both that if it doesn't do the right thing, doesn't break mutexes too much ;) (I'm just guessing the the overlapping bits, but I really mean that hppa *is* different wrt locking). My guess is the difference between i386/amd64 and hppa is a need for kernel support for compare-and-swap. On hppa, there have to be syscall, which may easily lead into rescheduling, race condition is just hitted more freqently on hppa. Anyway, it is only guess, build on hppa will show whether it would solve the problem. \o/ it built fine thanks a lot for your help. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpL788CcbZ1B.pgp Description: PGP signature
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
severity 491809 important retitle 491809 DNS stub resolver could be hardened. thanks On Fri, Jul 25, 2008 at 10:06:01PM +, Florian Weimer wrote: reopen 491809 thanks * Pierre Habouzit: Kaminsky agrees confirm the issue, so I can say for sure that the glibc isn't vulnerable to the attack he describes, as it needs a resolver that caches additionnal RRs, which the glibc doesn't do. As of attacks that would use non randomized source port use, this is addressed by recent kernels hence is fixed enough. I've trouble parsing what you wrote. What I mean, is that the glibc performs no additionnal RR caching, which is how the attack poisons caches. Moreover the glibc is _not_ a recursive resolver either. And finally it also uses random source ports, which is the simplest way to prevent Kaminsky's attack. Based on information provided at the DNS summit, I do think we should harden the glibc stub resolver. That's another matter which doesn't warrant a critical severity at all. The glibc stub resolver is already safe enough by many standards. I don't deny it could be hardened though (Improving the RNG is probably not a bad idea). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpHCXdOIdJV7.pgp Description: PGP signature
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
On Tue, Jul 22, 2008 at 03:24:06PM +, Florian Weimer wrote: * Aurelien Jarno: Currently, there is no suitable patch to backport. I hope that improved port randomization will be available shortly. You mean a patch for the kernel? Yes, one for the kernel, and one for the transaction ID generation in the libc resolver, too. (Oh, and shortly == next week or so.) Assuming the TID generator for the glibc is good enough and that the flaw is the one described in [0], then the glibc code (even nscd) isn't vulnerable, because it doesn't cache or even look at the additional records. The problems with QID randomization are quite orthogonal, and it's a problem known for 20 years now (using last QID+1 isn't really an option ;p). Having a better random number generator will probably help, but quite doesn't require such a severity (as there is already randomization of the QIDs, maybe not a perfect one). So unless you have further non yet disclosed informations, I'd suggest reconsidering the DSA. [0] http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpuuddWtwKnI.pgp Description: PGP signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Wed, Jun 18, 2008 at 12:25:33PM +, A Mennucc wrote: I fix all bugs that can reasonably be fixed. When ffmpeg in Debian was too obsolete to link to mplayer, there was nothing I could do. Since 2006, many things happened; for example, in http://bugs.debian.org/403330 I asked for a new version of ffmpeg, but 403330 was closed by the version 0.cvs20070307 that became rapidly obsolete wrt mplayer 1.0~rc2 Hint: ffmpeg in Debian is team maintained. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVzI1ejIN7O.pgp Description: PGP signature
Bug#485956: Errata - resetting severity
On Fri, Jun 13, 2008 at 02:07:29PM +, Jon wrote: Perhaps you can explain something to me then. I am able to build the package without being root, and have explained this to the user. He just can't get it to work with his command line. Please explain why this makes the bug serious? Where does it state in the policy that -*that*- exact command-line must be supported? Jon Well, You're supposed to know that, and it's so easy to find you should be ashamed to ask. Though it's in policy §4.9 [0], I quote the relevant bits: build The build target must not do anything that might require root privilege. build-arch (optional), build-indep (optional) The build-arch and build-indep targets must not do anything that might require root privilege. binary, binary-arch, binary-indep The binary targets must be invoked as root.[23] clean The clean target may need to be invoked as root if binary has been invoked since the last clean, or if build has been invoked as root (since build may create directories, for example). IOW fakeroot must not be used for anything else than the binary* and clean targets. *FULL STOP*. Anything else is buggy, whatever command you're using. IOW, building a debian package this way: $ dpkg-source -x foo.dsc $ cd foo*/ $ ./debian/rules build $ fakeroot debian/rules binary $ fakeroot debian/rules clean *must* be supported no matter what. FWIW this is Debian Packaging 101. [0] http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpkdq21dg8PU.pgp Description: PGP signature
Bug#485956: Errata - resetting severity
: changing ownership of `debian/tmp-src/usr/share/doc/qmail-src/copyright': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/share/doc/qmail-src': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/share/doc': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/share': Operation not permitted chown: changing ownership of `debian/tmp-src/usr': Operation not permitted chown: changing ownership of `debian/tmp-src': Operation not permitted make: *** [binary-src] Error 1 ./debian/rules build 1,49s user 1,76s system 95% cpu 3,407 total -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdeik8uOpIL.pgp Description: PGP signature
Bug#485955: gdb: completely fails to detect frames
On Fri, Jun 13, 2008 at 06:04:53PM +, Daniel Jacobowitz wrote: On Thu, Jun 12, 2008 at 06:19:35PM +0200, Pierre Habouzit wrote: Is a shared library involved? No, the symbol is local, visibility hidden. Normally, when this happens, there is a symbol in the ELF symbol table (.symtab) for the hidden symbol. That symbol is missing in your case. Well I really don't do anything fancy here, no linker script is involved, just simple gcc… I don't know why it worked pre-6.7, but this is not a well-supported case in GDB. It expects there to be ELF symbols for all functions. Fortunately, an optimized code improvement added to GDB HEAD after 6.8 fixes your testcase again. okay, I'm glad then. In the mean time, I suggest you use 6.7, use HEAD, or arrange not to strip a subset of ELF symbols. That's what I'm doing (the former) for now. Thanks -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvfOmGtckP9.pgp Description: PGP signature
Bug#485956: Errata - resetting severity
On Fri, Jun 13, 2008 at 04:24:55PM +, Jon wrote: I'll take a look at it. STOP REMOVING THE CC TO THE BUG# ITS RUDE. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgppNm6Zc13Gw.pgp Description: PGP signature
Bug#481337: apt-proxy stops respnding after downloading one file
tag 481337 + sid thanks On Thu, May 15, 2008 at 11:27:24AM +, Dr. Tilo Levante wrote: Package: apt-proxy Version: 1.9.36.3 Severity: grave Justification: renders package unusable After an update, apt-proxy stopped responding after downloading one package. In the log file I found: bsddb.db.DBInvalidArgError: (22, 'Invalid argument -- /var/cache/apt-proxy/.apt-proxy/backends/debian/packages.db: unsupported hash version: 9') After deleting the whole /var/cache/apt-proxy/.apt-proxy/backends directory, apt-proxy worked again. maybe the directory should be deleted or upgraded during update? Greetings tilo [EMAIL PROTECTED] This bug is a well known python DB related breakage due to the change of db4.6 back to 4.5 at some point. You can fix your db's using db4.6_dump | db4.5_load (from dbX.Y-utils). This bug will not affect stable releases, so I'm tagging this bug accordingly. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprsCY7vdEIA.pgp Description: PGP signature
Bug#454313: status of bazaar
On Wed, Jun 11, 2008 at 12:20:25PM +, James Westby wrote: On Thu, 2008-06-05 at 10:56 +0200, Pierre Habouzit wrote: Bazaar currently suffers from #454313, but has reverse dependencies which prevent its sane removal from testing. It looks to me that bazaar is unmaintained upstream, the last 4 uploads in Debian are NMUs, and almost nobody is using it nowadays. Baz is unmaintained, and it would be great to remove it for lenny. I believe Manoj was originally opposed to this, but I believe that he won't be so worried about the removal now. Okay, let's do this then. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdsxKujDLXm.pgp Description: PGP signature
Bug#485914: libavg: spurious build-depends on liblzo-dev
Package: libavg Severity: serious Justification: prevent lzo removal libavg has build-dependencies on lzo, whereas it has no corresponding Runtime Depends. This is likely a spurious build-depends, please get rid of it, it prevents lzo removal from Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
Package: gdb Version: 6.8-3 Severity: grave Justification: renders package unusable Since the 6.8 releases, gdb totally fails to detect stack frames correctly, whereas the lenny version (6.7.1-2 atm) works fine. My architecture is amd64, but I've seen the same issues on i386 FWIW. The code is C, with quite a few inlines, changing the gcc debug levels (-g/-g3/-ggdb3) or even building with -O0 -fno-inline doesn't change a damn thing. This renders gdb mostly unusable because it's totally unable to dump useful backtraces (with source files and files lineno's) on segfaults. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 03:58:18PM +, Daniel Jacobowitz wrote: severity 485955 normal thanks On Thu, Jun 12, 2008 at 05:41:02PM +0200, Pierre Habouzit wrote: Since the 6.8 releases, gdb totally fails to detect stack frames correctly, whereas the lenny version (6.7.1-2 atm) works fine. My architecture is amd64, but I've seen the same issues on i386 FWIW. I've seen no evidence this bug affects anyone else and the package is clearly not unusable. Downgrading. The code is C, with quite a few inlines, changing the gcc debug levels (-g/-g3/-ggdb3) or even building with -O0 -fno-inline doesn't change a damn thing. This renders gdb mostly unusable because it's totally unable to dump useful backtraces (with source files and files lineno's) on segfaults. Can you provide a test case? Or even an example session? I can't read your mind... With gdb from sid: (gdb) bt #0 sms_emi_ack_5X (out=0x1b1dc88, msg=0x7fff637d97e0) at lib-inet/sms-emi.c:230 #1 0x00404973 in ?? () #2 0x004182f7 in ?? () #3 0x00412400 in sms_parse_emi (in=0x1b1dc70, out=0x1b1dc88, on_msg=value optimized out, priv=value optimized out) at lib-inet/sms-emi-parse.c:752 #4 0x00418f25 in ?? () #5 0x00406850 in agent_dispatch_epoll (timeout=value optimized out) at lib-inet/agent.c:1076 #6 0x00403a2f in main (argc=value optimized out, argv=value optimized out) at simulator/smsc/smsc.c:90 With gdb from etch: (gdb) bt #0 sms_emi_ack_5X (out=0x110dc88, msg=0x7fff73230240) at lib-inet/sms-emi.c:230 #1 0x00404973 in smsc_emi_on_query (we=0x110dbe0, msg=0x7fff73230240) at simulator/smsc/emi_smsc.c:232 #2 0x004182f7 in emi_common_hook (msg=0x7fff73230240, _w=value optimized out) at lib-inet/smsmachines.c:269 #3 0x00412400 in sms_parse_emi (in=0x110dc70, out=0x110dc88, on_msg=value optimized out, priv=value optimized out) at lib-inet/sms-emi-parse.c:752 #4 0x00418f25 in emilistener_event (w=0x110a0a0, kind=value optimized out) at lib-inet/smsmachines.c:379 #5 0x00406850 in agent_dispatch_epoll (timeout=value optimized out) at lib-inet/agent.c:1076 #6 0x00403a2f in main (argc=value optimized out, argv=value optimized out) at simulator/smsc/smsc.c:90 I here just ran gdb ./myexe and placed a breakpoint on sms_emi_ack_5X. It seems there is something fishy with pointer to functions as emilistener_event emi_common_hook and smsc_emi_on_query are callbacks. I'm sorry but I just can't give you access to that code :/ -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpiVwijD7wxB.pgp Description: PGP signature
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 04:13:39PM +, Daniel Jacobowitz wrote:
On Thu, Jun 12, 2008 at 06:11:28PM +0200, Pierre Habouzit wrote:
#0 sms_emi_ack_5X (out=0x1b1dc88, msg=0x7fff637d97e0) at
lib-inet/sms-emi.c:230
#1 0x00404973 in ?? ()
With gdb from etch:
(gdb) bt
#0 sms_emi_ack_5X (out=0x110dc88, msg=0x7fff73230240) at
lib-inet/sms-emi.c:230
#1 0x00404973 in smsc_emi_on_query (we=0x110dbe0,
msg=0x7fff73230240) at simulator/smsc/emi_smsc.c:232
Note, same address.
Is a shared library involved?
No, the symbol is local, visibility hidden.
Does list smsc_emi_on_query do anything?
lenny:
(gdb) list smsc_emi_on_query
249{
[... dumps code ...]
(gdb) b smsc_emi_on_query
Breakpoint 1 at 0x404520: file simulator/smsc/emi_smsc.c, line 254.
sid:
(gdb) list smsc_emi_on_query
No line number known for smsc_emi_on_query.
(gdb) b smsc_emi_on_query
Breakpoint 1 at 0x404520
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpf9SbIQvGIh.pgp
Description: PGP signature
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 04:19:35PM +, Pierre Habouzit wrote:
On Thu, Jun 12, 2008 at 04:13:39PM +, Daniel Jacobowitz wrote:
On Thu, Jun 12, 2008 at 06:11:28PM +0200, Pierre Habouzit wrote:
#0 sms_emi_ack_5X (out=0x1b1dc88, msg=0x7fff637d97e0) at
lib-inet/sms-emi.c:230
#1 0x00404973 in ?? ()
With gdb from etch:
(gdb) bt
#0 sms_emi_ack_5X (out=0x110dc88, msg=0x7fff73230240) at
lib-inet/sms-emi.c:230
#1 0x00404973 in smsc_emi_on_query (we=0x110dbe0,
msg=0x7fff73230240) at simulator/smsc/emi_smsc.c:232
Note, same address.
Is a shared library involved?
No, the symbol is local, visibility hidden.
Does list smsc_emi_on_query do anything?
lenny:
(gdb) list smsc_emi_on_query
249{
[... dumps code ...]
(gdb) b smsc_emi_on_query
Breakpoint 1 at 0x404520: file simulator/smsc/emi_smsc.c, line 254.
sid:
(gdb) list smsc_emi_on_query
No line number known for smsc_emi_on_query.
(gdb) b smsc_emi_on_query
Breakpoint 1 at 0x404520
I've rebuilt a sid gdb, and with the gdb in objdir/gdb/gdb it says:
./gdb ~/dev/mmsx/simulator/smsc/smsc
GNU gdb 6.8-debian
[...]
This GDB was configured as x86_64-linux-gnu...
Setting up the environment for debugging gdb.
Function internal_error not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered
N; input not from terminal]
Function info_command not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered
N; input not from terminal]
/home/madcoder/debian/tmp/gdb-6.8/objdir/gdb/.gdbinit:8: Error in sourced
command file:
No breakpoint number 0.
(gdb) b smsc_emi_on_query
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
Breakpoint 1 at 0x404520
(gdb)
Which I can reproduce doing that on the sid one:
(gdb) set complaints 1
(gdb) b smsc_emi_on_query
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
Breakpoint 1 at 0x404520
But not completely from the lenny one:
(gdb) set complaints 1
(gdb) b smsc_emi_on_query
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
Breakpoint 1 at 0x404520: file simulator/smsc/emi_smsc.c, line 254.
Also, the testsuite is still running but I already saw those failures:
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/break.exp
...
FAIL: gdb.base/break.exp: breakpoint at start of multi line while
conditional
FAIL: gdb.base/break.exp: breakpoint info
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/corefile.exp ...
FAIL: gdb.base/corefile.exp: accessing mmapped data in core file (mapping
address not found in core file)
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/mips_pro.exp ...
FAIL: gdb.base/mips_pro.exp: running to middle in runto
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/sepdebug.exp ...
FAIL: gdb.base/sepdebug.exp: breakpoint at start of multi line while
conditional
FAIL: gdb.base/sepdebug.exp: breakpoint info
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.cp/annota3.exp
...
FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpAn0DS5nWMR.pgp
Description: PGP signature
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 04:47:02PM +, Pierre Habouzit wrote:
Also, the testsuite is still running but I already saw those failures:
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/break.exp ...
FAIL: gdb.base/break.exp: breakpoint at start of multi line while
conditional
FAIL: gdb.base/break.exp: breakpoint info
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/corefile.exp ...
FAIL: gdb.base/corefile.exp: accessing mmapped data in core file (mapping
address not found in core file)
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/mips_pro.exp ...
FAIL: gdb.base/mips_pro.exp: running to middle in runto
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/sepdebug.exp ...
FAIL: gdb.base/sepdebug.exp: breakpoint at start of multi line while
conditional
FAIL: gdb.base/sepdebug.exp: breakpoint info
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.cp/annota3.exp ...
FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)
Attached is the full suite log. Tell me if you want/need anything
else.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
make: Entering directory `/home/madcoder/debian/tmp/gdb-6.8/objdir/gdb'
make[1]: Entering directory
`/home/madcoder/debian/tmp/gdb-6.8/objdir/gdb/testsuite'
Nothing to be done for all...
rootme=`pwd`; export rootme; \
srcdir=/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite ; export srcdir
; \
EXPECT=`if [ -f ${rootme}/../../expect/expect ] ; then echo
${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
EXEEXT= ; export EXEEXT ; \
RPATH_ENVVAR=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$RPATH_ENVVAR;
\
export RPATH_ENVVAR; \
if [ -f ${rootme}/../../expect/expect ] ; then \
TCL_LIBRARY=${srcdir}/../../tcl/library ; \
export TCL_LIBRARY ; fi ; \
runtest
Test Run By madcoder on Thu Jun 12 18:38:07 2008
Native configuration is x86_64-pc-linux-gnu
=== gdb tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/config/unix.exp as
tool-and-target-specific interface file.
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/array_bounds.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/array_return.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/array_subscript_addr.exp
...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/arrayidx.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/arrayparam.exp
...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/arrayptr.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/boolean_expr.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/catch_ex.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/char_param.exp
...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/complete.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/exec_changed.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/exprs.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/fixed_cmp.exp
...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/fixed_points.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/formatted_ref.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/frame_args.exp
...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/fun_addr.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/fun_in_declare.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/funcall_param.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/homonym.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/interface.exp
...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/nested.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/null_array.exp
...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/null_record.exp
...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/packed_array.exp ...
Running
/home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/packed_tagged.exp ...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/print_chars.exp
...
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.ada/print_pc.exp
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 05:00:18PM +, Daniel Jacobowitz wrote: On Thu, Jun 12, 2008 at 06:47:03PM +0200, Pierre Habouzit wrote: (gdb) b smsc_emi_on_query During symbol reading, DW_AT_name missing from DW_TAG_base_type. During symbol reading, unsupported tag: 'DW_TAG_const_type'. Breakpoint 1 at 0x404520 These complaints are not relevant to your error. Also, the testsuite is still running but I already saw those failures: See the log in /usr/share/doc/gdb for typical failures. Here is the diff: @@ -107,2 +106,4 @@ Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/break.exp ... +FAIL: gdb.base/break.exp: breakpoint at start of multi line while conditional +FAIL: gdb.base/break.exp: breakpoint info Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/call-ar-st.exp ... @@ -177,2 +178,3 @@ Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/mips_pro.exp ... +FAIL: gdb.base/mips_pro.exp: running to middle in runto Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/miscexprs.exp ... @@ -212,2 +214,4 @@ Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/sepdebug.exp ... +FAIL: gdb.base/sepdebug.exp: breakpoint at start of multi line while conditional +FAIL: gdb.base/sepdebug.exp: breakpoint info Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/sepsymtab.exp ... @@ -259,5 +263,5 @@ Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/annota3.exp ... +FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1) Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/anon-union.exp ... Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/arg-reference.exp ... -FAIL: gdb.cp/arg-reference.exp: No false reference Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/bool.exp ... @@ -281,3 +285,4 @@ FAIL: gdb.cp/inherit.exp: ptype tagless struct -FAIL: gdb.cp/inherit.exp: print type of anonymous union // unrecognized line type 1: class_with_anon_union::._0; +FAIL: gdb.cp/inherit.exp: ptype variable of type tagless struct +FAIL: gdb.cp/inherit.exp: print type of anonymous union // unrecognized line type 1: class_with_anon_union::anonymous union; Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/local.exp ... @@ -475,2 +478,3 @@ Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.threads/thread_check.exp ... +FAIL: gdb.threads/thread_check.exp: breakpoint at tf Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.threads/thread_events.exp ... Does readelf -wi complain about the file containing one of your 'invisible' functions? I see nothing special no. What does the DW_TAG_subprogram look like for smsc_emi_on_query? 16274: Abbrev Number: 71 (DW_TAG_subprogram) 6275 DW_AT_name: (indirect string, offset: 0x1ce4): smsc_emi_on_query 6279 DW_AT_decl_file : 1 627a DW_AT_decl_line : 254 627b DW_AT_prototyped : 1 627c DW_AT_type: 33fa 6280 DW_AT_low_pc : 0x404520 6288 DW_AT_high_pc : 0x404d21 6290 DW_AT_frame_base : 0xcc8 (location list) 6294 DW_AT_sibling : 644d See your query on IRC for the rest. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8cRFCw2qiZ.pgp Description: PGP signature
Bug#484507: grub-pc postinst fails silently
On Wed, Jun 11, 2008 at 09:04:54PM +, Robert Millan wrote: On Wed, Jun 04, 2008 at 03:29:05PM +0200, Pierre Habouzit wrote: Package: grub-pc Version: 1.96+20080601-2 Severity: serious Are you using ext3? No, reiserfs for / and dm-crypt/lvm2/xfs for the rest. Setting up grub-pc (1.96+20080601-2) ... Installing new version of config file /etc/grub.d/10_linux ... *** glibc detected *** /usr/sbin/grub-probe: realloc(): invalid next size: 0x01bf83d0 *** Can you check if reverting this commit: http://cvs.savannah.gnu.org/viewvc/grub2/fs/ext2.c?root=grubr1=1.18r2=1.19view=patch makes it work again? Well it didn't always fails, and I don't have the time to roll my own grub2 package _and_ test it I'm sorry. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpmDvrlApAc6.pgp Description: PGP signature
Bug#441797: [DebianGIS] [Fwd: [DebianGIS-dev] postgis REMOVED from testing]
On Sat, Jun 07, 2008 at 09:20:50AM +, Francesco P. Lovergine wrote: severity 441797 important severity 441794 important thanks On Sat, Jun 07, 2008 at 09:41:35AM +0200, Paolo Cavallini wrote: Hi all. Could someone please update us about the state of PostGIS, and the prospects for the near future? Thanks a lot. pc Have a look to the main bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441797 I have a couple of ideas about that: 1. it's not a true issue for etch-lenny because postgres versions are different and users can easily maintain the old version and migrate by hard upgrade script, as documented in the README file. So this is not a RC bug. 2. 1.3.1 is not more present in the archive, so that does not break anything currently. 3. We need to prepare a migration framework that uses the trick I shown in the report. Thanks strk for a past discussion about that :-) That should allow a more soft migration in some cases, but anyway Postgis REQUIRES running soft/hard upgrades scripts for all its databases, and that is a MUST and users are warned about that in README.Debian since ages. There's not a silver bullet. Well I was under the impression in the bug log that it also needed to keep an old version of a library during the upgrade wich is at best sloppy. If that's not needed, then yes, important works for me. Note that you have another RC bug open that is quite trivial to fix on its own. We try to release, please keep your packages clean. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpv9IxAyxdV1.pgp Description: PGP signature
Bug#480545: tagging 480545
On Thu, Jun 05, 2008 at 03:10:54PM +, Alexander Wirt wrote: Pierre Habouzit schrieb am Thursday, den 05. June 2008: On Sun, May 25, 2008 at 05:14:28PM +, Alexander Wirt wrote: # Automatically generated email from bts, devscripts version 2.10.28 tags 480545 pending Any reason why this isn't uploaded yet ? Just a matter of time and a broken internet connection. The connection had been fixed earlier this morning so this should be solved soon. okay, np :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpW02RCkj96i.pgp Description: PGP signature
Bug#478434: atokx installation fails during configure phase
On Tue, Apr 29, 2008 at 10:20:55PM +, peter green wrote: Are you sure this is a bug? the debconf message before I get that error seems to ask for a commercial CD (which I don't have, it seems this package can only be used if you own the appropriate commercial software. Then this is worse, this package should live in non-free. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9QAVIzMNw7.pgp Description: PGP signature
Bug#480545: tagging 480545
On Sun, May 25, 2008 at 05:14:28PM +, Alexander Wirt wrote: # Automatically generated email from bts, devscripts version 2.10.28 tags 480545 pending Any reason why this isn't uploaded yet ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpgtU7y5zXfF.pgp Description: PGP signature
Bug#484507: grub-pc postinst fails silently
Package: grub-pc Version: 1.96+20080601-2 Severity: serious Excerpt from today's update: Setting up grub-pc (1.96+20080601-2) ... Installing new version of config file /etc/grub.d/10_linux ... *** glibc detected *** /usr/sbin/grub-probe: realloc(): invalid next size: 0x01bf83d0 *** === Backtrace: = /lib/libc.so.6[0x7fea45626978] /lib/libc.so.6[0x7fea4562a571] /lib/libc.so.6(realloc+0x12f)[0x7fea4562afef] /usr/sbin/grub-probe[0x402ff9] /usr/sbin/grub-probe[0x411cb9] /usr/sbin/grub-probe[0x411d80] /usr/sbin/grub-probe[0x4130ac] /usr/sbin/grub-probe[0x4182da] /usr/sbin/grub-probe[0x4016f2] /usr/sbin/grub-probe[0x401b68] /lib/libc.so.6(__libc_start_main+0xe6)[0x7fea455d11a6] /usr/sbin/grub-probe[0x4014a9] === Memory map: 0040-00422000 r-xp 08:03 22141 /usr/sbin/grub-probe 00622000-00623000 rwxp 00022000 08:03 22141 /usr/sbin/grub-probe 00623000-0062f000 rwxp 00623000 00:00 0 01be2000-0213 rwxp 01be2000 00:00 0 [heap] 7fea4000-7fea40021000 rwxp 7fea4000 00:00 0 7fea40021000-7fea4400 ---p 7fea40021000 00:00 0 7fea4539c000-7fea453b2000 r-xp 08:03 4625183 /lib/libgcc_s.so.1 7fea453b2000-7fea455b2000 ---p 00016000 08:03 4625183 /lib/libgcc_s.so.1 7fea455b2000-7fea455b3000 rwxp 00016000 08:03 4625183 /lib/libgcc_s.so.1 7fea455b3000-7fea456fd000 r-xp 08:03 4822269 /lib/libc-2.7.so 7fea456fd000-7fea458fd000 ---p 0014a000 08:03 4822269 /lib/libc-2.7.so 7fea458fd000-7fea4590 r-xp 0014a000 08:03 4822269 /lib/libc-2.7.so 7fea4590-7fea45902000 rwxp 0014d000 08:03 4822269 /lib/libc-2.7.so 7fea45902000-7fea45907000 rwxp 7fea45902000 00:00 0 7fea45907000-7fea45923000 r-xp 08:03 4822265 /lib/ld-2.7.so 7fea45b02000-7fea45b04000 rwxp 7fea45b02000 00:00 0 7fea45b1f000-7fea45b22000 rwxp 7fea45b1f000 00:00 0 7fea45b22000-7fea45b24000 rwxp 0001b000 08:03 4822265 /lib/ld-2.7.so 7fff4db0f000-7fff4db24000 rwxp 7ffea000 00:00 0 [stack] 7fff4dbfe000-7fff4dc0 r-xp 7fff4dbfe000 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Aborted Updating /boot/grub/grub.cfg ... And it continued to upgrade without a glitch. The update should have failed. Moreover, memory corruption isn't nice, which is another bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459567: dirmngr segfaults on hppa architecture
On Mon, Jun 02, 2008 at 08:08:41AM +, Deller, Helge wrote: FWIW this is likely to be a libpth issue, which in turn may be a makecontext/setcontext issue in the glibc. You have to contact porters about that. I know for sure, that the makecontext/setcontext have not yet been implemented on hppa. Are they required for dirmngr ? Okay and that's what the strack dump shows. libpth uses make/setcontext when available, and else uses sigaltstack tricks to do threads. I assume something is broken in the latter code, maybe with recent compilers. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpwkvcSViF8O.pgp Description: PGP signature
Bug#484082: maint-guide: freetype1 deprecation
On Mon, Jun 02, 2008 at 02:33:40PM +, Osamu Aoki wrote: On Mon, Jun 02, 2008 at 11:32:13AM +0200, [EMAIL PROTECTED] wrote: Package: maint-guide Severity: serious Hi, The security team wants to deprecate freetype1 for lenny. Your package either depends or build-depends upon freetype1(-tools). Please drop that dependency, so that freetype1 can be removed from Debian. (see http://bugs.debian.org/480230) ??? This was fixed in NMU too. (Although NMU broke package thus staying in unstable.) Osamu On Mon, Jun 02, 2008 at 02:11:27PM +, Osamu Aoki wrote: On Mon, Jun 02, 2008 at 11:32:13AM +0200, [EMAIL PROTECTED] wrote: Package: debian-reference Severity: serious Hi, The security team wants to deprecate freetype1 for lenny. Your package either depends or build-depends upon freetype1(-tools). Please drop that dependency, so that freetype1 can be removed from Debian. (see http://bugs.debian.org/480230) Hi, It was NMUed. That fixed issue of freetype1. (Or he claimed so.): 2008-05-22 See it is closed. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481789 At the same time, I was doing major update in which no PDF/PS are generated and source is not only SGML but also has XML. I made 2 uploads with current package shape on: 2008-05-31 and 2008-06-01 I wonder ... is there still a issue with my package. I see no problem. Are you only checking testing status? Just wait 10 more days, the newest should move to testing then. Osamu Yes I saw that later, I'm sorry, note that I closed the bugs since to fix my mistake. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp5IVQVL5bY9.pgp Description: PGP signature
