Bug#688778: [Pkg-libvirt-maintainers] Bug#688778: /usr/bin/virsh: vbox:///session uri undocumented
On Tue, Sep 25, 2012 at 06:08:06PM +0200, Michal Suchanek wrote: Package: libvirt-bin Version: 0.10.1-2 Severity: normal File: /usr/bin/virsh Hello, vbox:///session is the default uri in virsh but it is not documented in the man page. Because it isn't (from the manpage): LIBVIRT_DEFAULT_URI The hypervisor to connect to by default. Set this to a URI, in the same format as accepted by the connect option. This overrides the default URI set in any client config file and prevents libvirt from probing for drivers. So libvirt is autoprobing by default. I agree that this could probably be documented more prominently. Cheers, -- Guido -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (410, 'unstable'), (200, 'experimental'), (150, 'precise-updates'), (150, 'precise-security'), (150, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libvirt-bin depends on: ii adduser 3.113+nmu3 ii gettext-base0.18.1.1-9 ii libavahi-client30.6.31-1 ii libavahi-common30.6.31-1 ii libblkid1 2.22-1~test1 ii libc6 2.13-35 ii libcap-ng0 0.6.6-2 ii libdbus-1-3 1.6.0-1 ii libdevmapper1.02.1 2:1.02.74-4 ii libgcrypt11 1.5.0-3 ii libgnutls26 2.12.20-1 ii libnetcf1 0.1.9-2 ii libnl1 1.1-7 ii libnuma12.0.8~rc4-1 ii libparted0debian1 2.3-10 ii libpcap0.8 1.3.0-1 ii libpciaccess0 0.13.1-2 ii libreadline66.2-8 ii libsasl2-2 2.1.25.dfsg1-5 ii libudev0175-7 ii libvirt00.10.1-2 ii libxenstore3.0 4.2.0-1 ii libxml2 2.8.0+dfsg1-5 ii libyajl22.0.4-2 ii logrotate 3.8.1-4 Versions of packages libvirt-bin recommends: ii bridge-utils1.5-4 ii dmidecode 2.11-9 ii dnsmasq-base2.62-3 ii ebtables2.0.10.4-1 ii gawk1:4.0.1+dfsg-2 ii iproute 20120521-3 ii iptables1.4.14-3 ii libxml2-utils 2.8.0+dfsg1-5 ii netcat-openbsd 1.105-7 ii parted 2.3-10 ii pm-utils1.4.1-9 ii qemu1.1.0+dfsg-1 ii qemu-kvm1.1.1+dfsg-1nops2.1 Versions of packages libvirt-bin suggests: ii policykit-1 0.105-1 ii radvd1:1.9.1-1 -- no debconf information ___ Pkg-libvirt-maintainers mailing list pkg-libvirt-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673690: libmotif4 multiarch
tags 673690 + patch thanks Following a request by Graham Inggs, I'm attaching a debdiff of my changes against the Ubuntu 12.04 version of the package. It also includes my own respin of the fix for #635960. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673690: libmotif4 multiarch patch
Forgot to include the patch the first time around. Resending.
diff -Nru openmotif-2.3.3/debian/changelog openmotif-2.3.3/debian/changelog
--- openmotif-2.3.3/debian/changelog2012-09-26 08:11:52.0 +0200
+++ openmotif-2.3.3/debian/changelog2012-05-20 17:22:12.0 +0200
@@ -1,3 +1,16 @@
+openmotif (2.3.3-5ubuntu1+sg2) precise; urgency=low
+
+ * Convert to multiarch.
+ * Convert to format 3.0 (quilt).
+
+ -- Sergio Gelato sergio.gel...@astro.su.se Sun, 20 May 2012 17:21:39 +0200
+
+openmotif (2.3.3-5ubuntu1+sg1) precise; urgency=low
+
+ * Provide backwards compatibility with libmotif3. (Fixes: #635960)
+
+ -- Sergio Gelato sergio.gel...@astro.su.se Sat, 19 May 2012 17:38:23 +0200
+
openmotif (2.3.3-5ubuntu1) natty; urgency=low
* debian/patches/0003_fix_ftbfs_binutils-gold.patch: fix FTBFS
diff -Nru openmotif-2.3.3/debian/compat openmotif-2.3.3/debian/compat
--- openmotif-2.3.3/debian/compat 2012-09-26 08:11:52.0 +0200
+++ openmotif-2.3.3/debian/compat 2012-05-20 17:15:32.0 +0200
@@ -1 +1 @@
-6
+9
diff -Nru openmotif-2.3.3/debian/control openmotif-2.3.3/debian/control
--- openmotif-2.3.3/debian/control 2012-09-26 08:11:52.0 +0200
+++ openmotif-2.3.3/debian/control 2012-05-20 19:20:18.0 +0200
@@ -1,8 +1,8 @@
Source: openmotif
Section: non-free/devel
Priority: extra
-Build-Depends: debhelper (= 6.0.7), libxaw7-dev, byacc, flex, libsm-dev,
libx11-dev,
- libxext-dev, libxmu-dev, libxp-dev, libxt-dev, xbitmaps, libxft-dev,
autotools-dev, quilt
+Build-Depends: debhelper (= 9), dh-exec, libxaw7-dev, byacc, flex, libsm-dev,
libx11-dev,
+ libxext-dev, libxmu-dev, libxp-dev, libxt-dev, xbitmaps, libxft-dev,
autotools-dev
Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
XSBC-Original-Maintainer: Stefan Bauer stefan.ba...@cubewerk.de
Standards-Version: 3.9.1.0
@@ -12,10 +12,12 @@
Package: libmotif4
Architecture: any
Section: non-free/libs
+Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
-Pre-Depends: x11-common (= 1:7.0.0)
+Pre-Depends: ${misc:Pre-Depends}, x11-common (= 1:7.0.0)
Conflicts: libmotif3
Replaces: libmotif3
+Provides: libmotif3
Description: Open Motif - shared libraries
This package includes all files you need to run Motif
applications which are linked against Open Motif, which
diff -Nru openmotif-2.3.3/debian/libmotif4.files
openmotif-2.3.3/debian/libmotif4.files
--- openmotif-2.3.3/debian/libmotif4.files 2012-09-26 08:11:52.0
+0200
+++ openmotif-2.3.3/debian/libmotif4.files 2012-05-20 17:13:06.0
+0200
@@ -1,3 +1,3 @@
-/usr/lib/lib*.so.*
+/usr/lib/*/lib*.so.*
/usr/lib/X11/bindings
/usr/include/X11/bitmaps
diff -Nru openmotif-2.3.3/debian/libmotif4.links
openmotif-2.3.3/debian/libmotif4.links
--- openmotif-2.3.3/debian/libmotif4.links 1970-01-01 01:00:00.0
+0100
+++ openmotif-2.3.3/debian/libmotif4.links 2012-05-20 17:24:25.0
+0200
@@ -0,0 +1,4 @@
+#! /usr/bin/dh-exec
+usr/lib/${DEB_HOST_MULTIARCH}/libMrm.so.4.0.3
usr/lib/${DEB_HOST_MULTIARCH}/libMrm.so.3
+usr/lib/${DEB_HOST_MULTIARCH}/libUil.so.4.0.3
usr/lib/${DEB_HOST_MULTIARCH}/libUil.so.3
+usr/lib/${DEB_HOST_MULTIARCH}/libXm.so.4.0.3
usr/lib/${DEB_HOST_MULTIARCH}/libXm.so.3
diff -Nru openmotif-2.3.3/debian/libmotif-dev.files
openmotif-2.3.3/debian/libmotif-dev.files
--- openmotif-2.3.3/debian/libmotif-dev.files 2012-09-26 08:11:52.0
+0200
+++ openmotif-2.3.3/debian/libmotif-dev.files 2012-05-20 17:28:07.0
+0200
@@ -1,7 +1,7 @@
-/usr/lib/libMrm.a
-/usr/lib/libUil.a
-/usr/lib/libXm.a
-/usr/lib/lib*.so
+/usr/lib/*/libMrm.a
+/usr/lib/*/libUil.a
+/usr/lib/*/libXm.a
+/usr/lib/*/lib*.so
/usr/include/Xm
/usr/include/Mrm
/usr/include/uil
diff -Nru
openmotif-2.3.3/debian/patches/0004-multiarch-specialcase-libdir-X11.patch
openmotif-2.3.3/debian/patches/0004-multiarch-specialcase-libdir-X11.patch
--- openmotif-2.3.3/debian/patches/0004-multiarch-specialcase-libdir-X11.patch
1970-01-01 01:00:00.0 +0100
+++ openmotif-2.3.3/debian/patches/0004-multiarch-specialcase-libdir-X11.patch
2012-05-20 20:30:11.0 +0200
@@ -0,0 +1,47 @@
+For multiarch support, we change libdir to /usr/lib/$(DEB_HOST_MULTIARCH).
+However, we do not want to do this to /usr/lib/X11 yet.
+
+Note that XMBINDDIR_FALLBACK should really be set to /usr/share/X11/bindings
+since the files are platform-independent. We postpone moving them until a
+decision has been reached on libmotif-common.
+
+The configure.ac fixes are minimal and only suitable for Debian/Ubuntu
+packaging. For upstream one might want to add a command line option.
+
+Sergio Gelato, 2012-05-20.
+--- a/configure
b/configure
+@@ -18786,13 +18786,13 @@
+ LIBDIR=${libdir}/X11
+
+
+-MWMRCDIR=${libdir}/X11
++MWMRCDIR=${prefix}/lib/X11
+
+
+ INCDIR=${includedir}/X11
+
+
+-XMBINDDIR_FALLBACK=${libdir}/X11/bindings
++XMBINDDIR_FALLBACK=${prefix}/lib/X11/bindings
+
+
+ RM=rm -f
+---
Bug#688841: glyr: FTBFS on armel
Source: glyr Version: 1.0.0-1 Severity: serious Justification: fails to build from source Hello, glyr FTBFS on armel. The relevant log line is : build_doc.rb:43: undefined method `exists?' for Dir:Class (NoMethodError) For some reason, the armel buildd picked ruby 1.8 and the other ones ruby 1.9. Versioning the dependency should do the trick. -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688711: [3.4.4 - 3.5 regression] fails to find root device (Unable to find LVM volume data/root)
# 3.6-rc7 tags 688711 + fixed-upstream quit Jonathan Nieder wrote: Jonathan Nieder wrote: [ 1.949115] sda: sda1 sda2 sda3 sda5 [ 1.949751] sd 0:0:0:0: [sda] Attached SCSI disk Volume group data not found [...] Bisects to v3.5-rc1~164 [...] I'm retesting its second and first parent now. Both parents test ok, so looks like something bad happened during that merge. Next step is to linearize it, unless someone has a nicer idea. With all 35 core-rcu-for-linus patches[1] applied on top of 5ec29e3149d8 Merge branch 'core-locking-for-linus' the tree matches v3.5-rc1~164 and reliably fails to boot, with the same message described above. Unfortunately bisecting does not produce a clear result: - the kernel booted fine with the first three patches applied (up to and including c57afe80db4e rcu: Make RCU_FAST_NO_HZ account for pauses out of idle) - with patch 4, the boot failure happened once, but I couldn't make it happen again - likewise with patches up to and including #7 (98248a0e2432 rcu: Explicitly initialize RCU_FAST_NO_HZ per-CPU variables) --- the boot failure happened once, but next time I tried it it booted fine - the kernel reliably fails to boot towards the end of the series The bug resists investigation. Bisection log attached. Luckily 3.5.2-1~experimental.1 still reliably fails to boot. Better news: 3.6~rc7-1~experimental.1, built as described in bug#688834, reliably boots ok (!). So my use case is taken care of. Let's hope the fix sticks. Sincerely, Jonathan [1] 2fdbb31b6627 rcu: Add RCU_FAST_NO_HZ tracing for idle exit 2ee3dc80660a rcu: Make RCU_FAST_NO_HZ use timer rather than hrtimer c57afe80db4e rcu: Make RCU_FAST_NO_HZ account for pauses out of idle 79b9a75fb703 rcu: Add warning for RCU_FAST_NO_HZ timer firing f511fc624642 rcu: Ensure that RCU_FAST_NO_HZ timers expire on correct CPU 21e52e156663 rcu: Make RCU_FAST_NO_HZ handle timer migration 98248a0e2432 rcu: Explicitly initialize RCU_FAST_NO_HZ per-CPU variables b1420f1c8bfc rcu: Make rcu_barrier() less disruptive 559f9badd11d rcu: List-debug variants of rcu list routines f88022a4f650 rcu: Replace list_first_entry_rcu() with list_first_or_null_rcu() c9336643e144 rcu: Clarify help text for RCU_BOOST_PRIO d8169d4c369e rcu: Make __kfree_rcu() less dependent on compiler choices 8932a63d5edb rcu: Reduce cache-miss initialization latencies for large systems dabb8aa96020 rcu: Document kernel command-line parameters 6d8133919bac rcu: Document why rcu_blocking_is_gp() is safe 048a0e8f5e1d timer: Fix mod_timer_pinned() header comment 616c310e83b8 rcu: Move PREEMPT_RCU preemption to switch_to() invocation 9dd8fb16c361 rcu: Make exit_rcu() more precise and consolidate 37e377d2823e rcu: Fixes to rcutorture error handling and cleanup fae4b54f28f0 rcu: Introduce rcutorture testing for rcu_barrier() cef50120b61c rcu: Direct algorithmic SRCU implementation 4b7a3e9e3211 rcu: Remove fast check path from __synchronize_srcu() 440253c17fc4 rcu: Increment upper bit only for srcu_read_lock() 944ce9af4767 rcu: Flip -completed only once per SRCU grace period 18108ebfebe9 rcu: Improve SRCU's wait_idx() comments b52ce066c55a rcu: Implement a variant of Peter's SRCU algorithm 966f58c2f6df rcu: Remove unused srcu_barrier() dc87917501e3 rcu: Improve srcu_readers_active_idx()'s cache locality d9792edd7a9a rcu: Use single value to handle expedited SRCU grace periods 931ea9d1a6e0 rcu: Implement per-domain single-threaded call_srcu() state machine 9059c94017f7 rcu: Add rcutorture test for call_srcu() 9fab97876af8 rcu: Update RCU maintainership git bisect start # good: [5ec29e3149d800e6db83c1b6ff441daf319cbbe2] Merge branch 'core-locking-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 5ec29e3149d800e6db83c1b6ff441daf319cbbe2 # bad: [12198b131631e8e59b0a59859f943cb1ef6d195d] rcu: Update RCU maintainership git bisect bad 12198b131631e8e59b0a59859f943cb1ef6d195d # bad: [649e28922a1e7822f1d7a76092e0c952ba505820] timer: Fix mod_timer_pinned() header comment git bisect bad 649e28922a1e7822f1d7a76092e0c952ba505820 # bad: [bd87bd1e3ff13c60d9da6d4a5f4118a3c9d508c9] rcu: Make rcu_barrier() less disruptive git bisect bad bd87bd1e3ff13c60d9da6d4a5f4118a3c9d508c9 # bad: [c2f4b04298df660415fc3f6a2d257e311f336f2f] rcu: Add warning for RCU_FAST_NO_HZ timer firing git bisect bad c2f4b04298df660415fc3f6a2d257e311f336f2f # good: [1aed1bf682f181bb385580ed197b73b479981e6d] rcu: Make RCU_FAST_NO_HZ use timer rather than hrtimer git bisect good 1aed1bf682f181bb385580ed197b73b479981e6d # good: [43c8306bbe97bab2bba21f2f93dbad52d8b1d61f] rcu: Make RCU_FAST_NO_HZ account for pauses out of idle git bisect good 43c8306bbe97bab2bba21f2f93dbad52d8b1d61f # good: [c2f4b04298df660415fc3f6a2d257e311f336f2f] rcu: Add warning for RCU_FAST_NO_HZ timer firing git bisect good
Bug#688842: CPAN modules no longer installed to /usr/local by default
Package: perl Version: 5.14.2-13 Severity: serious Justification: maintainer opinion On Wed, Sep 26, 2012 at 06:46:02AM +1100, Steve (Telsat Broadband) wrote: I believe I've uncovered a small bug relating to the default installation parameters when using CPAN. On my first try using CPAN on the latest Debian testing version (Wheezy), I found that it was installing all the modules I requested into /root/perl instead of in the proper directories. Thanks for reporting this. They are indeed supposed to go in /usr/local rather than /root by default when root is installing modules. I'm filing this in our bug tracking system. I'm marking it as release critical for now as CPAN bootstrapping is considered one of the primary functions of the Perl standard library. It looks like this is related to 2011-01-16 Andreas J. Koenig a...@cpan.org * release 1.94_63 [...] * add support for bootstrapping local::lib when the user does not have write access to perl's site library directories (David Golden) When the site dirs don't exist, the CPAN shell interactive configuration states Warning: You do not have write permission for Perl library directories. and proceeds to suggest local::lib for installation, which is not the optimal suggestion for root users. We don't ship the site directories in /usr/local with the perl package, as they used to be created at CPAN install time if necessary, and not having them by default saves (or at least used to save) a bunch of stat() calls on every interpreter startup in the common case. Possibly we need to make CPAN::FirstTime try to mkdir those directories when probing. Help (and opinions on the right thing to do) is welcome on this. -- Niko Tyni nt...@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#688843: licensecheck: detect BDS-3-clause as BSD-2-clause
Package: devscripts Version: 2.12.4 Severity: normal licensecheck incorrectly detect the license of the attached file as BSD (2 clause) when it is really BSD (3 clause), see http://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_.28.22New_BSD_License.22_or_.22Modified_BSD_License.22.29 Regards, Dmitry. signature.asc Description: This is a digitally signed message part. # -*- coding: utf-8 -*- Copyright (c) 2011, Daniele Esposti e...@expobrain.net All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * The name of the contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. import sys from ctypes import cdll as loader # Generic constants __VERSION__ = 0.2.2 PIXEL_SZ = 3 PIXEL_ALPHA_SZ = 4
Bug#688794: PANIC: Circular dependancy after reboot when installing 1.20120606.6
Hi Henrique, It is quite weird to get this error on two different machines using different architectures and even while trying two different kernels on these two machines. Then four different configurations lead to this message. BTW, you are right: it is array... and not Array... in the error message. Another bad manual retyping. iucode-tool and cpuid are installed on either machine. cpuid is present and loaded as a module. I even tried to manually update the microcode (downloading from Intel web site and following the other steps described in the README.debian) with the same outcome. If I remove intel-microcode or don't upgrade, I don't have any probleme with kernel upgrades and grub. The i386 netbook is using the new grub2 and the other machine is still running the old grub-legacy. So none of them is a VM. I send you a copy of the initramfs generated on the i386 netbook running the 3.5-trunk kernel from experimental. Regards, Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688821: libglyr-dev: arch-dependent files in Multi-Arch: same package
* Jakub Wilk jw...@debian.org [120926 07:14]: libglyr-dev is marked as Multi-Arch: same, but the following files are architecture-dependent: [...] An example diff between i386 and mips is attached. Hum, I am a bit puzzled. i386 and mips used the same version of gtk-doc-tools. The toolchain is different (gcc 4.6 in one case and gcc 4.7 in the other one), but it shouldn't make too much a difference. It seems that the mips version can't find a lot of strings ; I'll investigate that. Thanks for the report. -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616515: gnucash: uses excessive memory after saving
Jayen Ashar j...@yahoo.com writes: I'm running i386, so I can't confirm. Sorry, my mistake. I have now uploaded an i386 package. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 pgpmBLT49YvO1.pgp Description: PGP signature
Bug#688843: licensecheck: detect BDS-3-clause as BSD-2-clause
On 26.09.2012 08:12, Dmitry Smirnov wrote: licensecheck incorrectly detect the license of the attached file as BSD (2 clause) when it is really BSD (3 clause), see http://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_.28.22New_BSD_License.22_or_.22Modified_BSD_License.22.29 It looks very much /not/ BSD-3, so far as I can see. The standard third clause, as per the link you quoted above is of the form: * Neither the name of the organization nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. whereas the file you attached says * The name of the contributors may be used to endorse or promote products derived from this software without specific prior written permission. That's different enough to make it a different license, imo. Obviously my co-maintainers may disagree. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687459: -- mc: didn't remove obsolete conffile /etc/mc/edit.spell.rc
Thank you for your useful advises, Jakub. I hope I won't miss such issue again. Cheers, Dmitry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688844: winbind init script not LSB compliant
Package: winbind Version: 3.6.6-3_amd64 winbind init script is not LSB compliant: the status function returns 4 instead of 3 when the daemon is stopped repro: apt-get install winbind /etc/init.d/winbind stop /etc/init.d/winbind status; echo $? this happens because the status_of_proc call has wrong parameter ordering. Attached patch fixes the issue. Tags: patch winbind_init_lsb.patch Description: Binary data
Bug#688845: texlive-fonts-extra: Please demote all additional Depends to Recommends
Package: texlive-fonts-extra Version: 2012.20120611-2 Severity: normal Hi there, once in a blue moon I decide I want to use a font (read: one single!) from the texlive-fonts-extra package. It is not only annoying that I have to download some hundred MB just for this package (this is already convered by #688041), but that another additional 22 font packages are also forced onto my system. I try to keep my installed fonts at a minimum and thus find this unacceptable. Hence, I request to demote these additional Depends to Recommends. The rationale being that users typically install texlive-fonts-extra for a hand full of additional fonts - not all of them. If a user installs texlive-fonts- extra, because he wants to use e.g. gentium in LaTeX, I think it can be expected that he takes care of installing the fonts-sil-gentium package as well himself. I still consider it reasonable to install all these additional packages in by default, thus Recommends fits here, but it should as well be possible to remove all of these additional fonts and still keep the texlive- fonts-extra package installed for the other fonts. Cheers, Fabian -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (901, 'testing'), (501, 'unstable'), (401, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.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#688736: [Piuparts-devel] Bug#688736: w3c-linkchecker: modifies conffiles (policy 10.7.3): /etc/w3c/checklink.conf
Hi Nicolas, On Mittwoch, 26. September 2012, Nicholas Bamber wrote: Thanks for the patch. I'll be happy to apply and acknowledge the patch. I am however concerned that the it appears the version of piuparts which generates these reports is not yet in sid, and I would like to hold off working on it until it is. The piuparts version in sid (or elsewhere) doesn't matter, the point is your package is buggy. Seriously buggy even! One can detect this (and suffer by it) easily without piuparts, so please fix the bug and don't complain about the messanger not having shaved for 3 days. I was too lazy to reply on -devel about this, but as you keep insisting... ;-) cheers, Holger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688745: Patch Update for LC_TIME issue
Hi all, attached is a patch update for the reported LC_TIME issue in the process script. Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb From f46e039b90de6c99843159048ef93272cb724a82 Mon Sep 17 00:00:00 2001 From: Mike Gabriel mike.gabr...@das-netzwerkteam.de Date: Tue, 25 Sep 2012 12:08:15 +0200 Subject: [PATCH 1/2] Use locale independent date format for mail processing. --- debian/changelog |1 + scripts/process |4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 1d062f9..f40f575 100644 --- a/debian/changelog +++ b/debian/changelog @@ -44,6 +44,7 @@ debbugs (2.4.2~exp2) UNRELEASED; urgency=low * Make sure that mails to gSubscriptionDomain and gBugSubscriptionDomain are only sent out if the variables in config are defined and have a lenght 0. + * Use locale independent date format for mail processing. -- Don Armstrong d...@debian.org Wed, 25 Aug 2010 01:57:38 -0700 diff --git a/scripts/process b/scripts/process index 9fb2c2f..75c487a 100755 --- a/scripts/process +++ b/scripts/process @@ -7,7 +7,9 @@ use warnings; use strict; -use POSIX qw(strftime); +use locale; +use POSIX qw(strftime locale_h); +setlocale(LC_TIME, C); use IO::File; -- 1.7.10 pgpePa8Tryg6A.pgp Description: Digitale PGP-Unterschrift
Bug#683554: [pkg-horde] Bug#683554: RM: horde3 and reverse dependencies -- ROM; Obsolete version
2012/8/2 Alexander Reichle-Schmehl toli...@debian.org: Hi again! Hi! (...) However, there seems to be a problem with: horde3 Trying to remove it results in: (...) # Broken Build-Depends: php-horde-activesync: pear-horde-channel php-horde-alarm: pear-horde-channel php-horde-argv: pear-horde-channel (cont...) (...) Breaking php-kolab-filter and php-kolab-freebusy is probably okay, as you requested their removal from testing, however all the build-depends on pear-horde-channel look like a problem. Maybe I missed something, but I couldn't find an other package providing pear-horde-channel, nor is there dummy package available build from a higher horde version. Could you please check, that removing horde3 won't result in a lot FTBFS bugs? The new pear-horde-channnel package is in NEW since two weeks. Waiting... Cheers -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688846: initramfs-tools: Upgrade Squeeze-Wheezy: crypto-LVM unaccessible
Package: initramfs-tools Version: 0.107 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, I upgrades my notebook from Squeeze to Wheezy (Stable - Testing). The laptop has an encrypted filesystem (encrypted LVM). The boot process failed because the kernel could not find its root file system. After the update, I had three kernels in my boot configuration: 3.2.0-3-486 new from Wheezy. Did not start 2.6.32-5-686 from Squeeze: did not start 2.6.26-2-686 from Squeeze: started loaded crypted LVM. I usually runned Squeezy using 2.6.32, which was the kernel running during the upgrade. Maybe I now have a Wheezy-2.6.32-5-686 which does not run properly on my laptop because with Squeeze I need a -486-Kernel due to my non-PAE-processor ... Anyways: I added some modules to /etc/initramfs-tools/modules: == dm_crypt dm_mod crypto_blkcipher cbc dm_snapshot dm_mirror dm_log == Then I created a new initramfs using update-initramfs. After this procedure I could boot the 3.2.-kernel. I think that some magic would be useful to detect this kind of setup and to add the modules needed to the initramfs (I do not know, which modules exactly were needed: I just added those which I thought might be needed. Thanks, Sebastian - -- Package-specific info: - -- initramfs sizes - -rw-r--r-- 1 root root 4.0M Aug 2 2010 /boot/initrd.img-2.6.26-2-686 - -rw-r--r-- 1 root root 3.0M Nov 5 2009 /boot/initrd.img-2.6.26-2-686.bak - -rw-r--r-- 1 root root 4.2M Sep 25 11:08 /boot/initrd.img-2.6.32-5-686 - -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-3-486 root=/dev/mapper/crystalline-root ro single - -- resume RESUME=/dev/mapper/crystalline-swap - -- /proc/filesystems ext3 ext2 fuseblk - -- lsmod Module Size Used by snd_hrtimer12540 1 nfnetlink_log 12910 0 nfnetlink 12786 1 nfnetlink_log cpufreq_conservative12987 0 tun17773 4 cpufreq_stats 12645 0 cpufreq_userspace 12520 0 ppdev 12651 0 lp 12797 0 cpufreq_powersave 12422 0 bnep 17288 2 bluetooth 99189 7 bnep crc16 12327 1 bluetooth autofs422840 1 michael_mic12490 8 arc4 12418 4 ecb12649 4 lib80211_crypt_tkip12993 2 lib80211_crypt_ccmp12703 1 binfmt_misc12778 1 uinput 12991 1 deflate12495 0 zlib_deflate 21318 1 deflate ctr12851 0 twofish_generic16529 0 twofish_i586 12453 0 twofish_common 20528 2 twofish_i586,twofish_generic camellia 24892 0 serpent24847 0 blowfish_generic 12424 0 blowfish_common16431 1 blowfish_generic cast5 24773 0 des_generic20771 0 xcbc 12629 0 rmd160 16584 0 sha512_generic 16675 0 sha1_generic 12483 0 hmac 12715 0 crypto_null12636 0 af_key 31004 0 fuse 51958 1 nfsd 173500 2 nfs 256619 1 nfs_acl12463 2 nfs,nfsd auth_rpcgss32012 2 nfs,nfsd fscache27566 1 nfs lockd 57192 2 nfs,nfsd sunrpc143211 17 lockd,auth_rpcgss,nfs_acl,nfs,nfsd ext2 49804 1 firewire_sbp2 17756 0 firewire_core 39034 1 firewire_sbp2 crc_itu_t 12331 1 firewire_core loop 17851 0 snd_intel8x0m 17503 5 snd_intel8x0 22457 2 snd_ac97_codec 84245 2 snd_intel8x0,snd_intel8x0m snd_pcm_oss36194 0 snd_mixer_oss 17668 1 snd_pcm_oss snd_pcm53402 6 snd_pcm_oss,snd_ac97_codec,snd_intel8x0,snd_intel8x0m thinkpad_acpi 47494 0 snd_page_alloc 12867 3 snd_pcm,snd_intel8x0,snd_intel8x0m nvram 13052 1 thinkpad_acpi sg 21589 0 snd_seq_midi 12744 0 radeon571180 1 snd_seq_midi_event 13245 1 snd_seq_midi sr_mod 17468 0 cdrom 34813 1 sr_mod snd_rawmidi18543 1 snd_seq_midi ipw2200 114659 0 joydev 12959 0 snd_seq39764 3 snd_seq_midi_event,snd_seq_midi uhci_hcd 22506 0 libipw 26059 1 ipw2200 ttm42957 1 radeon lib80211 12950 4 libipw,ipw2200,lib80211_crypt_ccmp,lib80211_crypt_tkip ehci_hcd 35684 0 snd_seq_device 13016 3 snd_seq,snd_rawmidi,snd_seq_midi usbcore 100493 3 ehci_hcd,uhci_hcd cfg80211 117608 2
Bug#688843: licensecheck: detect BDS-3-clause as BSD-2-clause
Hi Adam, You might be right, I've noticed that third clause is slightly different. The question is still why is it detected as 2-clause when the number of clauses, technically speaking, is three. I'm not sure if the change in the third clause is significant enough to declare it 2-clause. Also if BSD-2-clause is a fallback from unidentified BSD-like license the we have a bug in detection algorithm aren't we? Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Bug#688847: libav: multiple CVEs in ffmpeg/libav
Source: libav Severity: grave Justification: user security hole Hi, it seems that a huge pile of CVE were allocated for ffmpeg/libav and are supposed to be fixed in 0.11: CVE-2012-2772 CVE-2012-2774 CVE-2012-2775 CVE-2012-2776 CVE-2012-2777 CVE-2012-2779 CVE-2012-2782 CVE-2012-2783 CVE-2012-2784 CVE-2012-2785 CVE-2012-2786 CVE-2012-2787 CVE-2012-2788 CVE-2012-2789 CVE-2012-2790 CVE-2012-2791 CVE-2012-2792 CVE-2012-2793 CVE-2012-2794 CVE-2012-2795 CVE-2012-2796 CVE-2012-2797 CVE-2012-2798 CVE-2012-2799 CVE-2012-2800 CVE-2012-2801 CVE-2012-2802 CVE-2012-2803 CVE-2012-2804 As far as I can tell you're already aware of that, but so it's just a tracking bug. Regards, -- Yves-Alexis -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-grsec-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#688843: licensecheck: detect BDS-3-clause as BSD-2-clause
On 26.09.2012 09:14, Dmitry Smirnov wrote:
You might be right, I've noticed that third clause is slightly
different.
Well, it's basically the exact inverse of the usual clause. :)
The question is still why is it detected as 2-clause when the number
of
clauses, technically speaking, is three.
It's not about the number of clauses, it's about their content. Each of
the clauses has a well-known structure.
I'm not sure if the change in the third clause is significant enough
to
declare it 2-clause.
Also if BSD-2-clause is a fallback from unidentified BSD-like license
the we have a bug in detection algorithm aren't we?
It has to be quite close, not just BSD-like. The code's fairly
readable :-)
if ($licensetext =~ /THIS SOFTWARE IS PROVIDED .*AS IS AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY/) {
if ($licensetext =~ /All advertising materials mentioning features or
use of this software must display the following acknowledge?ment.*This
product includes software developed by/i) {
$license = BSD (4 clause) $license;
} elsif ($licensetext =~ /(The name .*? may not|Neither the names?
.*? nor the names of (its|their) contributors may) be used to endorse or
promote products derived from this software/i) {
$license = BSD (3 clause) $license;
} elsif ($licensetext =~ /Redistributions of source code must retain
the above copyright notice/i) {
$license = BSD (2 clause) $license;
} else {
$license = BSD $license;
}
}
I think my opinion here is fairly clear at the moment, but I'm also not
the most active of the maintainers right now, so I'll leave things to
see if any of the others comment.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688830: devscripts: [new] Please include who-permits-upload as a convenient interface to retrieve DM permissions
* Arno Töll a...@debian.org, 2012-09-26, 03:40: please consider inclusion of who-permits-upload, a Perl script I wrote to query and retrieve DM upload permissions in a convenient way. Shouldn't that be s/permits-upload/permitted-uploads/? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686038: [BTS#686038] templates://fpc/{control,fp-compiler.templates}.in
On Tue, 2012-09-25 at 18:12 -0400, David Prévot wrote: Le 25/09/2012 17:37, Abou Al Montacir a écrit : I've committed everything, Thanks for taking care of it. There are two missing translations from the BTS (Japanese and Swedish, patch attached). Committed, tahnks for the hint Can you please review and confirm that we can upload please? I'm sorry to ask you to wait a little: I'll shake the Spanish translators a bit more because this language is aiming to be 100 % complete for Wheezy, and we thus shouldn't brake its current status. No issue, I'll wait Sorry for the inconvenience and thanks in advance for your patience. No problem, I'm considering also submitting an ar.po file, but I don't know if Arabic is supported by debconf Cheers, signature.asc Description: This is a digitally signed message part
Bug#688830: devscripts: [new] Please include who-permits-upload as a convenient interface to retrieve DM permissions
Hi Jakub, On 26.09.2012 10:32, Jakub Wilk wrote: Shouldn't that be s/permits-upload/permitted-uploads/? Maybe - but that's true for who-uploads - in devscripts already - too. Having who-uploads but who-permitted-uploads sounded wrong to me. That said, I don't mind renaming it to whatever any of you prefers. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#688848: [libmad0] multiarch incompatibility
Package: libmad0
Version: 0.15.1b-7
Severity: normal
--- Please enter the report below this line. ---
Hi,
sudo aptitude install libmad0:i386
The following NEW packages will be installed:
libmad0:i386{b}
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/80.0 kB of archives. After unpacking 135 kB will be used.
The following packages have unmet dependencies:
libmad0 : Conflicts: libmad0:i386 but 0.15.1b-7 is to be installed.
libmad0:i386 : Conflicts: libmad0 but 0.15.1b-7 is installed.
How can i install libmad0:i386 ?
Thank you.
Guy
--- System information. ---
Architecture: amd64
Kernel: Linux 3.2.0-3-amd64
Debian Release: wheezy/sid
500 unstableqgis.org
500 unstableftp.fr.debian.org
500 testing ftp.fr.debian.org
500 stable dl.google.com
500 stable deb.opera.com
500 squeeze deb.playonlinux.com
500 hts www.lonelycoder.com
200 unstablewww.deb-multimedia.org
150 experimentalftp.fr.debian.org
--- Package information. ---
Depends (Version) | Installed
==-+-===
libc6 (= 2.2.5) |
Package's Recommends field is empty.
Package's Suggests field is empty.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636554: jruby: New upstream release
On 25/09/12 19:02, berta...@ptitcanardnoir.org wrote: On Tue, Sep 25, 2012 at 02:25:04PM +0100, Alex Young wrote: snip The work was done to repackage jruby-1.6.7.2 in June: http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2012-June/039090.html Yeah, I saw this message. Well done. It wasn't me, although I had a small hand in organising it :-) It had no response. I presume that's because it re-ships the jars it requires rather than depending on existing Debian packages where they're available. If I were to suggest a starting point, it would be to get its dependencies up to date. I agree, shipping the jars from the upstream source is quite a violation of Debian's policy, so this upload won't be accepted I think. It could go back into non-free until the dependencies are sorted out, surely? -- Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688850: qa.debian.org: DDPO shows wrong upstream version of package zgv
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: ddpo Hi, DDPO shows wrong upstream version (5.9-bin) for package zgv: http://qa.debian.org/developer.php?login=Boris%20Pek http://qa.debian.org/developer.php?login=packa...@qa.debian.org uscan shows correct version (5.9) and PTS shows nothing (which is correct while package don't need update): http://packages.qa.debian.org/z/zgv.html Also web page for watch file results looks strange: http://qa.debian.org/cgi-bin/watch?pkg=zgv Please fix it. Best regards, Boris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688851: sup-mail: crashes on startup
Package: sup-mail Version: 0.12.1+git20120407.aaa852f-1 Severity: important On startup sup-mail crashes. It started crashing like this after i ran sup-config and added sources. Unsure why. avtobiff@pong:~$ sup-mail /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': iconv will be deprecated in the future, use String#encode instead. /usr/lib/ruby/vendor_ruby/sup/util.rb:556:in `method_missing': no Redwood::HookManager instance defined in method call to run! (RuntimeError) from /usr/bin/sup-mail:381:in `module:Redwood' from /usr/bin/sup-mail:80:in `main' -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.9-vs2.3.2.7 (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 sup-mail depends on: ii libxapian-ruby1.9.1 1.2.12-2 ii ruby-chronic 0.6.7-2 ii ruby-eventmachine0.12.10-3 ii ruby-highline1.6.13-2 ii ruby-locale 2.0.5-5 ii ruby-lockfile2.1.0-2 ii ruby-mime-types 1.19-1 ii ruby-ncurses 1.3.1-2 ii ruby-rubymail1.0.0-1 ii ruby-trollop 1.16.2-3 ii ruby-yajl1.1.0-1 ii ruby1.9.11.9.3.194-1 Versions of packages sup-mail recommends: ii ruby-gpgme 2.0.0-2 sup-mail 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#688848: [pkg-mad-maintainers] Bug#688848: [libmad0] multiarch incompatibility
merge 653676 688848
thanks
On Wed, Sep 26, 2012 at 10:42:04AM +0200, Guy Roussin wrote:
Package: libmad0
Version: 0.15.1b-7
Severity: normal
--- Please enter the report below this line. ---
Hi,
sudo aptitude install libmad0:i386
The following NEW packages will be installed:
libmad0:i386{b}
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/80.0 kB of archives. After unpacking 135 kB will be used.
The following packages have unmet dependencies:
libmad0 : Conflicts: libmad0:i386 but 0.15.1b-7 is to be installed.
libmad0:i386 : Conflicts: libmad0 but 0.15.1b-7 is installed.
How can i install libmad0:i386 ?
We haven't applied the patch for multiarch yet. There is a patch
in http://bugs.debian.org/653676
Kurt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678636: dm-crypt partitions not further working: possible workaround
Sorry for creating bug report #688846 without noticing #678636 is already there. Sounds to me that both addresses the same problem. Maybe merge them? I also found some kind of workaround that at least seems to work for me. Thanks, Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688853: dspam: long line in message body causes '530 5.2.0 Message is empty. Aborting.'
Package: dspam Version: 3.10.1+dfsg-3~bpo60+1 Severity: critical dspam sends '530 5.2.0 Message is empty. Aborting.' while receiving incorrect spam message with long-long line, for example with length about 300K bytes: Content-Type: application/octet-stream; name=Pricediler.xls Content-Transfer-Encoding: base64 Content-Disposition: attachment 0M8R4KGxGuEAPgADAP7/CQAGAAAJTwQAEAAA/v///wD+AEYEAA...(whole length of the line is about 300K bytes) It causes MTA (exim in my case) to fail with 'Broken pipe' message for dspam router and use retries to send other emails to other recepients, so messages are deferred and delivered with delay. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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#688852: RFP: libcrypt-smimeengine-perl -- Interface to OpenSSL for SMIME commands with hardware
Package: wnpp Severity: wishlist * Package name: libcrypt-smimeengine-perl Version : 0.01 Upstream Author : fan...@exentrica.it * URL : http://search.cpan.org/~flazan/Crypt-SMimeEngine-0.01/SMimeEngine/lib/Crypt/SMimeEngine.pm * License : GPL Programming Lang: C/Perl Description : Interface to OpenSSL for SMIME commands with hardware It is a simple interface with native function of openssl for SMIME manipulation. It can be work with compatible openssl hardware engines. At this time the module does not realize encription/description functions. Write to the author if you are interested. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688486: upstream feedback
Patch looks fine, fixed as suggested in UPSTREAM Subversion 24008. Thanks for the suggestion / fix. -Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610712: [devscripts] Allow to check cryptographic signatures
http://www.phpmyadmin.net/home_page/security/PMASA-2012-5.php clearly shows the problematic situation of not having cryptographic signatures or tools to check it offline. This could easily break the trust chain and therefore introduce backdoors in Debian even when upstream and Debian packagers didn't do anything wrong. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688778: [Pkg-libvirt-maintainers] Bug#688778: /usr/bin/virsh: vbox:///session uri undocumented
Excerpts from Guido Günther's message of Wed Sep 26 08:21:06 +0200 2012: On Tue, Sep 25, 2012 at 06:08:06PM +0200, Michal Suchanek wrote: Package: libvirt-bin Version: 0.10.1-2 Severity: normal File: /usr/bin/virsh Hello, vbox:///session is the default uri in virsh but it is not documented in the man page. Because it isn't (from the manpage): LIBVIRT_DEFAULT_URI The hypervisor to connect to by default. Set this to a URI, in the same format as accepted by the connect option. This overrides the default URI set in any client config file and prevents libvirt from probing for drivers. So libvirt is autoprobing by default. I agree that this could probably be documented more prominently. And it autoprobes an uri which is not listed as a supported uri in the man page. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688830: devscripts: [new] Please include who-permits-upload as a convenient interface to retrieve DM permissions
On 12-09-26 at 10:38am, Arno Töll wrote: Hi Jakub, On 26.09.2012 10:32, Jakub Wilk wrote: Shouldn't that be s/permits-upload/permitted-uploads/? Maybe - but that's true for who-uploads - in devscripts already - too. Having who-uploads but who-permitted-uploads sounded wrong to me. That said, I don't mind renaming it to whatever any of you prefers. I suggest naming it who-can-upload - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#688848: [pkg-mad-maintainers] Bug#688848: [libmad0] multiarch incompatibility
How can i install libmad0:i386 ? We haven't applied the patch for multiarch yet. There is a patch in http://bugs.debian.org/653676 Kurt Kurt, Thank you for your quick response, Can I find the binaries somewhere ? ... or the debian way to patch and compile these two packages (libmad0:i386 and libmad0:amd64). Guy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688848: [pkg-mad-maintainers] Bug#688848: Bug#688848: [libmad0] multiarch incompatibility
On Wed, Sep 26, 2012 at 11:15:20AM +0200, Guy Roussin wrote: How can i install libmad0:i386 ? We haven't applied the patch for multiarch yet. There is a patch in http://bugs.debian.org/653676 Kurt Kurt, Thank you for your quick response, Can I find the binaries somewhere ? ... or the debian way to patch and compile these two packages (libmad0:i386 and libmad0:amd64). You will need to make your own source package with that patch applied and build it for both i386 and amd64. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682388: [PATCH] Fix string null termination and SIGABRT from glibc
According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682388 the string is not null terminated when too much data is read. This patch fixes the crashes for me. My traces: PowerTOP 2.1 Overview Idle stats Frequency stats Device stats Tunab Package |CPU 0 POLL0.0%| POLL0.0%0.0 ms C1 0.0%| C1 0.0%0.0 ms C2 3.8%| C2 5.4%0.2 ms C3 12.4%| C3 20.9%1.7 ms |CPU 1 | POLL0.0%0.0 ms | C1 0.0%0.2 ms | C2 2.2%0.2 ms | C3 3.8%0.9 ms *** stack smashing detected ***: /usr/local/sbin/powertop terminated === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb7d7be70] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe4e1a)[0xb7d7be1a] /usr/local/sbin/powertop[0x8067a01] ESC Exit |/usr/local/sbin/powertop[0x8067ce7] /usr/local/sbin/powertop[0x806b727] /usr/local/sbin/powertop[0x8070d62] /usr/local/sbin/powertop[0x806c2e6] /usr/local/sbin/powertop[0x8089ecf] /usr/local/sbin/powertop[0x804df42] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7cade46] /usr/local/sbin/powertop[0x804e0f1] === Memory map: 08048000-080af000 r-xp 08:02 2336756/usr/local/sbin/powertop 080af000-080b rw-p 00067000 08:02 2336756/usr/local/sbin/powertop 080b-1022a000 rw-p 00:00 0 [heap] b68c6000-b69c7000 rw-p 00:00 0 b6aaa000-b6acb000 rw-p 00:00 0 b6acb000-b6b4c000 rw-s 00:09 5025 anon_inode:[perf_event] b6b4c000-b6bcd000 rw-s 00:09 5025 anon_inode:[perf_event] b6bcd000-b6c4e000 rw-s 00:09 5025 anon_inode:[perf_event] b6c4e000-b6ccf000 rw-s 00:09 5025 anon_inode:[perf_event] b6ccf000-b6d5 rw-s 00:09 5025 anon_inode:[perf_event] b6d5-b6dd1000 rw-s 00:09 5025 anon_inode:[perf_event] b6dd1000-b6e52000 rw-s 00:09 5025 anon_inode:[perf_event] b6e52000-b6ed3000 rw-s 00:09 5025 anon_inode:[perf_event] b6ed3000-b6f54000 rw-s 00:09 5025 anon_inode:[perf_event] b6f54000-b6fd5000 rw-s 00:09 5025 anon_inode:[perf_event] b6fd5000-b7056000 rw-s 00:09 5025 anon_inode:[perf_event] b7056000-b70d7000 rw-s 00:09 5025 anon_inode:[perf_event] b70d7000-b7158000 rw-s 00:09 5025 anon_inode:[perf_event] b7158000-b71d9000 rw-s 00:09 5025 anon_inode:[perf_event] b71d9000-b725a000 rw-s 00:09 5025 anon_inode:[perf_event] b725a000-b72db000 rw-s 00:09 5025 anon_inode:[perf_event] b72db000-b735c000 rw-s 00:09 5025 anon_inode:[perf_event] b735c000-b73dd000 rw-s 00:09 5025 anon_inode:[perf_event] b73dd000-b745e000 rw-s 00:09 5025 anon_inode:[perf_event] b745e000-b74df000 rw-s 00:09 5025 anon_inode:[perf_event] b74df000-b756 rw-s 00:09 5025 anon_inode:[perf_event] b756-b75e1000 rw-s 00:09 5025 anon_inode:[perf_event] b75e1000-b7662000 rw-s 00:09 5025 anon_inode:[perf_event]
Bug#503310: Any news ?
Hi, Is there any news on this old bug? Best regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686038: [BTS#686038] templates://fpc/{control,fp-compiler.templates}.in
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/09/2012 04:33, Abou Al Montacir a écrit : I'm considering also submitting an ar.po file, but I don't know if Arabic is supported by debconf I'm not aware of Arabic not supported by debconf, on the contrary: I often deal with ar.po files, so do not hesitate ;). Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJQYtFKAAoJELgqIXr9/gnyoNMQAIX6lxODUQB0Lg51GG3RXxJH 38aR2g4T2dkBkGtkQnTqiL6Ky9QLwvewxpCu+RjFgqy5Jf4uhVpoB/8Sh4VSO7H+ tU36rY8Sc/5nc0pPb/fclj9/KlmG0quyov4Ci5h6YZ99G9iQliZH0hR21tuNz2t9 cQvo/XgTUbnTb8l7YviTtxsZ0s9Zl6CCIhJoq4X5c6SAoYm0KhwTc6ZpDcdtMSzH RLNJjZdBXP8MMWQv1HADKk0nHK9U0FlwZox8WbiHW6chQTRdVk+IlLqcsRlq1X+I D7UYcfwL1vkwHnLzt2vcaIHTCTXnFyDDwiR3lDEnbAANiOu32a4P/PoBcsJgLT3K tFFxcWA0VteWiHeAQWiwpWWOrbwoIO/BCEYAUklesPxqJHWZYj4aW4Ms7KNMG44I FraYsIP5ILEZYeJyaQeQ2zX0H/2DhXkI7VgpetpwqrBNTxYMoEz0zmwl1y8Ssm6U GlQxgctPu/WHUsS0ldGY8xXqr3HVt9Qg85DuFsRXEkh0T+kWSarg5LGRlqmkL6yJ 9qj4EQQ+jq1pqoQocwp2TBpAO53DdOWZbG/HJ9fYrkvpM3B6dC5WrV5Jg2LlRm4Q ZkD2nE1WbbGUgrGgMzrVggS5EQodpXFU+6uazNjbDFGQwwGSu8IKdWlChnMdc5MY p0H2Cr2IQ/f5aUn+KqKa =h82u -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#672934: tagging 672934
Hello again! On Tue, Sep 25, 2012 at 03:07:54PM +0200, Aurelien Jarno wrote: [...] Anything someone can help out with? You can build it and try it. Would like to report that I'm getting test failures First build these tests failed: Encountered regressions that don't match expected failures: tst-cputimer1.out, Error 1 tst-eintr1.out, Error 1 The cputimer1 test said timer returned too soon. I did two more (clean) builds and then only the eintr1 test failed. tst-eintr1.out said: [lots.of.dots]..tf1: pthread_create failed: Resource temporarily unavailable tf1: pthread_create failed: Resource temporarily unavailable and on third attempt it said: [lots.of.dots]tf1: pthread_create failed: Resource temporarily unavailable I'll disable tests for now to get through the build. If you have any suggestions or anything you want me to test, please let me know! :) Fwiw, I'm on amd64 with a freshly installed Debian Wheezy system. -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682388: Patch works on powertop 2.0 in unstable
tag 682388 +patch thanks The provided patch works also on powertop 2.0 version in unstable, and on the latest git version (2.1.1 something). -Mikko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687526: reminder: unblock (pre-approval) slbackup 0.0.12-4
Dear Release Team, any news on my unblock request (pre-approval) of slbackup 0.0.12-4? Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpn981PonCfg.pgp Description: Digitale PGP-Unterschrift
Bug#688800: mplayer2: can not seek wvc1 videos
On Wed, 2012-09-26 at 07:21 +0200, Reinhard Tartler wrote: wvc1 videos are unseekable in mplayer2. For example if I try to seek 10 seconds forward using right key, then the video freezes. A sample video is here: http://ftyps.com/unrelated/vc1_in_wmv.wmv I can reproduce the problem with the default libavformat demuxer: mplayer -demuxer lavfpref vc1_in_wmv.wmv But not with the internal asf demuxer: mplayer -demuxer asf vc1_in_wmv.wmv Interestingly, avplay does not have any problems with seeking: avplay vc1_in_wmv.wmv This doesn't mean that libavformat was bugfree, this may as well indicate a problem in the way how mplayer2 drives libavformat. Uoti, can you have a look at this? Thanks! This is a bug in the libavcodec VC-1 decoder. It outputs a frame from the old position after a seek flush. Actually, the codec object in vc1dec.c seems to be completely missing the needed .flush field entry. That it happens to work closer to normal with the internal demuxer is just a side effect of a different timing mode used with the old demuxer; the decoder misbehavior does not have the same effects in that case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687402: beanstalkd: FTBFS: tests failed
That's fine Keith. Let me know please when you have something ready. -- Every great idea is worthless without someone to do the work. --Neil Williams signature.asc Description: Digital signature
Bug#688843: licensecheck: detect BDS-3-clause as BSD-2-clause
On Wed, 26 Sep 2012 18:30:50 Adam D. Barratt wrote: I think my opinion here is fairly clear at the moment, but I'm also not the most active of the maintainers right now, so I'll leave things to see if any of the others comment. I see your point. I'm practically convinced but out of curiosity I'd like to see another another response to this. Otherwise please feel free to close at your discretion. Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Bug#418324: #418324 xterm: baffling weirdness with 9x15 font and some Unicode glyphs
given that the explanation was complete, suggesting a workaround and that no further reply was given, this can be closed. -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#619711: console-setup: breaks copying keymap to initramfs
On Fri, Sep 21, 2012 at 12:54:12PM +0200, Michael Prokop wrote: Anton, while working on this issue I noticed that setupcon doesn't always return an according error code. Example: http://michael-prokop.at/screeni/gkrellShoot_12-09-21_112226.png Could you please take care of that? Yes, this shouldn't be a problem. Anton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686207: [LCFC] templates://lazarus/{lcl-utils.templates,control}.in
On Sun, 2012-09-16 at 21:11 +0200, Paul Gevers wrote: Hi [I am not the maintainer of Lazarus, but interested as I maintain a dependency: Winff.] On 16-09-12 13:49, Justin B Rye wrote: Paul Gevers wrote: In the control.in file, I notice a lot of metapackages which had not architecture: all. This is not really translation related but anyway. I could imaging that it ensures that on all platforms it depends on the correct version in that architecture, but is that really what we want? I don't know what you want; I'm not even sure what happens with meta/dependency-packages in cases like this. (So much for compile anywhere!) I would say, this is up to the maintainer, but I suggest to use architecture All for all metapackages. Yes could be changed to Architecture: all Wait, don't you mean one set of configuration files? (And capitalised Lazarus.) Yes. Confirm Therefore the update-alternatives can be used to switch between versions of the configuration files. No need for the, and I'm not sure about that therefore. Maybe it should be instead? And it would be clearer if it said something about switching to an appropriate config to match the Lazarus version. (Or is it that you switch the lazarus alternative to match the lazarus-ide alternative?) I tried to understand the logic in the package and I think all alternatives are slave by default (see below). All these references to configuration files get repetitive. Agreed. Okay, this is making a lot more sense. Thanks, that is what I wanted to achieve. _Description: Rename /etc/lazarus to /etc/lazarus.bak? There is a real directory at /etc/lazarus, probably from a previous installation. However, Lazarus now supports keeping multiple versions Let's make it explicit that it is the Lazarus SUITE that support the multiple versions. installed at the same time and using the alternatives system to set a default version for: * lazarus-ide (the IDE); * lazarus (the configuration file and helper tools). configuration files Looking into it, I now see that there are more items in the alternatives system for Lazarus. As they are by default all in slave mode, do we need to mention a list? This would avoid some of the confusion latter on, I would say the /etc/lazarus/ issue in this template is PART of the Lazarus multiple version support. Let's try to make that clear. So again some improvement: _Description: Rename /etc/lazarus to /etc/lazarus.bak? The Lazarus suite now supports keeping multiple versions installed at the same time and using the alternatives system to set proper defaults. Normally, the latest version of any component is used. . To use the alternatives system on the system-wide configuration of the Lazarus suite, /etc/lazarus needs to be under control of the alternatives system. Currently there is a real directory at /etc/lazarus, probably from a previous installation. In order to start using the alternatives system on the configuration you must accept renaming /etc/lazarus. If you don't, you will need to review the configuration on every version update of Lazarus as, unfortunately, the configuration files are not always backward-compatible. Also switching between different versions might need more intervention. . If you have made changes to your configuration files, you will probably need to review them and apply them to all versioned configurations, as they will not automatically propagate. I hope I did not misunderstand how the package uses the alternatives system and I believe the above text is a lot clearer in what the user should take into account to determine the answer here. I'm globally OK with this. I think we can freeze this and call for internationalization. Cheers, signature.asc Description: This is a digitally signed message part
Bug#683942: #683942 xterm: alternate screen scrolling
I've applied a change for this which will appear in the #282 updates. -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#688854: texlive-fonts-extra: Please move fourier to texlive-fonts-recommended
Package: texlive-fonts-extra Version: 2012.20120611-2 Severity: wishlist Hi, I'd consider Adobe Utopia as one of the usual fonts and was astouned to find fourier it in the behemoth that is texlive-fonts-extra. The same could be said about fouriernc and New Century Schoolbook . BTW, where is Garamond gone? - Fabian -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (901, 'testing'), (501, 'unstable'), (401, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#688804: m4 can accidentally link to libsigsegv
Hi. [ Cc: debian-release for advice ]. I have received this report which is really two different bugs: A) The initial one reported by Igor: Building m4 creates a package linked with libsigsegv or not depending on the environment. This should never happen in a Debian package and that's why we have Build-Depends, Build-Conflicts and so on. A Debian package, when built, should always create the same .deb. B) The real fix by Eric: m4 should really be linked against libsigsegv. Release managers: Is it too late in the freeze to fix B? (The patch would be very small, it would be a matter of adding a Build-Depends). In case it is too late: May I fix bug A in wheezy at least? (In this case the .deb would not change in functionality, but the build process would never create a different .deb by accident). Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688855: linphone: not compiled with vp8 video codec
Package: linphone Version: 3.5.2-10 Severity: serious Justification: 0: makes the package in question unusable or mostly so Dear Maintainers, Linphone supports natively the vp8 video codec. However, the debian/control file doesn't depend on libvpx-dev. The vp8 codec is quickly replacing theora as the common patent free video codec for voip. This is serious, the lack of support in Wheezy would make Linphone irrelevant for the next few years. Trivial patch attached. Cheers, Guillaume Beraudo -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linphone depends on: ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libavcodec536:0.8.3-7 ii libavutil51 6:0.8.3-7 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgsm1 1.0.13-4 ii libgtk2.0-0 2.24.10-2 ii liblinphone43.5.2-10 ii libmediastreamer1 3.5.2-10 ii libnotify4 0.7.5-1 ii libogg0 1.3.0-4 ii libortp83.5.2-10 ii libpango1.0-0 1.30.0-1 ii libspeex1 1.2~rc1-6 ii libspeexdsp11.2~rc1-6 ii libswscale2 6:0.8.3-7 ii libtheora0 1.1.1+dfsg.1-3.1 ii libvpx1 1.1.0-1 ii libx11-62:1.5.0-1 ii libxv1 2:1.0.7-1 ii linphone-nogtk 3.5.2-10 linphone recommends no packages. Versions of packages linphone suggests: ii yelp 3.4.2-1+b1 -- no debconf information --- old/control 2012-09-26 12:40:45.941102350 +0200 +++ new/control 2012-09-26 12:41:07.973103419 +0200 @@ -11,7 +11,7 @@ libasound2-dev [linux-any], libv4l-dev [linux-any], libspeex-dev, libspeexdsp-dev, libsamplerate0-dev, libxml-parser-perl, libgsm1-dev, - libgtk2.0-dev, libglade2-dev, libtheora-dev, + libgtk2.0-dev, libglade2-dev, libtheora-dev, libvpx-dev, libxv-dev, libavcodec-dev, libreadline-dev, libsdl1.2-dev, libswscale-dev Standards-Version: 3.9.3
Bug#688792: syntax error
tag 688792 +moreinfo thanks Ross, Thanks for the report. First of all whenever I play with mysql inside a chroot I have to bring down the real mysql server as otherwise there is a port clash. (I'm not sure how piuparts avoids this issue.) And that certainly causes upgrade failures. That said I have not yet managaed to get the postinst script to run that SQL. Given that the code is there that should just be a matter of me studying precisely what is needed to trigger it. Also I am fairly sure that all the maintenance scripts need a thorough review but I am trying quite hard to not make any non-essential changes until the freeze is over. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688856: linphone: not build with notification support
Package: linphone Version: 3.5.2-10 Severity: normal Dear Maintainer, Linphone supports notification. It should be activated by adding libnotify-dev to the build dependencies. Guillaume -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linphone depends on: ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libavcodec536:0.8.3-7 ii libavutil51 6:0.8.3-7 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgsm1 1.0.13-4 ii libgtk2.0-0 2.24.10-2 ii liblinphone43.5.2-10 ii libmediastreamer1 3.5.2-10 ii libnotify4 0.7.5-1 ii libogg0 1.3.0-4 ii libortp83.5.2-10 ii libpango1.0-0 1.30.0-1 ii libspeex1 1.2~rc1-6 ii libspeexdsp11.2~rc1-6 ii libswscale2 6:0.8.3-7 ii libtheora0 1.1.1+dfsg.1-3.1 ii libvpx1 1.1.0-1 ii libx11-62:1.5.0-1 ii libxv1 2:1.0.7-1 ii linphone-nogtk 3.5.2-10 linphone recommends no packages. Versions of packages linphone suggests: ii yelp 3.4.2-1+b1 -- 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#688857: slapd - Modifications by refint not replicated
Package: slapd Version: 2.4.31-1 Severity: important Modifications made by refint are not replicated. They neither update the modification timestamp nor the CSN used for replication. This is serious data loss, because the replicas gets out of sync pretty quickly. There seems to be no way to recover from this discrepancy without doing a complete replication. While this seems to be known, it is not documented at all in the man-pages related to the refint and memberof overlays. Also it violates the principle of least surprise, because the changes are not limited to operational attributes. Bastian -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-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 Versions of packages slapd depends on: ii adduser3.113+nmu3add and remove users and groups ii coreutils 8.5-1 GNU core utilities ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.13-35 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libgnutls262.12.20-1 GNU TLS library - runtime library ii libldap-2.4-2 2.4.23-7.2OpenLDAP libraries ii libltdl7 2.4.2-1.1 A system independent dlopen wrappe ii libperl5.105.10.1-17squeeze3 shared Perl library ii libsasl2-2 2.1.23.dfsg1-7Cyrus SASL - authentication abstra ii libslp11.2.1-7.8 OpenSLP libraries ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii perl [libmime-base64-p 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii psmisc 22.19-1 utilities that use the proc file s ii unixodbc 2.2.14p2-1ODBC tools libraries Versions of packages slapd recommends: ii libsasl2-modules 2.1.23.dfsg1-7 Cyrus SASL - pluggable authenticat Versions of packages slapd suggests: ii ldap-utils2.4.23-7.2 OpenLDAP utilities -- Configuration Files: /etc/default/slapd changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688854: texlive-fonts-extra: Please move fourier to texlive-fonts-recommended
Am 26.09.2012 12:56, schrieb Fabian Greffrath: I'd consider Adobe Utopia as one of the usual fonts and was astouned to find fourier it in the behemoth that is texlive-fonts-extra. The same could be I fact, it is even mentioned by the psnfss package among the common font: http://www.ctan.org/pkg/psnfss BTW, where is Garamond gone? I have just learned that it's licensed under the Alladin FPL and thus considered non-free. :( - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688639: [SECURITY] [DSA 2550-1] asterisk security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Moritz Please test/report, whether the packages located at http://people.debian.org/~jmm/ fix the problem for you. Could you please publish the source package as well? And is this going to go into squeeze-updates eventually? Cheers Daniel (@moritz: sry for double-posting...) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQYuUBAAoJEIWTgWPaKFdzzTgP+QFfFGoV832ZwcAmhxJvwGko UTh+q4m+HLnpZSmRMJMQsXD1yaL7aPxdX/ro0ZWlE7b4cKYnQJ50MVGvxyWI9OIG ENh1nemiVGvyCsbEKVQ6ockIbRllYT3IWjmaAmKu+/CmmbUjUFafEd/wgRvK5mDG 1C363bXDZla+8NblI/LJnvlvXoP6zt9sgmywdYlg4lZy/x7vo69sUbXXhvcA6f3h kKAqGlQwNdZN4Wc8PhmtQQyFDhK1MM3v+L7jEwgWpTdCMmByPGPiWDn21fQte6Dz joEeUbfRekHTKYKynEN41clfL7SIAyVOhTjt9HfRBss+TjquQ1yQdwt4MXTD8iKE 08XAmIge7mbOW7Edypc/dlHPLn3lxfI/M3kpOKfGL+16SpLRHCFoYzbBAzxF2ASi cWoayD74V/0mE0qWt58/m14ahAFQs6g5ypYKIm+AT2IxNGL9f8Z8XswE+Qm0MQTz qIrWXfe0UZ3lA5gh2ocNh9tVRbY78VtCBKgJKt3DtatBZUAJfyhGDMb0vowL6fp0 YKZnTeozW/fEc6IVuR38Xi19350JFdAlLUUYgeNdM7LFICJvbMFzBTFKXHtQgTgX 5ZsE/Z/WA8A8dUNo0OZ6ZikU+m8zrxYFgXwaYhPVrMcwRbhCDu30H2KSMGVOqoer FeQ0HGCxuE9rjgMO27nR =5J/q -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#669184: I think it is resolved
It seems that VDE and virtio are friends again! I've just done 6 file transfer tests via ssh and nfs and had no issues whatsoever. All of the machines involved: Host and 2 VMs running up to date Debian Wheezy. Good news I guess since its on freeze now... Please let me know if you need any further info. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688687: ess: new stable release 12.09
On 24 September 2012 at 16:23, Cássio M. M. Pereira wrote: | Package: ess | Version: 12.04-4-1 | Severity: wishlist | | Dear ESS Maintainers, | | The core developers of ESS have just released a new stable version | 12.09: https://stat.ethz.ch/pipermail/ess-help/2012-September/008212.html | | It would be nice to have the new version available in Debian, as it | fixes many bugs found in the old release. You missed this: ess (12.09-1) unstable; urgency=low * New upstream version released today -- Dirk Eddelbuettel e...@debian.org Mon, 24 Sep 2012 14:32:49 -0500 I released it within the hour after the upstream release. ;-) Dirk | | Thanks, | Cássio M. M. Pereira | | ___ | ESS-Debian mailing list | ess-deb...@r-project.org | https://stat.ethz.ch/mailman/listinfo/ess-debian -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688845: Acknowledgement (texlive-fonts-extra: Please demote all additional Depends to Recommends)
Furthermore, AFAICT the additional font packages pulled in by texlive-fonts-extra contain fonts in TTF or OTF formats and are thus only useful for xetex and the like, not for standard plain pdflatex. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688858: tor ignore OutboudBindAddress
Package: tor Version: 0.2.2.35-1~squeeze+1 Severity: important My server has 2 IP address - X.X.X.X and Y.Y.Y.Y. I want run tor relay only at X.X.X.X. /etc/tor/torrc: --- ORPort 9090 ORListenAddress X.X.X.X DirListenAddress X.X.X.X ExitPolicy accept *:80,accept *:443,accept *:110,accept *:143,accept *:993,accept *:995,accept *:6660-6669,accept *:6697,accept *:7000-7001,accept *:706,accept *:1863,accept *:5050,accept *:5190,accept *:5222,accept *:5223,accept *:8300,accept *:,reject *:* OutboundBindAddress X.X.X.X --- But tor initalise connect from first server IP address and I see in log: --- Sep 26 14:29:45.266 [warn] Your server (Y.Y.Y.Y:9090) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Sep 26 14:29:45.266 [warn] Your server (Y.Y.Y.Y:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. --- -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tor depends on: ii adduser3.112+nmu2add and remove users and groups ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libssl0.9.80.9.8o-4squeeze13 SSL shared libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages tor recommends: ii logrotate 3.7.8-6 Log rotation utility ii tor-geoipdb 0.2.2.35-1~squeeze+1 geoIP database for Tor ii torsocks1.0~epsilon+dfsg1-1 use socks-friendly applications wi ii tsocks 1.8beta5-9.1 transparent network access through Versions of packages tor suggests: pn mixmaster none (no description available) pn polipo | privoxy none (no description available) pn socat none (no description available) pn tor-arm none (no description available) pn xul-ext-torbutton none (no description available) -- 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#688797: [Pkg-openldap-devel] Bug#688797: openldap 2.4.23 and 2.4.31 slapd server process frequently stops during everyday use
On Tue, Sep 25, 2012 at 03:04:16PM -0700, Quanah Gibson-Mount wrote: --On Tuesday, September 25, 2012 6:35 PM +0100 Jose Calhariz jose.calha...@ist.utl.pt wrote: Package: slapd Version: 2.4.31-1~bpo60+2 Severity: important Tags: upstream During normal day use the slapd daemon stops and have to be restarted by a watchdog daemon. This problem is present on openldap 2.4.23 and on 2.4.31 (private backport from wheezy). From a previous investigation with 2.4.23 this is a problem of deadlocks in Berleckey DB. The backport was in the hope that this was the bug #618904. But our problem is still present on 2.4.31. Exists information from a db*_stat -CA that I will send in the next email. What version of BDB are you linked to? We follow Debian on this. Openldap 2.4.31 is linked to BDB 5.1.29 and openldap 2.4.23 is linked to BDB 4.8.30. There are consistent reports of deadlock issues with BDB 5.3. I would recommend against using that version of BDB. 4.7.25+patches has been solid for me. All indications with the BDB deadlock issue in 5.3 is that it is a BDB bug, and thus nothing to do with OpenLDAP. It may exist in other 5.x versions of BDB. --Quanah In attach there is a db5.1_stat -CA from one server with problems, openldap 2.4.31. -- -- Há boas razões para proteger a Terra. É o modo mais seguro e correto de prolongar a lucratividade --Paul Allaire root@aqua:/var/lib/ldap# db5.1_stat -CA Default locking region information: 117 Last allocated locker ID 0x7fff Current maximum unused locker ID 9 Number of lock modes 1500Maximum number of locks possible 1500Maximum number of lockers possible 1500Maximum number of lock objects possible 40 Number of lock object partitions 52 Number of current locks 435 Maximum number of locks at any one time 17 Maximum number of locks in any one bucket 0 Maximum number of locks stolen by for an empty partition 0 Maximum number of locks stolen for any one partition 43 Number of current lockers 45 Maximum number of lockers at any one time 31 Number of current lock objects 232 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 86M Total number of locks requested (86727631) 86M Total number of locks released (86727402) 0 Total number of locks upgraded 110 Total number of locks downgraded 20092 Lock requests not available due to conflicts, for which we waited 174 Lock requests not available due to conflicts, for which we did not wait 1 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 1MB 240KB The size of the lock region 47562 The number of partition locks that required waiting (0%) 2396The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 75217 The number of locker allocations that required waiting (0%) 0 The number of region locks that required waiting (0%) 3 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: LockRegion type 5 Region ID __db.005Region name 0x7f0c18c97000 Region address 0x7f0c18c97138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 87 allocations, 0 failures, 0 frees, 1 longest Allocations by power-of-two sizes: 1KB 2 2KB 0 4KB 41 8KB 40 16KB 0 32KB 0 64KB 2 128KB 0 256KB 2 512KB 0 1024KB 0 REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 287 Lock region region mutex [0/2777 0% 16831/139689947899648] 2053locker table size 2053object table size 952 obj_off 218128 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status - Object --- 80001647 dd=10 locks held 0write locks 0pid/thread 3972/140206564955904 priority 100 80001647 READ 1 WAITistPersonServices.bdb page 28 80001648 dd= 9 locks held 0write locks 0pid/thread 3972/140206539781888 priority 100 80001648 READ 1 WAITistPersonServices.bdb page 28 80001649 dd= 8 locks held 0write locks 0pid/thread 3972/140206514607872 priority 100 80001649 READ 1 WAITistPersonServices.bdb page 28 8000164a dd= 7 locks held 0write locks 0pid/thread 3972/140206489433856 priority 100 8000164a READ 1 WAIT
Bug#688859: Upload auctex 11.86 to squeeze-backports
Package: auctex Severity: wishlist Version 11.86-10.1 Please upload latest auctex version to Debian squeeze-backports. Apart from a nearly-empty changelog entry nothing needs to be adapted to make the package fit into a squeeze installation. Thanks, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp9FHQHLTX5a.pgp Description: Digitale PGP-Unterschrift
Bug#688687: ess: new stable release 12.09
Yes, indeed, Dirk's response time was absolutely awesome. He should rather be danked for that! Martin Am 26.09.2012 13:39 schrieb Dirk Eddelbuettel e...@debian.org: On 24 September 2012 at 16:23, Cássio M. M. Pereira wrote: | Package: ess | Version: 12.04-4-1 | Severity: wishlist | | Dear ESS Maintainers, | | The core developers of ESS have just released a new stable version | 12.09: https://stat.ethz.ch/pipermail/ess-help/2012-September/008212.html | | It would be nice to have the new version available in Debian, as it | fixes many bugs found in the old release. You missed this: ess (12.09-1) unstable; urgency=low * New upstream version released today -- Dirk Eddelbuettel e...@debian.org Mon, 24 Sep 2012 14:32:49 -0500 I released it within the hour after the upstream release. ;-) Dirk | | Thanks, | Cássio M. M. Pereira | | ___ | ESS-Debian mailing list | ess-deb...@r-project.org | https://stat.ethz.ch/mailman/listinfo/ess-debian -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ___ ESS-Debian mailing list ess-deb...@r-project.org https://stat.ethz.ch/mailman/listinfo/ess-debian
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please approve the following changes for package libxvmc
As we are not going to get libxvmc turned to multi-arch for wheezy (see
#640499) I'm now trying another approach with minimal changes to the
libxvmc package:
Can we add a new package
Package: libxvmc1-i386
Section: libs
Priority: extra
Architecture: i386
Multi-arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
Description: X11 Video extension library (alternate i386 package)
that ships another copy of the libraries in /usr/lib/i386-linux-gnu/
To avoid installing libxvmc1-i386:i386 and libxvmc1:i386 at the same
time and have two copies of the same library available, I'm adding
Package: libxvmc1
Conflicts: libxvmc1-i386 [i386]
and to avoid picking up a dependency on libxvmc1-i386 by accident, its
shlibs file points to libxvmc1.
I added a lintian-overrides file, but that is not being installed as I
wanted to avoid changing anything in debian/rules.
Note that this new package does not ship the conffile as it is expected
to be only installed along libxvmc1:amd64 which comes with the conffile.
(This dependency can't be expressed by package relationships.)
This will keep the existing non-multiarch libxvmc1 unchanged, the build
system is untouched, nothing will start to use the alternate copy
package accidently. For libgl1-nvidia-glx:i386 to actually pick up this
alternate library, we need to add a shlibs.local file (in
nvidia-graphics-drivers) with
libXvMC 1 libxvmc1 | libxvmc1-i386 [i386]
I chose to add the extra package to the libxvmc source package as that
will avoid forking (and therefore code duplication) and getting libxvmc1
and libxvmc1-i386 out of sync. Even with a second copy in the a binary
package in the archive, there is no overhead in case a security update
for libxvmc should be neccessary.
Judging by the number of bug reports, it is really important for our
users to restore the ability to run 32-bit OpenGL applications on a
amd64 system and get accelleration by the non-free nvidia driver.
That was working in squeeze and will be considered as a serious
regression if this is not getting fixed in some way for wheezy.
See e.g. #685054, #686033, #676723, #688714
I'll be happy to assist getting a proper multi-arch libxvmc into jessie
and to clean up this temporary package that we need for wheezy.
Andreas
diffstat for libxvmc_1.0.7-1 libxvmc_1.0.7-1.1
debian/libxvmc1-i386.install |2 ++
debian/libxvmc1-i386.lintian-overrides |4
debian/libxvmc1-i386.shlibs|2 ++
libxvmc-1.0.7/debian/changelog | 12
libxvmc-1.0.7/debian/control | 26 ++
5 files changed, 46 insertions(+)
diff -u libxvmc-1.0.7/debian/control libxvmc-1.0.7/debian/control
--- libxvmc-1.0.7/debian/control
+++ libxvmc-1.0.7/debian/control
@@ -22,6 +22,7 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
+Conflicts: libxvmc1-i386 [i386]
Description: X11 Video extension library
libXvMC provides an X Window System client interface to the
XVideo-MotionCompensation extension to the X protocol.
@@ -37,6 +38,31 @@
This module can be found at
git://anongit.freedesktop.org/git/xorg/lib/libXvMC
+Package: libxvmc1-i386
+Section: libs
+Priority: extra
+Architecture: i386
+Multi-arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
+Description: X11 Video extension library (alternate i386 package)
+ libXvMC provides an X Window System client interface to the
+ XVideo-MotionCompensation extension to the X protocol.
+ .
+ The XVideo-MotionCompensation extension allows for further accelerated drawing
+ of videos. Video data may be sent at earlier stages of the decoding pipeline
+ than raw YUV data. At the moment, driver support for XvMC is poor to
+ non-existent.
+ .
+ More information about X.Org can be found at:
+ URL:http://www.X.org
+ .
+ This module can be found at
+ git://anongit.freedesktop.org/git/xorg/lib/libXvMC
+ .
+ This is a multiarchified package intended to be co-installable with
+ libxvmc1:amd64.
+
Package: libxvmc1-dbg
Section: debug
Architecture: any
diff -u libxvmc-1.0.7/debian/changelog libxvmc-1.0.7/debian/changelog
--- libxvmc-1.0.7/debian/changelog
+++ libxvmc-1.0.7/debian/changelog
@@ -1,3 +1,15 @@
+libxvmc (2:1.0.7-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Add libxvmc1-i386 package, a partially multiarchified package that is
+co-installable with libxvmc1:amd64. Works around missing multiarch
+support, see #640499. Let libxvmc1:i386 conflict with this new package.
+The .shlibs points to libxvmc1 instead of libxvmc1-i386 to avoid
+accidentally adding a dependency on this
Bug#688639: [SECURITY] [DSA 2550-1] asterisk security update
On Wed, Sep 26, 2012 at 01:20:33PM +0200, Daniel Reichelt wrote: Hi Moritz Please test/report, whether the packages located at http://people.debian.org/~jmm/ fix the problem for you. Could you please publish the source package as well? Note that it was built from the squeeze branch of the Subversion repository listed in the package: http://anonscm.debian.org/viewvc/pkg-voip/asterisk/branches/squeeze/ -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688860: xserver-xorg-input-evdev: mouse cursor jumping with absolute input device
Package: xserver-xorg-input-evdev Version: 1:2.7.0-1 Severity: important Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=54353 When running inside a VirtualBox virtual machine with mouse integration enabled, the mouse cursor will randomly jump to the top and/or left of the screen. A workaround is described in https://bugs.freedesktop.org/show_bug.cgi?id=54353#c4, and it works for me, though I can not say what other side effects are caused by not resetting the valuator mask after motion events are posted. (Would have been forwarded to https://www.virtualbox.org/ticket/10853 before I knew this was an Xorg bug.) -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Feb 8 2010 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2044664 Aug 21 20:55 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef] /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 3.2.0-3-amd64 (Debian 3.2.23-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Mon Jul 23 02:45:17 UTC 2012 Xorg X server log files on system: -- -rw-r--r-- 1 root root 31040 May 30 11:27 /var/log/Xorg.1.log -rw-r--r-- 1 root root 31226 Sep 26 12:51 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [2910181.019] X.Org X Server 1.12.3.902 (1.12.4 RC 2) Release Date: 2012-08-19 [2910181.019] X Protocol Version 11, Revision 0 [2910181.019] Build Operating System: Linux 3.2.0-3-amd64 x86_64 Debian [2910181.019] Current Operating System: Linux leela.office.red-redemption.com 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 [2910181.019] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-3-amd64 root=UUID=10911f8b-c532-4347-b502-3108a6f9feba ro console=ttyS0 console=tty0 quiet init=/lib/systemd/systemd splash [2910181.019] Build Date: 21 August 2012 07:36:50PM [2910181.019] xorg-server 2:1.12.3.902-1 (Julien Cristau jcris...@debian.org) [2910181.019] Current version of pixman: 0.26.0 [2910181.019] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [2910181.019] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [2910181.019] (==) Log file: /var/log/Xorg.0.log, Time: Wed Sep 26 12:51:22 2012 [2910181.019] (==) Using system config directory /usr/share/X11/xorg.conf.d [2910181.019] (==) No Layout section. Using the first Screen section. [2910181.019] (==) No screen section available. Using defaults. [2910181.019] (**) |--Screen Default Screen Section (0) [2910181.019] (**) | |--Monitor default monitor [2910181.020] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [2910181.020] (==) Automatically adding devices [2910181.020] (==) Automatically enabling devices [2910181.021] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [2910181.021] Entry deleted from font path. [2910181.021] (WW) The directory /usr/share/fonts/X11/100dpi/ does not exist. [2910181.021] Entry deleted from font path. [2910181.021] (WW) The directory /usr/share/fonts/X11/75dpi/ does not exist. [2910181.021] Entry deleted from font path. [2910181.021] (WW) The directory /usr/share/fonts/X11/100dpi does not exist. [2910181.021] Entry deleted from font path. [2910181.021] (WW) The directory /usr/share/fonts/X11/75dpi does not exist. [2910181.021] Entry deleted from font path. [2910181.021] (WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist. [2910181.021] Entry deleted from font path. [2910181.021] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, built-ins [2910181.021] (==) ModulePath set to /usr/lib/xorg/modules [2910181.021] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [2910181.021] (II) Loader magic: 0x7f48e9324ae0 [2910181.021] (II) Module ABI versions: [2910181.021] X.Org ANSI C Emulation: 0.4 [2910181.021] X.Org Video Driver: 12.1 [2910181.021] X.Org XInput driver : 16.0 [2910181.021] X.Org Server Extension : 6.0 [2910181.023] (--) PCI:*(0:0:2:0) 80ee:beef:: rev 0, Mem @ 0xe000/16777216 [2910181.023] (II) Open ACPI successful (/var/run/acpid.socket) [2910181.023] (II) LoadModule: extmod [2910181.023] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
Bug#678975: libzrtpcpp2: status update?
Package: libzrtpcpp2 Followup-For: Bug #678975 Dear Maintainer, The package is still not in sid and testing. Do you know why it is blocked in experimental? Cheers, Guillaume -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libzrtpcpp2 depends on: ii libc62.13-35 ii libccrtp02.0.3-4 ii libgcc1 1:4.7.1-7 ii libssl1.0.0 1.0.1c-4 ii libstdc++6 4.7.1-7 ii libucommon5 5.2.2-4 libzrtpcpp2 recommends no packages. libzrtpcpp2 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#688772: gnome Depends network-manager-gnome
Russ Allbery writes (Bug#688772: gnome Depends network-manager-gnome): I've been thinking about this over lunch, and I do feel like the gnome metapackage is substantively different than the gnome-core metapackage. I'm not sure if it's sufficiently different to warrant a different decision, but it does seem different enough to warrant a separate discussion. Most of the points that were determinative of our decision on gnome-core apply to gnome too. The historic point of the gnome metapackage is not to just install the base machinery of GNOME in the same way that gnome-core is. It's rather to give the user a complete desktop environment built around GNOME. There have historically been all sorts of applications in there that people may or may not use. It's a fairly heavy-weight metapackage; it pulls in everything from office suites to a mail client. All of that is fine but of course as you yourself wrote: 4. For most applications and components, the only drawback of this would be some additional disk space usage, since the application, despite being installed, wouldn't need to be used. However, network-manager assumes that, if it is installed, it should attempt to manage the system's network configuration. It attempts to avoid overriding local manual configuration, but it isn't able to detect all cases where the user is using some other component or system to manage networking. The user has to take separate, explicit (and somewhat unusual for the average user) action to disable network-manager after it has been installed. So n-m is special. We still have the upgrade problem with network-manager from squeeze gnome to wheezy gnome, but I would expect, if I had the full gnome metapackage installed, for quite a lot to potentially change across versions: new applications added or dropped, new implementations of particular common tasks to be blessed upstream, etc. So I'm not sure if that's as strong of a reason to stick with Recommends in that metapackage. The point is that if a user deliberately deinstalls something (as would have to be the case with a violated Recommends in squeeze), we should not undo that decision willy-nilly. From the point of view of the gnome metapackage, I can see no justification at all for the increased strictness of the dependency. The fact that GNOME upstream have decreed that n-m is part of GNOME Core rather than just part of GNOME isn't relevant to the gnome metapackage, except insofar as it means that the dependency should move down onto gnome-core. To be clear, if I were the GNOME maintainers, I would use Recommends. But I'm not, and I'd rather that they make the call as much as possible. The issues seem very similar to me. It is perhaps less important that people be able to conveniently install a whole application suite without getting n-m. But the upgrade issue is the same and will affect nearly as many users. And on the face of it it is simply entirely wrong to upgrade the dependency. I can see no justification for it. And the maintainers haven't even provided one! Putting aside the communication breakdowns and the heated arguments and so forth, if just the gnome metapackage issue in its current form had come to us cold, I'm trying to work through what decision I'd make. I would have made the same decision. But I'm not convinced that this is the right basis to think about it. It is not a good precedent to set that if a matter is brought to the TC, the maintainer who loses the debate in the TC will do something which undermines the effect of the TC decision and which wasn't proposed in the TC discussion. Having taken hold of the matter and overruled the maintainer, we have a responsibility to see through the consequences, and to avoid backsliding by the maintainer. I'm wondering if we should just document the change to the gnome metapackage in the release notes. I think there's really something to be said for treating this as a compromise position. What you are proposing is a compromise between doing the right thing for our users, and upholding the autonomy of the maintainer. That is contrary to our stated principles. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688765: libpri and hardening flags [was: Re: Bug#688765: FTBFS if built twice in a row]
Dear Release Team, On Wed, Sep 26, 2012 at 01:43:32AM +0200, Tzafrir Cohen wrote: On Tue, Sep 25, 2012 at 03:36:47PM +0200, Helmut Grohne wrote: Source: libpri Version: 1.4.12-2 Severity: serious Justification: fails to build from source The upstream Makefile creates a version.c which is not removed during (make) clean. Thus the second attempt to build the package fails with a message from dpkg-source saying that local changes (to version.c) were detected and the build is aborted. Since the package uses dh, the fix is as simple as: echo version.c debian/clean Applied, thanks for the report. While rebuilding to fix this, I noticed the lintian notice regarding hardening flags. The package use a custom Makefile, which was easy enough to fix. It is a library that is used in a PSTN module of the Asterisk telephony server and thus is network facing for a liberal definition of network (the N in PSTN[1]). Note that libss7 is likely to be similar: both a similar build system and a similar relation to the network. So, should I go ahead and include this fix as well? [1] http://en.wikipedia.org/wiki/PSTN -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688862: linphone: don't depend on ancient automake9
Package: linphone Version: 3.5.2-10 Severity: wishlist Dear Maintainer, Please don't depend on a specific version of automake, especially the buggy automake9. It can prevent build in some situation: src/Makefile.am: installing `./depcomp' /usr/share/automake-1.9/am/depend2.am: am__fastdepOBJC does not appear in AM_CONDITIONAL src/Makefile.am: Objective C source seen but `OBJC' is undefined Guillaume PS: I tested the default automake in wheezy which works correctly. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linphone depends on: ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libavcodec536:0.8.3-7 ii libavutil51 6:0.8.3-7 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgsm1 1.0.13-4 ii libgtk2.0-0 2.24.10-2 ii liblinphone43.5.2-10 ii libmediastreamer1 3.5.2-10 ii libnotify4 0.7.5-1 ii libogg0 1.3.0-4 ii libortp83.5.2-10 ii libpango1.0-0 1.30.0-1 ii libspeex1 1.2~rc1-6 ii libspeexdsp11.2~rc1-6 ii libswscale2 6:0.8.3-7 ii libtheora0 1.1.1+dfsg.1-3.1 ii libvpx1 1.1.0-1 ii libx11-62:1.5.0-1 ii libxv1 2:1.0.7-1 ii linphone-nogtk 3.5.2-10 linphone recommends no packages. Versions of packages linphone suggests: ii yelp 3.4.2-1+b1 -- 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#688863: non-uniform treatment of self-conflicts for real/virtual M-A: same packages
Package: apt Severity: important [ Re-posting this as APT bug report, to keep track of it. The original version is at https://lists.debian.org/deity/2012/09/msg00088.html , the thread with further discussion (and in particular the POV of one of the Policy Editors) at https://lists.debian.org/deity/2012/09/msg00088.html ] Executive summary: it seems that APT treats differently self-conflicts for Multi-Arch: same packages, depending on whether the conflicts happen on real or virtual package names. Conflicts on virtual package names are ignored, whereas conflicts on real package names are not. Early discussions with -policy people seem to hint at a desired behavior where M-A: same packages should be co-installable across different architectures, ignoring self-conflicts, no matter if the conflicts happen via real or virtual package names. Cheers. On Thu, Sep 13, 2012 at 04:26:03PM -0700, Russ Allbery wrote: That does sound like a bug. The intuitive behavior when foo both Provides and Conflicts with bar would be for the Conflicts to only apply to other packages. Indeed. This particular combination of package metadata has a specific meaning defined in Policy 7.4: […] their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing some feature. So you need to specifically recognize the case of Conflicts naming the package itself or a virtual package that this package provides, and in that case the Conflicts should not be applied to that package for installability determination. None of this language has, as yet, been updated for multiarch, but I think it makes logical sense for a M-A: same package to be coinstallable even if it Conflicts with its own package name or a virtual package it Provides, by extension from the intention of this construct without multiarch. […] I could use double checking about the correctness of current APT's behavior. From how Russ put it above, it shouldn't matter whether the conflict is via a virtual package name or via a real package name: self-conflicts across architecture boundaries should be ignored for M-A: same packages. According to the attached tests (which are courtesy of Pietro Abate), it seems that APT does ignore self-conflict across arch boundaries when they are via virtual packages (test 1), but it doesn't ignore them when they are via real packages (test 2). Looking on a random desktop-like laptop machine with various suites, we've found ~200 packages which declare self-conflicts on their real names (probably due to historical package renaming, that have remained around). None of them is M-A: same, so the above alleged APT issue is only theoretical at this point. But it might become real with the increasing popularity of multiarch-ed packages in the Debian archive. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » Packages Package: a1 Version: 1 Architecture: arch1 Multi-Arch: same Provides: ap Conflicts: ap Package: a1 Version: 1 Architecture: arch2 Multi-Arch: same Provides: ap Conflicts: ap Package: a2 Version: 1 Architecture: arch1 Multi-Arch: same Conflicts: a2 Package: a2 Version: 1 Architecture: arch2 Multi-Arch: same Conflicts: a2 Package: a3 Version: 1 Architecture: arch1 Multi-Arch: same Package: a3 Version: 1 Architecture: arch2 Multi-Arch: same Test 1 == $./fakeapt.sh test install a1:arch1 a1:arch2 [...] The following NEW packages will be installed: a1 a1:arch2 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Inst a1 (1 localhost [arch1]) Inst a1:arch2 (1 localhost [arch2]) Conf a1 (1 localhost [arch1]) Conf a1:arch2 (1 localhost [arch2]) Test 2 == $./fakeapt.sh test install a2:arch1 a2:arch2 Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: a2 : Conflicts: a2:arch2 but 1 is to be installed a2:arch2 : Conflicts: a2 but 1 is to be installed E: Unable to correct problems, you have held broken packages. Test 3 == $./fakeapt.sh test install a3:arch1 a3:arch2 [...] The following
Bug#686033: libgl1-nvidia-glx: 304.37-1 libgl1-nvidia-glx:i386, removes libgl1-nvidia-glx (amd64) and Nvidia driver
Hi, I can confirm that the patch by you, Andreas, is working fine. The problems with the conffile are caused by a bug in dpkg [1] and there are other packages triggering it, like libpam-modules. Which dpkg versions are affected? Current unstable and sid. Guillem is aware of the issue (as can be seen in the bugreport http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684776 ). I'll ping him in the bugreport. Would it be appropriate for the NVidia packagers to do an NMU on libxvmc to fix this situation? Note that I am not speaking about Wheezy here, but about the current broken status of Sid. I have a NMUdiff attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687373 with no response so far. I'm *not* favoring a NMU of this if we can't fix it in wheezy. I'm thinking about another solution ... for wheezy. I only recently noticed the 304 drivers already migrated to Wheezy, so it's just as broken as Sid now (I had installed the sid drivers before migration already). Also I was not aware of your NMU unblock request, thanks for the pointer. I'm not insisting on an NMU if there's an alternative, I'd just be glad to prevent this regression from happening in Wheezy, and hope to help achieving that. Do you consider the dpkg bug a blocker for fixing this in Wheezy? Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688853: dspam: long line in message body causes '530 5.2.0 Message is empty. Aborting.'
Le mercredi 26 septembre 2012 11:07:09, vous avez écrit : Package: dspam Version: 3.10.1+dfsg-3~bpo60+1 Severity: critical dspam sends '530 5.2.0 Message is empty. Aborting.' while receiving incorrect spam message with long-long line, for example with length about 300K bytes: From what I read so far, dspam only reads a maximum of 1023 bytes per line but discard the whole line after that. I guess because of this it must be confuse by the quantity of bytes read and continues to read when there is no more data. The error you mention is raised by dspam when a message is empty. I'll continue to investigate. Thomas signature.asc Description: This is a digitally signed message part.
Bug#688864: isc-dhcp-client: Please provide a command-line option to avoid updating /etc/resolv.conf
Package: isc-dhcp-client Version: 4.2.4-1 Severity: wishlist Dear Maintainer, Sometimes dhclient is used to test network configurations. In these cases, it is a pain to need to go each time to hook files to have /etc/resolv.conf updated or not. Please add a command line flag to avoid updating /etc/resolv.conf Thanks -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages isc-dhcp-client depends on: ii debianutils 4.3 ii iproute 20110629-1 ii isc-dhcp-common 4.2.4-1 ii libc62.13-32 isc-dhcp-client recommends no packages. Versions of packages isc-dhcp-client suggests: pn avahi-autoipd none pn resolvconf none -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#684776: Re: Bug#684776: dpkg incorrectly complains about conffile contents being different for MA packages
Hi again, (sorry if you got this mail twice, my email program is acting strange) Yeah, reproduced here, and looking into it right now. I have a hunch I've already fixed this in my 1.17.x branch, though. Ok, I fixed this locally and been running some tests, will do some more tests and ponder a bit about the implications of the fix before pushing to master. Any news on this? Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685375: Breaks booting with nfsroot
retitle 685375 breaks booting with nfsroot tag 685375 moreinfo after the changes in 3.0~b3-1, this should not be necessary anymore. can you please confirm? -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686033: libgl1-nvidia-glx: 304.37-1 libgl1-nvidia-glx:i386, removes libgl1-nvidia-glx (amd64) and Nvidia driver
On 2012-09-26 14:39, Ralf Jung wrote: Which dpkg versions are affected? Current unstable and sid. probably wheezy and sid which both have dpkg 1.16.8 To avoid this bug, there is still a possibility to split out a -common package. I only recently noticed the 304 drivers already migrated to Wheezy, so it's just as broken as Sid now (I had installed the sid drivers before migration already). Also I was not aware of your NMU unblock request, thanks for the pointer. I'm now trying another approach (that will need a minor modification of n-g-d, too) http://bugs.debian.org/688861 http://mentors.debian.net/debian/pool/main/libx/libxvmc/libxvmc_1.0.7-1.1.dsc Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640499: Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
In case anyone is interested in a .dsc: http://mentors.debian.net/debian/pool/main/libx/libxvmc/libxvmc_1.0.7-1.1.dsc Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671815: linphone: undefined reference
Package: linphone Version: 3.5.2-10 Followup-For: Bug #671815 Dear Maintainer, Configure fails to store the zrtp dependency in ortp.pc. See the attached patch from ortp upstream git commit b7c5f78d83f8a310ba3700e93174c7eb1234d2d3 Hopping that the ZRTP package will finally comes to sid and wheezy. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678975 Guillaume -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linphone depends on: ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libavcodec536:0.8.3-7 ii libavutil51 6:0.8.3-7 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgsm1 1.0.13-4 ii libgtk2.0-0 2.24.10-2 ii liblinphone43.5.2-10 ii libmediastreamer1 3.5.2-10 ii libnotify4 0.7.5-1 ii libogg0 1.3.0-4 ii libortp83.5.2-10 ii libpango1.0-0 1.30.0-1 ii libspeex1 1.2~rc1-6 ii libspeexdsp11.2~rc1-6 ii libswscale2 6:0.8.3-7 ii libtheora0 1.1.1+dfsg.1-3.1 ii libvpx1 1.1.0-1 ii libx11-62:1.5.0-1 ii libxv1 2:1.0.7-1 ii linphone-nogtk 3.5.2-10 linphone recommends no packages. Versions of packages linphone suggests: ii yelp 3.4.2-1+b1 -- no debconf information add-zrtp-to-ortp-dependencies Description: Binary data
Bug#686033: libgl1-nvidia-glx: 304.37-1 libgl1-nvidia-glx:i386, removes libgl1-nvidia-glx (amd64) and Nvidia driver
Hi, Current unstable and sid. probably wheezy and sid which both have dpkg 1.16.8 Uhm, sorry, you are right of course. To avoid this bug, there is still a possibility to split out a -common package. The bug is only triggered by calling dpkg with both architectures of the package at once, so most people will not hit it initially but only on the first succeeding package upgrade. But yes, splitting the conffile would be possible, though I am not sure it's a good idea to complicate the package so much for working around a dpkg bug. I had already done that before the dpkg guys told me that conffile in MA: same are actually supported, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499#41 I'm now trying another approach (that will need a minor modification of n-g-d, too) http://bugs.debian.org/688861 http://mentors.debian.net/debian/pool/main/libx/libxvmc/libxvmc_1.0.7-1.1.dsc Interesting, so you think this has a better chance than multiarchifying libxvmc itself? However, in n-g-d I think it should be something like libxvmc1-i386 [i386] | libxvmc1 as dependency since the first alternative is what apt-get and aptitude usually try to install (and I don't think they are smart enough to re-try another alternative if a conflict arises). Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
Hi, As we are not going to get libxvmc turned to multi-arch for wheezy (see #640499) I'm now trying another approach with minimal changes to the libxvmc package: Related to this, there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687373 Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688853: dspam: long line in message body causes '530 5.2.0 Message is empty. Aborting.'
severity 688853 grave thanks Le mercredi 26 septembre 2012 14:40:20, Thomas Preud'homme a écrit : Le mercredi 26 septembre 2012 11:07:09, vous avez écrit : Package: dspam Version: 3.10.1+dfsg-3~bpo60+1 Severity: critical dspam sends '530 5.2.0 Message is empty. Aborting.' while receiving incorrect spam message with long-long line, for example with length about 300K bytes: From what I read so far, dspam only reads a maximum of 1023 bytes per line but discard the whole line after that. I guess because of this it must be confuse by the quantity of bytes read and continues to read when there is no more data. The error you mention is raised by dspam when a message is empty. I'll continue to investigate. Sorry I read to fast. What happen is that dspam read data from the socket by block of 1023 bytes and then search for a line in it by searching for the newline character with strchr. If it doesn't find a newline character, it returns NULL in cascade from pop_buffer up to read_sock through daemon_getline. When this returns NULL, it consider there is an error and return the error you saw. I didn't think much about it yet but I think a solution should be easy. Thomas signature.asc Description: This is a digitally signed message part.
Bug#640499: Fwd: Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
manually forwarding to #640499 as the BTS does not seem to handle
X-DebBugs-Cc: n@b.d.o properly
Original Message
Subject: Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a
libxvmc1-i386:i386 package
Resent-Date: Wed, 26 Sep 2012 12:09:06 +
Resent-From: Andreas Beckmann deb...@abeckmann.de
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: 640...@bugs.debian.org,
pkg-nvidia-de...@lists.alioth.debian.org, Debian Release Team
debian-rele...@lists.debian.org
Date: Wed, 26 Sep 2012 14:06:33 +0200
From: Andreas Beckmann deb...@abeckmann.de
Reply-To: Andreas Beckmann deb...@abeckmann.de, 688...@bugs.debian.org
To: Debian Bug Tracking System sub...@bugs.debian.org
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please approve the following changes for package libxvmc
As we are not going to get libxvmc turned to multi-arch for wheezy (see
#640499) I'm now trying another approach with minimal changes to the
libxvmc package:
Can we add a new package
Package: libxvmc1-i386
Section: libs
Priority: extra
Architecture: i386
Multi-arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
Description: X11 Video extension library (alternate i386 package)
that ships another copy of the libraries in /usr/lib/i386-linux-gnu/
To avoid installing libxvmc1-i386:i386 and libxvmc1:i386 at the same
time and have two copies of the same library available, I'm adding
Package: libxvmc1
Conflicts: libxvmc1-i386 [i386]
and to avoid picking up a dependency on libxvmc1-i386 by accident, its
shlibs file points to libxvmc1.
I added a lintian-overrides file, but that is not being installed as I
wanted to avoid changing anything in debian/rules.
Note that this new package does not ship the conffile as it is expected
to be only installed along libxvmc1:amd64 which comes with the conffile.
(This dependency can't be expressed by package relationships.)
This will keep the existing non-multiarch libxvmc1 unchanged, the build
system is untouched, nothing will start to use the alternate copy
package accidently. For libgl1-nvidia-glx:i386 to actually pick up this
alternate library, we need to add a shlibs.local file (in
nvidia-graphics-drivers) with
libXvMC 1 libxvmc1 | libxvmc1-i386 [i386]
I chose to add the extra package to the libxvmc source package as that
will avoid forking (and therefore code duplication) and getting libxvmc1
and libxvmc1-i386 out of sync. Even with a second copy in the a binary
package in the archive, there is no overhead in case a security update
for libxvmc should be neccessary.
Judging by the number of bug reports, it is really important for our
users to restore the ability to run 32-bit OpenGL applications on a
amd64 system and get accelleration by the non-free nvidia driver.
That was working in squeeze and will be considered as a serious
regression if this is not getting fixed in some way for wheezy.
See e.g. #685054, #686033, #676723, #688714
I'll be happy to assist getting a proper multi-arch libxvmc into jessie
and to clean up this temporary package that we need for wheezy.
Andreas
diffstat for libxvmc_1.0.7-1 libxvmc_1.0.7-1.1
debian/libxvmc1-i386.install |2 ++
debian/libxvmc1-i386.lintian-overrides |4
debian/libxvmc1-i386.shlibs|2 ++
libxvmc-1.0.7/debian/changelog | 12
libxvmc-1.0.7/debian/control | 26 ++
5 files changed, 46 insertions(+)
diff -u libxvmc-1.0.7/debian/control libxvmc-1.0.7/debian/control
--- libxvmc-1.0.7/debian/control
+++ libxvmc-1.0.7/debian/control
@@ -22,6 +22,7 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
+Conflicts: libxvmc1-i386 [i386]
Description: X11 Video extension library
libXvMC provides an X Window System client interface to the
XVideo-MotionCompensation extension to the X protocol.
@@ -37,6 +38,31 @@
This module can be found at
git://anongit.freedesktop.org/git/xorg/lib/libXvMC
+Package: libxvmc1-i386
+Section: libs
+Priority: extra
+Architecture: i386
+Multi-arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
+Description: X11 Video extension library (alternate i386 package)
+ libXvMC provides an X Window System client interface to the
+ XVideo-MotionCompensation extension to the X protocol.
+ .
+ The XVideo-MotionCompensation extension allows for further accelerated drawing
+ of videos. Video data may be sent at earlier stages of the decoding pipeline
+ than raw YUV data. At the moment, driver support for XvMC is poor to
+ non-existent.
+ .
+ More information about X.Org can be found at:
+ URL:http://www.X.org
+ .
+ This module can be found at
+ git://anongit.freedesktop.org/git/xorg/lib/libXvMC
+ .
+ This is a
Bug#688801: kde-window-manager: Incorrect Build-conflict against libgles2-mesa-dev
Hello Martin, the build conflict right now is correct because kwin isn't linked against opengl es 2.0 on purpose and if we build the package with libgles2-mesa-dev fails to build because of a missing file. Another slightly different thing is if we should enable the open gl es stuff in kwin(I think we should do it one of these days). This is why I disabled the opengl es some months ago (copied from an IRC log): [08 Abr 2012] [18:27:03] santa_ pinotree: if I understand it correctly: in kde 4.8 kwin gles can be built at the same time that normal kwin, however it won't be run unless the user goes to a terminal and writes kwin_gles -replace. in the future the compositing stuff in kwin may be a plugin so the gles compositing would be loaded if open gl es is working [Dom 08 Abr 2012] [18:31:45] * pinotree expects a conclusion [snip] [Dom 08 Abr 2012] [18:35:23] santa_ pinotree: so I think it makes sense to adopt the drop the gless stuff proposed by you. we can add packages for kwin gles later, I'd need to check if what the ubuntu guys did makes sense, but we have better things to do imo[1] In my first message, is it my guess right or am I missing something? How does it work in 4.9? I mean, does it load the opengl es compositing automatically if possible? [1]The better things to do were packaging the rest of the KDE SC, so finally I didn't have time to work on this thing again since that IRC conversation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688772: gnome Depends network-manager-gnome
Ian == Ian Jackson ijack...@chiark.greenend.org.uk writes: Hi. I'm very pleased that you took the time to write a thoughtful response to my message. I appreciate that you're trying to work with me even though the situation is frustrating and you feel under pressure to work towards the solution you want in time for wheezy. Now, I'll admit that there was probably some searching going on for how to fit some goals into what the TC proposed. I'll admit that there might have been some ask for forgiveness not permission going on. But all those things are normal with frustration. Ian What kind of emotional state do you think I should have after Ian the legitimate and unanimous authority of the TC has been Ian undermined in this way ? Perhaps I would be frustrated. So, you're frustrated because you went to a lot of work and you feel that someone is working to undermine your work? You'd like to express those feelings and get them onto the record? If I've got that right, I'd ask you to think about various ways of accomplishing those goals. For myself, I think I might have better luck if I tried to connect with the gnome-meta maintainer and help them understand how I felt. I would hope that by achieving that connection they'd be more likely to consider their impact on me in the future. My hope would be to get to a state where they say Sam tried to work with us even though we disagreed and the decision was against us so I should consider my impact on him. I think that's going to be more productive than someone who thinks Well, Sam's going to dislike this and yell at me. So I might right a message to the gnome-meta maintainer (copying a list if I felt I needed to do that) talking about how I was frustrated and how I was having a hard time finding an interpretation that was not about subverting the decision. I'd probe for misunderstandings as well as try and build an understanding of the emotional impact on me if there was no misunderstanding in fact. Everyone has different communication styles. What works for me might seem verbose and silly to someone else. However, I'd ask that you consider the effects of communication both on others (even if you don't feel you're getting that from them) and on accomplishing your goals whatever they are. And then later having a serious discussion about how you and the TC can write resolutions that are more likely to achieve the long-term goals of the TC while avoiding frustration. Ian Normally we write our resolutions with the intent that people Ian will not subvert them, or work against their intent. That is Ian after all required by the Constitution. Ian If we need to make them watertight against malicious and Ian lawyerish interpretation, then we will need to anticipate every Ian way in which the maintainers might try to subvert our intent. Ian Along the lines of point 6 in my proposal. So, you're concerned that if you try to make the resolutions water-tight that others might wish for more respect? That makes a lot of sense to me. I think though that whenever a maintainer is overruled there is likely to be a lot of frustration and disappointment. That can get in the way even when there is no malice. I might have added something like The TC requests that the gnome-meta maintainer confirm that upgrading from squeeze to wheezy without network-manager installed does not install network-manager. We'd be happy to assist with this work if desired. I might move some of the rationale text out of the resolution proper. So the resolution focuses on the specific actions as well as the desired state in the decision part and avoids too much other text. Obviously others would approach things differently. For example, I think you considered the rationale portion important to have in the body of the resolution. I think though that discussing the desirability of the upgrade behavior in the decision part would not be overly-legalistic. If I were overruled, I don't think a nicely worded request like that would increase my frustration or disappointment. Thanks again for your time. I wish you the best of luck on quickly reaching a decision within the TC. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688853: dspam: long line in message body causes '530 5.2.0 Message is empty. Aborting.'
Yes, I see in daemon_getline() function in daemon.c it tries to read buf[1024] with some timeout and get. But it seems that read_sock() returns NULL message. 26.09.2012 16:40, Thomas Preud'homme пишет: Le mercredi 26 septembre 2012 11:07:09, vous avez écrit : Package: dspam Version: 3.10.1+dfsg-3~bpo60+1 Severity: critical dspam sends '530 5.2.0 Message is empty. Aborting.' while receiving incorrect spam message with long-long line, for example with length about 300K bytes: From what I read so far, dspam only reads a maximum of 1023 bytes per line but discard the whole line after that. I guess because of this it must be confuse by the quantity of bytes read and continues to read when there is no more data. The error you mention is raised by dspam when a message is empty. I'll continue to investigate. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
On 26.09.2012 14:01, Ralf Jung wrote: As we are not going to get libxvmc turned to multi-arch for wheezy (see #640499) I'm now trying another approach with minimal changes to the libxvmc package: Related to this, there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687373 Not so much related, as a proposed alternative, afaics? The maintainers appear to have made their opinion quite clear in #640499 on the originally suggested approach, however... Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688866: RFP: spot -- Tiny file search utility
Package: wnpp Severity: wishlist * Package name: spot Version : 1.0 Upstream Author : Guillermo Rauch rau...@gmail.com * URL : https://github.com/guille/spot * License : MIT Programming Lang: Bash Description : Tiny file search utility Tiny ack-style file search utility. * Short written in Bash: you can edit it easily to suit your liking. * Fast. Just find + grep. * Searches most things by default instead of some known predefined extensions. * Ignores .git, .svn, devices and binary files. * All arguments constitute the search text. No need to wrap most searches in double quotes. * spot is case-insensitive by default. However, if your search term contains an uppercase letter, it becomes sensitive! * If the first argument contains a slash and is a valid directory, the search is constrained to that particular target. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688867: X-DebBugs-Cc: xxx...@bugs.debian.org does not seem to work
Package: bugs.debian.org Severity: normal Hi, setting X-Debbugs-Cc to another bugs address nn@bugs.d.o does not seem to work. I just submitted bug #688861 against release.d.o, it included a patch that I considered important for the original bug that is to be worked around, so I set X-DebBugs-Cc: 640...@bugs.debian.org The confirmation mail said: As you requested using X-Debbugs-CC, your message was also forwarded to 640...@bugs.debian.org, pkg-nvidia-de...@lists.alioth.debian.org (after having been given a Bug report number, if it did not have one). But the message didn't show up in #640499, while followup from me got through, so I forwarded the mail again manually. I remember that I wondered about missing Cc:s in other bug submissions earlier, but never looked into this in detail. Message-IDs: To submit@, and also received at pkg-nvidia-devel@ 20120926120633.24003.68718.report...@cake.ae.cs.uni-frankfurt.de Acknowledgement: handler.688861.b.13486612019870@bugs.debian.org Manually forwarded to #640499: 5062ff29.8020...@abeckmann.de Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682616: upgrading to grave
severity 682616 grave thanks Hi, I'm upgrading this bug to grave because me and others (Adnan Hodzic) find that it makes Chromium unusable or mostly so. It can also cause data loss if it crashes while you're filling in a form or writing something. Maybe I'm exaggerating; feel free to downgrade. I just feel that this bug warrants attention. -- Pelle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
Hi, As we are not going to get libxvmc turned to multi-arch for wheezy (see #640499) I'm now trying another approach with minimal changes to the libxvmc package: Related to this, there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687373 Not so much related, as a proposed alternative, afaics? The maintainers appear to have made their opinion quite clear in #640499 on the originally suggested approach, however... You mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499#66 ? He didn't say he's opposed to the patch, just that the release team might not let it through. The release team didn't reply (or I missed it?). libcap2 multiarchification was let in though (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684647), and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681717 looks like a similar case which has not yet been decided on (multiarchification needed to prevent regression from Squeeze for a large usergroup - even larger than this one, which only affects users of the proprietary NVidia driver). Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
On 2012-09-26 15:20, Adam D. Barratt wrote: Not so much related, as a proposed alternative, afaics? The maintainers appear to have made their opinion quite clear in #640499 on the originally suggested approach, however... Therefore I'm now investigating a different approach ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
On 26.09.2012 14:32, Ralf Jung wrote: As we are not going to get libxvmc turned to multi-arch for wheezy (see #640499) I'm now trying another approach with minimal changes to the libxvmc package: Related to this, there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687373 Not so much related, as a proposed alternative, afaics? The maintainers appear to have made their opinion quite clear in #640499 on the originally suggested approach, however... You mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499#66 ? No, I meant http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499#149 He didn't say he's opposed to the patch, just that the release team might not let it through. The release team didn't reply (or I missed it?). libcap2 multiarchification was let in though (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684647), and I'm aware of that. :-) (see the release team members involved in that discussion). That's also a different situation; libcap2 is required to allow us to get rid of the monolithic ia32-libs. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688868: libexosip2: should be compiled with SSL support
Package: libexosip2-7 Version: 3.6.0-4 Severity: serious Justification: 0: makes the package in question unusable or mostly so Dear Maintainer, The exosip library is not compiled with SSL support. The control file marks libssl-dev as a build conflict. I couldn't find the rationale behind it; only a bug report from 2007 on Bayonne mention the fact. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442964 . Today this bug has become serious because many routers mess up with unencrypted SIP traffic, preventing calls to succeed. TLS was added to Linphone one year ago using exosip with SSL and it works as expected and is available in wheezy. I hesitated to set the severity to serious, but frankly, many people will be stuck in using skype if TLS support is not available in their softphone. Cheers, Guillaume -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libexosip2-7 depends on: ii libc6 2.13-35 ii libosip2-7 3.6.0-4 ii multiarch-support 2.13-35 libexosip2-7 recommends no packages. libexosip2-7 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#682388: [Powertop] [PATCH] Fix string null termination and SIGABRT from glibc
On (09/26/12 12:04), Mikko Rapeli wrote: Date: Wed, 26 Sep 2012 12:04:01 +0300 From: Mikko Rapeli mikko.rap...@iki.fi To: power...@lists.01.org Cc: 682...@bugs.debian.org Subject: [Powertop] [PATCH] Fix string null termination and SIGABRT from glibc According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682388 the string is not null terminated when too much data is read. This patch fixes the crashes for me. My traces: PowerTOP 2.1 Overview Idle stats Frequency stats Device stats Tunab Package |CPU 0 POLL0.0%| POLL0.0%0.0 ms C1 0.0%| C1 0.0%0.0 ms C2 3.8%| C2 5.4%0.2 ms C3 12.4%| C3 20.9%1.7 ms |CPU 1 | POLL0.0%0.0 ms | C1 0.0%0.2 ms | C2 2.2%0.2 ms | C3 3.8%0.9 ms *** stack smashing detected ***: /usr/local/sbin/powertop terminated === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb7d7be70] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe4e1a)[0xb7d7be1a] /usr/local/sbin/powertop[0x8067a01] ESC Exit |/usr/local/sbin/powertop[0x8067ce7] /usr/local/sbin/powertop[0x806b727] /usr/local/sbin/powertop[0x8070d62] /usr/local/sbin/powertop[0x806c2e6] /usr/local/sbin/powertop[0x8089ecf] /usr/local/sbin/powertop[0x804df42] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7cade46] /usr/local/sbin/powertop[0x804e0f1] === Memory map: 08048000-080af000 r-xp 08:02 2336756/usr/local/sbin/powertop 080af000-080b rw-p 00067000 08:02 2336756/usr/local/sbin/powertop 080b-1022a000 rw-p 00:00 0 [heap] b68c6000-b69c7000 rw-p 00:00 0 b6aaa000-b6acb000 rw-p 00:00 0 b6acb000-b6b4c000 rw-s 00:09 5025 anon_inode:[perf_event] b6b4c000-b6bcd000 rw-s 00:09 5025 anon_inode:[perf_event] b6bcd000-b6c4e000 rw-s 00:09 5025 anon_inode:[perf_event] b6c4e000-b6ccf000 rw-s 00:09 5025 anon_inode:[perf_event] b6ccf000-b6d5 rw-s 00:09 5025 anon_inode:[perf_event] b6d5-b6dd1000 rw-s 00:09 5025 anon_inode:[perf_event] b6dd1000-b6e52000 rw-s 00:09 5025 anon_inode:[perf_event] b6e52000-b6ed3000 rw-s 00:09 5025 anon_inode:[perf_event] b6ed3000-b6f54000 rw-s 00:09 5025 anon_inode:[perf_event] b6f54000-b6fd5000 rw-s 00:09 5025 anon_inode:[perf_event] b6fd5000-b7056000 rw-s 00:09 5025 anon_inode:[perf_event] b7056000-b70d7000 rw-s 00:09 5025 anon_inode:[perf_event] b70d7000-b7158000 rw-s 00:09 5025 anon_inode:[perf_event] b7158000-b71d9000 rw-s 00:09 5025 anon_inode:[perf_event] b71d9000-b725a000 rw-s 00:09 5025 anon_inode:[perf_event] b725a000-b72db000 rw-s 00:09 5025 anon_inode:[perf_event] b72db000-b735c000 rw-s 00:09 5025 anon_inode:[perf_event] b735c000-b73dd000 rw-s 00:09 5025 anon_inode:[perf_event] b73dd000-b745e000 rw-s 00:09 5025 anon_inode:[perf_event] b745e000-b74df000 rw-s 00:09 5025
Bug#639975: clementine: Release candidate for version 1.1 available
Hi Rogério, I am beginning to package this version. If I does not encounter troubles, I will be able to upload it to experimental soon. Regards, Thomas Pierson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677450: dmraid: fakeraid root device not activated during boot
Hi Ulrich, I'm currently in the process of reviewing udeb-producing packages to make them migrate to wheezy if appropriate. Ulrich Dangel u...@debian.org (10/09/2012): Did you test it without the PREREQS=udev line? There is also a wait_for_udev function in the functions file, so we should probably use this. Could you test if: . /scripts/functions wait_for_udev 30 works for you? If it does I'll do an NMU. I guess you received a private mail confirming everything works fine with that patch? Mraw, KiBi. signature.asc Description: Digital signature
