Bug#740952: purging old records from the database
On 06/03/14 21:59, Daniel Pocock wrote: On 06/03/14 21:51, Michael Biebl wrote: Am 06.03.2014 16:11, schrieb Daniel Pocock: Package: rsyslog-mongodb Version: 7.4.4-1 With normal logfiles, the files are rotated by logrotate What is the recommended solution for purging old records from MongoDB? Tbh, I have absolutely no idea. I'm actually not convinced that this should be done automatically. That said, the mongodb maintainer might have an answer, how this could be done for mongodb, so I've CCed him. Fwiw, the other db output plugins (e.g. rsyslog-mysql or rsyslog-pgsql) don't setup such an automatic pruning either. I also raised an upstream issue for comments on this issue: https://github.com/rsyslog/rsyslog/issues/47 Maybe some cron job can be created and records can be purged based on some combination of (priority, facility, age) - that would resemble the rules used to manage the traditional files Given the simplicity of MongoDB setup and maintenance for this type of data set, it could even be offered as an option in the debconf menus, e.g. Do you want to enable ommongodb now in a default configuration? This will just work if your mongodb-server has no passwords, as is the default on Debian. This may lead to quite a lot of people using it. Brief update on this issue - I published a script for this on my blog: http://danielpocock.com/pruning-syslog-entries-from-mongodb It uses python-pymongo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769983: qemu-user-static: tcg fatal error
Control: tag -1 + confirmed upstream Control: retitle -1 qemu-user multi-threaded issues Control: forwarded -1 https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1350435 18.11.2014 06:59, James Valleroy wrote: [] I found this issue has been reported to qemu upstream [1] and there is a patch available [2]. The patch is just a workaround for the issue (it pins multi-threaded code to a single CPU core), but I tested it and it did eliminate the errors. Please consider adding this patch to the Debian package, at least temporarily until a better solution is found. [0] http://anonscm.debian.org/cgit/freedombox/freedom-maker.git/tree/bin/mk_freedombox_image [1] https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1350435 [2] https://patches.linaro.org/32473/ This is a known old problem -- qemu-user target does not emulate multi-threaded applications properly. That patch is a gross hack, and it is even incorrect as it pins qemu process especially to core #0 wich might not even be available. There's a much simpler workaround for this, and is more -- to pin your qemu process to a single core using taskset. Something like this: taskset 0x01 vmdebootstrap ... or taskset 0x02 qemu-arm-static /foreign/arm/usr/bin/foo ... (this pins to core #2) and so on. At least here you can choose which cpu/core to use. And no, I don't really want to add that patch to debian package. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768776: systemd wakes up CIFS/network drives too early
Hi dAgeCKo, dAgeCKo wrote (17 Nov 2014 20:59:15 GMT) : journalctl -al [...] Here are joined why you requested. I hope that the provided information could help you. Thanks! However, the journalctl output seems to be empty (or is it my MUA?) = may you please double-check that you were running this command as root? Also, please confirm what version of systemd you're running currently, since at some point on this bug you said you couldn't upgrade to v215, and I'm afraid we can't support v208 anymore. [Then, once all the needed info is gathered, I'll leave it to people with more expertise. /me just triaging bugs to support a bit the poor souls who are taking too much heat.] Cheers! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766228: systemd does not care /etc/default/grub
Hi PHilipp. Philipp Hug mardi 18 novembre à 00:30 Hi Philippe, By looking at the code it seems that systemd sets /sys/module/vt/parameters/default_utf8 based on the locale setting which makes sense: https://github.com/systemd/systemd/blob/master/src/vconsole/vconsole-setup.c#L92 Can you paste the output of 'localectl' ? If it shows UTF-8, try to change it in /etc/default/locale root:/tmp# localectl System Locale: LANG=fr_FR.iso885915@euro VC Keymap: fr-latin9 X11 Layout: fr X11 Model: pc105 X11 Variant: latin9 X11 Options: compose:menu,terminate:ctrl_alt_bksp root:/tmp# kbd_mode Le clavier est en mode Unicode (UTF-8) root:/tmp# To be in the right locale I'm obliged to add setupcon in the .bashrc. Now, there a little problem, I leave today for a long time the house where the computer has this problem, so next time. So, in the futur, tests will not be possible. Regards. -- Ph. Delavalade -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode
Hi Quentin,
Quentin Lefebvre wrote (17 Nov 2014 17:24:38 GMT) :
I could provide a patch so that systemd-cryptsetup behaves the same way
as cryptsetup.
But actually, there is even an easier way to solve this: change the 'hash'
parameter
in /etc/crypttab to 'plain'.
Doing this, cryptdisks_{start,stop} scripts work well, and so do
systemd-cryptsetup
(as it will pass a NULL pointer as hash parameter to cryptsetup, which is
also legacy
cryptsetup's way to handle keyfile + hash in plain mode).
Good to know, congrats for the debugging!
Now:
1. The proper solution still seems to patch systemd-cryptsetup so that
this workaround isn't needed; may you please send your patch
upstream? If not, just tell us and I guess someone here will do
it :)
2. If a fix doesn't make it into systemd in Jessie, then I guess we'll
want to document this workaround in NEWS.Debian, and make sure the
release notes point there.
IMO, let's not spend time on #2 right now, and instead focus on #1.
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770006: emacs24: freeze while editing simple shell script
Package: emacs24
Version: 24.4
Severity: important
While editing a new shell script (current status below, manually edited
from the last autosave to match the contents in the frozen display), after
a couple of operations emacs becomes unresponsive, following the move of
the point from end of die word to the start of the case word, and the
block cursor visually changes when the window is (de)focussed.
After killing/restarting emacs, and restoring the buffer, it appears that
when I move to that point the case word gets purple-highlighted, so I
guess the error is related to that highlight.
=== buffer contents
#!/bin/sh
set -e
ME=$(basename $0)
usage()
{
cat 2 EOF
Usage:
$ME set
$ME update
EOF
}
[ $# -ge 1 ] || die
case
===
However, thread gmain appears not to get out of this frame:
#0 0x081c034d in exec_byte_code (bytestr=optimized out,
vector=158755517, maxdepth=56, args_template=0, nargs=0, args=optimized
out) at bytecode.c:916
#1 0x0818cdb1 in funcall_lambda (fun=152, nargs=0, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbde4f4) at eval.c:2979
#2 0x0818d07b in Ffuncall (nargs=1, args=0xbfbde4f0) at eval.c:2873
#3 0x0818c831 in eval_sub (form=160589614) at eval.c:2155
#4 0x0818b60b in internal_catch (tag=141378418, func=0x818c2a0
eval_sub, arg=160589614) at eval.c:1112
#5 0x081c12bd in exec_byte_code (bytestr=optimized out,
vector=160382669, maxdepth=72, args_template=5140, nargs=5,
args=optimized out) at bytecode.c:1097
#6 0x0818cdb1 in funcall_lambda (fun=152, nargs=5, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbde74c) at eval.c:2979
#7 0x0818d07b in Ffuncall (nargs=6, args=0xbfbde748) at eval.c:2873
#8 0x081c034d in exec_byte_code (bytestr=optimized out,
vector=157766949, maxdepth=28, args_template=1024, nargs=1,
args=optimized out) at bytecode.c:916
#9 0x0818cdb1 in funcall_lambda (fun=152, nargs=1, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbde8ac) at eval.c:2979
#10 0x0818d07b in Ffuncall (nargs=2, args=0xbfbde8a8) at eval.c:2873
#11 0x081c034d in exec_byte_code (bytestr=optimized out,
vector=160271053, maxdepth=40, args_template=0, nargs=0, args=optimized
out) at bytecode.c:916
#12 0x0818cdb1 in funcall_lambda (fun=152, nargs=0, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbdea14) at eval.c:2979
#13 0x0818d07b in Ffuncall (nargs=1, args=0xbfbdea10) at eval.c:2873
#14 0x0818c831 in eval_sub (form=160589502) at eval.c:2155
#15 0x0818f34b in internal_lisp_condition_case (var=160263770,
bodyform=optimized out, handlers=optimized out) at eval.c:1317
#16 0x081c1373 in exec_byte_code (bytestr=optimized out,
vector=158741789, maxdepth=32, args_template=1540, nargs=1,
args=optimized out) at bytecode.c:1162
#17 0x0818cdb1 in funcall_lambda (fun=152, nargs=1, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbded50) at eval.c:2979
#18 0x0818d07b in Ffuncall (nargs=2, args=0xbfbded4c) at eval.c:2873
#19 0x0818dfb0 in Fapply (nargs=3, args=0xbfbded4c) at eval.c:2294
#20 0x0818d14b in Ffuncall (nargs=4, args=0xbfbded48) at eval.c:2793
#21 0x081c034d in exec_byte_code (bytestr=optimized out,
vector=158757461, maxdepth=20, args_template=512, nargs=0, args=optimized
out) at bytecode.c:916
#22 0x0818cdb1 in funcall_lambda (fun=152, nargs=0, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbdeea8) at eval.c:2979
#23 0x0818d07b in Ffuncall (nargs=1, args=0xbfbdeea4) at eval.c:2873
#24 0x081c034d in exec_byte_code (bytestr=optimized out,
vector=158308461, maxdepth=24, args_template=139240386, nargs=0,
args=optimized out) at bytecode.c:916
#25 0x0818cd37 in funcall_lambda (fun=152, nargs=0, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbdf0bc) at eval.c:3045
#26 0x0818d07b in Ffuncall (nargs=1, args=0xbfbdf0b8) at eval.c:2873
#27 0x0818dfb0 in Fapply (nargs=2, args=0xbfbdf0b8) at eval.c:2294
#28 0x0818d14b in Ffuncall (nargs=3, args=0xbfbdf0b4) at eval.c:2793
#29 0x081c034d in exec_byte_code (bytestr=optimized out,
vector=137711981, maxdepth=16, args_template=139240386, nargs=0,
args=optimized out) at bytecode.c:916
#30 0x081c2fbe in Fbyte_code (bytestr=137711953, vector=137711981,
maxdepth=16) at bytecode.c:482
#31 0x0818c688 in eval_sub (form=137711942) at eval.c:2192
#32 0x0818f34b in internal_lisp_condition_case (var=141397034,
bodyform=optimized out, handlers=optimized out) at eval.c:1317
#33 0x081c1373 in exec_byte_code (bytestr=optimized out,
vector=137711821, maxdepth=20, args_template=139240386, nargs=0,
args=optimized out) at bytecode.c:1162
#34 0x0818cd37 in funcall_lambda (fun=152, nargs=1, arg_vector=0xbfbde228,
arg_vector@entry=0xbfbdf3f8) at eval.c:3045
#35 0x0818d07b in Ffuncall (nargs=2, args=0xbfbdf3f4) at eval.c:2873
#36 0x0818d51b in call1 (fn=139264778, arg1=154824109) at eval.c:2611
#37 0x08125824 in timer_check_2 (idle_timers=optimized out,
timers=optimized out) at keyboard.c:4514
#38 timer_check () at keyboard.c:4581
#39 0x08125c5d in readable_events (flags=flags@entry=1) at keyboard.c:3447
#40 0x0812724b in get_input_pending (flags=flags@entry=1)
Bug#770007: qtcreator fails to start
Package: qtcreator Version: 3.2.1+dfsg-6 Severity: important Dear Maintainer, After installing qtcreator with a apt-get install qtcreator the application fails to load. Launching by clicking the icon does nothing. However, launching from console provides the following errors: Cannot start '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory Segmentation fault It seems that qt4-qmake is required for qtcreator to even launch. This seems odd as qtcreator is currently based on qt5. Installing the qt4-qmake package is the only way to get the application to run. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qtcreator depends on: ii libbotan-1.10-0 1.10.8-2 ii libc62.19-13 ii libgcc1 1:4.9.1-19 ii libqt5concurrent55.3.2+dfsg-4+b1 ii libqt5core5a [qtbase-abi-5-3-2] 5.3.2+dfsg-4+b1 ii libqt5declarative5 [qtquick1-abi-5-2-1] 5.3.2-3 ii libqt5designer5 5.3.2-3 ii libqt5designercomponents55.3.2-3 ii libqt5gui5 5.3.2+dfsg-4+b1 ii libqt5help5 5.3.2-3 ii libqt5network5 5.3.2+dfsg-4+b1 ii libqt5printsupport5 5.3.2+dfsg-4+b1 ii libqt5qml5 [qtdeclarative-abi-5-3-2] 5.3.2-4 ii libqt5quick5 5.3.2-4 ii libqt5script55.3.2+dfsg-2 ii libqt5sql5 5.3.2+dfsg-4+b1 ii libqt5sql5-sqlite5.3.2+dfsg-4+b1 ii libqt5webkit55.3.2+dfsg-3 ii libqt5widgets5 5.3.2+dfsg-4+b1 ii libqt5x11extras5 5.3.2-2 ii libqt5xml5 5.3.2+dfsg-4+b1 ii libstdc++6 4.9.1-19 ii libx11-6 2:1.6.2-3 ii qml-module-qtquick-controls 5.3.2-2 ii qml-module-qtquick2 5.3.2-4 ii qtchooser47-gd2b7997-2 ii qtcreator-data 3.2.1+dfsg-6 Versions of packages qtcreator recommends: ii gdb7.7.1+dfsg-5 ii konsole [x-terminal-emulator] 4:4.14.2-1 ii make-guile [make] 4.0-8 ii qt5-doc5.3.2-3 ii qtbase5-dev-tools 5.3.2+dfsg-4+b1 ii qtcreator-doc 3.2.1+dfsg-6 ii qtdeclarative5-dev-tools 5.3.2-4 ii qtquick1-5-dev-tools 5.3.2-3 ii qttools5-dev-tools 5.3.2-3 ii qttranslations5-l10n 5.3.2-2 ii qtxmlpatterns5-dev-tools 5.3.2-2 ii xterm [x-terminal-emulator]312-1 Versions of packages qtcreator suggests: pn cmake none pn g++none ii git1:2.1.3-1 ii kdelibs5-data 4:4.14.2-3 pn subversion none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770009: imagemagick: FTBFS on mips
package: imagemagick version: 8:6.8.9.9-3 severity: serious Hi, The latest upload of imagemagic FTBFS on mips (but builds fine on all other architectures). https://buildd.debian.org/status/logs.php?pkg=imagemagickver=8%3A6.8.9.9-3arch=mips 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#770008: calendar-google-provider: Can no longer connect to Google calendars
Package: calendar-google-provider Version: 33.0~b1-1 Severity: grave Justification: renders package unusable Dear Maintainer, calendar-google-provider was working fine for me until yesterday. Now I can't even authenticate to any Google calendars, though Exchange ones still work fine via a different add-on. I assume that the problem is https://developers.google.com/google-apps/calendar/v2/developers_guide_protocol This API is a subject to the Deprecation Policy and will be shutdown on November 17, 2014. Please use APIv3 instead. If it's relevant, upstream Philipp Kewisch mentions that he hopes to release a 1.0.3 soon but I don't know how those version numbers relate to the Debian package ones. Cheers, Mark -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (600, 'stable'), (500, 'stable-updates'), (50, 'testing'), (40, 'unstable'), (30, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769948: udev: dpkg can't configure udev while upgrading to jessie
Control: tag -1 + moreinfo Hi Thuban, Thuban wrote (18 Nov 2014 06:53:16 GMT) : # dpkg --configure --pending Paramétrage de udev (215-5+b1) ... + update_hwdb + udevadm hwdb --update + addgroup --quiet --system input dpkg: erreur de traitement du paquet udev (--configure) : le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1 What's the output of: $ LC_ALL=C getent group input ? Is there any chance that you, or some other software you run, have already created a group called input? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770010: unblock: libsynthesis/3.4.0.47.4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libsynthesis The version in sid fixes bug #768990. The new version contains no other changes. A debdiff is attached. The change was discussed with the release team on #debian-release on November 12th: 13:31 Scorpi if a too sloppy dependency may lead to failure when starting a program (library package may be too old due to a partial upgrade), but the actual wheezy - jessie upgrade is not affected, this bug is not important for jessie, right? 13:32 jcristau if your dependencies are broken, fix them 13:33 Scorpi I fixed the library that causes the broken dependency. the library has only one user so only one binNMU is required. however, I wonder if that should go into jessie 13:33 jmw almost certainly not 13:34 jmw is there a bug number to look at already? 13:34 Scorpi yes, #768990 13:34 -zwiebelbot:#debian-release- Debian#768990: libsynthesis0: unversioned shlibs file causes insufficient dependencies - https://bugs.debian.org/768990 13:35 KiBi jmw: I think that one is fine to push to jessie 13:35 Scorpi when I discovered this the error condition was easy to get. but after the new libsynthesis migrated to testing, it isn't anymore 13:35 KiBi if I understood the problem correctly, remember it correctly right now, and am not crazy 13:36 KiBi (which makes 3 big ifs) 13:36 jmw yes, that does look ok 13:36 Scorpi because libsynthesis will be always upgraded due to another versioned dependency in syncevolution-common 13:36 jmw Scorpi: please fix it and open an unblock bug with all relevant details 13:37 Scorpi ok 13:37 jmw you can quote this conversation if you wish 13:37 jmw then there's a chance one of us will remember the details :) To let the bugfix become effective, a binNMU for packages that build-depend on libsynthesis is required. This is only one package: syncevolution. unblock libsynthesis/3.4.0.47.4-2 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.7-05353-g11687ee (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -Nru libsynthesis-3.4.0.47.4/debian/changelog libsynthesis-3.4.0.47.4/debian/changelog --- libsynthesis-3.4.0.47.4/debian/changelog 2014-10-25 20:58:28.0 +0200 +++ libsynthesis-3.4.0.47.4/debian/changelog 2014-11-12 10:33:21.0 +0100 @@ -1,3 +1,9 @@ +libsynthesis (3.4.0.47.4-2) unstable; urgency=medium + + * Make dh_makeshlibs generate a versioned shlibs file (Closes: #768990) + + -- Tino Mettler tino+deb...@tikei.de Wed, 12 Nov 2014 10:09:55 +0100 + libsynthesis (3.4.0.47.4-1) unstable; urgency=medium * New upstream release diff -Nru libsynthesis-3.4.0.47.4/debian/rules libsynthesis-3.4.0.47.4/debian/rules --- libsynthesis-3.4.0.47.4/debian/rules 2014-10-25 20:58:28.0 +0200 +++ libsynthesis-3.4.0.47.4/debian/rules 2014-11-12 10:33:21.0 +0100 @@ -19,6 +19,9 @@ override_dh_strip: dh_strip --dbg-package=libsynthesis-dbg +override_dh_makeshlibs: + dh_makeshlibs -V + PATCH_EXPORT_SCRIPT=/usr/share/gitpkg/hooks/quilt-patches-deb-export-hook export-patches: [ ! -r debian/patches ] || \
Bug#769625: Unreproducible
severity 769625 important thanks On Tue, 18 Nov 2014 10:53:47 +0800 積丹尼 Dan Jacobson jida...@jidanni.org wrote: A fresh reinstall still reproduces it on my j3 machine. No bug however on j2. So lowering severity as it appears to be a problem with a single instance and therefore likely to be a local problem, not a problem with the package. NW Could this be related to a plugin or extension installed on the NW system? Here is a list of the different packages between j2 (left) and j3. Plugins and extensions wouldn't be packages, necessarily. These could be third-party downloads made within the browser. The list would be available via the Preferences menu. The list of libraries needed by the binary is obtained with: $ objdump -p /usr/bin/midori I've got no idea why you did anything with libneon27-gnutls. It is not related. There is some user configuration in ~/.config/midori/ The fact that this is only reproducible on a single machine points at a problem of local configuration - with a browser, that's typically an extension or plugin. I can't tell you which commands to run as this is a problem specific to your local machine. There were no changes to the midori binary with the current version, only to the debian packaging. It was simply a rebuild against updated libraries in unstable. An out of date plugin or extension can easily cause issues as it does not get updated at the same time. If the plugin had been packaged, it would likely have been rebuilt regularly. Plugins and extensions installed manually cannot be updated. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp6N4R_ImXg8.pgp Description: OpenPGP digital signature
Bug#766121: upstart: please conflict with systemd-sysv
Source: upstart Followup-For: Bug #766121 Seems to be fixed? Just installed upstart over sysvinit-core and it worked ok. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769941: libgstreamer-plugins-base1.0-0: Iceweasel crashes with gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
On Mo, 2014-11-17 at 19:13 +, George B. wrote: Package: libgstreamer-plugins-base1.0-0 Version: 1.4.4-2 Severity: critical Justification: breaks unrelated software Hello, Iceweasel has started crashing when I try and login into Google Mail. Looking at the backtrace it appears to be caused by libgstreamer, so filing a bug against this package (AFAIK this particular package is where those functions came from). Apologies if this was supposed to filed against a different package - feel free to re-assign in that case. [...] Hi, thanks for reporting this. I assume it first started to appear when upgrading from 1.4.3 to 1.4.4 yesterday? Can you always reproduce it when logging in on GMail? Which version of iceweasel are you using? It does not crash for me unfortunately. If you can always reproduce it, could you run iceweasel in valgrind (don't forget to install valgrind-dbg)? Set G_SLICE=always-malloc in the environment and run valgrind with --track-origins=yes and --trace-children=yes This looks like either stack corruption somewhere, or something in iceweasel released objects that it is still going to use. I'm not aware of any change from 1.4.3 to 1.4.4 that could be related to this unfortunately. signature.asc Description: This is a digitally signed message part
Bug#762016: ladish FTBFS on parisc architecture, patch attached
While you're at it, could you add defined(__aarch64__) to that test so that it will build on arm64? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770012: installation-reports: Debian Installer Jessie Beta 2
Package: installation-reports Version: 2.57 Severity: wishlist Boot method: USB with .iso Image version: http://cdimage.debian.org/cdimage/jessie_di_beta_2/multi-arch/iso-cd/debian-jessie-DI-b2-amd64-i386-netinst.iso Machine: Generic PC assembled in 2011 Partitions: root@debian:~# df -Tl File system Tipo 1K-blocchiUsati Disponib. Uso% Montato su /dev/mapper/debian--vg-root ext4 58529988 5911400 49622364 11% / udevdevtmpfs 102400 10240 0% /dev tmpfs tmpfs 3280432 9316 3271116 1% /run tmpfs tmpfs 8201076 2128 8198948 1% /dev/shm tmpfs tmpfs 51204 5116 1% /run/lock tmpfs tmpfs 82010760 8201076 0% /sys/fs/cgroup /dev/sdb1 ext2 24097254525174006 24% /boot tmpfs tmpfs 16402168 1640208 1% /run/user/117 tmpfs tmpfs 1640216 24 1640192 1% /run/user/1000 /dev/sda1 ext4 60344404 55218556 2037468 97% /media/mdt/92fe4628-9d9b-4d14-84b2-02d0ba568eb8 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [0] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: No problem during install. All works fine. When downloading packages, shows network speed should be useful. d-i ask for use non-free software but some packages are not automatically installed. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769863 Consider to add apt-build and let the user to choose to perform a system-wide rebuild with native optimizations at install time. -- == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20141002 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 Northbridge only single slot PCI-e GFX Hydra part [1002:5a11] (rev 02) lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD890 Northbridge only single slot PCI-e GFX Hydra part [1002:5a11] lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD/ATI] RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] lspci -knn: 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port B) [1002:5a16] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port D) [1002:5a18] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port E) [1002:5a19] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port F) [1002:5a1a] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port G) [1002:5a1b] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40) lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] lspci -knn: Kernel driver in use: ahci lspci -knn: 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] lspci -knn: Kernel driver in use: ohci-pci lspci -knn: 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:13.0
Bug#769948: udev: dpkg can't configure udev while upgrading to jessie
What's the output of: $ LC_ALL=C getent group input When I run this command : $ LC_ALL=C getent group input input:x:1001:xavier `xavier` is the user running the command. Is there any chance that you, or some other software you run, have already created a group called input? I don't think so. What king of package could have done this? Regards -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770011: lynx -dump badly converts #x2026; (with French locale at least)
Package: lynx Version: 2.8.9dev1-2 Severity: normal When I do lynx -dump http://raphaelhertzog.com/ /tmp/dump with a UTF-8 locale I get a file that is not valid UTF-8: $ isutf8 /tmp/dump /tmp/dump: line 7, char 1, byte offset 23: invalid UTF-8 code $ head -n 7 /tmp/dump | tail -n 1 Search this website� Search This comes from an input field with « value=Search this website#x2026; » As far as I know #x2026; is valid and should be converted to the UTF-8 character …. Note that the same operation with the C locale will convert that character to a single dot. So the problem is really only when you use an UTF-8 locale. Cheers, -- System Information: Debian Release: jessie/sid APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 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 lynx depends on: ii lynx-cur 2.8.9dev1-2+b1 lynx recommends no packages. lynx 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#551590: metacity: system bell inaudible in X
Hi, Samuel Thibault wrote (06 Nov 2010 22:46:20 GMT) : This is a me too. While trying to make gdm beep somehow, I stumbled across metacity disabling XkbAudibleBellMask, which thus makes the core bell rerouted via some gnome daemon. Setting /desktop/gnome/sound/event_sounds to true does work for me in my current setup: ii xserver-xorg 1:7.5+7 the X.Org X server ii xserver-xorg-core 2:1.7.7-8 Xorg X server - core server Is it still the case on current testing/sid? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769951: [Pkg-mpd-maintainers] Bug#769951: mpd: `update-rc.d mpd disable' is not enough to be able to run mpd as normal user
Hi, can you have a look what it is that's listening on port 6600? E.g. with sudo netstat -lntp I get tcp6 00 :::6600 :::* LISTEN 1/init Does that mean I am somehow using SystemV init AND systemd ? Clément -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770009: [Pkg-gmagick-im-team] Bug#770009: imagemagick: FTBFS on mips
control: tags -1 + moreinfo On Tue, Nov 18, 2014 at 9:55 AM, Ivo De Decker iv...@debian.org wrote: package: imagemagick version: 8:6.8.9.9-3 severity: serious It is likely not in imagemagick, package does not fail before corrupt png fix (not triggered by built) and source is indentical previous build succeed on ball see https://buildd.debian.org/status/logs.php?pkg=imagemagickver=8%3A6.8.9.9-2arch=mipssuite=sid Could you investigate ? Hi, The latest upload of imagemagic FTBFS on mips (but builds fine on all other architectures). https://buildd.debian.org/status/logs.php?pkg=imagemagickver=8%3A6.8.9.9-3arch=mips Cheers, Ivo ___ Pkg-gmagick-im-team mailing list pkg-gmagick-im-t...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769917: survex-aven: No Display and/or controls on opening 3d file
Reminds me that on the last update the driver for my graphic card had a forced change to nvidia-legacy-304xx-driver (I think) not sure what from. I could not get the nouveau driver to work properly, although that was a while (years) back Andrew On 17/11/14 23:36, Olly Betts wrote: What does this report: glxinfo|grep OpenGL OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NV46 OpenGL version string: 2.1 Mesa 10.3.2 OpenGL shading language version string: 1.20 OpenGL extensions: OpenGL ES profile version string: OpenGL ES 2.0 Mesa 10.3.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 OpenGL ES profile extensions: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769972: New CTTE members
* Don Armstrong (d...@debian.org) [141118 02:39]: On Mon, 17 Nov 2014, Bdale Garbee wrote: Works for me. I like the start considering wording, too, as opposed to closing the call for nominations. Good thought. very nice indeed. OK. I've written the draft of this here: http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/769972_new_ctte_members/call_for_nominations.txt Feel free to make any changes. I'll send out the announcement in 24 hours unless someone objects. Thanks. Unfortunatly I have to run a conference the next days, so please don't expect further answers from me right now. But as long as you all agree the text is good, it's good for me as well. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769593: [Ceph-maintainers] Bug#769593: ceph: systemd service
Dmitry Smirnov only...@debian.org writes: On Mon, 17 Nov 2014 17:39:07 Gaudenz Steinlin wrote: I don't particularly like this in it's current state. The line ExecStartPre=-/bin/systemctl start ceph-osd* seems very wrong to me. Very wrong? Why? IMHO it is elegant because you can't define dependency on service if you don't know its name (or maybe I just couldn't find how to write a dependency on something like ceph-osd@#). It works correctly too as it can start only _enabled_ services. To me it looks very wrong because it goes back to custom scripting (calling a command) instead of using built in systemd facilities. IMO systemd is about getting rid of complex error prone scripts like the ceph init script. The fact that it's possible to replace this init script by 3 config files with 5-10 lines each is a hughe advantage (IMHO). The meta service file might work now, but it looks like something bound to bite you later. I'm not a systemd expert but I did not find an easy way to create something like a meta-service in a way that looks like integrated into systemd. But then I don't think that's needed either. The way the current init script tries to start all the different daemons in one script always seemd odd to me. Do we need a meta service like this? Unfortunately we need it for compatibility. Otherwise systemd tries to start SysV script and we have a mess much worse than just having no-op meta service... If that's the only reason you would like to have this service file, then there is an easier solution. The standard way to avoid this is to install a service file which is a symlink to /dev/null. In other words /lib/systemd/system - /dev/null. There are various examples of this already in the systemd package. I agree with this. Having multiple instances per machine of ceph-mon or ceph-mds does not make sense. On the other hand your proposed implementation uses %H which resolves to the hostname. This is not compatible with the current implementation in the init script which parses the configuration file to find the id of the mds and mon. I'm not sure how to solve this, but IMO all distributions should do this in the same way and at the very least we need an upgrade path for users that don't have the hostname as the id of their mon and mds (like having mon.1, mon.2, ... instead of node1, node2, ...). I see 3 possible solutions: - Add a script similar to the code in the current init script which parses the config file to get the id and use that when starting the daemon. - Agreement that mons and mds should have their ids equal to the hostname. I don't really like that solution as it seems quite inflexible. - Use a service template (with the @) nonetheless. This is probably the simplest solution but requires more manual intervention by the cluster administrator. He has to set the id manually when enabling the service. I didn't look deeper into this argument but if I recall correctly you can't start daemon without passing hostname, right? It _seems_ to work since it may try to bring up service even when it doesn't have corresponding section in ceph.conf... would it be enough if upstream modifies service to ignore host name supplied through command line and use ceph.conf only? I reckon it is merely a documentation issue which may worth mentioning for transition to systemd rather than introduce and fairly ugly workarounds... You don't pass the hostname, you pass the id. They don't have to match. Passing a wrong id does not work as the daemon then does not find it's store. I don't think this is merley a documentation issue. I'm not even sure if it's possible to rename a mon. Some other discussion points: - Restart policy: I think we should take advantage of the fact that systemd can monitor processes and restart them if they fail. I propose to start the daemon in the forground (like it's done already) and set Restart=on-failure. See man systemd.service[1] for the details what this means. Do we need custom values for RestartSec (time to sleep before restart, default 100ms), StartLimitInterval, StartLimitBurst (both related to start rate limiting, default 5 times in 10 seconds)? See boilerplate in my ceph-osd@.service. Yes, we need all this to avoid infinite restarts as well as to avoid resarting services too fast. Malfunctioning OSD which dies soon after it restarted can put cluster to permanent peering state if restarted too often. By default systemd only restarts 5 times and then gives up. So permanent restarts are not a problem. After that the values only limit manual restarts. If someone has good values which are backed by evidence I don't have anything against changing the default. But until then I would just go with the systemd defaults. One thing which makes me _very very_ unhappy about Ceph is that its OSDs are unstable because upstream do not treat 'em like mission-critical service and
Bug#770013: libjpeg62-turbo : Conflicts: libjpeg62 but 1:1.3.1-3 is installed.
Package: libjpeg62-turbo Version: 1:1.3.1-10 Severity: important Tags: upstream Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** * What led up to the situation? Installing evince * What exactly did you do (or not do) that was effective (or ineffective)? I manually installed libjpeg-turbo_1.0.1_i386.deb wget 'http://sourceforge.net/projects/libjpeg-turbo/files/1.0.1/libjpeg- turbo_1.0.1_i386.deb/download' -O libjpeg-turbo_1.0.1_i386.deb sudo dpkg -i libjpeg-turbo_1.0.1_i386.deb * What was the outcome of this action? I was able to install evince, but neither libjpeg62-turbo nor libpoppler46 can be installed * What outcome did you expect instead? To be able to install both packages -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769687: no network is a common condition
Hi, On Dienstag, 18. November 2014, Martin Pitt wrote: This isn't meant literally -- with no network access at all, a buildd couldn't build anything as it couldn't install any build deps or upgrade chroots, etc. sure, the buildd must have network. but the package itself must build fine without network access. It must be able to access any archive mirror (even a local one if you really have no network), and that's all that the tests do. also not for test runs. it's impossible to get reliable builds if you rely on outside parameters... So, I'll look at this, but it is a really unusual scenario IMHO and certainly doesn't warrant release-critical status. I still disagree :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#770014: upstart: no login prompt on tty1
Source: upstart Severity: normal Hello, I replaced sysvinit with upstart and when I booted I have no prompt. Apparently login propmpt is not available neither on tty1 nor ttyS0. There is login prompt on tty2 but this is not shown. Note that in the case when plymouth shows pretty graphics or text progressbar it is obvious that the tty1 is taken by plymouth. However, both in qemu (with the default Cirrus graphics emulation) and on my tablet plymouth faios completely so there is just inexpliacble void on tty1. I think this could be resolved by printing a message on the console which would get hidden by plymouth if it works and would show when it does not. Alternatively, there is an error saying something about fallback graphics process failing so the plymouth failure can be also detected. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751827: python-virtualenv: version of pip in virtualenvs fails to uninstall some packages
1.5.6-3 doesn't seem to be working over here even on a fresh virtualenv Installing collected packages: pillow Found existing installation: Pillow 2.4.0 Can't uninstall 'Pillow'. No files were found to uninstall. - Jack Laxson
Bug#770015: libaudio2: [multiarch] co-installation of libaudio2:i386 and libaudio2:amd64 impossible
Package: libaudio2 Severity: normal Dear Maintainer, * What led up to the situation? I install both libaudio2:i386 and libaudio2:amd64 (the former for being able to install skype) * What was the outcome of this action? Installation error: dpkg: error processing archive /var/cache/apt/archives/libaudio2_1.9.4-1+b1_i386.deb (--unpack): trying to overwrite shared '/usr/share/doc/libaudio2/changelog.Debian.gz', which is different from other instances of package libaudio2:i386 Errors were encountered while processing: /var/cache/apt/archives/libaudio2_1.9.4-1+b1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: dpkg: dependency problems prevent configuration of libqtgui4:i386: libqtgui4:i386 depends on libaudio2; however: Package libaudio2:i386 is not installed. * What outcome did you expect instead? Installation successful. * What solution did you find? A manual removal of /usr/share/doc/libaudio2/changelog.Debian.gz -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769907: general: non-sysvinit init systems are made of fail
On 18 November 2014 00:52, Thomas Goirand z...@debian.org wrote: On 11/18/2014 03:50 AM, Michal Suchanek wrote: With current sysvinit the serial console is also used as main but sysvinit-core does not produce any messages on tty0 whatsoever and so does not mislead the user into thinking that useful boot progress feedback can be obtained on that terminal. This is because bootlogd only supports a single output at a time, and therefore only outputs on the *last* occurrence of the console= boot parameter. The patch that I pointed to resolves this by adding support for outputting to multiple consoles. If you want it for Wheezy, I have it here (as I use it for my unofficial OpenStack backport repo, it's in that repository): http://archive.gplhost.com/debian/pool/juno-backports/main/s/sysvinit/ This is nice but I wonder if it resolves the problem. Do fsck messages go through bootlogd? Also iirc bootlogd is an optional addon that logs the init messages into a file which is by default not installed. On 11/18/2014 03:50 AM, Michal Suchanek wrote: systemd on the other hand prints selected messages on both terminals but most messages go only to the main serial terminal. Yet another WTF, and probably if you ask upstream, they'll find a good reason for that, and will tag +wontfix if you submit a bug... I'd be curious to know what's the (twisted) reasoning behind. Maybe because upstream considers that ttyS0 is for debugging, which IMO is wrong (it should be considered as a normal console, just like tty0, and debug messages should also be printed to tty0 anyway). BTW, it's good to know that we have a way to debug things with systemd, thanks for the tip! :) I think that the reason is that ttyS0 comes later on kernel commandline and all init systems here agree that it should make it the main console. The problem is probably impedance mismatch when integrating several init bits. I suspect that systemd dutifully logs its own messages to all consoles but sysv-rc only logs to the main console. I would strongly suggest that you file bugs against both systemd and upstart then! (and *not* using the general pseudo-package...) Which one would it be in this case? Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767266: unblock: plymouth/0.9.0-9
retitle 767266 unblock: plymouth/0.9.0-9
thanks
Dear release team,
Could you please unblock plymouth/0.9.0-9 that has been now uploaded to
unstable.
The scope of this unblock request has changed a bit, but I think the
changes are quite minimal.
The issue mentioned in the initial request (initramfs generation
failing in some conditions) has been fixed as well but with a less
invasive way than creating a new package as initially thought.
The patch added by Sjoerd has already been merged upstream.
plymouth (0.9.0-9) unstable; urgency=medium
[ Laurent Bigonville ]
* debian/control: Add a dependency against init-system-helpers as we are
explicitly using deb-systemd-helper in the plymouth postinst script
(Closes: #767937)
* debian/local/plymouth.hook: Test if the plugin is present on disk before
trying to copy it to the initramfs (Closes: #767170)
* debian/control: Reword the package description. (Closes: #768350)
Thanks to Justin B Rye justin.byam@gmail.com
* debian/local/plymouth.hook: Properly copy .plymouth file into the
initramfs for themes that are not shipping images, this should fix the
tribar theme.
[ Sjoerd Simons ]
*
debian/patches/debian/patches/utils-Don-t-create-unix-sockets-non-blocking.patch:
+ Added. Don't open unix socket connections as non-blocking as the read
function assume blocking sockets. Fixes plymouth failing to query the
password from the user (Closes: #763276)
-- Sjoerd Simons sjo...@debian.org Mon, 17 Nov 2014 22:42:50 +0100
Cheers,
Laurent Bigonvillediff --git a/debian/changelog b/debian/changelog
index 08a91bf..c05ef6f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,25 @@
+plymouth (0.9.0-9) unstable; urgency=medium
+
+ [ Laurent Bigonville ]
+ * debian/control: Add a dependency against init-system-helpers as we are
+explicitly using deb-systemd-helper in the plymouth postinst script
+(Closes: #767937)
+ * debian/local/plymouth.hook: Test if the plugin is present on disk before
+trying to copy it to the initramfs (Closes: #767170)
+ * debian/control: Reword the package description. (Closes: #768350)
+Thanks to Justin B Rye justin.byam@gmail.com
+ * debian/local/plymouth.hook: Properly copy .plymouth file into the
+initramfs for themes that are not shipping images, this should fix the
+tribar theme.
+
+ [ Sjoerd Simons ]
+ * debian/patches/debian/patches/utils-Don-t-create-unix-sockets-non-blocking.patch:
++ Added. Don't open unix socket connections as non-blocking as the read
+function assume blocking sockets. Fixes plymouth failing to query the
+password from the user (Closes: #763276)
+
+ -- Sjoerd Simons sjo...@debian.org Mon, 17 Nov 2014 22:42:50 +0100
+
plymouth (0.9.0-8) unstable; urgency=medium
* Move the script.so from plymouth-themes to the main plymouth package
diff --git a/debian/control b/debian/control
index ccfcee6..d0a2080 100644
--- a/debian/control
+++ b/debian/control
@@ -27,17 +27,23 @@ Pre-Depends: ${misc:Pre-Depends}
Depends:
${misc:Depends},
${shlibs:Depends},
- initramfs-tools | dracut,
+ initramfs-tools | dracut,
+ init-system-helpers (= 1.18),
Conflicts: console-common
Breaks: plymouth-drm ( 0.9.0-6~), plymouth-themes ( 0.9.0-8~)
Replaces: plymouth-drm ( 0.9.0-6~), plymouth-themes ( 0.9.0-8~)
Suggests:
desktop-base,
plymouth-themes
-Description: Graphical Boot Animation and Logger
- Plymouth provides an attractive boot animation in place of the text messages
- that normally get shown. Text messages are instead redirected to a logfile for
- viewing after boot.
+Description: boot animation, logger and I/O multiplexer
+ Plymouth provides a boot-time I/O multiplexing framework - the most obvious
+ use for which is to provide an attractive graphical animation in place of
+ the text messages that normally get shown during boot. (The messages are
+ instead redirected to a logfile for later viewing.) However, in event-driven
+ boot systems Plymouth can also usefully handle user interaction such as
+ password prompts for encrypted file systems.
+ .
+ This package provides the basic framework, enabling a text-mode animation.
Package: plymouth-x11
Architecture: linux-any
@@ -47,12 +53,16 @@ Depends:
plymouth (= ${binary:Version}),
Recommends: plymouth-themes
Suggests: gdm
-Description: Graphical Boot Animation and Logger (x11 renderer and log viewer)
- Plymouth provides an attractive boot animation in place of the text messages
- that normally get shown. Text messages are instead redirected to a logfile for
- viewing after boot.
+Description: boot animation, logger and I/O multiplexer - X11 renderer and log viewer
+ Plymouth provides a boot-time I/O multiplexing framework - the most obvious
+ use for which is to provide an attractive graphical animation in place of
+ the text messages that normally get shown during boot. (The messages are
+ instead redirected to a logfile for later viewing.) However, in
Bug#770016: Clarify network access for building packages in main
Package: debian-policy Severity: wishlist 2.2.1 says the packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non- main package), In practice there is a consensus that this also means packages must not access external network servers which conforms to the spirit but not to the letter of this section. Note that there may be other requirements which are not codified, as mentioning only things that are packaged is not enough, it should say something like must not use any stuff except for packages in main. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757114: systemd-run --user fails
Control: tag -1 + moreinfo Ansgar Burchardt wrote (05 Aug 2014 13:01:22 GMT) : trying to use systemd-run --user fails: $ systemd-run --user /bin/sleep 3600 Running as unit run-17508.service. Failed start transient unit: Process org.freedesktop.systemd1 exited with status 1 It works fine for me on current sid: intrige+ 11871 0.0 0.0 5804 660 ?Ss 11:03 0:00 /bin/sleep 3600 Can you still reproduce this bug? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770017: Pinning by glob and version yields unexpected effects
Package: apt Version: 1.0.9.3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I’m trying to avoid a bug in evolution-data-server version 3.12.7.1-2. That package is actually split in many, so I tried to avoid listing all of them and specified Package: /.*/ Pin: version 3.12.7.1-2 Pin-Priority: -1 in my apt-preferences, hoping that this version number is unique, and under that assumption expecting this to apply to e-d-s packages only. It works for e-d-s. Without: $ LANG=C apt-cache policy evolution-data-server evolution-data-server: Installed: 3.12.7.1-1 Candidate: 3.12.7.1-2 Version table: 3.12.7.1-2 0 500 http://http.debian.net/debian/ sid/main amd64 Packages *** 3.12.7.1-1 0 100 /var/lib/dpkg/status With: $ LANG=C apt-cache policy evolution-data-server evolution-data-server: Installed: 3.12.7.1-1 Candidate: 3.12.7.1-1 Package pin: 3.12.7.1-2 Version table: 3.12.7.1-2 -1 500 http://http.debian.net/debian/ sid/main amd64 Packages *** 3.12.7.1-1 -1 100 /var/lib/dpkg/status Unfortunately and unexpectedly, this has effects on other packages as well. Without this: $ LANG=C apt-cache policy perl perl: Installed: 5.20.1-2 Candidate: 5.20.1-3 Version table: 5.20.1-3 0 500 http://http.debian.net/debian/ sid/main amd64 Packages *** 5.20.1-2 0 100 /var/lib/dpkg/status With this: $ LANG=C apt-cache policy perl perl: Installed: 5.20.1-2 Candidate: 5.20.1-2 Package pin: (not found) Version table: 5.20.1-3 -1 500 http://http.debian.net/debian/ sid/main amd64 Packages *** 5.20.1-2 -1 100 /var/lib/dpkg/status Note that it does not want to upgrade perl any more. Greetings, Joachim - -- Package-specific info: - -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16-3-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16-3-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16-3-amd64$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Architectures:: armhf; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2;
Bug#766670: RC bug in stable and oldstable for getmail4
On Mon, 03 Nov 2014, Osamu Aoki wrote: These only affect stable 4.32.0-2 and oldstable 4.20.0-1. I think that the use of backported current testing package is the reasonable option. The updates listed in the upstream changelog (see below) are releted to security updatyes and their regression fixes? Well, importing new upstream versions is not an option for stable and oldstable. Quite frankly, I am not competent enough to extract a correct set of patches out of these changes without breaking the program? It is too risky since even upstream had few regressions. Maybe you can ask upstream if they are willing to point you the correct set of commits? It's not very nice to let stable and oldstable users with known vulnerabilities. We can hide them under the carpet when they are minor but the flaws described here seem rather important to get fixed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770011: lynx -dump badly converts #x2026; (with French locale at least)
On Tue, Nov 18, 2014 at 10:24:04AM +0100, Raphaël Hertzog wrote: Package: lynx Version: 2.8.9dev1-2 Severity: normal When I do lynx -dump http://raphaelhertzog.com/ /tmp/dump with a UTF-8 locale I get a file that is not valid UTF-8: thanks (I can reproduce this, and saved the relevant test-data). -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#769969: casablanca: FTBFS on non-x86 arches
control: forwarded -1 https://casablanca.codeplex.com/workitem/312 control: forwarded -1 https://casablanca.codeplex.com/workitem/291 Hi Hector, Hello, Your package fails to build from source on Debian autobuilder network on non-x86 architectures. Please check your package build logs at: https://buildd.debian.org/status/package.php?p=casablancasuite=sid Best regards Indeed, I opened the correspondent bug reports upstream, unfortunately I don't have enough manpower to fix them by myself. I'll try to put a git snapshot on experimental if needed, but I don't think this will fix any of the actual build failures. Help might be appreciated :) cheers, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769624: Major Security Flaw when viewing WebM videos.
On So, 2014-11-16 at 16:20 -0800, James Galizio wrote: On Sun, 16 Nov 2014 13:04:27 +0100 Yves-Alexis Perez cor...@debian.org wrote: On dim., 2014-11-16 at 10:48 +0100, Sebastian Dröge wrote: On Sa, 2014-11-15 at 12:01 -0800, James Galizio wrote: Also; just ran iceweasel through the terminal and recreated the steps to the crash. Terminal output below. [...] Segmentation fault That last line makes me believe that this isn't fixed yet; and in any case, having the browser crash is still a bug, no? [Also CC'ing Yves-Alexis who reported the other bug] Definitely, yes. The patch from the other bug is applied, which is supposed to be the fix for the CVE though. Unfortunately the only reference to the fix that I can find is in the Debian bug report as the Mozilla Bugzilla Bug is still non-public. Maybe there are more related changes that were forgotten? Do you know anything about that? :) Also you you get a backtrace of the segfault to see where exactly it comes from? And are you sure packages for that âcrunchbang GNU/Linuxâ are really identical to the Debian ones? -- Yves-Alexis Crunchbang has a separate repo for Crunchbang specific packages; but shares the vast majority of its packages (99%, including all major system libraries) with debian mainline. It uses the official debian repos. When I said I was using the latest version of iceweasel from the experimental branch, I meant it. Also; apologies for not recording the error through gdb. Here's the log that should have been posted; I have a longer version of it if need be, but this seems to be the portion that is relevant to the current issue. [...] Are you using libvpx 1.3.0-3 from Debian too or is it a Crunchbang specific package? The backtrace is relatively useless unfortunately, the memory corruption has happened before that already. Can you reproduce the problem when running in valgrind? Please don't forget to install valgrind-dbg and also relevant other debug packages, then set G_SLICE=always-malloc in the environment and run valgrind with --track-origins=yes and --trace-children=yes and paste the log here. signature.asc Description: This is a digitally signed message part
Bug#765810: eatmydata: be usable with Multi-Arch scenarios, and compatible with old versions in chroot
On Mon, 17 Nov 2014, Mattia Rizzolo wrote: I don't feel this as a so important bug to request a freeze exception. Do you think it is worth an unblock request? I’d like to ask the RT for it, if you agree with including it if they give their okay, yes. Multi-Arch support is a Release Goal, and chroot compatibility is not unimportant either. That is, if you have a look over the patch and don’t have any thing against my solution for it. I planned an upload with only the fix for the FTBFS in a couple of day. OK. (If you need a sponsor for that – I can do that today.) Maybe we can include this change to an upload targeting experimental, asking for pre-approval and once obtained upload to unstable? what do you think of this plan? Good idea, yes. I can do both uploads, if you want. other architectures, *and* another fix of mine, adding the missing multiarch-support Pre-Depends to the library package (probably RC, maybe not for jessie though). You're right, I should add a Pre-Depends as you did. If you want you might commit+push this change to the repo. Okay, will do. Yes, I was writing something similar, but I'm in the middle of an exams period here and I'm lagging a bit... Sure, no problems. We all have lives (I hope ☺). My plan (with upstream ack) was to rewrite eatmydata.sh.in and eatmydata.in in a single eatmydata script, forward it to upstream, This is more or less what I did – except this solution will probably(!) only work with GNU ld.so (I’d have to try BSD’s, but Debian GNU/kFreeBSD uses GNU’s so no trouble there, and I know it ignores Darwin). But I could extend the script to add back support for the other ld.so types in the way upstream currently uses. wait for an inclusion (I waited less than 24 hours for a reply the last time I contacted upstream!), a release and then package the Oh, wow ☺ updated package, for stretch. I can then use your script :) Sure. I would, of course, be willing to help and change the script accordingly. (Being author of a shell has got to be worth something, after all…) bye, //mirabilos -- Why don't you use JavaScript? I also don't like enabling JavaScript in Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766408: python2.7: The os module does not exhibit proper functionality with the open() function.
Control: tags -1 moreinfo
Control: severity -1 normal
On 10/22/2014 11:17 PM, thims wrote:
Package: python2.7
Version: 2.7.3-6+deb7u2
I don't know about this version. Please ask the person who provided this
package.
user: python
import os
os.read('/home/user/nonexisting_file', os.O_TRUNC)
Traceback (most recent call last):
File stdin, line 1, in module
OSError: [Errno 2] No such file or directory: 'home/user/nonexisting_file'
this doesn't make sense. the os.read takes a file descriptor as first argument.
You should attach working code, not pseudo code like this.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770018: RFS: par2cmdline/0.6.11-1 (unblock approved)
Package: sponsorship-requests Severity: normal X-Debbugs-CC: Vincent Cheng vch...@debian.org Dear mentors, I am looking for a sponsor for par2cmdline: Package name: par2cmdline Version : 0.6.11-1 Upstream Author : Ike Devolder et al. URL : https://github.com/BlackIkeEagle/par2cmdline License : GPL-2+ Section : utils It builds a single binary package: par2 - PAR 2.0 compatible file verification and repair tool Mentors URL: http://mentors.debian.net/package/par2cmdline Download with dget: dget -x http://mentors.debian.net/debian/pool/main/p/par2cmdline/par2cmdline_0.6.11-1.dsc Changes since the last upload: * New upstream release: + Fixes a regression causing failure to locate misnamed files during repair. (Closes: #769820) * Bump standards-version to 3.9.6 (no changes needed). A freeze unblock has been approved for upload to unstable, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769962 Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770017: Pinning by glob and version yields unexpected effects
Control: retitle -1 Pinning by regex and version yields unexpected effects On Tue, Nov 18, 2014 at 11:06:12AM +0100, Joachim Breitner wrote: Package: apt Version: 1.0.9.3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I’m trying to avoid a bug in evolution-data-server version 3.12.7.1-2. That package is actually split in many, so I tried to avoid listing all of them and specified I don't think you can do this currently, it won't work with the current implementation. Package: /.*/ Pin: version 3.12.7.1-2 Pin-Priority: -1 in my apt-preferences, hoping that this version number is unique, and under that assumption expecting this to apply to e-d-s packages only. Yes, but it's not a glob, it's a regex. So it probably means I messed this up. The pinning implementation is a bit ... special - it has one pin per package, and then chooses the candidate by this, instead of assigning the pin (priorities) to individual versions and then picking the highest (sans some exceptions, like downgrades). It's something I always wanted to replace, but I have not found the time to fix a bug in my new algorithm and port it to APT yet :( The same applies for more complex glob patterns than *, * simply only supports release pins. It fails for **, though. I think this was probably me too... As a workaround in APT, I think it might be a good idea to only apply a regex pin to a package if a version with the specified Pin constraint exists. That should be closer to what I intended to do. I don't know if it is feasible to implement this, though (as I said, it's a bit weird sometimes). Not sure if we could get a fix into jessie either. Now that we have source package information in the cache, we should probably consider adding pinning by source package (we might have this already, but I'm not sure, I'm not up-to-date). -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 Netiquette. - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769721: distutils should add /usr/local/include/python2.7/ to include path
Control: tags -1 + help On 11/15/2014 10:12 PM, Jakub Wilk wrote: Package: python2.7 Version: 2.7.8-11 distutils, by default, installs header files to /usr/local/include/python2.7/. But this directory in not within include path when you are building extensions (only /usr/include/python2.7/ is). I don't see a good way how to fix that, and don't want to have this directory included by default, because this is the location of an upstream python installation as well, when not configuring with any parameters. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742745: More info for #742745
Control: severity -1 important Control: merge -1 703582 Control: tags -1 upstream patch Control: forwarded -1 https://github.com/spacewalkproject/spacewalk/pull/176 I just found out that the patch suggested by Carsten Menzel in Debian bug #703582 fixes the marshalling exception and lets the client registration at the Spacewalk server succeed. I would like to see this being fixed in Debian jessie, hence I intend to raise the severity to 'serious' and ask release management to unblock a fix for the package. Cheers, Micha -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769797: gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2
On 11/16/2014 04:22 PM, Ludovic Brenta wrote: Matthias Klose writes: known. please wait for the gcc-4.9 4.9.2-2 upload before syncing. OK. Are you planning to request a freeze exception so that 4.9.2 goes into jessie? yes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755992: proftpd-mod-clamav: error: Can not stat file (9): Bad file descriptor
Hello, I have the same problem on Debian Wheezy. Some precisions: 1. Clamav can access the files when I test manually: # clamscan /data/proftpd/TEST/eicar.com /data/proftpd/TEST/eicar.com: Eicar-Test-Signature FOUND 2. The error appears whether DefaultChdir is activated or not (I thought that chroot could be the cause) The configuration used to reproduce the error: /etc/proftpd/proftpd.conf LoadModule mod_clamav.c IfModule mod_clamav.c ClamAV on ClamServer localhost ClamPort 3310 ClamMaxSize 250 Mb /IfModule /etc/clamav/clamd.conf: TCPSocket 3310 TCPAddr 127.0.0.1 Best regards, Jeremie L. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764191: eclipse: FTBFS on armel
Hi Hector, Thank you for the report. It looks like the VM crashed during the build. Could you try again with OpenJDK 7u71 please? Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769593: [Ceph-maintainers] Bug#769593: Bug#769593: ceph: systemd service
Hi Dmitry Smirnov only...@member.fsf.org writes: On Mon, 17 Nov 2014 09:18:50 Sage Weil wrote: Also, +LimitNOFILE=32768 is still going to be problematic as large clusters need to adjust that value up. Need to figure out how to make it tunable... maybe just by using a dedicated 'ceph' user and adjusting it in /etc/security/limit.d/* ? Due to systemd .service file limitations it is hard to make it tunable since LimitNOFILE do not take variables. What are the disadvantages of hardcoding it to higher value? I'm not sure what's best to do... I investigated this a bit. It's possible to have a ceph-osd@.service.d directory with additional configuration options in it. So it's possible to just change this setting without overriding the whole service unit file. But I have found no way to read the vaule from ceph.conf like the sysv init script does. Someone on #debian-systemd confirmed that this is not possible. Is the value in ceph.conf used for anything else than the init script? If it's only used in the init script I'm not sure if it really belongs there. LimitNOFILE=infinity causes this to be set to the maximum possible value (hard limit). Maybe we can just use that. If more than the hard limit is needed, the pam_limits configuration has to be adjusted anyway (also for sysv). Do you see any downsides to setting this value as high as possible for everyone? Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769687: no network is a common condition
Holger Levsen [2014-11-18 10:44 +0100]: It must be able to access any archive mirror (even a local one if you really have no network), and that's all that the tests do. also not for test runs. it's impossible to get reliable builds if you rely on outside parameters... Why is that outside parameters? It's calling apt-get download for a few packages just as the build dep installation stage does? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#770020: unblock: nsd/4.1.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package nsd
Hi,
this release fixes RC bug (#743396), the dh_linkdoc fixed by Julien,
but he forgot to add Pre-Depends: ${misc:Pre-Depends} to pull new
dpkg, thus a new build.
$ diffstat nsd_4.1.0-2.debdiff
changelog| 16
control | 22 ++
copyright| 15 +++
nsd.postinst |4 ++--
nsd3.maintscript |7 ---
nsd3.postinst|8
rules|5 +
7 files changed, 44 insertions(+), 33 deletions(-)
nsd (4.1.0-2) unstable; urgency=medium
.
[ Jonathan Dupart ]
* Fix invalid user: 'nsd' move the debhelper tag at the end of the
postinst script (Closes: #743396)
.
[ Julien Cristau ]
* Stop using dh_installdocs --link-doc, as that makes nsd binNMU-unsafe.
Deal with the symlink-to-dir migration.
.
[ Ondřej Surý ]
* Add ${misc:Pre-Depends} to pull new dpkg before calling symlink_to_dir
* Call wrap-and-sort -a on d/control and d/copyright
unblock nsd/4.1.0-2
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (800, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 3.0 (quilt)
Source: nsd
Binary: nsd, nsd3
Architecture: any all
Version: 4.1.0-2
Maintainer: Ondřej Surý ond...@debian.org
Homepage: http://www.nlnetlabs.nl/nsd/
Standards-Version: 3.9.4
Vcs-Browser: http://anonscm.debian.org/?p=pkg-nlnetlabs/nsd.git
Vcs-Git: git://anonscm.debian.org/pkg-nlnetlabs/nsd.git
Build-Depends: bison, debhelper (= 9), dh-autoreconf, dpkg-dev (= 1.16.1.1~),
flex, libevent-dev, libssl-dev, openssl, po-debconf
Package-List:
nsd deb net optional arch=any
nsd3 deb oldlibs extra arch=all
Checksums-Sha1:
cb4ec496eaec5bfbd5b9f4b361da2a0a79d17030 1056649 nsd_4.1.0.orig.tar.gz
5a318f170e733e25b72b59ca604fb56d884ea490 16452 nsd_4.1.0-2.debian.tar.xz
Checksums-Sha256:
ec3f6902f6f26a6b9248dcd7e9f42472fa52755740b4ba6b9d3bd08910b39b62 1056649
nsd_4.1.0.orig.tar.gz
af10810b32713911b3e5b1b9b214fd2a4b57ea707642900b7593851e3dea91b1 16452
nsd_4.1.0-2.debian.tar.xz
Files:
6597b3240c7f28c8861beb3cd9a38df3 1056649 nsd_4.1.0.orig.tar.gz
d2ae5d80fce116416ae50615ca08c076 16452 nsd_4.1.0-2.debian.tar.xz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQJ8BAEBCgBmBQJUayAXXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMEI5MzNEODBGQ0UzRDk4MUEyRDM4RkIw
Qzk5QjcwRUY0RkNCQjA3AAoJEAyZtw70/LsHhUEQAJfZImyjpzop8+sdOrke5ZVp
T2XI5O0rL/gW7CXpFM7s5e9tU9Kp0bY1lZob8d00Gci7cXHQeHKFBgkK6N1a6aXB
e4mW/3BYJJgzLLjfTqF8GgnDfitgcbn/r/PnFKNNCEWHIAmAUG0N3+P01UaBhQiT
8t3nuLJazaeNxJl4VCGYgepPsvDJguw8i3DX7+Yy5kOb3LmVadMbKdXx6IthNGcG
T5HLTMANiAjEtQ3nXhviALW77KFvFLZwiTd3ha3QxlMAdczDjtN88bQ9HuSokljy
tD0qNyFaVrQQA0Kyhz+yfSVP5rAHiCkHDL6kkLpgL11X3PV09px7wfz6D56P9ni5
5i5orkZTbgX4d33jUmiGuvge8AtEi2rVR4p5g4q2NQAlNw3e8gWm1j0B0Vngr6+I
hPEHz11KPIKpfkaZb1ArH2h1NxNCTiMuXs6CFdLfVtDLXHUyHo34/yDyYFMgtLHh
35ktq4jMvekGlbSmOHY5+gljmI+TL+UEgh4bdpZtWyHVhiW05ZpHYMEPLFBCoQ0s
M/L0T6fpJvKsf8ShNChHhcJztvpiTjUaZXXsRKAPGJdw8xfjsU7fgbpB+ZHupjfB
2CJB0npn7t4gnlE2xqicS7vX/1yAVvBRCZh9hGMkRj5Zk4XiqjvQsJLQBpxsAxvR
89FkvqlCFBSHLBxrhza3
=PBd8
-END PGP SIGNATURE-
diff -Nru nsd-4.1.0/debian/changelog nsd-4.1.0/debian/changelog
--- nsd-4.1.0/debian/changelog 2014-09-04 16:12:43.0 +0200
+++ nsd-4.1.0/debian/changelog 2014-11-18 11:29:24.0 +0100
@@ -1,3 +1,19 @@
+nsd (4.1.0-2) unstable; urgency=medium
+
+ [ Jonathan Dupart ]
+ * Fix invalid user: 'nsd' move the debhelper tag at the end of the
+postinst script (Closes: #743396)
+
+ [ Julien Cristau ]
+ * Stop using dh_installdocs --link-doc, as that makes nsd binNMU-unsafe.
+Deal with the symlink-to-dir migration.
+
+ [ Ondřej Surý ]
+ * Add ${misc:Pre-Depends} to pull new dpkg before calling symlink_to_dir
+ * Call wrap-and-sort -a on d/control and d/copyright
+
+ -- Ondřej Surý ond...@debian.org Tue, 18 Nov 2014 11:17:39 +0100
+
nsd (4.1.0-1) unstable; urgency=medium
* New upstream version 4.1.0
diff -Nru nsd-4.1.0/debian/control nsd-4.1.0/debian/control
--- nsd-4.1.0/debian/control 2014-09-04 16:12:43.0 +0200
+++ nsd-4.1.0/debian/control 2014-11-18 11:29:24.0 +0100
@@ -2,15 +2,15 @@
Section: net
Priority: optional
Maintainer: Ondřej Surý ond...@debian.org
-Build-Depends: debhelper (= 9),
+Build-Depends: bison,
+ debhelper (= 9),
+ dh-autoreconf,
dpkg-dev (= 1.16.1.1~),
- dh-autoreconf,
- bison,
flex,
+ libevent-dev,
libssl-dev,
- libevent-dev,
- openssl,
- po-debconf
+
Bug#770019: samba: Adding Printer Drivers to [print$] fails
Package: samba Version: 2:3.6.19-1~bpo70+1 Severity: normal Dear Maintainer, I was trying to enable Point-and-Print for my Domain Users following typical instructions like https://wiki.samba.org/index.php/Samba_as_a_print_server. After preparing the share [print$] with appropriate rights, I use the wizard from Windows 7 (64bit) to upload the printer drivers, however this fails reproducibly with the following log-entry: printing/nt_printing.c:944(move_driver_file_to_download_area) move_driver_file_to_download_area: Unable to rename [x64/SOMEFILE] to [x64/3/SOMEFILE]: NT_STATUS_NETWORK_BUSY Access rights for the [print$] share and dirs below are 775 (sticky-bit set), and the log does not show any problems accessing the files - just the one shown above... -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.16.15 ii libacl1 2.2.51-8 ii libattr1 1:2.4.46-8 ii libc6 2.13-38+deb7u6 ii libcap2 1:2.22-1.2 ii libcomerr21.42.5-1.1 ii libcups2 1.5.3-5+deb7u4 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u2 ii libk5crypto3 1.10.1+dfsg-5+deb7u2 ii libkrb5-3 1.10.1+dfsg-5+deb7u2 ii libldap-2.4-2 2.4.31-1+nmu2 ii libpam-modules1.1.3-7.1 ii libpam-runtime1.1.3-7.1 ii libpam0g 1.1.3-7.1 ii libpopt0 1.16-7 ii libtalloc22.0.7+git20120207-1 ii libtdb1 1.2.10-2 ii libtevent00.9.16-1 ii libwbclient0 2:3.6.19-1~bpo70+1 ii lsb-base 4.1+Debian8+deb7u1 ii procps1:3.3.3-3 ii samba-common 2:3.6.19-1~bpo70+1 ii update-inetd 4.43 ii zlib1g1:1.2.7.dfsg-13 Versions of packages samba recommends: ii logrotate 3.8.1-4 ii tdb-tools 1.2.10-2 Versions of packages samba suggests: pn ctdb none pn ldb-tools none ii openbsd-inetd [inet-superserver] 0.20091229-2 ii smbldap-tools 0.9.7.1 ii winbind 2:3.6.19-1~bpo70+1 -- debconf information: samba/generate_smbpasswd: true samba/run_mode: daemons samba-common/title: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762690: libhibernate-validator-java: affected by CVE-2014-3558
On Sun, 02 Nov 2014 23:38:30 +0100 Emmanuel Bourg ebo...@apache.org wrote: libhibernate-validator-java is only used as a build dependency of libhibernate3-java. No package depends on it at runtime, so the risk of being affected by this vulnerability is rather low, if not zero. Thank you for this information but it's not really a satisfactory answer. We can't knowingly ship libraries with serious security issues. It's not the first time I see that kind of answers from the java team. Please at least package new upstream versions with the appropriate security fixes. I can understand that backporting security patches might be difficult but packaging new upstream versions is the basis of our work in Debian. We can't stay with outdated versions and known vulnerabilities for ever. Please send a call for help on debian-devel(-announce) if you are not able to do the basic work of keeping your packages up-to-date. Then the publicity team might relay your message further... and maybe you'll find some supplementary volunteers. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765924: RFS: libgom/0.2.1-1
Le Mon, 17 Nov 2014 06:33:41 -0800, Joseph Herlant herla...@gmail.com a écrit : Hi Laurent, On Mon, Nov 17, 2014 at 6:16 AM, Laurent Bigonville bi...@debian.org wrote: Are you still looking for a sponsor? Yes I am. Would you agree to but your package under the GNOME team maintenance? GOM will become an official module starting with the GNOME 3.16 release and having coordinated uploads might be important for us. Actually that's what I wanted to do in the 1st place. I made an Alioth request to be part of the Gnome team and sent 2 mails to the debian-gtk-gnome list back in mid october but didn't got any answer. That's why I pushed it to collab-maint. We are planning to switch to git for the maintenance of our packages anyway, moving the repository afterwards would be trivial. If you want to put the package under the team maintenance you can add Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org as maintainer and add you to the uploaders (or the opposite if you prefer). For alioth membership, I guess the best is to pass on IRC (#debian-gnome on the OFTC network) Also I think you should also enable the introspection support to allow other language that C to be able to use the library. This would require adding a new gir1.2-gom-1.0 package. The API documentation might also be interesting for some people, I guess it could be added to the -dev package. No problem. I'll do that this week-end (changed my computer so I have to reinstall some tools before. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768189: macchanger: Automatic macchanger makes wifi unusable
retitle 768189 should not automatically change MAC (w/o user consent) thanks On Wed, Nov 05, 2014 at 01:29:58PM -0600, nandhp wrote: I upgraded to macchanger version 1.7.0-2 on Saturday, and it completely broke my wifi. I believe this is due to the new feature, where it automatic changes the MAC address every time I connect. The same happened to my wired connection. macchanger is great a tool, but automatically changing MAC address without user consent is puzzling at best, and could lead to unexpected breakages. I think macchanger should not do that by default and be installed out of the box with ENABLE_ON_POST_DOWN=no. If the maintainer feels strongly about making the package automatic change MACs, then there should be a DebConf prompt (but still defaulting to no, IMHO). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769593: [Ceph-maintainers] Bug#769593: ceph: systemd service
On Tue, 18 Nov 2014 10:39:46 Gaudenz Steinlin wrote: To me it looks very wrong because it goes back to custom scripting (calling a command) instead of using built in systemd facilities. IMO systemd is about getting rid of complex error prone scripts like the ceph init script. The fact that it's possible to replace this init script by 3 config files with 5-10 lines each is a hughe advantage (IMHO). The meta service file might work now, but it looks like something bound to bite you later. Agreed. Meta service makes sence only for compatibility (or maybe only for stopping everything ceph-related with one command). Native systemd services seems to be nicer. I'm not a systemd expert but I did not find an easy way to create something like a meta-service in a way that looks like integrated into systemd. But then I don't think that's needed either. The way the current init script tries to start all the different daemons in one script always seemd odd to me. Do we need a meta service like this? Unfortunately we need it for compatibility. Otherwise systemd tries to start SysV script and we have a mess much worse than just having no-op meta service... If that's the only reason you would like to have this service file, then there is an easier solution. The standard way to avoid this is to install a service file which is a symlink to /dev/null. In other words /lib/systemd/system - /dev/null. There are various examples of this already in the systemd package. Cool, we can turn it to complete no-op. It may be nice -- I didn't think of it. You don't pass the hostname, you pass the id. They don't have to match. Passing a wrong id does not work as the daemon then does not find it's store. I don't think this is merley a documentation issue. I'm not even sure if it's possible to rename a mon. OK... By default systemd only restarts 5 times and then gives up. No it is incorrect. My OSDs are crashing like crazy and with Restart=on- abnormal service restarted within seconds after failure and never give up so it may be restarted hundred times or more. So permanent restarts are not a problem. After that the values only limit manual restarts. If someone has good values which are backed by evidence I don't have anything against changing the default. But until then I would just go with the systemd defaults. Defaults couldn't be worse and I already explained why. Commented boilerplate in ceph-osd@.service is closest I could get to useful restart but then I asked myself whether restart is needed at all and couldn't produce a definitive answer. I tend to leave restart code commented in case someone decide to try it (or feel that it may be useful). At the moment I'm against restart enabled by default -- this realisation comes from weeks of experimentation. I can't follow your reasoning here. On one hand you think OSDs are unstalbe (which does not match my experience) but on the other hand you don't want to restart them. That seems odd to me. Because restart is disruptive if OSD crashes right away (or shortly) after initialisation. The faulty hardware argument is a good one. Is there a way to detect this? No, there isn't. Do OSDs exit with a specific code in this case. That would be best as we could just add this code to the list of successful exit codes. Is there a specific exit codes for asserts in code? No, so this is not an option. - Mounting OSD filesystems: For sysvinit the init script mounts the OSD filesystem. None of the proposed systemd solutions mounts any filesystems. How did you miss RequiresMountsFor=/var/lib/ceph/osd/ceph-%i in my ceph- osd@.service file? I did not miss this. But this does not cause the filesystem to be mounted and does not stop the deamon from starting if there is no configuration to mount the filesystem at all, because it does not know about it (see below). I'm not sure I follow you... I may have misunderstood RequiresMountsFor... Would it attempt start service if RequiresMountsFor location is not mounted? Or do you mean that mount points could be missing from fstab? I'd say that principle of least surprise dictates that all mount points should be listed in fstab, not mounted by some obscure logic/script... RequiresMountsFor= Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path. Mount points marked with noauto are not mounted automatically and will be ignored for the purposes of this option. If such a mount should be a requirement for this unit, direct dependencies on the mount units may be added (Requires= and After= or some other combination). I'm still not sure I understand how systemd works and what's your plan... This means you don't have to list the mount points. Systemd is clever enough to figure out what it has to mount to make the directory
Bug#770021: lintian: check for FIXME
Package: lintian Version: 2.5.30 Severity: wishlist Dear Maintainer, When packaging, I add the 'FIXME' word in some points to review after an initial result/package test. I think that it can be util for other maintainers. I put below an example, simulating that we need update a field because the upstream has a new homepage and the d/control is using an old URL: Source: mac-robber Section: utils Priority: optional Maintainer: Debian Forensics forensics-de...@lists.alioth.debian.org Uploaders: Joao Eriberto Mota Filho eribe...@debian.org Build-Depends: debhelper (= 9) Standards-Version: 3.9.5 Homepage: FIXME http://www.sleuthkit.org/mac-robber Vcs-Browser: http://anonscm.debian.org/cgit/forensics/mac-robber.git Vcs-Git: git://anonscm.debian.org/forensics/mac-robber.git Thanks for your attention. Regards, Eriberto -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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#742761: evince: patch provided at bugzilla bugreport
Package: evince Version: 3.14.1-1 Followup-For: Bug #742761 There is now a simple patch provided at the bugzilla bug report, which has already been pushed to evince master. Could this patch be applied in time for jessie? thanks! Florian -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evince depends on: ii evince-common 3.14.1-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-13 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libevdocument3-4 3.14.1-1 ii libevview3-3 3.14.1-1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.0-2 ii libgtk-3-0 3.14.4-2 ii libnautilus-extension1a3.14.0-1 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-01.36.8-2 ii libsecret-1-0 0.18-1+b1 ii libxml22.9.1+dfsg1-4 ii shared-mime-info 1.3-1 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages evince recommends: ii dbus-x11 1.8.10-1 ii gvfs 1.22.1-1 Versions of packages evince suggests: ii nautilus 3.14.0-1 ii poppler-data 0.4.7-1 ii unrar 1:5.0.10-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#769999: wmbiff: no longer reports old messages with shell command
On 11/17/2014 11:07 PM, Louis-David Mitterrand wrote: In the latest version when a 'shell' command returns a count of (old) messages then 00 is displayed instead. If new N is returned then the new count is still displayed as it should. Thanks for your report! This was changed upstream (see [1]). Perhaps a compromise would be to add a command line and/or wmbiffrc option to choose whether you would prefer the old or new behavior? [1] http://repo.or.cz/w/dockapps.git/commit/2773b5a718666938492ee71ce6d4bccc4b006a2b -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770004: dpkg-maintscript-helper: dir_to_symlink fails when upgrading package that has gone from arch:any to arch:all
Control: reassign -1 cyrus-imapd-2.4 Control: retitle -1 cyrus-imapd-2.4: Insuficient arguments passed to dpkg-maintscript-helper Control: severity -1 serious On Tue, 2014-11-18 at 08:20:36 +0100, Ondřej Surý wrote: Package: dpkg Version: 1.17.21 Severity: grave File: /usr/bin/dpkg-maintscript-helper (BTW, if this had been an issue in dpkg, then it would not have been grave, as it would not break unrelated software, just the one currently being acted on.) dpkg-maintscript-helper fails to find the package files when using dir_to_symlink (and probably vice versa) and upgrading from arch:any to arch:all at the same time. dpkg-maintscript-helper only does what it is told. In this case the packaging has not specified a package name (with the required arch-qualifier) to the dpkg-maintscript-helper call, so it cannot infer that you are doing an arch switch. Please read the man page for the command for more details. The bug manifests in libcyrus-imap-perl24 upgrade from wheezy to jessie (filled as #769553): Preparing to unpack .../libcyrus-imap-perl24_2.4.17+caldav~beta10-7_all.deb ... dpkg-query: no packages found matching libcyrus-imap-perl24:all […] But I can reproduce this with any transitional package from src:cyrus-imapd-2.4 (anything with -2.4 suffix except cyrus-common-2.4), f.e.: Preparing to unpack .../cyrus-clients-2.4_2.4.17+caldav~beta10-7_all.deb ... dpkg-query: no packages found matching cyrus-clients-2.4:all […] ,--- $ grep . debian/*.maintscript debian/cyrus-admin-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-admin-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-admin.maintscript:symlink_to_dir /usr/share/doc/cyrus-admin /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-3~ debian/cyrus-caldav-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-caldav-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-clients-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-clients-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-clients.maintscript:symlink_to_dir /usr/share/doc/cyrus-clients /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-3~ debian/cyrus-common.maintscript:mv_conffile /etc/logcheck/violations.ignore.d/cyrus-common-2_4 /etc/logcheck/violations.ignore.d/cyrus-common 2.4.17+caldav~beta10-3~ debian/cyrus-dev-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-dev-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-doc-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-doc-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-imapd-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-imapd-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-murder-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-murder-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-nntpd-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-nntpd-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-pop3d-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-pop3d-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/cyrus-replication-2.4.maintscript:dir_to_symlink /usr/share/doc/cyrus-replication-2.4 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ debian/libcyrus-imap-perl.maintscript:symlink_to_dir /usr/share/doc/libcyrus-imap-perl /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-3~ debian/libcyrus-imap-perl24.maintscript:dir_to_symlink /usr/share/doc/libcyrus-imap-perl24 /usr/share/doc/cyrus-common-2.4 2.4.17+caldav~beta10-7~ `--- What I've not checked is if debhelper can pass different arguments depending on the maintainer script invoked, which _might_ be required here, but I've not thought about it. Because then you'd probably need to call dpkg-maintscript-helper manually. In any case, definitely a bug in the packaging, and as such reassigning. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769965: minetest: please support init.d scripts and a global configuration file
Woot, many thanks for these changes! I'll try to fill the TODO a bit further to seek your help on the other points ;) I just pushed my local changes to the the git, sorry about that. I have one main question about the server started automatically. Will it be given a specific user id? I would not certify the security of that server, and I'd like to sandbox it as much as possible. I plan since a long time to check how to do that, but you have just solved all my questions but this one. Could you please check your changes to see if they are the most secure ones, ie the ones that do not trust the server program but sandbox it the most, please ? Many many thanks for your work, Mt. On Tue, Nov 18, 2014 at 12:08:41AM +0100, Markus Koschany wrote: Package: src:minetest Version: 0.4.10+repack-2 Severity: wishlist Tags: patch Hi, I saw that this bug was still on your TODO list. It would be great if the minetest server started automatically on boot. I have pushed my patches to the experimental branch. Main changes are: 1. Added a minetest-server.init script 2. Added postinst maintainer script to create a Debian-minetest system user who uses /var/games/minetest-server as HOME directory. 3. Addded a postrm maintainer script to remove all files in /var/games/minetest-server on purge. 4. Installed the server binary to /usr/lib/minetest 5. Created a minetestserver wrapper script. 6. Installed minetest.conf to /etc/minetest/minetest.conf and the server will now read from this global configuration file. This will ensure that things like service minetest-server start/stop work as expected. I am happy to answer any questions that may arise. Please note that I didn't push the changes to master because the latest upload to unstable, -2, was missing. Regards, Markus -- clmnt: je pense que je vais faire le gros goret signature.asc Description: Digital signature
Bug#770023: razorqt-lightdm-greeter: should provide virtual package lightdm-greeter
Source: razorqt Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If I want to to use Razor-qt with lightdm, I am currently forced to install another frontend. Please have razorqt-lightdm-greeter provide the virtual package lightdm-greeter to allow composing a minimal installation with only Qt libraries, not also GTK+ or KDE. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJUayvyXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vW93MIALs/tzfnXCfD+8tqdRJkfO6p UGiuAOMHHckTAvNd3FLCe3r/pkbwt/QuLvPBj0SWu6SbitXJztUicXizj3rMN5Au pNX0m3ZPOugI9eHQk3Nm8PvG+IGZHRo4Knzm+EI4kYRVLGawH3BHFSnX5X4kxdRh QJTdfZQC84uIu21wLA74XYoB7y9gHbBsLsCqT9aUdJJszyf271Ws8QB0YyhHT0pP hLGJYNhFE+xRwGHlp7Hb4IYhBlrvQQHJjRUzdN1wSm5yDNJOdOr07RwoGAg0aRFR 1VgZw/myla7UCICHsOCbRRh9FJi07XsjDvtPWpWf23jGyrRj0OoTFcPSs1bcwSE= =yKwE -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#770022: libc-client2007e: unselectable socket in ssl_getdata() where sock = FD_SETSIZE (similar to #478193)
Package: libc-client2007e
Version: 8:2007f~dfsg-2
Severity: important
Tags: upstream patch
Dear Maintainer,
* After the fix for #478193, we continued to have a problem with having the
error unselectable socket in ssl_getdata for a similar reason.
* We made a similar fix for the ssl_getdata function.
* This resolved the issue for us.
* Note that this can only be triggered with = 1024 open connections.
-- System Information:
Debian Release: 7.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 libc-client2007e depends on:
ii libc6 2.13-38+deb7u4
ii libcomerr21.42.5-1.1
ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u2
ii libk5crypto3 1.10.1+dfsg-5+deb7u2
ii libkrb5-3 1.10.1+dfsg-5+deb7u2
ii libpam-modules1.1.3-7.1
ii libpam0g 1.1.3-7.1
ii libssl1.0.0 1.0.1e-2+deb7u13
ii mlock 8:2007f~dfsg-2
libc-client2007e recommends no packages.
Versions of packages libc-client2007e suggests:
pn uw-mailutils none
-- no debconf information
Our patch:
--- uw-imap.orig/src/osdep/unix/ssl_unix.c 2014-06-04 15:34:16.0
+0100
+++ uw-imap/src/osdep/unix/ssl_unix.c 2014-06-04 15:34:21.0 +0100
@@ -472,16 +472,14 @@
long ssl_getdata (SSLSTREAM *stream)
{
- int i,sock;
- fd_set fds,efds;
- struct timeval tmo;
+ int i,sock,tmo;
+ struct pollfd pfd;
tcptimeout_t tmoh = (tcptimeout_t) mail_parameters (NIL,GET_TIMEOUT,NIL);
long ttmo_read = (long) mail_parameters (NIL,GET_READTIMEOUT,NIL);
time_t t = time (0);
blocknotify_t bn = (blocknotify_t) mail_parameters (NIL,GET_BLOCKNOTIFY,NIL);
if (!stream-con || ((sock = SSL_get_fd (stream-con)) 0)) return NIL;
/* tcp_unix should have prevented this */
- if (sock = FD_SETSIZE) fatal (unselectable socket in ssl_getdata());
(*bn) (BLOCK_TCPREAD,NIL);
while (stream-ictr 1) { /* if nothing in the buffer */
time_t tl = time (0); /* start of request */
@@ -490,15 +488,12 @@
if (SSL_pending (stream-con)) i = 1;
else {
if (tcpdebug) mm_log (Reading SSL data,TCPDEBUG);
- tmo.tv_usec = 0;
- FD_ZERO (fds); /* initialize selection vector */
- FD_ZERO (efds); /* handle errors too */
- FD_SET (sock,fds); /* set bit in selection vector */
- FD_SET (sock,efds); /* set bit in error selection vector */
+ pfd.fd = sock;
+ pfd.events = POLLIN;
errno = NIL; /* block and read */
do { /* block under timeout */
- tmo.tv_sec = ti ? ti - now : 0;
- i = select (sock+1,fds,0,efds,ti ? tmo : 0);
+ tmo = ti ? ti - now : 0;
+ i = poll (pfd, 1, ti ? tmo * 1000 : -1);
now = time (0); /* fake timeout if interrupt time expired */
if ((i 0) (errno == EINTR) ti (ti = now)) i = 0;
} while ((i 0) (errno == EINTR));
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760431: byobu prevents inverted text from displaying and shows as italics instead
Hello, I recently upgraded to Ubuntu 14.10 and ran into this issue; it does appear tmux is at fault (or rather, screen's terminfo description). The tmux FAQ (http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ) has an entry vim displays reverse video instead of italics, while less displays italics (or just regular text) instead of reverse. What's wrong? which describes a fix involving creating a new terminfo file. The only wrinkle for byobu is the default-terminal command should go in ~/.byobu/.tmux.conf instead of ~/.tmux.conf. I suppose this may be too much for byobu to fix automagically, but it does seem to be a head-scratcher for users who don't investigate deep enough to find a fix in tmux. HTH, Jeff
Bug#769729: cron-apt with systemd-cron
Hi, I noticed this bug report.I gave a try to cron-apt with systemd-cron and it works perfectly. But, systemd notices process new files so fast that it refreshed *twice* during unpacking, leaving an harmless cron-cron-apt.dpkg-new-root-0.timer behind. (a timer without its matching .service doesn't do anything) The file doesn't exist in /run/systemd/generator anymore, but will remain in systemctl output so long it has not been garbage-collected. This is fixed now upstream. https://github.com/systemd-cron/systemd-cron/commit/9b47c38a5308c3d34c2868ebd73af734d57901ac The Debian policy states that all crontab containing a dot (.) should be ignored; but this project has also Arch Gentoo users; so I'd not push this upstream. This causes a lot of confusion anyway: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/706565 http://www.semicomplete.com/blog/geekery/ubuntu-cron-silently-ignores-files.html
Bug#770024: razorqt-openssh-askpass: should provide virtual package ssh-askpass
Source: razorqt Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If I understand correctly that razorqt-openssh-askpass provides the ssh-askpass interface, it should provide the corresponding virtual package. If I am mistaken, I suggest to consider clarifying the long description to avoid misunderstanding. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJUay+9XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWos8H/RYp72/OGNaikbrQBtp4bCF+ CqchefGY49lKFnGxrmM8Dt4pMzG4vjPIQPbb+br1L10PXTxmU6RY4AXpu4wifYTp c4tHIwoWDSD6Zl2OVwXBTXWrVjyUNQg72HamI0tf48nBRqU2XhaLXaVOeb+5mSXu ESsfFGUZy28f0CmNzd1ggJplrlkL4RfPp+Fs5A5lup0Kw0fv4dsJPgQ09H/uh0i0 5NN9zYNuwbCaRVVGP4lG0fX+qeusLumNcdwCRPOCqs1iZo3bwgqC3fIC4akcdM// Qn8Awh2DyHiyblZS5A4Xe+7SmFi1Y15HhMjNRzUjcPBJT6IFOG0rxR7XJXkiRJE= =69ZK -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#767355: Patch for System.EntryPointNotFoundException: CreateCaret
Control: tags -1 pending On Mon, Nov 17, 2014 at 3:14 PM, Mathieu Malaterre ma...@debian.org wrote: Control: tags -1 patch On Mon, Nov 17, 2014 at 3:08 PM, Jaroslav Imrich ja...@jariq.sk wrote: Hello Mathew, I have developed a patch [1] for HexBox control 1.6.0 that disables usage of carets when required unmanaged functions are not available in the runtime platform.With this patch caret is not displayed on Linux with Mono runtime but other than that HexBox control is still perfectly usable. Feel free to incorporate these changes into your package or contact me if you need any help with that. [1] https://github.com/jariq/Be.HexEditor/commit/c05c5df1358bf5427dd2fcec0e392a132cd69422 Wow ! Thanks much, will try asap. Jaroslav, Do you know why I get the following (simply start close hexbox, you do not need to even open a file): $ hexbox Unhandled Exception: System.ArgumentException: A null reference or invalid value was found [GDI+ status: InvalidParameter] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x0] in filename unknown:0 at System.Drawing.Graphics.GdipMeasureString (IntPtr graphics, System.String text, System.Drawing.Font font, System.Drawing.RectangleF layoutRect, IntPtr stringFormat) [0x0] in filename unknown:0 at System.Drawing.Graphics.MeasureString (System.String text, System.Drawing.Font font, Int32 width, System.Drawing.StringFormat format) [0x0] in filename unknown:0 at (wrapper remoting-invoke-with-check) System.Drawing.Graphics:MeasureString (string,System.Drawing.Font,int,System.Drawing.StringFormat) at System.Windows.Forms.TextRenderer.MeasureTextInternal (IDeviceContext dc, System.String text, System.Drawing.Font font, Size proposedSize, TextFormatFlags flags, Boolean useMeasureString) [0x0] in filename unknown:0 at System.Windows.Forms.TextRenderer.MeasureText (System.String text, System.Drawing.Font font, Size proposedSize, TextFormatFlags flags) [0x0] in filename unknown:0 at System.Windows.Forms.ToolStripItem.OnParentChanged (System.Windows.Forms.ToolStrip oldParent, System.Windows.Forms.ToolStrip newParent) [0x0] in filename unknown:0 at System.Windows.Forms.ToolStripItem.set_Parent (System.Windows.Forms.ToolStrip value) [0x0] in filename unknown:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem:set_Parent (System.Windows.Forms.ToolStrip) at System.Windows.Forms.ToolStripItemCollection.Remove (System.Windows.Forms.ToolStripItem value) [0x0] in filename unknown:0 at System.Windows.Forms.ToolStripItem.Dispose (Boolean disposing) [0x0] in filename unknown:0 at System.Windows.Forms.ToolStripDropDownItem.Dispose (Boolean disposing) [0x0] in filename unknown:0 at System.Windows.Forms.ToolStripMenuItem.Dispose (Boolean disposing) [0x0] in filename unknown:0 at System.ComponentModel.Component.Finalize () [0x0] in filename unknown:0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759260: [summary] Bug#759260: removal of the Extra priority.
On Tue, 18 Nov 2014, Charles Plessy wrote: Le Mon, Nov 17, 2014 at 03:55:26PM +0100, Santiago Vila a écrit : Hi Santiago, practically speaking, how do you or others use the Optional priority to check that a package is not directly or transitively conflicting with another package ? First, according to debcheck (https://qa.debian.org/debcheck.php?dist=sidlist=main-only-priorityarch=ANY) there are thousands of packages whose Priority setting violates the current policy. Second, tools such as apt-get --simulate are very efficient at checking if the installation of one package will need or trigger the removal of another one. In which case would it be more efficient to check the priority instead, especially given the first point above ? We can't obviously rely on the current rule if it's violated, but violations of the rule are just a sign that we didn't try hard enough to comply with it, not a sign that the rule is useless and we should drop it. Can you give concrete examples where the Extra priority has been instrumental for you as a user or a developer, in a way that has no practical alternative ? Or said differently, what would break concretely for you if tomorrow the Optional and Extra priorities were merged ? As it has been pointed out by others, whenever we have a set of mutually conflicting packages performing the same task, the package having optional priority is the one that we recommend among them. It is a way to tell the user in doubt, use this one. For example, there was a time in which there were several NFS servers available. The only one who survived, nfs-kernel-server, is the only one that was optional, so I installed that one when I needed a NFS server a long time ago. If we had not the extra priority, I would have to look at popularity-contest or similar data. I think that it is a good thing that we have a way to recommend packages which is independent from what everyone else is using. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769941: libgstreamer-plugins-base1.0-0: Iceweasel crashes with gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
On Di, 2014-11-18 at 11:37 +, George B. wrote: On 18/11/14 09:22, Sebastian Dröge wrote: I assume it first started to appear when upgrading from 1.4.3 to 1.4.4 yesterday? I noticed it with GMail yesterday, but I haven't used that for a long time (I usually connect via Icedove). I did note a crash at some point last week on some other random website - that time I just ignored it, but it is possible it was related. Can you always reproduce it when logging in on GMail? Which version of iceweasel are you using? It does not crash for me unfortunately. I can always reproduce it, providing I have media.gstreamer.enabled = true in about:config. If set to false false - no crash. Iceweasel version is 33.1 (from experimental) If you can always reproduce it, could you run iceweasel in valgrind (don't forget to install valgrind-dbg)? Set G_SLICE=always-malloc in the environment and run valgrind with --track-origins=yes and --trace-children=yes Unfortunately valgrind never gets to fully load the login page (exits with Killed). I used: valgrind --track-origins=yes --trace-children=yes --error-limit=no iceweasel -safe-mode I attach the STDERR log, but I'm not sure how useful that will be since there is no mention of gstreamer there. Not very useful :) But thanks! Can you check if the crash goes away if you downgrade some of the GStreamer packages to 1.4.3, and if so which one makes the difference? signature.asc Description: This is a digitally signed message part
Bug#768850: ruby-activemodel, ruby-activesupport: needs Breaks for the packages it Replaces
On 2014-11-14 20:51, Antonio Terceiro wrote:
The following packages will be REMOVED:
gcc-4.7-base
The following packages have been kept back:
rails
The problematic package is ruby-activesupport-2.3 which gets a higher
score (score=21) than ruby-activesupport (score=11) (probably due to a high
number of
rdepends in wheezy, the scoring seems to be fixed in jessie though):
Investigating (0) ruby-activesupport [ amd64 ] none - 2:4.1.7-1 ( ruby )
Broken ruby-activesupport:amd64 Breaks on ruby-activesupport-2.3 [ amd64 ]
2.3.14-7 ( ruby )
Considering ruby-activesupport-2.3:amd64 21 as a solution to
ruby-activesupport:amd64 11
Holding Back ruby-activesupport:amd64 rather than change
ruby-activesupport-2.3:amd64
and this starts a cascade of keeping the *-2.3 packages installed,
resulting in the old rails being kept.
So add a transitional dummy package that ensures the stack of *-2.3
packages gets removed:
Package: ruby-activesupport-2.3
Architecture: all
Depends: ruby-activesupport (= 2:4),
${misc:Depends},
${shlibs:Depends}
Breaks:
ruby-activesupport-3.2,
ruby-activesupport-4.0,
ruby-actionpack-2.3,
ruby-activerecord-2.3,
ruby-activeresource-2.3,
ruby-rails-2.3,
Description: transitional dummy package
Ensure the removal of rails 2.3 on upgrades from wheezy.
This package can be safely removed.
and in ruby-activesupport use
Replaces: ruby-activesupport-2.3 ( 2:4), ruby-activesupport-3.2,
ruby-activesupport-4.0
Breaks: ruby-activesupport-2.3 ( 2:4), ruby-activesupport-3.2,
ruby-activesupport-4.0
It's important to have the Breaks directly in ruby-activesupport-2.3,
having them only transitively via ruby-activesupport does not work -
that seems to be the apt bug fixed in jessie.
The upgrade then looks like this:
Investigating (0) ruby-activesupport-2.3 [ amd64 ] 2.3.14-7 - 2:4.1.7-1
( ruby )
Broken ruby-activesupport-2.3:amd64 Breaks on ruby-actionpack-2.3 [ amd64 ]
2.3.14-5 ( ruby )
Considering ruby-actionpack-2.3:amd64 5 as a solution to
ruby-activesupport-2.3:amd64 22
Added ruby-actionpack-2.3:amd64 to the remove list
Broken ruby-activesupport-2.3:amd64 Breaks on ruby-activerecord-2.3 [ amd64 ]
2.3.14-6 ( ruby )
Considering ruby-activerecord-2.3:amd64 9 as a solution to
ruby-activesupport-2.3:amd64 22
Added ruby-activerecord-2.3:amd64 to the remove list
Broken ruby-activesupport-2.3:amd64 Breaks on ruby-activeresource-2.3 [ amd64
] 2.3.14-3 ( ruby )
Considering ruby-activeresource-2.3:amd64 1 as a solution to
ruby-activesupport-2.3:amd64 22
Added ruby-activeresource-2.3:amd64 to the remove list
Broken ruby-activesupport-2.3:amd64 Breaks on ruby-rails-2.3 [ amd64 ]
2.3.14-4 ( ruby )
Considering ruby-rails-2.3:amd64 -1 as a solution to
ruby-activesupport-2.3:amd64 22
Added ruby-rails-2.3:amd64 to the remove list
Fixing ruby-activesupport-2.3:amd64 via remove of ruby-actionpack-2.3:amd64
Fixing ruby-activesupport-2.3:amd64 via remove of
ruby-activerecord-2.3:amd64
Fixing ruby-activesupport-2.3:amd64 via remove of
ruby-activeresource-2.3:amd64
Fixing ruby-activesupport-2.3:amd64 via remove of ruby-rails-2.3:amd64
Investigating (0) ruby-actionmailer-2.3 [ amd64 ] 2.3.14-3 ( ruby )
Broken ruby-actionmailer-2.3:amd64 Depends on ruby-actionpack-2.3 [ amd64 ]
2.3.14-5 ( ruby ) (= 2.3.14)
Considering ruby-actionpack-2.3:amd64 5 as a solution to
ruby-actionmailer-2.3:amd64 1
Removing ruby-actionmailer-2.3:amd64 rather than change
ruby-actionpack-2.3:amd64
Done
The transitional package now causes a cascade of removals, not keeps :-)
(the score increased by one because the package now exists in the target
release)
The following packages will be REMOVED:
ruby-actionmailer-2.3 ruby-actionpack-2.3 ruby-activerecord-2.3
ruby-activeresource-2.3 ruby-rails-2.3
...
It's sufficient to have only one transitional package - the one that gets the
highest score from apt.
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757891: init-system-helpers: Please do not depend on perl
Michael Stapelberg, le Mon 17 Nov 2014 14:00:58 -0800, a écrit : I’ve pushed a couple of commits, see http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/ — can you please confirm that I didn’t miss anything and uploading that version fixes the problem? It seems to be alright, yes: Depends: perl-base (= 5.20.1-3) Thanks to everybody involved! Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769835: googleearth-package: depenencies not installed before dpkg -i, causing unmet dependencies and other problems
Hey Matt, Thank you for the report. However I was aware of this, and this isn't a googleearth-package bug as it's the dpkg that doesn't resolve dependencies before installing a package. If you i.e use gdebi which besides installing packages also resolves and installs its dependencies. Then the problem you encountered won't occur. Thanks and please inform me if you have any additional questions and/or comments. Regards, Adnan On Sun, Nov 16, 2014 at 11:14 PM, Matt Kukowski dymorp...@gmail.com wrote: Package: googleearth-package Version: 0.7.0 Severity: important Dear Maintainer, After running make-googleearth it builds the package just fine. But, when it gets to Installing the pkg (dpkg -i ...) it reports unmet dependancies. bug spew... - dpkg: dependency problems prevent configuration of googleearth: googleearth depends on libfreeimage3; however: Package libfreeimage3 is not installed. googleearth depends on lsb-core; however: Package lsb-core is not installed. dpkg: error processing googleearth (--install): dependency problems - leaving unconfigured Processing triggers for desktop-file-utils ... Processing triggers for gnome-menus ... Processing triggers for shared-mime-info ... Processing triggers for menu ... Processing triggers for mime-support ... Errors were encountered while processing: googleearth You then have to run 'apt-get install -f' to correct the dependancy problem as it breaks apt-get. -- System Information: Debian Release: 7.7 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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages googleearth-package depends on: ii bzip2 1.0.6-4 ii dpkg-dev1.16.15 ii fakeroot1.18.4-2 ii file5.11-2+deb7u6 ii wget1.13.4-3+deb7u2 ii x11-common 1:7.7+3~deb7u1 ii x11-utils 7.7~1 googleearth-package recommends no packages. googleearth-package suggests no packages. -- no debconf information
Bug#769769: python3.4: unowned files after purge: __pycache__/*.cpython-34.pyc
On 11/16/2014 12:04 PM, Andreas Beckmann wrote: From the attached log (scroll to the bottom...): 0m39.8s ERROR: FAIL: Package purging left files on system: /usr/lib/python3.4/__pycache__/__phello__.cpython-34.pyc not owned this seems to be a special case, as the source file name doesn't match the bytecode name. In many other python packages other __pycache__/*.cpython-34.pyc are not cleaned up. please be specific, and file separate issues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769687: no network is a common condition
Hi Martin, On Dienstag, 18. November 2014, Martin Pitt wrote: Why is that outside parameters? It's calling apt-get download for a few packages just as the build dep installation stage does? no, it's not like that. you are using a specific mirror via http, while the host could use a file:// mirror via nfs or rsync or just /var/cache/apt/archives. - your build results are unreliable and unpredictable. (you = your packages build process, the host = the stuff which prepares the build environment) we've discussed this briefly on #debian-devel today and now there is #770016 Clarify network access for building packages in main against debian-policy to document this properly. cherrs, Holger signature.asc Description: This is a digitally signed message part.
Bug#770004: dpkg-maintscript-helper: dir_to_symlink fails when upgrading package that has gone from arch:any to arch:all
Hi Guillem, thanks for getting back so quickly. On Tue, Nov 18, 2014, at 12:24, Guillem Jover wrote: Control: reassign -1 cyrus-imapd-2.4 Control: retitle -1 cyrus-imapd-2.4: Insuficient arguments passed to dpkg-maintscript-helper Control: severity -1 serious On Tue, 2014-11-18 at 08:20:36 +0100, Ondřej Surý wrote: Package: dpkg Version: 1.17.21 Severity: grave File: /usr/bin/dpkg-maintscript-helper (BTW, if this had been an issue in dpkg, then it would not have been grave, as it would not break unrelated software, just the one currently being acted on.) JFTR I have discussed this with Helmut Grohne on #-devel before filling the bug. dpkg-maintscript-helper fails to find the package files when using dir_to_symlink (and probably vice versa) and upgrading from arch:any to arch:all at the same time. dpkg-maintscript-helper only does what it is told. In this case the packaging has not specified a package name (with the required arch-qualifier) to the dpkg-maintscript-helper call, so it cannot infer that you are doing an arch switch. Please read the man page for the command for more details. The manpage doesn't say anything about upgrades from arch:any to arch:all, just about Multi-Arch? What I've not checked is if debhelper can pass different arguments depending on the maintainer script invoked, which _might_ be required here, but I've not thought about it. Because then you'd probably need to call dpkg-maintscript-helper manually. The problem here is more complex - which arch should I pick in the call? E.g. should I pass f.e. libcyrus-imap-perl24:$(dpkg --print-architecture) to the dpkg-maintscript-helper call? Would that work for M-A packages? In any case, definitely a bug in the packaging, and as such reassigning. I can definitely fix that in the packaging, but it's going to be a horrible hack :(. (Personally I think we should have just fixed dh_installdoc --link-doc...) Cheers, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770025: gcc-4.9-base: please add Breaks: gcc-4.7-base ( 4.7.3) as in gcc-4.8-base
Package: gcc-4.9-base Version: 4.9.1-19 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, please sync the Breaks between gcc-4.8-base and gcc-4.9-base s.t. both include Breaks: gcc-4.7-base ( 4.7.3). This will ensure more consistent upgrade behavior from wheezy to jessie. I currently face upgrade problrms in piuparts where a minimal chroot keeps gcc-4.7-base installed after a distupgrade (this is taken as a reference), but a chroot with some packages to be tested will remove gcc-4.7-base because gcc-4.8-base gets installed. After removing the packages to be tested the resulting system does not match the reference any more ... Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770016: further reasoning
Hi, this has also already been documented as best practice (to say at least) in https://wiki.debian.org/buildd which says: most buildds will have no network access available. Your package build+test process must not attempt to use the network or assume that any network interface is available. Also relying on outside factors is bad, as they may change and thus make the build results unreliable and unpredictable. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#769449: (no subject)
On 11/14/2014 04:13 PM, Barry Warsaw wrote: It is not enough to remove /usr/lib/python-wheels in python3.4 and use a tmpdir because pip (inside the venv) also needs to have the *.whl files on its sys.path, otherwise its imports fail. pip would have to put all /usr/share/python-wheels/*.whl on its sys.path (which I don't like). Or we would have to also copy all of /usr/share/python-wheels/*.whl to the tempdir. Even then though, I'm not sure that's enough to make pip-inside-venv work again when run outside of ensurepip. Given where we are in the Jessie cycle, and the fact that this bug is not triggered by a user visible failure, and things work right now, I am disinclined to change this. Perhaps we can look again for Jessie+1. If it ain't broke... I'm changing this now to use /var/lib/python-wheels, which is policy conform. Please fix python-pip accordingly. From my point of view, this should go into jessie. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769769: python3.4: unowned files after purge: __pycache__/*.cpython-34.pyc
On 2014-11-18 13:07, Matthias Klose wrote: In many other python packages other __pycache__/*.cpython-34.pyc are not cleaned up. please be specific, and file separate issues. OK, will do so. I expected this could be a more general issue (dh_python?) ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770000: unblock: systemd/215-6
Hey Niels, Niels Thykier [2014-11-18 7:16 +0100]: The changes look reasonable. But before you upload it, would it be possible to include patch for #754987 (comment #119 or #129) as well? :) Oh dear, what a nasty issue! I was able to reproduce it in a VM, and test/confirm the fix: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b6bf6be Either way, please upload to unstable and let us know once it has been accepted. :) I took the liberty to update the standards-version, to fix the lintian warning: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=20e1ccdd Aside from these two commits, the -6 upload is as advertised in the original diff. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#770016: Clarify network access for building packages in main
Le Tue, Nov 18, 2014 at 03:03:07PM +0600, Andrey Rahmatullin a écrit : 2.2.1 says the packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non- main package), In practice there is a consensus that this also means packages must not access external network servers which conforms to the spirit but not to the letter of this section. Note that there may be other requirements which are not codified, as mentioning only things that are packaged is not enough, it should say something like must not use any stuff except for packages in main. Hi Andrew, I guess that it is implicit from the defintion of contrib that follows in 2.2.2: The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. This said, one could argue that the definition of main should not depend on the definition of contrib or non-free... Would you, Holger or somebody else propose a patch ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757891: init-system-helpers: Please do not depend on perl
Samuel Thibault, le Tue 18 Nov 2014 13:00:29 +0100, a écrit : Michael Stapelberg, le Mon 17 Nov 2014 14:00:58 -0800, a écrit : I’ve pushed a couple of commits, see http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/ — can you please confirm that I didn’t miss anything and uploading that version fixes the problem? It seems to be alright, yes: Depends: perl-base (= 5.20.1-3) Ah but that was written by hand :) Anyway, I have tried installing a base system and removing perl with the commited fixes, and it does boot fine. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768774: systemd randomly starts one of the installed display managers
Control: forcemerge 748668 768774 Control: retitle 748668 slim: Under systemd, randomly hijacks default-x-display-manager ignoring default selection Control: affects 748668 gdm3 On Sun, Nov 09, 2014 at 06:40:40PM +0100, dAgeCKo wrote: Le 09/11/2014 17:47, Michael Biebl a écrit : Control: reassign -1 slim Am 09.11.2014 um 09:37 schrieb dAgeCKo: Package: systemd Version: 208-8 Severity: normal Debian: Testing amd64 Regression: No If several display managers are installed (for example gdm3 and slim), at each boot, systemd seems to randomly choose one and launch it. So we might have gdm3 at one boot and slim at another boot. That's not a bug in systemd, but slim In Debian there is traditionally a /etc/X11/default-display-manager config file, which describes the default display manager. The sysv init script for the display manager reads that file, checks if it's supposed to start and exit's otherwise. This means, you can have multiple display managers installed and all of their sysv init scripts enabled. slim does ship a native .service file, which doesn't include that check. It should add a check like gdm.service (or lightdm.service) ExecStartPre=/bin/sh -c '[ $(cat /etc/X11/default-display-manager 2/dev/null) = /usr/sbin/gdm3 ]' slim should also setup the /etc/systemd/system/display-manager.service in its maintainer scripts. I'm re-assigning this bug to slim. Ideally it uses the same scheme as was implemented for gdm3 and lightdm. Joss and Martin have designed and implemented that scheme, so I've CCed them in case the slim maintainer has more questions. Thanks. Since slim and gdm3 behaved well when systemd was not used, I quickly thought that systemd was the guilty... This has already been reported as #748668, thus forcemerging lightdm implementation is suggested there as the way to go for #748668, as well as the info under titanpad. That info should be enough for a fix, so I tagged that bug report as +patch even if no explicit patch was added. Since you experienced this problem also with gdm3 I am marking this bug report as affecting it. Should this be RC? 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#497225: Bug#691265: gnome-alsamixer upstream Git
Thanks Bob, this is nice because it will be packaged by the Debian Gnome Team[1] asap. Best wishes, Pierangelo [1] http://pkg-gnome.alioth.debian.org/index.html 2014-11-15 23:06 GMT+01:00 Bob Bib bob...@ukr.net: Just for the record: gnome-alsamixer is currently keeped in GNOME Git repository: https://git.gnome.org/browse/gnome-alsamixer/ --- Best wishes, Bob
Bug#737750: debian-installer: Netboot initrd does not download, ata-modules or sata-modules udebs
On Wed, 26 Feb 2014 01:09:38 + Ben Hutchings b...@decadent.org.uk wrote: I just tested it in KVM/QEMU. It does download ata-modules. Are you using the current (7.4) netboot images? If I remember rightly, old netboot images may stop working after a point release if you don't keep the corresponding udebs on a local mirror. I'm able to reproduce this problem on a variety of servers configured to use AHCI SATA controllers with the Debian 7.7 network install. I've not dug into the exact cause of the problem but I can see that there is no AHCI module loaded by the network installer, modprobe ahci returns that such a module is not known, and dmesg gives no hint of the disks being discovered or probed. As a result no hard disks are detected and the install can't proceed. lspci does show the SATA controller as present. If I instead use a DVD image to boot the installer then everything is fine. I'm not sure what I can usefully do or provide to help debug this but happy to assist if I can. Kieran The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762690: libhibernate-validator-java: affected by CVE-2014-3558
Le 18/11/2014 11:51, Raphael Hertzog a écrit : Thank you for this information but it's not really a satisfactory answer. I understand your concerns and I'm not claiming that shipping vulnerable libraries is a good thing. My answer was a factual evaluation of the impact of this vulnerability on Debian, so people are at least informed about the actual risks. Please send a call for help on debian-devel(-announce) if you are not able to do the basic work of keeping your packages up-to-date. Then the publicity team might relay your message further... and maybe you'll find some supplementary volunteers. Updating packages is not always basic unfortunately, I wish it was though. signature.asc Description: OpenPGP digital signature
Bug#770016: Clarify network access for building packages in main
On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote: I guess that it is implicit from the defintion of contrib that follows in 2.2.2: The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. I have a feeling that software here is too narrow. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770026: unblock: metamonger/0.20141118-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package metamonger
This Closes: #769271 by using an epoch 32 bit systems can stomach in all
tests.
% debdiff metamonger_0.20141008-1_all.deb
metamonger_0.20141118-1_all.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Version: [-0.20141008-1-] {+0.20141118-1+}
%
unblock metamonger/0.20141118-1
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757891: init-system-helpers: Please do not depend on perl
On Mon, Nov 17, 2014 at 02:00:58PM -0800, Michael Stapelberg wrote:
I’ve pushed a couple of commits, see
http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/ —
can you please confirm that I didn’t miss anything and uploading that
version fixes the problem?
Looks fine, thanks. I can test it a bit tonight.
For future robustness, you might want to use 'dh_perl -d' instead of
removing ${perl:Depends}. Something like
override_dh_perl:
dh_perl -d
and
Depends: perl-base (= 5.20.1-3), ${perl:Depends}, ${misc:Depends}
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769941: libgstreamer-plugins-base1.0-0: Iceweasel crashes with gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
On 18/11/14 11:42, Sebastian Dröge wrote: Can you check if the crash goes away if you downgrade some of the GStreamer packages to 1.4.3, and if so which one makes the difference? I have downgraded to 1.4.3 and it still crashes :-( $ dpkg-query -l | grep gstream | fgrep -v 0.10 ii gstreamer1.0-libav:amd64 1.4.3-1 amd64libav plugin for GStreamer ii gstreamer1.0-plugins-base:amd64 1.4.3-1.1 amd64 GStreamer plugins from the base set ii gstreamer1.0-plugins-good:amd64 1.4.3-2amd64 GStreamer plugins from the good set iU gstreamer1.0-plugins-good-dbg:amd64 1.4.3-2amd64 GStreamer plugins from the good set ii gstreamer1.0-pulseaudio:amd64 1.4.3-2 amd64GStreamer plugin for PulseAudio ii gstreamer1.0-x:amd64 1.4.3-1.1 amd64GStreamer plugins for X11 and Pango ii libgstreamer-plugins-base1.0-0:amd64 1.4.3-1.1 amd64 GStreamer libraries from the base set ii libgstreamer1.0-0:amd64 1.4.3-1.2 amd64Core GStreamer libraries and elements ii libreoffice-avmedia-backend-gstreamer 1:4.3.3-1 amd64GStreamer backend for LibreOffice -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770027: Please add udd.debian.org to other list
Package: reportbug Version: 6.5.0 Severity: wishlist Hi, I want to report a bug concerning udd.debian.org but the service is not listed under other. Please add it there. This might need a pseudo package created on bugs.d.o or something. Please forward the bug as needed. MfG Goswin -- Package-specific info: ** Environment settings: EDITOR=xemacs EMAIL=goswin-...@web.de INTERFACE=text ** /home/mrvn/.reportbugrc: reportbug_version 1.99.31 mode expert ui text realname Goswin von Brederlow email goswin-...@web.de no-cc header X-Debbugs-CC: goswin-...@web.de -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages reportbug depends on: ii apt 1.0.9.1 ii python2.7.5-5 ii python-reportbug 6.5.0 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail none pn debconf-utils none pn debsumsnone pn dlocatenone ii emacs23-bin-common 23.4+1-4.1+b1 ii exim4 4.82-8 ii exim4-daemon-heavy [mail-transport-agent] 4.82-8 ii file 1:5.18-1 ii gnupg 1.4.16-1.1 ii python-gtk22.24.0-3+b1 pn python-gtkspellnone pn python-urwid none pn python-vte none ii xdg-utils 1.1.0~rc1+git20111210-7 Versions of packages python-reportbug depends on: ii apt 1.0.9.1 ii python2.7.5-5 ii python-debian 0.1.21+nmu2 ii python-debianbts 1.11 ii python-support1.0.15 python-reportbug 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#769972: New CTTE members
Don Armstrong writes (Bug#769972: New CTTE members): Feel free to make any changes. I'll send out the announcement in 24 hours unless someone objects. This is (all) a good idea. Please do go ahead. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770028: Please skip to the found bugs when clicking search
Package: udd.debian.org Severity: wishlist When I search for bugs on http://udd.debian.org/bugs/ I have to scroll quite far down to the search button. When I click it the page reloads and is at the begining again. So I have to scroll a long way down again to see my search results. It would be better if the page would load and skip diorectly to the results (using the #results tag). MfG Goswin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) 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#757891: init-system-helpers: Please do not depend on perl
Niko Tyni, le Tue 18 Nov 2014 14:39:06 +0200, a écrit :
On Mon, Nov 17, 2014 at 02:00:58PM -0800, Michael Stapelberg wrote:
I’ve pushed a couple of commits, see
http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/ —
can you please confirm that I didn’t miss anything and uploading that
version fixes the problem?
Looks fine, thanks. I can test it a bit tonight.
For future robustness, you might want to use 'dh_perl -d' instead of
removing ${perl:Depends}. Something like
override_dh_perl:
dh_perl -d
and
Depends: perl-base (= 5.20.1-3), ${perl:Depends}, ${misc:Depends}
Indeed, that properly does not add the perl dependency.
Samuel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769941: libgstreamer-plugins-base1.0-0: Iceweasel crashes with gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
I have also tried downgrading iceweasel to 31.2 in Sid but it still crashes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767676: ola-rdm-tests: fails to install: subprocess installed post-installation script returned error exit status 10
Hello Helmut, Please find attached anew version for the patch. Here is what I fixed: * Remove debconf calls from ola-rdm-tests postinst. (Closes: #767676) * Fix other seriouys issues: - Provides missing /etc/default/ola from ola postinst script to allow olad service control in the same way rdm_test_server is - Update init scripts to change advice to enable olad drm_test_server services (dpkg-reconfigure won't work without debconf) - add postrm scripts for packages ola ola-rdm-tests to fully remove configuration files dirs so that piuparts tests can pass As you asked: - I didn't changed configuration file names. I thought this was a bit out of scope, you confirmed :) - packages pass piuparts tests (I tested .changes file with --no-upgrade-test since jessie package fails to install) I also documented verbosely changes in changelog as requested by [1] Please let me know wheter the work is satisfying or I need to iterate more. Regards, Jean Baptiste [1] https://release.debian.org/jessie/freeze_policy.html On 18/11/2014 08:15, Helmut Grohne wrote: On Mon, Nov 17, 2014 at 11:42:54PM +0100, Jean Baptiste Favre wrote: Thanks for your advice. I'm working on a new version of the patch. In the meantime, what should I do with my already uploaded NMU (on mentors.debian.net). Maybe I should delete it just to be sure nobody will upload it ? You can do that. I also noticed that init scripts ask for dpkg-reconfigure package to enable service start, which is disabled by default. I guess this was OK when debconf handles /etc/default/package content, but obviously it won't work anymore. I can change the init script to display another message. This sounds like a documentation fix. Currently, this should be covered by the freeze policy. So fixing it should be ok for now. Finally, I'm considering shipping /etc/default/ola which is not shipped currently, in the same way as /etc/default/ola-rdm-tests. It controls whether olad service is enabled or not. This sounds like a functional change. While it looks like an improvement, I do not yet see why this should be release critical. So better skip this for the upload targeting jessie, but you can prepare a separate .debdiff for Wouter to apply later if you like. (Better create a new bug report at lower severity then.) And, last question, speaking about /etc/default files, I wonder which are the best practices: - name /etc/default/xxx file according to the init script which will use them - name /etc/default/xxx file according to the package which provide them In my case, /etc/default/ola is provided by ola package but controls olad service. Same with /etc/default/ola-rdm-tests which is provided by eponym package to control rdm_test_server service. All these would indeed increase the overall package quality, but I wonder if this is not a bit out of scope work considering Jessie freeze. You are rightly wondering. These changes are likely not acceptable for jessie. It looks to me that you are looking a bit too far at the moment. This bug was found using piuparts. After applying your initial .debdiff, piuparts still rightfully complains (about other things). This is why I asked you to reiterate. Nothing more. Helmut diff -Nru ola-0.9.1/debian/changelog ola-0.9.1/debian/changelog --- ola-0.9.1/debian/changelog 2014-08-17 10:07:29.0 +0200 +++ ola-0.9.1/debian/changelog 2014-11-18 09:47:02.0 +0100 @@ -1,3 +1,17 @@ +ola (0.9.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Remove debconf calls from ola-rdm-tests postinst. (Closes: #767676) + * Fix other seriouys issues: +- Provides missing /etc/default/ola from ola postinst script to allow + olad service control in the same way rdm_test_server is +- Update init scripts to change advice to enable olad drm_test_server + services (dpkg-reconfigure won't work without debconf) +- add postrm scripts for packages ola ola-rdm-tests to fully remove + configuration files dirs so that piuparts tests can pass + + -- Jean Baptiste Favre deb...@jbfavre.org Sun, 16 Nov 2014 17:44:18 +0100 + ola (0.9.1-1) unstable; urgency=low * New upstream release diff -Nru ola-0.9.1/debian/ola.olad.init ola-0.9.1/debian/ola.olad.init --- ola-0.9.1/debian/ola.olad.init 2014-08-17 09:17:40.0 +0200 +++ ola-0.9.1/debian/ola.olad.init 2014-11-18 09:46:06.0 +0100 @@ -23,7 +23,7 @@ if [ $RUN_DAEMON = true ] || [ $RUN_DAEMON = yes ] ; then DAEMON_ARGS=--syslog --log-level 3 --config-dir /etc/ola elif [ $1 = start ] || [ $1 = stop ] ; then - echo The init script is currently inactive;\nuse \dpkg-reconfigure ola\ to change this. 2 + echo The init script is currently inactive;\nPlease update \/etc/default/ola\ to change this. 2 fi [ -x $DAEMON ] || exit 0 diff -Nru ola-0.9.1/debian/ola.postinst ola-0.9.1/debian/ola.postinst --- ola-0.9.1/debian/ola.postinst 2014-08-17 09:17:40.0 +0200 +++
Bug#770016: Clarify network access for building packages in main
On Tue, 18 Nov 2014, Andrey Rahmatullin wrote: On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote: I guess that it is implicit from the defintion of contrib that follows in 2.2.2: The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. I have a feeling that software here is too narrow. Well, contrib is also used when there is a requirement of *data* (be it game assets or scientific datasets) external to Debian main, not just software. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769742: [Pkg-ofed-devel] Bug#769742: libopensm5: move libosmcomp3, libosmvendor4 to separate packages
On Sun, Nov 16, 2014 at 02:58:21AM +0100, Andreas Beckmann wrote: Package: libopensm5 Version: 3.3.18-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts libopensm5 ships three libraries with independent soversions: /usr/lib/x86_64-linux-gnu/libopensm.so.5.2.1 /usr/lib/x86_64-linux-gnu/libosmcomp.so.3.0.8 /usr/lib/x86_64-linux-gnu/libosmvendor.so.4.0.0 /usr/lib/x86_64-linux-gnu/libopensm.so.5 /usr/lib/x86_64-linux-gnu/libosmcomp.so.3 /usr/lib/x86_64-linux-gnu/libosmvendor.so.4 This does not work, because soversion changes in the two other libraries cannot be represented in the package versioning. Right now we have in sid the package ibutils (and maybe more) with an unusable binary: # ldd /usr/bin/ibis linux-vdso.so.1 (0x7f30818f6000) libopensm.so.5 = /usr/lib/x86_64-linux-gnu/libopensm.so.5 (0x7f30816dc000) libosmvendor.so.3 = not found libosmcomp.so.3 = /usr/lib/x86_64-linux-gnu/libosmcomp.so.3 (0x7f30814cd000) because libopensm5 ships libosmvendor.so.4 nowadays. This is an unnoticed transition. For jessie, this bug can be fixed with binNMUs for ibutils (and maybe other affected packages). If the release team accepts this solution, they may tag this bug jessie-ignore. Please do not upload split packages to sid without getting a transition slot and a GO from the release team. But you may (and should) upload them to experimental. This bug was discovered by adequate in a piuparts run. Hi Andreas, Thank you for your bug report. I was a bit annoyed that you went and asked for the binNMU without waiting for me to reply or failing to indicate your plans in this bug report. I also agree with Julien it's better to split the package and fix this properly. I'll upload the package to experimental (well, NEW) as soon as I can, will check the affected packages - not a lot of them and they are all maintained by the ofed team - and I'll find with the RT the best solution. Ana -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770029: libpcl-dev: Wrong PCL_ROOT set in PCLConfig.xml
Package: libpcl-dev Version: 1.7.2-2 Severity: important Dear Maintainer, * What led up to the situation? Trying to compile an application with cmake, using libpcl-dev. * What exactly did you do (or not do) that was effective (or ineffective)? Trying to make any cmake on an application with libpcl-dev * What was the outcome of this action? cmake reports that PCL can not be found on this machine. * What outcome did you expect instead? Correct configuration with cmake. -- System Information: Debian Release: jessie/sid Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (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 libpcl-dev depends on: ii libboost-all-dev 1.55.0.2 ii libeigen3-dev 3.2.2-3 ii libflann-dev 1.8.4-4.1 ii libopenni-dev 1.5.4.0-7+b2 ii libpcl1.7 1.7.2-2 ii libqhull-dev 2012.1-5 ii libvtk5-dev 5.8.0-17.5 libpcl-dev recommends no packages. Versions of packages libpcl-dev suggests: pn libpcl-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769589: debian-cd: Please improve .disk/cd_type for non-complete builds
Steve McIntyre st...@einval.com (2014-11-18): On Mon, Nov 17, 2014 at 07:05:34AM +0100, Petter Reinholdtsen wrote: [Steve McIntyre] Interesting change; I'd be tempted to refactor things slightly in the code, but that's a secondary thing. I'm more curious: what are the ramifications for d-i? Have you investigated/tested? We use d-i in Debian Edu, and it is able to install from our ISO. I have not investigated more than that. :) I suspect it might affect apt-setup, but have not checked the code. tack:~/debian/d-i/d-i/packages$ grep -lr cd_type . | less ./apt-setup/generators/50mirror ./apt-setup/generators/41cdset ./apt-setup/debian/changelog ./apt-setup/finish-install.d/10apt-cdrom-setup So yes, it affects apt-setup only. In 50mirror: it would affect the code that decides whether or not to offer a network mirror, and the installer priority setting. Appending extra details on not_complete will change things here. In 41cdset: it won't change anything here, we'll still bail out as we're not_complete. In 10apt-cdrom-setup: again, appending to not_complete will break the logic there that turns off the CD source for netinst images. I think you need to make some changes in d-i too before I'm happy to take this patch, sorry. Thanks for the heads-up. Looks like material for stretch. Mraw, KiBi. signature.asc Description: Digital signature
Bug#759737: debian-installer: Need preseed entry to select default grub device
Chris Kuehl cku...@ocf.berkeley.edu (2014-11-17): Andrew's patch looks very reasonable to me, as it would allow sysadmins to fully automate installs without further complicating the issues raised in #712907 (which mostly affect interactive installs). I've spent a few hours attempting to test the patch, but can't seem to properly integrate my locally-built grub-installer udeb into a netboot build (either via localudebs or by downloading and unpacking the udeb manually from the installer shell). I strongly suspect my own incompetence is to blame, though, and not the patch. I might be missing something, but we can't seem to find any other way to fully automate jessie installs via preseeding, like we could with wheezy. (For context, our physical machines are split between using /dev/sda and /dev/sde for the first hard drive, while VirtualBox uses /dev/sda and KVM /dev/vda.) grub-installer is fetched from the network in most cases, so it's a bit hard to use a custom one. I tend to build a netinst CD with easy-build.sh (from debian-cd.git), which works fine… once you've got a debian-cd thing configured. I wonder whether the severity of this bug should be raised to important? I suspect that automating installs is an important feature for many other d-i users, so I'm not sure wishlist is appropriate for this bug. I'm going to continue attempting to test the patch, and report back if I have any luck. The severity isn't really important; the fact I've added it to my list of things to keep an eye on, is. Thanks for the poke. Mraw, KiBi. signature.asc Description: Digital signature
