Bug#764178: debsources: infobox CSS alignment problem with short files
Hey Christophe On 05/11/14 07:51 AM, Christophe Siraut wrote: Hi, My commit adds a padding-right to make sure that even if the file has one short line, it's content will be left-aligned. We could instead limit the expansion of the first column, which contains the line numbers, see attachment. Looks like that's a better solution ! I had tested with max-width, it didn't work for me. Should have tested with a simple width :) Thanks Cheers, Christophe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767862: pcscd: Socket activation not working on first try
Le 05/11/2014 11:59, Laurent Bigonville a écrit : On Mon, 03 Nov 2014 20:33:01 +0100 Ludovic Rousseau ludovic.rouss...@gmail.com wrote: [...] Edit the file /lib/systemd/system/pcscd.service and add --debug to the line: ExecStart=/usr/local/sbin/pcscd --foreground --auto-exit This should generate much more pcscd debug messages. I've attached the log here. You can see a first call to gpg --card-status that fails and then a 2nd one 1 min later. It looks like a bug in pcsc-lite. pcscd is answering commands _before_ the list of USB readers has been scanned and the readers are ready. I will fix that. Thanks. -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768154: unblock: trousers/0.3.13-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package trousers
The recent upload to unstable contains only the targeted fix for the
RC bug reported in #767690.
Full debdiff attached.
unblock trousers/0.3.13-3
diff -Nru trousers-0.3.13/debian/changelog trousers-0.3.13/debian/changelog
--- trousers-0.3.13/debian/changelog 2014-08-20 14:27:34.0 +0200
+++ trousers-0.3.13/debian/changelog 2014-11-04 15:16:06.0 +0100
@@ -1,3 +1,18 @@
+trousers (0.3.13-3) unstable; urgency=high
+
+ * Fix postinst script, preventing installation (Closes: #767690)
+- The postinst script does not fail anymore if the TPM device is not
+ present, or if udev reload command fails.
+ This is typically the case in a chroot environment.
+ * Fix init script to be more robust:
+- Test for TPM device owner and issue a warning if not matching the tss
+ user.
+- Do not try to change uid before running tcsd, the daemon already changes
+ its uid just after starting.
+ * Urgency high, RC bug
+
+ -- Pierre Chifflier pol...@debian.org Tue, 04 Nov 2014 15:11:08 +0100
+
trousers (0.3.13-2) unstable; urgency=medium
* Fix FTBFS on hurd-i386 and kfreebsd-any (Closes: #754359)
diff -Nru trousers-0.3.13/debian/trousers.init trousers-0.3.13/debian/trousers.init
--- trousers-0.3.13/debian/trousers.init 2012-06-15 12:58:08.0 +0200
+++ trousers-0.3.13/debian/trousers.init 2014-11-04 15:06:24.0 +0100
@@ -35,7 +35,15 @@
exit 0
fi
- start-stop-daemon --start --quiet --oknodo --pidfile /var/run/${NAME}.pid --user ${USER} --chuid ${USER} --exec ${DAEMON} -- ${DAEMON_OPTS}
+ for tpm_dev in /dev/tpm*; do
+ TPM_OWNER=$(stat -c %U $tpm_dev)
+ if [ x$TPM_OWNER != xtss ]
+ then
+log_warning_msg TPM device owner for $tpm_dev is not 'tss', this can cause problems.
+ fi
+ done
+
+ start-stop-daemon --start --quiet --oknodo --pidfile /var/run/${NAME}.pid --user ${USER} --exec ${DAEMON} -- ${DAEMON_OPTS}
RETVAL=$?
log_end_msg $RETVAL
[ $RETVAL = 0 ] pidof $DAEMON /var/run/${NAME}.pid
diff -Nru trousers-0.3.13/debian/trousers.postinst trousers-0.3.13/debian/trousers.postinst
--- trousers-0.3.13/debian/trousers.postinst 2014-06-29 17:31:52.0 +0200
+++ trousers-0.3.13/debian/trousers.postinst 2014-11-04 14:49:01.0 +0100
@@ -16,9 +16,9 @@
chmod 0700 /var/lib/tpm
# ask udev to check for new udev rules (and fix device permissions)
- if udevadm --version /dev/null; then
- udevadm control --reload-rules
- udevadm trigger --sysname-match=tpm[0-9]*
+ if [ -e /dev/tpm0 ] udevadm --version /dev/null; then
+ udevadm control --reload-rules ||:
+ udevadm trigger --sysname-match=tpm[0-9]* ||:
fi
;;
Bug#746578: libpam-systemd to flip dependencies - proposal
I don't think this matters for the vote, and apologies because there's probably a better place to send this advice. I was thinking last night about the apt and debootstrap resolver issues and was wondering whether the following solution might help. I realize the issue is minor and is more about minimizing packages installed than safety of the proposal. What if libpam-systemd depended on systemd-shim-nosysv|systemd-sysv|systemd-shim? Introduce a new package systemd-shim-nosysv in the systemd-shim package that depends on systemd-shim and conflicts with systemd-sysv. I have not tried this. It might reduce the probability that systemd-shim gets uselessly installed. however, I don't know whether it creates systems where systemd-sysv gets removed. Even if this does end up being a good idea, I don't think the TC resolution needs to change. As I read it, the essential character of the resolution is that systemd-shim is preferred to systemd-sysv in libpam-systemd. If we find better technical ways of doing that, more power to us all. If there is a real disagreement about whether we're within the spirit of the TC resolution should it pass, we can ask the TC again either informally or formally. I don't want to see us getting ultra-picky about the wording of resolutions to constrain or permit future innovation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768155: simbody: Fix FTBFS on ppc
Package: simbody Version: 3.4.1+dfsg-1 Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el powerpc Dear Maintainer, on the latest buildd log on simbody, the build fails on powerpc and ppc64el with : cd /«BUILDDIR»/simbody-3.4.1+dfsg/obj-powerpc64le-linux-gnu/SimTKcommon/sharedTarget /usr/bin/c++ -DSimTK_SIMBODY_AUTHORS=\Michael.Sherman_Peter.Eastman\ -DSimTK_SIMBODY_COPYRIGHT_YEARS=\2005-14\ -DSimTK_SimTKCOMMON_AUTHORS=\Michael.Sherman_Peter.Eastman\ -DSimTK_SimTKCOMMON_BUILDING_SHARED_LIBRARY -DSimTK_SimTKCOMMON_COPYRIGHT_YEARS=\2005-10\ -DSimTK_SimTKCOMMON_LIBRARY_NAME=SimTKcommon -DSimTK_SimTKCOMMON_MAJOR_VERSION=3 -DSimTK_SimTKCOMMON_MINOR_VERSION=4 -DSimTK_SimTKCOMMON_PATCH_VERSION=1 -DSimTK_SimTKCOMMON_SVN_REVISION=\\ -DSimTKcommon_EXPORTS -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -I/«BUILDDIR»/simbody-3.4.1+dfsg/Platform/Linux/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/./include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/Scalar/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/SmallMatrix/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/Mechanics/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/BigMatrix/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/Geometry/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/Simulation/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/Random/include -I/«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/Polynomial/include-o CMakeFiles/SimTKcommon.dir/__/src/tinyxml.cpp.o -c /«BUILDDIR»/simbody-3.4.1+dfsg/SimTKcommon/src/tinyxml.cpp /tmp/ccgchSJT.s: Assembler messages: /tmp/ccgchSJT.s:236: Error: syntax error; found `i', expected `,' /tmp/ccgchSJT.s:236: Error: junk at end of line: `isync' /tmp/ccgchSJT.s:309: Error: syntax error; found `i', expected `,' /tmp/ccgchSJT.s:309: Error: junk at end of line: `isync' There seems to be a typo in SimTKcommon/src/gmx_atomic.h which I tried to fix with the attached patch. The package then builds successfully. Could you please review and confirm ? Thank you! F. --- a/debian/patches/fix_ppc64el.patch 1970-01-01 01:00:00.0 +0100 +++ b/debian/patches/fix_ppc64el.patch 2014-11-05 13:21:05.736000696 +0100 @@ -0,0 +1,11 @@ +--- simbody-3.4.1+dfsg.orig/SimTKcommon/src/gmx_atomic.h simbody-3.4.1+dfsg/SimTKcommon/src/gmx_atomic.h +@@ -470,7 +470,7 @@ gmx_atomic_add_return(gmx_atomic_t * + __asm__ __volatile__(1: lwarx %0,0,%2\n + \tadd %0,%1,%0\n + \tstwcx. %0,0,%2 \n +- \tbne-1b ++ \tbne-1b\n + \tisync\n + : =r (t) + : r (i), r (a-value) --- a/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ b/debian/patches/series 2014-11-05 13:20:56.708000696 +0100 @@ -0,0 +1 @@ +fix_ppc64el.patch
Bug#768156: general: dpkg frontend inconsistent
Package: general Severity: minor Hello, I was upgrading my system and several times I was asked for installing a new configuration file. Sometimes the question is posed in teletype style frontend sometimes in colour character terminal TUI style frontend. Can't this be consistent? I don't remember ever configurin the frontend to use but whatever is the default there should be only one default. Thanks Michal -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (410, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15-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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766991: [Pkg-acpi-devel] Bug#766991: acpid: does not process events
Am 05.11.2014 um 14:25 schrieb Norbert Preining: Hi TEd, hi Michael (Meskes), override_dh_systemd_enable: dh_systemd_enable --no-enable debian/acpid.service dh_systemd_enable debian/acpid.socket That --no-enable should probably removed in the rules file. There are more kernel modules out there (thinkpad?...) that send acpi events via the kernel, thus not starting the acpid would disable all of them. Well, the kernel events are not disabled if acpid is not running. I think what you meant can be summarised as: There are different use cases for acpid: a/ dispatching acpi events via /run/acpid.socket. Those events are consumed by 3rd party applications which read from the socket file. Using systemd socket activation means, acpid is only started on demand if there is actually a consumer requiring acpid. E.g. traditionally, this was the way, Xorg read ACPI events. b/ acpid's internal event processing which calls (shell) scripts on certain events which are defined in /etc/acpi/. I assume Norbert is using acpid in mode b/, so what he noticed was, that his shell scripts in /etc/acpi/ were not processed as he apparently doesn't have a service which triggers the start of acpid by reading from /run/acpid.socket. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#763369: g++-4.9: Linker failure when using str::thread
Hi, $ g++ -std=c++11 threadtest.cpp -o threadtest /tmp/cc2mc1l4.o: In function `std::thread::threadvoid (*)()(void (*)())': threadtest.cpp:(.text._ZNSt6threadC2IPFvvEIEEEOT_DpOT0_[_ZNSt6threadC5IPFvvEIEEEOT_DpOT0_]+0x1e): undefined reference to `pthread_create' collect2: error: ld returned 1 exit status The program used to compile and run just fine around a month ago. The problem also affects clang++. I will attach a small example program. The program compiles and runs fine when I add -pthread to the flags (this work-around applies to both g++ and clang++). However, it was my understanding (and expectation) that this flag is no longer needed with C++11 - in fact, I shouldn't even know that it's pthreads implementing the std::thread class. this is expected behaviour now. You have to link with -pthread. So even though C++11 is supposed to abstract away from platform-specific details, I still have to know which threading library is used internally by my libstdc++? I don't think that's well though-out, but I understand that this is not your decision but an upstream one. Oh well :-/ 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#768097: clamtk: Won't start.
Hi Rob, On 05.11.2014 13:30, rob wrote: On 04/11/14 23:55, Andreas Cadhalpun wrote: Please report the output of the following commands: $ dpkg --verify gnome-icon-theme $ find /usr/share/icons/gnome/ -name *gtk-new* | xargs file $ find /usr/share/icons/gnome/ -name *document-new* | xargs file root@debian:/home/rob# dpkg --verify gnome-icon-theme No output root@debian:/home/rob# find /usr/share/icons/gnome/ -name *gtk-new* | xargs file /usr/share/icons/gnome/16x16/actions/gtk-new.png: symbolic link to `document-new.png' /usr/share/icons/gnome/24x24/actions/gtk-new.png: symbolic link to `document-new.png' /usr/share/icons/gnome/256x256/actions/gtk-new.png: symbolic link to `document-new.png' /usr/share/icons/gnome/48x48/actions/gtk-new.png: symbolic link to `document-new.png' /usr/share/icons/gnome/22x22/actions/gtk-new.png: symbolic link to `document-new.png' /usr/share/icons/gnome/32x32/actions/gtk-new.png: symbolic link to `document-new.png' root@debian:/home/rob# find /usr/share/icons/gnome/ -name *document-new* | xargs file /usr/share/icons/gnome/16x16/actions/document-new.png: PNG image data, 16 x 16, 8-bit/color RGBA, non-interlaced /usr/share/icons/gnome/24x24/actions/document-new.png: PNG image data, 24 x 24, 8-bit/color RGBA, non-interlaced /usr/share/icons/gnome/256x256/actions/document-new.png: PNG image data, 256 x 256, 8-bit/color RGBA, non-interlaced /usr/share/icons/gnome/48x48/actions/document-new.png: PNG image data, 48 x 48, 8-bit/color RGBA, non-interlaced /usr/share/icons/gnome/22x22/actions/document-new.png: PNG image data, 22 x 22, 8-bit/color RGBA, non-interlaced /usr/share/icons/gnome/32x32/actions/document-new.png: PNG image data, 32 x 32, 8-bit/color RGBA, non-interlaced So the icons are there, they are just not registered. Please run: # gtk-update-icon-cache-3.0 --force /usr/share/icons/gnome After that clamtk should work. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670377: i965 driver doesn't work on my 945GME
Problem: no VA support for intel G45 and others reason: missing i915_drv_video.so, which is not delivered by any package solution: Should the installed i965_drv_video.so be loaded instead of the missing i915_drv_video.so? After looking at the source for vainfo, I tried to load i965 and got a segfault: env LIBVA_DRIVER_NAME=i965 VA_INTEL_DEBUG=1 vainfo libva info: VA-API version 0.36.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'i965' libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_36 g_intel_debug_option_flags:1 Segmentation fault (core dumped) Seems like my chipset should be supported per https://01.org/linuxgraphics/about/supported-hardware -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768157: machine hangs when loading cirrus with modeset=1 while booted with vga=791
Package: src:linux Version: 3.16.7-1 Severity: normal Hi, while testing the new Grml release, I noticed an interesting hang of QEMU when the machine is booted. The initial testing was done using [1] in QEMU from Sid (2.1+dfsg-5), but I also could reproduce it with the same QEMU and a fresh Jessie install with both, 3.16.5-1 and 3.16.7-1. To reproduce: * boot a fresh Jessie with 3.16 kernel in QEMU and vga=791 as bootparam * modprobe cirrus modeset=1 * machine hangs I am not sure this will happen on real cirrus HW, as I don't have any, but QEMU is quite widespread and cirrus is the default VGA driver. Regards Evgeni [1] http://download.grml.org/devel/grml64-full_2014.10-rc1.iso -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-1 (2014-11-04) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg01-root ro quiet vga=791 ** Not tainted ** Kernel log: [0.565203] AMD IOMMUv2 functionality not available on this system [0.565321] TCP: cubic registered [0.565339] NET: Registered protocol family 10 [0.565544] mip6: Mobile IPv6 [0.565548] NET: Registered protocol family 17 [0.565553] mpls_gso: MPLS GSO support [0.565831] registered taskstats version 1 [0.566263] rtc_cmos 00:00: setting system clock to 2014-11-05 13:53:31 UTC (1415195611) [0.566318] PM: Hibernation image not present or could not be loaded. [0.567297] Freeing unused kernel memory: 1200K (818ed000 - 81a19000) [0.567299] Write protecting the kernel read-only data: 8192k [0.570060] Freeing unused kernel memory: 940K (880001515000 - 88000160) [0.570697] Freeing unused kernel memory: 224K (8800017c8000 - 88000180) [0.584291] systemd-udevd[51]: starting version 215 [0.584626] random: systemd-udevd urandom read with 1 bits of entropy available [0.594962] ACPI: bus type USB registered [0.594996] usbcore: registered new interface driver usbfs [0.595009] usbcore: registered new interface driver hub [0.597676] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 [0.601839] SCSI subsystem initialized [0.611252] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10 [0.611884] usbcore: registered new device driver usb [0.612948] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.614231] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 [0.616681] uhci_hcd: USB Universal Host Controller Interface driver [0.622091] uhci_hcd :00:01.2: UHCI Host Controller [0.622101] uhci_hcd :00:01.2: new USB bus registered, assigned bus number 1 [0.622127] uhci_hcd :00:01.2: detected 2 ports [0.622215] uhci_hcd :00:01.2: irq 11, io base 0xc040 [0.623527] libata version 3.00 loaded. [0.625041] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [0.625045] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.625047] usb usb1: Product: UHCI Host Controller [0.625049] usb usb1: Manufacturer: Linux 3.16.0-4-amd64 uhci_hcd [0.625051] usb usb1: SerialNumber: :00:01.2 [0.625480] hub 1-0:1.0: USB hub found [0.625635] hub 1-0:1.0: 2 ports detected [0.626321] ata_piix :00:01.1: version 2.13 [0.632467] FDC 0 is a S82078B [0.639578] scsi0 : ata_piix [0.649203] scsi1 : ata_piix [0.649260] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc0a0 irq 14 [0.649262] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc0a8 irq 15 [0.651923] virtio-pci :00:03.0: irq 40 for MSI/MSI-X [0.651946] virtio-pci :00:03.0: irq 41 for MSI/MSI-X [0.651966] virtio-pci :00:03.0: irq 42 for MSI/MSI-X [0.653788] virtio-pci :00:05.0: irq 43 for MSI/MSI-X [0.653811] virtio-pci :00:05.0: irq 44 for MSI/MSI-X [0.654532] vda: vda1 vda2 [0.813146] ata2.01: NODEV after polling detection [0.813919] ata2.00: ATAPI: QEMU DVD-ROM, 2.1.2, max UDMA/100 [0.814966] ata2.00: configured for MWDMA2 [0.816265] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.1. PQ: 0 ANSI: 5 [0.828633] sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray [0.828638] cdrom: Uniform CD-ROM driver Revision: 3.20 [0.828869] sr 1:0:0:0: Attached scsi CD-ROM sr0 [0.829893] sr 1:0:0:0: Attached scsi generic sg0 type 5 [0.900192] device-mapper: uevent: version 1.0.3 [0.900644] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-de...@redhat.com [0.936061] usb 1-1: new full-speed USB device number 2 using uhci_hcd [0.947446] EXT4-fs (dm-0): INFO: recovery required on readonly filesystem [0.947451] EXT4-fs (dm-0): write access will be enabled during recovery [0.959940] EXT4-fs (dm-0): recovery complete [0.961943] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [1.097518] usb 1-1: New USB device found,
Bug#768158: texstudio-doc: fails to upgrade from 'wheezy' - trying to overwrite /usr/share/doc/texstudio/html/doc15.png
Package: texstudio-doc Version: 2.8.4+debian-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'wheezy'. It installed fine in 'wheezy', then the upgrade to 'jessie' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces From the attached log (scroll to the bottom...): Selecting previously unselected package texstudio-doc. Unpacking texstudio-doc (from .../texstudio-doc_2.8.4+debian-1_all.deb) ... dpkg: error processing /var/cache/apt/archives/texstudio-doc_2.8.4+debian-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/texstudio/html/doc15.png', which is also in package texstudio 2.3+debian-3 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for fontconfig ... Errors were encountered while processing: /var/cache/apt/archives/texstudio-doc_2.8.4+debian-1_all.deb cheers, Andreas texstudio=2.3+debian-3_texstudio-doc=2.8.4+debian-1.log.gz Description: application/gzip
Bug#768160: ruby-twitter: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/ruby/vendor_ruby/twitter/version.rb
Package: ruby-twitter Version: 5.11.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'wheezy'. It installed fine in 'wheezy', then the upgrade to 'jessie' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces From the attached log (scroll to the bottom...): Selecting previously unselected package ruby-twitter. Unpacking ruby-twitter (from .../ruby-twitter_5.11.0-1_all.deb) ... dpkg: error processing /var/cache/apt/archives/ruby-twitter_5.11.0-1_all.deb (--unpack): trying to overwrite '/usr/lib/ruby/vendor_ruby/twitter/version.rb', which is also in package ruby-twitter4r 0.7.0-3 Errors were encountered while processing: /var/cache/apt/archives/ruby-twitter_5.11.0-1_all.deb cheers, Andreas ruby-twitter4r=0.7.0-3_ruby-twitter=5.11.0-1.log.gz Description: application/gzip
Bug#764693: modem-manager-gui: crash on start
Package: modem-manager-gui Version: 0.0.17.1-2 Followup-For: Bug #764693 Dear Maintainer, I am getting the same behaviour with newer version. I've installed debug symbols to provide backtrace: (gdb) r Starting program: /usr/bin/modem-manager-gui [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. ** (modem-manager-gui:16571): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files [New Thread 0x7fffefadc700 (LWP 16575)] Connection manager: Network Manager = 0.9.0 Modem manager: Modem Manager = 0.7.0 [New Thread 0x7fffeddae700 (LWP 16576)] ** (modem-manager-gui:16571): WARNING **: Modem Manager = 0.7.0: GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unauthorized: PolicyKit authorization failed: challenge needed for 'org.freedesktop.ModemManager1.Device.Control' ** (modem-manager-gui:16571): WARNING **: Modem Manager = 0.7.0: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type=method_call, sender=:1.78 (uid=1000 pid=16571 comm=/usr/bin/modem-manager-gui ) interface=org.freedesktop.ModemManager1.Modem.Contacts member=GetCount error name=(unset) requested_reply=0 destination=:1.30 (uid=0 pid=5511 comm=/usr/sbin/ModemManager ) ** (modem-manager-gui:16571): WARNING **: No data loaded from file Program received signal SIGSEGV, Segmentation fault. 0x76493650 in g_str_hash () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 (gdb) bt #0 0x76493650 in g_str_hash () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x76492b98 in g_hash_table_lookup () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00428b17 in mmgui_main_sms_get_message_list_from_thread (data=0xd8f530) at sms-page.c:254 #3 0x764a3b6d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x764a3f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x764a3ffc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x76a611bc in g_application_run () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #7 0x0040f212 in main (argc=1, argv=0x7fffe198) at main.c:2919 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages modem-manager-gui depends on: ii libc6 2.19-12 ii libcairo2 1.14.0-2.1 ii libgdbm31.8.3-13 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.0-2 ii libgtk-3-0 3.14.4-1 ii modemmanager1.4.0-1 ii multiarch-support 2.19-12 ii network-manager 0.9.10.0-3 ii ppp 2.4.6-3 Versions of packages modem-manager-gui recommends: ii mobile-broadband-provider-info 20140317-1 pn yelpnone Versions of packages modem-manager-gui suggests: pn evolution-data-server none ii libcanberra0 0.30-2.1 pn libindicate5 | libmessaging-menu0 none ii libnotify4 0.7.6-2 -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768159: vala-mode.el error upgrading emacs
Package: emacs24 Version: 24.4+1-4 Severity: normal I get the following error when trying to upgrade emacs24 that hit testing today: n toplevel form: vala-mode.el:115:1:Error: Symbol's function definition is void: cl-macroexpand- all ERROR: install script from vala-mode-el package failed dpkg: error processing package emacs24 (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: emacs24 Not all changes and updates succeeded. For further details of the failure, please expand the 'Details' panel below. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.3.140929 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages emacs24 depends on: ii emacs24-bin-common 24.4+1-4 ii gconf-service 3.2.6-3 ii libacl12.2.52-2 ii libasound2 1.0.28-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-12 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libdbus-1-31.8.8-2 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 ii libgconf-2-4 3.2.6-3 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgif44.1.6-11 ii libglib2.0-0 2.42.0-2 ii libgnutls-deb0-28 3.3.8-3 ii libgomp1 4.9.1-19 ii libgpm21.20.4-6.1 ii libgtk-3-0 3.14.4-1 ii libice62:1.0.9-1 ii libjpeg62-turbo1:1.3.1-10 ii libm17n-0 1.6.4-3 ii libmagickcore-6.q16-2 8:6.8.9.9-2 ii libmagickwand-6.q16-2 8:6.8.9.9-2 ii libotf00.9.13-2 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-01.36.8-2 ii libpng12-0 1.2.50-2 ii librsvg2-2 2.40.5-1 ii libselinux12.3-2 ii libsm6 2:1.2.2-1 ii libtiff5 4.0.3-10+b2 ii libtinfo5 5.9+20140913-1 ii libx11-6 2:1.6.2-3 ii libxft22.3.2-1 ii libxinerama1 2:1.1.3-1 ii libxml22.9.1+dfsg1-4 ii libxpm41:3.5.11-1 ii libxrandr2 2:1.4.2-1 ii libxrender11:0.9.8-1 ii zlib1g 1:1.2.8.dfsg-2 emacs24 recommends no packages. Versions of packages emacs24 suggests: ii emacs24-common-non-dfsg 24.4+1-2 -- 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#761996: kde-workspace: 'Sleep' menu entry is missing in kicker menu
Package: kde-workspace Version: 4:4.11.13-1 Followup-For: Bug #761996 Dear Maintainer, I've found this bug is still exist in current version. I've notices it is reproducable with systemd-shim/sysvinit-core With systemd-sysv 'Sleep' button is showing. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kde-workspace depends on: ii freespacenotifier 4:4.11.13-1 ii kde-window-manager 4:4.11.13-1 ii kde-workspace-bin 4:4.11.13-1 ii klipper 4:4.11.13-1 ii ksysguard 4:4.11.13-1 ii systemsettings 4:4.11.13-1 Versions of packages kde-workspace recommends: ii kdm 4:4.11.13-1 ii kinfocenter 4:4.11.13-1 ii kmenuedit4:4.11.13-1 kde-workspace suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768161: unblock: dogtag-pki/10.2.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package dogtag-pki It has been on sid for ~19 days, file conflict with strongswan has been fixed (for now, proper fix should get in strongswan 5.2.1-5), changelog as follows: dogtag-pki (10.2.0-3) unstable; urgency=medium * control: Add Breaks/Replaces on strongswan-starter to pki-tools. (Closes: #767561) -- Timo Aaltonen tjaal...@debian.org Wed, 05 Nov 2014 00:40:10 +0200 dogtag-pki (10.2.0-2) unstable; urgency=medium * patches: Fix servlet jar name, and paths to jss4.jar and symkey.jar. -- Timo Aaltonen tjaal...@debian.org Fri, 24 Oct 2014 20:39:24 +0300 dogtag-pki (10.2.0-1) unstable; urgency=low * Initial release (Closes: #653606) -- Timo Aaltonen tjaal...@debian.org Fri, 10 Oct 2014 14:40:12 +0300 unblock dogtag-pki/10.2.0-3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768162: fsck.ext4 -n should not just quit at the first error, else user will think there is only one error
Package: e2fsprogs Version: 1.42.12-1 Severity: wishlist File: /sbin/e2fsck User would like to cautiously examine the situation before chaning anything, so does: # fsck.ext4 -vn -B 1024 -b 8193 /dev/sde2 e2fsck 1.42.12 (29-Aug-2014) Superblock has an invalid journal (inode 8). Clear? no fsck.ext4: Illegal inode number while checking ext3 journal for /dev/sde2 /dev/sde2: ** WARNING: Filesystem still has errors ** # User assumes there is only that one little error, so then does the same command without the -n, and answers y, only to be met with another error that needs an answer, so he answer y again. Then another then another, now he wants to quit out with ^C ... which leaves filesystem even more wrecked. So there should be a q added and put into the prompt at each question, RET,y,n,q,h(help) that would allow him to quit out of who knows how many more questions. And of course -n or a new --show-all-questions should show all of what he will be getting asked, before he starts runing his disks! One could say /dev/sde2: ** WARNING: Filesystem still has errors ** says that there are errors... but one thinks it is talking about that one error that we haven't fixed yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766991: [Pkg-acpi-devel] Bug#766991: acpid: does not process events
On Wed, 05 Nov 2014 14:52:27 +0100 Michael Biebl bi...@debian.org wrote: Am 05.11.2014 um 14:25 schrieb Norbert Preining: Hi TEd, hi Michael (Meskes), override_dh_systemd_enable: dh_systemd_enable --no-enable debian/acpid.service dh_systemd_enable debian/acpid.socket That --no-enable should probably removed in the rules file. There are more kernel modules out there (thinkpad?...) that send acpi events via the kernel, thus not starting the acpid would disable all of them. Well, the kernel events are not disabled if acpid is not running. I think what you meant can be summarised as: There are different use cases for acpid: a/ dispatching acpi events via /run/acpid.socket. Those events are consumed by 3rd party applications which read from the socket file. Using systemd socket activation means, acpid is only started on demand if there is actually a consumer requiring acpid. E.g. traditionally, this was the way, Xorg read ACPI events. b/ acpid's internal event processing which calls (shell) scripts on certain events which are defined in /etc/acpi/. I assume Norbert is using acpid in mode b/, so what he noticed was, that his shell scripts in /etc/acpi/ were not processed as he apparently doesn't have a service which triggers the start of acpid by reading from /run/acpid.socket. If acpid needs to run to manage scripts in /etc/acpi/events/, then in addition to the acpid.socket file, you should also ship an acpid.path file, containing: [Path] ConditionDirectoryNotEmpty=/etc/acpi/events/ [Install] WantedBy=paths.target That will then cause systemd to automatically activate acpid.service whenever /etc/acpi/events/ becomes non-empty, in addition to acpid.socket which will activate acpid.service whenever anything connects to the acpid socket. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766914: [Virtual-pkg-base-maintainers] Processed (with 5 errors): Re: Bug#766914: closed by Amaya am...@debian.org (Re: Bug#766914: base: audio group should not be default for users)
Debian Bug Tracking System wrote: reassign 766914 user-setup Bug #766914 [base] base: audio group should not be default for users Thanks for assigning this bug to the right package. -- .''`.The world breaks everyone, and afterward, some are : :' :strong at the broken places.- Ernest Hemingway `. `' `-Proudly running Debian GNU/Linux -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766991: [Pkg-acpi-devel] Bug#766991: acpid: does not process events
Hi Michael b/ acpid's internal event processing which calls (shell) scripts on certain events which are defined in /etc/acpi/. Yes, that one. I assume Norbert is using acpid in mode b/, so what he noticed was, that his shell scripts in /etc/acpi/ were not processed as he apparently doesn't have a service which triggers the start of acpid by reading from /run/acpid.socket. Yes, because they are response scripts to simple key press events toggling the touchpad - a 5 liner in shell script. I think there should be no need for a special service for that. Amd, out of pure and simply consistency during upgrades, acpid *has* to run. I am not the only one relying on acpi scripts I guess. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#762386: Any comments?
If someone wants to debug x86 program he can install valgrind for x86. Why force amd64 valgrins users to install x86 libraries? -- eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768061: setuplibdir in config.py not used.
Hi, It seems setuplibdir in config.py is not used at all. That is why this strange value did not cause problem. | pkglibdir = '/usr/lib/x86_64-linux-gnu/ibus-hangul' | setuplibdir = pkglibdir + '/setup Actual files are /usr/lib/ibus/ibus-engine-hangul /usr/lib/ibus/ibus-setup-hangul I sugest attached as possible fix. Please note this also fix missing dh-python dependency recommended while building with newer debhelper. Osamu From e1eda085ba69d349d9ac05572a9146ba8aebcc76 Mon Sep 17 00:00:00 2001 From: Osamu Aoki os...@debian.org Date: Wed, 5 Nov 2014 23:08:28 +0900 Subject: [PATCH] Fix arch dep file in /usr/share * Fix arch dep file in /usr/share. Closes: #768061 * Add dh-python to depends. --- debian/changelog | 7 + debian/control | 1 + .../0002-Fix-remaining-s-libdir-libexecdir-g.patch | 31 ++ debian/patches/series | 1 + 4 files changed, 40 insertions(+) create mode 100644 debian/patches/0002-Fix-remaining-s-libdir-libexecdir-g.patch diff --git a/debian/changelog b/debian/changelog index 6792937..76c36b3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +ibus-hangul (1.5.0-2) unstable; urgency=medium + + * Fix arch dep file in /usr/share. Closes: #768061 + * Add dh-python to depends. + + -- Osamu Aoki os...@debian.org Wed, 05 Nov 2014 23:06:43 +0900 + ibus-hangul (1.5.0-1) unstable; urgency=medium * New upstream release diff --git a/debian/control b/debian/control index bc20a13..9755d4a 100644 --- a/debian/control +++ b/debian/control @@ -13,6 +13,7 @@ Build-Depends: autopoint, autotools-dev, debhelper (= 9~), dh-autoreconf, + dh-python, intltool, libhangul-dev (= 0.1.0), libibus-1.0-dev (= 1.4.0), diff --git a/debian/patches/0002-Fix-remaining-s-libdir-libexecdir-g.patch b/debian/patches/0002-Fix-remaining-s-libdir-libexecdir-g.patch new file mode 100644 index 000..f0d7177 --- /dev/null +++ b/debian/patches/0002-Fix-remaining-s-libdir-libexecdir-g.patch @@ -0,0 +1,31 @@ +From: Osamu Aoki os...@debian.org +Date: Wed, 5 Nov 2014 22:30:21 +0900 +Subject: Fix remaining s/libdir/libexecdir/g + +--- + setup/Makefile.am | 6 +++--- + setup/config.py.in | 4 ++-- + setup/main.py | 2 +- + 3 files changed, 6 insertions(+), 6 deletions(-) + +--- a/setup/Makefile.am b/setup/Makefile.am +@@ -64,8 +64,7 @@ + config.py: config.py.in Makefile + sed -e 's@SETUP_GETTEXT_PACKAGE@$(GETTEXT_PACKAGE)g' \ + -e 's@SETUP_LOCALEDIR@$(localedir)g' \ +- -e 's@SETUP_PKGDATADIR@$(pkgdatadir)g' \ +- -e 's@SETUP_PKGLIBDIR@$(pkglibdir)g' $ $@ ++ -e 's@SETUP_PKGDATADIR@$(pkgdatadir)g' $ $@ + + ibus-setup-hangul: ibus-setup-hangul.in config.py Makefile + sed -e 's@SETUP_PKGDATADIR@$(pkgdatadir)g' \ +--- a/setup/config.py.in b/setup/config.py.in +@@ -21,6 +21,4 @@ + gettext_package = '@SETUP_GETTEXT_PACKAGE@' + localedir = '@SETUP_LOCALEDIR@' + pkgdatadir = '@SETUP_PKGDATADIR@' +-pkglibdir = '@SETUP_PKGLIBDIR@' + setupdatadir = pkgdatadir + '/setup' +-setuplibdir = pkglibdir + '/setup' diff --git a/debian/patches/series b/debian/patches/series index a2fba86..8b09165 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1 +1,2 @@ python3.patch +0002-Fix-remaining-s-libdir-libexecdir-g.patch -- 2.1.3
Bug#764195: gcc-4.9: problems with precompiled headers on arm64
Control: tags -1 moreinfo upstream Am 06.10.2014 um 11:55 schrieb Edmund Grimley Evans: Package: gcc-4.9 Version: 4.9.1-16 There are a couple of Debian packages that failed to build on arm64 apparently because of problems with precompiled headers: qtbase-opensource-src See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762702 aegisub See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764187 It's difficult to extract a small test case, and it's presumably impossible to reproduce the problem with preprocessed source as GCC's standard internal compiler error message suggests. please recheck with 4.9.2 and trunk (gcc-snapshot). In the past I had mixed results with precompiled headers on AArch64. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767893: systemd cannot mount zfs filesystems from fstab
On November 3, 2014 9:36:49 AM EST, Michael Biebl bi...@debian.org wrote: Am 03.11.2014 um 15:06 schrieb John Holland: It seems like it is unable to mount a zfs volume given in fstab during boot. Strangely the presence of such an entry in fstab also seems to cause the password entry problem. With no zfs in fstab I can enter the passwords and the zfs volumes with non legacy mount points mount ok. It sounds like maybe I need to try a Plymouth theme as well as just plymouth as I do not get a graphical start screen. However if a fix is coming for systemd maybe I should wait for that to see if it clears it up. On November 3, 2014 8:09:44 AM EST, Zbigniew Jędrzejewski-Szmek zjedr...@gmu.edu wrote: On Mon, Nov 03, 2014 at 05:51:57AM -0500, John Holland wrote: I created luks volumes, installed zfsonlinux.org packages, created a zpool out of the luks volumes. When ZFS is managing the mounting of the fs's it works. If I put a zfs filesystem in /etc/fstab the prompts to enter passwords for the luks volumes during boot are mixed in with output. So actually its not the ZFS volumes, but simply the luks unlocking that is the problem? You say that the prompts are mixed with output, but do things work if you type in the password blind? You can either wait until systemd-217 (which fixes the overlapping output) or install plymouth (which provides a graphical prompt which is not interrupted by text output). http://changelog.complete.org/archives/9241-update-on-the-systemd-issue might be relevant for you. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#765857: [cowbuilder] Unable to create Jessie i386 environment on amd64 host, pbuilder works on its own
On 05/11/14 06:39, Junichi Uekawa wrote: cowbuilder uses LD_PRELOAD'ed library that it won't have a chance of working on a different architecture (well, if you implement enough it probably works). On my Testing amd64 install, the following call fails: = # sudo HOME=$HOME eatmydata cowbuilder --create --mirror http://10.1.0.3:3142/ftp.uk.debian.org/debian --basepath /var/cache/pbuilder/jessie-i386-test/base.cow --distribution jessie --debootstrapopts --arch --debootstrapopts i386 This is all new to me, but I remember successfully doing it before. What about the fact this issue affects a bogstandard Jessie amd64 environment creation, which is the current installed environment? -- Libre software on Github: https://github.com/OmegaPhil FSF member #9442 signature.asc Description: OpenPGP digital signature
Bug#768163: CUPS and CM option
Package: CUPS Version: 1.7.5 I just found out that on the CUPS page when defining (or modifying) a printer the Color Calibration Mode check box only appears only when the language of the desktop is set to English. I found this because I'm French and using a french desktop on GNOME Shell. But this option was on a new box I had installed without all locales, so defaulting to English. I can confirm this, by switching from English to French and back the option Color Calibration Mode is present or not. Attached are two screen shots with the pages in French and in English. The screen shots are taken from the same computer. The only change was the default language. Regards, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Bug#762386: valgrind: Last version requires libc6-386. Why?
Package: valgrind Followup-For: Bug #762386 I would also know if this is a hard dependency, or not. I guess it was probably intended to be a Recommend? And if it is, could you depend/recommend on libc6:i386 | libc6-i386 instead? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768164: haskell-tls: SSLv3 support
Package: haskell-tls Severity: important Tags: security Hi, openssl disabled SSLv3 for jessie since 1.0.1j-1. Shall we do the same for haskell-tls? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762637: RFP: qtile -- full-featured, pure-Python tiling window manager
Debian is going in freeze and it might be worth delaying the packaging given that: Version 0.8 is based on xpyb, pycairo/pangocairo, pygtk A test package, once installed, was impacted by #669907 The current development version is based on xcffib, cairocffi, asyncio In the next release: - python-cairocffi will replace python-cairo - xcffib will replace xpyb Thanks -- Federico Ceratto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768020: [Pkg-shadow-devel] Bug#768020: Missing /dev/ttySC* entries in /etc/securetty
On 05 Nov 2014 09:16, Geert Uytterhoeven wrote: On Tue, Nov 4, 2014 at 6:31 PM, Mike Frysinger vap...@gentoo.org wrote: On 04 Nov 2014 10:04, Geert Uytterhoeven wrote: Package: login Version: 1:4.2-2+b1 /etc/securetty contains the following /dev/ttySC* entries: | # SCI serial port (SuperH) ports and SC26xx serial ports | ttySC0 | ttySC1 | ttySC2 | ttySC3 Some Renesas ARM-based SH-Mobile development boards have the serial console on ttySC4 or ttySC6, or a secondary console on ttySC7. At least one SH-based board has its serial console on ttySC5. Can you please add entries ttySC[4-9]? there's a lot of boards with a lot of different serial devices. i'm not sure every possibility should be hardcoded ? every distro is duplicating this work too and maintaining their own random full list. can't we do better here ? Unfortunately, due to the only real 16550 serial ports can be called ttyS%u rule... i'm aware (having written merged some serial drivers myself). my point was to improve things by default in userland. perhaps the default should be to not have an /etc/securetty at all ? if the system is configured to launch getty on a tty, then in today's world, it means it's a local device right ? if you have physical access to something, and know It may still be connected to a modem, waiting for incoming calls... how many of these systems legitimately exist anymore ? we shouldn't be handicapping the majority of users for an extreme edge case. if those people want to set up securetty, they can create the file themselves. the root password, what exactly is this protecting the system from ? /etc/securetty is not meant to prevent privileged people from getting in, but to protect the system against eavesdropping on unsecure lines (.e.g. out-of-the-building serial cables and modem lines). how does securetty prevent that ? you can log in as non-root and then sudo. or try and leverage a known security vuln to escalate that non-root account. any perceived security provided by securetty is an illusion. -mike signature.asc Description: Digital signature
Bug#746578: libpam-systemd to flip dependencies - proposal
On Wed, 5 Nov 2014 11:49:45 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - proposal): So, I hereby formally propose the resolution text below. I intend to call for votes some time tomorrow. Thanks again to Josh for all his careful and constructive interventions in the discussion. I'm glad to see that he's now happy with this proposal. This proposal doesn't seem to include the change you made in git commit 227f496617929c48bfd20a9c96eead8b91ee69b7 to fix a typo I reported in item 4: 4. In particular, on systems that already have systemd-sysv installed, libpam-systemd will still not pull in systemd-shim, thus minimizing the risk of breakage on systemd systems. However, on systems that intentionally do not have systemd installed, the installation of libpam-systemd will then prefer to pull in systemd-shim and keep the installed init system rather than switching to systemd-sysv. In your mail with Message-ID 21590.30193.479905.710...@chiark.greenend.org.uk, you said: Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - proposal): [...] s/intentionally do not have systemd/intentionally do not have systemd-sysv/ Fixed in git. I hereby make that change to my formal proposal. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754854: [uwsgi] patch 1005 should not be needed
Il 27/10/2014 17:44, Riccardo Magliocchetti ha scritto: Hello, Il 25/10/2014 21:28, Jonas Smedegaard ha scritto: Hi, Riccardo Magliocchetti wrote: Patch 1005_emperor-pg-fix-cflags.patch should have been already fixed upstream in 7c31b6657ffdbbbe566822fbcdb6cf2eb4b44026 so could be removed. Indeed that upstream commit look quite related, but removing patch 1005 cause the build to fail - just tried for 2.0.7-1. Help investigating what is going on here is appreciated. Looks like the saner option would be to remove the build hack that was added for unknown reason, see: https://github.com/unbit/uwsgi/pull/759 A more conservative patch has been applied to master, so it would be nice if you can substitute 1005 with [1]. If that works fine for you i'll ask to have it backported to 2.0.x so you can drop it. [1] https://github.com/unbit/uwsgi/commit/35acf3793d9c586c366d6d9b2b9f9f124f302060 thanks -- Riccardo Magliocchetti -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746578: libpam-systemd to flip dependencies - proposal
On Wed, 05 Nov 2014 08:42:07 -0500 Sam Hartman hartm...@debian.org wrote: I don't think this matters for the vote, and apologies because there's probably a better place to send this advice. I was thinking last night about the apt and debootstrap resolver issues and was wondering whether the following solution might help. I realize the issue is minor and is more about minimizing packages installed than safety of the proposal. What if libpam-systemd depended on systemd-shim-nosysv|systemd-sysv|systemd-shim? Introduce a new package systemd-shim-nosysv in the systemd-shim package that depends on systemd-shim and conflicts with systemd-sysv. I have not tried this. It might reduce the probability that systemd-shim gets uselessly installed. however, I don't know whether it creates systems where systemd-sysv gets removed. Seems like a great idea to me; we talked a bit about Conflicts in the context of cgmanager, but this approach (with an artificial intermediate package) makes much more sense. I agree that it needs careful testing, though; after Christian Seiler's testing of debootstrap and apt, I really don't know how either would decide to resolve this. Either or both might well decide to choose the alternate dependency of the essential init package rather than the alternate dependency of libpam-systemd. Even if this does end up being a good idea, I don't think the TC resolution needs to change. As I read it, the essential character of the resolution is that systemd-shim is preferred to systemd-sysv in libpam-systemd. If we find better technical ways of doing that, more power to us all. If there is a real disagreement about whether we're within the spirit of the TC resolution should it pass, we can ask the TC again either informally or formally. I don't want to see us getting ultra-picky about the wording of resolutions to constrain or permit future innovation. I agree; when I suggested clarifying in the TC decision that the Depends shouldn't be hard-coded (what became clause 6 of the current proposal), I didn't just have versioned dependency changes in mind, but also package structural changes (on either systemd's or systemd-shim's part). I think the suggestion you made above fits entirely within the spirit of the TC resolution. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766840: [armhf] Illegal assembler code generated with -O2
Control: forwarded -1 https://gcc.gnu.org/PR63749 Control: tags -1 + upstream Am 26.10.2014 um 10:48 schrieb Ole Streicher: The warnings are on similar places as above, just with the floats replaced by doubles or long doubles. please attach the original file as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768164: [Pkg-haskell-maintainers] Bug#768164: haskell-tls: SSLv3 support
Hi, Am Mittwoch, den 05.11.2014, 16:45 +0100 schrieb Moritz Muehlenhoff: Package: haskell-tls Severity: important Tags: security Hi, openssl disabled SSLv3 for jessie since 1.0.1j-1. Shall we do the same for haskell-tls? good question. Probably yes. Did openssl disable SSLv3 completely, or did it just removed it from the default list of accepted settings? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#768165: RM: matrixssl -- RoQA; outdated, unmaintained
Package: ftp.debian.org Severity: normal Hi, please remove matrixssl. It's orphaned for a while and noone was interested in adopting it since 2009 (544057). The version currently in the archive is outdated; the last rev dep (ipsvd) moved away from it. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768166: [libpsl0] Typo in extended description
Package: libpsl0 Version: 0.5.1-1 Severity: minor The extended description contains: Libpsl allows checking domains against the Public Suffix List, It can be used to avoid privacy-leaking 'super-cookies', 'super domain' certificates, for domain highlighting purposes sorting domain lists by site and more. This should be two sentences. The first comma should be replaced with a period. By the way, I don't really understand what this library does after reading this description without getting more information, even though I am not ignorant about cookies, certificates and domains. Questions which come to mind: What is the Public Suffix List? What are 'super-cookies'? What are 'super domain'-s? What is domain highlighting? What does sorting domain lists by site mean? It is not necessary for the description to answer all of these, but if it's simple to answer some, this might help readers figure out what kind of service this package provides. -- Filipus Klutiero http://www.philippecloutier.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768164: [Pkg-haskell-maintainers] Bug#768164: haskell-tls: SSLv3 support
On Wed, Nov 05, 2014 at 05:07:15PM +0100, Joachim Breitner wrote: Hi, Am Mittwoch, den 05.11.2014, 16:45 +0100 schrieb Moritz Muehlenhoff: Package: haskell-tls Severity: important Tags: security Hi, openssl disabled SSLv3 for jessie since 1.0.1j-1. Shall we do the same for haskell-tls? good question. Probably yes. Did openssl disable SSLv3 completely, or did it just removed it from the default list of accepted settings? openssl disabled it entirely; it features a dedicated build flag for it (no-ssl3). Could you approach haskell-tls upstream for their recommendation to disable it? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768167: dpkg-architecture export DEB_TARGET_* make cross build failure
Package: src:gcc-4.9 Version: 4.9.2-1 In the past, dpkg-architecture doesn't export DEB_TARGET_* Vars, so in rules.defs ifdef DEB_TARGET_GNU_TYPE TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) else # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif DEB_TARGET_ARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) DEB_TARGET_ARCH_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) DEB_TARGET_GNU_TYPE ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) DEB_TARGET_MULTIARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) works But now, when DEB_TARGET_GNU_TYPE and DEB_TARGET_ARCH always define, we can not get cross complier with debian/target file or DEB_GCC_TARGET var. Modifying it to this can fix this problem # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) DEB_TARGET_ARCH := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) DEB_TARGET_ARCH_OS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) DEB_TARGET_ARCH_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) DEB_TARGET_GNU_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) DEB_TARGET_GNU_TYPE := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) DEB_TARGET_GNU_SYSTEM := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) DEB_TARGET_MULTIARCH:= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) GCC 4.8 also has the same problem. -- YunQiang Su --- gcc-4.9-4.9.2/debian/rules.defs 2014-11-06 00:12:34.0 +0800 +++ gcc-4.9/debian/rules.defs 2014-11-06 00:03:38.081051557 +0800 @@ -89,33 +89,30 @@ ifdef GCC_TARGET DEB_GCC_TARGET := $(GCC_TARGET) endif -ifdef DEB_TARGET_GNU_TYPE - TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) -else - # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested - # by toolchain-source maintainer - DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) - ifndef DEB_TARGET_ARCH -ifneq (,$(DEBIAN_TARGET_FILE)) - DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) + +# allow debian/target to be used instead of DEB_GCC_TARGET - this was requested +# by toolchain-source maintainer +DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) +ifndef DEB_TARGET_ARCH + ifneq (,$(DEBIAN_TARGET_FILE)) +DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) + else +ifdef DEB_GCC_TARGET + DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else - ifdef DEB_GCC_TARGET -DEB_TARGET_ARCH := $(DEB_GCC_TARGET) - else -DEB_TARGET_ARCH := $(DEB_HOST_ARCH) - endif + DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif - TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif +TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) -DEB_TARGET_ARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) -DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) -DEB_TARGET_ARCH_CPU?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) -DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) -DEB_TARGET_GNU_TYPE?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) -DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) -DEB_TARGET_MULTIARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) +DEB_TARGET_ARCH:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) +DEB_TARGET_ARCH_OS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) +DEB_TARGET_ARCH_CPU:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) +DEB_TARGET_GNU_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) +DEB_TARGET_GNU_TYPE:= $(call
Bug#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)
Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - proposal): On Wed, 5 Nov 2014 11:49:45 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: Thanks again to Josh for all his careful and constructive interventions in the discussion. I'm glad to see that he's now happy with this proposal. This proposal doesn't seem to include the change you made in git commit 227f496617929c48bfd20a9c96eead8b91ee69b7 to fix a typo I reported in item 4: Bum. Given that I had already formally made the change, I think my call for votes should be read as being a CFV on the revised version, notwithstanding that the resolution text was incorrectly stated in the CFV email. For the avoidance of any doubt: I am calling for votes on the text below: Y (override, swap dependencies, requires 3:1) FD Ian. (My previous vote of Y,FD stands.) === Rationale (Constitution 6.1(5)): 1. Currently libpam-systemd (which is pulled in by quite a few dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'. 2. The effect of this is that installing some packages which depend (directly or indirectly) on libpam-systemd can cause a user's init system to be switched to systemd, even on systems where a user has deliberately chosen not to use the default init system, and even when the switch is unnecessary. 3. Swappping the order of these dependencies would avoid that and has no harmful effect: 4. In particular, on systems that already have systemd-sysv installed, libpam-systemd will still not pull in systemd-shim, thus minimizing the risk of breakage on systemd systems. However, on systems that intentionally do not have systemd-sysv installed, the installation of libpam-systemd will then prefer to pull in systemd-shim and keep the installed init system rather than switching to systemd-sysv. Decision (Constitution 6.1(4)): 5. We therefore overrule the decision of the maintainer of libpam-systemd binary package. The Depends entry systemd-sysv | systemd-shim (= 8-2) should be replaced by systemd-shim (= 8-2) | systemd-sysv 6. For the avoidance of doubt, we do not intend to set this specific syntax in stone. For example, if in future libpam-systemd needs to depend on a later systemd-shim, or needs a versioned rather than unversioned dependency on systemd-sysv, that is fine and would not contradict our decision. Release (Constitution 6.1(5)): 7. Our advice is that this change should be in jessie. If necessary, this view should be conveyed to the Release Team, after the change is in unstable, by filing an unblock request in the usual way. === -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767359: fixed in lightdm 1.10.3-3
Thanks for fixing that bug. I just wanted to add, that version 1.10.3-3 also fixes the bug that the selected user is not remembered anymore (I was just going to report that one). So if anyone wonders how to get rid of that bug, just install 1.10.3-3. Kind regards Patrick signature.asc Description: This is a digitally signed message part.
Bug#765156: flashproxy is marked for autoremoval from testing
Hi, On Dienstag, 4. November 2014, Ximin Luo wrote: OK, I've uploaded a release candidate to mentors, same address as above. I took a look, and there are two or three problems, though the fix itself is mostly fine I think :-) 1. bumping the standards version now is often perceived as unwanted noise by those reviewing the changes to decide whether to let it enter jessie. leave it now, but next time please only include non-cosmetic changes _if_ you add non ron-RC fixes at all. 2. your fix for #765156 looks good to me, I just wonder whether in the following it really should only be 20 and not 40 or 100... are you sure that safe enough now and in 5 years? ++for i in xrange(0, 20): (I think so, as hw gets faster but... maybe 40 is still better as there could be even slower hw??) 3. there are lot of changes in debian/rules between 1.7-1 and 1.7-2 and there's no mentioning of those in debian/changelog at all. Is there a bug# for the problem they are fixing? Get well soon! thanks, I'm on it..! :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#766466: php-guzzle: ftbfs and (sometimes) after built attempt in pbuilder, nodejs still runs server.js
Hi David, On Dienstag, 28. Oktober 2014, David Prévot wrote: Seems to be related to the proxy: if I run the test with http_proxy set to use a local Squid, I manage to get failing tests (albeit without segfault). I just uploaded 3.9.2+dfsg-5 that unsets http_proxy for running the tests, please let me know if that’s enough for Jenkins (and if the segfault vanished ;). you should be able to see yourself at https://jenkins.debian.net/userContent/reproducible.html - it should have built 3.9.2+dfsg-5 by now, at least there was no build backlog there this morning... I'm writing this offline so cannot check atm. (But bcc:ing myself to make sure I will check when I'm online again :) yes, those are two bugs. I'll leave the cloning to you though. You have a better grasp whats happening. Let’s see first if we’re able to kill two birds with one stone ;). ok, sure! :) cheers Holger signature.asc Description: This is a digitally signed message part.
Bug#767668: gcc-4.9: gcc internal compiler error with atomic_compare_exchange_weak_explicit
Control: forwarded -1 https://gcc.gnu.org/PR63751 Control: tags -1 + upstream fixed-upstream Am 01.11.2014 um 20:33 schrieb Daniele Di Proietto: the attached code leads to an internal compiler error. I didn't try it with upstream GCC, only with GCC from debian testing. this is fixed upstream (GCC 5) and in Debian (gcc-snapshot). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
Package: watchdog Version: 5.14-1 Severity: important Dear Maintainer, since the last upgrade watchdog does not get started at boot time: Nov 05 16:42:52 grappa systemd[1]: Found ordering cycle on graphical.target/start Nov 05 16:42:52 grappa systemd[1]: Breaking ordering cycle by deleting job watchdog.service/start Nov 05 16:42:52 grappa systemd[1]: Job watchdog.service/start deleted to break ordering cycle starting with graphical.target/start Starting the service manually works. The only modification in the config files I have done manually is to enable the watchdog-device. Regards Uwe -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (750, 'testing'), (650, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages watchdog depends on: ii debconf [debconf-2.0] 1.5.53 ii init-system-helpers1.21 ii libc6 2.19-12 ii lsb-base 4.1+Debian13+nmu1 ii makedev2.3.1-93 ii udev 215-5+b1 watchdog recommends no packages. watchdog suggests no packages. -- Configuration Files: /etc/default/watchdog changed: run_wd_keepalive=1 run_watchdog=1 watchdog_module=none watchdog_options= /etc/watchdog.conf changed: watchdog-device = /dev/watchdog realtime= yes priority= 1 -- debconf information: * watchdog/run: true * watchdog/module: none * watchdog/restart: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768167: dpkg-architecture export DEB_TARGET_* make cross build failure
On Thu, 6 Nov 2014 00:15:13 +0800 YunQiang Su wzss...@gmail.com wrote: Package: src:gcc-4.9 Version: 4.9.2-1 In the past, dpkg-architecture doesn't export DEB_TARGET_* Vars, so in rules.defs ifdef DEB_TARGET_GNU_TYPE TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) else # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif DEB_TARGET_ARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) DEB_TARGET_ARCH_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) DEB_TARGET_GNU_TYPE ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) DEB_TARGET_MULTIARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) works But now, when DEB_TARGET_GNU_TYPE and DEB_TARGET_ARCH always define, we can not get cross complier with debian/target file or DEB_GCC_TARGET var. Modifying it to this can fix this problem # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested # by toolchain-source maintainer DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) ifndef DEB_TARGET_ARCH This line is also need to be removed, so update the patch. ifneq (,$(DEBIAN_TARGET_FILE)) DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else ifdef DEB_GCC_TARGET DEB_TARGET_ARCH := $(DEB_GCC_TARGET) else DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif endif endif TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) --- gcc-4.9-4.9.2/debian/rules.defs 2014-11-06 00:12:34.0 +0800 +++ gcc-4.9/debian/rules.defs 2014-11-06 00:34:16.521099152 +0800 @@ -89,33 +89,28 @@ ifdef GCC_TARGET DEB_GCC_TARGET := $(GCC_TARGET) endif -ifdef DEB_TARGET_GNU_TYPE - TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2/dev/null) + +# allow debian/target to be used instead of DEB_GCC_TARGET - this was requested +# by toolchain-source maintainer +DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) +ifneq (,$(DEBIAN_TARGET_FILE)) + DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) else - # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested - # by toolchain-source maintainer - DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2/dev/null))) - ifndef DEB_TARGET_ARCH -ifneq (,$(DEBIAN_TARGET_FILE)) - DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE) -else - ifdef DEB_GCC_TARGET -DEB_TARGET_ARCH := $(DEB_GCC_TARGET) - else -DEB_TARGET_ARCH := $(DEB_HOST_ARCH) - endif -endif + ifdef DEB_GCC_TARGET +DEB_TARGET_ARCH := $(DEB_GCC_TARGET) + else +DEB_TARGET_ARCH := $(DEB_HOST_ARCH) endif - TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) endif +TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2/dev/null) -DEB_TARGET_ARCH?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) -DEB_TARGET_ARCH_OS ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) -DEB_TARGET_ARCH_CPU?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) -DEB_TARGET_GNU_CPU ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) -DEB_TARGET_GNU_TYPE?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) -DEB_TARGET_GNU_SYSTEM ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) -DEB_TARGET_MULTIARCH ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) +DEB_TARGET_ARCH:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH) +DEB_TARGET_ARCH_OS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS) +DEB_TARGET_ARCH_CPU:= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU) +DEB_TARGET_GNU_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU) +DEB_TARGET_GNU_TYPE:= $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) +DEB_TARGET_GNU_SYSTEM := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) +DEB_TARGET_MULTIARCH := $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) ifeq ($(DEB_TARGET_GNU_TYPE),i486-linux-gnu) DEB_TARGET_GNU_TYPE = i586-linux-gnu
Bug#763517: patches breaking color management
Control: reopen -1 1.7.5-7 Control: tags -1 +moreinfo CC'ing Till and Joe; please go see https://bugs.debian.org/763517#54 for the example image. Le mercredi, 5 novembre 2014, 14.04:15 Pascal Obry a écrit : In fact no, it is not fixed it was a testing procedure on my side. Sorry! How to reopen this ticket? Hereby doing this. I have attached a picture of the wrong output from Debian (CUPS 1.7.5) and the correct from Ubuntu (CUPS 1.7.2). We clearly see the purple color cast on the print from Debian (the base picture is BW). I don't see it that clearly. :-) Pascal: it would be useful to describe precisely how you configured your printer with color management. If you could also try older versions of gutenprint http://snapshot.debian.org/package/gutenprint/, that'd really help too. TIA, Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768020: [Pkg-shadow-devel] Bug#768020: Missing /dev/ttySC* entries in /etc/securetty
On Wed, Nov 5, 2014 at 4:49 PM, Mike Frysinger vap...@gentoo.org wrote:
perhaps the default should be to not have an /etc/securetty at all ? if
the
system is configured to launch getty on a tty, then in today's world, it
means
it's a local device right ? if you have physical access to something, and
know
It may still be connected to a modem, waiting for incoming calls...
how many of these systems legitimately exist anymore ? we shouldn't be
handicapping the majority of users for an extreme edge case. if those people
want to set up securetty, they can create the file themselves.
the root password, what exactly is this protecting the system from ?
/etc/securetty is not meant to prevent privileged people from getting in,
but to protect the system against eavesdropping on unsecure lines
(.e.g. out-of-the-building serial cables and modem lines).
how does securetty prevent that ? you can log in as non-root and then sudo.
or
try and leverage a known security vuln to escalate that non-root account. any
perceived security provided by securetty is an illusion.
Ah, sudo is a recent invention ;-)
But you're right, /etc/securetty has little value these days.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766466: php-guzzle: ftbfs and (sometimes) after built attempt in pbuilder, nodejs still runs server.js
Hi, so it build twice as can be seen on https://jenkins.debian.net/userContent/rb- pkg/php-guzzle.html so I guess you can close this bug! cheers thanks, Holger signature.asc Description: This is a digitally signed message part.
Bug#768169: ITP: sfarklib -- Library for decompressing sfArk soundfonts
Package: wnpp Severity: wishlist Owner: Ruben Undheim ruben.undh...@gmail.com * Package name: sfarklib Version : 0.20131219gitee08d0c Upstream Author : Andy Inman * URL : http://melodymachine.com/sfark-linux-mac * License : GPL-3 Programming Lang: C++ Description : Library for decompressing sfArk soundfonts sfArk is a lossless audio compression format optimized for SoundFont files. This library can decompress such files into .sf SoundFont files. I intend to maintain it as part of the Debian Science team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768170: squid3 fails to upgrade
Package: squid3 Version: 3.4.8-2 Severity: important Hi! It seems that upgrading from stable to current version doesn't work out as expected. To reproduce install squid3 from stable, then change the config a bit (the listening port from 3128 to 3127 for example) and do a apt-get upgrade (squid3 from stable is running before the upgrade). You'll end up with this: The following packages will be upgraded: squid3 squid3-common 2 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. Need to get 0 B/2326 kB of archives. After this operation, 2493 kB of additional disk space will be used. Reading changelogs... DoneY/n] (Reading database ... 163947 files and directories currently installed.) Preparing to unpack .../squid3_3.4.8-2_amd64.deb ... Unpacking squid3 (3.4.8-2) over (3.1.20-2.2+deb7u2) ... Preparing to unpack .../squid3-common_3.4.8-2_all.deb ... Unpacking squid3-common (3.4.8-2) over (3.1.20-2.2+deb7u2) ... Processing triggers for man-db (2.7.0.2-3) ... Setting up squid3-common (3.4.8-2) ... Setting up squid3 (3.4.8-2) ... Installing new version of config file /etc/init.d/squid3 ... Installing new version of config file /etc/logrotate.d/squid3 ... Installing new version of config file /etc/resolvconf/update-libc.d/squid3 ... Configuration file '/etc/squid3/squid.conf' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** squid.conf (Y/I/N/O/D/Z) [default=N] ? Creating Squid HTTP proxy 3.x spool directory structure 2014/11/05 17:11:09| aclParseAclLine: ACL 'manager' already exists with different type. FATAL: Bungled /etc/squid3/squid.conf line 693: acl manager proto cache_object Squid Cache (Version 3.4.8): Terminated abnormally. CPU Usage: 0.016 seconds = 0.016 user + 0.000 sys Maximum Resident Size: 36720 KB Page faults with physical i/o: 0 dpkg: error processing package squid3 (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: squid3 E: Sub-process /usr/bin/dpkg returned an error code (1) If I change the squid.conf.dpkg-dist into squid.conf then I can finish the install. On the old config we have: acl manager proto cache_object http_access allow manager localhost http_access deny manager And looks to me that there is a new manager acl defined internally as I cannot see it defined anywhere on the new config file but I can see it being used: http_access allow localhost manager http_access deny manager Regards -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/1 CPU core) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages squid3 depends on: ii adduser 3.113+nmu3 ii libc62.19-12 ii libcap2 1:2.24-6 ii libcomerr2 1.42.12-1 ii libdb5.3 5.3.28-6 ii libecap2 0.2.0-1 ii libexpat12.1.0-6 ii libgcc1 1:4.9.2-1 ii libgssapi-krb5-2 1.12.1+dfsg-11 ii libk5crypto3 1.12.1+dfsg-11 ii libkrb5-31.12.1+dfsg-11 ii libldap-2.4-22.4.40-2 ii libltdl7 2.4.2-1.11 ii libnetfilter-conntrack3 1.0.4-1 ii libnettle4 2.7.1-3 ii libpam0g 1.1.8-3.1 ii libsasl2-2 2.1.26.dfsg1-12 ii libstdc++6 4.9.2-1 ii libxml2 2.9.2+dfsg1-1 ii logrotate3.8.7-1 ii lsb-base 4.1+Debian13+nmu1 ii netbase 5.3 ii squid3-common3.4.8-2 squid3 recommends no packages. Versions of packages squid3 suggests: pn resolvconf none ii smbclient2:4.1.13+dfsg-2 pn squid-cginone pn squid-purge none pn squidclient none pn ufw none pn winbindd none -- Configuration Files: /etc/squid3/squid.conf changed [not included] -- 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#768173: ITP: sfarkxtc -- Converts soundfonts in the legacy sfArk v2 file format to sf2
Package: wnpp Severity: wishlist Owner: Ruben Undheim ruben.undh...@gmail.com * Package name: sfarkxtc Version : 0.20130812git80b1da3 Upstream Author : Andy Inman * URL : http://melodymachine.com/sfark-linux-mac * License : GPL-3 Programming Lang: C++ Description : Converts soundfonts in the legacy sfArk v2 file format to sf2 This is a very small command line tool to convert legacy sfArk files into the SoundFont 2 format. It uses the library sfarklib. I intend to maintain it as part of the Debian Science team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767659: evince 3.14.1-1 gets undefined symbol with libpoppler46:i386 earlier than 0.26.5-2
I can confirm this issue and its resolution. I got the same segfault about the same undefined symbol when I last upgraded evince: ii libpoppler-glib8:amd640.26.5-2 amd64PDF rendering library (GLib-based shared library) ii libpoppler46:amd640.26.5-1 amd64PDF rendering library ii poppler-data 0.4.7-1 all encoding data for the poppler PDF rendering library ii poppler-utils 0.26.5-2 amd64PDF utilities (based on Poppler) ii evince3.14.1-1 amd64Document (PostScript, PDF) viewer ii evince-common 3.14.1-1 all Document (PostScript, PDF) viewer - common files ii gir1.2-evince-3.0 3.14.1-1 amd64GObject introspection data for the evince libraries The error message: (evince:1962): EvinceDocument-WARNING **: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8: undefined symbol: _ZN7GfxFont16getAlternateNameEPKc Segmentation fault also, manually upgrading libpoppler46 to the -2 version fixed the issue. since the problem seems to be coming from the version difference between libpoppler46 and libpoppler-glib8, this bug report might be more suited to the library libpoppler-glib8, since that's the package that's depending on libpoppler46 -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Bug#766459: please don't upload this to wheezy
On Wed, Nov 05, 2014 at 06:05:59AM +0100, Adam Borowski wrote: For reasons I explained in #767999, hacking debootstrap to configure base-passwd and base-files in a specific order is neither sufficient nor necessary. It does work around the problem for those running debootstrap from fully upgraded unstable (and if it was uploaded to stable, wheezy) but doesn't help in any other use cases. I never imagined to find so much bias in a single email message. hacking debootstrap: It's not hacking, it's fixing a bug. In fact, the fix is obvious, reasonable and clean. is not necessary. Yes, it is necessary, because base-passwd is essential and base-files is just using a feature of an essential package, namely chown and default Debian system users, as does dpkg and quite a few other essential packages in their postinst. And once that this necessary thing is done, the problem will disappear, so it's sufficient as well. It does work around the problem. No, it actually fixes the problem. The problem is that base-files uses the feature of an essential package before the essential package is ready, but that's precisely what debootstrap is supposed to do: ensuring that everything works by breaking the cycles. but doesn't help in any other use cases. Sure. It only fixes the problem in stable, testing and unstable. Ok, this would leave oldstable and non Debian systems, but those will always be able to use the version in stable. debootstrap is written to be portable and only needs wget to work. (Hmm. And people still wonder why this issue makes me to be upset) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768171: RFP: yacy -- A free (libre) decentralised Internet Search Engine
Package: wnpp Severity: wishlist * Package name: yacy Version : 1.8 Upstream Author : * URL : http://www.yacy-websuche.de/wiki/index.php/En:DebianInstall * License : GPL Programming Lang: java Description : A free (libre) decentralised Internet Search Engine [debian packages already exist for this software] YaCy is a free search engine that anyone can use to build a search portal for their intranet or to help search the public internet. When contributing to the world-wide peer network, the scale of YaCy is limited only by the number of users in the world and can index billions of web pages. It is fully decentralized, all users of the search engine network are equal, the network does not store user search requests and it is not possible for anyone to censor the content of the shared index -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768172: internal error: unsupported dialog type 2
Package: util-linux Version: 2.25.2-2 Severity: wishlist File: /sbin/cfdisk X-debbugs-CC: Karel Zak k...@redhat.com For size just type 1 instead of 1M, then hit RET upon seeing [ primary ] this will generate internal error: unsupported dialog type 2. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765156: flashproxy is marked for autoremoval from testing
On 05/11/14 14:40, Holger Levsen wrote: Hi, On Dienstag, 4. November 2014, Ximin Luo wrote: OK, I've uploaded a release candidate to mentors, same address as above. I took a look, and there are two or three problems, though the fix itself is mostly fine I think :-) 1. bumping the standards version now is often perceived as unwanted noise by those reviewing the changes to decide whether to let it enter jessie. leave it now, but next time please only include non-cosmetic changes _if_ you add non ron-RC fixes at all. OK. 2. your fix for #765156 looks good to me, I just wonder whether in the following it really should only be 20 and not 40 or 100... are you sure that safe enough now and in 5 years? ++for i in xrange(0, 20): (I think so, as hw gets faster but... maybe 40 is still better as there could be even slower hw??) The previous sleep time was 0.1s, and now it will sleep for a maximum of 1s (10 times the previous), so I think this should be OK. 3. there are lot of changes in debian/rules between 1.7-1 and 1.7-2 and there's no mentioning of those in debian/changelog at all. Is there a bug# for the problem they are fixing? I just noticed that I wasn't running some of the tests, that's all it is (and some variable renames for consistency). So I figured this is too trivial to put in debian/changelog, and there is no effect on the binary packages. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Bug#768156: general: dpkg frontend inconsistent
Hi Michal, On Mittwoch, 5. November 2014, Michal Suchanek wrote: I was upgrading my system and several times I was asked for installing a new configuration file. Sometimes the question is posed in teletype style frontend sometimes in colour character terminal TUI style frontend. which tool did you use (how) to upgrade? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#758622: kernel crashes after soft lockups in xen domU
And some more information ... Am 2014-10-13 12:04, schrieb Jonas Meurer: Am 2014-08-19 12:26, schrieb Jonas Meurer: I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware setup. I'm unable to reproduce the crash on another Xen system with same kernel an Xen versions but different CPU and motherboard. The VM runs in production mode on the second Xen system since several weeks without one single crash. I've got a test system now where I'm able to reproduce the bug by putting the VM (a webserver) under heavy load with the help of siege and pylot. The VM crashes every time I put the webserver under heavy load, everytime with the same backtrace. I replaced the full system (all hardware components except the harddisks) with a new one in the meantime - and still the bug is repoducible. I'll try to describe the setup: Two Xen virtualization servers (xen1 and xen2), mirroring one block device with DRBD using a primary/secondary setup. The DRBD device holds LVM with the LVs for one single virtual machine (the webserver). This webserver runs an Apache2 daemon. The first virtualization server (xen1, the one that's live) runs rock stable, same for the webserver VM on top. No crashes, no exploding load. The second virtualization server (xen2) runs well as long as it's only secondary (i.e. no virtual machine started). As soon as I switch the DRBD primary to xen2 and start the webserver VM there, load on the webserver is unusual high, it becomes laggy and after some hours (sometimes minutes) it crashes like described in earlier mails. Now I created a test-VM on xen2 that is not on top of the DRBD device in order to factor out DRBD as reason. As already written, if I fire some HTTP requests against the Apache daemon on the test-VM, the VM crashes the same way. I first replaced memory modules and CPU by similar ones without results. Now I replaced the whole hardware (except harddisks) by another one - still the same crashes. So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ Cheers, jonas Regarding the hardware: the RAM was checked with memtest86+ and no errors found and the CPU has been replaced by a new one (same model). Still, the VM crash is reproducible. The hardware on the crashing system is: CPU: Intel Xeon E5-2609v2/4x2,5GHz Motherboard: Supermicro X9SRI-F For information, the hardware on non-crashing system is: CPU: Intel XEON L5639/6x2,13 GHz Motherboard: Supermicro X8STi It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated This is still valid, even though I no longer think that it's related to a RT process at all, as no sched_fifo/rr processes are started. Usually, a few minutes later, soft lockups start to happen, and then the system crashes: The backtrace is slightly different now due to kernel and Xen updates: [353013.384931] sched: RT throttling activated [354008.100835] BUG: soft lockup - CPU#5 stuck for 22s! [apache2:24848] [354008.100846] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100872] CPU 5 [354008.100874] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100894] [354008.100898] Pid: 24848, comm: apache2 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [354008.100904] RIP: e030:[8100122a] [8100122a] hypercall_page+0x22a/0x1000 [354008.100914] RSP: e02b:8802f0b41c00 EFLAGS: 0246 [354008.100918] RAX: 00040001 RBX: 88020200 RCX: 8100122a [354008.100922] RDX:
Bug#768172: internal error: unsupported dialog type 2
Hello Dan Jaocobson! On Thu, Nov 06, 2014 at 12:47:46AM +0800, 積丹尼 Dan Jacobson wrote: [...] File: /sbin/cfdisk X-debbugs-CC: Karel Zak k...@redhat.com (You probably want to make that util-linux at vger.kernel.org instead in the future if you want to involve upstream directly.) For size just type 1 instead of 1M, then hit RET upon seeing [ primary ] this will generate internal error: unsupported dialog type 2. Might be related to our use of slang instead of ncurses. (Which is because there's no udeb for libncursesw5 and util-linux is building an udeb for the installer. Hopefully we'll be able to switch to ncurses in Jessie+1.) Would be welcome if you could rebuild the util-linux package against libncursesw5-dev instead of slang and see if the bug remains... Regards, 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#765156: flashproxy is marked for autoremoval from testing
Hi, On Mittwoch, 5. November 2014, Ximin Luo wrote: 1. bumping the standards version now is often perceived as unwanted noise by those reviewing the changes to decide whether to let it enter jessie. leave it now, but next time please only include non-cosmetic changes _if_ you add non ron-RC fixes at all. OK. :-) 2. [...] The previous sleep time was 0.1s, and now it will sleep for a maximum of 1s (10 times the previous), so I think this should be OK. ok, cool, thanks. 3. there are lot of changes in debian/rules between 1.7-1 and 1.7-2 and there's no mentioning of those in debian/changelog at all. Is there a bug# for the problem they are fixing? I just noticed that I wasn't running some of the tests, that's all it is (and some variable renames for consistency). So I figured this is too trivial to put in debian/changelog, and there is no effect on the binary packages. please describe this in debian/changelog, re-upload to mentors and I'll happily upload to sid! basically any changes should be somehow mentioned in debian/changelog and at this time such changes certainly..! Thanks! cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#768174: parcimonie: Encoding error prevents it from starting
Package: parcimonie
Version: 0.8.3-1
Severity: important
In the usage instruction from the man page I should check the output of
parcimonie --verbose for misconfiguration or bugs.
The output I'm getting suggest that it's not working (I think):
$ parcimonie --verbose
Reference bless( do{\(my $o = '140085460212544')}, 'Encode::XS' ) did
not pass type constraint (not isa Encode::Encoding) (in
$self-{encoding}) at (eval 256) line 31
__ANON__ requires that the reference isa Encode::Encoding
The reference (in $self-{encoding}) isa Encode::XS
I get the same output when running parcimonie-applet or
parcimonie-applet --help.
The output of parcimonie --help and parcimonie --usage does look normal.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages parcimonie depends on:
ii libclone-perl0.37-1+b1
ii libconfig-general-perl 2.56-1
ii libfile-homedir-perl 1.00-1
ii libfile-which-perl 1.09-1
ii libglib-perl 3:1.305-2
ii libgnupg-interface-perl 0.50-3
ii libgtk3-perl 0.018-1
ii liblist-moreutils-perl 0.33-2+b1
ii liblocale-gettext-perl 1.05-8+b1
ii libmoo-perl 1.006001-1
ii libmoox-late-perl0.015-1
ii libmoox-options-perl 4.012-1
ii libnamespace-clean-perl 0.25-1
ii libnet-dbus-glib-perl0.33.0-1+b4
ii libnet-dbus-perl 1.0.0-2+b2
ii libpango-perl1.226-2
ii libpath-tiny-perl0.058-1
ii libtime-duration-parse-perl 0.11-1
ii libtry-tiny-perl 0.22-1
ii libtype-tiny-perl1.04-1
ii libtypes-path-tiny-perl 0.005-1
ii perl 5.20.1-2
ii perl-modules 5.20.1-2
ii torsocks 2.0.0-1
Versions of packages parcimonie recommends:
ii gnupg-curl 1.4.18-4
ii tor 0.2.5.10-1
parcimonie 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#768175: The file /dev/sde5 does not exist and no size was specified.
Package: e2fsprogs Version: 1.42.12-1 Severity: wishlist File: /sbin/mke2fs # fdisk -l /dev/sde Disk /dev/sde: 3.8 GiB, 4075290624 bytes, 7959552 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x Device Boot Start End Sectors Size Id Type /dev/sde1 2048 5834751 5832704 2.8G 83 Linux /dev/sde2 5834752 6858751 1024000 500M 83 Linux /dev/sde3 6858752 686079920481M 83 Linux /dev/sde4 6860800 7770111 909312 444M 5 Extended /dev/sde5 6862848 7770111 907264 443M 83 Linux # mke2fs -t ext4 /dev/sde5 mke2fs 1.42.12 (29-Aug-2014) The file /dev/sde5 does not exist and no size was specified. It does too. I just created it with cfdisk. dmesg|tail doesn't show anything odd. Anyway some better error message is needed. # ls -l /dev/sde? brw-rw 1 root disk 8, 65 11-06 01:02 /dev/sde1 brw-rw 1 root disk 8, 66 11-06 01:02 /dev/sde2 brw-rw 1 root disk 8, 67 11-06 01:02 /dev/sde3 So I don't know why cfdisk, which says syncing disks after quitting, doesn't notify the rest of Debian about the new partitions. Or maybe it is just my bad luck with USB in general. Better backup anything to hard disk as often unmounted superblocks get zapped (upon poweroff?), no matter what card reader... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768176: unblock: pioneers/15.3-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pioneers
Bug #765319 (non-free license for artwork) is RC in the current version in
pioneers. Upstream has contacted the artist and they relicensed it under
CC-BY-SA-4.0. Upstream has released a new version with this fix.
I asked on IRC if this could get a freeze exception, or if I should backport
the change. I was told a new upstream version is not a problem, as long as
there aren't other changes in it.
However, I didn't know it also includes whitespace and sorting changes to files
in debian/ and a buffer overflow fix (which is probably not a security issue,
but I didn't investigate), and while changing debian/copyright it was changed
to follow DEP-5. I'm guessing this is still not a problem? If it is, I can
either prepare 15.2-2, or downgrade the bug severity to wishlist (the problem
is solved; it is now a documentation issue that the license mentioned in the
package is not accurate).
The debdiff only shows version and sorting differences. I've attached a
cleaned diff of both upstream trees.
Thanks,
Bas
unblock pioneers/15.3-1
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: mipsel
armhf
Kernel: Linux 3.16-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -urp pioneers-15.2/ChangeLog pioneers-15.3/ChangeLog
--- pioneers-15.2/ChangeLog 2014-07-07 13:05:32.0 -0400
+++ pioneers-15.3/ChangeLog 2014-10-26 09:49:02.0 -0400
@@ -1,3 +1,19 @@
+2014-10-26 Roland Clobus rclo...@rclobus.nl
+ * editor/gtk/editor.c: Fixed a read beyond the array size.
+ * NEWS, client/ai/lobbybot.c: Prepare for the release of 15.2.
+
+2014-10-24 Roland Clobus rclo...@rclobus.nl
+ * docs/Relicense question about icons from the Gorilla theme.eml:
+ Email about the relicensing of derived work from the Gorilla theme.
+With many thanks to Jakub Steiner for allowing his work to be
+ relicensed.
+ * client/gtk/data/style-ai.svg, server/gtk/pioneers-server.svg,
+ editor/gtk/pioneers-editor.svg, client/gtk/data/pioneers.svg:
+ Relicensed as CC-BY-SA 4.0
+
+2014-07-07 Roland Clobus rclo...@rclobus.nl
+ * configure.ac: Work version is 15.3.
+
2014-07-07 Roland Clobus rclo...@rclobus.nl
* Released 15.2.
diff -urp pioneers-15.2/client/ai/lobbybot.c pioneers-15.3/client/ai/lobbybot.c
--- pioneers-15.2/client/ai/lobbybot.c 2014-07-07 13:04:31.0 -0400
+++ pioneers-15.3/client/ai/lobbybot.c 2014-10-26 09:49:02.0 -0400
@@ -129,7 +129,7 @@ static void lobbybot_chat_parser(gint pl
if (!strncmp(chat, /news, 5)) {
ai_chat(N_(The last released version of Pioneers is));
/* Update this string when releasing a new version */
- ai_chat(15.2);
+ ai_chat(15.3);
return;
}
}
diff -urp pioneers-15.2/client/gtk/data/pioneers.svg pioneers-15.3/client/gtk/data/pioneers.svg
--- pioneers-15.2/client/gtk/data/pioneers.svg 2013-05-20 14:48:28.0 -0400
+++ pioneers-15.3/client/gtk/data/pioneers.svg 2014-10-24 11:36:38.0 -0400
@@ -22,9 +22,9 @@
id=metadata3867rdf:RDFcc:Work
rdf:about=dc:formatimage/svg+xml/dc:formatdc:type
rdf:resource=http://purl.org/dc/dcmitype/StillImage; /cc:license
- rdf:resource=http://creativecommons.org/licenses/by-sa/3.0/; /dc:title /dc:creatorcc:Agentdc:titleRoland Clobus/dc:title/cc:Agent/dc:creatordc:descriptionIcon for Pioneers.
+ rdf:resource=http://creativecommons.org/licenses/by-sa/4.0/; /dc:title /dc:creatorcc:Agentdc:titleRoland Clobus/dc:title/cc:Agent/dc:creatordc:descriptionIcon for Pioneers.
The colours are similar to the colours in the Classic theme./dc:description/cc:Workcc:License
- rdf:about=http://creativecommons.org/licenses/by-sa/3.0/;cc:permits
+ rdf:about=http://creativecommons.org/licenses/by-sa/4.0/;cc:permits
rdf:resource=http://creativecommons.org/ns#Reproduction; /cc:permits
rdf:resource=http://creativecommons.org/ns#Distribution; /cc:requires
rdf:resource=http://creativecommons.org/ns#Notice; /cc:requires
@@ -170,4 +170,4 @@ The colours are similar to the colours i
style=font-size:6.86722279px;font-weight:normal;stroke-width:1;font-family:FreeSans
id=text633-1tspan
id=tspan634-59/tspan/text
-/g/svg
\ No newline at end of file
+/g/svg
diff -urp pioneers-15.2/client/gtk/data/style-ai.svg pioneers-15.3/client/gtk/data/style-ai.svg
--- pioneers-15.2/client/gtk/data/style-ai.svg 2013-06-07 07:03:48.0 -0400
+++ pioneers-15.3/client/gtk/data/style-ai.svg 2014-10-24 11:36:38.0 -0400
@@ -19,40 +19,17 @@
height=48.00px
width=48.00px
version=1.1metadata
- id=metadata22510
- rdf:RDF
-cc:Work
- rdf:about=
- dc:formatimage/svg+xml/dc:format
- dc:type
-
Bug#764195: gcc-4.9: problems with precompiled headers on arm64
please recheck with 4.9.2 and trunk (gcc-snapshot). In the past I had mixed results with precompiled headers on AArch64. I was able to reproduce the problem with aegisub and with qtbase-opensource-src. Replacing 4.9.1-16 with 4.9.2-1 or 20141017-1 made no difference. It seems strange to me that a problem with precompiled headers is architecture-specific. Is that a clue that might make it possible to guess where the problem is? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766250: eject: [kfreebsd] fails to open cdrom tray
Hi, On Tue, 4 Nov 2014 14:47:34 + Steven Chamberlain ste...@pyro.eu.org wrote: There seems to be no problem with this on a jessie system. I'm still leaving this 'gift' bug if someone would like practice at simple debugging on kfreebsd. Well, I don't think all is OK now. Indeed, with yesterday's daily build, I too was able to eject the CD. But I still could not access thr drive in xfburn. Having a closer look at /dev/cd0, I discovered that it is a character device belonging to root:tty ! This was er.. slightly unexpected. I don't remember if it was a character device before, but I do remember its group was 'cdrom', as I would expect. Changing ownership back to cdrom in the hope to be able to burn CDs as a normal user again did not help, but additionally prevented ejection like before. Some days earlier, when ejecting still failed out of the box, I used ktrace/kdump on both 'eject /dev/cdrom' and 'camcontrol eject cd0'. In eject, /dev/cd0 is opened, and the ioctl returns an error. In camcontrol (which indeed ejects the CD), cd0 is mentioned nowhere, so without the source or actual debugging, I don't see how to get a clue about how and why it succeeds. Unfortunately, kdump-tools is currently uninstallable. Regards, Herbert -- Herbert Kaminski D-26122 Oldenburg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768172: internal error: unsupported dialog type 2
AH == Andreas Henriksson andr...@fatal.se writes: File: /sbin/cfdisk X-debbugs-CC: Karel Zak k...@redhat.com AH (You probably want to make that util-linux at vger.kernel.org instead AH in the future if you want to involve upstream directly.) (Non power user me does not belong on that list.) AH Would be welcome if you could rebuild the util-linux package against AH libncursesw5-dev instead of slang and see if the bug remains... Ho ho ho, just reporting an internal error I saw. I haven't touched a compiler in years. Anyway glad I found the error for you. By the way https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768175 may be a more juicy bug you could help with. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768177: unblock: gtk+3.0/3.14.4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock A gtk+3.0 version just uploaded to unstable has fixes for two important bugs: * Added missing schema file without which the built-in debugging mechanism was not working. * Fixed calculation of menu size for menus on top of the screen, which makes gnome-panel menus usable again (#767906). Pre-approved by Emilio Pozuelo Monfort on IRC. Thanks in advance, -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#766962: quassel: diff for NMU version 0.10.0-2.1
Control: reopen -1 Control: found -1 0.11.0-1 Version 0.11.0 does *not* contain the commit that fixes this bug. 0.11.0-1 is also wrongly marked as fixed in the security tracker. I guess now 0.10.0-2.1 has to be re-uploaded with a different version to testing-proposed-updates. Cheers, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#472477: RE: #472477 - ssh-add -D does not remove SSH key from gnome-keyring-daemon memory
On Fri, 19 Sep 2014 20:35:41 +0100 Pedro Beja altha...@gmail.com wrote: this is an old bug. Could you please still reproduce this issue with newer gnome-keyring version like 3.4.1-5 or 3.12.2-1 ? Still happening with gnome-keyring 3.14.0-1+b1 and openssh-client 1:6.7p1-2 on jessie. $ echo $SSH_AUTH_SOCK /run/user/1000/keyring/ssh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768156: general: dpkg frontend inconsistent
On Wed, Nov 5, 2014 at 17:53:50 +0100, Holger Levsen wrote: Hi Michal, On Mittwoch, 5. November 2014, Michal Suchanek wrote: I was upgrading my system and several times I was asked for installing a new configuration file. Sometimes the question is posed in teletype style frontend sometimes in colour character terminal TUI style frontend. which tool did you use (how) to upgrade? Pretty sure this is ucf vs dpkg's conffile prompt. Cheers, Julien signature.asc Description: Digital signature
Bug#768179: python3-markups: Does not load Markdown extensions with options
Package: python3-markups Version: 0.5.1-1 Severity: important Tags: upstream fixed-upstream The ReText documentation [1] mentions that parameters for Markdown extensions can be specified in brackets in markdown-extensions.txt file. That was working fine with first versions of Markups, but later one of upstream commits (namely [2]) broke it. The fix is trivial [3], released upstream as 0.5.2 and covered by test suite. [1] https://sourceforge.net/p/retext/wiki/Configuration%20file/#loading-markdown-extensions [2] https://github.com/mitya57/pymarkups/commit/9d81874857 [3] https://github.com/mitya57/pymarkups/commit/c72b6e486c -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#768178: systemd: sysvinit wrapper breaks newly-installed services
Package: systemd Version: 215-5+b1 Severity: important Hi, systemd is breaking unrelated software and preventing it from starting normally: (Results below are the same if you call /etc/init.d/fp-facilitator directly, instead of service fp-facilitator) $ sudo aptitude install flashproxy-facilitator [..] Setting up flashproxy-facilitator (1.7-1) ... # configure the settings so things can work $ sudo sed -i -e 's/RUN_DAEMON=no/RUN_DAEMON=yes/g' /etc/default/fp-facilitator $ sudo sed -i -e 's/^#\(.*\)websocket\(.*\)/\1websocket\2/g' /etc/flashproxy/facilitator-relays # now try starting the service $ sudo service fp-facilitator start $ sudo service fp-facilitator status ● fp-facilitator.service - LSB: Flash proxy facilitator [..] Active: active (exited) since Wed 2014-11-05 17:56:58 GMT; 34s ago [..] Nov 05 17:56:58 pdeb2 fp-facilitator[19028]: Not starting Flash proxy facilitator (Disabled in /etc/default/fp-facilitator).. $ head -n2 /etc/default/fp-facilitator # Change to yes to run the service. RUN_DAEMON=yes # Why isn't this working? Things worked perfectly fine with sysvinit. $ sudo service fp-facilitator stop $ sudo service fp-facilitator start $ sudo service fp-facilitator status ● fp-facilitator.service - LSB: Flash proxy facilitator [..] Active: active (running) since Wed 2014-11-05 17:57:46 GMT; 1s ago [..] # Now it works? But I didn't change anything! This is very weird behaviour. I get that sometimes it's the script's fault, but in /etc/init.d/fp-facilitator I source DEFAULTSFILE almost immediately, so RUN_DAEMON should be checked. Perhaps the systemctl redirector stuff is clobbering these variables? X -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.4 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.25.1-5 ii libc6 2.19-12 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-2 ii libgcrypt20 1.6.2-4 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-5+b1 ii sysv-rc 2.88dsf-53.4 ii udev215-5+b1 ii util-linux 2.25.1-5 Versions of packages systemd recommends: ii dbus1.8.8-2 ii libpam-systemd 215-5+b1 Versions of packages systemd suggests: ii systemd-ui 3-2 -- 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#767915: your mail
On 2014-11-05 Torrance, Douglas dtorra...@monmouthcollege.edu wrote: tags 449774 pending Hello Douglas, I have just seen that you ITA wmbiff. Great! Could you please let 0.4.27-2.3 propagate to testing before you make a cleanup upload? 759259 should be fixed in jessie ASAP. Thanks, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' signature.asc Description: Digital signature
Bug#767351: c++ missing symbols
On Wed, Nov 5, 2014 at 2:18 PM, Matthias Klose d...@debian.org wrote: Control: reassign -1 src:imagemagick Am 30.10.2014 um 13:17 schrieb Bastien ROUCARIES: package: libstdc++6 version: 4.9.1-19 severity: important control: forwarded -1 https://gcc.gnu.org/ml/gcc/2014-07/msg00030.html control: affects -1 src:imagemagick Acording to https://buildd.debian.org/status/fetch.php?pkg=imagemagickarch=armelver=8%3A6.8.9.9-2stamp=1414597993 __aeabi_atexit@CXXABI_ARM_1.3.3 is missing No. This is an architecture limitation with armv4, armv5 and armv6. imagemagick shouldn't require these features on such architectures. Care to explain then how to fix ? Imagemagick does not play tricks with compile flags and use only standard library. How are they generated ? Where could we find information about the missing feature ? Thanks Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768164: [Pkg-haskell-maintainers] Bug#768164: haskell-tls: SSLv3 support
Dear Moritz, Am Mittwoch, den 05.11.2014, 17:12 +0100 schrieb Moritz Muehlenhoff: On Wed, Nov 05, 2014 at 05:07:15PM +0100, Joachim Breitner wrote: Am Mittwoch, den 05.11.2014, 16:45 +0100 schrieb Moritz Muehlenhoff: Package: haskell-tls Severity: important Tags: security Hi, openssl disabled SSLv3 for jessie since 1.0.1j-1. Shall we do the same for haskell-tls? good question. Probably yes. Did openssl disable SSLv3 completely, or did it just removed it from the default list of accepted settings? openssl disabled it entirely; it features a dedicated build flag for it (no-ssl3). Ok, I think we can easily follow suit here. Removing code is always simple :-) Could you approach haskell-tls upstream for their recommendation to disable it? Vincent, did you consider this issue already? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#766064: /etc/init.d/uuidd says Stopping uuidd generator
Control: forwarded -1 http://www.spinics.net/lists/util-linux-ng/msg10472.html Patch submitted on upstream mailing list. Regards, 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#765156: flashproxy is marked for autoremoval from testing
On 05/11/14 17:01, Holger Levsen wrote: please describe this in debian/changelog, re-upload to mentors and I'll happily upload to sid! basically any changes should be somehow mentioned in debian/changelog and at this time such changes certainly..! Thanks! Done! https://mentors.debian.net/package/flashproxy X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Bug#768173: Correction
Correction: I intend to maintain it as part of the Debian Multimedia Maintainers team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744040: Package of libbdplus
Dear Debian Multimedia maintainers, I finished a package of libbdplus [1] using git-buildpackage. libbdplus is a research project to implement the BD+ System Specifications under LGPL 2.1. Now, I am looking for a mentor for reviewing it. Someone is interested in this package? Best regards, Dylan [1] http://mentors.debian.net/package/libbdplus https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744040
Bug#768169: Correction
Correction: I intend to maintain it as part of the Debian Multimedia Maintainers team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746564: minidlna doesn't work - upnpsoap sql error
Hi,
I'm sorry for the late reply.
I always used vlc from debian-archive (apt-pinning prevents dmo from
installing packages existing in debian).
I tried vlc 2.0.7 from the debian archive but it also doesn't work in
most cases and in the rarely cases it works, it takes a long time until
showing the files.
I also tried mediatomb instead of minidlna: same issue. It seems like
there is no video player in debian that can access upnp servers well.
Also the current vlc from testing doesn't work.
Best regards,
martin
Vlc packages:
apt-cache policy (dpkg -l | awk '/^ii/ /vlc/ {print $2}')
libvlc5:
Installiert: 2.2.0~pre4-2
Installationskandidat: 2.2.0~pre4-2
Versionstabelle:
1:2.2.0~pre4-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 2.2.0~pre4-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
libvlccore8:
Installiert: 2.2.0~pre4-2
Installationskandidat: 2.2.0~pre4-2
Versionstabelle:
1:2.2.0~pre4-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 2.2.0~pre4-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
phonon-backend-vlc:
Installiert: 0.8.0-2
Installationskandidat: 0.8.0-2
Versionstabelle:
1:0.8.0-dmo3 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 0.8.0-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
vlc:
Installiert: 2.2.0~pre4-2
Installationskandidat: 2.2.0~pre4-2
Versionstabelle:
1:2.2.0~pre4-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 2.2.0~pre4-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
vlc-data:
Installiert: 2.2.0~pre4-2
Installationskandidat: 2.2.0~pre4-2
Versionstabelle:
1:2.2.0~pre4-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 2.2.0~pre4-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
vlc-nox:
Installiert: 2.2.0~pre4-2
Installationskandidat: 2.2.0~pre4-2
Versionstabelle:
1:2.2.0~pre4-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 2.2.0~pre4-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
vlc-plugin-pulse:
Installiert: 2.2.0~pre4-2
Installationskandidat: 2.2.0~pre4-2
Versionstabelle:
1:2.2.0~pre4-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 2.2.0~pre4-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
vlc-plugin-samba:
Installiert: 2.2.0~pre4-2
Installationskandidat: 2.2.0~pre4-2
Versionstabelle:
1:2.2.0~pre4-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
*** 2.2.0~pre4-2 0
900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746564: (no subject)
I forgot to mention the packages installed from dmo:
apt-cache policy (dpkg -l | awk '/^ii/ /-dmo/ {print $2}')
deb-multimedia-keyring:
Installiert: 2012.05.10-dmo4
Installationskandidat: 2012.05.10-dmo4
Versionstabelle:
*** 2012.05.10-dmo4 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
100 /var/lib/dpkg/status
gstreamer0.10-ffmpeg:
Installiert: 1:0.10.13-dmo1
Installationskandidat: 1:0.10.13-dmo1
Versionstabelle:
*** 1:0.10.13-dmo1 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
100 /var/lib/dpkg/status
0.10.13-5 0
600 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
libdvdcss2:
Installiert: 1.3.0-dmo1
Installationskandidat: 1.3.0-dmo1
Versionstabelle:
*** 1.3.0-dmo1 0
500 http://www.deb-multimedia.org/ testing/main amd64 Packages
100 /var/lib/dpkg/status
Removing these packages didn't change anything.
Best regards,
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)
I vote Y, FD on the following. Ian Jackson ijack...@chiark.greenend.org.uk writes: Rationale (Constitution 6.1(5)): 1. Currently libpam-systemd (which is pulled in by quite a few dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'. 2. The effect of this is that installing some packages which depend (directly or indirectly) on libpam-systemd can cause a user's init system to be switched to systemd, even on systems where a user has deliberately chosen not to use the default init system, and even when the switch is unnecessary. 3. Swappping the order of these dependencies would avoid that and has no harmful effect: 4. In particular, on systems that already have systemd-sysv installed, libpam-systemd will still not pull in systemd-shim, thus minimizing the risk of breakage on systemd systems. However, on systems that intentionally do not have systemd-sysv installed, the installation of libpam-systemd will then prefer to pull in systemd-shim and keep the installed init system rather than switching to systemd-sysv. Decision (Constitution 6.1(4)): 5. We therefore overrule the decision of the maintainer of libpam-systemd binary package. The Depends entry systemd-sysv | systemd-shim (= 8-2) should be replaced by systemd-shim (= 8-2) | systemd-sysv 6. For the avoidance of doubt, we do not intend to set this specific syntax in stone. For example, if in future libpam-systemd needs to depend on a later systemd-shim, or needs a versioned rather than unversioned dependency on systemd-sysv, that is fine and would not contradict our decision. Release (Constitution 6.1(5)): 7. Our advice is that this change should be in jessie. If necessary, this view should be conveyed to the Release Team, after the change is in unstable, by filing an unblock request in the usual way. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ pgpyyeOVVn4lg.pgp Description: PGP signature
Bug#768180: meld: doesn't react to SIGINT anymore
Package: meld Version: 3.12.1-1 Severity: important Hi. Apparently meld doesn't react to siging anymore. $ meld * ^C^C ^C^C^C^CTraceback (most recent call last): File /usr/lib/python2.7/dist-packages/meld/diffgrid.py, line 84, in do_motion_notify_event def do_motion_notify_event(self, event): KeyboardInterrupt ^C Marking this a important since many 3rd party programs depend on this standard behaviour. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages meld depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii gir1.2-gtksource-3.0 3.14.1-1 ii libcanberra-gtk3-module 0.30-2.1 ii libgtk-3-0 3.14.4-1 ii libgtksourceview-3.0-1 3.14.1-1 ii patch2.7.1-6 ii python 2.7.8-2 ii python-gi3.14.0-1 ii python-gi-cairo 3.14.0-1 pn python:any none Versions of packages meld recommends: ii yelp 3.14.1-1 meld 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#768178: systemd: sysvinit wrapper breaks newly-installed services
Am 05.11.2014 um 19:05 schrieb Ximin Luo: Package: systemd Version: 215-5+b1 Severity: important Hi, systemd is breaking unrelated software and preventing it from starting normally: Well, the title of this bug report is misleading and wrong. I'll try to explain what you're encountering. (Results below are the same if you call /etc/init.d/fp-facilitator directly, instead of service fp-facilitator) $ sudo aptitude install flashproxy-facilitator [..] Setting up flashproxy-facilitator (1.7-1) ... Since flashproxy-facilitator uses invoke-rc.d flashproxy-facilitator start in postinst, the state of the service is active (exited) at this point. The default for sysv init scripts is RemainAfterExit=true [0], so even if there are no running processes, the service is marked as active. This is because systemd doesn't know, if the sysv init script is supposed to start a long running process or a just some one shot commands. # configure the settings so things can work $ sudo sed -i -e 's/RUN_DAEMON=no/RUN_DAEMON=yes/g' /etc/default/fp-facilitator $ sudo sed -i -e 's/^#\(.*\)websocket\(.*\)/\1websocket\2/g' /etc/flashproxy/facilitator-relays # now try starting the service $ sudo service fp-facilitator start If the service is already considered active, a start will be no-op. You'll need service fp-facilitator restart here (or stop + start, which is the equivalent). $ sudo service fp-facilitator status ● fp-facilitator.service - LSB: Flash proxy facilitator [..] Active: active (exited) since Wed 2014-11-05 17:56:58 GMT; 34s ago [..] Nov 05 17:56:58 pdeb2 fp-facilitator[19028]: Not starting Flash proxy facilitator (Disabled in /etc/default/fp-facilitator).. $ head -n2 /etc/default/fp-facilitator # Change to yes to run the service. RUN_DAEMON=yes # Why isn't this working? Things worked perfectly fine with sysvinit. $ sudo service fp-facilitator stop $ sudo service fp-facilitator start $ sudo service fp-facilitator status ● fp-facilitator.service - LSB: Flash proxy facilitator [..] Active: active (running) since Wed 2014-11-05 17:57:46 GMT; 1s ago [..] # Now it works? But I didn't change anything! You did something different. You used service fp-facilitator stop before starting the service. This will explicitly mark the service as inactive (dead). This is very weird behaviour. I get that sometimes it's the script's fault, but in /etc/init.d/fp-facilitator I source DEFAULTSFILE almost immediately, so RUN_DAEMON should be checked. Perhaps the systemctl redirector stuff is clobbering these variables? systemd doesn't clobber any variables. The problem here is, that the service is considered active, even though it isn't really, since it has been neutered via the ENABLE flag. Therefore, such ENABLE or RUN_DAEMON flags in /etc/default/ should be avoided. A few recommendations - Avoid such ENABLE flags in /etc/default/service - Ship a native .service file to explicitly tell systemd about the type of service [1] so it can track it more reliably. - Iif you want to stick with sysv init scripts but tell systemd that the sysv init script runs a long running process, add a # pidfile: /var/run/foo.pid pseudo header. Does that clarify things? Michael [0] http://www.freedesktop.org/software/systemd/man/systemd.service.html#RemainAfterExit= [1] http://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#767915: your mail
On 11/05/2014 12:08 PM, Andreas Metzler wrote: Hello Douglas, I have just seen that you ITA wmbiff. Great! Could you please let 0.4.27-2.3 propagate to testing before you make a cleanup upload? 759259 should be fixed in jessie ASAP. Will do. Thanks for the heads up! Doug -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768020: [Pkg-shadow-devel] Bug#768020: Missing /dev/ttySC* entries in /etc/securetty
On 05 Nov 2014 17:35, Geert Uytterhoeven wrote: On Wed, Nov 5, 2014 at 4:49 PM, Mike Frysinger wrote: perhaps the default should be to not have an /etc/securetty at all ? if the system is configured to launch getty on a tty, then in today's world, it means it's a local device right ? if you have physical access to something, and know It may still be connected to a modem, waiting for incoming calls... how many of these systems legitimately exist anymore ? we shouldn't be handicapping the majority of users for an extreme edge case. if those people want to set up securetty, they can create the file themselves. the root password, what exactly is this protecting the system from ? /etc/securetty is not meant to prevent privileged people from getting in, but to protect the system against eavesdropping on unsecure lines (.e.g. out-of-the-building serial cables and modem lines). how does securetty prevent that ? you can log in as non-root and then sudo. or try and leverage a known security vuln to escalate that non-root account. any perceived security provided by securetty is an illusion. Ah, sudo is a recent invention ;-) `su` isn't though, and i don't think `su` enforces securetty ? it's only at `login` time ? But you're right, /etc/securetty has little value these days. i guess this is something we need to encourage each distro to do as i don't think the upstream shadow package already ships this behavior by default. i'll update Gentoo after i double check the behavior and see if anyone notices :). -mike signature.asc Description: Digital signature
Bug#768181: totem crashes while browsing upnp share
Package: totem Version: 3.14.0-2 Severity: normal Dear Maintainer, everytime I try to browse my upnp share totem crashes. Please find a backtrace attached to this bugreport. Best regards, Martin -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-c720 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages totem depends on: ii gnome-icon-theme3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii grilo-plugins-0.2 0.2.13-1+b1 ii gsettings-desktop-schemas 3.14.1-1 ii gstreamer1.0-clutter2.0.12-1 ii gstreamer1.0-plugins-bad1.4.3-2+b1 ii gstreamer1.0-plugins-base 1.4.3-1.1 ii gstreamer1.0-plugins-good 1.4.3-2 ii gstreamer1.0-x 1.4.3-1.1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-12 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libclutter-1.0-01.20.0-1 ii libclutter-gst-2.0-02.0.12-1 ii libclutter-gtk-1.0-01.6.0-1 ii libcogl-pango20 1.18.2-2 ii libcogl-path20 1.18.2-2 ii libcogl20 1.18.2-2 ii libdrm2 2.4.58-2 ii libegl1-mesa [libegl1-x11] 10.3.1-1 ii libgbm1 10.3.1-1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgirepository-1.0-1 1.42.0-2.2 ii libglib2.0-02.42.0-2 ii libgnome-desktop-3-10 3.14.1-1 ii libgrilo-0.2-1 0.2.11-2 ii libgstreamer-plugins-base1.0-0 1.4.3-1.1 ii libgstreamer1.0-0 1.4.3-1.2 ii libgtk-3-0 3.14.4-1 ii libjson-glib-1.0-0 1.0.2-1 ii libnautilus-extension1a 3.14.0-1 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpeas-1.0-0 1.12.1-1 ii libtotem-plparser18 3.10.3-1 ii libtotem0 3.14.0-2 ii libwayland-client0 1.6.0-2 ii libwayland-cursor0 1.6.0-2 ii libwayland-egl1-mesa [libwayland-egl1] 10.3.1-1 ii libwayland-server0 1.6.0-2 ii libx11-62:1.6.2-3 ii libxcomposite1 1:0.4.4-1 ii libxdamage1 1:1.1.4-2 ii libxext62:1.3.3-1 ii libxfixes3 1:5.0.1-2 ii libxi6 2:1.7.4-1 ii libxkbcommon0 0.4.3-2 ii libxml2 2.9.1+dfsg1-4 ii libxrandr2 2:1.4.2-1 pn python:any none ii totem-common3.14.0-2 Versions of packages totem recommends: ii gstreamer1.0-libav 1.4.3-1 ii gstreamer1.0-plugins-ugly 1.4.3-1 ii gstreamer1.0-pulseaudio1.4.3-2 ii totem-plugins 3.14.0-2 Versions of packages totem suggests: ii gnome-codec-install 0.4.7+nmu2 -- debconf-show failed GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from totem...Reading symbols from /usr/lib/debug//usr/bin/totem...done. done. (gdb) run Starting program: /usr/bin/totem [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fffe54ec700 (LWP 30474)] [New Thread 0x7fffe4ceb700 (LWP 30475)] [New Thread 0x7fffd6ef4700 (LWP 30476)] [New Thread 0x7fffd66f3700 (LWP 30477)] [New Thread 0x7fffd5ef2700 (LWP 30478)] [New Thread 0x7fffd56f1700 (LWP 30479)] [New Thread 0x7fffd4ef0700 (LWP 30480)] [New Thread 0x7fffc700 (LWP 30481)] [New Thread 0x7fffcefe6700 (LWP 30482)]
Bug#768182: unblock: pymarkups/0.5.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, I would like to get pymarkups/0.5.2-1 promoted into testing. I got a bug report about it today (on upstream support forum), and published a new upstream release containing only that fix. The bug report also got copied to Debian as #768179. The debdiff is attached. There are no packaging changes. Thanks in advance, -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#763606: Confirmation
Dear maintainers, I have the same exact problem. I have a bridge over an ethernet NIC and an OpenVPN tap interface. Kernel 3.14-2-powerpc works correctly and 3.16-[23]—powerpc do not. The remote openvpn host can reach the bridge interface correctly and thus communicate with the host. However any other access of the remote host that should be forwarded from the openvpn tap interface through the ethernet interface does not work. I have used netsniff-ng over the remote tap interface, the local tap interface, the local bridge interface, and the local ethernet interface while making a DHCP request from the remote host that should be forwarded to the local network. In all cases the request packet was visible, but not the response. Find below some of the hardware details of my system just in case it helps. - /proc/cpuinfo - processor : 0 cpu : 7447A, altivec supported clock : 1333.28MHz revision : 1.5 (pvr 8003 0105) bogomips : 83.20 timebase : 41600661 platform : PowerMac model : PowerMac10,2 machine : PowerMac10,2 motherboard : PowerMac10,2 MacRISC3 Power Macintosh detected as : 287 (Mac mini (Late 2005)) pmac flags: 0010 L2 cache : 512K unified pmac-generation : NewWorld Memory: 1024 MB - /proc/cpuinfo end - 08: PCI 2200b.0: 0600 Host bridge [Created at pci.328] Unique ID: 7rcY.vkm17Jxs1m3 SysFS ID: /devices/pci0002:20/0002:20:0b.0 SysFS BusID: 0002:20:0b.0 Hardware Class: bridge Model: Apple UniNorth 2 Internal PCI Vendor: pci 0x106b Apple Inc. Device: pci 0x0036 UniNorth 2 Internal PCI Module Alias: pci:v106Bd0036svsdbc06sc00i00 Config Status: cfg=new, avail=yes, need=no, active=unknown 11: PCI 2200f.0: 0200 Ethernet controller [Created at pci.328] Unique ID: rBUF.nAQ7Jnazou0 SysFS ID: /devices/pci0002:20/0002:20:0f.0 SysFS BusID: 0002:20:0f.0 Hardware Class: network Model: Apple UniNorth 2 GMAC (Sun GEM) Vendor: pci 0x106b Apple Inc. Device: pci 0x0032 UniNorth 2 GMAC (Sun GEM) Revision: 0x80 Driver: gem Driver Modules: sungem Device File: eth0 Memory Range: 0xf520-0xf53f (rw,non-prefetchable) Memory Range: 0xf510-0xf51f (ro,non-prefetchable,disabled) IRQ: 41 (7184 events) HW Address: 00:11:24:*:*:* Link detected: yes Module Alias: pci:v106Bd0032svsdbc02sc00i00 Driver Info #0: Driver Status: sungem is active Driver Activation Cmd: modprobe sungem Config Status: cfg=new, avail=yes, need=no, active=unknown 12: PCI 11017.0: ff00 Unclassified device [Created at pci.328] Unique ID: tO0B.wjNr0SYqtL5 SysFS ID: /devices/pci0001:10/0001:10:17.0 SysFS BusID: 0001:10:17.0 Hardware Class: unknown Model: Apple KeyLargo/Intrepid Mac I/O Vendor: pci 0x106b Apple Inc. Device: pci 0x003e KeyLargo/Intrepid Mac I/O Driver: macio Memory Range: 0x8000-0x8007 (rw,non-prefetchable) Module Alias: pci:v106Bd003EsvsdbcFFsc00i00 Config Status: cfg=new, avail=yes, need=no, active=unknown 15: PCI 1100b.0: 0600 Host bridge [Created at pci.328] Unique ID: zM3W.OKqHekp9WN3 SysFS ID: /devices/pci0001:10/0001:10:0b.0 SysFS BusID: 0001:10:0b.0 Hardware Class: bridge Model: Apple UniNorth 2 PCI Vendor: pci 0x106b Apple Inc. Device: pci 0x0035 UniNorth 2 PCI Module Alias: pci:v106Bd0035svsdbc06sc00i00 Config Status: cfg=new, avail=yes, need=no, active=unknown Cheers, Josep M. Perez -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748728: nmu for libuser
* Michael Gilbert mgilb...@debian.org, 2014-11-01, 20:55: override_dh_auto_install: dh_auto_install rm -f $(CURDIR)/debian/tmp/pyshared/libusermodule.la + mkdir $(CURDIR)/debian/tmp/usr/share/man/man8 + for n in $$(ls debian/tmp/usr/sbin); do \ + mv $(CURDIR)/debian/tmp/usr/share/man/man1/$$n.1 \ + $(CURDIR)/debian/tmp/usr/share/man/man8/$$n.8; \ + sed -i s/^\.TH $$n 1 /.TH $$n 8 / \ + $(CURDIR)/debian/tmp/usr/share/man/man8/$$n.8; \ + done This for loop lacks set -e; please see Policy §4.6. -- 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#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)
On Wed, 05 Nov 2014, Ian Jackson wrote: I am calling for votes on the text below: Y (override, swap dependencies, requires 3:1) FD I vote Y FD. -- Don Armstrong http://www.donarmstrong.com Whatever you do will be insignificant, but it is very important that you do it. -- Mohandas Karamchand Gandhi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716644: github-cli does not support github API V3
Severity: grave Control: retitle -1 github-cli: Does not work with github anymore Time to raise severity -- the program is no longer usable as it used a no-more available API. It is (IMHO) a removal candidate. See https://github.com/jsmits/github-cli/blob/master/README.rst -- tobi signature.asc Description: This is a digitally signed message part
Bug#768178: systemd: sysvinit wrapper breaks newly-installed services
On 05/11/14 18:31, Michael Biebl wrote: Since flashproxy-facilitator uses invoke-rc.d flashproxy-facilitator start in postinst, the state of the service is active (exited) at this point. The default for sysv init scripts is RemainAfterExit=true [0], so even if there are no running processes, the service is marked as active. This is because systemd doesn't know, if the sysv init script is supposed to start a long running process or a just some one shot commands. [..] If the service is already considered active, a start will be no-op. I think this is the bug on systemd's part. I get that start is a no-op might make sense for actual systemd services, but how does it make sense for the sysvinit wrapper? In a plain sysvinit setup (that does not have systemd interfering with things) start is run unconditionally if I say service x start. What is the problem with doing things this way? systemd doesn't clobber any variables. The problem here is, that the service is considered active, even though it isn't really, since it has been neutered via the ENABLE flag. Therefore, such ENABLE or RUN_DAEMON flags in /etc/default/ should be avoided. Er, I wrote a sysvinit script, not a systemd script. As far as I know, there is no sysvinit standard that forbids ENABLE or RUN_DAEMON, even if it is discouraged. If systemd wants to kludge wrappers for sysvinit, it's the *responsibility of systemd* to not break existing software. A few recommendations - Avoid such ENABLE flags in /etc/default/service - Ship a native .service file to explicitly tell systemd about the type of service [1] so it can track it more reliably. - Iif you want to stick with sysv init scripts but tell systemd that the sysv init script runs a long running process, add a # pidfile: /var/run/foo.pid pseudo header. I can do these things, and thanks for the explanation - but this issue is still systemd's fault, that should be fixed ultimately on the systemd side. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Bug#768156: general: dpkg frontend inconsistent
Hi Holger, On 5 Nov 2014 16:53, Holger Levsen hol...@layer-acht.org wrote: which tool did you use (how) to upgrade? I also experienced this when upgrading a system from squeeze to wheezy a few days ago. I followed the upgrade instructions in wheezy's release notes, i.e. using apt-get. I'll have a look through the logs to see if I can spot a pattern. Thanks -- Matt Wheeler http://funkyh.at
Bug#768121: laptop-mode-tools: Ethernet module should check for carrier before changing link speed
Sorry for the confusion, I'll try to clarify. On Wed, 5 Nov 2014, Ritesh Raj Sarraf wrote: On 11/05/2014 11:02 AM, Matthew Gabeler-Lee wrote: On at least my system (r8169 driver), any time ethtool is called to set the advertised link speed, it causes a momentary loss of carrier. This causes l-m-t to incorrectly think the link was not in use, and shut it off. What do you mean by shut it off ? I believe the ethernet is disabled, while on battery, only if the corresponding setting is enabled in the config file. By shut it off, I mean running ip link set dev eth0 down to disable the interface -- /usr/share/laptop-mode-tools/modules/ethernet line 131. On a related note, the invocation of ethtool doesn't work at all on at least that chipset. Apparently it is necessary to include the duplex setting as well. Not including the duplex setting causes ethtool to emit Cannot advertise speed X ... but still causes the momentary carrier loss. I don't know if this requirement/limitation is specific to the r8169 driver. Including the duplex setting allows it to actually restrict the link speed. I'm not sure what you mean here. Works for me.. I think my hardware may have some limitations around the speed changing that yours does not have. The only catch you'll notice is that while on AC, my wired ethernet is 10Mb/s where as on BATT, it is 1000Mb/s. This seems bass ackwards? Wouldn't you want the on battery state to be the low speed to save power? That's not really relevant to my problem though. Running ethtools -s eth0 speed 10 (or any other value for the speed) fails to set the speed limit on my system. In order to set the speed limit on my system, you must also specify the duplex setting -- ethtool -s eth0 speed 10 duplex full works properly, as does ... duplex half. # when no carrier is detected on the interface (e.g., no active cable is # plugged in). This is the other / more important aspect that is not working properly for me. Because of the call to ethtool to set the speed, it always sees NO-CARRIER when it checks this. This temporary NO-CARRIER state happens even if the ethtool call gives the error described above, or if it succeeds, and even if the speed set is the same as the current speed. Switching the order of the Handle throttling and Shut down interface sections in the ethernet module script would be sufficient to fix the issue, at least as far as it can be fixed within the limitations of my hardware. I don't think there's any way to fix the link loss every time the speed is set from l-m-t without breaking other systems. I think that would need to be fixed in the driver, if possible ... it may be a limitation of the hardware. -- -Matt Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick GPG pubkey fingerprint: A57F B354 FD30 A502 795B 9637 3EF1 3F22 A85E 2AD1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768183: psocksxx: FTBFS: '.../libpsocksxx-doc/docs/' is not a directory
Source: psocksxx Version: 0.0.6-1 Severity: serious Justification: fails to build from source Builds of psocksxx covering only its architecture-dependent binary packages (as on the autobuilders, or with dpkg-buildpackage -B) have been failing: cp -r /«PKGBUILDDIR»/doc/doxygen/html/* /«PKGBUILDDIR»/debian/libpsocksxx-doc/usr/share/doc/libpsocksxx-doc/docs/ cp: target '/«PKGBUILDDIR»/debian/libpsocksxx-doc/usr/share/doc/libpsocksxx-doc/docs/' is not a directory make[1]: *** [override_dh_installdocs] Error 1 debian/rules:26: recipe for target 'override_dh_installdocs' failed make[1]: Leaving directory '/«PKGBUILDDIR»' make: *** [binary-arch] Error 2 debian/rules:19: recipe for target 'binary-arch' failed Could you please take a look, and arrange to run this command only when actually building the -doc package? For that matter, it would be good to move doxygen to Build-Depends-Indep and likewise run it only when building the -doc package. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766962: quassel: diff for NMU version 0.10.0-2.1
Hi Felix,
On Wed, Nov 05, 2014 at 06:45:09PM +0100, Felix Geyer wrote:
Control: reopen -1
Control: found -1 0.11.0-1
Version 0.11.0 does *not* contain the commit that fixes this bug.
Thanks for checking also this version!
0.11.0-1 is also wrongly marked as fixed in the security tracker.
Yes and no about the security-tracker. The CVE/bug was fixed in
0.10.0-2.1 which was superseeded by 0.11.0-1 in unstable before
reaching testing. The security-tracker cannot notice that it was fixed
in 0.10.0-2.1 but would not be fixed in 0.11.0-1 (as 0.10.0-2.1
0.11.0-1). The security-tracker has the following entry, which now
needs an adjustment depending on the choosen aproach:
CVE-2014-8483 [out-of-bounds read on a heap-allocated array]
RESERVED
{DSA-3063-1}
- quassel 0.10.0-2.1 (bug #766962)
NOTE:
https://github.com/quassel/quassel/commit/8b5ecd226f9208af3074b33d3b7cf5e14f55b138
NOTE: http://bugs.quassel-irc.org/issues/1314
- konversation unfixed
NOTE: https://bugs.kde.org/show_bug.cgi?id=210792
I guess now 0.10.0-2.1 has to be re-uploaded with a different version
to testing-proposed-updates.
Either that or a 1:0.10.0-2.1 upload again to unstable, and ask the
release team for an unblock of this version. I think the latter would
be preferable as it leaves more changes of updates trough unstable
during the freeze complying with the freeze policy given.
Regards,
Salvatore
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
