Bug#624393: eclipse-pydev-gcj: Depends: eclipse-platform-gcj which is a virtual package.
Package: eclipse-pydev-gcj Version: 1.2.5-4 Severity: normal The package is uninstallable for that reason. cheers, Simon -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages eclipse-pydev depends on: ii bicyclerepair 0.9-6 A refactoring tool for python ii eclipse 3.5.2-9Extensible Tool Platform and Java ii jython2.5.1-2Python seamlessly integrated with ii libcommons-codec-java 1.5-1 encoder and decoders such as Base6 ii python2.6.6-14 interactive high-level object-orie ii python-dev2.6.6-14 header files and a static library Versions of packages eclipse-pydev recommends: pn eclipse-platform-gcj none (no description available) pn eclipse-pydev-gcj none (no description available) eclipse-pydev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624394: ITP:ncbi-blast-plus
Package: wnpp Severity: wishlist Owner: Olivier Sallou olivier.sal...@irisa.fr Package name: ncbi-blast-plus Version : 2.2.25 URL : http://blast.ncbi.nlm.nih.gov/Blast.cgi?CMD=WebPAGE_TYPE=BlastDocsDOC_TYPE=Download License : public domain Programming Lang: C++ Description : The BLAST+ applications have a number of performance and feature improvements over the legacy BLAST applications BLAST+ is a new suite of BLAST tools that utilizes the NCBI C++ Toolkit. The Basic Local Alignment Search Tool (BLAST) is the most widely used sequence similarity tool. There are versions of BLAST that compare protein queries to protein databases, nucleotide queries to nucleotide databases, as well as versions that translate nucleotide queries or databases in all six frames and compare to protein databases or queries. -- gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#624395: sec: New upstream version 2.6.0 available
Source: sec Version: 2.5.3-1+nmu1 Severity: wishlist Hi There is a new upstream version available for `sec': --- version 2.6.0 * added support for the EventGroup rule. * starting from this version, the Calendar rule accepts a year condition in the time specification. * added support for the 'lcall', 'getwpos' and 'setwpos' actions. * added support for the named match variables and variable maps. * added Cached and NCached pattern types, and support for pattern match caching. * starting from this version, all unset or undefined variables are substituted with empty strings. Thanks for your work! Best regards Salvatore -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619433: Follow-up
Hello, Just to inform that the bug has found a fix upstream (commit 7bed50c5edf5cba8dd515a31191cbfb6065ddc85, details can be found at https://bugzilla.kernel.org/show_bug.cgi?id=31872). The fix has been included in linux-2.6 tree and is waiting in the queue-2.6.38 subdirectory. I am currently running a self built linux-2.6.38 image with the above fix included, and it seems that the bug did not touch any one but me (given my buggy bios). I can now wait for next upload in Debian (next 2.6.38 if any, or next 2.6.39 in experimental or unstable), so I believe you can just close this bug without any further action. Best regards and thank you for pointing me to the right place. Pascal Dormeau -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624396: gnome-shell: frequenly fails gracefully losing stored favorites after restart
Package: gnome-shell Version: 3.0.0.2-1 Severity: normal 1. I've experienced frequent Gnome Shell crashes that crash gracefully and reload not forcing me out of the environment. 2. All prior stored information for the Favorites List becomes lost. (i.e., the default list of apps for quick use is all that remains after the graceful crash) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-shell depends on: ii gconf2 2.32.1-2GNOME configuration database syste ii gir1.2-atk-1.0 2.0.0-1 The ATK accessibility toolkit (GOb ii gir1.2-clutter-1 1.6.10-3GObject introspection data for the ii gir1.2-freedeskt 0.10.7-1Introspection data for some FreeDe ii gir1.2-gconf-2.0 2.32.1-2GNOME configuration database syste ii gir1.2-gdkpixbuf 2.23.3-3GDK Pixbuf library - GObject-Intro ii gir1.2-gkbd-3.0 2.91.91-2 GObject introspection data for the ii gir1.2-glib-2.0 0.10.7-1Introspection data for GLib, GObje ii gir1.2-gnomeblue 3.0.0-1 Introspection data for GnomeBlueto ii gir1.2-gtk-3.0 3.0.8-1 The GTK+ graphical user interface ii gir1.2-json-glib 0.12.0-3GLib JSON manipulation library (do ii gir1.2-mutter-3. 3.0.0-2 GObject introspection data for Mut ii gir1.2-networkma 0.8.998-1 GObject introspection data for Net ii gir1.2-pango-1.0 1.28.3-6Layout and rendering of internatio ii gir1.2-polkit-1. 0.101-4 GObject introspection data for Pol ii gir1.2-telepathy 0.14.5-1GLib Telepathy connection manager ii gir1.2-telepathy 0.2.8-2 Telepathy logger service - introsp ii gir1.2-upowergli 0.9.9-4 GObject introspection data for upo ii gjs 0.7.13-2Mozilla-based javascript bindings ii gnome-bluetooth 3.0.0-1 GNOME Bluetooth tools ii gnome-control-ce 1:3.0.0.1-1 utilities to configure the GNOME d ii gnome-icon-theme 3.0.0-1 GNOME Desktop icon theme (symbolic ii gnome-settings-d 3.0.0.1-1 daemon handling the GNOME session ii gsettings-deskto 3.0.0-1 GSettings deskop-wide schemas ii libatk1.0-0 2.0.0-1 The ATK accessibility toolkit ii libc62.11.2-13 Embedded GNU C Library: Shared lib ii libcairo-gobject 1.10.2-6The Cairo 2D vector graphics libra ii libcairo21.10.2-6The Cairo 2D vector graphics libra ii libcamel1.2-19 2.32.3-1Evolution MIME message handling li ii libcanberra0 0.26-3 a simple abstract interface for pl ii libclutter-1.0-0 1.6.10-3Open GL based interactive canvas l ii libcroco30.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.4.8-3 simple interprocess messaging syst ii libdbus-glib-1-2 0.92-1 simple interprocess messaging syst ii libdconf00.7.3-4 Simple key-based configuration sys ii libdrm2 2.4.25-1Userspace interface to kernel DRM ii libebook1.2-10 3.0.0-1 Client library for evolution addre ii libecal1.2-8 3.0.0-1 Client library for evolution calen ii libedataserver1. 3.0.0-1 Utility library for evolution data ii libedataserverui 3.0.0-1 GUI utility library for evolution ii libffi5 3.0.9-4 Foreign Function Interface library ii libfontconfig1 2.8.0-2.2 generic font configuration library ii libfreetype6 2.4.4-1 FreeType 2 font engine, shared lib ii libgconf2-4 2.32.1-2GNOME configuration database syste ii libgdk-pixbuf2.0 2.23.3-3GDK Pixbuf library ii libgirepository- 0.10.7-1Library for handling GObject intro ii libgjs0b 0.7.13-2Mozilla-based javascript bindings ii libgl1-mesa-glx 7.10.2-1A free implementation of the OpenG ii libglib2.0-0 2.28.6-2GLib library of C routines ii libgnome-desktop 3.0.0-1 Utility library for loading .deskt ii libgnome-menu2 3.0.0-1 GNOME implementation of the freede ii libgstreamer0.10 0.10.32.3-1 Core GStreamer libraries and eleme ii libgtk-3-0 3.0.8-1 The GTK+ graphical user interface ii libical0 0.44-3 iCalendar library implementation i ii libjson-glib-1.0 0.12.0-3
Bug#624371: ITP: ADIOS -- ADIOS Adaptable IO subsystem for science
Hi, On Wed, Apr 27, 2011 at 09:41:44PM +0100, Alastair McKinstry wrote: Package: wnpp Severity: wishlist Owner: Alastair McKinstry mckins...@debian.org * Package name: ADIOS Version : 1.2.1 Upstream Author : UT-BATTELLE, LLC Homepage: http://www.olcf.ornl.gov/center-projects/adios/ * License : BSD Programming Lang: C, Fortran Description : ADIOS Adaptable IO subsystem for science The Adaptable IO System (ADIOS) provides a simple, flexible way for scientists to describe the data in their code that may need to be written, read, or processed outside of the running simulation. By providing an external to the code XML file describing the various elements, their types, and how you wish to process them this run, the routines in the host code (either Fortran or C) can transparently change how they process the data. Not sure I understand that description, in particular: By providing an external to the code XML file describing the various elements, their types, and how you wish to process them this run, the routines in the host code (either Fortran or C) can transparently change how they process the data. That is, by providing *what* ? Best regards, Filippo -- Filippo Rusconi, PhD - CNRS - public key C78F687C Author of ``massXpert'' at http://www.massxpert.org signature.asc Description: Digital signature
Bug#551537: GTK interface does not display UTF characters correctly
Package: apt-listchanges Version: 2.85.7 Tags: patch Followup-For: Bug #551537 The following patch fixes the problem using the frontend function _render() specifically designed for the purpose: ---8--- --- /usr/share/apt-listchanges/AptListChangesGtk.py.dist2011-04-28 08:34:42.0 +0200 +++ /usr/share/apt-listchanges/AptListChangesGtk.py 2011-04-28 08:35:10.0 +0200 @@ -42,7 +42,7 @@ def display_output(self,text): self.button_close.set_sensitive(True) buf = self.glade.get_widget(textview_main).get_buffer() -buf.set_text(unicode(text, 'latin-1').encode(UTF-8)) +buf.set_text(self._render(text)) gtk.main() def update_progress(self): ---8--- -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-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 apt-listchanges depends on: ii apt 0.8.14.1 Advanced front-end for dpkg ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy ii debianutils 3.4.4Miscellaneous utilities specific t ii python 2.6.6-14 interactive high-level object-orie ii python-apt 0.7.100.3+b1 Python interface to libapt-pkg ii python-support 1.0.13 automated rebuilding support for P ii ucf 3.0025+nmu2 Update Configuration File: preserv Versions of packages apt-listchanges recommends: ii msmtp-mta [mail-transport-age 1.4.23-1 light SMTP client with support for Versions of packages apt-listchanges suggests: ii chromium [www-brow 10.0.648.205~r81283-1 Chromium browser ii elinks [www-browse 0.12~pre5-3.2 advanced text-mode WWW browser ii iceape-browser [ww 2.0.13-1 Iceape Navigator (Internet browser ii iceweasel [www-bro 3.5.18-1 Web browser based on Firefox ii konqueror [www-bro 4:4.4.5-3 advanced file manager, web browser ii konsole [x-termina 4:4.4.5-3 X terminal emulator ii lynx-cur [www-brow 2.8.8dev.8-1 Text-mode WWW Browser with NLS sup ii opera [www-browser 11.10.2092A fast and secure web browser and ii python-glade2 2.24.0-1 GTK+ bindings: Glade support ii python-gtk22.24.0-1 Python bindings for the GTK+ widge ii rxvt-unicode [x-te 9.10-1RXVT-like terminal emulator with U ii w3m [www-browser] 0.5.3-2+b1WWW browsable pager with excellent ii xterm [x-terminal- 269-1 X terminal emulator -- debconf information: * apt-listchanges/confirm: false * apt-listchanges/which: both * apt-listchanges/frontend: gtk * apt-listchanges/email-address: * apt-listchanges/save-seen: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624380: [Pkg-clamav-devel] Bug#624380: clamav-base: Please package huge example files seperately or move them to clamav-docs
This one time, at band camp, Axel Beckert said: With the exception of the example configuration file, those files are probably not needed by the vast majority of the clamav users, yet all of them have to waste those 26 MB of disk space and download time when installing e.g. freshclam which has a hard dependency. Hi, We've been around this before, unfortunately. The problem is that we can't require a network connection for users installing the software, and without these files, the dependencies can end up installing non-functional software. I'm afraid I don't see any way out of this one. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#624398: xserver-xorg: postinst script wants to invoke-rc.d hal on GNU/kFreeBSD, but there is no more /etc/init.d/hal
Package: xserver-xorg Version: 1:7.6+6 Severity: normal trying to install xserver-xorg on this kFreeBSD system failed in the postinst script (attached) when trying to invoke-rc.d hal restart. I was able to push through without hal by prefixing that line of /var/lib/dpkg/info/xserver-xorg.postinst with a : But i'm not sure what the right thing to do is to really resolve the issue. /usr/share/doc/hal/changelog.Debian.gz notes that the hal maintainer removed the init script several months ago. Any thoughts on what the right thing to do is? --dkg -- Package-specific info: X server symlink status: lrwxr-xr-x 1 root root 13 Apr 28 02:07 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1782568 Mar 26 07:10 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 2.6.16 (d...@freebsd.org) (gcc version 4.3.5) #4 Sun Dec 18 04:30:00 CET 1977 Xorg X server log files on system: -- -rw-r--r-- 1 root root 44890 Apr 28 02:27 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [35.035] X.Org X Server 1.9.5 Release Date: 2011-03-17 [35.035] X Protocol Version 11, Revision 0 [35.035] Build Operating System: GNU/kFreeBSD 8.1-1-686 i686 Debian [35.035] Current Operating System: GNU/kFreeBSD loki 8.2-1-686 #0 Sat Feb 19 22:43:45 UTC 2011 i686 [35.036] Build Date: 26 March 2011 10:52:36AM [35.036] xorg-server 2:1.9.5-1 (Cyril Brulebois k...@debian.org) [35.036] Current version of pixman: 0.21.6 [35.036]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [35.036] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [35.036] (==) Log file: /var/log/Xorg.0.log, Time: Thu Apr 28 02:27:03 2011 [35.134] (==) Using system config directory /usr/share/X11/xorg.conf.d [35.159] (==) No Layout section. Using the first Screen section. [35.159] (==) No screen section available. Using defaults. [35.160] (**) |--Screen Default Screen Section (0) [35.160] (**) | |--Monitor default monitor [35.182] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [35.211] (==) Automatically adding devices [35.211] (==) Automatically enabling devices [35.419] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [35.419]Entry deleted from font path. [35.739] (WW) `fonts.dir' not found (or not valid) in /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType. [35.739]Entry deleted from font path. [35.739](Run 'mkfontdir' on /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType). [35.739] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [35.739] (==) ModulePath set to /usr/lib/xorg/modules [35.740] (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AutoAddDevices. [35.740] (II) Loader magic: 0x81f9040 [35.740] (II) Module ABI versions: [35.740]X.Org ANSI C Emulation: 0.4 [35.740]X.Org Video Driver: 8.0 [35.740]X.Org XInput driver : 11.0 [35.740]X.Org Server Extension : 4.0 [35.740] (--) PCI:*(0:0:2:0) 8086:2562:1028:0127 rev 1, Mem @ 0xf000/134217728, 0xffa0/524288, BIOS @ 0x/65536 [35.740] (II) LoadModule: extmod [35.915] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [35.971] (II) Module extmod: vendor=X.Org Foundation [35.971]compiled for 1.9.5, module version = 1.0.0 [35.971]Module class: X.Org Server Extension [35.971]ABI class: X.Org Server Extension, version 4.0 [35.971] (II) Loading extension MIT-SCREEN-SAVER [35.971] (II) Loading extension XFree86-VidModeExtension [35.971] (II) Loading extension XFree86-DGA [35.971] (II) Loading extension DPMS [35.971] (II) Loading extension XVideo [35.971] (II) Loading extension XVideo-MotionCompensation [35.971] (II) Loading extension X-Resource [35.971] (II) LoadModule: dbe [35.972] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [36.022] (II) Module dbe: vendor=X.Org Foundation [36.022]compiled for 1.9.5, module version = 1.0.0 [36.022]Module
Bug#624399: libtextcat: CVS directories in source
Package: libtextcat Version: 2.2-2 Severity: minor X-Debbugs-Cc: era+deb...@iki.fi lucid$ apt-get source libtextcat ... output as expected, getting version 2.2 ... lucid$ cd libtextcat-2.2 lucud$ find . -name CVS -ls 29246614 drwxr-xr-x 2 era era 4096 May 19 2003 ./langclass/ShortTexts/CVS 29245804 drwxr-xr-x 2 era era 4096 May 22 2003 ./langclass/LM/CVS 29245744 drwxr-xr-x 2 era era 4096 May 19 2003 ./langclass/CVS /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624351: ptrdiff_t is used without including the appropriate headers
Hi, i have checked it with my gcc (4.4.5-8) and find no problem. stddef.h is included from cstddef - bits/stl_algobase.h - algorithm - btree.h you using other compiler/STL maybe ? On Wed, Apr 27, 2011 at 10:16 PM, Philipp Klaus Krause p...@spth.de wrote: Package: stx-btree-dev Version: 0.8.3-3 ptrdiff_t is used in btree.h, but no header providing it is included, thus a program including btree headers, but not including stddef.h before it will fail: /usr/include/stx/btree.h:393:17: error: ‘ptrdiff_t’ does not name a type /usr/include/stx/btree.h:592:17: error: ‘ptrdiff_t’ does not name a type /usr/include/stx/btree.h:796:17: error: ‘ptrdiff_t’ does not name a type /usr/include/stx/btree.h:999:17: error: ‘ptrdiff_t’ does not name a type -- pub 1024D/E99AF373 pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624400: linux-image-2.6.32-5-amd64: Intel Ethernetcard does not work
Package: linux-image-2.6.32-5-amd64 Severity: normal There is a problem with the e1000e driver, the Intel cards Intel Corporation 82571EB Gigabit Ethnernet Controller (rev 06) dual port Intel Corporation 82574L Gigabit Ethnet Connection dual port both cards show up via lspci and dmesg but they cant get any link and they dont activate when a network cable gets plugged in. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624398: xserver-xorg: postinst script wants to invoke-rc.d hal on GNU/kFreeBSD, but there is no more /etc/init.d/hal
On Thu, Apr 28, 2011 at 03:01:32 -0400, Daniel Kahn Gillmor wrote: Package: xserver-xorg Version: 1:7.6+6 Severity: normal trying to install xserver-xorg on this kFreeBSD system failed in the postinst script (attached) when trying to invoke-rc.d hal restart. I was able to push through without hal by prefixing that line of /var/lib/dpkg/info/xserver-xorg.postinst with a : But i'm not sure what the right thing to do is to really resolve the issue. /usr/share/doc/hal/changelog.Debian.gz notes that the hal maintainer removed the init script several months ago. Any thoughts on what the right thing to do is? Bring the init script back, or give us another way to restart hal if it's running. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624397: xserver-xorg-input-synaptics: ALPS GlidePoint no longer working properly
On Wed, Apr 27, 2011 at 23:48:18 -0700, Ludovico Cavedon wrote: Package: xserver-xorg-input-synaptics Version: 1.4.0-1 Severity: normal Since a rencent update (but I cannot really tell if it was the kernel or the xserver-xorg-input-synaptics package, my touchpad stopped wrking properly. Vertical scrolling no loner works, and I am not able to change the touchpad settings. $ synclient Couldn't find synaptics properties. No synaptics driver loaded? gpointing-device-settings actually shows my tocuhpad, but all settings are to the minimum value and changing them has no effect. I read in other bug reports with similar issues that they fixed by reinstalling xserver-xorg-input-synaptics, but it did not help in my case. Looks like udev b0rkage to me. [24.500] (II) config/udev: Adding input device AlpsPS/2 ALPS GlidePoint (/dev/input/event2) [24.500] (**) AlpsPS/2 ALPS GlidePoint: Applying InputClass evdev keyboard catchall [24.500] (**) AlpsPS/2 ALPS GlidePoint: always reports core events [24.500] (**) AlpsPS/2 ALPS GlidePoint: Device: /dev/input/event2 [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found 3 mouse buttons [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found absolute axes [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found x and y absolute axes [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found absolute touchpad. [24.500] (II) AlpsPS/2 ALPS GlidePoint: Configuring as touchpad [24.500] (**) AlpsPS/2 ALPS GlidePoint: YAxisMapping: buttons 4 and 5 [24.500] (**) AlpsPS/2 ALPS GlidePoint: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [24.500] (II) XINPUT: Adding extended input device AlpsPS/2 ALPS GlidePoint (type: TOUCHPAD) [24.500] (II) AlpsPS/2 ALPS GlidePoint: initialized for absolute axes. It's being added as a keyboard (using the evdev driver) instead of a touchpad (using synaptics). Make sure you don't have a /run directory in your root filesystem. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624401: help2man: [INTL:de] Updated German translation
Package: help2man Version: 1.39.2 Severity: wishlist Tags: l10n Hi, please find attached the updated German translation of help2man. Kind regards, Chris # Translation of help2man to German # Copyright (C) 1997-2003 Free Software Foundation, Inc. # This file is distributed under the same license as the help2man package. # Chris Leick 2009, 2011 c.le...@vollbio.de. # msgid msgstr Project-Id-Version: help2man 1.39.2\n Report-Msgid-Bugs-To: Brendan O'Dea bug-help2...@gnu.org\n POT-Creation-Date: 2011-02-28 11:20+1100\n PO-Revision-Date: 2011-04-23 10:42+0100\n Last-Translator: Chris Leick c.le...@vollbio.de\n Language-Team: German debian-l10n-ger...@lists.debian.org\n Language: de\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #: help2man:69 #, perl-format msgid GNU %s %s\n \n Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2009, 2010,\n 2011 Free Software Foundation, Inc.\n This is free software; see the source for copying conditions. There is NO\n warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n \n Written by Brendan O'Dea b...@debian.org\n msgstr GNU %s %s\n \n Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2009, 2010\n 2011 Free Software Foundation, Inc.\n Dies ist freie Software. Lesen Sie die Quelle, um die Kopierbedingungen\n zu erhalten. Es gibt KEINE Gewährleistung, nicht einmal für\n MARKTGÃNGIGKEIT oder EIGNUNG FÃR SPEZIELLE ZWECKE.\n \n Geschrieben von Brendan O'Dea b...@debian.org\n #: help2man:80 #, perl-format msgid `%s' generates a man page out of `--help' and `--version' output.\n \n Usage: %s [OPTION]... EXECUTABLE\n \n -n, --name=STRING description for the NAME paragraph\n -s, --section=SECTION section number for manual page (1, 6, 8)\n -m, --manual=TEXT name of manual (User Commands, ...)\n -S, --source=TEXT source of program (FSF, Debian, ...)\n -L, --locale=STRING select locale (default \C\)\n -i, --include=FILE include material from `FILE'\n -I, --opt-include=FILE include material from `FILE' if it exists\n -o, --output=FILE send output to `FILE'\n -p, --info-page=TEXTname of Texinfo manual\n -N, --no-info suppress pointer to Texinfo manual\n -l, --libtool exclude the `lt-' from the program name\n --help print this help, then exit\n --version print version number, then exit\n \n EXECUTABLE should accept `--help' and `--version' options and produce output on\n stdout although alternatives may be specified using:\n \n -h, --help-option=STRING help option string\n -v, --version-option=STRING version option string\n --version-string=STRING version string\n --no-discard-stderr include stderr when parsing option output\n \n Report bugs to bug-help2...@gnu.org.\n msgstr »%s« generiert aus der Ausgabe von »--help« und »--version« eine\n Handbuchseite.\n \n Aufruf: %s [OPTION]... PROGRAMM\n \n -n, --name=ZEICHENKETTEBeschreibung für den NAME-Abschnitt\n -s, --section=ABSCHNITTAbschnittsnummer der Handbuchseite (1, 6, 8)\n -m, --manual=TEXT Name des Handbuchs (Anwenderbefehle, ...)\n -S, --source=TEXT Quelle des Programms (FSF, Debian, ...)\n -L, --locale=ZEICHENKETTE Locale auswählen (Vorgabe »C«)\n -i, --include=DATEIMaterial aus »DATEI« einbinden\n -I, --opt-include=DATEIMaterial aus »DATEI« einbinden, wenn es\n existiert\n -o, --output=DATEI in »DATEI« ausgeben\n -p, --info-page=DATEI Name des Texinfo-Handbuchs\n -N, --no-info Verweis auf Texinfo-Handbuch unterdrücken\n -l, --libtool das »lt-« aus dem Programmnamen ausschlieÃen\n --help diese Hilfe anzeigen, dann beenden\n --version Versionsnummer anzeigen, dann beenden\n \n PROGRAMM sollte »--help«- und »--version«-Optionen\n akzeptieren und eine Ausgabe auf der Standardausgabe (stdout) erzeugen,\n aber es können auch Alternativen angegeben werden:\n \n -h, --help-option=ZEICHENKETTE Hilfeoptionzeichenkette\n -v, --version-option=ZEICHENKETTE Versionsoptionzeichenkette\n --version-string=ZEICHENKETTE Versionszeichenkette\n --no-discard-stderrStandardfehlerausgabe (stderr) bei der\n Optionenanalyse einschlieÃen\n \n Berichten Sie Fehler an bug-help2...@gnu.org.\n #: help2man:164 #, perl-format msgid %s: can't open `%s' (%s) msgstr %s: »%s« kann nicht geöffnet werden (%s) #: help2man:225 #, perl-format msgid %s: no valid information found in `%s' msgstr %s: Keine gültigen Informationen in »%s« gefunden #: help2man:248 #, perl-format msgid %s: can't unlink %s (%s) msgstr %s: %s kann nicht entfernt werden (%s) #: help2man:252 #, perl-format msgid %s: can't create %s (%s) msgstr %s: %s kann nicht erzeugt werden (%s) #.
Bug#624402: ITP: xen-qemu-dm-4.1 -- Xen Qemu Device Model virtual machine hardware emulator
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: xen-qemu-dm-4.1 Version : 4.1.0 Upstream Author : Fabrice Bellard, Xen team, and others xen-de...@lists.xensource.com * URL : http://www.xen.org/ * License : BSD, GPL, GPL v2 or later, LGPL-2 Programming Lang: C Description : Xen Qemu Device Model virtual machine hardware emulator This package is the Xen version of the Qemu emulator especially patched for its hypervisor. With xen-qemu-dm, you can run a fully virtualized virtual machine if your hardware supports it (Intel VT support, or AMD-v technology). This is an updated package for version 4.1 of Xen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596144: Patch for the l10n upload of norwegian
Dear maintainer of norwegian,
On Tuesday, April 19, 2011 I sent you a notice announcing my intent to upload a
NMU of your package to fix its pending l10n issues, after an initial
notice sent on Sunday, April 17, 2011.
We finally agreed that you would do the update yourself at the end of
the l10n update round.
That time has come.
--Non standard text --
Tollef, no more new translation, indeed. Funnily, then, the only
translation to update is the Danish one, which is kida funny for a
package meant to install a Norwegian dictionary..:-)
Anyway, go ahead at your will now. Hopefully, I won't bother you in
the upcoming year about l10n stuff for this package..:-)
--End of non standard text ---
To help you out, here's the patch which I would have used for an NMU.
Please feel free to use all of it...or only the l10n part of it.
The corresponding changelog is:
Source: norwegian
Version: 2.0.10-3.3
Distribution: UNRELEASED
Urgency: low
Maintainer: Christian Perrier bubu...@debian.org
Date: Sun, 17 Apr 2011 08:42:00 +0200
Closes: 596144 623073
Changes:
norwegian (2.0.10-3.3) UNRELEASED; urgency=low
.
* Non-maintainer upload.
* Rebuild with new ispell. Closes: #623073
* Fix pending l10n issues. Debconf translations:
* Danish (Joe Hansen). Closes: #596144
--
diff -Nru norwegian-2.0.10.old/debian/changelog norwegian-2.0.10/debian/changelog
--- norwegian-2.0.10.old/debian/changelog 2011-04-12 05:51:29.314365676 +0200
+++ norwegian-2.0.10/debian/changelog 2011-04-18 08:11:44.220685464 +0200
@@ -1,3 +1,12 @@
+norwegian (2.0.10-3.3) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Rebuild with new ispell. Closes: #623073
+ * Fix pending l10n issues. Debconf translations:
+ * Danish (Joe Hansen). Closes: #596144
+
+ -- Christian Perrier bubu...@debian.org Sun, 17 Apr 2011 08:42:00 +0200
+
norwegian (2.0.10-3.2) unstable; urgency=low
* fix debian/myspell-nb.links, oops
diff -Nru norwegian-2.0.10.old/debian/control norwegian-2.0.10/debian/control
--- norwegian-2.0.10.old/debian/control 2011-04-12 05:51:29.982381496 +0200
+++ norwegian-2.0.10/debian/control 2011-04-18 08:12:26.213692406 +0200
@@ -2,12 +2,12 @@
Section: text
Priority: optional
Maintainer: Tollef Fog Heen tfh...@debian.org
-Build-Depends: debhelper (= 6), ispell, gawk, perl, aspell (= 0.60.3-2), dictionaries-common-dev (=0.20), po-debconf, gettext (= 0.11), hunspell-tools | myspell-tools
+Build-Depends: debhelper (= 6), ispell (= 3.3.02), gawk, perl, aspell (= 0.60.3-2), dictionaries-common-dev (=0.20), po-debconf, gettext (= 0.11), hunspell-tools | myspell-tools
Standards-Version: 3.8.1
Package: inorwegian
Architecture: any
-Depends: ${misc:Depends}, ispell, debconf | debconf-2.0, dictionaries-common
+Depends: ${misc:Depends}, ispell (= 3.3.02), debconf | debconf-2.0, dictionaries-common
Provides: ispell-dictionary
Description: Norwegian dictionary for ispell
This package provides the Norwegian dictionary, to be used with ispell
diff -Nru norwegian-2.0.10.old/debian/po/cs.po norwegian-2.0.10/debian/po/cs.po
--- norwegian-2.0.10.old/debian/po/cs.po 2011-04-12 05:51:28.650349962 +0200
+++ norwegian-2.0.10/debian/po/cs.po 2011-04-19 08:22:51.932806942 +0200
@@ -19,6 +19,7 @@
PO-Revision-Date: 2007-07-20 23:14+0200\n
Last-Translator: Miroslav Kure ku...@debian.cz\n
Language-Team: Czech debian-l10n-cz...@lists.debian.org\n
+Language: cs\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
diff -Nru norwegian-2.0.10.old/debian/po/da.po norwegian-2.0.10/debian/po/da.po
--- norwegian-2.0.10.old/debian/po/da.po 2011-04-12 05:51:28.650349962 +0200
+++ norwegian-2.0.10/debian/po/da.po 2011-04-17 08:42:37.381787925 +0200
@@ -1,28 +1,21 @@
-# translation of norwegian_2.0-13_da.po to Danish
-#
-#Translators, if you are not familiar with the PO format, gettext
-#documentation is worth reading, especially sections dedicated to
-#this format, e.g. by running:
-# info -n '(gettext)PO Files'
-# info -n '(gettext)Header Entry'
-#Some information specific to po-debconf are available at
-#/usr/share/doc/po-debconf/README-trans
-# or http://www.debian.org/intl/l10n/po-debconf/README-trans#
-#Developers do not need to manually edit POT or PO files.
+# Danish translation norwegian.
+# Copyright (C) 2010 norwegian nedenstående oversættere.
+# This file is distributed under the same license as the norwegian package.
# Claus Hindsgaul clau...@image.dk, 2004.
+# Joe Hansen joedalt...@yahoo.dk, 2010.
#
msgid
msgstr
-Project-Id-Version: norwegian_2.0-13_da\n
+Project-Id-Version: norwegian\n
Report-Msgid-Bugs-To: tfh...@debian.org\n
POT-Creation-Date: 2007-07-18 20:02+0200\n
-PO-Revision-Date: 2004-04-03 13:18+0200\n
-Last-Translator: Claus Hindsgaul clau...@image.dk\n
-Language-Team: Danish da...@klid.dk\n
+PO-Revision-Date: 2010-09-08 23:51+0200\n
+Last-Translator:
Bug#623281: qt4-x11: sh4: FTBFS: ./../include/QtCore/../../src/corelib/arch/qatomic_generic.h:197: error: invalid conversion from 'const void*' to 'void*'
tag 623281 + pending
thanks
Hi,
Alle giovedì 28 aprile 2011, Nobuhiro Iwamatsu ha scritto:
2011/4/28 Pino Toscano toscano.p...@tiscali.it:
Alle martedì 19 aprile 2011, Nobuhiro Iwamatsu ha scritto:
Because In the case of sh4, the architecture is set in 'generic',
and use src/corelib/arch/generic/.
Theorically qt4 should build with the 'generic' architecture.
OK, I misunderstood.
Determining system architecture...
(Linux:2.6.33.5-3-g0ef7fb0-dirty:sh4) Trying 'sh4'...
'sh4' is unsupported, using 'generic'
'sh4' is unsupported, using 'generic'
System architecture: 'generic'
[...]
I made patch to support sh4. Could you apply this patch?
Your patch is based on the code resulting after the qt4-x11 patch
07_trust_dpkg-arch_over_uname-m.diff, hence it is wrong.
Attached there is an attempt of better patch for sh4; could you
please try it?
Sure, and I tried. work fine with this patch.
Thanks for the fast testing!
The patch has been committed to the qt4-x11 debian packaging
repository[1], and will be in the next upload to unstable.
Also, please note that in qt4 there seems to be two sh
architectures, see the the src/corelib/arch/qatomic_{sh,sh4a}.h
and the two 'sh' and 'sh4a' directories in src/corelib/arch/; the
patch you did and the one I just attached use the 'sh' variant
(which I guess is the generic one for SH).
Yes, sh in qt4 supprt sh3 and sh4.
sh4a uses the order that sh do not support with these CPU's.
Your patch is right.
I see.
As also said in #623185, note that switching from 'generic' to the 'sh'
architecture is binary incompatible, so you will need to rebuilding
every package depending on libqtcore4 after the qt4-x11 upload carrying
this fix is uploaded.
[1] http://git.debian.org/?p=pkg-kde/qt/qt4-
x11.git;a=commit;h=23927e8cd13bfd0f8ec001c180aa0135c6f22b44
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#624148: asterisk-config: System goes down due to unattended-upgrades
On Mon, Apr 25, 2011 at 08:05:17PM -0500, John Goerzen wrote:
Package: asterisk-config
Version: 1:1.6.2.9-2+squeeze2
Severity: grave
Justification: renders package unusable
Thanks for your bugreport.
I use unattended-upgrades to provide security updates. This normally works
fine,
and although I expect that an upgrade might take down Asterisk for a few
minutes,
this took the system down and did not bring it back up. I'm going to guess
it was
related to this:
The code in unattended-upgrades should catch conffile changes like
this, so this looks like you hit a bug in that detection. Or the
asterisk package is modifiying by some out-of-band mechanism like in a
maintainer script. That case is not handled by u-n and the failure
below is to be expected (the program could do better by providing a
default answer, but its hard to pick a good default here :/).
What version of unattended-upgrades did you use? The regular 0.62.2
from squeeze?
Thanks,
Michael
Setting up asterisk-config (1:1.6.2.9-2+squeeze2) ...
Configuration file `/etc/asterisk/sip.conf'
== Modified (by you or by a script) since installation.
== Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** sip.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing
asterisk-config (--configure):
EOF on stdin at conffile prompt
I can't imagine why the shipped conffile would have had to change for a
security update.
And, indeed:
dpkg: dependency problems prevent configuration of asterisk:
asterisk depends on asterisk-config (= 1:1.6.2.9-2+squeeze2) |
asterisk-config-custom; however:
Package asterisk-config is not configured yet.
Package asterisk-config-custom is not installed.
dpkg: error processing asterisk (--configure):
dependency problems - leaving unconfigured
Setting up asterisk-doc (1:1.6.2.9-2+squeeze2) ...
configured to not write apport reports
Errors were encountered while processing:
asterisk-config
asterisk
Unattended-upgrades log:
Initial blacklisted packages:
Starting unattended upgrades script
Allowed origins are: [('Debian', 'stable'), ('Debian',
'squeeze-security')]
Packages that are upgraded: asterisk asterisk-config asterisk-doc
asterisk-sounds-main
Writing dpkg log to
'/var/log/unattended-upgrades/unattended-upgrades-dpkg_2011-04-25_16:35:07.929825.log'
Installing the upgrades failed!
error message: 'E:Sub-process /usr/bin/dpkg returned an error code (1)'
dpkg returned a error! See
'/var/log/unattended-upgrades/unattended-upgrades-dpkg_2011-04-25_16:35:07.929825.log'
for details
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
asterisk-config depends on no packages.
Versions of packages asterisk-config recommends:
pn asterisk none (no description available)
asterisk-config suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624398: xserver-xorg: postinst script wants to invoke-rc.d hal on GNU/kFreeBSD, but there is no more /etc/init.d/hal
Daniel Kahn Gillmor d...@fifthhorseman.net (28/04/2011): Any thoughts on what the right thing to do is? Alternatively to what Julien said, help with the first item on: http://blog.ikibiki.org/2011/02/21/DXN-6/ KiBi. signature.asc Description: Digital signature
Bug#624397: xserver-xorg-input-synaptics: ALPS GlidePoint no longer working properly
On 04/28/2011 12:15 AM, Julien Cristau wrote: On Wed, Apr 27, 2011 at 23:48:18 -0700, Ludovico Cavedon wrote: Looks like udev b0rkage to me. [24.500] (II) config/udev: Adding input device AlpsPS/2 ALPS GlidePoint (/dev/input/event2) [24.500] (**) AlpsPS/2 ALPS GlidePoint: Applying InputClass evdev keyboard catchall [24.500] (**) AlpsPS/2 ALPS GlidePoint: always reports core events [24.500] (**) AlpsPS/2 ALPS GlidePoint: Device: /dev/input/event2 [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found 3 mouse buttons [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found absolute axes [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found x and y absolute axes [24.500] (--) AlpsPS/2 ALPS GlidePoint: Found absolute touchpad. [24.500] (II) AlpsPS/2 ALPS GlidePoint: Configuring as touchpad [24.500] (**) AlpsPS/2 ALPS GlidePoint: YAxisMapping: buttons 4 and 5 [24.500] (**) AlpsPS/2 ALPS GlidePoint: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [24.500] (II) XINPUT: Adding extended input device AlpsPS/2 ALPS GlidePoint (type: TOUCHPAD) [24.500] (II) AlpsPS/2 ALPS GlidePoint: initialized for absolute axes. It's being added as a keyboard (using the evdev driver) instead of a touchpad (using synaptics). Uhm Make sure you don't have a /run directory in your root filesystem. Well, I actually did... I removed it and it fixed my issue! Thanks! I guess I should reassign this issue to udev, right? Is there any additional information that you think would be relevand for udev maintainers? Thanks, Ludovico -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624398: [Pkg-utopia-maintainers] Bug#624398: xserver-xorg: postinst script wants to invoke-rc.d hal on GNU/kFreeBSD, but there is no more /etc/init.d/hal
Am 28.04.2011 09:10, schrieb Julien Cristau:
On Thu, Apr 28, 2011 at 03:01:32 -0400, Daniel Kahn Gillmor wrote:
Package: xserver-xorg
Version: 1:7.6+6
Severity: normal
trying to install xserver-xorg on this kFreeBSD system failed in the
postinst script (attached) when trying to invoke-rc.d hal restart.
I was able to push through without hal by prefixing that line of
/var/lib/dpkg/info/xserver-xorg.postinst with a :
But i'm not sure what the right thing to do is to really resolve the issue.
/usr/share/doc/hal/changelog.Debian.gz notes that the hal maintainer
removed the init script several months ago.
Any thoughts on what the right thing to do is?
The right thing to do is making Xorg stop using hal on !linux.
Bring the init script back, or give us another way to restart hal if
it's running.
The hal init script will not be re-introduced.
If you want to see how hal handles (re)starting hald on upgrades, check the
postinst script, I basically does
get_pid() {
[ -n $1 ] || return 0
dbus-send --system --dest=org.freedesktop.DBus --print-reply \
/org/freedesktop/DBus
org.freedesktop.DBus.GetConnectionUnixProcessID \
string:$1 2/dev/null | awk '/uint32/ {print $2}'
}
# restart hald if it was running before
pid=$(get_pid org.freedesktop.Hal)
if [ -n $pid ]; then
kill $pid 2/dev/null || true
lshal /dev/null || true # will trigger through D-Bus activation
fi
The last step (triggering a hald start via D-Bus activation).
It was initially added for applications which used a buggy approach to check if
hald was running and disabled themselves otherwise, i.e. they didn't trigger a
D-Bus activation request.
All affected packages I know of have been fixed.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#608301: [Pkg-utopia-maintainers] Bug#608301: Reported upstream
Am 28.04.2011 07:36, schrieb Martin Steigerwald: report the issues I had about it - and then probably wait long till they get fixed. For example rejecting a hibernation cause an *unrelated, currently unused* kernel was upgraded IMHO is just far off what I would expect to be reasonable. As with some other solutions - IMHO Network Manager as well - I find it overengineered and too complex to be reliable in all contexts. Dude, please stop spreading your personal frustration and FUD in a completely unrelated bug report. It definitely doesn't belong there. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#624398: [Pkg-utopia-maintainers] Bug#624398: xserver-xorg: postinst script wants to invoke-rc.d hal on GNU/kFreeBSD, but there is no more /etc/init.d/hal
Am 28.04.2011 09:39, schrieb Michael Biebl: lshal /dev/null || true # will trigger through D-Bus activation fi The last step (triggering a hald start via D-Bus activation). ^ is probably no longer necessary today. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#624402: ITP: xen-qemu-dm-4.1 -- Xen Qemu Device Model virtual machine hardware emulator
On Thu, Apr 28, 2011 at 15:20:00 +0800, Thomas Goirand wrote: This is an updated package for version 4.1 of Xen. Updated packages don't need ITPs. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624403: libmodplug: FTBFS on all arches
Source: libmodplug Version: 1:0.8.8.2-2B Severity: serious https://buildd.debian.org/status/package.php?p=libmodplugsuite=unstable and http://buildd.debian-ports.org/status/package.php?p=libmodplugsuite=unstable please fix this. Konstantinos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616510: kdm or xserver crashes intermittently but often when interacting with screen saver unlock dialog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I get a similar crash, often when unlocking the screensaver. But it is the X server that crashes so it is probably not a KDE issue. There is a stack trace in the X.org log. I haven't been able to get a full trace with symbols. Some packages I am using: xserver-xorg-core 2:1.9.5-1 xserver-xorg-video-intel 2:2.15.0-1 libgl1-mesa-dri 7.10.2-1 [ 43165.424] Backtrace: [ 43165.730] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x4aacc8] [ 43165.730] 1: /usr/bin/Xorg (0x40+0x61e59) [0x461e59] [ 43165.730] 2: /lib/libpthread.so.0 (0x7fefaccf+0xef60) [0x7fefaccfef60] [ 43165.731] 3: /usr/lib/dri/i965_dri.so (0x7fefa900e000+0x85bfb) [0x7fefa9093bfb] [ 43165.731] 4: /usr/lib/dri/i965_dri.so (0x7fefa900e000+0x6d9f6) [0x7fefa907b9f6] [ 43165.731] 5: /usr/lib/dri/i965_dri.so (0x7fefa900e000+0x5c8ec) [0x7fefa906a8ec] [ 43165.731] 6: /usr/lib/dri/i965_dri.so (0x7fefa900e000+0x148892) [0x7fefa9156892] [ 43165.731] 7: /usr/lib/dri/i965_dri.so (0x7fefa900e000+0x1465dc) [0x7fefa91545dc] [ 43165.731] 8: /usr/lib/dri/i965_dri.so (0x7fefa900e000+0x1467aa) [0x7fefa91547aa] [ 43165.731] 9: /usr/lib/dri/i965_dri.so (0x7fefa900e000+0x21bc8e) [0x7fefa9229c8e] [ 43165.740] 10: /usr/lib/xorg/modules/extensions/libglx.so (0x7fefaa4a6000+0x32563) [0x7fefaa4d8563] [ 43165.740] 11: /usr/lib/xorg/modules/extensions/libglx.so (0x7fefaa4a6000+0x368a2) [0x7fefaa4dc8a2] [ 43165.740] 12: /usr/bin/Xorg (0x40+0x48909) [0x448909] [ 43165.740] 13: /usr/bin/Xorg (0x40+0x257ab) [0x4257ab] [ 43165.740] 14: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fefaba52c4d] [ 43165.740] 15: /usr/bin/Xorg (0x40+0x25339) [0x425339] [ 43165.741] Segmentation fault at address (nil) [ 43165.741] Fatal server error: [ 43165.741] Caught signal 11 (Segmentation fault). Server aborting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk25GXkACgkQXjXn6TzcAQnREACglhm+do1DPcd07+LEJWjv1p2f JIYAn2Xky8pxg5jPfxebR5yF9BWQ2/4+ =PF4w -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623702: [Pkg-nagios-devel] Bug#623702: nagios-plugins: check_host segfault on some sites
Hi, On Fri, Apr 22, 2011 at 02:12:08PM +0400, Max Kosmach wrote: check_host segfaults on www.google.ru /usr/lib/nagios/plugins/check_icmp -H www.google.ru OK - www.google.ru: rta 78.868ms, lost 0%|rta=78.868ms;200.000;500.000;0; pl=0%;40;80;; rtmax=79.730ms rtmin=78.445ms but /usr/lib/nagios/plugins/check_host -H www.google.ru Segmentation fault This happens when specifying a host-name that resolves to more than one IP. A fix is available in the sh/pu branch in my nagiosplug.git [1]. Cheers, Sebastian [1] http://git.tokkee.org/?p=nagiosplug.git;a=commit;h=2b01a46 or: https://github.com/tokkee/nagiosplug/tree/sh/pu -- Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Bug#624398: [Pkg-utopia-maintainers] Bug#624398: xserver-xorg: postinst script wants to invoke-rc.d hal on GNU/kFreeBSD, but there is no more /etc/init.d/hal
On Thu, Apr 28, 2011 at 09:39:14 +0200, Michael Biebl wrote:
The right thing to do is making Xorg stop using hal on !linux.
That's probably not going to happen this year.
Bring the init script back, or give us another way to restart hal if
it's running.
The hal init script will not be re-introduced.
Then hal needs to have Breaks on older xserver-xorg on kfreebsd.
If you want to see how hal handles (re)starting hald on upgrades, check the
postinst script, I basically does
get_pid() {
[ -n $1 ] || return 0
dbus-send --system --dest=org.freedesktop.DBus --print-reply \
/org/freedesktop/DBus
org.freedesktop.DBus.GetConnectionUnixProcessID \
string:$1 2/dev/null | awk '/uint32/ {print $2}'
}
# restart hald if it was running before
pid=$(get_pid org.freedesktop.Hal)
if [ -n $pid ]; then
kill $pid 2/dev/null || true
lshal /dev/null || true # will trigger through D-Bus activation
fi
The last step (triggering a hald start via D-Bus activation).
It was initially added for applications which used a buggy approach to check
if
hald was running and disabled themselves otherwise, i.e. they didn't trigger a
D-Bus activation request.
All affected packages I know of have been fixed.
Thanks, I'll try to work something out.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
tag 624354 + help moreinfo thanks On 04/28/2011 07:47 AM, Mike Hommey wrote: reassign 624354 binutils thanks On Wed, Apr 27, 2011 at 09:53:08PM +0200, Matthias Klose wrote: reassign 624354 xulrunner-1.9.1 thanks too easy. please make sure that all objects involved in the link are built with -fPIC. They are. Thank you I doubt it. For another example see: https://lists.debian.org/debian-powerpc/2010/06/msg00010.html Won't look at this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624387: grep: Incorrect bracket expression parsing with national locale
On 28/04/11 03:04, Igor O. Ladygin wrote: Grep from Lenny work successfully: $./grep -V GNU grep 2.5.3 Copyright (C) 1988, 1992-2002, 2004, 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $echo Пример|./grep -qE [Пп]ример; echo $? 0 Hi, Could you please try grep 2.7-2 from experimental? It solves some UTF and brakets-related issues. Thanks, Santiago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 09:53:58AM +0200, Matthias Klose wrote: tag 624354 + help moreinfo thanks On 04/28/2011 07:47 AM, Mike Hommey wrote: reassign 624354 binutils thanks On Wed, Apr 27, 2011 at 09:53:08PM +0200, Matthias Klose wrote: reassign 624354 xulrunner-1.9.1 thanks too easy. please make sure that all objects involved in the link are built with -fPIC. They are. Thank you I doubt it. Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. shows nothing at all, and in particular no reason for the reassignment. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614948: reopening 614948, notfixed 614948 in 6.01-3
reopen 614948 notfixed 614948 6.01-3 subscribe 614948 thanks Hello, The bug is still not fixed. I have an IPv6-only system, and here's what I get: $ HEAD 'http://[::1]/' 500 Can't connect to [::1]:80 (Bad hostname) Content-Type: text/plain Client-Date: Thu, 28 Apr 2011 07:55:12 GMT Client-Warning: Internal response $ HEAD 'http://ipv6.google.com/' 500 Can't connect to ipv6.google.com:80 (Bad hostname) Content-Type: text/plain Client-Date: Thu, 28 Apr 2011 07:55:18 GMT Client-Warning: Internal response $ HEAD 'http://google.com/' 500 Can't connect to google.com:80 (Network is unreachable) Content-Type: text/plain Client-Date: Thu, 28 Apr 2011 07:56:41 GMT Client-Warning: Internal response -- WBR, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624404: gnupg-agent: debian/copyright refers to non-accessible URL
Package: gnupg-agent Version: 2.0.17-2 Severity: minor debian/control reads: The current version was obtained from http://ftp.gnupg.org/GnuPG/gnupg/ Please udpate, as this returns: $ wget --server-response http://ftp.gnupg.org/GnuPG/gnupg/ --2011-04-28 11:06:36-- http://ftp.gnupg.org/GnuPG/gnupg/ Resolving ftp.gnupg.org... 217.69.76.55 Connecting to ftp.gnupg.org|217.69.76.55|:80... failed: Connection refused. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnupg-agent depends on: ii libassuan02.0.1-3IPC library for the GnuPG componen ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libgcrypt11 1.4.6-5LGPL Crypto library - runtime libr ii libgpg-error0 1.10-0.3 library for common error values an ii libpth20 2.0.7-16 The GNU Portable Threads ii libreadline6 6.1-3 GNU readline and history libraries ii pinentry-curses [pinentry]0.8.1-1curses-based PIN or pass-phrase en ii pinentry-gtk2 [pinentry] 0.8.1-1GTK+-2-based PIN or pass-phrase en Versions of packages gnupg-agent recommends: ii gnupg 1.4.11-3 GNU privacy guard - a free PGP rep gnupg-agent suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote:
On 04/28/2011 09:57 AM, Mike Hommey wrote:
Take the build log, remove all lines without -fPIC, you'll only get
lines for building binaries and objects that aren't linked into
libxul.so. QED.
shows nothing at all, and in particular no reason for the reassignment.
Another data point that I gave before: 3.5.17-1 built just fine, but
3.5.18-1 didn't. And attached here is the diff between both versions,
since you don't trust the maintainer telling you that the switch in the
toolchain is the likely culprit.
But, yeah, it's just easier to dismiss toolchain bugs.
diff --git a/.hgtags b/.hgtags
index e4d679e..c049fad 100644
--- a/.hgtags
+++ b/.hgtags
@@ -40,3 +40,7 @@ f7a9328d3fb6f1829858cb9774637bcb756ee29f UPDATE_PACKAGING_R7
4e2a6694987623bf43c83f2d0d161e5506431e1a UPDATE_PACKAGING_R11_1
d5eeb3c1521478207596dc753c0649ed2cf67ee2 FIREFOX_3_5_17_RELEASE
d5eeb3c1521478207596dc753c0649ed2cf67ee2 FIREFOX_3_5_17_BUILD1
+d5eeb3c1521478207596dc753c0649ed2cf67ee2 SEAMONKEY_2_0_12_BUILD1
+d5eeb3c1521478207596dc753c0649ed2cf67ee2 SEAMONKEY_2_0_12_RELEASE
+5a5dcb215b8d58a7b37c489ff5f5937acd0bc707 FIREFOX_3_5_18_RELEASE
+5a5dcb215b8d58a7b37c489ff5f5937acd0bc707 FIREFOX_3_5_18_BUILD1
diff --git a/browser/config/version.txt b/browser/config/version.txt
index c8e1136..cec4e41 100644
--- a/browser/config/version.txt
+++ b/browser/config/version.txt
@@ -1 +1 @@
-3.5.17
+3.5.18
diff --git a/config/milestone.txt b/config/milestone.txt
index 3f423a4..b7d5e54 100644
--- a/config/milestone.txt
+++ b/config/milestone.txt
@@ -10,4 +10,4 @@
# hardcoded milestones in the tree from these two files.
#
-1.9.1.17
+1.9.1.18
diff --git a/debian/changelog b/debian/changelog
index 557b468..6cbd2dc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+iceweasel (3.5.18-1) unstable; urgency=high
+
+ * New upstream release.
+ * mfsa2011-11: Update to HTTPS certificate blacklist.
+
+ -- Mike Hommey gland...@debian.org Wed, 23 Mar 2011 10:53:41 +0100
+
iceweasel (3.5.17-1) unstable; urgency=high
* New upstream release.
diff --git a/debian/control b/debian/control
index 882cbe0..e1aa468 100644
--- a/debian/control
+++ b/debian/control
@@ -55,7 +55,7 @@ Depends: ${shlibs:Depends},
fontconfig,
procps,
debianutils (= 1.16),
- xulrunner-1.9.1 (= 1.9.1.17)
+ xulrunner-1.9.1 (= 1.9.1.18)
Suggests: ttf-lyx | latex-xft-fonts,
xfonts-mathml,
ttf-mathematica4.1,
diff --git a/js/src/config/milestone.txt b/js/src/config/milestone.txt
index 3f423a4..b7d5e54 100644
--- a/js/src/config/milestone.txt
+++ b/js/src/config/milestone.txt
@@ -10,4 +10,4 @@
# hardcoded milestones in the tree from these two files.
#
-1.9.1.17
+1.9.1.18
diff --git a/security/manager/ssl/src/nsNSSCallbacks.cpp
b/security/manager/ssl/src/nsNSSCallbacks.cpp
index b2dc52e..3f0a221 100644
--- a/security/manager/ssl/src/nsNSSCallbacks.cpp
+++ b/security/manager/ssl/src/nsNSSCallbacks.cpp
@@ -75,6 +75,7 @@
#include cert.h
#include ocsp.h
#include nssb64.h
+#include secerr.h
static NS_DEFINE_CID(kNSSComponentCID, NS_NSSCOMPONENT_CID);
NSSCleanupAutoPtrClass(CERTCertificate, CERT_DestroyCertificate)
@@ -978,10 +979,70 @@ void PR_CALLBACK HandshakeCallback(PRFileDesc* fd, void*
client_data) {
PR_Free(signer);
}
+struct nsSerialBinaryBlacklistEntry
+{
+ unsigned int len;
+ const char *binary_serial;
+};
+
+// bug 642395
+static struct nsSerialBinaryBlacklistEntry myUTNBlacklistEntries[] = {
+ { 17, \x00\x92\x39\xd5\x34\x8f\x40\xd1\x69\x5a\x74\x54\x70\xe1\xf2\x3f\x43
},
+ { 17, \x00\xd8\xf3\x5f\x4e\xb7\x87\x2b\x2d\xab\x06\x92\xe3\x15\x38\x2f\xb0
},
+ { 16, \x72\x03\x21\x05\xc5\x0c\x08\x57\x3d\x8e\xa5\x30\x4e\xfe\xe8\xb0 },
+ { 17, \x00\xb0\xb7\x13\x3e\xd0\x96\xf9\xb5\x6f\xae\x91\xc8\x74\xbd\x3a\xc0
},
+ { 16, \x39\x2a\x43\x4f\x0e\x07\xdf\x1f\x8a\xa3\x05\xde\x34\xe0\xc2\x29 },
+ { 16, \x3e\x75\xce\xd4\x6b\x69\x30\x21\x21\x88\x30\xae\x86\xa8\x2a\x71 },
+ { 17, \x00\xe9\x02\x8b\x95\x78\xe4\x15\xdc\x1a\x71\x0a\x2b\x88\x15\x44\x47
},
+ { 17, \x00\xd7\x55\x8f\xda\xf5\xf1\x10\x5b\xb2\x13\x28\x2b\x70\x77\x29\xa3
},
+ { 16, \x04\x7e\xcb\xe9\xfc\xa5\x5f\x7b\xd0\x9e\xae\x36\xe1\x0c\xae\x1e },
+ { 17, \x00\xf5\xc8\x6a\xf3\x61\x62\xf1\x3a\x64\xf5\x4f\x6d\xc9\x58\x7c\x06
},
+ { 0, 0 } // end marker
+};
+
SECStatus PR_CALLBACK AuthCertificateCallback(void* client_data, PRFileDesc*
fd,
PRBool checksig, PRBool
isServer) {
nsNSSShutDownPreventionLock locker;
+ CERTCertificate *serverCert = SSL_PeerCertificate(fd);
+ if (serverCert
+ serverCert-serialNumber.data
+ !strcmp(serverCert-issuerName,
+CN=UTN-USERFirst-Hardware,OU=http://www.usertrust.com,O=The USERTRUST
Network,L=Salt Lake City,ST=UT,C=US)) {
+
+unsigned char
Bug#624382: transition: KDE SC 4.6
Hello, On ketvirtadienis 28 Balandis 2011 01:59:22 Modestas Vainius wrote: It's not very clear to me (personally) what to do with kdebindings but IMHO if possible, it's better to delay it sometime after this transition. This ugly beast links the whole distro together. Just to note: even if current kdebindings 4:4.4.5 was binNMUed and built fine against 4.6, it would definitely pick up dependency on at least new kdebase- workspace, kdegraphics and kdeedu. kdebindings links sip, python and mono together (and something else I don't remember now). P.S. It is fine to have kdebindings RC buggy in unstable or testing (it wouldn't be the first and the last time, really :-)). All that counts is that it did not end up blocking transitions. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#614948: why
Please read the tickets? This ticket was closed because it now applied to libnet-http-perl. This ticket was kept open for older versions because we may want to backport any fix to older versions. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624327: marked as done (dpkg-reconfigure keyboard-configuration silently dies)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/11 20:51, Debian Bug Tracking System wrote: On Wed, Apr 27, 2011 at 03:24:07PM +0200, Harald Dunkel wrote: Trying to configure several servers over network I noticed that dpkg-reconfigure keyboard-configuration silently dies, if no keyboard is attached to the PC. I suppose you don't mean that dpkg-reconfigure dies (i.e. exits with error) but that it simply exits without asking any questions. This is the intended behaviour - there is no point to configure a keyboard if there is no keyboard. There is no point to install the keyboard-configuration package for a machine without keyboard, either, so we can ignore this special case. The machines _do_ have a keyboard; its just not attached all the time. I can suggest four solutions for your problem: 1. Buy an active KVM switch. With an active KVM switch all computers will see a keyboard. Replacing the KVM as a workaround for a software problem is not an option right now. 2. Do not reconfigure remotely the keyboard. It is safer when a local operator does this because it is possible to test that the keyboard configuration works as intended. Traveling to the data center in Frankfurt (about 300km) just to configure the keyboard layout is not an option, either. 3. Edit /etc/default/keyboard by hand. You can use scp to copy the same file between the machines. This a lot easier than running dpkg-reconfigure on each machine. 4. Run dpkg-reconfigure on the computer that currently sees the keyboard from the KVM switch and then copy its /etc/default/keyboard to the other machines. You mean I should avoid running dpkg-reconfigure and configure the packages manually instead? I can do that for almost all packages, but actually I don't see why the postinst scripts shouldn't do their job. For the machines _with_ a local keyboard I could login via ssh and define a completely arbitrary keyboard mapping using dpkg-reconfigure. I don't know the internals of the postinst script that much, but it seems that this temporary hardware dependency can be dropped. I don't like keyboards with national settings either, but fact is that some people can type only with their favorite keyboard layout. Surely this is not a fatal problem, but it would be very nice if we could find a smart solution for this, instead of just closing this bug report. Many thanx Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk24+9UACgkQUTlbRTxpHjf5awCdGjZbCPFMeZLs0tBmzo3xSoCl 1bAAnjDwIUKyY6vN4XUTduSADV4knQQs =sGV0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On 04/28/2011 10:06 AM, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. shows nothing at all, and in particular no reason for the reassignment. Another data point that I gave before: 3.5.17-1 built just fine, but 3.5.18-1 didn't. And attached here is the diff between both versions, since you don't trust the maintainer telling you that the switch in the toolchain is the likely culprit. But, yeah, it's just easier to dismiss toolchain bugs. yes, it's easier for you this way. The toolchain may expose the bug; attaching a senseless debdiff doesn't help your argument. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. shows nothing at all, and in particular no reason for the reassignment. Another data point that I gave before: 3.5.17-1 built just fine, but 3.5.18-1 didn't. And attached here is the diff between both versions, since you don't trust the maintainer telling you that the switch in the toolchain is the likely culprit. But, yeah, it's just easier to dismiss toolchain bugs. I'll also add that the symbol for which the relocation is failing, _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm. But you're right, it's most probably not a toolchain problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608301: [Pkg-utopia-maintainers] Bug#608301: Reported upstream
Am Donnerstag, 28. April 2011 schrieb Michael Biebl: Am 28.04.2011 07:36, schrieb Martin Steigerwald: report the issues I had about it - and then probably wait long till they get fixed. For example rejecting a hibernation cause an *unrelated, currently unused* kernel was upgraded IMHO is just far off what I would expect to be reasonable. As with some other solutions - IMHO Network Manager as well - I find it overengineered and too complex to be reliable in all contexts. Dude, please stop spreading your personal frustration and FUD in a completely unrelated bug report. It definitely doesn't belong there. Sorry, its not easy to concentrate just on the facts for the bug report at times when software just doesn't work for me. I do spend much time on detailed bug reports and most of my post you refer to was constructive. I reported the issue upstream! And there detailed feedback would be more approbiate. Yes, I am frustrated with the situation at times. Actually cause it seems I have to use Network Manager in order for quite some KDE application to properly detect online status. I tried wicd, but the gtk gui of it didn't respond to mouse clicks at all. When I would have found an alternative to network manager actually I think I would be using it already. I think its understandable that I am frustrated. Its understandable that you are frustrated as well given the long list of unresolved bug reports for network manager. But if you insist on taking just the frustration, and not the constructive feedback I provided, then thats your choice. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#624405: libkdcraw8: dcraw - new upstream available
Package: libkdcraw8 Version: 4:4.4.5-2 Severity: wishlist Tags: upstream There's a newer upstream version of dcraw available which would support my camera (Canon EOS 550D). Please consider rebuilding against the newer dcraw. Thanks, Karsten -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libkdcraw8 depends on: ii kdegraphics-libs-data 4:4.4.5-2data files for libraries from the ii libc6 2.11.2-11Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-2GCC support library ii libgomp14.6.0-2 GCC OpenMP (GOMP) support library ii libkdecore5 4:4.4.5-4the KDE Platform Core Library ii libkdeui5 4:4.4.5-4the KDE Platform User Interface Li ii libkio5 4:4.4.5-4the Network-enabled File Managemen ii liblcms11.18.dfsg-1.2+b3 Color management library ii libqtcore4 4:4.7.2-3Qt 4 core module ii libqtgui4 4:4.7.2-3Qt 4 GUI module ii libstdc++6 4.6.0-2 The GNU Standard C++ Library v3 libkdcraw8 recommends no packages. libkdcraw8 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624406: udt: FTBFS on many arches
Source: udt Version: 4.8-1 Severity: serious https://buildd.debian.org/status/package.php?p=libmodplugsuite=unstable and http://buildd.debian-ports.org/status/package.php?p=libmodplugsuite=unstable please fix this. Konstantinos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623719: nmu: Please bin nmu the following for a SONAME bump of libmuparser
On Fri, Apr 22, 2011 at 15:57:25 +0200, Mehdi Dogguy wrote: But, there is an issue with getfem++: It build depends on scilab-include which is not available everywhere: scilab-include | 5.3.1-3 | wheezy | amd64, armel, i386, ia64, mipsel, powerpc, s390, sparc scilab-include | 5.3.1-4 | sid | amd64, armel, i386, ia64, mipsel, powerpc, s390, sparc So, it's stuck on kfreebsd-* and mips (at least) and, thus, needs to be fixed. FWIW, csound and koffice build depend on libgmm++-dev. britney doesn't care about build-deps, though, so removing getfem++ temporarily would work, I think? Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624407: lcdproc: FTBFS on many arches
Source: lcdproc Version: 0.5.4-4 Severity: serious https://buildd.debian.org/status/package.php?p=lcdprocsuite=unstable and http://buildd.debian-ports.org/status/package.php?p=lcdprocsuite=unstable please fix this. Konstantinos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624010: udev: system does not boot because of inactivated lvm root device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Marco, Am Di den 26. Apr 2011 um 14:33 schrieb Marco d'Itri: You can checkout the GIT tree and look at them with gitk, I would like to do so but I find no git repository of udev. There is no vcs line in the package so »debcheckout udev« do not work. Gruß Klaus - -- Klaus Ethgenhttp://www.ethgen.ch/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTbkmYJ+OKpjRpO3lAQrhDAf9Gc4rMMUHFQGti5LHS2XC0829AeJmsjIO JTalnkkwNVqLqH1p6leZr0YiJujYsAht1DVAhbi8YB0wmyHlMV03Wqt7bvale5U1 gwKquXvhb8AfTBShXu5GjoLBoVCHi2QXAwk5immcM1PGdrWL2sLicGx3XHbRowov SqiY52Yrq7E+O00TpDeODzqsnGtlJpzqtQYOpJUoSEUZ29RdhhVMfCKhq996S5NS D3MEjBxkJjtXL4h9mX5V15lX67Vrk6fjSF18IQKUZg1MJMR0S0+Hohw3O322bgUy ZECY1UGcVwUeM7U6z+o7C7/0F3ZVoLRBTgXHwHEbAkCSNXorlbBmdQ== =7tk3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624406: Acknowledgement (udt: FTBFS on many arches)
apologies, the correct URLs are these: http://buildd.debian-ports.org/status/package.php?p=udtsuite=unstable and https://buildd.debian.org/status/package.php?p=udtsuite=unstable Regards Konstantinos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624408: golang: Don't migrate to testing [maintainer request]
Package: golang Severity: serious Tags: sid, wheezy Placeholder bug to stop golang from migrating to testing distribution. The APIs are not stable yet to be supported in the stable distribution. O. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624409: raul FTBFS on kfreebsd-amd64
Package: raul Version: 0.8.0-0.1 Severity: important Tags: experimental Hi, raul fails to build on kfreebsd-amd64 maybe due to a bug of doxygen. We may solve this by preventing docs from being built from source, I'll provide a patch soon. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623719: nmu: Please bin nmu the following for a SONAME bump of libmuparser
On 04/28/2011 10:29 AM, Julien Cristau wrote: On Fri, Apr 22, 2011 at 15:57:25 +0200, Mehdi Dogguy wrote: But, there is an issue with getfem++: It build depends on scilab-include which is not available everywhere: scilab-include | 5.3.1-3 | wheezy | amd64, armel, i386, ia64, mipsel, powerpc, s390, sparc scilab-include | 5.3.1-4 | sid | amd64, armel, i386, ia64, mipsel, powerpc, s390, sparc So, it's stuck on kfreebsd-* and mips (at least) and, thus, needs to be fixed. FWIW, csound and koffice build depend on libgmm++-dev. britney doesn't care about build-deps, though, so removing getfem++ temporarily would work, I think? Sure. I was just hoping/waiting for a comment from Scott. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624410: vxl: FTBFS on armel
Package: vxl Severity: important Tags: upstream vxl fails to build on armel with the following errors: [ 79%] Building CXX object contrib/brl/bpro/bprb/CMakeFiles/bprb.dir/Templates/vbl_smart_ptr+bprb_parameters-.o [ 79%] Building CXX object contrib/brl/bpro/bprb/CMakeFiles/bprb.dir/Templates/bprb_parameters+bprb_filepath-.o Linking CXX shared library ../../../../lib/libbprb.so CMakeFiles/bprb.dir/Templates/bprb_parameters+unsigned_int-.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for bprb_param_typeunsigned int' CMakeFiles/bprb.dir/Templates/bprb_parameters+unsigned-.o:(.data.rel.ro+0x0): first defined here CMakeFiles/bprb.dir/Templates/bprb_parameters+unsigned_int-.o:(.rodata+0x0): multiple definition of `typeinfo name for bprb_param_typeunsigned int' CMakeFiles/bprb.dir/Templates/bprb_parameters+unsigned-.o:(.rodata+0x0): first defined here collect2: ld returned 1 exit status make[3]: *** [lib/libbprb.so] Error 1 make[3]: Leaving directory `/build/buildd-vxl_1.14.0-5-armel-6R8nux/vxl-1.14.0/Build' make[2]: *** [contrib/brl/bpro/bprb/CMakeFiles/bprb.dir/all] Error 2 make[1]: *** [all] Error 2 make: *** [debian/stamp-makefile-build] Error 2 make[2]: Leaving directory `/build/buildd-vxl_1.14.0-5-armel-6R8nux/vxl-1.14.0/Build' make[1]: Leaving directory `/build/buildd-vxl_1.14.0-5-armel-6R8nux/vxl-1.14.0/Build' -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624411: xfce4-netload-plugin: FTBFS on kfreebsd
Package: xfce4-netload-plugin Version: 1.0.0-2 Severity: serious Justification: fails to build from source (but built successfully in the past) See https://buildd.debian.org/status/package.php?p=xfce4-netload-plugin Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624412: ITP: libscythestat -- Scythe Statistical C++ Library
Package: wnpp Severity: wishlist Owner: Steffen Moeller steffen_moel...@gmx.de * Package name: libscythestat Version : 1.0.2 * URL : http://scythe.wustl.edu/ * License : GPL Programming Lang: C++ Description : Scythe Statistical C++ Library From their home page: The Scythe Statistical Library is an open source C++ library for statistical computation, written by Daniel Pemstein (Harvard University and University of Illinois), Kevin M. Quinn (UC Berkeley), and Andrew D. Martin (Washington University). It includes a suite of matrix manipulation functions, a suite of pseudo-random number generators, and a suite of numerical optimization routines. Programs written using Scythe are generally much faster than those written in commonly used interpreted languages, such as R and MATLAB, and can be compiled on any system with the GNU GCC compiler (and perhaps with other C++ compilers). One of the primary design goals of the Scythe developers has been ease of use for non-expert C++ programmers. We provide ease of use through three primary mechanisms: (1) operator and function over-loading, (2) numerous pre-fabricated utility functions, and (3) clear documentation and example programs. Additionally, Scythe is quite flexible and entirely extensible because the source code is available to all users under the GNU General Public License. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624413: thunar-volman: Unbuildable on kfreebsd (wrong build-dep on libgudev)
Package: thunar-volman Version: 0.6.0-3 Severity: serious Justification: fails to build from source (but built successfully in the past) libgudev is Linux-only. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624414: changes in squeeze affecting a smooth NFS upgrade/use
Package: release-notes Severity: normal Hi I keep telling me I should write something that could be included into the Release Notes about things people should be aware of when using NFS in squeeze. Instead of trying to have a coherent text I'll just list some topics: - default NFS uses version 4 in squeeze, one can work around failures to mount because of this by mentioning the -vers=3 option explicitly when mounting (or in fstab) - when using Kerberos default encryption has changed, one can work around it by specifying an older encryption type explicitly (-sec=...) when mounting - the chance that NFS related daemons are not started at boot are increased both for NFS clients as well as NFS servers, can be worked round by restarting portmap (or rpcbind), nfs-common and nfs-kernel-server in that order for the ones that are installed - NFSv4 needs the idmap daemon to be started, can be worked around by updating /etc/default/nfs-common (and /etc/default/nfs-kernel-server) to have NEED_IDMAPD=yes and restart nfs-common (and nfs-kernel-server) - for switching the server exports to NFSv4 one needs to specify a root of all exported filesystems specified by including the fsid=0 (or fsid=root) option, one does not need to specify fsid for any other exported filesystem unless it has no uuid (in that case use a small integer that will be used like the uuid) Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 10:15:00AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. shows nothing at all, and in particular no reason for the reassignment. Another data point that I gave before: 3.5.17-1 built just fine, but 3.5.18-1 didn't. And attached here is the diff between both versions, since you don't trust the maintainer telling you that the switch in the toolchain is the likely culprit. But, yeah, it's just easier to dismiss toolchain bugs. I'll also add that the symbol for which the relocation is failing, _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm. But you're right, it's most probably not a toolchain problem. Even better, if I download xulrunner-1.9.1_1.9.1.18-1_powerpc.deb and take a look at the relocations in libxul.so, I can't even find the relocation ld.so is complaining about. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624415: opt: debian/copyright non-existing URL
Package: opt Version: 3.19-1.1 Severity: minor debian/copyright reads: It was downloaded from http://nis-www.lanl.gov/~jt/Software/opt/ This URL no longer responds. Please add comment: As of 2011-04-28 the URL is no longer available. Or update the URL to reflect more recent location. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624416: RM: ladcca -- RoQA; buggy; superseeded; abandoned upstream; orphaned
Package: ftp.debian.org Severity: normal Hi, ladcca is unuseful at all: upstream moved efforts from it to lash at first, and then now to ladish. So please, remove ladcca from Debian sid. Thanks in advance, Alessio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624417: rhythmbox: radio support fails with TypeError: Couldn't find conversion for foreign struct 'cairo.Context'
Package: rhythmbox Version: 2.90.1~20110329-1 Severity: important Hi, trying to listen to an online radio, I'm getting this: | $ rhythmbox | | (rhythmbox:8040): Gtk-WARNING **: GTK+ module /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so cannot be loaded. | GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported. | Gtk-Message: Failed to load module canberra-gtk-module | GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. | | (rhythmbox:8040): Rhythmbox-WARNING **: Unable to start mDNS browsing: MDNS service is not running | | (rhythmbox:8040): libdmapsharing-WARNING **: Unable to initialize mDNS: Daemon not running | | (rhythmbox:8040): libdmapsharing-WARNING **: Unable to notify network of media sharing: The avahi MDNS service is not running | | (rhythmbox:8040): libdmapsharing-WARNING **: Unable to start Remote lookup: MDNS service is not running | | (rhythmbox:8040): Rhythmbox-WARNING **: Unable to grab media player keys: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SettingsDaemon was not provided by any .service files *clicking on the online radio happens here* | (rhythmbox:8040): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed | | (rhythmbox:8040): Rhythmbox-WARNING **: Couldn't find an x overlay | TypeError: Couldn't find conversion for foreign struct 'cairo.Context' | Segmentation fault I guess a backtrace isn't really needed, the TypeError is likely to be the initial culprit here? KiBi. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/6 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rhythmbox depends on: ii dbus 1.4.8-2 simple interprocess messaging syst ii gconf2 2.32.1-2 GNOME configuration database syste ii gnome-icon-theme 2.30.3-2 GNOME Desktop icon theme ii gstreamer0.10-alsa [gs 0.10.32-2 GStreamer plugin for ALSA ii gstreamer0.10-plugins- 0.10.32-2 GStreamer plugins from the base ii gstreamer0.10-plugins- 0.10.28-3 GStreamer plugins from the good ii gstreamer0.10-x0.10.32-2 GStreamer plugins for X11 and Pang ii libatk1.0-02.0.0-1 The ATK accessibility toolkit ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib ii libcairo-gobject2 1.10.2-6 The Cairo 2D vector graphics libra ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libdbus-1-31.4.8-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.92-1simple interprocess messaging syst ii libffi53.0.9-4 Foreign Function Interface library ii libfontconfig1 2.8.0-2.2 generic font configuration library ii libfreetype6 2.4.4-1 FreeType 2 font engine, shared lib ii libgconf2-42.32.1-2 GNOME configuration database syste ii libgdk-pixbuf2.0-0 2.23.3-3 GDK Pixbuf library ii libgirepository-1.0-1 0.10.7-1 Library for handling GObject intro ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgnome-media-profile 2.91.2-4 GNOME Media Profiles library ii libgstreamer-plugins-b 0.10.32-2 GStreamer libraries from the base ii libgstreamer0.10-0 0.10.32-6 Core GStreamer libraries and eleme ii libgtk-3-0 3.0.8-1 The GTK+ graphical user interface ii libice62:1.0.7-1 X11 Inter-Client Exchange library ii libpango1.0-0 1.28.3-6 Layout and rendering of internatio ii libpython2.6 2.6.6-10 Shared Python runtime library (ver ii librhythmbox-core4 2.90.1~20110329-1 support library for the rhythmbox ii libsm6 2:1.2.0-1 X11 Session Management library ii libsoup-gnome2.4-1 2.34.0-1 HTTP library implementation in C - ii libsoup2.4-1 2.34.0-1 HTTP library implementation in C - ii libtotem-plparser172.32.4-3 Totem Playlist Parser library - ru ii libxml22.7.8.dfsg-2+b1 GNOME XML library ii media-player-info 14-1 Media player identification files ii python-gobject 2.28.3-3 Python bindings for the GObject li ii python-gst0.10 0.10.21-2 generic media-playing framework (P ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages rhythmbox recommends: pn avahi-daemon none(no description available) pn gstreamer0.10-plugins- none
Bug#624418: modprobe fuse failed on Unknown symbol kstrtoull
Package: linux-2.6 Version: 2.6.38-4 Severity: normal When attempting to modprobe fuse (needed for ntfs-3g), it fails on kernel 2.6.38-2, leaving one line with error message in dmesg: [17105.390564] fuse: Unknown symbol kstrtoull (err 0) I tried reinstalling the kernel package (apt-get install --reinstall ...) to rule out possibility of the file being somehow replaced by some other version, but problem persisted. # modprobe fuse WARNING: All config files need .conf: /etc/modprobe.d/00local, it will be ignored in a future release. FATAL: Error inserting fuse (/lib/modules/2.6.38-2-amd64/kernel/fs/fuse/fuse.ko): Unknown symbol in module, or unknown parameter (see dmesg) # dmesg | tail [17105.390564] fuse: Unknown symbol kstrtoull (err 0) -- Package-specific info: ** Version: Linux version 2.6.38-2-amd64 (Debian 2.6.38-3) (b...@decadent.org.uk) (gcc version 4.4.5 (Debian 4.4.5-15) ) #1 SMP Thu Apr 7 04:28:07 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.38-2-amd64 root=/dev/mapper/sda5_crypt ro quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [16985.776538] Booting Node 0 Processor 3 APIC 0x3 [16985.868026] Switched to NOHz mode on CPU #3 [16985.894688] NMI watchdog enabled, takes one hw-pmu counter. [16985.896182] CPU3 is up [16985.899688] ACPI: Waking up from system sleep state S3 [16986.374227] i915 :00:02.0: restoring config space at offset 0xf (was 0x100, writing 0x10a) [16986.374253] i915 :00:02.0: restoring config space at offset 0x7 (was 0x0, writing 0x9030) [16986.374270] i915 :00:02.0: restoring config space at offset 0x6 (was 0x8, writing 0x8008) [16986.374286] i915 :00:02.0: restoring config space at offset 0x5 (was 0x1, writing 0x30b1) [16986.374303] i915 :00:02.0: restoring config space at offset 0x4 (was 0x0, writing 0x9048) [16986.374320] i915 :00:02.0: restoring config space at offset 0x1 (was 0x90, writing 0x900407) [16986.374374] pci :00:02.1: restoring config space at offset 0x4 (was 0x0, writing 0x9040) [16986.374392] pci :00:02.1: restoring config space at offset 0x1 (was 0x90, writing 0x97) [16986.374500] pcieport :00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x10a) [16986.374527] pcieport :00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x90719061) [16986.374545] pcieport :00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0x90209020) [16986.374562] pcieport :00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0x4040) [16986.374580] pcieport :00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x10100) [16986.374601] pcieport :00:1c.0: restoring config space at offset 0x3 (was 0x81, writing 0x810010) [16986.374621] pcieport :00:1c.0: restoring config space at offset 0x1 (was 0x10, writing 0x100407) [16986.374701] pcieport :00:1c.3: restoring config space at offset 0xf (was 0x400, writing 0x40b) [16986.374727] pcieport :00:1c.3: restoring config space at offset 0x9 (was 0x10001, writing 0x90919081) [16986.374745] pcieport :00:1c.3: restoring config space at offset 0x8 (was 0x0, writing 0x90109010) [16986.374763] pcieport :00:1c.3: restoring config space at offset 0x7 (was 0x0, writing 0x2020) [16986.374780] pcieport :00:1c.3: restoring config space at offset 0x6 (was 0x0, writing 0x20200) [16986.374801] pcieport :00:1c.3: restoring config space at offset 0x3 (was 0x81, writing 0x810010) [16986.374821] pcieport :00:1c.3: restoring config space at offset 0x1 (was 0x10, writing 0x100407) [16986.374889] uhci_hcd :00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a) [16986.374917] uhci_hcd :00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x3081) [16986.374945] uhci_hcd :00:1d.0: restoring config space at offset 0x1 (was 0x280, writing 0x281) [16986.374980] uhci_hcd :00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20a) [16986.375008] uhci_hcd :00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x3061) [16986.375036] uhci_hcd :00:1d.1: restoring config space at offset 0x1 (was 0x280, writing 0x281) [16986.375070] uhci_hcd :00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30a) [16986.375098] uhci_hcd :00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x3041) [16986.375127] uhci_hcd :00:1d.2: restoring config space at offset 0x1 (was 0x280, writing 0x281) [16986.375172] uhci_hcd :00:1d.3: restoring config space at offset 0xf (was 0x400, writing 0x40b) [16986.375202] uhci_hcd :00:1d.3: restoring config space at offset 0x8 (was 0x1, writing 0x3021) [16986.375231] uhci_hcd :00:1d.3: restoring config space at offset 0x1 (was 0x280, writing 0x281) [16986.375277] ehci_hcd :00:1d.7:
Bug#624411: [Pkg-xfce-devel] Bug#624411: xfce4-netload-plugin: FTBFS on kfreebsd
reassign 624411 kfreebsd-kernel-headers forcemerge 621820 624411 affects 621820 xfce4-netload-plugin thanks On jeu., 2011-04-28 at 10:43 +0200, Julien Cristau wrote: Package: xfce4-netload-plugin Version: 1.0.0-2 Severity: serious Justification: fails to build from source (but built successfully in the past) See https://buildd.debian.org/status/package.php?p=xfce4-netload-plugin See #621820 and the discussion there. -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624405: closed by Modestas Vainius mo...@debian.org (Re: Bug#624405: libkdcraw8: dcraw - new upstream available)
It has been closed by Modestas Vainius mo...@debian.org. There's a newer upstream version of dcraw available which would support my camera (Canon EOS 550D). Please consider rebuilding against the newer dcraw. You probably mean 4.6.2, don't you? It's in experimental like the rest of KDE SC 4.6.2. No, I did not mean that. Nevertheless, your suggestion is a reasonable tradeoff. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624419: RM: cyrus-imapd-2.2/2.2.13p1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove cyrus-imapd-2.2 from testing, we plan to remove it from unstable and replace it by cyrus-imapd-2.4 in the future, but we want to do it gradually and test the migration path. There's already RC placeholder bug #623132 to keep it from entering testing again. Thank you very much, O. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604174: ITP: mysql-workbench-gpl -- MySQL Database diagramming and development tool
On Wed, Apr 13, 2011 at 11:29:35AM +0200, Sandro Tosi wrote: Hi Norber On Thu, Dec 23, 2010 at 10:01, Norbert Tretkowski norb...@tretkowski.de wrote: we're already working on a package, the current state is available in our Subversion repository: http://svn.debian.org/wsvn/pkg-mysql/mysql-workbench/trunk/ I saw you keep updating this repo, which is nice, but I'd like to understand what's missing to upload it to unstable: is there something that needs to be done? can I help you somehow? I was wondering the same myself and I found this email: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2011-March/003368.html :( Some of the problems listed at: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2011-March/003367.html could be solved with repackaging and removing all that stuff that isn't required in Linux. But still 'combing' all the code and addressing all the remaining issues would take some time. Ana -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624327: marked as done (dpkg-reconfigure keyboard-configuration silently dies)
On Thu, Apr 28, 2011 at 07:32:11AM +0200, Harald Dunkel wrote: There is no point to install the keyboard-configuration package for a machine without keyboard, either, so we can ignore this special case. The machines _do_ have a keyboard; its just not attached all the time. I am not sure this is a special case. Yes, it makes no sense to manually install keyboard-configuration on a headless machine but there can be some other reasons that cause keyboard-configuration to be automatically installed. It is not difficult to change the configure script to always ask the questions (regardless of whether there is a keyboard or not). If the developers at debian-b...@lists.debian.org think this is desirable I can make the required changes. 3. Edit /etc/default/keyboard by hand. You can use scp to copy the same file between the machines. This a lot easier than running dpkg-reconfigure on each machine. 4. Run dpkg-reconfigure on the computer that currently sees the keyboard from the KVM switch and then copy its /etc/default/keyboard to the other machines. You mean I should avoid running dpkg-reconfigure and configure the packages manually instead? I can do that for almost all packages Dpkg-reconfigure is not meant to handle all possible configurations of a package. In non-standard situations the user always has to configure the package manually. But I believe the solutions I proposed are even easier than running dpkg-reconfigure on all machines. Method 4 allows you to use dpkg-reconfigure if you wish -- you can run dpkg-reconfigure on any machine with a keyboard and copy its /etc/default/keyboard to all machines with no keyboard (this can be one of the computers connected to the KVM switch or, if you wish, this can be even your local computer with possibly different version of keyboard-configuration). actually I don't see why the postinst scripts shouldn't do their job. [...] I don't know the internals of the postinst script that much, but it seems that this temporary hardware dependency can be dropped. Yes, it is easy to drop this dependency and if the members of debian-boot@lists.d.o suggest, I will make the required changes. I suppose there is no way to differentiate between a headless machine and a machine that is only temporarily without a keyboard. Thats why it seems undesirable to ask keyboard questions on computers with no keyboard. I don't like keyboards with national settings either, but fact is that some people can type only with their favorite keyboard layout. Surely this is not a fatal problem, but it would be very nice if we could find a smart solution for this, instead of just closing this bug report. Isn't it easier to scp /etc/default/keyboard that to run dpkg-reconfigure on each machine and answer many times the same questions? Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624413: [Pkg-xfce-devel] Bug#624413: thunar-volman: Unbuildable on kfreebsd (wrong build-dep on libgudev)
clone 624413 -1 -2 reassign -1 ftp.debian.org retitle -1 RM: thunar-volman [kfreebsd-i386 kfreebsd-amd64 hurd-i386] -- ANAIS; Now Linux only severity -1 normal reassign -2 buildd.debian.org retitle -2 [p-a-s] please blacklist thunar-volman from non Linux arches severity -2 normal thanks On jeu., 2011-04-28 at 10:45 +0200, Julien Cristau wrote: Package: thunar-volman Version: 0.6.0-3 Severity: serious Justification: fails to build from source (but built successfully in the past) libgudev is Linux-only. Yes, sadly thunar-volman is now Linux only. I hope that won't last but that's the current state. I'll make an upload specifying Architecture: linux-any but aiui it needs special action from ftpmasters and buildd admins so cloning and reassigning. Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622888: lintian overrides should support more precise pattern matching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2011-04-25 18:17, Niels Thykier wrote: Hi Hi all, Andreas, I might have failed to CC on my previous mail to #622888 (just a heads up if you do not recognise the quote). I have looked a bit on this and ... [...] So, I am proposing the following solution: * Allow * anywhere in extra to match any characters - possibly use ** as any character and * as any non-slash character - Text::Glob does not quote work for this, but a hand-crafted glob2regex should not be hard if it is only * (and **) with no escape (that is no \* = literal *). * Allow type + architecture specific tags in override files. Lintian should ignore all overrides not for this type and architecture. - Absence of type or architecture should be assumed to be current type/architecture (status quo) - architecture can be any valid Debian architecture including the currently accepted wild-cards (e.g. linux-any etc.)[1] - I have a partly patch for this; it does not recognise wildcards nor does it check for unknown/invalid architectures. The syntax is the same as the B-D field. Overrides will look like this: [[name][ \[arch-pattern\]][ type]:] tag[ extra ...] (I have cleverly stolen the proposal of both Steve + Andreas, reworded to my own proposal and totally claim credit for it .) [...] ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNuS/rAAoJEAVLu599gGRCh+gP/3Tfb/hypav4vIV0/ko/xmor hFP3impoHXp1rvv//Xh5yWFK0kuLK0f37kwLjogujf1rox2sF5EKkG67qxJ9wT1S LEcAFt5P552zdKF0Eg1gt+fjhOT3U1+1NlygVlWt+xZ+fvGvkRS6pLDH1yTJwr+6 Cz9WWmQ+j0f64kRhsSgUvtu+kyTqxZe5yTyuGPQ3tL8iZ63UCK9jt+bRR/VDvm3T ioa/BQG9Zi78VAhyojdgMc+sodq/PatOBzMb/LgrXslyCGy2bpfVi3tV+tMqrb77 v9Ud2I8eivRk7L0DhPGhZA8tGG1u67JS7qzDCoM+ZhTGwV8HHplVVuCgriexW+// OvRniPxRPzFXec4wbLhxkAk67KOoRdqLHLvdpdN5NJzfeYuMhxW52QtVj8FH4IC8 Q36I/qNgtf+vigWp1cJfo3PiU3dgMidTJSHiesIzZrBFsJcosGy4UhE8JBlEYws+ 9FBJ8V9rDwn/eUs8AjAh3pQZy1gRKHvAlMqp4H2p+yWSw8cjvV7R2SuLDSRgCSr0 +JEChdOmC+souJ3LTMI7M7Q0NKbjHGZEB2XL7Z8E4xApzXPCUdxk+kEgL+SBFRMh jGSKBjgjgsEe3X6rf/dae8CKvp9db3FrBcBLuBYqh72M/1gJEscWTdfN+/0Agpby PXygWhFuxSNySGZdwajJ =EtEx -END PGP SIGNATURE- 0001-Allow-simple-architecture-specific-overrides.patch Description: application/wine-extension-patch 0001-Allow-simple-architecture-specific-overrides.patch.sig Description: Binary data
Bug#624417: rhythmbox: radio support fails with TypeError: Couldn't find conversion for foreign struct 'cairo.Context'
Cyril Brulebois k...@debian.org (28/04/2011): trying to listen to an online radio, I'm getting this: | $ rhythmbox ... | (rhythmbox:8040): Rhythmbox-WARNING **: Couldn't find an x overlay | TypeError: Couldn't find conversion for foreign struct 'cairo.Context' | Segmentation fault Actually the same happens with local files playback. Removing the plugins package makes local playback work again. KiBi. signature.asc Description: Digital signature
Bug#305069: mutt: extra redraw, scroll when resuming
the part that was reproducible before is still reproducible with 1.5.21-4 when menu_scroll is set. The flash is not reproducible. Cheers Antonio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589808: grep: Odd result with [A-Z] and non-C locale
On 24/04/11 19:58, Dererk wrote: Anibal, do you think there would be a chance to backport this? It appears to be quite a gain for everyone. Hi, If you mean uploading to backports.debian.org, it should be ok. But as far as I know, the best practices is to wait until the package reaches testing (I haven't upload anything before to backports). Cheers! Santiago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597595: Info received (Error loading XML document)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Emmanuel, did you verify the error with the latest debian package (3.0.10-1) I checked the source and all split() functions had been replaced by preg_split(). Cheers Bjoern -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk25MlQACgkQABMWRpwdNulYQwCfSHhvAIQiE1L5DH965ZC4tlZY FfoAoJgBuCiFOQPb924gX+NgsrOMfICT =Xf1V -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 11:17:34AM +0200, Michel Dänzer wrote: On Don, 2011-04-28 at 10:45 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:15:00AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. No possibility of e.g. a static library being linked into a shared object? None from the iceweasel source, at least. shows nothing at all, and in particular no reason for the reassignment. Another data point that I gave before: 3.5.17-1 built just fine, but 3.5.18-1 didn't. And attached here is the diff between both versions, since you don't trust the maintainer telling you that the switch in the toolchain is the likely culprit. But, yeah, it's just easier to dismiss toolchain bugs. The R_PPC_REL24 relocations may happen to work sometimes (possibly most of the time). I'll also add that the symbol for which the relocation is failing, _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm. But you're right, it's most probably not a toolchain problem. Even better, if I download xulrunner-1.9.1_1.9.1.18-1_powerpc.deb and take a look at the relocations in libxul.so, I can't even find the relocation ld.so is complaining about. How did you look? daenzer@thor|11:11:06 objdump -R /usr/lib/xulrunner-1.9.1/libxul.so|grep R_PPC_REL24 0033faa0 R_PPC_REL24 _restgpr_29_x 0033fdc0 R_PPC_REL24 _restgpr_29_x 0033fea0 R_PPC_REL24 _restgpr_29_x [...] 47132 hits. And none of the offsets match the end of the relocation address ld.so is talking about. Now, for something interesting, LD_DEBUG=all says this: binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x' just before failing, and it (obviously) fails on the first of these relocations. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 11:25:06AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:17:34AM +0200, Michel Dänzer wrote: On Don, 2011-04-28 at 10:45 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:15:00AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. No possibility of e.g. a static library being linked into a shared object? None from the iceweasel source, at least. shows nothing at all, and in particular no reason for the reassignment. Another data point that I gave before: 3.5.17-1 built just fine, but 3.5.18-1 didn't. And attached here is the diff between both versions, since you don't trust the maintainer telling you that the switch in the toolchain is the likely culprit. But, yeah, it's just easier to dismiss toolchain bugs. The R_PPC_REL24 relocations may happen to work sometimes (possibly most of the time). I'll also add that the symbol for which the relocation is failing, _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm. But you're right, it's most probably not a toolchain problem. Even better, if I download xulrunner-1.9.1_1.9.1.18-1_powerpc.deb and take a look at the relocations in libxul.so, I can't even find the relocation ld.so is complaining about. How did you look? daenzer@thor|11:11:06 objdump -R /usr/lib/xulrunner-1.9.1/libxul.so|grep R_PPC_REL24 0033faa0 R_PPC_REL24 _restgpr_29_x 0033fdc0 R_PPC_REL24 _restgpr_29_x 0033fea0 R_PPC_REL24 _restgpr_29_x [...] 47132 hits. And none of the offsets match the end of the relocation address ld.so is talking about. Now, for something interesting, LD_DEBUG=all says this: binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x' just before failing, and it (obviously) fails on the first of these relocations. Actually, it doesn't fail on the first one. libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which makes the relocation for offset 0x009e9148, which makes it the 3963th. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 11:32:16AM +0200, Mike Hommey wrote: And none of the offsets match the end of the relocation address ld.so is talking about. Now, for something interesting, LD_DEBUG=all says this: binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x' just before failing, and it (obviously) fails on the first of these relocations. Actually, it doesn't fail on the first one. libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which makes the relocation for offset 0x009e9148, which makes it the 3963th. (easier to find the relocation when you have the base of the library in memory, really odd alignment, by the way) All in all, it looks to me like it used to work by mere luck, but somehow now fails because the lib containing the _restgpr_29_x symbol is too far, which libgcc_s.so would likely be as well. So using a R_PPC_REL24 relocation for these undefined symbols looks like a big stretch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Don, 2011-04-28 at 10:45 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:15:00AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. No possibility of e.g. a static library being linked into a shared object? shows nothing at all, and in particular no reason for the reassignment. Another data point that I gave before: 3.5.17-1 built just fine, but 3.5.18-1 didn't. And attached here is the diff between both versions, since you don't trust the maintainer telling you that the switch in the toolchain is the likely culprit. But, yeah, it's just easier to dismiss toolchain bugs. The R_PPC_REL24 relocations may happen to work sometimes (possibly most of the time). I'll also add that the symbol for which the relocation is failing, _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm. But you're right, it's most probably not a toolchain problem. Even better, if I download xulrunner-1.9.1_1.9.1.18-1_powerpc.deb and take a look at the relocations in libxul.so, I can't even find the relocation ld.so is complaining about. How did you look? daenzer@thor|11:11:06 objdump -R /usr/lib/xulrunner-1.9.1/libxul.so|grep R_PPC_REL24 0033faa0 R_PPC_REL24 _restgpr_29_x 0033fdc0 R_PPC_REL24 _restgpr_29_x 0033fea0 R_PPC_REL24 _restgpr_29_x [...] 47132 hits. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Don, 2011-04-28 at 11:25 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:17:34AM +0200, Michel Dänzer wrote: On Don, 2011-04-28 at 10:45 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:15:00AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. No possibility of e.g. a static library being linked into a shared object? None from the iceweasel source, at least. I think so far the most likely origin of the R_PPC_REL24 relocations seems libgcc.a. Matthias, do you concur? If so, any ideas what the iceweasel build might be doing wrong? Or otherwise, any ideas for isolating where they're coming from? I'll also add that the symbol for which the relocation is failing, _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm. But you're right, it's most probably not a toolchain problem. Even better, if I download xulrunner-1.9.1_1.9.1.18-1_powerpc.deb and take a look at the relocations in libxul.so, I can't even find the relocation ld.so is complaining about. How did you look? daenzer@thor|11:11:06 objdump -R /usr/lib/xulrunner-1.9.1/libxul.so|grep R_PPC_REL24 0033faa0 R_PPC_REL24 _restgpr_29_x 0033fdc0 R_PPC_REL24 _restgpr_29_x 0033fea0 R_PPC_REL24 _restgpr_29_x [...] 47132 hits. And none of the offsets match the end of the relocation address ld.so is talking about. Not sure that matters at all. A R_PPC_REL24 relocation in a shared object is a bug. P.S. /usr/lib/xulrunner-2.0/libxul.so seems contaminated as well. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624409: Attaching NMU diff
Hi Paul, you find the NMU diff attached. raul (0.8.0-0.2) experimental; urgency=low * Non-maintainer upload. * debian/rules: - Build docs only when doxygen, graphviz are installed; this also fixes FTBFS on kfreebsd-amd64 (Closes: #611193). - Build with --debug enabled. * debian/control: - Move doxygen, graphviz to Build-Depends-Indep. - Sort Build-Depends values. * debian/patches/1001-dont_run_ldconfig.patch: - Avoid calling ldconfig once the build is finished, this allow us to save a bit of time. * Remove debian/patches/hppa_parallel.patch since it is unneeded now. -- Alessio Treglia ales...@debian.org Thu, 28 Apr 2011 11:39:06 +0200 Regards, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 raul_0.8.0-0.2.nmudiff Description: Binary data
Bug#624413: [Pkg-xfce-devel] Bug#624413: thunar-volman: Unbuildable on kfreebsd (wrong build-dep on libgudev)
On Thu, Apr 28, 2011 at 11:04:45 +0200, Yves-Alexis Perez wrote: Yes, sadly thunar-volman is now Linux only. I hope that won't last but that's the current state. That seems silly. Surely the code that was there earlier to handle other kernels hasn't magically stopped working? I'll make an upload specifying Architecture: linux-any but aiui it needs special action from ftpmasters and buildd admins so cloning and reassigning. You'll also need to drop the dependency on thunar-volman from xfce4. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 11:40:48AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:32:16AM +0200, Mike Hommey wrote: And none of the offsets match the end of the relocation address ld.so is talking about. Now, for something interesting, LD_DEBUG=all says this: binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x' just before failing, and it (obviously) fails on the first of these relocations. Actually, it doesn't fail on the first one. libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which makes the relocation for offset 0x009e9148, which makes it the 3963th. (easier to find the relocation when you have the base of the library in memory, really odd alignment, by the way) All in all, it looks to me like it used to work by mere luck, but somehow now fails because the lib containing the _restgpr_29_x symbol is too far, which libgcc_s.so would likely be as well. So using a R_PPC_REL24 relocation for these undefined symbols looks like a big stretch. FWIW, taking a look at where these relocations take place show that the corresponding symbols (from the -dbg package) are in functions coming from objects that *are* built -fPIC. It also happens that, in libnss3-1d, the libcrmf.a file contains the same kind of relocations, and all the files built in that lib *are* built -fPIC. That would help having a smaller testcase than iceweasel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 11:43:12AM +0200, Michel Dänzer wrote: On Don, 2011-04-28 at 11:25 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:17:34AM +0200, Michel Dänzer wrote: On Don, 2011-04-28 at 10:45 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:15:00AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote: On 04/28/2011 09:57 AM, Mike Hommey wrote: Take the build log, remove all lines without -fPIC, you'll only get lines for building binaries and objects that aren't linked into libxul.so. QED. No possibility of e.g. a static library being linked into a shared object? None from the iceweasel source, at least. I think so far the most likely origin of the R_PPC_REL24 relocations seems libgcc.a. Matthias, do you concur? If so, any ideas what the iceweasel build might be doing wrong? Or otherwise, any ideas for isolating where they're coming from? See my other message. I'll also add that the symbol for which the relocation is failing, _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm. But you're right, it's most probably not a toolchain problem. Even better, if I download xulrunner-1.9.1_1.9.1.18-1_powerpc.deb and take a look at the relocations in libxul.so, I can't even find the relocation ld.so is complaining about. How did you look? daenzer@thor|11:11:06 objdump -R /usr/lib/xulrunner-1.9.1/libxul.so|grep R_PPC_REL24 0033faa0 R_PPC_REL24 _restgpr_29_x 0033fdc0 R_PPC_REL24 _restgpr_29_x 0033fea0 R_PPC_REL24 _restgpr_29_x [...] 47132 hits. And none of the offsets match the end of the relocation address ld.so is talking about. Not sure that matters at all. A R_PPC_REL24 relocation in a shared object is a bug. P.S. /usr/lib/xulrunner-2.0/libxul.so seems contaminated as well. ... but somehow worked during the test suite. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Don, 2011-04-28 at 11:55 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:40:48AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:32:16AM +0200, Mike Hommey wrote: And none of the offsets match the end of the relocation address ld.so is talking about. Now, for something interesting, LD_DEBUG=all says this: binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x' just before failing, and it (obviously) fails on the first of these relocations. Actually, it doesn't fail on the first one. libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which makes the relocation for offset 0x009e9148, which makes it the 3963th. (easier to find the relocation when you have the base of the library in memory, really odd alignment, by the way) All in all, it looks to me like it used to work by mere luck, but somehow now fails because the lib containing the _restgpr_29_x symbol is too far, which libgcc_s.so would likely be as well. So using a R_PPC_REL24 relocation for these undefined symbols looks like a big stretch. FWIW, taking a look at where these relocations take place show that the corresponding symbols (from the -dbg package) are in functions coming from objects that *are* built -fPIC. It also happens that, in libnss3-1d, the libcrmf.a file contains the same kind of relocations, and all the files built in that lib *are* built -fPIC. That would help having a smaller testcase than iceweasel. If libcrmf.a ends up being linked into libxul.so, that would be the static library I asked about, and the bug. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624422: [dropbox] New upstream version 1.1.28 available
Package: dropbox Version: 1.0.10-1 Severity: normal Hi, there is a new version of db available, please update the Debian package if you have time. Thank you very much for packaging Dropbox! Cheers, Bastian --- System information. --- Architecture: i386 Kernel: Linux 2.6.38-2-686 Debian Release: wheezy/sid 500 unstableftp.de.debian.org 500 unstabledebian-multimedia.org 500 stable dl.google.com 101 experimentalftp.de.debian.org --- Package information. --- Depends (Version) | Installed ===-+-= libatk1.0-0 (= 1.29.3) | 2.0.0-1 libc6 (= 2.4) | 2.11.2-11 libfontconfig1 (= 2.8.0) | 2.8.0-2.2 libgcc1(= 1:4.1.1) | 1:4.6.0-5 libglib2.0-0(= 2.12.0) | 2.28.6-1 libgtk2.0-0 (= 2.10.0) | 2.24.4-3 libpango1.0-0 (= 1.14.0) | 1.28.3-6 libsm6 | 2:1.2.0-1 libx11-6| 2:1.4.3-1 libxcomposite1 (= 1:0.3-1) | 1:0.4.3-1 libxcursor1 ( 1.1.2) | 1:1.1.11-1 libxdamage1 (= 1:1.1) | 1:1.1.3-1 libxext6| 2:1.2.0-2 libxfixes3 (= 1:4.0.1) | 1:4.0.5-1 libxi6 | 2:1.4.2-1 libxinerama1| 2:1.1.1-1 libxrandr2 | 2:1.3.1-1 libxrender1 | 1:0.9.6-1 Package's Recommends field is empty. Package's Suggests field is empty. -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624351: ptrdiff_t is used without including the appropriate headers
Am 28.04.2011 09:07, schrieb Ury Stankevich: Hi, i have checked it with my gcc (4.4.5-8) and find no problem. stddef.h is included from cstddef - bits/stl_algobase.h - algorithm - btree.h you using other compiler/STL maybe ? I use gcc 4.6.0-5, libstdc++ 4.6.0-5, from current Debian unstable. My bits/stl_algobase.h does not include cstddef. Philipp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 12:01:04PM +0200, Michel Dänzer wrote: On Don, 2011-04-28 at 11:55 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:40:48AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:32:16AM +0200, Mike Hommey wrote: And none of the offsets match the end of the relocation address ld.so is talking about. Now, for something interesting, LD_DEBUG=all says this: binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x' just before failing, and it (obviously) fails on the first of these relocations. Actually, it doesn't fail on the first one. libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which makes the relocation for offset 0x009e9148, which makes it the 3963th. (easier to find the relocation when you have the base of the library in memory, really odd alignment, by the way) All in all, it looks to me like it used to work by mere luck, but somehow now fails because the lib containing the _restgpr_29_x symbol is too far, which libgcc_s.so would likely be as well. So using a R_PPC_REL24 relocation for these undefined symbols looks like a big stretch. FWIW, taking a look at where these relocations take place show that the corresponding symbols (from the -dbg package) are in functions coming from objects that *are* built -fPIC. It also happens that, in libnss3-1d, the libcrmf.a file contains the same kind of relocations, and all the files built in that lib *are* built -fPIC. That would help having a smaller testcase than iceweasel. If libcrmf.a ends up being linked into libxul.so, that would be the static library I asked about, and the bug. Let me write it again: - The R_PPC_REL24 relocations are all over libxul.so on objects that are built -fPIC. - libcrmf.a is also linked into libxul.so, and it also contains R_PPC_REL24 relocations, but all the objects it contains are built -fPIC. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 12:04:42PM +0200, Mike Hommey wrote: Let me write it again: - The R_PPC_REL24 relocations are all over libxul.so on objects that are built -fPIC. - libcrmf.a is also linked into libxul.so, and it also contains R_PPC_REL24 relocations, but all the objects it contains are built -fPIC. And this is a -Os bug, apparently. Building with -O2 doesn't seem to yield these relocations. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Don, 2011-04-28 at 12:04 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 12:01:04PM +0200, Michel Dänzer wrote: On Don, 2011-04-28 at 11:55 +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:40:48AM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 11:32:16AM +0200, Mike Hommey wrote: And none of the offsets match the end of the relocation address ld.so is talking about. Now, for something interesting, LD_DEBUG=all says this: binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x' just before failing, and it (obviously) fails on the first of these relocations. Actually, it doesn't fail on the first one. libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which makes the relocation for offset 0x009e9148, which makes it the 3963th. (easier to find the relocation when you have the base of the library in memory, really odd alignment, by the way) All in all, it looks to me like it used to work by mere luck, but somehow now fails because the lib containing the _restgpr_29_x symbol is too far, which libgcc_s.so would likely be as well. So using a R_PPC_REL24 relocation for these undefined symbols looks like a big stretch. FWIW, taking a look at where these relocations take place show that the corresponding symbols (from the -dbg package) are in functions coming from objects that *are* built -fPIC. It also happens that, in libnss3-1d, the libcrmf.a file contains the same kind of relocations, and all the files built in that lib *are* built -fPIC. That would help having a smaller testcase than iceweasel. If libcrmf.a ends up being linked into libxul.so, that would be the static library I asked about, and the bug. Let me write it again: - The R_PPC_REL24 relocations are all over libxul.so on objects that are built -fPIC. - libcrmf.a is also linked into libxul.so, and it also contains R_PPC_REL24 relocations, but all the objects it contains are built -fPIC. I asked about linking static libraries into shared objects because that *cannot work* in general. If there are still other R_PPC_REL24 relocations in libxul.so after you've fixed that, please provide more details about those. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
reassign 624354 gcc-4.5 thanks On Thu, Apr 28, 2011 at 12:14:41PM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 12:10:54PM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 12:04:42PM +0200, Mike Hommey wrote: Let me write it again: - The R_PPC_REL24 relocations are all over libxul.so on objects that are built -fPIC. - libcrmf.a is also linked into libxul.so, and it also contains R_PPC_REL24 relocations, but all the objects it contains are built -fPIC. And this is a -Os bug, apparently. Building with -O2 doesn't seem to yield these relocations. I'm attaching a preprocessed source that yields the problem. $ gcc -o encutil.o -Os -fPIC -c encutil.i $ readelf -r encutil.o Relocation section '.rela.text' at offset 0x478 contains 4 entries: Offset InfoTypeSym.Value Sym. Name + Addend 004e 05fc R_PPC_REL16_HA .got2 + 8012 0052 05fa R_PPC_REL16_LO .got2 + 8016 006c 0b12 R_PPC_PLTREL24 SEC_ASN1Encode_Util + 8000 007c 0c0a R_PPC_REL24 _restgpr_30_x + 0 Relocation section '.rela.got2' at offset 0x4a8 contains 1 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0901 R_PPC_ADDR32 crmf_encoder_out + 0 $ gcc -o encutil.o -O2 -fPIC -c encutil.i $ readelf -r encutil.o Relocation section '.rela.text' at offset 0x480 contains 3 entries: Offset InfoTypeSym.Value Sym. Name + Addend 005a 05fc R_PPC_REL16_HA .got2 + 8022 005e 05fa R_PPC_REL16_LO .got2 + 8026 0078 0b12 R_PPC_PLTREL24 SEC_ASN1Encode_Util + 8000 Relocation section '.rela.got2' at offset 0x4a4 contains 1 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0901 R_PPC_ADDR32 crmf_encoder_out + 0 And with gcc-4.4: $ gcc-4.4 -o encutil.o -Os -fPIC -c encutil.i $ readelf -r encutil.o Relocation section '.rela.text' at offset 0x474 contains 3 entries: Offset InfoTypeSym.Value Sym. Name + Addend 005a 05fc R_PPC_REL16_HA .got2 + 8022 005e 05fa R_PPC_REL16_LO .got2 + 8026 0078 0b12 R_PPC_PLTREL24 SEC_ASN1Encode_Util + 8000 Relocation section '.rela.got2' at offset 0x498 contains 1 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0901 R_PPC_ADDR32 crmf_encoder_out + 0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 12:10:38PM +0200, Michel Dänzer wrote: I asked about linking static libraries into shared objects because that *cannot work* in general. If there are still other R_PPC_REL24 relocations in libxul.so after you've fixed that, please provide more details about those. Let me rephrase it then: libcrmf.a is NOT a static library. It is a library of PIC objects. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624423: mono-dbg: dpkg-deb (subprocess): short read on buffer copy for failed to write to pipe in copy
Package: mono-dbg Version: 2.10.1-4 Severity: grave Justification: renders package unusable dpkg -i mono-dbg_2.10.1-4_all.deb (Reading database ... 155562 files and directories currently installed.) Unpacking mono-dbg (from mono-dbg_2.10.1-4_all.deb) ... dpkg-deb (subprocess): short read on buffer copy for failed to write to pipe in copy dpkg-deb: subprocess paste returned error exit status 2 dpkg: error processing mono-dbg_2.10.1-4_all.deb (--install): short read on buffer copy for backend dpkg-deb during `./usr/lib/mono/2.0/mscorlib.dll.mdb' Errors were encountered while processing: mono-dbg_2.10.1-4_all.deb -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32 (SMP w/6 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash mono-dbg depends on no packages. Versions of packages mono-dbg recommends: ii mono-debugger 2.6.3-2.2 Debugger for Mono mono-dbg suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623613: Removing SAN mapping spawn uninterruptible process
Le Wed, 27 Apr 2011 23:29:40 +0530, Ritesh Raj Sarraf r...@debian.org a écrit : On Wed, Apr 27, 2011 at 5:01 PM, Laurent Bigonville bi...@debian.org wrote: It is already packaged in scsitools. Can you try that script? I will probably mix some issue here. 1) in the version in stable, when all patch are deleted, multipath -ll still list the mapping, with the version from unstable, the mapping is automatically removed. This create some confusion in my mind as I was reading that the mapping should be removed automatically when all the paths are deleted. Yes. Recently, the flush_on_last_del feature was added. Can you check if that is active by default? (multipath -v3 should show you all the applied options) According to redhat doc [0] this is disabled by default. But it seems that when doing: echo 1 /sys/block/sdX/device/delete to remove the paths with flush_on_last_del enabled, that the mapping is not release if there other processes that are were already waiting for IO (kpartx and blkid, again in this case) multipathd: cc_fleet_otf_test_4_1 Last path deleted, disabling queueing multipathd: cc_fleet_otf_test_4_1: map in use multipathd: cc_fleet_otf_test_4_1: can't flush multipathd: flush_on_last_del in progress multipathd: cc_fleet_otf_test_4_1: failed in domap for removal of path sda I think that this should be reported upstream. 2) as soon as the mapping on the san is removed all the paths get faulty cc_fleet_otf_test_4_1 (3600a0b8000472512152a4d5cdd9e) dm-0 IBM,1815 FAStT size=500G features='0' hwhandler='1 rdac' wp=rw |-+- policy='round-robin 0' prio=0 status=active | |- 0:0:1:1 sdb 8:16 active faulty running | `- 1:0:1:1 sdd 8:48 active faulty running `-+- policy='round-robin 0' prio=0 status=enabled |- 0:0:0:1 sda 8:0 active faulty running `- 1:0:0:1 sdc 8:32 active faulty running And /var/log/daemon.log gets spammed with: [...] so it seems that the status is flipping (the up and ghost paths seems the same as when the LUN was mapped), is this expected? This might be weird. The pathchecker reports that sdd and sdb are up but the overall active paths listed go down to 0. At this point, if you run `multipath -v3`, does the status change to what pathchecker is reporting? With the LUN unmapped on the san manager, no, the paths are still considered 'faulty' But with the version from unstable I get the following entries in the logs which look more sensible: multipathd: cc_fleet_otf_test_4_1: sdb - rdac checker reports path is down multipathd: checker failed path 8:16 in map cc_fleet_otf_test_4_1 multipathd: cc_fleet_otf_test_4_1: remaining active paths: 3 multipathd: cc_fleet_otf_test_4_1: sdc - rdac checker reports path is down multipathd: checker failed path 8:32 in map cc_fleet_otf_test_4_1 multipathd: cc_fleet_otf_test_4_1: remaining active paths: 2 multipathd: cc_fleet_otf_test_4_1: sdd - rdac checker reports path is down multipathd: checker failed path 8:48 in map cc_fleet_otf_test_4_1 multipathd: cc_fleet_otf_test_4_1: remaining active paths: 1 multipathd: cc_fleet_otf_test_4_1: sde - rdac checker reports path is down multipathd: checker failed path 8:64 in map cc_fleet_otf_test_4_1 multipathd: cc_fleet_otf_test_4_1: remaining active paths: 0 multipathd: dm-0: add map (uevent) multipathd: dm-0: devmap already registered multipathd: cc_fleet_otf_test_4_1: sdb - rdac checker reports path is down multipathd: cc_fleet_otf_test_4_1: sdc - rdac checker reports path is down multipathd: cc_fleet_otf_test_4_1: sdd - rdac checker reports path is down multipathd: cc_fleet_otf_test_4_1: sde - rdac checker reports path is down [...] So this seems fixed in unstable/testing. 3) The whole problem I have first described here could be due to the queue_if_no_path feature and the fact that some udev rules call kpartx and blkid, because when I issues dmsetup message cc_fleet_otf_test_4_1 0 fail_if_no_path the process that were stuck exit and I can then remove the previously stuck mapping. queue_if_no_path is used to ensure that applications don't fail when all paths go down (commonly seen during target cluster faults where there is a window for all paths being unavailable). All it does is to suspend all relevant processes (notice is the ps output, they'll all be in 'D' UnInterruptible State). Now, _if_ the udev rules touch device mapper devices at that moment, yes, you will see all those processes stuck. When those processes are stuck, can you take a ps output to see what those commands (kpartx/blkid) are trying to access? With both version (from stable and unstable) as soon the lun is unmapped in the SAN manager a kpartx and a blkid are spawned waiting for the IO's to resume and preventing the removal of the mapping from multipath, this seems to be related to the fact that multipath try to readd the dm device (see logs above) at that point. This is spawned when multipathd see that the paths are
Bug#581505: trousers init script should not use --chuid (tcsd does that by itself)
Hi. I think I'm also hitting the same problem, but with different symptom - I cannot start tcsd (0.3.5-2+b1 on sid) at all. I believe it's the init script at fault. In /etc/init.d/trousers, it invokes tcsd daemon with start-stop-daemon --start --quiet --background \ --make-pid --pidfile /var/run/tcsd.pid \ --user tss --chuid tss \ --exec /usr/sbin/tcsd -- -f However, tcsd fails to start with this configuration (without any error message). By removing --chuid tss, start-stop-daemon --start --quiet --background \ --make-pid --pidfile /var/run/tcsd.pid \ --user tss \ - HERE --exec /usr/sbin/tcsd -- -f this starts without any problem. # ps auxww | grep tcsd tss 27852 0.0 0.0 22772 1628 ? S 19:17 0:00 /usr/sbin/tcsd -f Running uid is also set collectly, as it's done by tcsd itself. === src/tcsd/svrside.c === 271 #ifndef SOLARIS 272 pwd = getpwnam(TSS_USER_NAME); ... 282 setuid(pwd-pw_uid); 283 #endif So I guess removing --chuid tss from init script solves the issue. Also, trying to set running uid outside the program is probably useless, as TSS_USER_NAME is hardcoded to be tss in the source. Best Regards, -- Taisuke Yamada (@tyamadajp) Old fingerprint = 5229 959A C85D 3C21 923A 41BD 5D60 D687 701E 5AA9 New fingerprint = 9912 2F0A F0A2 4CDC 592A 2731 A03D C4C2 EECA D0AE signature.asc Description: OpenPGP digital signature
Bug#624424: Typos in package description
Source: cairo-dock-plugins
Version: 2.3.0~0rc1-1
Severity: minor
Tags: patch
Hello,
I found a few typos in the package descriptions while translating it via the
DDTSS. A patch to fix them is included.
Regards, Erik
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- control 2011-03-02 01:59:17.0 +0100
+++ control.new 2011-04-28 12:11:46.0 +0200
@@ -99,10 +99,10 @@
Package: cairo-dock-plugin-data
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: Cairo-dock - Plug-in data file
+Description: Cairo-dock - Plug-in data files
A collection of official plug-ins and applets for cairo-dock.
.
- This package provides plug-in data file.
+ This package provides plug-in data files.
Package: cairo-dock-alsamixer-plugin
Architecture: alpha amd64 armel avr32 hppa i386 ia64 m32r m68k mips mipsel
powerpc powerpcspe ppc64 s390 sh4 sparc sparc64
@@ -124,17 +124,17 @@
Package: cairo-dock-cairo-penguin-plugin
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, cairo-dock-plugin-data (=
${source:Version})
-Description: Cairo-dock - Cairo penguin plug-in
+Description: Cairo-dock - Cairo-Penguin plug-in
A collection of official plug-ins and applets for cairo-dock.
.
- This plug-in add a lively Penguin in your dock.
+ This plug-in adds a lively Penguin in your dock.
Tux images are taken from Pingus, some other characters are available
or can be added easily.
Package: cairo-dock-clipper-plugin
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, cairo-dock-plugin-data (=
${source:Version})
-Description: Cairo-dock - Cairo clipper plug-in
+Description: Cairo-dock - Clipper plug-in
A collection of official plug-ins and applets for cairo-dock.
.
This plug-in keeps a trace of the clipboard and mouse selection,
@@ -149,10 +149,10 @@
A collection of official plug-ins and applets for cairo-dock.
.
This plug-in displays time and date in your dock.
- Two view are available : numeric and analogic, based on Cairo-Clock.
+ Two views are available : numeric and analogic, based on Cairo-Clock.
This is compatible with the Cairo-Clock's themes, and you can detach itself to
be a perfect clone of Cairo-Clock.
- And this supports alarms, and a basic calendar, and allows you to setup time
+ And this supports alarms, and a basic calendar, and allows you to set time
and date.
Package: cairo-dock-compiz-icon-plugin
@@ -162,10 +162,10 @@
Description: Cairo-dock - Compiz icon plug-in
A collection of official plug-ins and applets for cairo-dock.
.
- This plug-in allows you to manage compiz and other windows manager.
- The sub-dock gives you to acces to CCSM, Emerald and some basic Compiz
+ This plug-in allows you to manage Compiz and other window managers.
+ The sub-dock gives you access to CCSM, Emerald and some basic Compiz
actions.
- The configuration panel gives user some options to launch Compiz.
+ The configuration panel gives users some options to launch Compiz.
Package: cairo-dock-dbus-plugin
Architecture: any
@@ -173,7 +173,7 @@
Description: Cairo-dock - Dbus plug-in
A collection of official plug-ins and applets for cairo-dock
.
- This plug-in lets extern applications interact on the dock.
+ This plug-in lets external applications interact on the dock.
The communication between both sides is based on Dbus.
Package: cairo-dock-desklet-rendering-plugin
@@ -208,9 +208,9 @@
A collection of official plug-ins and applets for cairo-dock.
.
This plug-in manages the dustbin.
- User can threw files and unmount disks by drag andn droping them on the
- icon.
- This can warn user if use too much space.
+ Users can delete files and unmount disks by drag and dropping them on
+ the icon.
+ This can warn users if they use too much space.
Package: cairo-dock-icon-effect-plugin
Architecture: any
@@ -234,7 +234,7 @@
Description: Cairo-dock - Logout plug-in
A collection of official plug-ins and applets for cairo-dock.
.
- A very simple plugin that adds an icon to log out from your session.
+ A very simple plug-in that adds an icon to log out from your session.
Package: cairo-dock-motion-blur-plugin
Architecture: any
@@ -260,7 +260,7 @@
Description: Cairo-dock - Powermanager plug-in
A collection of official plug-ins and applets for cairo-dock.
.
- This plug-in controls powermanager for laptop's battery.
+ This plug-in controls the powermanager for your laptop's battery.
It works with ACPI and DBus.
Package: cairo-dock-quick-browser-plugin
@@ -289,7 +289,7 @@
Description: Cairo-dock - Shortcuts plug-in
A collection of official plug-ins and applets for cairo-dock.
.
- This plug-in lets you access quickly to all of your shortcuts.
+ This
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 12:16:46PM +0200, Mike Hommey wrote:
reassign 624354 gcc-4.5
thanks
On Thu, Apr 28, 2011 at 12:14:41PM +0200, Mike Hommey wrote:
On Thu, Apr 28, 2011 at 12:10:54PM +0200, Mike Hommey wrote:
On Thu, Apr 28, 2011 at 12:04:42PM +0200, Mike Hommey wrote:
Let me write it again:
- The R_PPC_REL24 relocations are all over libxul.so on objects that are
built -fPIC.
- libcrmf.a is also linked into libxul.so, and it also contains
R_PPC_REL24 relocations, but all the objects it contains are built
-fPIC.
And this is a -Os bug, apparently. Building with -O2 doesn't seem to
yield these relocations.
I'm attaching a preprocessed source that yields the problem.
$ gcc -o encutil.o -Os -fPIC -c encutil.i
$ readelf -r encutil.o
Relocation section '.rela.text' at offset 0x478 contains 4 entries:
Offset InfoTypeSym.Value Sym. Name + Addend
004e 05fc R_PPC_REL16_HA .got2 + 8012
0052 05fa R_PPC_REL16_LO .got2 + 8016
006c 0b12 R_PPC_PLTREL24 SEC_ASN1Encode_Util + 8000
007c 0c0a R_PPC_REL24 _restgpr_30_x + 0
Relocation section '.rela.got2' at offset 0x4a8 contains 1 entries:
Offset InfoTypeSym.Value Sym. Name + Addend
0901 R_PPC_ADDR32 crmf_encoder_out + 0
$ gcc -o encutil.o -O2 -fPIC -c encutil.i
$ readelf -r encutil.o
Relocation section '.rela.text' at offset 0x480 contains 3 entries:
Offset InfoTypeSym.Value Sym. Name + Addend
005a 05fc R_PPC_REL16_HA .got2 + 8022
005e 05fa R_PPC_REL16_LO .got2 + 8026
0078 0b12 R_PPC_PLTREL24 SEC_ASN1Encode_Util + 8000
Relocation section '.rela.got2' at offset 0x4a4 contains 1 entries:
Offset InfoTypeSym.Value Sym. Name + Addend
0901 R_PPC_ADDR32 crmf_encoder_out + 0
And with gcc-4.4:
$ gcc-4.4 -o encutil.o -Os -fPIC -c encutil.i
$ readelf -r encutil.o
Relocation section '.rela.text' at offset 0x474 contains 3 entries:
Offset InfoTypeSym.Value Sym. Name + Addend
005a 05fc R_PPC_REL16_HA .got2 + 8022
005e 05fa R_PPC_REL16_LO .got2 + 8026
0078 0b12 R_PPC_PLTREL24 SEC_ASN1Encode_Util + 8000
Relocation section '.rela.got2' at offset 0x498 contains 1 entries:
Offset InfoTypeSym.Value Sym. Name + Addend
0901 R_PPC_ADDR32 crmf_encoder_out + 0
And a smaller testcase exhibiting the problem:
extern int bar();
int foo() {
return bar();
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599701: simple-scan - segmentation fault in debian sid after scan completes
Please try to reproduce this with the latest 2.32.0.2 release available in sid. Regards, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624413: [Pkg-xfce-devel] Bug#624413: thunar-volman: Unbuildable on kfreebsd (wrong build-dep on libgudev)
On jeu., 2011-04-28 at 11:49 +0200, Julien Cristau wrote: On Thu, Apr 28, 2011 at 11:04:45 +0200, Yves-Alexis Perez wrote: Yes, sadly thunar-volman is now Linux only. I hope that won't last but that's the current state. That seems silly. Surely the code that was there earlier to handle other kernels hasn't magically stopped working? Hal code has been dropped and I'm not sure anybody wants it back. I'll make an upload specifying Architecture: linux-any but aiui it needs special action from ftpmasters and buildd admins so cloning and reassigning. You'll also need to drop the dependency on thunar-volman from xfce4. Yes, the xfce4 upload is planned too. Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624409: Wrong bug ref
Hi again, a wrong bug number was set in debian/changelog, the correct diff is attached. diff -Nru raul-0.8.0/debian/changelog raul-0.8.0/debian/changelog --- raul-0.8.0/debian/changelog 2011-04-12 17:07:47.0 +0200 +++ raul-0.8.0/debian/changelog 2011-04-28 12:46:20.0 +0200 @@ -1,3 +1,20 @@ +raul (0.8.0-0.2) experimental; urgency=low + + * Non-maintainer upload. + * debian/rules: +- Build docs only when doxygen, graphviz are installed; + this also fixes FTBFS on kfreebsd-amd64 (Closes: #624409). +- Build with --debug enabled. + * debian/control: +- Move doxygen, graphviz to Build-Depends-Indep. +- Sort Build-Depends values. + * debian/patches/1001-dont_run_ldconfig.patch: +- Avoid calling ldconfig once the build is finished, this allow us + to save a bit of time. + * Remove debian/patches/hppa_parallel.patch since it is unneeded now. + + -- Alessio Treglia ales...@debian.org Thu, 28 Apr 2011 12:46:11 +0200 + raul (0.8.0-0.1) experimental; urgency=low * Non-maintainer upload. I intend to upload this to experimental DELAYED-5 within few hours, please let me know if you have objections. Cheers, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 raul_0.8.0-0.2.nmudiff Description: Binary data
Bug#624425: openssh-server: strange segfaults in logs and posssibility of successfull remote command execution
Package: openssh-server Version: 1:5.5p1-6 Severity: important -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 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 openssh-server depends on: ii adduser 3.112+nmu2 add and remove users and groups ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii dpkg1.15.8.10Debian package management system ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2common error description library ii libgssapi-krb5-21.8.3+dfsg-4 MIT Kerberos runtime libraries - k ii libkrb5-3 1.8.3+dfsg-4 MIT Kerberos runtime libraries ii libpam-modules 1.1.1-6.1Pluggable Authentication Modules f ii libpam-runtime 1.1.1-6.1Runtime support for the PAM librar ii libpam0g1.1.1-6.1Pluggable Authentication Modules l ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii libssl0.9.8 0.9.8o-4squeeze1 SSL shared libraries ii libwrap07.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii openssh-blacklist 0.4.1list of default blacklisted OpenSS ii openssh-client 1:5.5p1-6secure shell (SSH) client, for sec ii procps 1:3.2.8-9/proc file system utilities ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages openssh-server recommends: ii openssh-blacklist-extra 0.4.1 list of non-default blacklisted Op ii xauth 1:1.0.4-1 X authentication utility Versions of packages openssh-server suggests: pn molly-guard none (no description available) pn rssh none (no description available) pn ssh-askpass none (no description available) pn ufw none (no description available) -- debconf information: ssh/vulnerable_host_keys: * ssh/use_old_init_script: true ssh/encrypted_host_key_but_no_keygen: ssh/disable_cr_auth: false Apr 28 04:35:31 wz5 kernel: [3883195.806079] sshd[3692]: segfault at 18 ip 00417d29 sp 7fff7dbcad40 error 4 in sshd[40+7 Also SPAM message were sent from root without any authentication attempt logged. Only trace is this segfault logs, which happened right at time when SPAM were sent. Temporary solution is to disable PermitRootLogin, as other account are unknown for remote user. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624426: mumble-django postinst chown ignores dpkg-statoverride
Package: mumble-django Version: 2.4-3 Hi, I think running mumble-django as www-data is stupid and wrong; so I chose to spawn it with runit/spawn-fcgi as a different user: exec /usr/bin/spawn-fcgi -s /var/run/lighttpd2/mumble-django.sock -n -u mumble-server -U www-data -- /usr/share/mumble-django/mumble-django.fastcgi Unfortunately your postinst script overwrites the db permissions at every update despite my dpkg-statoverride entries: # dpkg-statoverride --list '/var/lib/mumble-django*' mumble-server mumble-server 751 /var/lib/mumble-django mumble-server mumble-server 640 /var/lib/mumble-django/mumble-django.db3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615889: libmtp8: mtp-detect doen't connect to creative zen v plus anymore
tags 615889 moreinfo thanks Hi, could you format your device and try it again with the latest release available in Debian testing? Thanks in advance. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
