Bug#735154: ITP: sockjs-twisted -- Simple library for adding SockJS support to a twisted application
Hi, On Mon, Jan 13, 2014 at 11:10 AM, Alexandre Rossi n...@zincube.net wrote: Package: wnpp Severity: wishlist Owner: Alexandre Rossi alexandre.ro...@gmail.com * Package name: sockjs-twisted Version : 1.2.1 Upstream Author : Christopher Gamble ch...@chrisgamble.net * URL : http://github.com/Fugiman/sockjs-twisted * License : BSD Programming Lang: Python Description : Simple library for adding SockJS support to a twisted application SockJS-Twisted passes all SockJS-Protocol v0.3.3 tests, and all SockJS-Client qunit tests. In addition to basic SockJS usage, it supports : - hosting multiple SockJS services off of one port, - offering of static resources, dynamic pages, and SockJS endpoints off of a single port, - multiplexing. FYI, preliminary package for review available[1]. I'll also be seeking sponsorship when git hosting is finalized (need to be part of DPMT or hosting in collab-maint on alioth?). Regards, Alex [1] http://sousmonlit.zincube.net/~niol/apt/pool/main/s/socksjs-twisted/socksjs-twisted_1.2.1-1~bpo70+1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686754: Is there any hope that this bug will be fixed?
Again and again i have to correct the grub.cfg manually.
And you can see this bug in all depending distributions of Debian.
Example today:
# blkid
/dev/sda1: LABEL=P1EXT4-8G UUID=c4aa8129-f5a0-4599-b487-3f63ff736c1b
TYPE=ext4
/dev/sda2: UUID=5166cbb1-8234-4127-bb0b-bbfda1658b68 TYPE=ext4
LABEL=P2EXT4-30G
/dev/sda5: UUID=448a6eb5-2173-43e3-b35a-62e9e81a2316 TYPE=swap
/dev/sda6: LABEL=P3EXT20G UUID=d37744be-c228-4add-9cf3-ce42aff94a7f SEC_TYPE=ext2
TYPE=ext3
/dev/sda7: LABEL=P7-EXT4-900G UUID=f4d36b10-bae9-4b22-a19b-0f34916337b3
TYPE=ext4
/dev/sda3: LABEL=P3EXT4-30G UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5
TYPE=ext4
/dev/sdb1: LABEL=SSD UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 TYPE=ext4
grub.cfg
menuentry Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (on /dev/sda3) --class
gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos3)'
search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
linux /boot/vmlinuz-3.2.0-3-amd64
root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro quiet
initrd /boot/initrd.img-3.2.0-3-amd64
}
menuentry Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (Wiederherstellungsmodus) (on /dev/sda3) --class gnu-linux --class
gnu --class os {
insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos3)'
search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
linux /boot/vmlinuz-3.2.0-3-amd64
root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single
initrd /boot/initrd.img-3.2.0-3-amd64
But the first 2 partitions are right now. ;-)
It would be fine if i can boot from all partitions ...
Cheers
Karsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735260: installation-reports: Jessie Netinst for PowerPC-64 creates will not boot after installation -- but works for PowerPC-32
Package: installation-reports Severity: important Tags: d-i -- Package-specific info: Boot method: CD Image version: Debian GNU/Linux testing Jessie - Official Snapshot powerpc NETINST Binary-1 20140108-22:14 Date: Jan 13, 2014 Machine: PowerPC MacPro G5 Partitions: sudo mac-fdisk -l /dev/sda /dev/sda #type name length base ( size ) system /dev/sda1 Apple_partition_map Apple 63 @ 1 ( 31.5k) Partition map /dev/sda2 Apple_Bootstrap untitled 1954 @ 64 (977.0k) NewWorld bootblock /dev/sda3 Apple_UNIX_SVR2 untitled 13671876 @ 2018 ( 6.5G) Linux native /dev/sda4 Apple_UNIX_SVR2 swap 11748047 @ 13673894 ( 5.6G) Linux swap /dev/sda5 Apple_UNIX_SVR2 untitled 1928103178 @ 25421941 (919.4G) Linux native /dev/sda6 Apple_Free Extra 49 @ 1953525119 ( 24.5k) Free space Block size=512, Number of Blocks=1953525168 DeviceType=0x0, DeviceId=0x0 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o] Detect network card:[o] Configure network: [o] Detect CD: [o] Load installer modules: [o] Clock/timezone setup: [o] User/password setup:[o] Detect hard drives: [o] Partition hard drives: [o] Install base system:[o] Install tasks: [o] Install boot loader:[o] Overall install:[e] Comments/Problems: All went well until it came time to reboot after the install. The machine rebooted and gave the question about whether to boot linux or CD. I answered l for Linux. Then it said loading secondary bootloader and nothing after that except the blinking folder icon with a questionmark. I believe the CD or Linux quetion and the loading second stage message come from the open-firmware program ofboot.b which is customized by ybin to account for the OF device location of the second stage bootloader, yaboot. It seems likely that the cusomiation is failing, somehow. It never gets into yaboot. I tried the same netinst CD on a G4, PowerPC-32 Mac and it worked perfectly. This bug report is being submitted from the G5 machine with Wheezy, so you can get all the hardware stuff for it. I'm also attaching the two yaboot.conf files for comparison. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=7 (wheezy) - installer build 20130613+deb7u1 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux macpro 3.2.0-4-powerpc64 #1 SMP Debian 3.2.51-1 ppc64 GNU/Linux lspci -knn: :f0:0b.0 Host bridge [0600]: Apple Inc. U3H AGP Bridge [106b:0059] lspci -knn: Kernel driver in use: agpgart-uninorth lspci -knn: :f0:10.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV350 AP [Radeon 9600] [1002:4150] lspci -knn: Subsystem: Advanced Micro Devices [AMD] nee ATI RV350 AP [Radeon 9600] [1002:4150] lspci -knn: Kernel driver in use: radeonfb lspci -knn: 0001:00:00.0 Host bridge [0600]: Apple Inc. U3 HT Bridge [106b:0057] lspci -knn: 0001:00:01.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge [106b:0045] lspci -knn: 0001:00:02.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge [106b:0046] lspci -knn: 0001:00:03.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge [106b:0047] lspci -knn: 0001:00:04.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge [106b:0048] lspci -knn: 0001:00:05.0 PCI bridge [0604]: Apple Inc. K2 HT-PCI Bridge [106b:0049] lspci -knn: 0001:01:07.0 Unassigned class [ff00]: Apple Inc. K2 KeyLargo Mac/IO [106b:0041] (rev 60) lspci -knn: Kernel driver in use: macio lspci -knn: 0001:01:08.0 USB controller [0c03]: Apple Inc. K2 KeyLargo USB [106b:0040] lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: 0001:01:09.0 USB controller [0c03]: Apple Inc. K2 KeyLargo USB [106b:0040] lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: 0001:02:0d.0 Unassigned class [ff00]: Apple Inc. K2 ATA/100 [106b:0043] lspci -knn: Kernel driver in use: pata-pci-macio lspci -knn: 0001:02:0e.0 FireWire (IEEE 1394) [0c00]: Apple Inc. K2 FireWire [106b:0042] lspci -knn: Subsystem: Apple Inc. Device [106b:5811] lspci -knn: Kernel driver in use: firewire_ohci lspci -knn: 0001:03:0f.0 Ethernet controller [0200]: Apple Inc. K2 GMAC (Sun GEM) [106b:004c] lspci -knn: Kernel driver in use: gem lspci -knn:
Bug#734696: qemu: Please add packages on powerpcspe
09.01.2014 12:44, Roland Stigge wrote: Source: qemu Version: 1.7.0+dfsg-2 Severity: wishlist Tags: patch Hi, on powerpcspe, some qemu packages are missing. The attached patch adds those. Hmm. What _is_ powerpcspe, anyway? I mean, I don't know architecture details anyway, but what it is for Debian? It does not look like an official debian architecture. If we start adding unofficial arches, what about other architectures missing? I'll add powerpcspe, but I just want to understand. Besides, I for one can't support it in any way, so any bugs/issues in there are yours (for some definition of you, -- maybe as users for non-official ports). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
On Tue, 2014-01-14 at 08:22 +0100, Hardy Griech wrote: On 13.01.2014 15:53, Ian Campbell wrote: On Mon, 2014-01-13 at 13:54 +0100, Sylvain LEVEQUE wrote: I upgraded a QNAP TS-119 from linux-image-3.11-2-kirkwood to linux-image-3.12-1-kirkwood. dpkg.log states: 2014-01-06 14:37:08 upgrade linux-image-kirkwood:armel 3.11+54 3.12+55 : thanks for notifying me. Where can I find the 3.13 experimental kernel? Adding the experimental package path to sources.list does not help. Ah, it seems I was mistaken -- the armel kernel package of 3.13 didn't build so it isn't available yet. I suppose this will be fixed with the next upload (I'm going to investigate). (I put the bug and Sylvain back in the CC so they see this too). Ian. signature.asc Description: This is a digitally signed message part
Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
On Tue, 2014-01-14 at 08:18 +, Ian Campbell wrote: Ah, it seems I was mistaken -- the armel kernel package of 3.13 didn't build so it isn't available yet. I suppose this will be fixed with the next upload (I'm going to investigate). FYI Ben has already fixed the FTBFS, so the next upload should be good. Ian. signature.asc Description: This is a digitally signed message part
Bug#729203: RFP: ffmpeg -- complete, cross-platform solution to record, convert and stream audio and video
FLOSS software and linux distros in particular are as successful as they are because of the separation between developers and distro-packagers. Disputes and disagreements will happen from time to time. However when debian takes a side and goes to the extent of using a name for a hostile fork, it certainly weakens debian. It also weakens FLOSS And the fact that ffmpeg does not exist in debian repos any more does not hold any water -- it was part of the hostile takeover -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604128: /usr/bin/perl: corrupted double-linked list also on i386
Package: perl Version: 5.18.1-5 Followup-For: Bug #604128 Dear Maintainer, Error occurred on a fresh installed Wheezy with kernel 3.12 from backports and broke the dist-upgrade. Used system is a Samsung NC10 netbook running kernel 3.12 from backports and SLiM DM with XFCE4 and i3 WM. The rest of the Wheezy installation is default. * What led up to the situation? Distro upgrade from wheezy to jessie * What exactly did you do (or not do) that was effective (or ineffective)? change wheezy to jessie in /etc/apt/sources.list apt-get update apt-get upgrade apt-get dist-upgrade * What was the outcome of this action? De-configuring udev (175-7.2) ... Unpacking consolekit (0.4.6-3+b1) over (0.4.5-3.1) ... Replacing files in old package udev (175-7.2) ... Preparing to unpack .../archives/udev_204-6_i386.deb ... Moving obsolete conffile /etc/init.d/udev-mtab out of the way... *** Error in `/usr/bin/perl': corrupted double-linked list: 0x09e280f0 *** * What outcome did you expect instead? Including a reboot a working Jessie :-) -- System Information: Debian Release: jessie/sid ( in between running is still wheezy upgrade failed ) APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.12-0.bpo.1-686-pae (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 perl depends on: ii libbz2-1.01.0.6-5 ii libc6 2.17-97 ii libdb5.1 5.1.29-6 ii libgdbm3 1.8.3-12 ii perl-base 5.18.1-5 iu perl-modules 5.18.1-5 ii zlib1g1:1.2.8.dfsg-1 Versions of packages perl recommends: ii netbase 5.2 Versions of packages perl suggests: pn libterm-readline-gnu-perl | libterm-readline-perl-perl none pn makenone pn perl-docnone Chears, Bernard Zijlstra -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This issue was assigned CVE-2014-1438 and has now been fixed in kernel mainline. Since analysis showed, that it is not specific to vm86-mode, new bug description could be similar to OSVDB: restore_fpu_checking Function Unhandled FPU Exception Local DoS See [1] for patch, [2] for information about CVE-assignment, at [3] you can find references to various resources related to this bug, e.g. the mailing list posts, POC code for crash and privilege escalation. [1] https://lkml.org/lkml/2014/1/11/196 [2] http://www.openwall.com/lists/oss-security/2014/01/14/1 [3] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/ - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLU4GUACgkQxFmThv7tq+7CxgCdGHW5AIIGLoO0CXTuJypIYsvU xrYAnRFi2QvDrBs3tnIkxvF+F3xpGZAj =H8Vy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735254: flash-kernel: QNAP TS-212 doesn't boot with 3.12-1-kirkwood and flash-kernel 3.12
Control: reassign -1 src:linux Control: forcemerge 735172 -1 On Tue, 2014-01-14 at 05:50 +, Ruben Silveira wrote: Description and steps to reproduce: - QNAP TS-212 (cpuinfo = 'QNAP TS-119/TS-219') with 3.11-2-kirkwood and flash-kernel 3.12; - Installed 3.12-1-kirkwood (update-initramfs and flash-kernel executed automatically and normally); - Rebooted; - System not up; - Connected serial console; - Rebooted; - System hangs just after kernel being (successfully) loaded by U-Boot, with no output whatsoever. You see Uncompressing Linux... done, booting the kernel. as the last thing, right? I was able to restore an old backup (flash and rootfs), repeat the whole process and get to the same exact result. I suppose this has to do with DT - Device Tree and could be (loosely) related to bugs #731345 and #734769. Actually AFAICT this is #735172 which is a kernel bug unrelated to the recent flash-kernel changes, reassigning and merging. The solution appears to be the appendage of DTB to the kernel, but I have little to no knowledge in patching flash-kernel to get to a working solution. This issue is being observed even on platforms which have no DTB support yet (e.g. TS-419). Have you actually tried with an appended DTB and seen it work or are you speculating? Thanks, Ian. signature.asc Description: This is a digitally signed message part
Bug#735261: kmail2 randomly marks read messages as unread
Package: kmail Version: 4:4.11.3-1 Severity: grave Justification: causes non-serious data loss Dear Maintainer, KMail randomly marks single messages as unread. This makes my normal workflow, where I leave messages unread for later, deeper consideration, tedious and bordering on impossible. KMail also randomly creates new duplicates of old messages, which are (of course) also marked unread. After an safe-update which included Akonadi, I found duplicates for 400 such messages. Losing read status is data loss. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-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 kmail depends on: ii kde-runtime 4:4.11.3-1 ii kdepim-runtime4:4.11.3-1 ii kdepimlibs-kio-plugins4:4.11.3-2 ii libakonadi-calendar4 4:4.11.3-2 ii libakonadi-contact4 4:4.11.3-2 ii libakonadi-kde4 4:4.11.3-2 ii libakonadi-kmime4 4:4.11.3-2 ii libakonadiprotocolinternals1 1.11.0-1 ii libc6 2.17-97 ii libcalendarsupport4 4:4.11.3-1 ii libgcc1 1:4.8.2-13 ii libgpgme++2 4:4.11.3-2 ii libgrantlee-core0 0.3.0-5 ii libincidenceeditorsng44:4.11.3-1 ii libkabc4 4:4.11.3-2 ii libkalarmcal2 4:4.11.3-2 ii libkcalcore4 4:4.11.3-2 ii libkcalutils4 4:4.11.3-2 ii libkcmutils4 4:4.11.3-2 ii libkdecore5 4:4.11.3-2 ii libkdepim44:4.11.3-1 ii libkdeui5 4:4.11.3-2 ii libkio5 4:4.11.3-2 ii libkleo4 4:4.11.3-1 ii libkmime4 4:4.11.3-2 ii libknewstuff3-4 4:4.11.3-2 ii libknotifyconfig4 4:4.11.3-2 ii libkontactinterface4 4:4.11.3-2 ii libkparts44:4.11.3-2 ii libkpgp4 4:4.11.3-1 ii libkpimidentities44:4.11.3-2 ii libkpimtextedit4 4:4.11.3-2 ii libkpimutils4 4:4.11.3-2 ii libkprintutils4 4:4.11.3-2 ii libksieveui4 4:4.11.3-1 ii libktnef4 4:4.11.3-2 ii libmailcommon44:4.11.3-1 ii libmailimporter4 4:4.11.3-1 ii libmailtransport4 4:4.11.3-2 ii libmessagecomposer4 4:4.11.3-1 ii libmessagecore4 4:4.11.3-1 ii libmessagelist4 4:4.11.3-1 ii libmessageviewer4 4:4.11.3-1 ii libnepomukcore4 4:4.11.3-2 ii libpimcommon4 4:4.11.3-1 ii libqt4-dbus 4:4.8.5+git209-g718fae5+dfsg-1 ii libqt4-network4:4.8.5+git209-g718fae5+dfsg-1 ii libqt4-xml4:4.8.5+git209-g718fae5+dfsg-1 ii libqtcore44:4.8.5+git209-g718fae5+dfsg-1 ii libqtgui4 4:4.8.5+git209-g718fae5+dfsg-1 ii libqtwebkit4 2.2.1-7 ii libsendlater4 4:4.11.3-1 ii libsolid4 4:4.11.3-2 ii libsoprano4 2.9.4+dfsg-1 ii libstdc++64.8.2-13 ii libtemplateparser44:4.11.3-1 ii perl 5.14.2-21 Versions of packages kmail recommends: ii gnupg-agent 2.0.22-3 ii gnupg22.0.22-3 ii pinentry-gtk2 [pinentry-x11] 0.8.3-1 Versions of packages kmail suggests: ii bogofilter 1.2.4+dfsg1-2 pn clamav | f-prot-installer none ii kaddressbook 4:4.11.3-1 pn kleopatra none ii procmail 3.22-21 ii spambayes 1.1a6-1 -- 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#734761: [Pkg-xen-devel] Bug#734761: xen-system-amd64: XEN kernel detects 3GB RAM instead of 4GB
On Thu, 2014-01-09 at 17:37 +0100, Maarten de Wolff wrote: The xen kernel detects 3GB of memory instead of the full 4GB. When using the normal kernel 4GB is detected. On boot the 4GB is detected: root@ams-tc1-xen27:~# dmesg |grep Mem [0.00] Memory: 3226132k/4980736k available (3426k kernel code, 788180k absent, 966424k reserved, 3312k data, 576k init) But only 3GB is used: This only tells you what dom0 is seeing/using. What does xl info (or xm info) tell you about the whole system? This might relate to the issue described in http://blog.xen.org/index.php/2012/04/30/memory-where-it-has-not-gone/ http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone Ian. signature.asc Description: This is a digitally signed message part
Bug#734857: bundler: cannot load, /usr/share/rubygems-integration/1.9.1/gems/bundler-1.5.0/bin/bundle
On 01/10/2014 05:45 PM, Christian Hofstaedtler wrote: * Chris c20...@gmail.com [140110 13:03]: To reproduce it suffices to call bundle: $ bundle /usr/local/bin/bundle:23:in `load': cannot load such file -- /usr/share/rubygems-integration/1.9.1/gems/bundler-1.5.0/bin/bundle (LoadError) from /usr/local/bin/bundle:23:in `main' ^ Debian does not ship /usr/local/bin/bundle. I suspect that you somehow installed bundler from RubyGems. Okay. So we reinstalled bundler and did then a `bundle install` for the gitlab stuff. Now gitlab worked again. The latest update of bundler from debian testing (1.5.1+dfsg-1) pulled in afterwords didn't break anything, either, i.e. now everything works as expected. Thanks, Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735183: FTBFS on all architectures: test-suite failures
On Tue, Jan 14, 2014 at 12:22 PM, Theppitak Karoonboonyanan t...@linux.thai.net wrote: That's weird. I cannot reproduce it with my i386 cowbuilder. See the attached build log. (My host system is amd64, but the base.cow being used is debootstrapped as i386.) OK. I managed to setup sbuild and have found the cause of the problem. It's about the difference between normal build and arch-only build. Fix will be uploaded soon. -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735159: dpkg: install-info fallout
On 2014-01-13 16:16, Guillem Jover wrote: Hmm, I guess it depends on the amount of packages affected, if it's few I don't think I would mind, but if we were talking about say 20+ then maybe we should look into something else. in wheezy, not in jessie, in sid (fixable in jessie or wheezy-pu) bison++ #708488 elib #689773 jargon #708492 opt #708497 trueprint #708500 automake1.9-doc #708486 in wheezy, not in jessie/sid (fixable in wheezy-pu) nana (pu #735020) in squeeze, not in wheezy/jessie/sid (needs Breaks in dpkg) bugzilla3 ( 3.6.2.0-5) cpp-4.1-doc ( 4.1.2.nf2-4) cpp-4.2-doc ( 4.2.4.nf1-4) gcc-4.1-doc gcc-4.2-doc gcj-4.1-doc gcj-4.2-doc gfortran-4.1-doc gfortran-4.2-doc gnat-4.1-doc gnat-4.2-doc And that is probably only the beginning ... still 3 piuparts tests queued Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735262: netpbm: typo in pam.5
Package: netpbm Version: 2:10.0-15+b1 Severity: normal Tags: patch Dear Maintainer, The manual page pam.5 contains wrongly spell TUPLTYPE as TUPLETYPE some places. TUPLETYPE -- TUPLTYPE /Torkel -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 netpbm depends on: ii libc62.13-38 ii libjpeg8 8d-1 ii libnetpbm10 2:10.0-15+b1 ii libpng12-0 1.2.49-1 ii libtiff4 3.9.6-11 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages netpbm recommends: ii ghostscript 9.05~dfsg-6.3+deb7u1 netpbm suggests no packages. -- no debconf information diff -ur netpbm-free-10.0-1.orig/pnm/pam.5 netpbm-free-10.0-1/pnm/pam.5 --- netpbm-free-10.0-1.orig/pnm/pam.5 2014-01-14 08:44:10.711015224 +0100 +++ netpbm-free-10.0-1/pnm/pam.5 2013-12-27 03:20:41.067392468 +0100 @@ -59,7 +59,7 @@ .br .B MAXVAL 255 .br -.B TUPLETYPE RGB +.B TUPLTYPE RGB .br .B ENDHDR @@ -120,7 +120,7 @@ header lines, the tuple type is the concatenation of the values from each of them, separated by a single blank, in the order in which they appear in the header. If there are no -.B TUPLETYPE +.B TUPLTYPE header lines the tuple type is the null string. .PP
Bug#735048: mediathekview: doesn't start at all
On 12.01.2014 11:20, Gerfried Fuchs wrote: Package: mediathekview Version: 4-1 Severity: grave Justification: renders package unusable Hi! *ping* Did you try to run MediathekView with OpenJDK 7? What was the outcome? Thanks Markus signature.asc Description: OpenPGP digital signature
Bug#712512: Problem remains
Please follow the instructions of the section USB printer does not print or prints garbage on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733222: qemu-system-x86: postinst script looks for update-alternatives in the wrong directory
27.12.2013 15:39, Andreas Janssen wrote: Package: qemu-system-x86 Version: 1.7.0+dfsg-2 Severity: normal Dear Maintainer, The postinst, prerm and portrm scripts of qemu-system-x86 (and other qemu-system packages) look for update-alternatives in the wrong directory: if [ -x /usr/sbin/update-alternatives ]; then On testing/unstable, update-alternatives is in /usr/bin: Actually it is in both, since /usr/sbin/update-alternatives is a symlink to ../bin/update-alternatives. It's been this way for a long time. But at any rate, this check is wrong, because update-alternatives, unlike, say, ucf or binfmt, isn't optional, it is part of dpkg and is always present on a debian (-derived) system. So there's just no point in checking for its presence. I removed it now. Thank you for the bugreport. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735048: mediathekview: doesn't start at all
tags 735048 - moreinfo severity 735048 normal thanks Dear Markus! * Markus Koschany a...@gambaru.de [2014-01-12 12:10:41 CET]: On 12.01.2014 11:20, Gerfried Fuchs wrote: I didn't want to wait the few days for the testing transition, so I installed mediathekview from unstable into my testing system. But it doesn't start at all, this is the output I receive: Did you try to run MediathekView with OpenJDK 6 or OpenJDK 7? As far as I can see you seem to have installed OpenJDK 7 but perhaps your defaults (update-alternatives) still point to version 6? MV 4 will only work with OpenJDK 7 or later and since default-jre points to OpenJDK-7 on your system, the dependency should be satisfied. You are right, after I removed openjdk-6 packages from my system mediathekview started properly. I am uncertain how this problem could get resolved. Having a wrapper script that would set JAVA_HOME, or anything along that lines. Or at least give useful error message when started from the commandline - which wouldn't help people calling it from the menu. Maybe a zenity dialogue then or such. Do you have an idea how other packages with similar requirements do mitigate the issue? At least thanks for your information on how to get it working! Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los| -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730604: [Pkg-libvirt-maintainers] Bug#730604: libvirt-bin: Please rename libvirt-bin.service back to libvirtd.service and use symlink or Alias= instead
Le Tue, 14 Jan 2014 07:56:43 +0100, Guido Günther a...@sigxcpu.org a écrit : Hi Laurent, On Sun, Jan 12, 2014 at 12:45:03PM +0100, Laurent Bigonville wrote: Le Wed, 27 Nov 2013 08:08:22 +0100, Guido Günther a...@sigxcpu.org a écrit : On Wed, Nov 27, 2013 at 07:36:31AM +0100, Laurent Bigonville wrote: Package: libvirt-bin Version: 1.1.4-1 Severity: normal Hi, Could you please rename back the libvirt-bin.service systemd service file to libvirtd.service and use a symlink (libvirtd.service - libvirt-bin.service) or add Alias=libvirt-bin.service in the service file instead. I've actually done this already here a couple of weeks ago to reduce the upstream diff but didn't get around to test if the upgrade works as expected when the unit name changes (since we don't stop the service in the preinst). Now that I read the below it was a good idea to not upload without proper testing. OK, we had an issue in quasi-similar situation with network-manager, see #734460) systemd when stopping the service, is looking in the cgroups for the canonical name of the .service file. If it cannot find it, it thinks the service is dead. The canonical name of the service would change during the upgrade and systemd will be confused. Thinking about this: wouldn't it be simpler (and more consistent with the sysv scripts) if we simply add a libvirt alias)? I'm not sure what you mean here. I don't think any changes on the LSB initscript is required here. Renaming the .service file back to the original and adding a symlink that matches the name of the initscript should be enough. Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735186: Problem with diff report
Hello Roland! - Mail original - Hi Vincent! On Mon, 13 Jan 2014, Vincent LOUPIEN wrote: Since the migration of Debian 6 Squeeze in Debian 7.2 Wheezy , there is a problem with the generation of the daily report of differences . In this report indicated all configurations of all networks equipements that have experienced a change in theirs configurations. Can you give more concrete information what changed? Is it every single line of every config or is it only some special part of the config? No changes have been made to the configuration of Rancid during the migration phase from Squeeze to Wheezy. What type of devices (vendor) do you collect data from? Only devices from Cisco Catalyst and HP Procurve series. We manage 3 sites that are running more than 150 facilities , each of our sites have its own Rancid (with an identical configuration) and the 3 Rancid have exactly the same bad behavior and generate daily messages more and longer ... and finaly unworkable. I have to admit, that we still run squeeze on our production rancid systems, but with a (recompiled) wheezy rancid version. We didn't notice any problems with this setup on our devices. I did not dare get into a test from sources Rancid, I focus on using Debian package. I think this problem comes from running the new version of Debian or a side effect of migration (libraries, dependences, etc ...). Machines from which run my Rancid also host other services such as MRTG, Nagios, Syslog-ng, Apache2 ... and everything works wonders. So you should give me more input what exactly goes wrong. No problem: tell me what data do you need to advance your investigation: conf, log, others information ... ? Thank you for your quick reply :-) -- BEGIN:VCARD VERSION:3.0 FN:Vincent LOUPIEN N:LOUPIEN;Vincent;;; ADR;TYPE=work,postal,parcel:;;Direction des Systemes d'Information,Universite Pierre Mendes-France,Batiment Langues\, Nouvelles Technologies - Bureau 23,Domaine Universitaire,1300\, rue des Résidences - BP 47 Cedex 9;Grenoble;;F-38040; TEL;TYPE=work,fax:(+33).4.76.82.83.13 TEL;TYPE=work,voice:(+33).4.76.82.57.58 EMAIL;TYPE=internet:vincent.loup...@upmf-grenoble.fr URL;TYPE=work:http://webdsi.upmf-grenoble.fr/connecteur_php_5.1/BiperV4/infosplus_carte.php?personne=1218 REV:2013-03-22T14:01:40Z UID:c675c308-6f59-46f5-9589-14e7e4524794:2249 END:VCARD
Bug#734696: qemu: Please add packages on powerpcspe
Hi, On 01/14/2014 09:18 AM, Michael Tokarev wrote: Hmm. What _is_ powerpcspe, anyway? I mean, I don't know architecture details anyway, but what it is for Debian? It does not look like an official debian architecture. powerpcspe is basically powerpc without floating point registers nor AltiVec. However, it does floating point in the regular (integer) GPRs in an incompatible / overlapping instruction set. Therefore, incompatible. It needs to be re-compiled and maintained as a separate architecture. See https://wiki.debian.org/PowerPCSPEPort If we start adding unofficial arches, what about other architectures missing? Besides the official Debian architectures, debian-ports.org (run by Debian Developers also) provides some additional unofficial architectures, including powerpcspe, ppc64, alpha, sparc64 etc. We don't support them officially as debian.org, but accept wishlist bugs that improve support for debian-ports.org architectures. Some of them eventually become official Debian architectures in the future. Some of them are previously official architectures like hppa and m68k. I'll add powerpcspe, but I just want to understand. Fine, thanks! Besides, I for one can't support it in any way, so any bugs/issues in there are yours (for some definition of you, -- maybe as users for non-official ports). I'm maintaining powerpcspe as a port. However, mostly using standard Debian source packages for this which works fine, basically. Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735138: autopkg test always failing
Hi Martin, On Mon, Jan 13, 2014 at 05:26:42PM +0100, Martin Pitt wrote: Hello Ralf, Ralf Treinen [2014-01-13 16:53 +0100]: thanks for your patch. However, I cannot reproduce that Bad Input Stream error on my machine. What are the versions of the dependencies of aspcud that you had installed when running this test ? Indeed I re-tried in sid, and that particular Bad Input Stream error doesn't happen there: /tmp/aspcud-1.8.0 $ adt-run -B .// --- adt-virt-schroot sid [...] adt-run: ubtree0t-upstream: - - - - - - - - - - results - - - - - - - - - - ubtree0t-upstreamFAIL non-zero exit status 126 adt-run: ubtree0t-upstream: - - - - - - - - - - stderr - - - - - - - - - - /usr/bin/aspcud: /tmp/adt-run.rFHKC6/ubtree0t-upstream-testtmp/tmpdir/outNJPr7x/parse.py: /usr/bin/python: bad interpreter: No such file or directory So apparently something in these tests uses python, but python isn't a dependency of the package or the tests. Once I add that, the test [...] It may very well be that python actually needs to be a binary dependency of aspcud or cudf-tools, I didn't check that closely. Indeed, aspcud needs to depend on python. The aspcud.sh shell script contains an embedded python script, as I just discovered. Thanks for your help ! -Ralf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735264: wget does not check alternative names in SSL certificates
Package: wget Version: 1.13.4-3 Severity: normal Dear Maintainer, I have noticed that wget dos not honor alternative DNS names in SSL certificates. I found bug #409938 that deals with this problem and was closed stating that wget 1.13-1 has been patched. But it seems that the patch got lost in newer versions. You can test on https://uran.webstep.net/ wget says the certificate is not trusted, while curl downloads without any problem. Best regards Vladislav Kurz -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/8 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages wget depends on: ii dpkg 1.16.12 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38 ii libgcrypt111.5.0-5+deb7u1 ii libgnutls262.12.20-7 ii libgpg-error0 1.10-3.1 ii libidn11 1.25-2 ii zlib1g 1:1.2.7.dfsg-13 wget recommends no packages. wget 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#735265: lightdm-gtk-greeter: Language of previous session is not used
Package: lightdm-gtk-greeter Version: 1.6.1-5 Severity: normal Tags: l10n Dear Maintainer, When I select my language once in the language selector, I want to be logged in with that language on all subsequent log-ins, until I select another language in the language selector. That does not happen. I am always logged with the language of the system-wide locale, unless I select a language in the language selector. My language setting in ~/.xsessionrc is overwritten. Ideally, the language selector would have a option which leaves the setting in such a script unmodified. * What led up to the situation? I select english in the language selector and log in. Language is english. I log out. I make no selection in the language selector and log in. Language is dutch. * What outcome did you expect instead? I expect that subsequent log-ins use the earlier selected language, i.e. english in my case. Note that the locale setting below is the result of logging in with english as the selected language. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lightdm-gtk-greeter depends on: ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-02.36.4-1 ii libgtk-3-0 3.8.6-1 ii liblightdm-gobject-1-0 1.8.5-3 ii libx11-62:1.6.2-1 Versions of packages lightdm-gtk-greeter recommends: ii desktop-base 7.0.3 ii gnome-icon-theme-symbolic 3.10.1-1 pn gnome-themes-standard none ii policykit-10.105-4 lightdm-gtk-greeter suggests no packages. -- Configuration Files: /etc/lightdm/lightdm-gtk-greeter.conf changed: [greeter] background=/usr/share/images/desktop-base/login-background.svg theme-name=Adwaita xft-antialias=true xft-hintstyle=hintfull xft-rgba=rgb -- 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#733341: man pod blarg
Well dagnabit. So an i386 autobuilder is running an old pod2man or dependencies thereof. -.\ Automatically generated by Pod::Man 2.22 (Pod::Simple 3.07) +.\ Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28) Naturally the differences in the generated man pages are pretty trivial. I'm not sure if this is really Severity: important, assuming dpkg just installs one or the other for each file it doesn't make any real difference. Or does dpkg error out? That would be unfortunate. I could remove the Multi-Arch: same from liboping-dev. Or I could break out the man pages into liboping-doc. Or I could ignore the problem until dpkg becomes semantically aware, or pod2man stops leaving version numbers and commuting punctuation and formatting commands. Any recommendation? --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735186: Problem with diff report
Hi Vincent! On Tue, 14 Jan 2014, Vincent LOUPIEN wrote: No changes have been made ??to the configuration of Rancid during the migration phase from Squeeze to Wheezy. That's what I thought, but what changes does rancid report? Does it report everything changed (maybe because the line ends differ) or does it report only changes in some comments (for example the time stamp of the configuration or something like this)? Does rancid report the changes on every run? If so, how do the changes vary from report to report? If not, you may have a problem with CVS/SVN, where the data is stored? What type of devices (vendor) do you collect data from? Only devices from Cisco Catalyst and HP Procurve series. And all of them mention changes or only some subset? We didn't notice any problems with Cisco switches here (don't have HP Procurve for testing). Tscho Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735254: flash-kernel: QNAP TS-212 doesn't boot with 3.12-1-kirkwood and flash-kernel 3.12
On 14 January 2014 08:36, Ian Campbell i...@hellion.org.uk wrote: Control: reassign -1 src:linux Control: forcemerge 735172 -1 On Tue, 2014-01-14 at 05:50 +, Ruben Silveira wrote: Description and steps to reproduce: - QNAP TS-212 (cpuinfo = 'QNAP TS-119/TS-219') with 3.11-2-kirkwood and flash-kernel 3.12; - Installed 3.12-1-kirkwood (update-initramfs and flash-kernel executed automatically and normally); - Rebooted; - System not up; - Connected serial console; - Rebooted; - System hangs just after kernel being (successfully) loaded by U-Boot, with no output whatsoever. You see Uncompressing Linux... done, booting the kernel. as the last thing, right? You're right, that is the last message. I was able to restore an old backup (flash and rootfs), repeat the whole process and get to the same exact result. I suppose this has to do with DT - Device Tree and could be (loosely) related to bugs #731345 and #734769. Actually AFAICT this is #735172 which is a kernel bug unrelated to the recent flash-kernel changes, reassigning and merging. The solution appears to be the appendage of DTB to the kernel, but I have little to no knowledge in patching flash-kernel to get to a working solution. This issue is being observed even on platforms which have no DTB support yet (e.g. TS-419). Have you actually tried with an appended DTB and seen it work or are you speculating? I'm speculating, as I haven't tried that. I don't know what or how to append to a kernel. If you can point me to some kind a reference, I can test that out in my current setup. Thank you, Ruben -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693047: libpng: Please add autopkgtest
[I'm not the maintainer of this package.] * Martin Pitt martin.p...@ubuntu.com, 2012-11-12, 14:05: in Ubuntu Rafał Cieślak contributed an autopkgtest [1] test to libpng to run a simple compile/link/run test. This ensures that the -dev package installs a working pkg-config file, header files into the correct place, pulls in the right dependencies, etc. FWIW, the attached patch doesn't test if the pkg-config file works. + //Just creating a simple wrie struct. Typo: wrie - write -- 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#734464: Can be patched but it is problematic
This problem is the result of multiarch i think. Winetricks does not search /usr/lib/i386-linux-gnu/wine/bin and usr/lib/x86_64-linux-gnu/wine/bin for wineserver. I patched winetricks to include /usr/lib/i386-linux-gnu/wine/bin because i only use 32 bit prefixes and it works for me. But i think winetricks has to decide wich wineserver to use depending on the wineprefix (32 or 64 bit). Correct me if i am wrong. 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#714492: cups: Please allow cups to be build against libgnutls28-dev.
Control: reopen -1 Le samedi, 4 janvier 2014, 14.23:24 Didier '' Raboud a écrit : Hi Nicolas, Le dimanche, 30 juin 2013, 15.23:10 Nicolas Le Cam a écrit : A perhaps better option could be to directly build-depends on libgnutls28-dev (if no other packages depends on cups and legacy gnutls). I'm considering switching cups away from GnuTLS to OpenSSL given the recent discussion on debian-devel [0]. In fact, given that CUPS is GPL-2 only, it is not license-wise allowed to link CUPS with libgnutls28-dev The discussion has now showed that linking against OpenSSL is even worse, so I've made libcups2 link against GnuTLS 2.x again. And this move reopens this bug. Sorry… Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#735266: lintian: ppc64el architecture not recognised
Package: lintian Version: 2.5.21 Severity: normal Dear Maintainer, I have just uploaded procenv_0.29-2 which has a Build-Depends on libnuma-dev. That library is very architecture-dependent so I have had to specify all the Linux architectures in procenv's debian/control that are relevant. However, lintian rejects 'linux-ppc64el' as a valid architecture: $ lintian --profile debian -I -E --pedantic procenv_0.29-2_source.changes N: Using profile debian/main. N: Setting up lab in /tmp/temp-lintian-lab-6dBvDYkBJw ... N: Unpacking packages in group procenv/0.29-2 N: N: Processing changes file procenv (version 0.29-2, arch source) ... N: N: Processing source package procenv (version 0.29-2, arch source) ... E: procenv source: invalid-arch-string-in-source-relation linux-ppc64el [build-depends: libnuma-dev [linux-i386 linux-amd64 linux-ia64 linux-mips linux-mipsel linux-powerpc linux-ppc64 linux-ppc64el linux-x32]] P: procenv source: debian-watch-may-check-gpg-signature $ lintian --ftp-master-rejects -I -E --pedantic procenv_0.29-2_source.changes N: Using profile debian/ftp-master-auto-reject. N: Setting up lab in /tmp/temp-lintian-lab-T_cZDOel0A ... N: Unpacking packages in group procenv/0.29-2 N: N: Processing changes file procenv (version 0.29-2, arch source) ... N: N: Processing source package procenv (version 0.29-2, arch source) ... -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty') Architecture: i386 (i686) Kernel: Linux 3.13.0-2-generic (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.24-2ubuntu2 ii bzip2 1.0.6-5 ii diffstat 1.58-1 ii file 1:5.14-2ubuntu1 ii gettext0.18.3.1-1ubuntu2 ii hardening-includes 2.5ubuntu1 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29build1 ii libarchive-zip-perl1.30-7 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.36-1 ii libdpkg-perl 1.17.1ubuntu1 ii libemail-valid-perl1.192-1 ii libfile-basedir-perl 0.03-1fakesync1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-1build3 ii libparse-debianchangelog-perl 1.2.0-1ubuntu1 ii libtext-levenshtein-perl 0.06~01-2 ii libtimedate-perl 2.3000-1 ii liburi-perl1.60-1 ii man-db 2.6.5-3 ii patchutils 0.3.2-3 ii perl [libdigest-sha-perl] 5.18.1-5 ii t1utils1.37-2ubuntu1 Versions of packages lintian recommends: ii libautodie-perl 2.22-1 ii libperlio-gzip-perl 0.18-1build3 ii perl-modules [libautodie-perl] 5.18.1-5 Versions of packages lintian suggests: ii binutils-multiarch 2.24-2ubuntu2 ii dpkg-dev 1.17.1ubuntu1 ii libhtml-parser-perl3.71-1build1 ii libtext-template-perl 1.46-1 pn libyaml-perl none ii xz-utils 5.1.1alpha+20120614-2ubuntu1 -- no debconf information Kind regards, James. -- James Hunt #upstart on freenode http://upstart.ubuntu.com/cookbook https://lists.ubuntu.com/mailman/listinfo/upstart-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731195: works for me with wine 1.6.2-1 on wheezy
But i haven't checked sid. 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#735267: python-debian: add support for data.tar.xz
Package: python-debian Version: 0.1.21+nmu2 Severity: normal This just needs a trivial change to add 'xz' to PART_EXTS, but there are increasing numbers of packages with a data.tar.xz /usr/share/pyshared/debian/debfile.py:PART_EXTS = ['gz', 'bz2', 'xz'] # possible extensions -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armel armhf Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-debian depends on: ii python 2.7.5-5 ii python-chardet 2.0.1-2 ii python-six 1.5.2-1 Versions of packages python-debian recommends: ii python-apt 0.9.1 Versions of packages python-debian suggests: ii gpgv 1.4.16-1 -- no debconf information -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#735268: xemacs21: circular dependency hell
Package: xemacs21 Version: 21.4.22-5 Severity: important Hello Mark, There is a circular dependency between xemacs21, xemacs21-bin, xemacs21-mule, xemacs21-mule-canna-wnn, xemacs21-nomule and xemacs21-support: xemacs21:Depends: xemacs21-mule (= 21.4.22-5), xemacs21-mule-canna-wnn (= 21.4.22-5), xemacs21-nomule (= 21.4.22-5) xemacs21-bin:Depends: xemacs21-support (= 21.4.22-5) xemacs21-mule :Depends: xemacs21-support (= 21.4.22-5), xemacs21-bin (= 21.4.22-5+b1) xemacs21-mule-canna-wnn :Depends: xemacs21-support (= 21.4.22-5), xemacs21-bin (= 21.4.22-5+b1) xemacs21-nomule :Depends: xemacs21-support (= 21.4.22-5), xemacs21-bin (= 21.4.22-5+b1) xemacs21-support:Depends: xemacs21 (= 21.4.22-5) Complex circular dependencies are known to cause problems during upgrade, so we should try to get rid of them. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735253: libsdl1.2: Changes for ppc64el support
Hi, 2014/1/14 Steve Langasek steve.langa...@canonical.com: Package: libsdl1.2 Version: 1.2.15-8 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty ubuntu-patch Dear maintainers, In Ubuntu, we've applied the following patch to libsdl1.2 in order to make the package build on the ppc64el architecture. The upstream autogen.sh script does not properly invoke libtoolize, so dh_autoreconf ./autogen.sh only partially updates the autogenerated files; and this matters, since the ppc64el port specifically needs an update of ltmain.sh (and other future ports might, as well). Thanks for the report and the patch. We've been having the same problem with most of the SDL packages for new arches like arm64 and this one, at least the ones coming from core SDL and not extra modules. Do you think that there's a more fundamental way to fix this, like asking upstream about modifying autogen.sh with more sensible/useful/convenient commands; which would allow us to go without this kind of patches and less lines in debian/rules? At least since I am involved in the maintenance of SDL packages, about a year or two, they are quite amenable to incorporating fixes from us, specially because they are quite involved with deb packaging (they are hired by the company doing Steam OS, and I think that libSDL is an important aspect of Steam). Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675081: proftpd-basic: logrotate kills proftpd instead of restarting it
I have the same bug on 1.3.5~rc3-2.1. invoking restart manually gives ok for stop and ok for start, but the service is not actually started. adding a sleep 2 between stop and start in the init.d-script resolves the issue. This is running proftpd in StandAlone-mode. I just had this bug start happening to me, and it happens even without logrotate being involved. Just running: /etc/init.d/proftpd restart Logrotate invokes a restart of proftpd after rotation, so - in effect - running logrotate or restarting proftpd manually results in the same parts of the init.d script being run. The funny thing is that adding the sleep command totally changes the output of the init.d-script. This is without sleep: root@nas /etc/proftpd # /etc/init.d/proftpd restart [ ok ] Stopping ftp server: proftpd. [ ok ] Starting ftp server: proftpd. (proftpd is not running now) And this is with sleep: root@nas /etc/proftpd # /etc/init.d/proftpd restart [ ok ] Stopping ftp server: proftpd. [] Starting ftp server: proftpd2014-01-14 11:02:58,517 nas proftpd[3921] nas.weily.lan: 127.0.1.1:21 masquerading as x.x.x.x . ok
Bug#735269: iceweasel: PDF files saved via the built-in pdf viewer are corrupted
Package: iceweasel
Version: 24.2.0esr-1
Severity: normal
Tags: upstream
Dear Maintainer,
PDF files opened in the Firefox built-in viewer (plug-in) are
corrupted when downloaded using the 'Download' icon on the upper
right-hand corner of the screen. When I attempt to open one of these
damaged files using Evince, an error message is displayed, saying that
the file is corrupted and could not be opened.
If I instead download the file by right-clicking the link to the PDF
file and select 'Save Page As...' the file is downloaded undamaged.
This problem is discussed here:
https://support.mozilla.org/en-US/questions/972500. It is claimed that
the problem is fixed in later versions of pdf.js.
Please, port this back to the ESR version 24.
I know I can install the updated extension myself, but that is not how
an ESR version is supposed to work.
-- Package-specific info:
-- Extensions information
Name: Adblock Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled
Name: DBpedia Link for English Wikipedia Pages greasemonkey-user-script
Status: enabled
Name: Debian buttons
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8fb11c5b-84eb-4da0-9128-292eacce2dcb}
Package: xul-ext-debianbuttons
Status: enabled
Name: Default theme
Location:
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: DOM Inspector
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/inspec...@mozilla.org
Package: xul-ext-dom-inspector
Status: enabled
Name: Firebug
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/fire...@software.joehewitt.com
Package: xul-ext-firebug
Status: enabled
Name: FirePath
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/firexp...@pierre.tholence.com
Package: xul-ext-firexpath
Status: enabled
Name: Font Finder
Location: ${PROFILE_EXTENSIONS}/fontfin...@bendodson.com.xpi
Status: enabled
Name: Greasemonkey
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
Package: xul-ext-greasemonkey
Status: enabled
Name: Live HTTP headers
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}
Package: xul-ext-livehttpheaders
Status: enabled
Name: NoScript
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{73a6fe31-595d-460b-a920-fcc0f8843232}
Package: xul-ext-noscript
Status: enabled
Name: Operator
Location: ${PROFILE_EXTENSIONS}/{95C9A302-8557-4052-91B7-2BB6BA33C885}
Status: user-disabled
Name: Pocket
Location: ${PROFILE_EXTENSIONS}/isreaditla...@ideashower.com
Status: enabled
Name: ScrapBook
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{53A03D43-5363-4669-8190-99061B2DEBA5}
Package: xul-ext-scrapbook
Status: enabled
Name: Semantic Radar
Location: ${PROFILE_EXTENSIONS}/{94D438B0-C561-11DA-ABDA-D530ACCB55DD}
Status: enabled
Name: SQLite Manager
Location: ${PROFILE_EXTENSIONS}/sqlitemana...@mrinalkant.blogspot.com.xpi
Status: enabled
Name: The Tabulator Extension
Location: ${PROFILE_EXTENSIONS}/tabula...@csail.mit.edu
Status: app-disabled
Name: UnMHT
Location: ${PROFILE_EXTENSIONS}/{f759ca51-3a91-4dd1-ae78-9db5eee9ebf0}.xpi
Status: enabled
Name: WARM SHADES OF AUTUMN theme
Status: user-disabled
Name: Web Developer
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{c45c406e-ab73-11d8-be73-000a95be3b12}
Package: xul-ext-webdeveloper
Status: enabled
-- Plugins information
Name: DivX® Web Player
Location: /usr/lib/mozilla/plugins/libtotem-mully-plugin.so
Package: totem-mozilla
Status: enabled
Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled
Name: Google Talk Plugin Video Accelerator
Location: /opt/google/talkplugin/libnpgtpo3dautoplugin.so
Package: google-talkplugin
Status: enabled
Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled
Name: IcedTea-Web Plugin (using IcedTea-Web 1.3.2 (1.3.2-1))
Location: /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-6-plugin:amd64
Status: disabled
Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled
Name: QuickTime Plug-in 7.6.6
Location: /usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so
Package: totem-mozilla
Status: enabled
Name: Shockwave Flash (11,2,202,332)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled
Name: VLC Multimedia Plugin (compatible Videos 3.8.2)
Location: /usr/lib/mozilla/plugins/libtotem-cone-plugin.so
Package: totem-mozilla
Status:
Bug#735270: package build with SSE2 defaults on i386
Package: glm Version: 0.9.5.0-1 Severity: serious Tags: sid jessie when building on i386: cd /build/buildd/glm-0.9.5.0/obj-i686-linux-gnu/test/gtx /usr/bin/c++ -D_CRT_SECURE_NO_WARNINGS -O2 -g -DNDEBUG -I/build/buildd/glm-0.9.5.0/. -I/build/buildd/glm-0.9.5.0/./test/external-pedantic -o CMakeFiles/test-gtx_associated_min_max.dir/gtx_associated_min_max.cpp.o -c /build/buildd/glm-0.9.5.0/test/gtx/gtx_associated_min_max.cpp In file included from /build/buildd/glm-0.9.5.0/test/gtx/gtx_associated_min_max.cpp:10:0: /usr/lib/gcc/i686-linux-gnu/4.8/include/emmintrin.h:31:3: error: #error SSE2 instruction set not enabled # error SSE2 instruction set not enabled ^ This is not just for the glm build, but every package build-depending on this will ftbfs on i386. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730604: [Pkg-libvirt-maintainers] Bug#730604: libvirt-bin: Please rename libvirt-bin.service back to libvirtd.service and use symlink or Alias= instead
On Tue, Jan 14, 2014 at 10:08:58AM +0100, Laurent Bigonville wrote: [..snip..] I'm not sure what you mean here. I don't think any changes on the LSB initscript is required here. Renaming the .service file back to the original and adding a symlink that matches the name of the initscript should be enough. We'd e.g. still have /etc/default/libvirt-bin used to configure the libvirtd service. THe package will also still be named libvirt-bin so I wonder if it wouldn't be more consistent to leave the service file as and add a Alias=libvirtd so firewalld and others can reference it. I'm o.k. with renaming the whole package from libvirt-bin - libvirtd in the future including unit files and init scripts but that's nothing I have time for atm. Patches to achieve this (and especially testing) would be welcome. Cheers, -- Guido Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735264: wget certificates checking
Hello, I have found out that the problem was not in alternative names, but in certificate chain. I had some extra certificates (not needed to verify my server certificate) in the chain file and that was breaking it. -- S pozdravem Vladislav Kurz === WebStep, s.r.o. (Ltd.) = a step to the Web === address: Mezirka 1, 602 00 Brno, CZ, tel: +420 548 214 711 === www.webstep.net === vladislav.k...@webstep.net ===
Bug#733931: yafaray-exporter: Cannot activate addon
Hi, the yafaray homepage lists the 0.1.5 version for blender 2.67. At least on my machine it is running with blender 2.69. But I agree with you. It might be better to remove it from testing than to be annoyed with an incompatibility. Thanks Joseph Matteo F. Vescovi mfvesc...@gmail.com schrieb am 16:50 Mittwoch, 8.Januar 2014: Hi! On Thu, Jan 02, 2014 at 12:42:39PM +0100, Joseph Tannhuber wrote: Dear Maintainer, the addon does not work at all. If I try to activate the addon in blender (File - User Preferences - Addons - Render - Render: YafaRay Exporter), it fails with following error message: Error Traceback (most recent call last): File /usr/share/blender/scripts/modules/addon_utils.py, line 298 in enable mod=__import__(module_name) File /usr/share/blender/scripts/addons/yafaray/__init__.py, line 80, in module from.import prop ImportError: cannot import name prop YafaRay upstream is almost discontinued and even if I asked million times for tags in the source, actually I don't know which modification/commit brings the exporter to work fine with blender 2.69; this is the main reason why I haven't updated it yet. If the situation upstream-side doesn't change, I'm thinking about asking the complete removal of yafaray packages, engine and exporter. Cheers. -- Matteo F. Vescovi Debian Maintainer GnuPG KeyID: 0x83B2CF7A
Bug#735271: nvidia-graphics-drivers: CVE-2013-5987 - Unprivileged GPU access vulnerability
Source: nvidia-graphics-drivers Severity: serious Tags: security Control: fixed -1 319.72-1,331.20-1 Quoting from http://nvidia.custhelp.com/app/answers/detail/a_id/3377 Vulnerability Description: An NVIDIA graphics driver bug allows unprivileged user-mode software to access the GPU inappropriately. An attacker who successfully exploited this vulnerability could take control of an affected system. Exploit Scope and Risk: To take advantage of this vulnerability, an attacker would need to run specially crafted software locally on the target computer. Expert knowledge of system and NVIDIA GPU programming would be required to create such an exploit. NVIDIA is not aware of the existence of any actual exploits that leverage this vulnerability. This issue could potentially affect all supported PC OS platforms and form factors. NVIDIA Tegra GPUs are not vulnerable. The following table shows the first NVIDIA UNIX GPU Drivers that contain the security fix. Driver BranchVersion Release 331 331.20 Release 319 319.72 Release 304 304.116 nvidia-graphics-drivers-legacy-304xx is affected as well, but is already at the fixed version. It is unknown whether the older legacy branches are affected. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735270: package build with SSE2 defaults on i386
On Tue, Jan 14, 2014 at 11:09:09AM +0100, Matthias Klose wrote: when building on i386: cd /build/buildd/glm-0.9.5.0/obj-i686-linux-gnu/test/gtx /usr/bin/c++ -D_CRT_SECURE_NO_WARNINGS -O2 -g -DNDEBUG -I/build/buildd/glm-0.9.5.0/. -I/build/buildd/glm-0.9.5.0/./test/external-pedantic -o CMakeFiles/test-gtx_associated_min_max.dir/gtx_associated_min_max.cpp.o -c /build/buildd/glm-0.9.5.0/test/gtx/gtx_associated_min_max.cpp In file included from /build/buildd/glm-0.9.5.0/test/gtx/gtx_associated_min_max.cpp:10:0: /usr/lib/gcc/i686-linux-gnu/4.8/include/emmintrin.h:31:3: error: #error SSE2 instruction set not enabled # error SSE2 instruction set not enabled ^ This is not just for the glm build, but every package build-depending on this will ftbfs on i386. I don't think reverse depends will FTBFS. The problem is that the tests (which are only run at build time and are not in any way included in the binary packages) unconditionally #include emmintr.h. Could you try removing those #includes from glm-0.9.5.0/test/gtx/*.cpp, and try building again? -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Bug#735272: redist-server: please ship redis-sentinel
Package: redis-server Version: 2:2.8.2-1 Hi, although redis-sentinel is being built by src/Makefile, it is not listed in the install target of the Makefile - but it would still be nice to have it in the server package. Thanks, Bernd -- Mit freundlichen Grüßen Bernd Zeimetz Systems Engineer Debian Developer conova communications GmbH Web| http://www.conova.com/ E-Mail | b.zeim...@conova.com Zentrale Salzburg Karolingerstraße 36A 5020 Salzburg Tel | +43 (0) 662 22 00 - 313 Fax | +43 (0) 662 22 00 - 209 Es gelten die Allgemeinen Geschäftsbedingungen der conova communications GmbH, http://www.conova.com/de/agb/ smime.p7s Description: S/MIME cryptographic signature
Bug#735274: BSD license missing in debian/copyright
Package: openstack-trove Severity: normal User: alteh...@debian.org thanks Dear Maintainer, please add the BSD license of doc/source/_static/nature.css to debian/copyright. Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735273: xdelta3: Please add watch file
Source: xdelta3 Version: 3.0.7-dfsg-2 Severity: wishlist Dear Maintainer, I am attaching a watch file for your package. Please consider applying it. Also, a new upstream release (3.0.8) is now available. -- Dmitry Shachnev watch Description: Binary data
Bug#732008: Problem reappeared with 1.8.9p3-1
Just to confirm: problem is back in 1.8.9p3-1. I'm still using systemd, but maybe systemd is a red herring and it depends on other factors, e.g. gcc version. I just rebuilt 1.8.9~rc1-1 and 1.8.9p3-1 with the same toolchain (latest gcc-4.8 from testing): 1.8.9~rc1-1: good 1.8.9p3-1: bad Cheers, Roderich
Bug#254615: Bug#451932: Tar 1.27 supports ACL's
Yes, tar 1.27 supports ACLs, but that implementation needs bug fixes to bugs that make a reliable backup and restore more or less impossible. See https://bugzilla.redhat.com/show_bug.cgi?id=1052876 or http://lists.gnu.org/archive/html/bug-tar/2013-03/msg00021.html I would be happy to see a fixed version at least at Debian experimental - upstream maintainers might be happy to have test results... Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735275: libudev1: Keep libudev.so.0 as a link to libudev.so.1
Package: libudev1 Version: 204-6 Severity: normal Dear Maintainer, A number of applications depend on libudev.so.0, e.g. Google Chrome. These applications solve the problem by creating a link libudev.so.0 - /lib/x86_64-linux-gnu/libudev.so.1. Many users are affected by such failures, and on the web there are many questions about the problem. It would be better if the package libudev1 installs such a link. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libudev1 depends on: ii libc6 2.17-97 ii multiarch-support 2.17-97 libudev1 recommends no packages. libudev1 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#735270: package build with SSE2 defaults on i386
Am 14.01.2014 11:23, schrieb Guus Sliepen: I don't think reverse depends will FTBFS. The problem is that the tests (which are only run at build time and are not in any way included in the binary packages) unconditionally #include emmintr.h. Could you try removing those #includes from glm-0.9.5.0/test/gtx/*.cpp, and try building again? I don't think this would be the correct fix, because the include machinery provides several FORCE macros to support those targets as well. Please check with a i386 chroot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735264: wget certificates checking
Hello Vladislav, Am Dienstag, den 14.01.2014, 10:55 +0100 schrieb Vladislav Kurz: I have found out that the problem was not in alternative names, but in certificate chain. I had some extra certificates (not needed to verify my server certificate) in the chain file and that was breaking it. :) OK, fine. So there is no bug in wget in this area.;) Regards Noel signature.asc Description: This is a digitally signed message part
Bug#734922: apt-cache showsrc shows duplicate entries
On Sat, Jan 11, 2014 at 01:05:23AM +0530, Faheem Mitha wrote:
Package: apt
Version: 0.9.7.9+deb7u1
Severity: normal
Unlike, for example `apt-cache show` and `apt-cache policy`,
`apt-cache showsrc` shows duplicate entries. I can't see any good
reason for this inconsistency.
Attached is a possilbe fix, but there is some cleanup needed before
this can go in.
Cheers,
Michael
From 14042cb47e58bb64afefe67a0d83494191c11a7a Mon Sep 17 00:00:00 2001
From: Michael Vogt m...@debian.org
Date: Mon, 13 Jan 2014 17:35:54 +0100
Subject: [PATCH] do not show duplicated apt-cache showsrc entries
---
cmdline/apt-cache.cc | 23 +--
.../test-bug-734922-apt-showsrc-duplicate | 47 ++
2 files changed, 67 insertions(+), 3 deletions(-)
create mode 100755 test/integration/test-bug-734922-apt-showsrc-duplicate
diff --git a/cmdline/apt-cache.cc b/cmdline/apt-cache.cc
index b8892d2..58864b4 100644
--- a/cmdline/apt-cache.cc
+++ b/cmdline/apt-cache.cc
@@ -34,6 +34,7 @@
#include apt-pkg/pkgsystem.h
#include apt-pkg/indexfile.h
#include apt-pkg/metaindex.h
+#include apt-pkg/hashes.h
#include apt-private/private-list.h
#include apt-private/private-cmndline.h
@@ -1475,6 +1476,15 @@ bool ShowPkgNames(CommandLine CmdL)
return true;
}
/*}}}*/
+
+// FIXME: move to hashes.h: HashString::FromString()
+std::string Sha1FromString(std::string input)
+{
+ SHA1Summation sha1;
+ sha1.Add(input.c_str(), input.length());
+ return sha1.Result().Value();
+}
+
// ShowSrcPackage - Show source package records/*{{{*/
// -
/* */
@@ -1497,10 +1507,17 @@ bool ShowSrcPackage(CommandLine CmdL)
pkgSrcRecords::Parser *Parse;
unsigned found_this = 0;
+ // avoid showing idential records
+ std::setstd::string seen;
while ((Parse = SrcRecs.Find(*I,false)) != 0) {
-cout Parse-AsStr() endl;;
-found++;
-found_this++;
+ std::string sha1str = Sha1FromString(Parse-AsStr());
+ if (std::find(seen.begin(), seen.end(), sha1str) == seen.end())
+ {
+cout Parse-AsStr() endl;;
+found++;
+found_this++;
+seen.insert(sha1str);
+ }
}
if (found_this == 0) {
_error-Warning(_(Unable to locate package %s),*I);
diff --git a/test/integration/test-bug-734922-apt-showsrc-duplicate b/test/integration/test-bug-734922-apt-showsrc-duplicate
new file mode 100755
index 000..66db534
--- /dev/null
+++ b/test/integration/test-bug-734922-apt-showsrc-duplicate
@@ -0,0 +1,47 @@
+#!/bin/sh
+set -e
+
+TESTDIR=$(readlink -f $(dirname $0))
+. $TESTDIR/framework
+setupenvironment
+configarchitecture 'i386'
+
+# foo is identical, show it only once in showsrc
+insertpackage unstable foo i386 1.0
+insertpackage testing foo i386 1.0
+insertsource unstable foo i386 1.0
+insertsource testing foo i386 1.0
+
+# bar is different, show twice
+insertsource unstable bar i386 1.0
+insertsource testing bar i386 2.0
+
+setupaptarchive
+
+testequal Package: foo
+Binary: foo
+Version: 1.0
+Maintainer: Joe Sixpack j...@example.org
+Architecture: i386
+Files:
+ d41d8cd98f00b204e9800998ecf8427e 0 foo_1.0.dsc
+ d41d8cd98f00b204e9800998ecf8427e 0 foo_1.0.tar.gz
+
+Package: bar
+Binary: bar
+Version: 2.0
+Maintainer: Joe Sixpack j...@example.org
+Architecture: i386
+Files:
+ d41d8cd98f00b204e9800998ecf8427e 0 bar_2.0.dsc
+ d41d8cd98f00b204e9800998ecf8427e 0 bar_2.0.tar.gz
+
+Package: bar
+Binary: bar
+Version: 1.0
+Maintainer: Joe Sixpack j...@example.org
+Architecture: i386
+Files:
+ d41d8cd98f00b204e9800998ecf8427e 0 bar_1.0.dsc
+ d41d8cd98f00b204e9800998ecf8427e 0 bar_1.0.tar.gz
+ aptcache showsrc foo bar
\ No newline at end of file
--
1.8.3.2
Bug#730604: [Pkg-libvirt-maintainers] Bug#730604: libvirt-bin: Please rename libvirt-bin.service back to libvirtd.service and use symlink or Alias= instead
Le Tue, 14 Jan 2014 11:14:41 +0100, Guido Günther a...@sigxcpu.org a écrit : On Tue, Jan 14, 2014 at 10:08:58AM +0100, Laurent Bigonville wrote: [..snip..] I'm not sure what you mean here. I don't think any changes on the LSB initscript is required here. Renaming the .service file back to the original and adding a symlink that matches the name of the initscript should be enough. We'd e.g. still have /etc/default/libvirt-bin used to configure the libvirtd service. THe package will also still be named libvirt-bin so I wonder if it wouldn't be more consistent to leave the service file as and add a Alias=libvirtd I think it's a general good habit to keep the upstream file untouched. And I don't think that the alias in this case is good (Alias= is lost in case the service is disabled), a symlink will be needed anyway. so firewalld and others can reference it. I'm o.k. with renaming the whole package from libvirt-bin - libvirtd in the future including unit files and init scripts but that's nothing I have time for atm. Patches to achieve this (and especially testing) would be welcome. OK I'll add this to my todo list. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735275: [Pkg-systemd-maintainers] Bug#735275: libudev1: Keep libudev.so.0 as a link to libudev.so.1
Simon Pepping [2014-01-14 11:33 +0100]: A number of applications depend on libudev.so.0, e.g. Google Chrome. These applications solve the problem by creating a link libudev.so.0 - /lib/x86_64-linux-gnu/libudev.so.1. Many users are affected by such failures, and on the web there are many questions about the problem. It would be better if the package libudev1 installs such a link. No, that would be a dangerous hack. There is a reason why the soname got bumped, as libudev1 removed a few obsolete symbols. Surely they are not likely to be used, but if an application does, and it would link to libudev.so.1 thinking it was libudev.so.0 it would crash. For those third-party applications I suggest either bundling libudev.so.0 or providing a libudev0 package along with it. I'm not an authoritative maintainer of udev in Debian, but I suggest to wontfix this. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735277: wildmidi: Forked repo, a new release and an offer to help maintain the wildmidi package
Package: wildmidi Version: 0.2.3.4-2.1 Severity: wishlist Tags: upstream Dear Maintainer, In February 2012, Chris Ison, made a 0.2.3.5 release and the wildmidi package in Debian is still at 0.2.3.4 with a few bugs still unresolved and patches. The 0.2.3.5 release was the last release by Chris, he had just a few more commits in February and is stopped. His responses stop on Sourceforge, his commits, his twitter feed. All attempts to contact him have also failed. The queue of bugs and patches have been piling up as well. In attempt to fix bugs for myself, I decided to fork his SVN repo and have created a github repo with his commit history still intact here: https://github.com/psi29a/wildmidi Since then, there have been a number of contributors and patches have been poring in. We've gutted the autotools and replaced it with a cmake system. We're now able to cleanly, without warnings, build against latest GCC and Clang on Debian and Ubuntu. We even managed to get wildmidi to compile with Visual Studio 2010 and run. We're currently working on getting to running again on OSX. We're still ABI/API compatible, none of the symbols/exports have changed. You can drop this in and link against it without any code changes in other projects. We've also kept the door open for Chris' return and can give the git repo to him, or can join or stay where he is and just pull in our changes. That being said, we propose a switch from old upstream to the new upstream. I also would like to help with the package's maintenance in Debian. What can I do here to help. :) Cheers, Bret Curtis -- System Information: Debian Release: wheezy/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0-14-generic (SMP w/8 CPU cores) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735276: libmono-debugger-soft-cil has circular Depends on libmono-debugging-soft-cil
Package: libmono-debugger-soft-cil Version: 0+20131201.3459502-1 Severity: important Hello Jo, There is a circular dependency between libmono-debugger-soft-cil and libmono-debugging-soft-cil: libmono-debugger-soft-cil :Depends: libmono-debugging-soft-cil (= 0+20131201.3459502) libmono-debugging-soft-cil :Depends: libmono-debugger-soft-cil (= 0+20131201.3459502) Circular dependencies involving libraries are known to cause problems during upgrade between stable releases, so we should try to get rid of them. In this instance, both packages come from the same source, so they could be merged in a single package that would Provides both libmono-debugger-soft-cil and libmono-debugging-soft-cil. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
* Ian Campbell i...@hellion.org.uk [2014-01-13 14:53]: Apparently earlyprintk is enabled in our kirkwood kernels -- could you try adding earlyprintk to your kernel command line args please. It seems user Reardon has posted the output with earlyprintk (from a TS-41x) on the QNAP forum already: http://forum.qnap.com/viewtopic.php?f=147t=88948 (But Sylvain, it would be great if you could run with earlyprintk too to confirm the output). Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.12-1-kirkwood (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-1) ) #1 Debian 3.12.6-2 (2013-12-29) [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: QNAP TS-41x [0.00] Ignoring unrecognised tag 0x41000403 [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90 ramdisk=32768 earlyprintk [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 504652K/524288K available (3644K kernel code, 311K rwdata, 1280K rodata, 185K init, 412K bss, 19636K reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc04d73f0 (4925 kB) [0.00] .init : 0xc04d8000 - 0xc05067b4 ( 186 kB) [0.00] .data : 0xc0508000 - 0xc0555e80 ( 312 kB) [0.00].bss : 0xc0555e80 - 0xc05bd230 ( 413 kB) [0.00] NR_IRQS:114 [0.00] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms [0.00] Console: colour dummy device 80x30 It hangs right now, nothing more emitted. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
* Ian Campbell i...@hellion.org.uk [2014-01-13 14:53]: Apparently earlyprintk is enabled in our kirkwood kernels -- could you try adding earlyprintk to your kernel command line args please. Sylvain, I believe the right commands to issue in u-boot are: setenv bootargs console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90 ramdisk=32768 earlyprintk cp.b 0xf820 0x80 0x20 cp.b 0xf840 0xa0 0x90 bootm 0x80 -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733341: man pod blarg
* Barak A. Pearlmutter ba...@cs.nuim.ie, 2014-01-14, 09:33: Well dagnabit. So an i386 autobuilder is running an old pod2man or dependencies thereof. -.\ Automatically generated by Pod::Man 2.22 (Pod::Simple 3.07) +.\ Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28) I don't think the autobuilder was running an old pod2man. That would be a very old version of perl-modules, older than in wheezy. It's more likely that on i386 the manpages didn't get rebuilt from source, i.e. the pre-built ones from the source package are shipped. No idea why would that happen on one architecture but not on another. For completeness, amd64 appears to be the only architecture on which the manpages where rebuilt. For example, these are MD5 sums of /usr/share/man/man3/liboping.3.gz: 2888fbc87a50f8a4494ffbd003dadce9 on amd64; c3d41657a5c90753e51d099d1cd2d9f5 on i386, powerpc, armel, ... and everywhere else. Naturally the differences in the generated man pages are pretty trivial. I'm not sure if this is really Severity: important, assuming dpkg just installs one or the other for each file it doesn't make any real difference. Or does dpkg error out? That would be unfortunate. dpkg has no way of knowing whether the difference is real or not, so to be on the safe side, it errors out: Preparing to unpack .../liboping-dev_1.6.2-3_amd64.deb ... Unpacking liboping-dev:amd64 (1.6.2-3) ... Selecting previously unselected package liboping-dev:i386. Preparing to unpack .../liboping-dev_1.6.2-3_i386.deb ... Unpacking liboping-dev:i386 (1.6.2-3) ... dpkg: error processing archive /var/cache/apt/archives/liboping-dev_1.6.2-3_i386.deb (--unpack): trying to overwrite shared '/usr/share/man/man3/ping_send.3.gz', which is different from other instances of package liboping-dev:i386 -- 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#735272: closed by Chris Lamb la...@debian.org (Bug#735272: fixed in redis 2:2.8.4-1)
Hi Chris, thanks for the fast fix, but there are two things (and I can also blame myself for not realizing it earlier / not mentioning it in the bug report): - sentinel.conf should be shipped, too imho. - redis-sentinal is the same binary as redis-server, a symlink works well, too - I was somewhat stuck on old documentations which talked about the redis-sentinal binary. thanks, bernd -- Mit freundlichen Grüßen Bernd Zeimetz Systems Engineer Debian Developer conova communications GmbH Web| http://www.conova.com/ E-Mail | b.zeim...@conova.com Zentrale Salzburg Karolingerstraße 36A 5020 Salzburg Tel | +43 (0) 662 22 00 - 313 Fax | +43 (0) 662 22 00 - 209 Es gelten die Allgemeinen Geschäftsbedingungen der conova communications GmbH, http://www.conova.com/de/agb/ smime.p7s Description: S/MIME cryptographic signature
Bug#726578: Ping: pwgen: Multiple vulnerabilities in passwords generation
Thank you for reacting quickly!
begin quotation from Theodore Ts'o (in 20140112234500.ga15...@thunk.org):
On Sun, Jan 12, 2014 at 09:27:14PM +0100, Arne Wichmann wrote:
This grave problem is now open for more than two months. Is there any plan
to resolve this?
First, the CVE about having the unavailability of /dev/random fail
hard -- sure, that should be a separate bug since that's a fix that I
think is reasonable at this point. We can now guarantee that
/dev/random exists everywhere. (And by that same token, if an
attacker can cause /dev/random not to be present, they probably have
root, so you're probably toast anyway. So I don't think it's going to
really improve things to remove the drand() fallback, but I don't have
strong feelings about that.)
So you might clone a new bug for this...
Secondly, I'll note that one of the CVE's were rejected as not a
vulnerability. (In general it would have been better to have opened
seperate bugs for each CVE.)
Different maintainers have different preferences here - I will note that
you want seperate bugs (as we do for a number of other packages).
Finally, whether you think the other two CVE's justify this to be
serious, let alone grave bug really depends on what you think the
goals of pwgen are. To quote from the manual page:
This is your decision - we try to use a fitting severity for every problem,
but sometimes the cases are not so clear.
The pwgen program generates passwords which are designed to be easily
memorized by humans, while being as secure as possible. Human-memo???
rable passwords are never going to be as secure as completely com???
pletely random passwords. In particular, passwords generated by pwgen
without the -s option should not be used in places where the password
could be attacked via an off-line brute-force attack.On the other
hand, completely randomly generated passwords have a tendency to be
written down, and are subject to being compromised in that fashion.
So we could change the defaults to be pwgen -csy 20, in which case
you would get passwords like tihs:
L}U@lc_~i^n|ro!4uI- 1`;yXlYVMW%?E9)3A7G **}6BoBu=!~3)y?3v]Or
=:PC;H?E7*+6$c-QH URGgjUNG[\dSw\p7F-] _AXZ~(HYd8Q#%b!]'u:
~)0I-{)}_Ya*Q2nlWN; ^#t~1/'sf@*xz9GOhBuv e_[-_Fe{CD#]DY8@M^a
I'm not sure that would be an improvement, as simply no one would use
them.
OK, how about this? (Generated using pwgen -s).
vQ6uwkMk lSswO2MB tA8dYPpl KU1pQ2Xh 2XfxRyrC Za2xKx7h psPwHZ0c dOsC0JBX
JY3udA9c t6LzoiUq M0jR3AoS GOHkNE7G TeThsZz1 6cVi4ayY Poe4hPj7 o2a7OpPC
Xh24cRLO 1chQyseV 6c2k0O3B OkdgRxy4 K6Vc4JY2 ylO3IE9B gVvNxw6B 7wjcOXwF
Again, this will make the professional paranoids happy (although
perhaps not as happy as =:PC;H?E7*+6$c-QH), but its not clear that
real users would be any less likely to write ylO3IE9B on a sticky
note which is pasted to their monitor, or just in a passwords file
in their home directory.
I do not have a really good idea on how to handle this. Some ideas come to
mind, mostly inspired by [1]:
- Improve the algorithm to be less biased. Though I see that would not be
easy.
- Warn about the bias
- Use -s as default
[2] suggests, that there is a patch out there, but I have not yet looked at
it.
So ultimately, a lot of this is about an argument over defaults, and I
think the higher level problem is that no matter what password policy
you use, passwords are doomed as a technology. Anything which is
secure against a brute force attack is impossible for a user to use,
unless they share passwords across multiple sites so they only have to
remember one password such as ylO3IE9B --- at which point they get
toast once some web site screws up in some way and gets penetrated by
bad guys.
I see the point, but that does not make the problem go away, and in many
cases you do not have so much of a choice, so the program does still have
its points.
CVE-2013-4440 has an easy fix, isn't it?
[1] http://www.openwall.com/lists/oss-security/2012/01/19/24
[2] http://marc.info/?l=oss-securitym=138015793928431w=2
cu
AW
--
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (a...@linux.de)
signature.asc
Description: Digital signature
Bug#732008: Problem reappeared with 1.8.9p3-1
I have the same issue but I don't use systemd. Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
Hello (But Sylvain, it would be great if you could run with earlyprintk too to confirm the output). I will try to do this tonight. One question though: from a test point of view, do you agree that booting from a 3.12 or 3.13 kernel sent over tftp (and I assume pushed to RAM, seeing how fast it goes) is equivalent to have it flashed (a several minutes process)? I only tried the flashed way so far, but I'd rather go the tftp way if it's ok, to be a reboot away from a functional system. Thanks -- Sylvain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726466: [Pkg-systemd-maintainers] Bug#726466: libsystemd-login0: while logging in to tty6 got Failed to issue method call.
Hello Michael, 2013-12-21, 18:59 (+0100); Michael Stapelberg escriu: I’ve addressed this in commit http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=85582c5 I can confirm that it's fixed now. I can no longer reproduce with libsystemd-login0 204-6. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735278: Lsof is needed by checkrestart but it's tagged as 'recommends'
Package: debian-goodiesVersion: 0.61 If installing recommended packages is disabled checkrestart won't work because it depends on lsof http://packages.debian.org/wheezy/lsof which is tagged to debian-goodies as recommended package. Here is the output from checkrestart: $ checkrestartERROR: This program needs lsof in order to run.Please install the lsof package in your system.$ I believe lsof should be moved to be as 'depends' because of this. I am using 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64
Bug#735279: gnome-session-flashback: Screen does not redraw when resizing or moving application windows
Package: gnome-session-flashback Version: 3.8.0-1 Severity: important Dear Maintainer, When moving or resizing a window, the screen is incorrectly updated. The contours of the window stay frozen on the screen, making working under this graphic environment impossible. Switching to a different desktop keeps the images of the initial desktop on the screen. I think it is identic or related to bug #708279 It is found that under the 'new' Gnome shell this behaviour does not occur. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-session-flashback depends on: ii gnome-panel 3.8.0-1 ii gnome-screensaver 3.6.1-1 ii gnome-session-bin 3.8.4-3 ii gnome-session-common3.8.4-3 ii gnome-settings-daemon 3.8.5-2 ii metacity1:2.34.13-1 ii nautilus3.8.2-2 ii notification-daemon 0.7.6-1 ii plasma-widgets-workspace [notification-daemon] 4:4.11.3-3 ii policykit-1-gnome 0.105-2 Versions of packages gnome-session-flashback recommends: ii gnome-power-manager 3.8.2-1 Versions of packages gnome-session-flashback suggests: ii desktop-base 7.0.3 ii gnome-keyring 3.8.2-2 ii gnome-user-guide 3.8.2-1 -- 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#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
* Sylvain LÉVÊQUE sylvain.leve...@gmail.com [2014-01-14 12:13]: (But Sylvain, it would be great if you could run with earlyprintk too to confirm the output). I will try to do this tonight. One question though: from a test point of view, do you agree that booting from a 3.12 or 3.13 kernel sent over tftp (and I assume pushed to RAM, seeing how fast it goes) is equivalent to have it flashed (a several minutes process)? Yes. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735280: mount(8) refers package smbfs which is no longer present in sid
Package: mount Version: 2.20.1-5.5 Severity: minor Dear Maintainer, the manpage mount(8) refers to mount.cifs(8) which is located in the package smbfs according to the manual page, however smbfs is no longer present in Debian unstable and both mount.cifs and mount.cifs(8) can now be found in the package cifs-utils instead. The source package util-linux can be corrected by the following patch: --- mount/mount.8.orig 2014-01-14 11:16:02.0 +0100 +++ mount/mount.8 2014-01-14 11:18:41.938413304 +0100 @@ -1128,7 +1128,7 @@ .SH Mount options for cifs See the options section of the .BR mount.cifs (8) -man page (smbfs package must be installed). +man page (cifs-utils package must be installed). .SH Mount options for coherent None. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=eo.UTF-8, LC_CTYPE=eo.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mount depends on: ii libblkid12.20.1-5.5 ii libc62.17-97 ii libmount12.20.1-5.5 ii libselinux1 2.2.2-1 ii libsepol12.2-1 mount recommends no packages. Versions of packages mount suggests: pn nfs-common none -- 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#735270: package build with SSE2 defaults on i386
On Tue, Jan 14, 2014 at 11:36:08AM +0100, Matthias Klose wrote: I don't think reverse depends will FTBFS. The problem is that the tests (which are only run at build time and are not in any way included in the binary packages) unconditionally #include emmintr.h. Could you try removing those #includes from glm-0.9.5.0/test/gtx/*.cpp, and try building again? I don't think this would be the correct fix, because the include machinery provides several FORCE macros to support those targets as well. The #include emmintrin.h does not #define any macro that changes the behaviour in GLM. In fact, GLM itself checks for the presence of __SSE2__ and automatically #includes emmintrin.h if possible. Also, GLM version 0.9.4.6 did not #include emmintrin.h in its tests, and only a few tests have the #include, I think it is just an oversight from the upstream maintainer. Please check with a i386 chroot. An i386 chroot won't do me any good as I only have processors that support SSE2. It would be helpful if you could test the patch which I attached to this email on your i386 system. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org --- a/test/gtx/gtx_associated_min_max.cpp +++ b/test/gtx/gtx_associated_min_max.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/associated_min_max.hpp --- a/test/gtx/gtx_bit.cpp +++ b/test/gtx/gtx_bit.cpp @@ -7,8 +7,6 @@ // File: test/gtx/bit.cpp /// -#include emmintrin.h - #include glm/gtx/bit.hpp #include glm/gtc/type_precision.hpp --- a/test/gtx/gtx_closest_point.cpp +++ b/test/gtx/gtx_closest_point.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/associated_min_max.hpp --- a/test/gtx/gtx_color_space.cpp +++ b/test/gtx/gtx_color_space.cpp @@ -7,8 +7,6 @@ // File: test/gtx/color_space.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/color_space.hpp --- a/test/gtx/gtx_color_space_YCoCg.cpp +++ b/test/gtx/gtx_color_space_YCoCg.cpp @@ -7,8 +7,6 @@ // File: test/gtx/color_space_YCoCg.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/color_space_YCoCg.hpp --- a/test/gtx/gtx_component_wise.cpp +++ b/test/gtx/gtx_component_wise.cpp @@ -7,8 +7,6 @@ // File: test/gtx/component_wise.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/component_wise.hpp --- a/test/gtx/gtx_extented_min_max.cpp +++ b/test/gtx/gtx_extented_min_max.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/associated_min_max.hpp --- a/test/gtx/gtx_int_10_10_10_2.cpp +++ b/test/gtx/gtx_int_10_10_10_2.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/associated_min_max.hpp --- a/test/gtx/gtx_mixed_product.cpp +++ b/test/gtx/gtx_mixed_product.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include emmintrin.h - #include glm/glm.hpp #include glm/gtc/type_precision.hpp #include glm/gtx/associated_min_max.hpp signature.asc Description: Digital signature
Bug#735281: missing license in debian/coypright
Package: geoclue-2.0 Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, some documentation, for example geoclue-2.0.0\docs\geoclue-docs.xml is licensed under GFDLv1.1+. Please add this to debian/copyright. Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735282: midori: First character of text input not submitted by form
Package: midori Version: 0.4.3+dfsg-0.1 Severity: important Dear Maintainer, * What led up to the situation? Inputting a series of digits into an input type=text field, grabbing the field's contents via jQuery and then making an Ajax request succeeds other than the first digit of the text field _not_ being passed as part of the request. The same operation works correctly on Chrome and Firefox. * What exactly did you do (or not do) that was effective (or ineffective)? Nothing besides switch to alternative Webkit browsers. * What was the outcome of this action? Fully functional in Chrome and Firefox - the correct values are passed. * What outcome did you expect instead? Values not getting mangled. -- System Information: Debian Release: 7.1 Architecture: armhf (armv6l) Kernel: Linux 3.6.11+ (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages midori depends on: ii dbus-x111.6.8-1+deb7u1 ii libc6 2.13-38+rpi2 ii libcairo2 1.12.2-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libjavascriptcoregtk-1.0-0 1.8.1-3.4+rpi1 ii libnotify4 0.7.5-1 ii libpango1.0-0 1.30.0-1 ii libsoup2.4-12.38.1-2 ii libsqlite3-03.7.13-1+deb7u1 ii libunique-1.0-0 1.1.6-4 ii libwebkitgtk-1.0-0 1.8.1-3.4+rpi1 ii libx11-62:1.5.0-1+deb7u1+wheezy ii libxml2 2.8.0+dfsg1-7+nmu1 ii libxss1 1:1.2.2-1 Versions of packages midori recommends: ii gnome-icon-theme 3.4.0-2 midori suggests no packages. -- Configuration Files: /etc/xdg/midori/search changed: [Duck Duck Go] name=Duck Duck Go text=Privacy-aware Web Search uri=https://duckduckgo.com/?q=%st=raspberrypi token=dd [Yahoo] name=Yahoo text=Yahoo Web Search uri=http://search.yahoo.com/search?p= token=y [Google] name=Google text=Web Search uri=http://www.google.com/search?q=%s token=g [Wikipedia] name=Wikipedia text=The free encyclopedia uri=http://en.wikipedia.org/wiki/Special:Search/%s token=wp [TheFreeDictionary] name=The Free Dictionary text=Dictionary, Encyclopedia and Thesaurus uri=http://www.thefreedictionary.com/%s token=fd [Debian Packages] name=Debian Packages text=Search Debian Packages uri=http://packages.debian.org/%s icon= token=d [Debian Bugs] name=Debian Bugs text=Debian Bugs Search uri=http://bugs.debian.org/%s icon= token=dbs -- 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#735270: package build with SSE2 defaults on i386
Am 14.01.2014 12:41, schrieb Guus Sliepen: Please check with a i386 chroot. An i386 chroot won't do me any good as I only have processors that support SSE2. It would be helpful if you could test the patch which I attached to this email on your i386 system. this is a misunderstanding. The compiler doesn't define these on macros by itself. it defaults to i586. So yes, a test in an i386 chroot does help. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735270: package build with SSE2 defaults on i386
On Tue, Jan 14, 2014 at 01:01:25PM +0100, Matthias Klose wrote: An i386 chroot won't do me any good as I only have processors that support SSE2. It would be helpful if you could test the patch which I attached to this email on your i386 system. this is a misunderstanding. The compiler doesn't define these on macros by itself. it defaults to i586. So yes, a test in an i386 chroot does help. Ugh, I should have known that. I'll test it. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Bug#668890: This bug should be solved the most correct way IMO
Package: dirmngr Version: 1.1.1-1.1 Tags: patch Hi, thanks for the NMU; nonetheless, I believe the root cause of the issue shouldn't be worked around. The use of su in dirmngr init script is causing further troubles [1] and I believe that the cleanest solution, which I found to fix the mentioned issues, would be using start-stop-daemon directly, as Thorsten recommended in message #33: --- dirmngr.old 2014-01-14 13:01:12.235277583 +0100 +++ dirmngr.new 2014-01-14 13:01:24.791269629 +0100 @@ -32,7 +32,7 @@ mkdir -p /var/run/dirmngr || return 1 chown dirmngr:dirmngr /var/run/dirmngr || return 1 - output=$(su -c . /lib/lsb/init-functions umask 027 start_daemon -p $PIDFILE $DAEMON --daemon --sh dirmngr) || return 1 + output=$(start-stop-daemon --start --quiet --exec $DAEMON --oknodo --pidfile $PIDFILE --umask 027 --chuid dirmngr -- --daemon --sh) || return 1 eval $output || return 1 pid=$(echo $DIRMNGR_INFO | cut -d : -f 2) || return 1 echo $pid $PIDFILE || return 1 Please consider applying this patch. Thanks, Maurizio [1]: - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727645 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717554 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717731 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735283: virt-manager: cannot create disk when cretaing a VM
Package: virt-manager Version: 0.9.5-1 Severity: important Hello, I tried to create a VM and when i get to creating disk it says I don't have enough disk space to create a 33G disk. I have 70G on one disk and 50G on another so I certainly do have enough space. However, the disk is created in unknown location and there is no way to select where the disk is created. -- System Information: Debian Release: 7.3 APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (500, 'testing'), (410, 'unstable'), (400, 'experimental'), (300, 'saucy-updates'), (300, 'saucy-security'), (300, 'saucy-proposed'), (300, 'saucy-backports'), (300, 'saucy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-rc6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages virt-manager depends on: ii gconf2 3.2.5-1+build1 ii librsvg2-common2.36.1-2 ii python 2.7.5-5 ii python-dbus1.1.1-1 ii python-glade2 2.24.0-3+b1 ii python-gnome2 2.28.1+dfsg-1 ii python-gtk-vnc 0.5.2-2 ii python-gtk22.24.0-3+b1 ii python-ipy 1:0.75-1 ii python-libvirt 1.2.0-2 ii python-support 1.0.15 ii python-urlgrabber 3.9.1-4 ii python-vte 1:0.28.2-5 ii virtinst 0.600.4-2 Versions of packages virt-manager recommends: ii gnome-icon-theme 3.4.0-2 ii libvirt-bin 1.2.0-2 ii python-spice-client-gtk 0.21-0nocelt3 Versions of packages virt-manager suggests: pn gnome-keyringnone pn python-gnomekeyring none pn python-guestfs none pn ssh-askpass none ii virt-viewer 0.5.6-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#506861: xz support for python-debian
forcemerge 506861 735267 severity 735267 important thanks Hi Neil and python-debian maintainers, Neil: your simple patch stops debfile from crashing when it sees xz compressed packages but doesn't permit debfile to work with these files. A patch for this has now existed in the bts for a while now. I've been very much hoping that someone would look over this patch and provide some feedback on it and/or merge it. Perhaps, at this stage, we should just upload it and deal with any bugs. Perhaps I've not made it clear enough in the past, but I am quite willing to help out with python-debian maintenance. I would, however, be happier if there were some code review of contributions. So, python-debian maintainers, any thoughts here? A review of this patch perhaps? Should I NMU python-debian with this patch? How about the others in the bts? Should I add myself to Uploaders while I'm at it? cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 signature.asc Description: This is a digitally signed message part.
Bug#735198: virt-manager: cannot show disk in VM settings
Package: virt-manager Version: 0.9.5-1 Followup-For: Bug #735198 This only happens if you choose the checkbox which says something like 'edit machine details before installation'. Once the machine is 'installed' showing its details works fine. -- System Information: Debian Release: 7.3 APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (500, 'testing'), (410, 'unstable'), (400, 'experimental'), (300, 'saucy-updates'), (300, 'saucy-security'), (300, 'saucy-proposed'), (300, 'saucy-backports'), (300, 'saucy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-rc6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages virt-manager depends on: ii gconf2 3.2.5-1+build1 ii librsvg2-common2.36.1-2 ii python 2.7.5-5 ii python-dbus1.1.1-1 ii python-glade2 2.24.0-3+b1 ii python-gnome2 2.28.1+dfsg-1 ii python-gtk-vnc 0.5.2-2 ii python-gtk22.24.0-3+b1 ii python-ipy 1:0.75-1 ii python-libvirt 1.2.0-2 ii python-support 1.0.15 ii python-urlgrabber 3.9.1-4 ii python-vte 1:0.28.2-5 ii virtinst 0.600.4-2 Versions of packages virt-manager recommends: ii gnome-icon-theme 3.4.0-2 ii libvirt-bin 1.2.0-2 ii python-spice-client-gtk 0.21-0nocelt3 Versions of packages virt-manager suggests: pn gnome-keyringnone pn python-gnomekeyring none pn python-guestfs none pn ssh-askpass none ii virt-viewer 0.5.6-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#684009: isc-dhcp-client: dhclient must not assume a IPv6 prefix length of 64 when setting an address
Note that dhclient does not itself configures the interface but instead
calls the shellscript /sbin/dhclient-script to do the work. So a quick
workaround is to patch that script to use a fixed netmask of /128
(patch attached).
The real fix is to hand a fixed /128 netmask to the dhclient-script from
the daemon. This patches C-code in dhclient (patch attached).
Note that the dhcpv6 protocol doesn't have an option for a netmask. So
it is always /128 and routing is left to icmpv6 router advertisements.
That also means that the option accept_ra of the dhcp method for the
INET6 address family in /etc/network/interfaces (see interfaces(5) man
page) probably should be on by default or completely removed. In
addition maybe a fixed netmask should be configurable (see excerpts from
RFC5942 below).
Just some more facts regarding this issue:
RFC 5942 is very clear about a DHCP client inventing a prefix:
RFC5942, p.7 under Host Rules:
1. The assignment of an IPv6 address -- whether through IPv6
stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
or manual configuration -- MUST NOT implicitly cause a prefix
derived from that address to be treated as on-link and added to
the Prefix List. ...
and on p.8 under the heading Observed Incorrect Implementation Behavior:
... An address
could be acquired through the DHCPv6 identity association for non-
temporary addresses (IA_NA) option from [RFC3315] (which does not
include a prefix length), or through manual configuration (if no
prefix length is specified). The host incorrectly assumes an
invented prefix is on-link. This invented prefix typically is a /64
that was written by the developer of the operating system network
module API to any IPv6 application as a default prefix length when
a length isn't specified...
I sincerely hope this gets fixed in the next release of dhcpd. Note that
I've also filed an upstream report with issue number #35178 (before I
knew about this debian report) and I'm surprised the currently scheduled
4.3.0a1 release doesn't yet have the fix.
Ralf
--
Ralf Schlatterbeck email: r...@zoo.priv.at
--- /sbin/dhclient-script.orig 2013-05-27 23:00:32.0 +0200
+++ /sbin/dhclient-script 2014-01-10 17:08:13.0 +0100
@@ -344,9 +344,9 @@
;;
BOUND6|RENEW6|REBIND6)
-if [ ${new_ip6_address} ] [ ${new_ip6_prefixlen} ]; then
+if [ ${new_ip6_address} ]; then
# set leased IP
-ip -6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \
+ip -6 addr add ${new_ip6_address}/128 \
dev ${interface} scope global
fi
--- client/dhc6.c.orig 2014-01-14 13:18:41.0 +0100
+++ client/dhc6.c 2014-01-14 13:19:06.0 +0100
@@ -3841,11 +3841,8 @@
piaddr(addr-address),
(unsigned) addr-plen);
} else {
- /* Current practice is that all subnets are /64's, but
- * some suspect this may not be permanent.
- */
client_envadd(client, prefix, ip6_prefixlen,
- %d, 64);
+ %d, 128);
client_envadd(client, prefix, ip6_address,
%s, piaddr(addr-address));
}
Bug#735272: closed by Chris Lamb la...@debian.org (Bug#735272: fixed in redis 2:2.8.4-1)
Hi Bernd, thanks for the fast fix, but there are two things (and I can also blame myself for not realizing it earlier / not mentioning it in the bug report): D'oh :) My fault too for not looking in more detail - I assumed it was just another redis-blah binary. Just uploading now. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734922: apt-cache showsrc shows duplicate entries
On Tue, 14 Jan 2014, Michael Vogt wrote: On Sat, Jan 11, 2014 at 01:05:23AM +0530, Faheem Mitha wrote: Package: apt Version: 0.9.7.9+deb7u1 Severity: normal Unlike, for example `apt-cache show` and `apt-cache policy`, `apt-cache showsrc` shows duplicate entries. I can't see any good reason for this inconsistency. Attached is a possilbe fix, but there is some cleanup needed before this can go in. In this line, idential should be identical. + // avoid showing idential records Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735284: MariaDB-5.5: [INTL:ja] New Japanese translation
Package: MariaDB-5.5 Version: 5.5.32-1 Severity: wishlist Tags: patch l10n Dear MariaDB-5.5 package maintainer, Here's Japanese po-debconf template translation (ja.po) file that reviewed by several Japanese Debian developers and users. Could you apply it, please? -- victory http://userscripts.org/scripts/show/102724 0.0.1.4 http://userscripts.org/scripts/show/163846 0.0.1 http://userscripts.org/scripts/show/163848 0.0.1 mariadb-5.5_5.5.32-1_ja.po.gz Description: Binary data
Bug#734611: RFS: libfixbuf/1.4.0 ITP -- Implementation of the IPFIX protocol
Hi, Quoting Wookey (2014-01-14 01:59:22) +++ Johannes Schauer [2014-01-08 15:41 +0100]: I am looking for a sponsor for my package libfixbuf: OK. Looks sound to me. thanks for looking at it! A couple of minor points: You might want to include a watch file for new upstream releases. I indeed wanted to but the website which offers the releases hides the correct url behind a JavaScript. It took me a while to find out that I had to enable JavaScript to be able to click on their links. Because of that it would be necessary for uscan to parse a JavaScript file. I did not find to out how to do this with uscan or if it is even possible at all. The default seems to just be searching for a href= tag values which does not work here because the a href= is generated by JavaScript. Should you do something with the included pyfixbuf-0.1.tar.gz, like drop it or add a python package?. It's mostly wasting 400K of space. I guess currently you have a pristine upstream tarball - it just happens to have another dollop of software somewhat unhelpfully included, and not in a format conducive to bulding from it. I guess that's fair enough. I forgot to remove that tarball from the upstream orig.tar.gz before my upload to mentors.debian.net. I solved the debian/watch issue when I noticed that apart from the download links, there are also links to the individual h1 headers on that website which include the version number. The resulting debian/watch file is a bit cryptic but seems to work. I also added debian/repack.sh to debian/watch debian/repack.sh repacks the upstream tarball, removing the tarball with the python bindings and some pre-generated documentation. I added a debian/README.source to explain the changes. The new version is on mentors as 1.4.0+ds-1 http://mentors.debian.net/debian/pool/main/libf/libfixbuf/libfixbuf_1.4.0+ds-1.dsc Thanks! cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732008: massive CPU hog as of late
Now this broken version is in unstable too. It keeps looping on poll() to read from socketpair status fd from child; the child closes its side when exec()ing the actual command to run, so the socket is readable due to EOF. There seems to no code whatsoever to stop further reading attempts at EOF (even though the code even logs EOF status)... The triggering change was probably this: Use SOCK_STREAM for socketpair, not SOCK_DGRAM so we get consistent semantics when the other end closes. This should make the conversion to poll() less problematic. SOCK_DGRAM probably didn't signal EOF when the other side closes, while SOCK_STREAM does. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735268: xemacs21: circular dependency hell
severity 735268 wishlist kthxbye On Tue, Jan 14, 2014 at 10:59:43AM +0100, Bill Allombert wrote: Complex circular dependencies are known to cause problems during upgrade, so we should try to get rid of them. On the other hand we've managed to survive for quite a few releases with this; it's a straightforward set of leaf packages after all. signature.asc Description: Digital signature
Bug#735285: nlkt: please add a desktop menu file
Package: nlkt Version: 0.3.2.2-1 Severity: wishlist It would be great if your package could include a FreeDesktop-style menu entry, so that it appears in the menus of GNOME, KDE and XFCE. Their format is described in the _Desktop Entry Specification_ at http://standards.freedesktop.org/desktop-entry-spec/latest/ (Complementary information can be found in the _Desktop Menu Specification_ at http://standards.freedesktop.org/menu-spec/latest/.) Essentially, all that is required is installing a file /usr/share/applications/nlkt.desktop which contains something like the following: [Desktop Entry] Version=1.0 Type=Application Name=nlkt Comment=Non-linear keyboard trainer (touch-typing tutor) # Comment[de]=Ein ... # Icon=nlkt-icon.pmg Exec=/usr/bin/nlkt Terminal=false Categories=Education; Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734476: mozilla-devscripts: tool to convert Version History pages to changelogs
* Benjamin Drung bdr...@debian.org, 2014-01-08, 00:31: Do you want to join the team? I'm not a team player, and I'm allergic to git, so no, not really. -- 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#735286: [rc-alert] output is not deterministic
Package: devscripts Version: 2.13.9 Severity: minor Order of flags in the rc-alert output is not deterministic: $ rc-alert libgcrypt11 rc1 $ rc-alert libgcrypt11 rc2 $ diff -u rc1 rc2 --- rc1 2014-01-14 13:51:43.560730335 +0100 +++ rc2 2014-01-14 13:53:09.316730335 +0100 @@ -1,6 +1,6 @@ Package: libgcrypt11 Bug: 368297 Title: sudo-ldap failes when you change uri to ldaps -Flags: [ +H ] (patch, help [wanted]) +Flags: [ +H ] (help [wanted], patch) Dists: [STU] (stable, testing, unstable) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages devscripts depends on: ii dpkg-dev 1.17.5 ii libc62.18-0experimental1 ii perl 5.18.1-5 ii python3 3.3.2-17 -- 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#735049: nvidia-support: Debconf prompts are misleading for NVIDIA Optimus users
On Sun, Jan 12, 2014 at 4:15 AM, Andreas Beckmann a...@debian.org wrote: On 2014-01-12 11:56, Vincent Cheng wrote: Installing bumblebee-nvidia (for optimus support) also pulls in the proprietary nvidia packages, along with nvidia-support; during the installation process, the user will see a debconf prompt saying that a xorg.conf snippet must be used to enable the nvidia driver (nvidia-support/create-nvidia-conf), which does not apply for nvidia optimus users and will break glx on the user's main display if the user blindly follows those debconf prompts. Aren't there three ways to run such a system: * in Intel mode (no non-free driver installed, no promts shown) * in Nvidia mode (only NVIDIA gpu, needs xorg.conf adjustment) * in Bumblebee mode (no xorg.conf adjustment needed) So this should be restricted to the bumblebee case, shouldn't it? Yes, although mux-less optimus laptops are by far the more common scenario, so option 2 is unavailable for many users, and we don't particularly care about option 1 since the user wouldn't install the nvidia packages in that case. + Ignore this message if you have a laptop with NVIDIA Optimus technology + (dual Intel and NVIDIA GPUs). Or can we somehow detect Optimus systems and show an entirely different template there? Ack, probably a better idea than just assuming the user knows how to determine if their laptop uses optimus or not. How Canonical does this in their nvidia-prime package can be found at [1], which requires nothing more than lspci (not sure if we can just assume pciutils is available). I guess we could check for optimus systems in a similar manner somewhere in postinst, and then just avoid triggering the nvidia-support/create-nvidia-conf template? (First email ever using my @debian.org address, yippee! ;) Regards, Vincent [1] https://github.com/tseliot/nvidia-prime/blob/master/prime-supported -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732008: massive CPU hog as of late
Package: sudo Version: 1.8.9p3-1 Followup-For: Bug #732008 I’ve just noticed the same problem (mostly because, on my four-core workstation at $dayjob, a “sudo xz -9” made IceWM’s CPU monitor go up by half instead of quarter) but cannot say since when it happens. Both “sudo su -” and “sudo sleep 300” also hog an entire CPU core. I am not, and never will be, running systemd. Running just “su -”, with root password, does not exhibit this problem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages sudo depends on: ii libc6 2.17-97 ii libpam-modules 1.1.3-11 ii libpam0g1.1.3-11 ii libselinux1 2.2.2-1 sudo recommends no packages. sudo suggests no packages. -- Configuration Files: /etc/sudoers [Errno 13] Permission denied: u'/etc/sudoers' /etc/sudoers.d/README [Errno 13] Permission denied: u'/etc/sudoers.d/README' -- 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#550410: Bug#732520: abinit: New upstream version, package unmaintained
Hi Ondrej, as I said below I'd consider uploading abinit as is in SVN to get it at least from a Debian packaging point of view fixed even if it is outdated. If I do not hear from you I will close #550410 by removing you from Uploaders. In case this will happen you are perfectly welcome to add your ID again for further upgrades of the package and as I repeatedly said I would be happy to sponsor your work. Kind regards Andreas. On Wed, Jan 08, 2014 at 03:53:02PM +0100, Andreas Tille wrote: Hi Daniel, On Tue, Jan 07, 2014 at 01:08:39PM +0100, Daniel Leidert wrote: IMO you better start with the most recent version. It seems to not have the previous DFSG-related issues (the whole orig-tarball target in debian/rules seems to be obsolete!). I agree that the latest version makes way more sense. However Ondrej said in response to my initial mail that he would consider working on this task which might need some more detailed knowledge about abinit than I have (mine is defintely none). My intention was to bring some totally broken package to some recent standard which is now reached in SVN to some extent. At least the package builds reasonably, is conform with latest Standards-Version and uses the latest packaging tools (debhelper 9; dh). I took a quick look into the source and there isnbsp;no need to run dh_autoreconf. ... Fixed in SVN. Further if abinit 5.x does not have more buildd related issues atm, there is IMHO no sense in rewriting the build system for this version. Better start with abinit 7 then. Since the package now rebuilds the binary packages currently inside the archive and contains less bugs and less lintian warnings I'd like to upload it as is now. The only thing I would like to know from Ondrej is, how to deal with #550410. ;-) I would be available for sponsering newer versions of abinit if a sponsor is needed. Kind regards Andreas. -- http://fam-tille.de ___ Debichem-devel mailing list debichem-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670147: Status of this bug?
Following up on this again: any chance of applying the patch that upstream already has, or otherwise updating to include this functionality? Thanks, 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#735275: [Pkg-systemd-maintainers] Bug#735275: libudev1: Keep libudev.so.0 as a link to libudev.so.1
Am 14.01.2014 14:03, schrieb Michael Biebl: Am 14.01.2014 11:44, schrieb Martin Pitt: Simon Pepping [2014-01-14 11:33 +0100]: A number of applications depend on libudev.so.0, e.g. Google Chrome. These applications solve the problem by creating a link libudev.so.0 - /lib/x86_64-linux-gnu/libudev.so.1. Many users are affected by such failures, and on the web there are many questions about the problem. It would be better if the package libudev1 installs such a link. No, that would be a dangerous hack. There is a reason why the soname got bumped, as libudev1 removed a few obsolete symbols. Surely they are not likely to be used, but if an application does, and it would link to libudev.so.1 thinking it was libudev.so.0 it would crash. Oh right. Shipping a symlink is certainly not the right way to address that. Have a look at [1] to see what damage such a symlink can have. For those third-party applications I suggest either bundling libudev.so.0 or providing a libudev0 package along with it. Or tell upstream to dlopen libudev if they want one binary to work with both versions. That would be an option. Or notifying upstream to build against libudev1 If the package (chrome in your case) was built for wheezy and you install it on sid/testing, you might install the libudev0 package from wheezy [1]. That package should be co-installable with libudev1. Btw, please file a upstream bug for Chrome Browser. It should *not* create such a symlink in postinst. [1] http://packages.debian.org/wheezy/libudev0 -- 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#735287: logcheck: invent conditional logging
Package: logcheck Version: 1.3.15 Severity: wishlist Hi... There is one thing I would like to have in logcheck for quite a long time already: Invent a mechanism by which a pattern is only mailed (or not mailed) if another pattern was seen a given time before it (or also possibly after it). For example I would like to make reboots invisible on some machines, but I do want to see it if the sshd terminates as long as the machine is not rebooting. cu AW -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (40, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.6 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages logcheck depends on: ii adduser3.113+nmu3 ii cron 3.0pl1-124 ii exim4-daemon-light [mail-transport-agent] 4.82-3 ii lockfile-progs 0.1.17 ii logtail1.3.15 pn mime-construct none ii rsyslog [system-log-daemon]7.4.4-1 Versions of packages logcheck recommends: ii logcheck-database 1.3.15 Versions of packages logcheck suggests: pn syslog-summary none -- Configuration Files: /etc/logcheck/logcheck.conf changed [not included] /etc/logcheck/logcheck.logfiles [Errno 13] Permission denied: u'/etc/logcheck/logcheck.logfiles' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684009: isc-dhcp-client: dhclient must not assume a IPv6 prefix length of 64 when setting an address
Hello,
Note that dhclient does not itself configures the interface but instead
calls the shellscript /sbin/dhclient-script to do the work. So a quick
workaround is to patch that script to use a fixed netmask of /128
(patch attached).
I did not see anything new in your patches, the patch of Arne Nordmark
already includes your changes (and some others, covering more cases).
Second, the /128 of ${new_ip6_address}/128 can probably be removed. An
address without prefix is set to /128 by default.
Regards,
Florent.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735288: O: winetricks -- package manager for WINE to install software easily
Package: wnpp Severity: normal I no longer have use this application. The package is in otherwise in a good shape: standard 3.9.4, debhelper 9, Copyright Format 1.0 For a prospective new maintainer: Start maintaining the package from Git[*] git clone $lo...@git.debian.org:/git/collab-maint/winetricks.git PTS: http://packages.qa.debian.org/w/winetricks.html Jari [*] http://wiki.debian.org/Alioth/Git http://wiki.debian.org/Alioth/Git#Collab_Maint_project -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735268: xemacs21: circular dependency hell
On Tue, Jan 14, 2014 at 12:38:51PM +, Mark Brown wrote: severity 735268 wishlist kthxbye On Tue, Jan 14, 2014 at 10:59:43AM +0100, Bill Allombert wrote: Complex circular dependencies are known to cause problems during upgrade, so we should try to get rid of them. On the other hand we've managed to survive for quite a few releases with this; it's a straightforward set of leaf packages after all. I was hoping you were planning to do a better job than the previous maintainer. This bug is #341005 which was closed by the package removal. There is no reason for xemacs21-support to depend on xemacs21 since xemacs21 is a dummy package. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732342: Samba Stack Trace due to hdb interface change in Heimdal
On Thu, 2014-01-09 at 18:04 -0600, Jeff Clark wrote: No problem. Will send it over in a few hours. With all the false starts on this, I've sat on the patches until I can test it with the developer at Catalyst IT who also reproduced it. Once that comes out OK, I'll get the fix for this pushed, and get the matching Heimdal patch in. Brian, This bug needs a patch to Heimdal as well as to Samba. I'll post you the patch once I've tested it, and then I guess we need to work on a stricter version dep here to make sure this all keeps in sync. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733600: python-gevent: Please package new upstream release 1.0
I'd also like to see version 1.0 packaged, and am willing to offer any help I can give! Thanks, Luca Wehrstedt
