Bug#746539: kernel-package: Please suggest liblz4-tool
Package: kernel-package Version: 12.036+nmu3 Severity: wishlist If I build a kernel with LZ4 compression enabled, it fails at / | LZ4 arch/x86/boot/compressed/vmlinux.bin.lz4 | /bin/sh: 1: lz4c: not found \ Kernel-package could Suggest liblz4-tool to help find the right binary to fix this. Thanks. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable'), (400, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armel Kernel: Linux 3.11.10-balti (SMP w/8 CPU cores; 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 kernel-package depends on: ii binutils 2.24-4 ii build-essential11.6 ii debianutils4.4 ii file 1:5.17-1 ii gettext0.18.3.2-1 ii make 3.81-8.3 ii module-init-tools 16-2 ii po-debconf 1.0.16+nmu2 ii util-linux 2.20.1-5.7 Versions of packages kernel-package recommends: ii cpio 2.11+dfsg-2 Versions of packages kernel-package suggests: pn btrfs-tools none ii bzip2 1.0.6-5 ii docbook-utils 0.6.14-3 ii e2fsprogs 1.42.9-3 pn grub | grub2none ii initramfs-tools [linux-initramfs-tool] 0.115 pn jfsutilsnone ii libncurses5-dev [libncurses-dev]5.9+20140118-1 ii linux-source3.13+56 pn mcelog none pn oprofilenone pn pcmciautils none pn ppp none ii procps 1:3.3.9-2 pn quota none pn reiserfsprogs none pn squashfs-tools none ii udev204-8 pn xfsprogsnone ii xmlto 0.0.25-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#745687: [Pkg-javascript-devel] Bug#745687: new upstream version (2.x series)
Quoting Jérémy Lal (2014-04-30 21:09:41) Le mercredi 30 avril 2014 à 14:34 +0200, Jonas Smedegaard a écrit : Quoting Jérémy Lal (2014-04-30 12:53:22) Le mercredi 30 avril 2014 à 12:35 +0200, Leo Iannacone a écrit : On 30 April 2014 02:10, Jonas Smedegaard d...@jones.dk wrote: Status of packaging is that these libraries needs packaging first: node-source-map node-uglify-to-browserify About node-uglify-to-browserify: You do not really need to package it, since it's only related to uglify2.x (it has no reverse-dependency) I think you can bundle it as a patch along with uglify v2.x. I am no fan of hiding upstream projects by maintaining as bundles in Debian. If in fact it makes best sense for node-uglify-to-browserify to be part of UglifyJS2 project, it makes more sense for me to have upstream merge those projects. Or did I perhaps misunderstand your suggestion? You understand correctly. I'm less strict about bundling... i'm using that workaround rarely, though. Anyway it doesn't matter here since in fact, uglify-to-browserify is A transform to make UglifyJS work in browserify. I propose we postpone packaging of this module and list it in Suggests for now. Agreed. About node-source-map: It build-depends on dryice (=0.4.8). You can find a pre-release package in pkg-javascript/node-dryice.git repository. Once it done/uploaded to unstable, we will be able to build source-map. I can help about that, Great! but could you find out about the dependency loop: dryice depends on uglify-js I suspect that such dependency would be only needed only for browser use, not for use in a Nodejs environment (which includes build environment for UglifyJS2). If that's true, I suggest to simply add hinting as documented here: https://wiki.debian.org/BuildProfileSpec I don't understand how that helps. In fact we have a simple uglify - sourcemap+dryice - uglify dependency loop. Sorry - I was thinking *build*-dependency loop. You are right, such hinting is of no help here. We could patch a little dryice so that it doesn't Depends uglify-js but only Recommends or Suggests it. Do i remember well ? would that be enough ? Sounds good. Seems the code already warns + returns uncompressed data if uglification fails, so possibly it is as simple as hacking the requires check. ...but I'd feel much safer leaving that in your hands :-D Related to the point above, it's interesting to note that dryice is a good example of what we could ask upstream to merge back into source-map. I'll leave that to you too. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#746488: linux-image-2.6.32-5-amd64: Random shutdowns from signal 15
Control: tag -1 moreinfo On Wed, Apr 30, 2014 at 09:25:34AM -0500, Justin McZeal wrote: It seems like we are getting random shutdowns, typically sometime between 7-9am CST. The last message in the logs is that a signal 15 was sent to all processes. Due to the nature of our business, we don't keep the server down long enough to leave time for investigation via DRAC. There are no services or crons that I know of that would randomly send a signal 15 to all processes. When this occurs, the console states that rsyslogd has stopped. We are in the process of making a Debian 7 server to transfer to, in case it's an OS related issue. The kernel does no random shutdowns for fun. Please show the _complete_ log. ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=db2d279a-afb3-4ea5-906a-bbb4ab04a8ce ro quiet pcie_aspm=off acpi=off noapic noacpi Are you kidding? You disable critical parts of current x86 architecture and expect it to work? Bastian -- A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746473: BUG: unable to handle kernel paging request at 0000000000001b90
On Wed, Apr 30, 2014 at 01:36:49PM +0300, root wrote: dmesg showed the log below The output of dmesg looks different (no leading time). Also it is truncated. You can try using a serial console or netconsole to catch the complete log if it does not survice otherwise. ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=UUID=a4d2a5df-8a06-46ce-bf5c-e1c671729c4f ro nomodeset Is there a reason for the nomodeset? Bastian -- Killing is wrong. -- Losira, That Which Survives, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746533: iso-codes: Incorrect Japanese translation of Maryland
(my answer CC'ed to debian-i18n as I think it contains useful information for new translators) From a bug report in iso-codes. Quoting Steve Wooster (swoos...@submitnet.net): Package: iso-codes Version: 3.52 Severity: normal Tags: l10n Dear Maintainer, iso-codes 3.52 appears to have an incorrect Japanese translation for Maryland (LR-MY and US-MD); it says アイスランド (aisurando, which I assume is the Japanese name for Iceland). Google Translate suggested writing Maryland as メリーランド(mariirando), which looks reasonable to me. Hi Steve, The translation is technically not incorrect. Let me explain. In the PO file, this string was marked as fuzzy. It indeed really has the translation of Iceland. Being marked fuzzy, it won't be used by gettext when the PO file is compiled to an MO file. The fuzzy marker indeed says to translators hey guys, look at this string, it recently changed and needs your attention. In this case, this is the result of fuzzy matching, a feature of gettext. When the Maryland string was added to the English strings, gettext looked into the PO file to find a similar string and found out Iceland. Then it included the Japanese translation of Iceland but included a fuzzy marker so that it's not used until corrected (correcting it will remove the fuzzy marker). This is a useful feature for longer strings. For instance, let's say you have software with that string: Hello world The French translator works on the PO file and translates it to msgid Hello world msgstr Bonjour le monde Later on, the software developer adds another string: Hello nice world The, gettext will be smart and re-use the French translation when it syncs the PO file: #, fuzzy msgid Hello gentle world msgstr Bonjour le monde It even optionnally adds of former string marker (this is the --previous option of the msgmerge utility): #, fuzzy #| msgid Hello world msgid Hello gentle world msgstr Bonjour le monde That virtuallyl says hey folks, this is a new string, but I found a similar string and I've been kind to you and re-used your translation. However, you need to correct it by comparing both original and new versions. Then, the French translator comes on that PO file and checks fuzzy strings. (s)he finds out this new string and is happy that part of his|her former translation is already there and (s)he just has to add the missing part: msgid Hello gentle world msgstr Bonjour le joli monde The fuzzy marker is removed and, with minimal hassle, the translator could update. Translators are lazy people. Even better, is (s)he uses some smart software to update PO files, this software can show him|her the difference between the former string and the new one so that (s)he can see that the change was the addition of the gentle word. This is very useful in very long strings when only one word is changed and makes it hard to spot what needs to be updated. I hope this will be useful to you and, indeed, I'm happy to have taken this opportunity to better explain fuzzy matching and --previous and why it is good to use good software to edit PO files...:-) Back to iso-codes: admitedly fuzzy matching is not very useful in this software, because strings are very short and there is indeed no strong relation between Iceland and Maryland...:-). Still, it was useful, for instance, when South Sudan was added because the translation of Sudan could be put with fuzzy matching Finally, I fixed things in the ISO-3166-2 Japanese translation by using your proposaland now, Maryland is properly translated in Japanese in that file in our git repository...;-) signature.asc Description: Digital signature
Bug#746540: bind9: FTBFS on hurd-i386
Source: bind9 Version: 1:9.9.5.dfsg-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, bind9 does not compile on Hurd since version 9.9.5 [1]. The problem is much like kFreeBSD's #741285, i.e. missing LDFLAGS when having ldopen. The attached patch extends the fix of #741285 to properly cover Hurd as well, whose GNU triplet is like i686-unknown-gnu0.5. [1] https://buildd.debian.org/status/fetch.php?pkg=bind9arch=hurd-i386ver=1%3A9.9.5.dfsg-4stamp=1398846530 Thanks, -- Pino --- a/configure.in +++ b/configure.in @@ -3568,7 +3568,7 @@ fi if test $dlopen = yes; then case $host in - *-linux*|*-gnu) + *-linux*|*-gnu*) SO_CFLAGS=-fPIC if test $have_dl = yes then
Bug#746533: marked as done (iso-codes: Incorrect Japanese translation of Maryland)
reopen 746533 thanks the string is marked as fuzzy. this means the msgstr was perhaps retrieved from iso_3166's Iceland as similar string by msgmerge or something, and never updated for Maryland note that the string is fuzzy, so will never appeared in users' screen. as such, this bug 746533 is not an issue so should be simply closed. Technically correctbut, as Steve peoposed a transation and I guess it is good, then I used it and indeed fixed something. So let's say we can use this bug report (but you were technically correct by closing the bug report anyway). signature.asc Description: Digital signature
Bug#745789: O: obexftp -- mount filesystem of ObexFTP capable devices
Control: retitle -1 O: obexfs -- mount filesystem of ObexFTP capable devices Hi, On Fri, Apr 25, 2014 at 07:06:58AM +0200, Hendrik Sattler wrote: Subject: O: obexftp -- mount filesystem of ObexFTP capable devices Package: wnpp Severity: normal I intend to orphan the obexftp package. I am the current upstream maintainer but have no time or passion anymore to also maintain the debian package. This package is merged upstream into the obexftp package that I also orphaned. The package description is: ObexFS uses FUSE to mount filesystems of ObexFTP capable devices either manually or in autofs style mode. It can handle all devices that the obexftp package can handle, connected via serial cable, IrDA, bluetooth or USB. I guess you intended to orphan obexfs with this bug (obexftp is orphaned in 745788). Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746541: xserver-xorg-video-qxl - Missing dep on xserver-xorg-video-modesetting
Source: xserver-xorg-video-qxl Version: 0.1.1-1 Severity: serious xserver-xorg-video-qxl needs the modesetting module to do anything useful on kernels with dri qxl. Bastian -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746542: xserver-xorg-video-qxl
Source: xserver-xorg-video-qxl - Errors because of missing dri Version: 0.1.1-1 Severity: important AIGLX tries to use the software renderer, but xserver-xorg-video-qxl does neither depend, nor recommend it. | (EE) AIGLX: reverting to software rendering | (EE) AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed (/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory) | (EE) GLX: could not load software renderer Bastian -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746543: pinba-engine-mysql-5.5: uninstallable: depends on obsolete version of mysql-5.5
package: pinba-engine-mysql-5.5 version: 1.0.0-4 severity: serious Hi, The upload of mysql-5.5 5.5.37-1 makes pinba-engine-mysql-5.5 uninstallable in sid, as it depends on an older version. Either a new upload or a binnmu is necessary. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607552: [5740bc9] Fix for Bug#607552 committed to git
tags 607552 +pending thanks Hi, The following change has been committed for this bug by Manoj Srivastava sriva...@golden-gryphon.com on Thu, 1 May 2014 00:04:13 -0700. The fix will be in the next upload. = [master]: New bug fixing release. * Bug fix: FTBFS due to binutils-gold, thanks to Bhavani Shankar R. Added -lm toi the linker line.(Closes: #607552). * Bug fix: depends on obsolete libmikmod2 on powerpc, thanks to Julien Cristau. This is not a direct dependency, so rebuilding should fix it. (Closes: #742598). = -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607552: [054bb14] Fix for Bug#607552 committed to git
tags 607552 +pending thanks Hi, The following change has been committed for this bug by Manoj Srivastava sriva...@golden-gryphon.com on Thu, 1 May 2014 00:04:26 -0700. The fix will be in the next upload. = [master]: New bug fixing release. * Bug fix: FTBFS due to binutils-gold, thanks to Bhavani Shankar R. Added -lm toi the linker line.(Closes: #607552). * Bug fix: depends on obsolete libmikmod2 on powerpc, thanks to Julien Cristau. This is not a direct dependency, so rebuilding should fix it. (Closes: #742598). Signed-off-by: Manoj Srivastava sriva...@golden-gryphon.com = -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746544: puredata crashes when unsetting GoP within a table
Package: puredata-core Version: 0.45.4-1 Hello, Steps to reproduce: - start puredata - create a new patch - create a table - right click on the table, select open - right click inside this new window, untick Graph on Parent - hit apply ... then it crashes. Note: happens on 2 different computers (i386 amd64) running Debian Jessie. Good day, 01 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744300: missing dependency on dh-python
On 04/25/2014 11:14 PM, Evgeni Golov wrote: control: tags -1 - moreinfo unreproducible control: severity -1 wishlist On Fri, Apr 25, 2014 at 04:51:19PM +0200, Evgeni Golov wrote: On Sun, Apr 13, 2014 at 12:32:23AM +0800, Thomas Goirand wrote: The package is missing a dependency on dh-python, and therefore, it did FTBFS on my automated build system. Please fix it. The package builds fine in a clean uptodate sid chroot. Can you please provide more info? This dependency is only needed when building backports for wheezy. As this is just to ease the backporters work, downgrading dependency to wishlist. Regards Evgeni Hi, Thanks for your reply. The author of pybuild, Piotr Ożarowski, agrees that dh-python should be declared explicitly. It does work because there's some indirect dependencies, though you shouldn't rely on them, IIRC. I don't mind whatever severity you assign for this bug, as long as you fix it. :) Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746029: ejabberd: only admin can connect after upgrade
After upgrading to Erlang 17 I got I/O error in Pidgin trying to connect. Other clients are unable to connect, too. And when I downgraded Erlang to 16 from wheezy-backports, problem dissappears. Might be that our problems are similiar. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743651: autofs5: does not support recursive mount (regression to #626473)
Package: autofs Version: 5.0.8-1 Followup-For: Bug #743651 Another variant of this problem: Attempting to automount an aufs view with automounted branches. A quick look through the code makes me wonder why the locking option was done as a compile time thing. It's used in very few places, and could fairly easily be turned into a runtime thing. Also, I'm pretty sure that #556910 is the same issue as this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746545: gnome-shell - Shutdown ignored
Package: gnome-shell Version: 3.12.1-3 Severity: important gnome-shell is not longer able to shutdown the system. journalctl -xb does not show any obvious errors. Bastian -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.18.0-1 ii evolution-data-server3.8.5-3+b2 ii gdm3 3.8.4-6 ii gir1.2-accountsservice-1.0 0.6.37-1 ii gir1.2-caribou-1.0 0.4.12-1+b1 ii gir1.2-clutter-1.0 1.18.0-2 ii gir1.2-freedesktop 1.40.0-2 ii gir1.2-gcr-3 3.12.0-1 ii gir1.2-gkbd-3.0 3.6.0-1 ii gir1.2-glib-2.0 1.40.0-2 ii gir1.2-gmenu-3.0 3.8.0-2 ii gir1.2-gnomebluetooth-1.03.8.1-2 ii gir1.2-gnomedesktop-3.0 3.8.4-2 ii gir1.2-gtk-3.0 3.12.0-4 ii gir1.2-ibus-1.0 1.5.5-1 ii gir1.2-mutter-3.03.8.4-3 ii gir1.2-networkmanager-1.00.9.8.8-7 ii gir1.2-nmgtk-1.0 0.9.8.8-5 ii gir1.2-pango-1.0 1.36.3-1 ii gir1.2-polkit-1.00.105-4 ii gir1.2-soup-2.4 2.46.0-2 ii gir1.2-telepathyglib-0.120.24.0-1 ii gir1.2-telepathylogger-0.2 0.8.0-3 ii gir1.2-upowerglib-1.00.9.23-2+b2 ii gjs 1.36.1-2 ii gnome-bluetooth 3.8.1-2 ii gnome-icon-theme-symbolic3.12.0-1 ii gnome-settings-daemon3.8.5-2 ii gnome-shell-common 3.8.4-8 ii gnome-themes-standard3.12.0-1 ii gsettings-desktop-schemas3.8.2-2 ii libatk-bridge2.0-0 2.10.2-3 ii libatk1.0-0 2.12.0-1 ii libc62.18-4 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libcamel-1.2-43 3.8.5-3+b2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libclutter-1.0-0 1.18.0-2 ii libcogl-pango20 1.18.0-2 ii libcogl-path20 1.18.0-2 ii libcogl201.18.0-2 ii libcroco30.6.8-2 ii libdbus-1-3 1.8.0-3 ii libdbus-glib-1-2 0.102-1 ii libdrm2 2.4.52-1 ii libecal-1.2-15 3.8.5-3+b2 ii libedataserver-1.2-173.8.5-3+b2 ii libegl1-mesa [libegl1-x11] 10.1.0-5 ii libgbm1 10.1.0-5 ii libgck-1-0 3.12.0-1 ii libgcr-base-3-1 3.12.0-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgirepository-1.0-11.40.0-2 ii libgjs0c [libgjs0-libmozjs185-1.0] 1.36.1-2 ii libglib2.0-0 2.40.0-2 ii libgnome-menu-3-03.8.0-2 ii libgstreamer1.0-01.2.4-1 ii libgtk-3-0 3.12.0-4 ii libical1 1.0-1 ii libjson-glib-1.0-0 1.0.0-1 ii libmozjs185-1.0 1.8.5-1.0.0+dfsg-4+b1 ii libmutter0b 3.8.4-3 ii libnm-glib4 0.9.8.8-7 ii libnm-gtk0 0.9.8.8-5 ii libnm-util2 0.9.8.8-7 ii libnspr4 2:4.10.4-1 ii libnss3 2:3.16-1 ii libnss3-1d 2:3.16-1 ii libp11-kit0 0.20.2-5 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpolkit-agent-1-0 0.105-4 ii libpolkit-gobject-1-00.105-4 ii libpulse-mainloop-glib0 5.0-2 ii
Bug#705111: Please enable the --enable-rdb option when building
01.05.2014 04:36, Dmitry Smirnov wrote: On Tue, 22 Apr 2014 14:32:30 Michael Tokarev wrote: I think that's all what needed, I will re-enable rbd/ceph on the next qemu upload. We're waiting for this functionality so eagerly but apparently it is still absent in (just uploaded) qemu_2.0.0+dfsg-4. Is there are any problems? We've several security issues and regressions in -testing and I really want them to be fixed first. The last upload fixes a bug which prevented qemu from migrating to -testing (which I overlooked because I was busy with family stuff -- perhaps pts should have a service to notify about stalled migrations?) I didn't forget about rdb. Please believe me, it is _very_ difficult to forget about it after all this story. I'm just afraid of something else popping up from its side, or elsewhere - as you can see, qemu is having lots of small issues recently which constantly prevents it from migrating in time. And I have real users with issues (like virtio-scsi bug with windows64 in 1.7.1 and 2.0 for which there's a band-aid included in 2.0 debian package) who are waiting for things to appear in -bpo. It will be enabled, like a few other things (new libcacard packages for example, which I also was holding for too long - needed for spice and other things too). Please give me some time for the dust after 2.0 to settle. Thank you. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744119: help with and sponsoring onion upload
On 04/25/2014 10:43 PM, David Moreno Montero wrote: Just a quick note to inform that I just removed the sd-daemon.[ch] files and I depend on system provided ones (at libsystemd-daemon-dev). Also fixed jquery, I added the uncompressed one. Shipping non-minified javascript in your source is a requirement of Debian for all source packages, so what you did is a good thing. However, we also require that you use all libraries that are packaged in the system. So you must use the jquery which is in Debian. And yes, you must comply with both rules, which means even if you don't use the jquery which you ship in your source code, it must *not* be minified. Just wanted to make this clear. Currently its not in control / depends, as I want to make my head if it should be enforced or not, but as systemd is on Debian's future, I guess it fits. You shouldn't force your users to use systemd if you can avoid it. We have chosen systemd as default, but our users may not like it and prefer another init system. Please respect the user choices if possible. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746546: message gets through but generates help message
Package: bugs.debian.org My comment got through, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746445#15 But I got this weird message as a side effect: ---BeginMessage--- General info Subscription/unsubscription/info requests should always be sent to the -request address of a mailing list. If a mailing list is called for example thel...@lists.debian.org, then the -request address can be inferred from this to be: thelist-requ...@lists.debian.org. To subscribe to a mailing list, simply send a message with the word subscribe in the Subject: field to the -request address of that list. To unsubscribe from a mailing list, simply send a message with the word (you guessed it :-) unsubscribe in the Subject: field to the -request address of that list. In the event of an address change, it would probably be the wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe to the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be Re:, without the quotes of course); the -request server does not react to replies. The archive server -- Every submission sent to this list is archived. The size of the archive depends on the limits set by the list maintainer (it is very well possible that only, say, the last two mails sent to the list are still archived, the rest might have expired). You can look at the header of every mail coming from this list to see under what name it has been archived. The X-Mailing-List: field contains the mailaddress of the list and the file in which this submission was archived. If you want to access this archive, you have to send mails to the -request address with the word archive as the first word of your Subject:. To get you started try sending a mail to the -request address with the following: Subject: archive help The listmaster -- To reach a human being answering your mail you may contact the address listmas...@lists.debian.org. We will process your request as soon as we can. Mail sent to this address is pre-parsed, a little mail robot will automatically answer all mails sent with the following Subject lines: help sends this help lists sends information on how to get a list of mailing lists ---End Message---
Bug#746501: [PKG-Openstack-devel] Bug#746501: cinder: should depend on sudo
On 05/01/2014 12:55 AM, Benedikt Trefzer wrote: Source: cinder Version: 2014.1-2~bpo70+1 Severity: normal Hi out there I was debugging quite a long time, why I could not create a volume from an image ... Result: If sudo is not installed, rootwrap for cinder is not working. Conclusion: Cinder should depend on sudo. Cheers Benedikt Hi Benedikt, Thanks for this useful bug report. I think it'd be wiser to have python-oslo.rootwrap to depend on sudo than having cinder doing so. I'm therefore reassigning the bug to that package, and will fix that one. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705111: Please enable the --enable-rdb option when building
Hi Michael, I understand, thank you for update and sorry for bugging you. Now when we know your roadmap we can wait till qemu migrates to testing first. -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#745849: src:binutils: debian/rules uses usr vs $(PF) inconcistently and confuses DEB_TARGET_* with DEB_HOST_*
Hi Matthias, Thanks for taking the time to reply and even selectively apply my patches! On Sun, Apr 27, 2014 at 10:28:58PM +0200, Matthias Klose wrote: Am 25.04.2014 21:17, schrieb Helmut Grohne: * Some places use usr and others use $(PF). Thus changing the PF variable does no longer work. The patch restores $(PF) to working order. If that variable is no longer useful, then maybe using its only working value usr in all places is a better solution. I believe that you missed the hunk conditional to GFDL_INVARIANT_FREE, but applied all the others. Is that intentional? * If $(TARGET) is non-empty, it contains what should be called DEB_TARGET_GNU_TYPE. I therefore introduce this new variable for both native and cross builds. All places that really want to know the target gnu type now use DEB_TARGET_GNU_TYPE. There are two kinds of variables being converted: + TARGET when it is not used to branch on being non-empty + DEB_HOST_GNU_TYPE when it DEB_TARGET_GNU_TYPE was meant the use of target for the native build doesn't make sense. just try to configure the native build with --target=. so this should not be used outside the rules to build the cross package. Clearly binutils (like gcc) does have target-specific elements. Therefore, I cannot follow your argument as to why referring to a target architecture would not make sense. Simply put, when doing a native build DEB_BUILD_GNU_TYPE, DEB_HOST_GNU_TYPE and DEB_TARGET_GNU_TYPE all have the very same value, so no breakage can be caused there by the proposed changes. The benefit of using different variables is to make the intention explicit. Without this differentiation further modifications become unnecessarily hard and/or lead to overly complex branching. I completely fail to see a scenario in which I either would want to configure a build with --target=. or where my patch would be introducing such a scenario. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746547: RM: hwinfo,libhd-dev,libhd-doc,libhd16/experimental [mips mipsel powerpc s390x] -- ROM; new upstream dependency on linux headers
Package: ftp.debian.org Severity: normal Package: ftp.debian.org Severity: normal Dear ftpmasters, hwinfo is now limited to build only on amd64 i386 armel and armhf; please remove the old binaries (hwinfo, libhd-dev, libhd-doc, libhd16) from sid. http://qa.debian.org/excuses.php?package=hwinfo Thanks, Seb -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743117: Intent to NMU
Dear Margarita, thank you for your contribution!
I was in vacations some days, so your NMU is welcome!
Best regards, Georges.
Margarita Manterola a écrit :
Hi,
I have taken the patch made by Paul, but added it to the 10-Makefile.patch,
where it made more sense.
I've tested the resulting program and it seemed to use cairo properly,
although
I'm not a French speaker, not a chemistry expert, it seemed to do the right
thing.
I'm attaching here the debdiff corresponding to my change. I'll be uploading
this fix to the 3-day delayed queue.
--
Cheers,
Marga
diff -Nru dozzaqueux-3.33/debian/changelog dozzaqueux-3.33/debian/changelog
--- dozzaqueux-3.33/debian/changelog 2014-01-05 17:10:54.0 +0100
+++ dozzaqueux-3.33/debian/changelog 2014-04-25 15:40:50.0 +0200
@@ -1,3 +1,11 @@
+dozzaqueux (3.33-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Modify 10-Makefile.patch to find cairocanvas component, fixing FTBFS.
+Based on patch by Paul Gevers elb...@debian.org. Closes: #743117
+
+ -- Margarita Manterola ma...@debian.org Fri, 25 Apr 2014 15:13:49 +0200
+
dozzaqueux (3.33-1) unstable; urgency=medium
* created a working watch file and added a script to make the new package
diff -Nru dozzaqueux-3.33/debian/patches/10-Makefile.patch
dozzaqueux-3.33/debian/patches/10-Makefile.patch
--- dozzaqueux-3.33/debian/patches/10-Makefile.patch 2014-01-05
17:09:41.0 +0100
+++ dozzaqueux-3.33/debian/patches/10-Makefile.patch 2014-04-25
15:16:05.0 +0200
@@ -1,6 +1,8 @@
/dev/null
-+++ b/Makefile
-@@ -0,0 +1,50 @@
+Index: dozzaqueux-3.33/Makefile
+===
+--- /dev/null1970-01-01 00:00:00.0 +
dozzaqueux-3.33/Makefile 2014-04-25 15:16:01.448456823 +0200
+@@ -0,0 +1,51 @@
+DESTDIR =
+
+FPC_VERSION = $(shell update-alternatives --list lazarus | tail -1 | awk -F
/ '{print $$5}')
@@ -12,6 +14,7 @@
+UNITLIBS +=
-Fu/usr/lib/lazarus/$(FPC_VERSION)/components/lazutils/lib/$(ARCH)/
+UNITLIBS +=
-Fu/usr/lib/lazarus/$(FPC_VERSION)/components/synedit/units/$(ARCH)/nogui/
+UNITLIBS += -Fu/usr/lib/lazarus/$(FPC_VERSION)/packager/units/$(ARCH)/
++UNITLIBS +=
-Fu/usr/lib/lazarus/$(FPC_VERSION)/components/cairocanvas/lib/$(ARCH)/gtk2/
+UNITLIBS +=
-Fu/usr/lib/lazarus/$(FPC_VERSION)/components/printers/lib/$(ARCH)/gtk2/
+UNITLIBS +=
-Fu/usr/lib/lazarus/$(FPC_VERSION)/components/synedit/units/$(ARCH)/
+UNITLIBS += -Fu.
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: Digital signature
Bug#746501: [PKG-Openstack-devel] Bug#746501: cinder: should depend on sudo
Hi Thomas This seems to e a good idea. I was inspired by neutron-l3-agent which depends on sudo. If you assign it to rootwrap there are probably other packages where it can be removed. Cheers Benedikt On 01.05.2014 10:14, Thomas Goirand wrote: On 05/01/2014 12:55 AM, Benedikt Trefzer wrote: Source: cinder Version: 2014.1-2~bpo70+1 Severity: normal Hi out there I was debugging quite a long time, why I could not create a volume from an image ... Result: If sudo is not installed, rootwrap for cinder is not working. Conclusion: Cinder should depend on sudo. Cheers Benedikt Hi Benedikt, Thanks for this useful bug report. I think it'd be wiser to have python-oslo.rootwrap to depend on sudo than having cinder doing so. I'm therefore reassigning the bug to that package, and will fix that one. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746548: base-files: os-release has no VERSION and VERSION_ID fields
Package: base-files Version: 7.2 Severity: wishlist -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-trunk-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 base-files depends on: ii gawk [awk] 1:4.1.1+dfsg-1 ii mawk [awk] 1.3.3-17 base-files recommends no packages. base-files suggests no packages. -- no debconf information The /etc/os-release file has no VERSION and VERSION_ID fields, which are critical for the usefulness of the file in scripts / tooling. Thanks Sylvain
Bug#746369: AW: Bug#746369: RFS: downtimed/0.6.2
-Ursprüngliche Nachricht- Von:Cameron Norman camerontnor...@gmail.com One thing I noticed is that upstream has an Upstart job, but you are not shipping it. Simply making a symlink from debian/downtimed.upstart to startup-scripts/upstart-startup.conf should do the trick. Updated package is present on mentors with the appropriate upstart link. Thank you. Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746477: /usr/bin/conky: conky terminates after several minutes with you don't need that many fonts message
Hi,
I have created a pull request on github.
Regards
Damian
Am 01.05.2014 06:42, schrieb Vincent Cheng:
On Wed, Apr 30, 2014 at 4:12 AM, Me m...@arcsin.de wrote:
Package: conky-std
Version: 1.9.0-2
Severity: normal
File: /usr/bin/conky
Dear Maintainer,
conky terminates reproducibly after several minutes on my system logging the
following:
Conky: desktop window (183) is subwindow of root window (d3)
Conky: window type - desktop
Conky: drawing to created window (0x2e2)
Conky: drawing to double buffer
Conky: you don't need that many fonts, sorry.
In between, conky works as expected. The following patch helps:
--- conky-1.9.0.orig/src/specials.c
+++ conky-1.9.0/src/specials.c
@@ -330,6 +330,15 @@ void new_gauge(struct text_object *obj,
}
#ifdef X11
+int find_font(char *name)
+{
+int i;
+for (i = 0; i font_count; i++)
+if (strncmp(name, fonts[i].name, DEFAULT_TEXT_BUFFER_SIZE)
== EQUAL)
+return i;
+return 0;
+}
+
void new_font(char *buf, char *args)
{
if ((output_methods TO_X) == 0)
@@ -337,6 +346,13 @@ void new_font(char *buf, char *args)
if (args) {
struct special_t *s = new_special(buf, FONT);
+ int index;
+
+if (index = find_font(args))
+{
+s-font_added = index;
+return;
+}
if (s-font_added font_count || !s-font_added ||
(strncmp(args, fonts[s-font_added].name, DEFAULT_TEXT_BUFFER_SIZE) !=
EQUAL) ) {
int tmp = selected_font;
Can you forward the patch upstream [1]? Thanks!
Regards,
Vincent
[1] https://github.com/brndnmtthws/conky
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746549: No music found
Package: gnome-music Version: 3.12.0-2 Severity: important important on the theory that it presumably works for others; if not, this should be RC. Running gnome-music produces a window with the following text: No music found! Put some files into the folder /home/josh/media/music However: ~$ find /home/josh/media/music -name '*.ogg' -o -name '*.mp3' -o -name '*.flac' | wc -l 798 I have lots of music in that folder; gnome-music just doesn't see it. - Josh Triplett -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-music depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii gir1.2-glib-2.0 1.40.0-2 ii gir1.2-grilo-0.2 0.2.10-1 ii gir1.2-gst-plugins-base-1.0 1.2.4-1 ii gir1.2-gstreamer-1.0 1.2.4-1 ii gir1.2-gtk-3.0 3.12.1-1 ii gir1.2-notify-0.70.7.6-2 ii gir1.2-totem-plparser-1.03.10.2-1 ii gir1.2-tracker-0.16 0.16.2-1+b2 ii gnome-settings-daemon3.8.5-2 ii grilo-plugins-0.20.2.12-2+b1 ii libatk1.0-0 2.12.0-1 ii libc62.18-5 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk-3-0 3.12.1-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii python3 3.3.4-1 ii python3-dbus 1.2.0-2+b2 ii python3-gi 3.12.1-1 ii python3-gi-cairo 3.12.1-1 pn python3:any none ii tracker 0.16.2-1+b2 gnome-music recommends no packages. gnome-music 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#657146: any news on tango-common: unowned files after purge ?!?
found 657146 8.1.2c+dfsg-4 thanks Hi, any news on this bug (tango-common: unowned files after purge (policy 6.8, 10.8))? It's currently blocking 16 other packages (in sid) from being tested by piuparts.d.o, which can be seen on https://piuparts.debian.org/sid/state-failed-testing.html (the numbers behind the package names are explained in the table header) and which is really a pity. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#668751: any news on unowned directory after purge: /usr/share/liquidsoap ?!?
Hi, any news on this bug (liquidsoap: unowned directory after purge: /usr/share/liquidsoap)? It's currently blocking 35 other packages (in sid) from being tested by piuparts.d.o, which can be seen on https://piuparts.debian.org/sid/state-failed-testing.html (the numbers behind the package names are explained in the table header) and which is really a pity. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
Ben Hutchings b...@decadent.org.uk writes: How is it 'not working'? didn't have time to inspect the details yet - Crash/hang when trying to suspend? suspend itself seems to work - Immediate resume after suspending? no - Unresponsive when trying to resume? - Crash/hang after resuming? looks like a complete crash on resume nothing in the logs have to power down to get the device working again jens pgp3ZccnL_u2X.pgp Description: PGP signature
Bug#745687: [Pkg-javascript-devel] Bug#745687: Bug#745687: new upstream version (2.x series)
Related to the point above, it's interesting to note that dryice is a good example of what we could ask upstream to merge back into source-map. I'll leave that to you too. I added an issue: https://github.com/mozilla/source-map/issues/108 let's see what happens. Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746551: geany: please improve support for SCSS (Sassy CSS)
Package: geany Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Currently, to handle SCSS one needs to... 1) copy /usr/share/geany/filetypes.css to $HOME/.config/geany/filedefs/ 2) edit the copied file to add these: [lexer_properties] lexer.css.scss.language=1 1) copy /usr/share/geany/filetype_extensions.conf to $HOME/.config/geany/filedefs/ 2) edit the copied file to change a line into this: CSS=*.css;*.scss; Then it works editing SCSS files - and plain CSS files too, only slightly mis-treated. Would be better if possible to make side-wide customizations, by installing those files below etc, symlinking them to their expected location below /usr/share/geany/. Even better would be to treat SCSS as a separate language, selectable from the menu. It would inherit from CSS (as xml inherits from html). - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJTYhNNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWQVIH/1uMYshOKJHyl+lFjX7xExSb poV86tdrdlA8zaqQSipS4rkXf6yIx85OIHlsomCY0rEartvv8JagCcLTiDwS/bJH EU4i34n2+tD83gpSntZx4oIQfTKCR5Wwvj/ynwWNPTPX5TONr/E0Vy8q2z4rF0o/ e409AAUiIEQERC3xdnVe6u7FW0IJiT2rw4FnkysTxa3SZAP5o7JF/zlRehoB87xu +qYjiE6qgykjFmmAlCmuU+HSckED9IVU+in8U+lj9ZZrkGUisep14s7Q8qbmhRcc wn+9Qe1sUL7sjCUWedM0R3x6XMCmNWIKwm5MRnqEg6MTc2+xD0uqJw6HKyHHg5Y= =n7RM -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#746363: needrestart: uninitialized value by kernel threads
Hi Axel,
On 05/01/2014 01:46 AM, Axel Beckert wrote:
On 04/29/2014 12:35 PM, Axel Beckert wrote:
# needrestart
Scanning processes...
Scanning candidates.Use of uninitialized value in pattern match (m//) at
/usr/sbin/needrestart line 285, HPIPE line 1.
Use of uninitialized value in pattern match (m//) at /usr/sbin/needrestart
line 285, HPIPE line 1.
this is very strange... it looks like the return of Proc::ProcessTable
is broken - I could not reproduce it, yet. It looks like the
/proc/pid/exe symlink is missing for some processes?!
Doesn't seem so:
# for i in /proc/[0-9]*; do if [ ! -e $i/exe ]; then ls -l $i/exe; fi; done
ls: cannot read symbolic link /proc/10/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Apr 28 22:53 /proc/10/exe
At least all of these pids I checked were kernel threads for which the
above behaviour is IIRC normal:
# ps auxwww | fgrep --color '['
root 1 0.0 0.0 13228 668 ?Ss2013 2:21 init [2]
root 2 0.0 0.0 0 0 ?S 2013 0:00 [kthreadd]
But the /proc/$pid/exe symlink is always there, it just doesn't have a
target. Which should be ok for kernel threads.
It was just to late at night... I was already aware of the kernel thread
behavior:
# ignore kernel threads
next unless(defined($ptable-{$pid}-{exec}));
The problem is the second scanning pass which looks for the parent
processes. It seems to happen if a process is a child of a kernel
thread... sadly I could not reproduce it, yet.
P.S.: Feel free to clone this report if you want to track the probably
at least two different issues in here separately.
ACK, kernel image stuff goes into #746550.
Thanks,
Thomas
--
:: WWW: http://fiasko-nw.net/~thomas/ ::
::: Jabber: xmpp:tho...@jabber.fiasko-nw.net :::
:: flickr: http://www.flickr.com/photos/laugufe/ ::
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746213: lua-curl: no Lua 5.2 support
On Wed, Apr 30, 2014 at 10:22:25PM -0700, Igor Bogomazov wrote: and of course do not hesitate writing to me, if I can do more than just this patch Sorry I've been busy. Your patch is very welcome as well as any other help packaging the software. I will apply it as soon as possible. Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746474: portalocker: diff for NMU version 0.5~ds0-0.1
tags 746474 pending thanks Thanks, uploaded. Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709896: squeeze: depends on obsolete thunar-vfs
Control: reassign -1 ftp.debian.org Control: severity -1 wishlist Control: retitle -1 RM: squeeze -- RoM; depends on hal which needs to go On jeu., 2014-05-01 at 00:32 +0200, Michael Biebl wrote: Am 01.05.2014 00:11, schrieb Yves-Alexis Perez: On jeu., 2014-05-01 at 00:05 +0200, Michael Biebl wrote: Did you make any progress on this issue? No, I need to proceed with the removals from unstable though. Ok, thanks for taking care of this. Should we just re-assign this bug then? Yes. Dear ftp-master, since Michael would like to have hal removed also from unstable, and thunar-vfs still needs it (and Squeeze needs thunar-vfs for now), we need to remove them from unstable as well. There's a non-hal port of Squeeze in development, but it's been like these for months or years, so it's unlikely to be released soon When (if) it's released, then it'll go to NEW. Thanks for the work, and regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#746552: kile: Consider not hardcoding Okular as PDF viewer
Package: kile Version: 4:2.1.3-2 Severity: wishlist Dear Maintainer, It would be great if Kile PDF viewing worked by default on non-KDE installs - particularly as KDE is not the default for testing. Currently, after install kile, in order to view a PDF generated by kile, one has to modify the PDF tool (settings-Conf. Kile-Tools-Build-ViewPDF-Command), or attempts to view the generated PDF fail with a message in the log area failed to start. Several possible solutions jump to mind * exo-open * A KilePDF script to detect and launch available binaries Either of these would make Kile work out of the box as an editor under non-KDE installs! Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kile depends on: ii kde-runtime 4:4.11.3-1 ii konsole 4:4.11.3-1 ii libc6 2.18-4 ii libgcc1 1:4.8.2-16 ii libkdecore5 4:4.11.3-2 ii libkdeui5 4:4.11.3-2 ii libkfile4 4:4.11.3-2 ii libkhtml5 4:4.11.3-2 ii libkio5 4:4.11.3-2 ii libkjsapi4 4:4.11.3-2 ii libkparts4 4:4.11.3-2 ii libkrosscore4 4:4.11.3-2 ii libktexteditor4 4:4.11.3-2 ii libnepomuk4 4:4.11.3-2 ii libnepomukutils44:4.11.3-2 ii libphonon4 4:4.7.1-1 ii libqt4-dbus 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-network 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-script 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-svg 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-xml 4:4.8.5+git242-g0315971+dfsg-2 ii libqtcore4 4:4.8.5+git242-g0315971+dfsg-2 ii libqtgui4 4:4.8.5+git242-g0315971+dfsg-2 ii libsoprano4 2.9.4+dfsg-1 ii libstdc++6 4.8.2-16 ii texlive-latex-base 2013.20140408-1 Versions of packages kile recommends: ii dvipng 1.14-2 ii ghostscript 9.05~dfsg-8+b1 ii imagemagick 8:6.7.7.10+dfsg-1 ii psutils 1.17.dfsg-1 ii texlive 2013.20140408-1 Versions of packages kile suggests: ii aspell0.60.7~20110707-1 pn asymptote none pn context none pn dblatex none ii ispell3.3.02-6 pn kbibtex none pn kile-doc none pn kile-l10n none pn latex2htmlnone pn lilypond none pn tex4htnone pn texlive-doc-base none pn texlive-xetex none ii zip 3.0-8 -- 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#745907: [Pkg-systemd-maintainers] Bug#745907: systemd: minidlna does not start on boot
Hi, Perhaps part of a solution for this bug is to include and use the upstream minidlna.service systemd unit, if that is allowed in Debian. This bug sounds like minidlna works fine with SysV init anyway. The unit file has After=network.target. It works for me on my Arch Linux install, which has the unchanged upstream .service file included with its minidlna package. It probably won't help with dynamic network changes though. Regards, Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744119: help with and sponsoring onion upload
I will check how to do the jquery but it might be dificult as onion should be compilable on non debian as well. Is is ok if at compilation time it is decided to use the onion provided one, or the system one? If the system one is used then its is not compiled in (jquery is converted to a C file to be used as static data). About systemd, onion will never force the user to use it. The support is just to compile the functionallity to be able to cooperate better with systemd, if the developer decides so. It is always optional to use systemd, but the library must be prepared. Even if the developer of whatever uses onion decides to support systemd, it still can be used without it. http://0pointer.de/blog/projects/socket-activation.html 2014-05-01 10:00 GMT+02:00 Thomas Goirand z...@debian.org: On 04/25/2014 10:43 PM, David Moreno Montero wrote: Just a quick note to inform that I just removed the sd-daemon.[ch] files and I depend on system provided ones (at libsystemd-daemon-dev). Also fixed jquery, I added the uncompressed one. Shipping non-minified javascript in your source is a requirement of Debian for all source packages, so what you did is a good thing. However, we also require that you use all libraries that are packaged in the system. So you must use the jquery which is in Debian. And yes, you must comply with both rules, which means even if you don't use the jquery which you ship in your source code, it must *not* be minified. Just wanted to make this clear. Currently its not in control / depends, as I want to make my head if it should be enforced or not, but as systemd is on Debian's future, I guess it fits. You shouldn't force your users to use systemd if you can avoid it. We have chosen systemd as default, but our users may not like it and prefer another init system. Please respect the user choices if possible. Cheers, Thomas Goirand (zigo) -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com
Bug#746363: needrestart: uninitialized value by kernel threads
severity 746550 wishlist
Hi Thomas,
Thomas Liske wrote:
At least all of these pids I checked were kernel threads for which the
above behaviour is IIRC normal:
# ps auxwww | fgrep --color '['
root 1 0.0 0.0 13228 668 ?Ss2013 2:21 init [2]
root 2 0.0 0.0 0 0 ?S 2013 0:00 [kthreadd]
But the /proc/$pid/exe symlink is always there, it just doesn't have a
target. Which should be ok for kernel threads.
It was just to late at night... I was already aware of the kernel thread
behavior:
# ignore kernel threads
next unless(defined($ptable-{$pid}-{exec}));
The problem is the second scanning pass which looks for the parent
processes. It seems to happen if a process is a child of a kernel
thread... sadly I could not reproduce it, yet.
Strange. I really wonder what's so different on my boxes. Did you try
it with Debian Unstable kernels? Or rather with Debian Stable kernels?
Maybe there changed something which causes this behaviour. (I haven't
tried 0.8 on Stable yet.)
P.S.: Feel free to clone this report if you want to track the probably
at least two different issues in here separately.
ACK, kernel image stuff goes into #746550.
Ok, downgrading that one to wishlist (via Bcc to control@b.d.o) as it
is probably a seldom corner case and hence more a feature request than
a real bug. At least important is not the proper severity for that
issue. :-)
Regards, Axel
--
,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615196: [Pkg-xfce-devel] Bug#615196: Bug#615196: Please stop using hal
Control: forcemerge -1 709897 Control: severity -1 wishlist Control: retitle -1 RM: thunar-vfs -- RoM; depends on obsolete hal Control: tag -1 -wontfix On mer., 2013-10-16 at 21:08 +0200, Yves-Alexis Perez wrote: On Wed, 2013-10-16 at 16:01 +0200, Michael Biebl wrote: Am 16.10.2013 15:58, schrieb Michael Biebl: Ping? What's the status on getting squeeze updated? If squeeze is not updated, would you be ok with removing it from the archive? It's not like it couldn't be re-introduced whenever it is fixed. The status didn't change, the strategy from us was to remove it from testing for now and not let it re-enter until a non-hal version exists. Just a side note: afaics the last release is from 24-Feb-2008. Is this package still actively developed? There's more recent code in git (http://git.xfce.org/apps/squeeze/), and especially a non hal port, but I'm unsure its state at that point (thus the reason for the testing removal). Let's proceed with the removal from unstable as well. ftp-master, same thing as squeeze, thunar-vfs uses hal so Michael wants it to go from unstable. Thanks for your work, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#746552: [Pkg-kde-extras] Bug#746552: kile: Consider not hardcoding Okular as PDF viewer
Hi, It would be great if Kile PDF viewing worked by default on non-KDE installs - particularly as KDE is not the default for testing. Currently, after install kile, in order to view a PDF generated by kile, one has to modify the PDF tool (settings-Conf. Kile-Tools-Build-ViewPDF-Command), or attempts to view the generated PDF fail with a message in the log area failed to start. Several possible solutions jump to mind * exo-open * A KilePDF script to detect and launch available binaries Either of these would make Kile work out of the box as an editor under non-KDE installs! exo-open is Xfce-specific. However, there's xdg-open, which is more general and would therefore IMHO be more suited. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745687: [Pkg-javascript-devel] Bug#745687: Bug#745687: new upstream version (2.x series)
Le jeudi 01 mai 2014 à 11:15 +0200, Jérémy Lal a écrit : Related to the point above, it's interesting to note that dryice is a good example of what we could ask upstream to merge back into source-map. I'll leave that to you too. I added an issue: https://github.com/mozilla/source-map/issues/108 I missed the fact that dryice is a devDependencies of projects that are well alive. Packaged it must be, then. Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746553: postgrey: Postgrey won't start with --pidfile option
Package: postgrey
Version: 1.32-6.1
Severity: important
Postgrey won't start with --pidfile option given whatever the directory or the
permissions. No messages in logs.
-- System Information:
Debian Release: 6.0.9
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-042stab084.12 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages postgrey depends on:
ii adduser3.112+nmu2add and remove users and groups
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii libberkeleydb-perl 0.42-1~squeeze1 use Berkeley DB 4 databases from P
ii libnet-dns-perl0.66-2Perform DNS queries from a Perl sc
ii libnet-server-perl 0.97-1An extensible, general perl server
ii perl 5.10.1-17squeeze6 Larry Wall's Practical Extraction
ii ucf3.0025+nmu1 Update Configuration File: preserv
Versions of packages postgrey recommends:
ii libdigest-sha1-perl 2.13-1 NIST SHA-1 message digest algorith
ii libnet-rblclient-perl 0.5-2Queries multiple Realtime Blackhol
ii libparse-syslog-perl1.10-1 Perl module for parsing syslog ent
ii postfix 2.7.1-1+squeeze1 High-performance mail transport ag
postgrey suggests no packages.
-- Configuration Files:
/etc/init.d/postgrey changed:
set -e
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/postgrey
NAME=postgrey
DESC=postfix greylisting daemon
PIDFILE=/var/run/postgrey/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
test -x $DAEMON || exit 0
. /lib/lsb/init-functions
if [ -r /etc/default/$NAME ]
then
. /etc/default/$NAME
fi
POSTGREY_OPTS=-d $POSTGREY_OPTS
if [ -z $POSTGREY_TEXT ]; then
POSTGREY_TEXT_OPT=
else
POSTGREY_TEXT_OPT=--greylist-text=$POSTGREY_TEXT
fi
ret=0
case $1 in
start)
log_daemon_msg Starting $DESC $NAME
if start-stop-daemon --start --oknodo --quiet \
--pidfile $PIDFILE --name $NAME \
--startas $DAEMON -- $POSTGREY_OPTS $POSTGREY_TEXT_OPT
then
log_end_msg 0
else
ret=$?
log_end_msg 1
fi
;;
stop)
log_daemon_msg Stopping $DESC $NAME
if start-stop-daemon --stop --oknodo --quiet \
--pidfile $PIDFILE --name $NAME
then
log_end_msg 0
else
ret=$?
log_end_msg 1
fi
rm -f $PIDFILE
;;
reload|force-reload)
log_action_begin_msg Reloading $DESC configuration...
if start-stop-daemon --stop --signal 1 --quiet \
--pidfile $PIDFILE --name $NAME
then
log_action_end_msg 0
else
ret=$?
log_action_end_msg 1
fi
;;
restart)
$0 stop
$0 start
ret=$?
;;
status)
status_of_proc -p $PIDFILE $DAEMON $NAME 2/dev/null
ret=$?
;;
*)
echo Usage: $SCRIPTNAME
{start|stop|restart|reload|force-reload|status} 2
exit 1
;;
esac
exit $ret
-- debconf information:
postgrey/1.32-3_changeport:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703855: Aw: Re: Bug#703855: netsniff-ng does not depend on package geoip-database
On 03/25/2013 08:03 PM, Daniel Borkmann wrote: On 03/25/2013 07:44 PM, liste_fran...@gmx.de wrote: Right, so how does netsniff-ng then not depend on geoip-database if you need to have the database to run it? Yep, so I tried to say that with my headline: The bug is that 'netsniff-ng does not depend on package geoip-database'. Makes sense! I thought the other way round. :-) Last time, I had a look at geoip-database, it's s simple shell script that downloads these databases through wget, nothing more. geoip-database is a data-only-package ( /usr/share/GeoIP/GeoIP.dat ), the package you might think of is geoip-database-contrib. So you might want to file a bug against the geoip-database package for inclusion of GeoLite City Good suggestion! Done with Bug#703915. Cool, thanks! Actually, what would also be good regarding GeoIP databases in that package might be to have an automatic updater in the background that could be installed *if the user wishes* which automatically updates the databases on the system to prevent a drift of measurement data over time into false/deprecated values. Maybe scheduled through a cronjob or so, but the time of update would need to be randomized somehow, not that all systems ask maxmind servers at once. I think a lot of tools use libGeoIP and could benefit from that. Probably most users just update once (when installing this packet) and that's it. You can do things like ... astraceroute -u ... and all needed databases will be automatically updated. So we don't strictly depend on this script. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746554: ITP: fteproxy -- programmable proxy for censorship circumvention
Package: wnpp Severity: wishlist Owner: Rolf Leggewie debian-b...@rolf.leggewie.biz * Package name: fteproxy Version : 0.2.13 Upstream Author : Kevin P. Dyer kpd...@gmail.com * URL : https://fteproxy.org * License : GPL 3+ Programming Lang: (C++, Python) Description : programmable proxy for censorship circumvention fteproxy provides transport-layer protection to resist keyword filtering, censorship and discrimantory routing policies. Its job is to relay datastreams, such as web browsing traffic, by encoding the stream into messages that satisfy a user-specified regular expression and are thus considered safe by the censors. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726916: grub-pc: grub is very slow and no welcome to grub is shown
2014-04-30 17:45 GMT+02:00 Anders Lagerås anders.lage...@gmail.com:
On 2014-04-30 14:46, Agustin Martin wrote:
On Tue, Apr 29, 2014 at 11:20:47AM +0200, Agustin Martin wrote:
On Sun, Oct 20, 2013 at 04:36:56PM +0200, Anders Lagerås wrote:
Package: grub-pc
Version: 2.00-19
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Maintainer,
Grub is very slow, it takes like 10 minutes of waiting until the kernel is
being loaded.
Before that no welcome to grub is shown and no boot menu, the screen is
just black.
Hi,
Same thing has started to happen here, with 2.02~beta2-9 installed. During
last week it started to show these symptoms, but with a shorter waiting
time.
However, today I had to wait for 10 minutes until grub showed the boot menu,
no welcome to grub shown as in original report.
Hi,
Seems I got the reason for this problem, at least in my system. Apparently a
test in 40grub2 is only valid for LANG={C,en_*} and causes problems for other
LANG values. It has already been reported to Ubuntu launchpad, and as
mentioned in that bug report, the same delay happens when running
update-grub, becoming larger with each run.
https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1176652
[40grub2 gets confused for menuentry generated in other languages]
My grub.cfg had become as large as 7441128. Renamed to something else in
case it was needed and reinstalled grub2. Size of new grub.cfg is 28139, far
smaller, and problem seems to have disappeared.
Anders, Is your grub.cfg also oversized?
Regards,
I don't know. It started to work again after newer version ogf grub was
installed and with the current version of grub it works as supposed. At
least now grub.cfg is 7312 bytes.
Hi, thanks for the reply.
Just noticed that you already added grub.cfg to your original report.
It does not look bloated, so may be the reason was different for your
bug, unless you sent the report from a different box. Also, it does
not look the worst scenario pointed to in the launchpad report (system
with one boot partition and a few Linux root partitions, like is at my
box)
Do you remember similar long delay when running update-grub? It may
have been run either manually or implicitly during configuration of
anything calling it (kernels, udev, grub, )
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746555: libre-ocaml-dev: should provide libre-ocaml-dev-XXXXXX
Package: libre-ocaml-dev
Version: 1.2.1-1+b1
Severity: important
Tags: patch
Hi, libre-ocaml-dev doesn't provide any libre-ocaml-dev-XX, which makes
it difficult to use with any other ocaml package that depends on it and
generates its dependencies with dh-ocaml. Please add to debian/control:
Provides: ${ocaml:Provides}
Mehdi: if you wish I can do the upload.
-Ralf.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libre-ocaml-dev depends on:
ii libc6 2.18-5
ii ocaml-nox [ocaml-nox-4.01.0] 4.01.0-3
Versions of packages libre-ocaml-dev recommends:
ii ocaml-findlib 1.4.1-1
libre-ocaml-dev 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#746556: RFP: MailWebsiteChanges -- Python script to keep track of website updates; sends email notifications and provides RSS2 feed
Package: wnpp Severity: wishlist * Package name: MailWebsiteChanges Version : 1.7 Upstream Author : DG debiang...@gmx.de * URL : https://github.com/Debianguru/MailWebsiteChanges * License : GPL Programming Lang: Python Description : Python script to keep track of website updates; sends email notifications and provides RSS2 feed Python script to keep track of website changes; sends email notifications on updates and/or also provides an RSS feed To specify which parts of a website should be monitored, XPath selectors (e.g. //h1), CSS selectors (e.g. h1), and regular expressions can be used (just choose the tools you like!). MailWebsiteChanges is related to PageMonitor for Chrome and AlertBox / Check4Change for Firefox. However, instead of living in your web browser, you can run it independently from command line / bash and install it as a simple cron job running on your linux server. - why is this package useful/relevant? It can run as a cronjob, frequently polling websites for changes. The application notifies the user by sending mail messages or updating an RSS2 feed in case of changes. - is it a dependency for another package? No. - do you use it? Yes, every day. I uploaded it to Github for public availability. - if there are other packages providing similar functionality, how does it compare? There are related tools like urlwatch, however, MailWebsiteChanges offers much more finegranular features like CSS/XPath/regex parsing of XML/HTML content, allowing for monitoring specific parts of websites, not just the whole content that is delivered by the webserver. It also provides an RSS2 feed. - how do you plan to maintain it? inside a packaging team I plan to continue development of this tool on github and would be happy to help packaging it -- however, since I never did packaging before, I would highly appreciate your help. Sourcecode is availabile here: https://github.com/Debianguru/MailWebsiteChanges Requires Python3, lxml, and cssselect -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746515: [Debichem-devel] Bug#746515: diff NMU for 5.0.2-5.1
Hi Michael, 2014-05-01 2:51 GMT+02:00 Michael Banck mba...@debian.org: After thinking about it some more, wouldn't it just be as good to remove the if/then/else hack? I didn't follow closely, but isn't the libmpich SONAME now again in line with the ARCH_DEFAULT_MPI_IMPL variable? Indeed, you are completely right! The updated diff is attached. Thanks Anton nmu2.debdiff Description: Binary data
Bug#746558: padre: please enable SCSS support in CSS lexer
Package: padre Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Padre looks cool. So I want to use it for webdesign the cool way - by use of Sassy CSS (SCSS). Scintilla added SCSS support in version 3.0.3, and for Geany it can be enabled by adding the following to /usr/share/geany/filetypes.css (or corresponding file below $HOME): [lexer_properties] lexer.css.scss.language=1 Something similar gotta be possible for Padre - and should IMO then be done by default. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJTYi4gXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWnlwH+gKXr32KIQiGjftsaVszBrqW 1G2fImxHk9JIgv7wruV8OOPFryz+HygKRJ5pkph7s8C+7oazhek+nboypBWMFLGQ Y/cxyynrVr0wFFhJPQm2OFdlzQJbkjfEJHwTtj9vi8qqFcztgt08AXltzTwnpSm8 O1cgERr39oIC7lAFiX0HTxYIq+7Ek+DkBu/OJ69roJebbxwGX0ueyHDmxbe010RQ +kfa9FbegejlyZ2E2elpoFyWeXNm5Ez0cH8y2b8FKS1LOXJCp8htqPghDUVGh4tq 8s9Sy4D93Trrpv8gNF3JxdxJG7BeYjyoAUl2to1oEwjTBdGuJVQeldDVV4FJcg4= =Ww/G -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#746559: padre: should call x-terminal-emulator (not xterm)
Package: padre Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Padre has a feature to run stuff in a terminal. Trying it out just spits an error at my system, however - about being unable to locate xterm. I don't have xterm installed, I use urxvt - and have configured x-terminal-emulator accordingly, which I believe Padre should respect. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJTYi8+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWeT4H/0zohK4pe+ouXC8n339azcai mMQtGvbjI8qmWeJ2AvSOt45NRZLjrCbn9hyahC5M0cVCk6X9pFmOGft5vvs3aAqh 5LzAghahTTyYEzDZwIaDQYjFJBYGmMQiqSAEO+3QbMB9Gvjw/PLAa3Hj32wQgtuL fy41DgDxNqmQMXO37Z1tqOgr+but098WFYq/2NNfEs2BZyYfOHw7UFTOipvipkZr aAZPVFvNLXV3+oHQRd/h1DkfB+DhLLTUIgX1Ypkao2e2P4Jw2kDG89WDO7ZIqy7v gkFoDLTQQpj841lDnR2PbbCEnoI0Gq6j2gX7uXsLT0lLwu9yrMFIlXtgIT7JatQ= =vgIH -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#746144: impressive: FTBFS: ! LaTeX Error: File `pgfcore.sty' not found.
control: tags -1 +patch Hi, Just adding build-depends solves this FTBFS, patch attached. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane diff -u impressive-0.10.3+svn61/debian/changelog impressive-0.10.3+svn61/debian/changelog --- impressive-0.10.3+svn61/debian/changelog +++ impressive-0.10.3+svn61/debian/changelog @@ -1,3 +1,11 @@ +impressive (0.10.3+svn61-1.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/control +- add Build-Depends: texlive-pictures to fix FTBFS (Closes: #746144) + + -- Hideki Yamane henr...@debian.org Thu, 01 May 2014 17:28:18 +0900 + impressive (0.10.3+svn61-1) unstable; urgency=low * Fresh upstream snapshot diff -u impressive-0.10.3+svn61/debian/control impressive-0.10.3+svn61/debian/control --- impressive-0.10.3+svn61/debian/control +++ impressive-0.10.3+svn61/debian/control @@ -5,6 +5,7 @@ Build-Depends-Indep: python, perl, texlive-latex-base, latex-beamer, texlive-fonts-recommended, + texlive-pictures, xvfb, xauth, python-opengl, python-pygame, python-imaging, libgl1-mesa-dri, poppler-utils | xpdf-utils (= 3.02-2), pdftk,
Bug#726916: grub-pc: grub is very slow and no welcome to grub is shown
Hello.
No I don't remember it taking very long.
Mvh Anders Lagerås
2014-05-01 12:52 GMT+02:00 Agustin Martin agmar...@debian.org:
2014-04-30 17:45 GMT+02:00 Anders Lagerås anders.lage...@gmail.com:
On 2014-04-30 14:46, Agustin Martin wrote:
On Tue, Apr 29, 2014 at 11:20:47AM +0200, Agustin Martin wrote:
On Sun, Oct 20, 2013 at 04:36:56PM +0200, Anders Lagerås wrote:
Package: grub-pc
Version: 2.00-19
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Maintainer,
Grub is very slow, it takes like 10 minutes of waiting until the
kernel is being loaded.
Before that no welcome to grub is shown and no boot menu, the screen
is just black.
Hi,
Same thing has started to happen here, with 2.02~beta2-9 installed.
During
last week it started to show these symptoms, but with a shorter waiting
time.
However, today I had to wait for 10 minutes until grub showed the boot
menu,
no welcome to grub shown as in original report.
Hi,
Seems I got the reason for this problem, at least in my system.
Apparently a
test in 40grub2 is only valid for LANG={C,en_*} and causes problems for
other
LANG values. It has already been reported to Ubuntu launchpad, and as
mentioned in that bug report, the same delay happens when running
update-grub, becoming larger with each run.
https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1176652
[40grub2 gets confused for menuentry generated in other languages]
My grub.cfg had become as large as 7441128. Renamed to something else in
case it was needed and reinstalled grub2. Size of new grub.cfg is
28139, far
smaller, and problem seems to have disappeared.
Anders, Is your grub.cfg also oversized?
Regards,
I don't know. It started to work again after newer version ogf grub was
installed and with the current version of grub it works as supposed. At
least now grub.cfg is 7312 bytes.
Hi, thanks for the reply.
Just noticed that you already added grub.cfg to your original report.
It does not look bloated, so may be the reason was different for your
bug, unless you sent the report from a different box. Also, it does
not look the worst scenario pointed to in the launchpad report (system
with one boot partition and a few Linux root partitions, like is at my
box)
Do you remember similar long delay when running update-grub? It may
have been run either manually or implicitly during configuration of
anything calling it (kernels, udev, grub, )
Regards,
--
Agustin
Bug#731536: libre2-dev in unstable
Same here, we are currently working on fteproxy which depends on libre2-dev at build-time. Please release to unstable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731536: libre2-dev in unstable
Same here, we are currently working on fteproxy which depends on libre2-dev at build-time. Please release to unstable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746560: please package tig 2.0.1
Package: tig Version: 1.2.1-1 Please package tig 2.0.1 available at: http://jonas.nitro.dk/tig/releases/tig-2.0.1.tar.gz signature.asc Description: Digital signature
Bug#746561: [libimobiledevice4] segfault when connecting ipad4 device (ios 7.1.1)
Package: libimobiledevice4 Version: 1.1.6+dfsg-1 Severity: normal --- Please enter the report below this line. --- libimobiledevice4 causes when connecting ipad4 device (IOS 7.1.1) [ 243.704360] iphone-set-info[7907]: segfault at 8 ip 7f2235d42ada sp 78135be8 error 4 in libc-2.18.so[7f2235cc1000+1a] [ 244.008072] ipheth-pair[8083]: segfault at 8 ip 7f443db2dada sp 7fffbcd82e78 error 4 in libc-2.18.so[7f443daac000+1a] [ 244.337142] gvfs-afc-volume[7647]: segfault at 8 ip 7fcbc79a9ada sp 7fcbc49b8b58 error 4 in libc-2.18.so[7fcbc7928000+1a] [ 575.098500] ideviceinfo[8260]: segfault at 8 ip 7f0dfcd8bada sp 7fffc3a02558 error 4 in libc-2.18.so[7f0dfcd0a000+1a] [ 591.600700] ideviceinfo[8262]: segfault at 8 ip 7fd8a108eada sp 7fffa1b80648 error 4 in libc-2.18.so[7fd8a100d000+1a] --- System information. --- Architecture: amd64 Kernel: Linux 3.13-1-amd64 Debian Release: jessie/sid 500 testing-proposed-updates ftp.icm.edu.pl 500 testing-proposed-updates ftp.debian.org 500 testing www.deb-multimedia.org 500 testing security.debian.org 500 testing ftp.icm.edu.pl 500 testing ftp.debian.org 500 stable dl.google.com --- Package information. --- Depends (Version) | Installed ==-+-=== libc6 (= 2.14) | libgcrypt11 (= 1.5.1) | libgnutls26 (= 2.12.17-0) | libplist2 (= 1.11) | libtasn1-6 (= 3.4-0) | libusbmuxd2 (= 1.0.9) | Recommends (Version) | Installed =-+-=== usbmuxd | 1.0.8-5 Suggests (Version) | Installed ===-+-=== libusbmuxd-tools | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746097: gogglesmm: FTBFS: src/GMAudioScrobbler.cpp:34:20: fatal error: gcrypt.h: No such file or directory
control: tags -1 +patch Hi, Just adding build-depends solves this FTBFS, patch attached. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane diff -Nru gogglesmm-0.12.7/debian/changelog gogglesmm-0.12.7/debian/changelog --- gogglesmm-0.12.7/debian/changelog 2013-10-04 17:32:22.0 +0900 +++ gogglesmm-0.12.7/debian/changelog 2014-05-01 20:37:17.0 +0900 @@ -1,3 +1,11 @@ +gogglesmm (0.12.7-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control +- add Build-Depends: libgcrypt20-dev to fix FTBFS (Closes: #746097) + + -- Hideki Yamane henr...@debian.org Thu, 01 May 2014 20:36:30 +0900 + gogglesmm (0.12.7-2) unstable; urgency=low * Changed dependencies from libxine-dev to libxine2-dev, closes: #724762 diff -Nru gogglesmm-0.12.7/debian/control gogglesmm-0.12.7/debian/control --- gogglesmm-0.12.7/debian/control 2013-09-28 05:14:22.0 +0900 +++ gogglesmm-0.12.7/debian/control 2014-05-01 20:35:43.0 +0900 @@ -4,7 +4,7 @@ Maintainer: Hendrik Rittich hendrik.ritt...@gmx.de Homepage: http://code.google.com/p/gogglesmm/ Build-Depends: debhelper (= 7), dpkg-dev (= 1.16.1~), -libdbus-1-dev, libtag1-dev, +libdbus-1-dev, libtag1-dev, libgcrypt20-dev, libfox-1.6-dev, libxrandr-dev, libxine2-dev, libsqlite3-dev (= 3.4), libbz2-dev, imagemagick Standards-Version: 3.9.4
Bug#745663: hyperestraier doesn't recurse CIFS directories
hi, On Thu, Apr 24, 2014 at 6:18 AM, Paolo Zandonella paolo.zandone...@libero.it wrote: estcmd gather command with 'dir' parameter as a CIFS mounted directory doesn't list subdirectory files. The same for command 'estcmd scandir cifs dir'. Compiling adding -D_FILE_OFFSET_BITS=64 to CFLAGS in Makefile (after configure) solves the problem. I've found the solution here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550449. I'm trying to apply this fix at: http://anonscm.debian.org/gitweb/?p=collab-maint/hyperestraier.git;a=shortlog;h=refs/heads/745663-fix-cifs Could you please test above, which make it or not? regards, -- KURASHIKI Satoru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746562: xserver-xephyr: large screen size causes immediate exit
Package: xserver-xephyr Version: 2:1.15.1-1 Severity: important ”Xephyr :9 -screen 4096x4096” shortly displays a black screen and exits silently after that. Smaller screen sizes are no problem, e.g. “Xephyr :9 -screen 4096x1024” works as expected. 2:1.15.99.902-1 from experimental has the same problem. This is a regression: 2:1.14.5-1 works fine, and so did all the previous versions I used to use over the years. (In case you’re wondering: Xephyr is useful for taking huge screenshots from things like Google Street View. ☺) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735648: x11vnc: buffer overflow detected: x11vnc terminated
Hi, this is the complete backtrace of my issue (amd64 system): = (gdb) bt #0 0x749fd3a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x74a004c8 in __GI_abort () at abort.c:89 #2 0x74a368f4 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x74b2c103 *** %s ***: %s terminated\n) at ../sysdeps/posix/libc_fatal.c:175 #3 0x74abcb97 in __GI___fortify_fail (msg=msg@entry=0x74b2c09a buffer overflow detected) at fortify_fail.c:31 #4 0x74abbc20 in __GI___chk_fail () at chk_fail.c:28 #5 0x74abcb07 in __fdelt_chk (d=optimized out) at fdelt_chk.c:25 #6 0x77b91f88 in rfbProcessNewConnection (rfbScreen=rfbScreen@entry=0xa275c0) at sockets.c:407 #7 0x77b924b8 in rfbCheckFds (rfbScreen=rfbScreen@entry=0xa275c0, usec=0) at sockets.c:306 #8 0x77b897bd in rfbProcessEvents (screen=0xa275c0, usec=optimized out) at main.c:1101 #9 0x0049b801 in ?? () #10 0x004605d2 in ?? () #11 0x00410777 in ?? () #12 0x749e9b45 in __libc_start_main (main=0x40d8d0, argc=11, argv=0x7fffe748, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffe738) at libc-start.c:287 #13 0x0041a78a in ?? () = As Shaddy wrote I think that the new libvncserv0 library (0.9.9+dfsg-5) will solve this problem. This bug can be closed. Thanks to all... :-) Gianluca On Monday 28 April 2014 23:38:09 Shaddy Baddah wrote: Hi, On 2014/04/24 04:02+0800, Florian Schlichting wrote: I'm downgrading this bug as I'm unable to reproduce it (doesn't affect everybody, does not make package unuseable as such) and I think it's unclear that this is actually a bug in x11vnc, rather than in one of the libraries it uses. The suggested patch is dubious: it is not changing any x11vnc code but instructs the build process to build its own version of libvncserver rather than use the shared library installed on the system. If that's really where the problem lies, this is a libvncserver bug. I notice both the Debian and Ubuntu reporters use i386 systems, whereas I'm on amd64. Has anybody tried recompiling x11vnc _without_ the patch (as in, just recompile the package against the current set of shared libraries) and checked if that's enough to fix things? And to produce a more useful backtrace it would probably help to have the libvncserver0-dbg and libc6-dbg packages installed. I have just filed Bug#746260 against libvncserver0 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746260) and if I am right about that one, it confirms that you were right that the bug is not in x11vnc, but in its main-use library. You are also probably right about system configuration, as I suspect I encounter the bug because I don't have my nic configured for ipv6. No bound ipv6 socket induces the buffer overflow error. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746563: python-support (build-)depends checks
Package: lintian Version: 2.5.22.1 Severity: normal Tags: patch python-support is deprecated in favour of dh_python2, as per http://packages.qa.debian.org/p/python-support/news/20110627T204800Z.html The attached patch adds two new warnings checking whether the python-support is listed as build-dependency or dependency. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.24.51.20140425-1 ii bzip2 1.0.6-5 ii diffstat 1.58-1 ii file 1:5.18-1 ii gettext0.18.3.2-1 ii hardening-includes 2.5 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b1 ii libarchive-zip-perl1.37-2 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.36-1 ii libdpkg-perl 1.17.9 ii libemail-valid-perl1.192-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-2 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.06~01-2 ii libtimedate-perl 2.3000-2 ii liburi-perl1.60-1 ii man-db 2.6.7.1-1 ii patchutils 0.3.3-1 ii perl [libdigest-sha-perl] 5.18.2-2+b1 ii t1utils1.37-2 Versions of packages lintian recommends: ii libautodie-perl 2.25-1 ii libperlio-gzip-perl 0.18-2 ii perl-modules [libautodie-perl] 5.18.2-2 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.17.9 ii libhtml-parser-perl3.71-1+b1 ii libtext-template-perl 1.46-1 pn libyaml-perl none ii xz-utils 5.1.1alpha+20120614-2 -- no debconf information diff -Nru lintian-2.5.22.1/checks/fields.desc lintian-2.5.22.2/checks/fields.desc --- lintian-2.5.22.1/checks/fields.desc 2014-03-30 11:56:39.0 +0200 +++ lintian-2.5.22.2/checks/fields.desc 2014-05-01 14:34:08.0 +0200 @@ -1222,3 +1222,18 @@ . Instead these permissions are granted via dak-commands files. Ref: https://lists.debian.org/debian-devel-announce/2012/09/msg8.html + +Tag: build-depends-on-python-support +Severity: normal +Certainty: certain +Info: This package build-depends on python-support. + python-support is deprecated and has been replaced by dh_python2. +Ref: http://wiki.debian.org/Python/TransitionToDHPython2 + +Tag: depends-on-python-support +Severity: normal +Certainty: certain +Info: This package depends on python-support. + python-support is deprecated and has been replaced by dh_python2. +Ref: http://wiki.debian.org/Python/TransitionToDHPython2 + diff -Nru lintian-2.5.22.1/checks/fields.pm lintian-2.5.22.2/checks/fields.pm --- lintian-2.5.22.1/checks/fields.pm 2014-03-30 11:56:39.0 +0200 +++ lintian-2.5.22.2/checks/fields.pm 2014-05-01 14:39:27.0 +0200 @@ -843,6 +843,10 @@ $pkg !~ m/-(?:dev|docs?|tools|bin)$/ $part_d_orig =~ m/-docs?$/); +tag 'depends-on-python-support' + if ( ($field eq 'depends' || $field eq 'pre-depends') + $d_pkg eq 'python-support'); + # default-jdk-doc must depend on openjdk-X-doc (or # classpath-doc) to be useful; other packages # should depend on default-jdk-doc if they want @@ -1033,6 +1037,9 @@ tag 'build-depends-on-build-essential', $field if ($d_pkg eq 'build-essential'); +tag 'build-depends-on-python-support' + if ($d_pkg eq 'python-support'); + # no tidy, tag name too long tag 'depends-on-build-essential-package-without-using-version', #
Bug#746488: linux-image-2.6.32-5-amd64: Random shutdowns from signal 15
What complete log are you looking for when all it says is signal 15 sent to rsyslogd? I've went through every log and nothing is showing a reason as to why it went down or what sent the signal 15. May 1 06:14:01 ace snmpd[1726]: error on subcontainer 'ia_addr' insert (-1) May 1 06:14:01 ace snmpd[1726]: error on subcontainer 'ia_addr' insert (-1) May 1 06:14:01 ace snmpd[1726]: error on subcontainer 'ia_addr' insert (-1) May 1 06:14:04 ace root: root [1733728]: May/01 - 06:14:02 /usr/bin/vmstat 1 3 [0] May 1 06:14:11 ace kernel: Kernel logging (proc) stopped. May 1 06:14:11 ace rsyslogd: [origin software=rsyslogd swVersion=4.6.4 x-pid=1363 x-info=http://www.rsyslog.com;] exiting on signal 15. May 1 07:00:27 ace kernel: imklog 4.6.4, log source = /proc/kmsg started. May 1 07:00:27 ace rsyslogd: [origin software=rsyslogd swVersion=4.6.4 x-pid=1582 x-info=http://www.rsyslog.com;] (re)start May 1 07:00:27 ace kernel: [0.00] Initializing cgroup subsys cpuset May 1 07:00:27 ace kernel: [0.00] Initializing cgroup subsys cpu May 1 07:00:27 ace kernel: [0.00] Linux version 2.6.32-5-amd64 (Debian 2.6.32-48squeeze5) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Apr 9 19:24:34 UTC 2014 May 1 07:00:27 ace kernel: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=db2d279a-afb3-4ea5-906a-bbb4ab04a8ce ro quiet pcie_aspm=off acpi=off noapic noacpi And in regards to the acpi/apic, we have no use for it. That's usually the first thing I disable if there are unexpected shutdown issues like this. Does this keep the system from getting a signal 15? -Original Message- From: Bastian Blank [mailto:wa...@debian.org] Sent: Thursday, May 01, 2014 1:23 AM To: Justin McZeal; 746...@bugs.debian.org Subject: Re: Bug#746488: linux-image-2.6.32-5-amd64: Random shutdowns from signal 15 Control: tag -1 moreinfo On Wed, Apr 30, 2014 at 09:25:34AM -0500, Justin McZeal wrote: It seems like we are getting random shutdowns, typically sometime between 7-9am CST. The last message in the logs is that a signal 15 was sent to all processes. Due to the nature of our business, we don't keep the server down long enough to leave time for investigation via DRAC. There are no services or crons that I know of that would randomly send a signal 15 to all processes. When this occurs, the console states that rsyslogd has stopped. We are in the process of making a Debian 7 server to transfer to, in case it's an OS related issue. The kernel does no random shutdowns for fun. Please show the _complete_ log. ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=db2d279a-afb3-4ea5-906a-bbb4ab04a8ce ro quiet pcie_aspm=off acpi=off noapic noacpi Are you kidding? You disable critical parts of current x86 architecture and expect it to work? Bastian -- A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0
Bug#614108: Pan marks articles read when first visiting group during pan session
Hello Sorry for the long delay in replying. Do you still have this problem with Pan 0.139 ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.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#746144: impressive: FTBFS: ! LaTeX Error: File `pgfcore.sty' not found.
great -- thanks -- will upload with your patch shortly On Thu, 01 May 2014, Hideki Yamane wrote: control: tags -1 +patch Hi, Just adding build-depends solves this FTBFS, patch attached. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#478193: uw-imap patch
We’ve done some further testing of this and deployed to our production servers, and I can confirm my patch works fine. Any chance this can be added into the Debian package? signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#742858: asunder: broken logrotate file
control: reopen -1 control: found -1 2.5-2 control: notfixed -1 2.5-2 On Sun, Apr 13, 2014 at 09:21:48PM +0100, Cleto Martín wrote: Yes, you are right. It is a packaging mistake, sorry. I'll remove in the next release. Thanks for your report. Removing the file from the packaging is not enough in this case. As it is a conffile, those are not removed on package upgrades. Please use dpkg-maintscript-helper from dpkg to remove the stale logrote file. Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746564: minidlna doesn't work - upnpsoap sql error
Package: minidlna Version: 1.0.24+dfsg-1 Severity: important Dear Maintainer, after installing and configuring minidlna it only worked once. Since I was trying to access a second time via vlc I got this error: [2014/05/01 14:33:38] upnpsoap.c:753: error: UPnP SOAP response cut short, to not exceed the max response size [2097152]! [2014/05/01 14:33:38] upnpsoap.c:1302: warn: SQL error: callback requested query abort Rebuilding the database, restarting minidlna, rebuilding from sid-source didn't change anything. So minidlna seems to not work anymore. Best regards, Martin -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minidlna depends on: ii adduser 3.113+nmu3 ii libavformat53 [libavformat-extra-53] 6:0.8.10-1 ii libavutil51 [libavutil-extra-51] 6:0.8.10-1 ii libc6 2.13-38+deb7u1 ii libexif12 0.6.20-3 ii libflac8 1.2.1-6 ii libid3tag00.15.1b-10 ii libjpeg8 8d-1 ii libogg0 1.3.0-4 ii libsqlite3-0 3.7.13-1+deb7u1 ii libvorbis0a 1.3.2-1.3 ii lsb-base 4.1+Debian8+deb7u1 minidlna recommends no packages. minidlna suggests no packages. -- Configuration Files: /etc/minidlna.conf changed: media_dir=A,/home/minidlna/Musik media_dir=V,/home/minidlna/Videos log_level=warn root_container=. network_interface=eth0 port=8200 friendly_name=Media serial=12345678 model_number=1 inotify=yes album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg -- 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#738339: stack-gobbling recursive exit recursion
There's an issue with the qhull library package in the Debian tracker, For qhull2012, the file pointer arguments for qh_new_qhull can no longer be null - this results in the program going into infinite recursion between qh_fprintf and qh_error, as qh_error tries to print, and qh_fprintf raises calls the error function, as the output pointer is null. See https://bugs.debian.org/738339 for further details. It's clear from the source code what's going on, but I'm not sure about the right way to break the recursion, so I didn't try to patch around it. And maybe a null FILE pointer should send output to stderr instead of exiting the program? That's a design decision, but I would note that the lintian, the debian nit-picking utility, gives an shlib-calls-exit for libqhull6, http://lintian.debian.org/tags/shlib-calls-exit.html so there a pretty strong prior among some people that libraries have no business calling exit(). Anyway ... if you wish, please feel free to discuss the issue on the Debian bug tracker, i.e., CC: 738...@bugs.debian.org. And if a patch to address this pops up, maybe in your git repo or whatever, feel free to send me a note and I'll rush it into the Debian package. Cheers, --Barak. PS If you have any issues or suggestions wrt the Debian package, please let me know. -- 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#746565: glpi depends only on php5-mysql, although it also works with php5-mysqlnd
Package: glpi Version: 0.83.31-1 Severity: normal Dear Maintainer, php5-mysqlnd is a compatible drop-in replacement for php5-mysql. The API is identical. Depending on php5-mysql with only php4-mysql an alternative (which btw. was removed from Debian a long time ago, before Squeeze even), causes APT to forcibly remove php5-mysqlnd and forces the installation of php5-mysql instead, unnecessarily. Please change the corresponding dependency of the glpi package from: php5-mysql | php4-mysql to: php5-mysql | php5-mysqlnd in stable, testing and unstable. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736214: reportbug: SMTP transmission issues can cause complete loss of bug report
tag 736214 confirmed severity 736214 important thanks Hi, I can confirm this bug, at least parts of it. If something goes wrong on the 'send via mail' part, it is not possible to recover the bug report. This is very bad, since a bug submitter is forced to rewrite his/her entire bug report. At this point many to-be bug reporters will throw the towel and leave the bug unreported, I think. And no, 'fix your mail setup' is not an option. If the user notices that the reportbug mail gets lost, (s)he needs a backup to resend after fixing their MTA/network/whatever. Right now there is no such backup. This should be fixed as soon as possible, at least keep the /tmp/reportbug-* file containing the report and point the user to them. Cheers, Julius P.S.: re-tagging as important (not grave), because it's very annoying. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746436: evolution-data-server: Unable to read any messages
Hi Paul, On Wed, Apr 30, 2014 at 01:16:44AM +0200, Paul Menzel wrote: Package: evolution-data-server Version: 3.12.0-1 Severity: grave Tags: upstream Justification: renders package unusable Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=728976 Control: found -1 3.12.1-1 Dear Debian folks, upgrading from Evolution Data Server 3.8.5 to 3.12.x it is impossible to read messages. They are not shown. Even building Evolution Data Server from the upstream branch `evolution-data-server-3-12` with the commit below does not help. commit 4615a98c7be1e3f8d23aa8a1c4f43b9d1fb62712 Author: Milan Crha mc...@redhat.com Date: Fri Apr 25 08:33:48 2014 +0200 Remove unused imapx_unmark_folder_subscribed() There are more issues like this reported in the GNOME Bugzilla, so spare Jessie/testing users from the regular Evolution upgrade pain until upstream fixes these issues. Thanks for the report. I wonder if you've tried with both e-d-s _and_ evolution from unstable, ie 3.12.1. There's a ton of bugfixes in there. It's interesting we've only got one bug report like this in Debian, so let's see if we can track it down fast and let eds migrate. -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ jo...@sindominio.net jo...@debian.org http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ signature.asc Description: Digital signature
Bug#733657: pan on LXDE freezes upon ending program
Confirmed. The freeze also happens with kde and so it's unrelated to LXDE. The freeze occurs when Pan has no server configuration. All the best -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746566: gdal-bin: ogr2ogr fails to create SQLite db using SPATIALITE=YES
Package: gdal-bin Version: 1.10.1+dfsg-5+b1 Severity: normal Dear Maintainer, The following command works and creates rat_boxes.sqlite: ogr2ogr -f SQLite rat_boxes.sqlite rat_boxes.xml however the following command will continue indefinitely, aparently doing nothing: ogr2ogr -f SQLite rat_boxes.sqlite rat_boxes.xml -dsco SPATIALITE=YES when interrupted both a .sqlite and a .sqlite-journal file is present. This is a recent problem as this worked a month or so back. libspatialite5 (4.1.1-9), spatialite-bin (4.1.1-4) libspatialite3 (3.1.0-rc2-2) are installed Although this is being reported from x86_64, the same problem exists on i386. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdal-bin depends on: ii libc6 2.18-4 ii libgcc1 1:4.8.2-16 ii libgdal1h 1.10.1+dfsg-5+b1 ii libstdc++6 4.8.2-16 gdal-bin recommends no packages. Versions of packages gdal-bin suggests: ii python-gdal 1.10.1+dfsg-5+b1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733564: pu: apache2 with ECDHE support
On Mon, Apr 14, 2014 at 09:57:21PM +0200, Stefan Fritsch wrote:
Am Montag, 14. April 2014, 21:18:46 schrieb Philipp Kern:
So I'd say that we should go and add ECDHE support to Apache as
suggested and also patch OpenSSL for the OS X bug as the
fingerprinting landed upstream and we would merely replicate
current upstream behavior.
OK, sounds good.
Kurt, if the openssl patch is like [1], it would require that apache2
is built against the updated version of openssl, due to the changed
value of SSL_OP_ALL. Can you please ping me when you have uploaded the
new package? Also, you should probably mention in the changelog that
only recompiled applications get to use the workaround.
I've just uploaded it.
Debdiff is attached.
Kurt
diff -Nru openssl-1.0.1e/debian/changelog openssl-1.0.1e/debian/changelog
--- openssl-1.0.1e/debian/changelog 2014-04-17 22:11:48.0 +0200
+++ openssl-1.0.1e/debian/changelog 2014-05-01 15:31:35.0 +0200
@@ -1,3 +1,12 @@
+openssl (1.0.1e-2+deb7u8) wheezy; urgency=medium
+
+ * Don't prefer ECDHE_ECDSA with some Safari versions
+This also adds the SSL_OP_SAFARI_ECDHE_ECDSA_BUG option.
+ * Actually restart the services when restart-without-asking is set.
+(Closes: #745801)
+
+ -- Kurt Roeckx k...@roeckx.be Thu, 01 May 2014 15:06:05 +0200
+
openssl (1.0.1e-2+deb7u7) wheezy-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru openssl-1.0.1e/debian/libssl1.0.0.postinst openssl-1.0.1e/debian/libssl1.0.0.postinst
--- openssl-1.0.1e/debian/libssl1.0.0.postinst 2014-04-16 22:59:01.0 +0200
+++ openssl-1.0.1e/debian/libssl1.0.0.postinst 2014-05-01 15:30:16.0 +0200
@@ -171,6 +171,8 @@
else
answer=no
fi
+else
+ answer=yes
fi
echo
if [ $answer = yes ] [ $services != ]; then
diff -Nru openssl-1.0.1e/debian/patches/ECDHE-ECDSA_Safari.patch openssl-1.0.1e/debian/patches/ECDHE-ECDSA_Safari.patch
--- openssl-1.0.1e/debian/patches/ECDHE-ECDSA_Safari.patch 1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1e/debian/patches/ECDHE-ECDSA_Safari.patch 2014-05-01 15:52:28.0 +0200
@@ -0,0 +1,194 @@
+From: Rob Stradling r...@comodo.com
+Date: Thu, 5 Sep 2013 13:09:03 +0100
+Subject: [PATCH] Don't prefer ECDHE-ECDSA ciphers when the client appears to
+ be Safari on OS X. OS X 10.8..10.8.3 has broken support for ECDHE-ECDSA
+ ciphers.
+Origin: upstream, commit:4b61f6d2a675fdb57dc93991e7b332a745b44d1f, commit:937f125efc80d7a4e80a5a02ec0eae02ea0b55ac, commit:f4a51970d245a61e991a0c2e196853e81a1a6c53
+
+
+diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod
+index cc588f3..fded060 100644
+--- a/doc/ssl/SSL_CTX_set_options.pod
b/doc/ssl/SSL_CTX_set_options.pod
+@@ -88,9 +88,10 @@ As of OpenSSL 0.9.8q and 1.0.0c, this option has no effect.
+
+ ...
+
+-=item SSL_OP_MSIE_SSLV2_RSA_PADDING
++=item SSL_OP_SAFARI_ECDHE_ECDSA_BUG
+
+-As of OpenSSL 0.9.7h and 0.9.8a, this option has no effect.
++Don't prefer ECDHE-ECDSA ciphers when the client appears to be Safari on OS X.
++OS X 10.8..10.8.3 has broken support for ECDHE-ECDSA ciphers.
+
+ =item SSL_OP_SSLEAY_080_CLIENT_DH_BUG
+
+diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
+index e7c5dcb..c2428f4 100644
+--- a/ssl/s3_lib.c
b/ssl/s3_lib.c
+@@ -3037,6 +3037,11 @@ void ssl3_clear(SSL *s)
+ s-s3-tmp.ecdh = NULL;
+ }
+ #endif
++#ifndef OPENSSL_NO_TLSEXT
++#ifndef OPENSSL_NO_EC
++ s-s3-is_probably_safari = 0;
++#endif /* OPENSSL_NO_EC */
++#endif /* OPENSSL_NO_TLSEXT */
+
+ rp = s-s3-rbuf.buf;
+ wp = s-s3-wbuf.buf;
+@@ -4016,6 +4021,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt,
+ ii=sk_SSL_CIPHER_find(allow,c);
+ if (ii = 0)
+ {
++#if !defined(OPENSSL_NO_EC) !defined(OPENSSL_NO_TLSEXT)
++ if ((alg_k SSL_kEECDH) (alg_a SSL_aECDSA) s-s3-is_probably_safari)
++{
++if (!ret) ret=sk_SSL_CIPHER_value(allow,ii);
++continue;
++}
++#endif
+ ret=sk_SSL_CIPHER_value(allow,ii);
+ break;
+ }
+diff --git a/ssl/ssl.h b/ssl/ssl.h
+index 593579e..c48990e 100644
+--- a/ssl/ssl.h
b/ssl/ssl.h
+@@ -555,7 +555,7 @@ struct ssl_session_st
+ #define SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG 0x0008L
+ #define SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG 0x0010L
+ #define SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER 0x0020L
+-#define SSL_OP_MSIE_SSLV2_RSA_PADDING 0x0040L /* no effect since 0.9.7h and 0.9.8b */
++#define SSL_OP_SAFARI_ECDHE_ECDSA_BUG 0x0040L
+ #define SSL_OP_SSLEAY_080_CLIENT_DH_BUG 0x0080L
+ #define SSL_OP_TLS_D5_BUG0x0100L
+ #define SSL_OP_TLS_BLOCK_PADDING_BUG 0x0200L
+diff --git a/ssl/ssl3.h b/ssl/ssl3.h
+index 247e88c..208b392 100644
+--- a/ssl/ssl3.h
b/ssl/ssl3.h
+@@ -539,6 +539,15 @@ typedef struct ssl3_state_st
+ /* Set if we saw the Next Protocol Negotiation extension from our peer. */
+ int next_proto_neg_seen;
+ #endif
++
++#ifndef OPENSSL_NO_TLSEXT
++#ifndef OPENSSL_NO_EC
++ /* This is
Bug#746567: error: server response code 403
Package: quvi Version: 0.4.2-1 Severity: normal It seems quvi fails to find certain videos. This could be a restriction from Google to force ads to be played, but I'm curious to hear from you guys: $ cclive http://www.youtube.com/watch?v=uAmINmjpQxw Checking ... . .. ..libquvi: error: server response code 403 (conncode=0) A. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages quvi depends on: ii dpkg 1.17.6 ii libc62.18-4 ii libcurl3-gnutls 7.36.0-1+b1 ii libquvi7 0.4.1-2 quvi recommends no packages. quvi 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#746568: may wrongly ban people due to Apache ACL changes
Package: fail2ban Version: 0.8.13-1 Severity: important Coin, Due to recent changes in Apache, a lot of AH01797 errors are triggered by the access_compat module. As it may take some time to users to convert all their ACL and all web-related Debian packages have not upgraded their shipped configuration yet, i think it would be best to ignore such kind of messages and avoid banning people for no good reason. Regards. -- Marc Dequènes (Duck) pgp2r65LQrGzL.pgp Description: PGP Digital Signature
Bug#682068: [Piuparts-devel] Bug#682068: selinux + piuparts
tag 682068 + patch
thanks
Le Wed, 30 Apr 2014 15:46:45 +0200,
Holger Levsen hol...@layer-acht.org a écrit :
Hi,
On Mittwoch, 30. April 2014, Laurent Bigonville wrote:
I'll try to cook something. But if you really want to remove the
support, wouldn't it be better to unconditionally switch to the new
path instead?
as said a year ago, just changing pathes won't work, as detecting
selinux needs to be updated too:
On Samstag, 18. Mai 2013, Holger Levsen wrote:
tags 682068 + moreinfo
thanks
Hi Laurent,
piuparts is only trying to mount selinux mountpoints if
/usr/sbin/selinuxenabled ran successfully.
I have two problems now:
- /usr/sbin/selinuxenabled doesn't even exist on my wheezy system
- isn't there some selinux tool to tell me the expected mountpoint?
I don't want to mess around with versions in piuparts.py source
code (be it wheezy, squeeze, 2.0.96-1 or 2.1.9-5) to decide
whether to mount /selinux or /sys/fs/selinux ?!!
See below for actual related code. That's it, plus calls to them.
def selinux_enabled(enabled_test=/usr/sbin/selinuxenabled):
if os.access(enabled_test, os.X_OK):
retval, output = run([enabled_test], ignore_errors=True)
if retval == 0:
return True
else:
return False
def mount_selinux(self):
if selinux_enabled():
run([mkdir, -p, self.relative(/selinux)])
run([mount, -t, selinuxfs, /selinux,
self.relative(/selinux)])
logging.info(SElinux mounted into chroot)
def unmount_selinux(self):
if selinux_enabled():
run([umount, self.relative(/selinux)])
logging.info(SElinux unmounted from chroot)
I think I really either want a tested patch from someone using
selinux or remove this code.
I've attached a patch that is implementing the change. If /selinux is
present, the selinuxfs will be mounted there. This directory was
shipped by libselinux package until wheezy (even if in wheezy it was
mounted already to the new location).
The patch is also changing the way the selinuxfs is mounted. The
selinuxfs is now bind mounted and then set to read only. This is needed
to make think the userspace that selinux is disabled, otherwise dpkg
will simply fail if the selinux policy is not installed in the chroot
(see: #734193)
I've also added a soft dependency against python-selinux to use the
python API to detect if selinux is enabled instead of using
selinuxenabled executable. If you don't agree with this, I can revert
this change.
Cheers,
Laurent Bigonville
diff -Nru piuparts-0.58/debian/control piuparts-0.58selinux1/debian/control
--- piuparts-0.58/debian/control 2014-05-01 00:25:32.0 +0200
+++ piuparts-0.58selinux1/debian/control 2014-05-01 13:50:56.0 +0200
@@ -38,7 +38,8 @@
${misc:Depends},
${python:Depends}
Recommends:
- adequate
+ adequate,
+ python-selinux
Suggests:
schroot
Description: .deb package installation, upgrading, and removal testing tool
diff -Nru piuparts-0.58/piuparts.py piuparts-0.58selinux1/piuparts.py
--- piuparts-0.58/piuparts.py 2014-05-01 00:25:32.0 +0200
+++ piuparts-0.58selinux1/piuparts.py 2014-05-01 16:04:56.0 +0200
@@ -57,6 +57,12 @@
except ImportError:
from debian_bundle import deb822
+try:
+import selinux
+selinux_enabled = selinux.is_selinux_enabled()
+except ImportError:
+selinux_enabled = False
+
import piupartslib.conf
DISTRO_CONFIG_FILE = /etc/piuparts/distros.conf
@@ -1411,16 +1417,26 @@
def mount_selinux(self):
-if selinux_enabled():
-run([mkdir, -p, self.relative(/selinux)])
-run([mount, -t, selinuxfs, /selinux, self.relative(/selinux)])
+if selinux_enabled:
+run([mkdir, -p, self.selinuxfs_relative_path()])
+run([mount, --bind, /sys/fs/selinux, self.selinuxfs_relative_path()])
+run([mount, -o, remount,ro,bind, self.selinuxfs_relative_path()])
logging.info(SElinux mounted into chroot)
def unmount_selinux(self):
-if selinux_enabled():
-run([umount, self.relative(/selinux)])
+if selinux_enabled:
+run([umount, self.selinuxfs_relative_path()])
logging.info(SElinux unmounted from chroot)
+# If /selinux is present, assume that this is the only supported
+# location by libselinux. Otherwise use the new location.
+# /selinux was shipped by the libselinux package until wheezy.
+def selinuxfs_relative_path(self):
+if os.path.isdir(self.relative('/selinux')):
+return self.relative('/selinux')
+else:
+return self.relative('/sys/fs/selinux')
+
def mount_proc(self):
Mount /proc inside chroot.
self.run([mount, -t, proc, proc, /proc])
@@ -1850,14 +1866,6 @@
def mount_proc(self): pass
def unmount_proc(self): pass
-def
Bug#746569: getrusage: documents how to get RUSAGE_THREAD
Package: manpages-dev Version: 3.61-1 Severity: normal Hello Simon, man getrusage documents RUSAGE_THREAD. However, as far as I can see, this symbol is only available if _GNU_SOURCE is defined, but this is not documented. So either libc-dev or manpages-dev should be fixed to match. 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#687607: isync: Still no recursive sync?
Package: isync Version: 1.1.0-2 Followup-For: Bug #687607 Hi, I just discovered isync today, as I was looking for a replacement for imapcopy. I am utterly surprised, that there is no support for subfolders. I understand the patch has been out for two years now. I will try to apply it locally, but I think, there is real demand for this. Thanks, Johannes -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages isync depends on: ii libc62.18-4 ii libdb5.3 5.3.28-3 ii libssl1.0.0 1.0.1g-3 isync recommends no packages. Versions of packages isync suggests: ii mutt 1.5.23-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#731328: patch for dns.monitor
Hi, This bug is no longer present in mon package. It was closed by 1.2.0-8 version upload [0]. [0] http://packages.qa.debian.org/m/mon/news/20131231T034913Z.html Thanks. -- Dario Minnucci mid...@debian.org Phone: +34 902884117 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = BAA1 7AAF B21D 6567 D457 D67D A82F BB83 F3D5 7033 signature.asc Description: OpenPGP digital signature
Bug#746570: live-build: chroot image contains /etc/mtab as a regular file
Package: live-build Version: 4.0~alpha36-1 Severity: minor At the time that *.hook.chroot run, /etc/mtab is a regular file. Since wheezy, Debian has preferred it to be a symlink to /proc/mounts (it became important to do that with kernels = 2.6.26). I'm not sure which stage of installation is normally responsible for this, but live-build doesn't do it. I'm currently using this code in a hook at 0500*.hook.chroot: rm -f /etc/mtab ln -s /proc/mounts /etc/mtab wheezy's sysvinit and systemd both fix this up during boot, and it looks as though extlinux(8) prefers /proc/mounts anyway, but it's probably useful to have the correct mtab for ad-hoc mount + chroot stuff - in particular, I'm not sure whether other bootloaders like grub do the same as extlinux, or whether they trust /etc/mtab. S -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages live-build depends on: ii cdebootstrap 0.5.10 ii debootstrap 1.0.59 ii python3 3.3.4-1 Versions of packages live-build recommends: ii cpio2.11+dfsg-2 ii live-boot-doc 4.0~alpha21-1 ii live-config-doc 4.0~alpha33-1 ii live-manual-html [live-manual] 1:4.0~alpha12-1 live-build 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#746571: gnade depends on ada-compiler which is going away
Package: libgnadecommon2-dev Version: 1.6.2-9 Severity: serious gnade depends on the virtual package ada-compiler which according to packages.debian.org is only provided by gnat-4.4. gnat-4.4 has already been removed from testing and has a removal request filed for unstable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746572: xserver-xfbdev: Mouse and Keyboard not working due to driver missing in package
Package: xserver-xfbdev Version: 2:1.12.4-6+deb7u2 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? I run xfbdev for a test Missing driver is clearly again in stable version, and left unchanged * What exactly did you do (or not do) that was effective (or ineffective)? effective to test friend config, as follows * What was the outcome of this action? no keyboard no mouse working, but I get a Xfbdev with fluxbox running, but no events * What outcome did you expect instead? that it works I have added at my grub.cfg vesafb:mtrr,ywrap vga=0x315 I have in particularly .xserverrc with: -keybd evdev,,device=/dev/input/event0 -mouse evdev,,=device=/device/input/mice and it says in the tty that no evdev driver is available. Please fix this issue rapidly. Thank you and yours sincerely, Pat *** End of the template - remove these lines *** -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (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 xserver-xfbdev depends on: ii libaudit0 1:1.7.18-1.1 ii libc6 2.13-38 ii libgcrypt11 1.5.0-5+deb7u1 ii libpixman-1-0 0.26.0-4+deb7u1 ii libselinux1 2.1.9-5 ii libxau6 1:1.0.7-1 ii libxdmcp6 1:1.1.1-1 ii libxfont1 1:1.4.5-2 ii xserver-common 2:1.12.4-6+deb7u2 xserver-xfbdev recommends no packages. xserver-xfbdev suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746568: may wrongly ban people due to Apache ACL changes
Hi Marc Thanks for the notice! Would you be so kind to provide references about this change in apache? On Thu, 01 May 2014, Marc Dequènes (Duck) wrote: Package: fail2ban Version: 0.8.13-1 Severity: important Coin, Due to recent changes in Apache, a lot of AH01797 errors are triggered by the access_compat module. As it may take some time to users to convert all their ACL and all web-related Debian packages have not upgraded their shipped configuration yet, i think it would be best to ignore such kind of messages and avoid banning people for no good reason. Regards. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663101: review of the upstream foreman debian package
Hi Antoine Firstly, apologies for the slow reply - I've been on vacation, and catching up with work :) I'm really happy to discuss getting Foreman (and it's other packages, such as the proxy and the installer) into Debian - that would be fantastic. My replies to your questions, and my own thoughts, are in-line... On 17 April 2014 01:44, Antoine Beaupré anar...@debian.org wrote: First off, the foreman-installer completely overwrites existing apache configuration files, which is contrary to Debian Policy, c. 7.6.1: The installer makes no changes to anything when the package is installed: # dpkg -L foreman-installer | grep /etc/apache2 | wc -l 0 It also has no postinst or preinst scripts which could modify Apache configuration. Changes to the Apache configuration only happen when the installer is executed by the user (which is intended, since Foreman's default configuration is to use Apache). Also, apt-get install foreman just fails: I can't reproduce this I'm afraid. On a fresh Wheezy box: root@wheezy934:~# apt-get install foreman snip The following NEW packages will be installed: binutils build-essential bundler cpp cpp-4.7 dpkg-dev fakeroot foreman foreman-proxy g++ g++-4.7 gcc gcc-4.7 libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libc-dev-bin libc6-dev libdpkg-perl libfile-fcntllock-perl libgomp1 libgssrpc4 libitm1 libkadm5clnt-mit8 libmpc2 libmpfr4 libquadmath0 libstdc++6-4.7-dev libtimedate-perl linux-libc-dev make manpages-dev patch rake ruby-dev ruby-rack ruby-rack-protection ruby-rkerberos ruby-sinatra ruby-tilt ruby1.9.1-dev rubygems-integration unzip zip snip Fetched 76.0 MB in 43s (1,750 kB/s) snip Setting up foreman (-wheezy+scratchbuild+201405011056) ... foreman not configured to start. Please edit /etc/default/foreman to enable. Seems fine. This was using our nightly repo, but the same successful result is obtained with the 1.4.x packages. Also, the underlying packages do not seem to cleanup properly after themselves: root@puppet0:/etc# apt-get purge foreman-postgresql foreman Testing this, it seems the Gemfile.lock is being left behind. I've filed a bug[1] on the Foreman tracker to address this. ... which basically means it will totally fail to install on wheezy, which still has rails 2.3. There is a lot of work to do. There's probably way more stuff i'm missing here. I've put these 3 comments together, because (in my opinion) this is the largest problem in getting Foreman upstream. Currently there are approximately 140 gems vendored in ~foreman/vendor/cache (including Rails 3.2.17). Every single one of these would need to become a new package in order to satisfy Debian's Ruby Packaging guidelines (as I understand it), and I do not have time to do this (which is why they are vendored). This problem is compounded by versioning problems with popular gems (such as Rails) - Foreman currently *requires* at least Rails 3.2.8, and is likely to move to Rails 4 soon. Many other gem dependencies move very quickly (often for security patches) so we'd need to make sure we were being repsonsive to that, as well. Until we have a clear plan of how to handle these gem dependencies, getting the Foreman package itself upstream seems impossible (unless I misunderstood, and Debian policy does indeed permit vendoring of gems) Having it installable on a simple wheezy environment would be a start. I also strongly encourage you to run the package through lintian to make sure it's properly built. As demonstrated above, the packages are installable. Without further debugging, I can't speculate on why you hit the Rails version issue, but that's the first time I've seen that error - and the wheezy packages are well tested. I've checked lintian and there's nothing massively serious, mostly a few ruby-script-but-no-ruby-dep errors which can probably be easily fixed at some point. Looking forward to see Foreman in Debian... Likewise, if we can figure out what to do with the gems :) I'm always available on Freenode if you want to discuss in real-time (nick: gwmngilfen, channels: #theforeman, #theforeman-dev) Regards, Greg [1] http://projects.theforeman.org/issues/5539 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743508:
Hello, so it seems that upstream agreed on the ABI breakage. The importance of this bug should be raised, this is now RC. We should ask the release team how to deal with this mess... Do you agree with this ? Cheers Frederic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658459: tome: New version with new license is available
On 2014-04-30 21:14:50, Manoj Srivastava wrote: On Fri, Feb 03 2012, Marcin Kulisz wrote: On project website (http://te4.org/) new version is available it's a full rewrite which now is licensed under GPL3 and it looks like releases are fairly regular. And it is a totally different game. Yep sorry for this. I am not sure of the artwork licenses, I think it should be packaged separately, perhaps as te4. Once I have the current game back up to speed, I might take a look at packaging te4. Thank you and thank you (for working on tome and for eventual plan to package te4) -- |_|0|_| | |_|_|0| Heghlu'Meh QaQ jajVam | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: Digital signature
Bug#746573: gui-apt-key: Does not support /etc/apt/trusted.gpg.d/ where package-originating keys are stored nowadays
Package: gui-apt-key Version: 0.4-2 Severity: important Dear Joey, previously all trusted keys for APT were managed in /etc/apt/trusted.gpg which was rewritten every time a package added or removed keys. Nowadays every package which wants to add keys to APT list of trusted keys, just drops a file into /etc/apt/trusted.gpg.d/ So if I call gui-apt-key on an uptodate Sid installation, it shows no key at all by default. (If I added keys manually, it only shows them.) It's probably not trivial to implement removal of keys from multiple key stores. Nevertheless, gui-apt-key should display all keys which are trusted, not only the manually added ones. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gui-apt-key depends on: ii libgtk2-perl2:1.2491-1 ii liblocale-gettext-perl 1.05-8 gui-apt-key recommends no packages. gui-apt-key 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#746574: gui-apt-key: Is no more able to delete keys from the keyring
Package: gui-apt-key Version: 0.4-2 Severity: important Dear Joey, While it worked in the past, GAK::Backend seems no more able to delete keys from a keyring. (Since the same issue is present in curses-apt-key which uses just GAK::Backend, it's not an issue of the GUI.) No error message or similar is thrown. The key which should be deleted stays in the keyring as well as in the list of keys presented by gui-apt-key. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gui-apt-key depends on: ii libgtk2-perl2:1.2491-1 ii liblocale-gettext-perl 1.05-8 gui-apt-key recommends no packages. gui-apt-key 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#746575: neutron: [INTL:it] Italian translation of debconf messages
Package: neutron Severity: wishlist Tags: l10n patch Hi. Please find attached the Italian translation of neutron debconf messages proofread by the Italian localization team. Please include it in your next upload. Thanks, Beatrice # Italian translation of neutron debconf messages. # Copyright (C) 2014, neutron package's copyright holder. # This file is distributed under the same license as the neutron package. # Beatrice Torracca beatri...@libero.it, 2014. msgid msgstr Project-Id-Version: neutron\n Report-Msgid-Bugs-To: neut...@packages.debian.org\n POT-Creation-Date: 2013-10-13 04:48+\n PO-Revision-Date: 2014-04-21 09:44+0200\n Last-Translator: Beatrice Torracca beatri...@libero.it\n Language-Team: Italian debian-l10n-ital...@lists.debian.org\n Language: it\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: Virtaal 0.7.1\n #. Type: string #. Description #: ../neutron-common.templates:2001 msgid Authentication server hostname: msgstr Nome host del server di autenticazione: #. Type: string #. Description #: ../neutron-common.templates:2001 msgid Please specify the hostname of your Neutron authentication server. Typically this is also the hostname of your OpenStack Identity Service (Keystone). msgstr Specificare il nome host del server di autenticazione Neutron. Tipicamente, è anche il nome host dell'OpenStack Identity Service (Keystone). #. Type: string #. Description #: ../neutron-common.templates:3001 msgid Authentication server tenant name: msgstr Nome del «locatario» («tenant») per il server di autenticazione: #. Type: string #. Description #: ../neutron-common.templates:3001 msgid Please specify the authentication server tenant name. msgstr Specificare il nome del «locatario» («tenant») per il server di autenticazione. #. Type: string #. Description #: ../neutron-common.templates:4001 msgid Authentication server username: msgstr Nome utente per il server di autenticazione: #. Type: string #. Description #: ../neutron-common.templates:4001 msgid Please specify the username to use with the authentication server. msgstr Specificare il nome utente da usare con il server di autenticazione. #. Type: password #. Description #: ../neutron-common.templates:5001 msgid Authentication server password: msgstr Password per il server di autenticazione: #. Type: password #. Description #: ../neutron-common.templates:5001 msgid Please specify the password to use with the authentication server. msgstr Specificare la password da usare con il server di autenticazione. #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid OpenVSwitch msgstr OpenVSwitch #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid LinuxBridge msgstr LinuxBridge #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid ml2 msgstr ml2 #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid Brocade msgstr Brocade #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid Nicira msgstr Nicira #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid Midonet msgstr Midonet #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid NEC msgstr NEC #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid Mellanox msgstr Mellanox #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid Hyper-V msgstr Hyper-V #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid RYU msgstr RYU #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid ml2/ml2_conf.ini msgstr ml2/ml2_conf.ini #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid MetaPlugin msgstr MetaPlugin #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid BigSwitch msgstr BigSwitch #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid Cisco msgstr Cisco #. Type: select #. Choices #: ../neutron-common.templates:6001 msgid PLUMgrid msgstr PLUMgrid #. Type: select #. Description #: ../neutron-common.templates:6002 msgid Neutron plugin: msgstr Plugin Neutron: #. Type: select #. Description #: ../neutron-common.templates:6002 msgid Neutron uses a plugin architecture to manage networking. When starting the Neutron server daemon, the configuration file corresponding to the plugin you wish to use needs to be loaded, by giving it as a parameter when starting the neutron-server daemon. Also, the core_plugin directive needs to match. Please select which plugin to use. msgstr Neutron usa un'architettura a plugin per gestire la rete. Quando si avvia il demone del server Neutron, il file di configurazione corrispondente al plugin che si desidera usare deve essere caricato fornendolo come parametro all'avvio del demone neutron-server. Inoltre la direttiva core_plugin deve corrispondere. Selezionare quale plugin usare. #. Type: boolean #. Description #: ../neutron-common.templates:7001
Bug#746576: tuskar: [INTL:it] Italian translation of debconf messages
Package: tuskar Severity: wishlist Tags: l10n patch Hi. Please find attached the Italian translation of tuskar debconf messages proofread by the Italian localization team. Please include it in your next upload. Thanks, Beatrice # Italian translation of tuskar debconf messages. # Copyright (C) 2014, tuskar package's copyright holder # This file is distributed under the same license as the tuskar package. # Beatrice Torracca beatri...@libero.it, 2014. msgid msgstr Project-Id-Version: tuskar\n Report-Msgid-Bugs-To: tus...@packages.debian.org\n POT-Creation-Date: 2013-12-15 15:59+0800\n PO-Revision-Date: 2014-04-21 09:34+0200\n Last-Translator: Beatrice Torracca beatri...@libero.it\n Language-Team: Italian debian-l10n-ital...@lists.debian.org\n Language: it\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: Virtaal 0.7.1\n #. Type: boolean #. Description #: ../tuskar-common.templates:2001 msgid Set up a database for Tuskar? msgstr Impostare un database per Tuskar? #. Type: boolean #. Description #: ../tuskar-common.templates:2001 msgid No database has been set up for tuskar to use. Before continuing, you should make sure you have the following information: msgstr Non è stato impostato alcun database per essere usato da tuskar. Prima di continuare assicurarsi di avere le seguenti informazioni: #. Type: boolean #. Description #: ../tuskar-common.templates:2001 msgid * the type of database that you want to use;\n * the database server hostname (that server must allow TCP connections from\n this machine);\n * a username and password to access the database. msgstr * il tipo di database che si desidera usare;\n * il nome host del server di database (che deve permettere le connessioni\n TCP da questa macchina);\n * un nome utente e una password per accedere al database. #. Type: boolean #. Description #: ../tuskar-common.templates:2001 msgid If some of these requirements are missing, do not choose this option and run with regular SQLite support. msgstr Se non si ha uno o più di questi requisiti, non scegliere questa opzione ed eseguire con il regolare supporto per SQLite. #. Type: boolean #. Description #: ../tuskar-common.templates:2001 msgid You can change this setting later on by running \dpkg-reconfigure -plow tuskar-common\. msgstr È possibile cambiare questa impostazione successivamente eseguendo «dpkg- reconfigure -plow tuskar-common». #. Type: string #. Description #: ../tuskar-common.templates:3001 msgid Authentication server hostname: msgstr Nome host del server di autenticazione: #. Type: string #. Description #: ../tuskar-common.templates:3001 msgid Please specify the hostname of the authentication server for Tuskar. Typically this is also the hostname of the OpenStack Identity Service (Keystone). msgstr Specificare il nome host del server di autenticazione per Tuskar. Tipicamente, è anche il nome host dell'OpenStack Identity Service (Keystone). #. Type: string #. Description #. Translators: a tenant in OpenStack world is #. an entity that contains one or more username/password couples. #. It's typically the tenant that will be used for billing. Having more than one #. username/password is very helpful in larger organization. #. You're advised to either keep tenant without translating it #. or keep it parenthezised. Example for French: #. locataire (tenant) #: ../tuskar-common.templates:4001 msgid Authentication server tenant name: msgstr Nome del locatario («tenant») per il server di autenticazione: #. Type: string #. Description #. Translators: a tenant in OpenStack world is #. an entity that contains one or more username/password couples. #. It's typically the tenant that will be used for billing. Having more than one #. username/password is very helpful in larger organization. #. You're advised to either keep tenant without translating it #. or keep it parenthezised. Example for French: #. locataire (tenant) #: ../tuskar-common.templates:4001 msgid Please specify the authentication server tenant name. msgstr Specificare il nome del «locatario» («tenant») per il server di autenticazione. #. Type: string #. Description #: ../tuskar-common.templates:5001 msgid Authentication server username: msgstr Nome utente per il server di autenticazione: #. Type: string #. Description #: ../tuskar-common.templates:5001 msgid Please specify the username to use with the authentication server. msgstr Specificare il nome utente da usare con il server di autenticazione. #. Type: password #. Description #: ../tuskar-common.templates:6001 msgid Authentication server password: msgstr Password per il server di autenticazione: #. Type: password #. Description #: ../tuskar-common.templates:6001 msgid Please specify the password to use with the authentication server. msgstr Specificare la password da usare con il server di autenticazione. #. Type: string #. Description #:
Bug#572804: latex-beamer: custom theorems fail in combination with hyperref in article mode
Am Mon, 28. Apr 2014, 14:57:33 +0200 schrieb Hilmar Preusse: On 06.03.10 J? Fahlke (jor...@jorrit.de) wrote: Hi, https://bugs.debian.org/572804 Package: latex-beamer Version: 3.07-2 Severity: normal Hi! The following latex file fails to compile with both latex and pdflatex: I can compile this example now. Islam, your example too. Can we close that issue? Works for me now, so I suppose we can close that as far I'm concerned. Although I note that I switched from i386 to amd64 meanwhile. Regards, Jö. -- Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics, University of Münster, Orleans-Ring 10, D-48149 Münster Tel: +49 251 83 35146 Fax: +49 251 83 32729 If God had intended Man to Smoke, He would have set him on Fire. -- fortune signature.asc Description: Digital signature
Bug#746578: libpam-systemd: for upgrade safety, swap or-dependency to systemd-shim|systemd-sysv
Package: libpam-systemd Version: 204-10 Severity: important For safety of upgrades from wheezy to jessie, the process of upgrading packages and installing new ones *must not* change either the currently- running init or the init that will manage the system on the next boot. The sysadmin needs an opportunity to check over any local customizations and then explicitly make the switch. Currently, libpam-systemd tries to pull in systemd-sysv, which conflicts with sysvinit-core, which violates this principle. The desired state for jessie is that systemd-sysv and sysvinit-core should be coinstallable, with an alternatives-like mechanism for deciding which package actually provides init (if this can be done with actual alternatives for /sbin/init, that would be ideal, but I suspect it cannot be that simple). I will be filing another bug against systemd-sysv and sysvinit-core to that effect, but as an immediate stopgap measure to prevent breakage, libpam-systemd should swap its or-dependency on systemd-sysv|systemd-shim so that systemd-shim is first. That will prevent upgrades of *unrelated* packages from changing the running init system. severity:important to block testing propagation; systems running testing with unattended upgrades enabled are one of the situations that need the extra safety net of a guarantee that a transition to systemd will not occur without deliberate sysadmin action. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 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 libpam-systemd depends on: ii libc6 2.18-5 ii libcap21:2.22-1.2 ii libdbus-1-31.8.2-1 ii libpam-runtime 1.1.8-3 ii libpam0g 1.1.8-3 ii multiarch-support 2.18-5 ii systemd204-10 ii systemd-shim 6-3 libpam-systemd recommends no packages. libpam-systemd 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#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable
Source: systemd-sysv Version: 204-10 Severity: critical Justification: breaks the whole system Control: retitle -2 sysvinit-core: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable For safety of upgrades from wheezy to jessie, the process of upgrading packages and installing new ones *must not* change either the currently- running init or the init that will manage the system on the next boot. A transition away from sysvinit must only occur as a result of a deliberate sysadmin action with that specific effect, not as a side effect of any other operation. To achieve this, systemd-sysv and sysvinit-core must be coinstallable, with an alternatives-like mechanism for deciding which package actually provides init (if this can be done with actual alternatives for /sbin/init, that would be ideal, but I suspect it cannot be that simple). Other potential providers of /sbin/init should ideally also be included in this mechanism, but because the default-for-new-installations is changing in jessie from sysvinit to systemd, the cooperation of those two providers is more important than the others. severity:critical because, depending on how an installation is configured, an unanticipated conversion to systemd absolutely can cause the system to be unbootable, or fail to carry out its intended function (e.g. because a network server no longer starts on boot as intended). -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
