Bug#766348: Does not parse ranges correctly
Package: systemd-cron
Version: 1.3.1+ds1-1
Severity: important
Ranges without steps (1-12) are not correctly parsed by
systemd-crontab-generator.
For example, the line:
55-59 11 * * 1-6true
results in the following:
$ ./systemd-crontab-generator /tmp/test
Traceback (most recent call last):
File ./systemd-crontab-generator, line 273, in module
for job in parse_crontab(filename, withuser=False):
File ./systemd-crontab-generator, line 125, in parse_crontab
'm': parse_time_unit(minutes, MINUTES_SET),
File ./systemd-crontab-generator, line 138, in parse_time_unit
map(parse_period(mapping), value.split(','))), set(
File ./systemd-crontab-generator, line 157, in parser
value = mapping(value)
ValueError: invalid literal for int() with base 10: '55-59'
The attached patch fixes the issue.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd-cron depends on:
ii init-system-helpers 1.21
ii python 2.7.8-1
pn python:any none
ii systemd-sysv 215-5+b1
systemd-cron recommends no packages.
systemd-cron suggests no packages.
--- systemd-crontab-generator.Orig 2014-10-22 14:53:01.915149745 +0200
+++ systemd-crontab-generator 2014-10-22 14:57:04.614228021 +0200
@@ -154,8 +154,8 @@
try:
range, step = value.split('/')
except ValueError:
-value = mapping(value)
-return slice(value, value + 1)
+range = value
+step = 1
if range == '*':
return slice(None, None, int(step))
Bug#743215: write: you are uid ???, but your login is as uid 0
Package: bsdmainutils Version: 9.0.6 Followup-For: Bug #743215 This issue is still affecting me. This check prevents write(1) to be used in cron/batch/slurm scripts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766038: Cannot set color scheme anymore
Package: lxappearance Version: 0.5.6-1 Severity: normal lxappearance doesn't offer the ability to change the gtk colors without lxsession anymore. Setting the gtk-color-scheme property in the gtkrc 2/3 files however doesn't really require lxsession in any way. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766053: Cannot edit user crontabs
On 10/20/2014 03:23 PM, Alexandre Detiste wrote: Hi, I have already discussed this bug with the two other upstreams: https://github.com/systemd-cron/systemd-cron/issues/15 They don't really want to mess with a setuid C program that is a potential security hole. The easiest to fix this on Debian would be to kindly as the 'cron' maintainers to generate an extra 'crontab' binary package with only '/usr/bin/crontab' the manpage included. https://github.com/a-detiste/crontab/commit/37ce687a58187d3cce610b28c1fad47854576584 I have documented this bug + a workaround in the manpage of the next release: https://github.com/systemd-cron/systemd-cron/commit/b9f8bc86eb361515089ebbad187aba8a6553033d Splitting crontab into a separate package would definitely be the way to go IMHO. It's true that we don't really need another implementation, and the proposed work-arounds are not good enough. Did you already ask the cron maintainers if such a patch will be accepted? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766053: Cannot edit user crontabs
Package: systemd-cron Version: 1.3.1+ds1-1 Severity: normal I was just giving systemd-cron a try and it seems that there are issues when using /usr/bin/crontab. /var/spool/cron/crontabs is not created with the correct permissions (my guess is that it should likely be chmod 1730, chown root:crontab). The second issue is that crontab is not running as setgid, since it's a script. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd-cron depends on: ii init-system-helpers 1.21 ii python 2.7.8-1 pn python:any none ii systemd-sysv 215-5+b1 systemd-cron recommends no packages. systemd-cron suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766038: Cannot set color scheme anymore
On 10/20/2014 06:06 PM, Andriy Grytsenko wrote: Yes, it is unavailable now to reflect the fact it requires XSettings daemon to work. Yes, you can set gtk-color-scheme property in ~/.gtkrc-2.0 file but unfortunately it will never affect colors of theme unless a XSettings daemon is running (and then lxsession provides such service), that happens just because each and every theme resets color when is loaded and only way to change them after that point is a XSettings daemon. And there were few bugreports about this before. Feel free to experiment with it to ensure yourself. I'm sorry to disappoint you. Yes, but then lxappearance still shouldn't check explicitly for lxsession, but only for a valid _XSETTINGS_S* atom. There are several alternative XSETTINGS daemons: xsettings-kde and xsettingsd come to my mind, but probably gnome-settings-daemon would also work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766038: Cannot set color scheme anymore
On 10/20/2014 06:54 PM, Andriy Grytsenko wrote: Yuri D'Elia has written on Monday, 20 October, at 18:25: Yes, but then lxappearance still shouldn't check explicitly for lxsession, but only for a valid _XSETTINGS_S* atom. There are several alternative XSETTINGS daemons: xsettings-kde and xsettingsd come to my mind, but probably gnome-settings-daemon would also work. You are right about that and upstream is aware of that, just needed a reliable way to detect XSETTINGS daemon presence, and also mechanism to store color value in that XSETTINGS daemon data. If you can provide a well tested patch within next few days then that would be awesome and updated lxappearance would appear in Debian unstable repository later this week. Otherwise that will be possible only after Jessie release due to scheduled freeze period. I won't definitely have time to provide a patch for this, sorry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766093: Multiple assertion failures
Package: hugin Version: 2014.0.0+dfsg-1+b1 Severity: important Something seems to be broken in either hugin or wxgtk3 right now. Starting hugin with no existing configuration gives me the following startup assertion failures: $ hugin 10:22:20 PM: Debug: Failed to connect to session manager: SESSION_MANAGER environment variable not defined (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion 'width 0' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion 'width 0' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed (hugin:28839): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'height = -1' failed When trying to stich a panorama, the following assertions are emitted: /usr/include/wx-3.0/wx/strvararg.h(456): assert (argtype (wxFormatStringSpecifierT::value)) == argtype failed in wxArgNormalizer(): format specifier doesn't match argument type /usr/include/wx-3.0/wx/strvararg.h(456): assert (argtype (wxFormatStringSpecifierT::value)) == argtype failed in wxArgNormalizer(): format specifier doesn't match argument type 10:24:39 PM: Debug: Failed to connect to session manager: SESSION_MANAGER environment variable not defined /usr/include/wx-3.0/wx/strvararg.h(456): assert (argtype (wxFormatStringSpecifierT::value)) == argtype failed in wxArgNormalizer(): format specifier doesn't match argument type .../include/wx/datetime.h(1740): assert IsValid() failed in GetTicks(): invalid wxDateTime .../src/common/datetime.cpp(1392): assert IsValid() failed in GetTm(): invalid wxDateTime .../include/wx/datetime.h(1740): assert IsValid() failed in GetTicks(): invalid wxDateTime .../include/wx/datetime.h(1740): assert IsValid() failed in GetTicks(): invalid wxDateTime .../src/common/datetime.cpp(1392): assert IsValid() failed in GetTm(): invalid wxDateTime .../include/wx/datetime.h(1740): assert IsValid() failed in GetTicks(): invalid wxDateTime .../src/common/datetime.cpp(1392): assert IsValid() failed in GetTm(): invalid wxDateTime .../include/wx/datetime.h(1740): assert IsValid() failed in GetTicks(): invalid wxDateTime .../src/common/datetime.cpp(1392): assert IsValid() failed in GetTm(): invalid wxDateTime .../include/wx/datetime.h(1740): assert IsValid() failed in GetTicks(): invalid wxDateTime I was thinking that something was broken in libwxgtk3, but I'm also using pgadmin3 and it seems to work just fine. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages hugin depends on: ii enblend 4.1.3+dfsg-2 ii enfuse4.1.3+dfsg-2 ii hugin-tools 2014.0.0+dfsg-1+b1 ii libboost-system1.55.0 1.55.0+dfsg-3 ii libboost-thread1.55.0 1.55.0+dfsg-3 ii libc6 2.19-11 ii libexiv2-13 0.24-4 ii libgcc1 1:4.9.1-18 ii libgl1-mesa-glx [libgl1] 10.3.1-1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1]9.0.0-2 ii libimage-exiftool-perl9.74-1 ii libpano13-3 2.9.19+dfsg-1+b2 ii libstdc++64.9.1-18 ii libtiff5 4.0.3-10+b2 ii libwxbase3.0-03.0.2-1+b1 ii libwxgtk3.0-0 3.0.2-1+b1 ii make 4.0-8 hugin recommends no packages. hugin suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719440: [Rest2web-develop] Bug#719440: rest2web: .. include:: is broken
On 08/11/2013 10:30 PM, Roland Koebler wrote: The .. include::-directive in rest2web searches for the file to include in the wrong directory and includes wrong files. Can somebody provide a small test case in downloadable form? I'm willing to look into this, but I'm a bit short in time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644894: [Rest2web-develop] Bug#644894: rest2web: # print setions # rapidly consumes memory
On 10/10/2011 11:32 AM, Roland Koebler wrote: In the documentation, it's mentioned that sections is a Python dictionary. But if I use # print sections #, r2w seems to consume infinite memory (at least gigabytes of memory in a few seconds). If not aborted immediately, the OOM-killer will probably kill something, and even pressing Ctrl-C immediately leaves the system unusable for several minutes. Some somebody provide a test case for this issue? I couldn't reproduce the issue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764871: allow to select an archive by source package name
Package: snapshot.debian.org Severity: wishlist I remember snapshot.debian.net at some point allowed to have an archive with all the versions of a source package by name: deb http://snapshot.debian.net/archive pool package This was extremely useful to progressively narrow down a package issue irregardless of time. It doesn't look like this feature is available anymore. Can it be restored? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764872: convert +profile regression enters infinite loop exhausting memory
Package: imagemagick Version: 8:6.8.9.6-4 Severity: important The following command: convert test.jpg +profile '!icc,*' out.jpg used to remove all image metadata except ICC tags/profiles. However, in recent versions it just dies after exhausting all system memory. Attaching a random sample image to test it. -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org compare: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org convert: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org composite: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org conjure: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org display: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org identify: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org import: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org mogrify: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org montage: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemagick.org stream: ImageMagick 6.8.9-6 Q16 x86_64 2014-09-06 http://www.imagemaeick.org -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imagemagick depends on: ii imagemagick-6.q16 8:6.8.9.6-4 imagemagick recommends no packages. imagemagick suggests no packages.
Bug#764702: No support for ED25519 keys with enable-ssh-support
Package: gnupg-agent Version: 2.0.26-3 Severity: normal I couldn't find an explicit Debian report for this issue, so I'm filing one to keep track of the status. gpg-agent ssh-agent's emulation (--enable-ssh-support) doesn't yet support ED25519 keys, as available in openssh 6.5 and onward. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763499: RFP: uselessd -- a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism.
Package: wnpp Severity: wishlist * Package name: uselessd Version : 2 Upstream Author : - * URL : http://uselessd.darknedgy.net/ * License : LGPL, MIT, Public Domain Programming Lang: C Description : a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763330: loginctl show-seat does not show ActiveSession/Sessions anymore
Package: systemd Version: 215-5+b1 Severity: minor File: /bin/loginctl At some point, loginctl stopped printing relevant information such as current ActiveSession and Sessions in 'show-seat' (and I guess in other commands as well): $ loginctl show-seat seat0 -a Id=seat0 ActiveSession=[unprintable] CanMultiSession=yes CanTTY=yes CanGraphical=yes Sessions=[unprintable] IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Some weeks ago it used to correctly print the session ids. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.4 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.20.1-5.9 ii libc6 2.19-11 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-1 ii libgcrypt20 1.6.2-4 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-5+b1 ii sysv-rc 2.88dsf-53.4 ii udev215-5+b1 ii util-linux 2.20.1-5.9 Versions of packages systemd recommends: ii dbus1.8.8-1 ii libpam-systemd 215-5+b1 Versions of packages systemd suggests: ii systemd-ui 3-2 -- Configuration Files: /etc/systemd/timesyncd.conf changed [not included] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762037: race in udev root device detection leaves root mounted read-only
Package: systemd Version: 215-4 Followup-For: Bug #762037 I'm also affected by this issue. Of note: the problem persists only if laptop-mode-tools is active (ie: on battery). If I boot the system on AC power, the laptop brings up just fine, suggesting that maybe it's just being activated too soon in the boot process, interfering with some other rule. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757645: Rationale for the change
On 08/18/2014 08:22 AM, Gianfranco Costamagna wrote: Since also my first sponsor got some troubles in running them (if you choose pyside without having it installed you will likely have a import error and in some cases a segfault, IIRC), and since I'm a person that _really_ likes to install and run things, rather than install, run/fail/run/fail/check_faults/change_library, I choose to go for having them both required. IMHO it's perfectly reasonable that if you can select the binding engine, and the selected one is missing, the example fails. The idea of the example is not to let people swap engines at runtime, but to make the example run at all. You could detect at runtime which binding is available and gray out the selection if you really wanted to. This would fix the issue permanently. In my opinion A is the best solution (didn't come in my mind when I firstly thought about this problem), but I really would like to hear some feedbacks ;) I would go for a Depends: pyside|pyqt recommending pyside as the favorable option, since pyqt with python 2.7 has still the old SIP api enabled by default (and changing it is a PITA). I would recommend newcomers to use pyside if possible, even just for the API. Most developers already have a clear idea of which binding to use. I would agree with upstream here to ship with the documentation. I'm working often offline, and I've reported many bug reports trying to ship docs along with the packages and to always Suggest: the -doc package if it exists. I personally wouldn't put examples into a different package, but ship them with the documentation. Unless the examples come with extra unreasonable dependencies. In this case, the -doc can recommend *both* pyqt and pyside (that is, with 2 recommends), without affecting the main package and without requiring an extra one. I feel that a reccomends would be too strong anyway, as one of the goals of pyqtgraph is really to be interchangeable between the two. As far as an example is concerned, if it runs with the installed engine, what's the point really? BTW I'm a quite old DM, but I'm not in the dm.txt list for this package, so would be nice to have a sponsor for the change ;). Cannot help you here, I also need sponsors ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757645: Rationale for the change
On 08/18/2014 11:32 AM, Gianfranco Costamagna wrote: You could detect at runtime which binding is available and gray out the selection if you really wanted to. This would fix the issue permanently. this needs code, and would be nice to have a patch, or to report upstream :) Yes, this is why it's probably like this anyway. Not worth the effort. but my approach will avoid the extra documentation if not needed, someone talked about small systems ;) No problem with that. It's always good to have more granularity. Though generally speaking, you'd need examples for doing development. I feel that a reccomends would be too strong anyway, as one of the goals of pyqtgraph is really to be interchangeable between the two. As far as an example is concerned, if it runs with the installed engine, what's the point really? the point is that people like me wants to have stuff working without reading the READMEs, trying to search for the right dependencies, look at recommends/depends/suggests fields... I think this discussion is a bit overkill. I mean, you need pyqtgraph for development. pyqtgraph needs at least *one* qt binding to work at all. As a developer, I don't need strict dependencies to understand that. In fact, I'm forced to use pyqt in some projects, and pyside in others. When pyqtgraph is pulled as a dependency, you need to make sure to pull the least amount of dependencies for user's sake. This is why an OR dependency is the way to go. I would revert dependencies just to fix this. I'm being pragmatic here. I'd expect developers to know what pyqt or pyside mean. Maybe they don't know which one to choose, but this doesn't make an intrinsic difference. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757645: Please revert the latest Depends from python-qt4 | python-pyside to python-qt4 and python-pyside
Package: python-pyqtgraph Version: 0.9.8-1 Followup-For: Bug #757645 Yes, please. pyqtgraph supports pyqt and pyside interchangeably. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755922: clang-X should Suggest: clang-X-doc
Package: clang-3.5 Version: 1:3.5~svn213451-1 Severity: wishlist As done for llvm, it would be nice if clang-X would Suggest: clang-X-doc. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753509: Should suggest cython-doc
Source: cython Severity: minor cython should suggest cython-doc. Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-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#753296: Acknowledgement (mpv completion fails)
On 06/30/2014 08:05 PM, Axel Beckert wrote: Yep, that's definitely broken... what architecture are you on? AFAICT both amd64 and i386 look fine. Damn! I had mpv pinned from deb-multimedia. Indeed, looks like the rebuild fails there for some reason, because the debian package works fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753296: mpv completion fails
Package: zsh Version: 5.0.5-4 Severity: minor The following happens if I try to complete a file for mpv: 1% mpv _mpv:7: command not found: *:files:-mfiles mpv is at 0.4 (from unstable). Not sure when this started to happen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753296: Acknowledgement (mpv completion fails)
Ahh sorry, I noticed only now that the _mpv function is shipped with mpv itself. Could you reassign it to mpv? Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753296: Acknowledgement (mpv completion fails)
On 06/30/2014 12:17 PM, Frank Terbeck wrote: Yuri D'Elia wrote: Ahh sorry, I noticed only now that the _mpv function is shipped with mpv itself. Could you reassign it to mpv? The problem you're describing looks like a broken completions-cache file. Before you proceed, try this: % rm ~/.zcompdump % exec zsh And see if the problem persists. It persists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753296: Acknowledgement (mpv completion fails)
On 06/30/2014 01:40 PM, Alessandro Ghedini wrote:
The problem you're describing looks like a broken completions-cache
file. Before you proceed, try this:
% rm ~/.zcompdump
% exec zsh
And see if the problem persists.
It persists.
Can you post the content of /usr/share/zsh/vendor-completions/_mpv? Also, what
architecture are you on? The script is generated at build time, so it might be
that the generation broke on some platforms.
Attaching.
#compdef mpv
# mpv zsh completion
_x_arguments -C -s \
'*:files:-mfiles'
case $state in
ao)
local -a values
values=(
)
_describe -t values 'audio outputs' values
;;
vo)
local -a values
values=(
)
_describe -t values 'video outputs' values
;;
af)
local -a values
values=(
)
_describe -t values 'audio filters' values
;;
vf)
local -a values
values=(
)
_describe -t values 'video filters' values
;;
mfiles)
_tags files urls
while _tags; do
_requested files expl 'media file' _files -g \
*.(#i)(asf|asx|avi|flac|flv|m1v|m2p|m2v|m4v|mjpg|mka|mkv|mov|mp3|mp4|mpe|mpeg|mpg|ogg|ogm|ogv|qt|rm|ts|vob|wav|webm|wma|wmv)(-.)
ret=0
if _requested urls; then
while _next_label urls expl URL; do
_urls $expl[@] ret=0
compadd -S '' $expl[@] {dvd,vcd,cdda,cddb,tv}:// ret=0
done
fi
(( ret )) || return 0
done
;;
esac
Bug#753330: RFP: padb -- Parallel Application Debugger
Package: wnpp Severity: wishlist * Package name: padb Version : 3.3 Upstream Author : Ashley Pittman ash...@pittman.co.uk * URL : http://padb.pittman.org.uk/ * License : LGPL Programming Lang: C Description : Parallel Application Debugger Padb is a Job Inspection Tool for examining and debugging parallel programs, primarily it simplifies the process of gathering stack traces on compute clusters however it also supports a wide range of other functions. Padb supports a number of parallel environments and it works out-of-the-box on the majority of clusters. It's an open source, non-interactive, command line, script-able tool intended for use by programmers and system administrators alike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751915: iv crash
Package: openimageio-tools Version: 1.4.9~dfsg0-1 Severity: normal With the last update, iv crashes on any file for me with the following assertion failure: % iv -F -v IMG53559.JPG OpenGL Shading Language supported: 1 OpenGL sRGB color space textures supported: 1 OpenGL half-float pixels supported: 1 OpenGL float texture storage supported: 1 OpenGL pixel buffer object supported: 1 OpenGL max texture dimension: 4096 read was not necessary -- using cache /tmp/buildd/openimageio-1.4.9~dfsg0/src/libtexture/imagecache.cpp:1964: failed assertion 'm_mem_used (long long)m_max_memory_bytes*10' -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-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 openimageio-tools depends on: ii libatomic1 4.9.0-6 ii libboost-filesystem1.55.0 1.55.0+dfsg-2 ii libboost-regex1.55.0 1.55.0+dfsg-2 ii libboost-system1.55.0 1.55.0+dfsg-2 ii libboost-thread1.55.0 1.55.0+dfsg-2 ii libc6 2.19-2 ii libfreetype6 2.5.2-1 ii libgcc11:4.9.0-6 ii libgif44.1.6-11 ii libgl1-mesa-glx [libgl1] 10.1.4-1 ii libglew1.101.10.0-3 ii libglu1-mesa [libglu1] 9.0.0-2 ii libice62:1.0.8-2 ii libilmbase61.0.1-6 ii libjpeg8 8d-2 ii libopencolorio11.0.9~dfsg0-1 ii libopencv-core2.4 2.4.8+dfsg1-2.2 ii libopencv-highgui2.4 2.4.8+dfsg1-2.2 ii libopenexr61.6.1-7 ii libopenimageio1.4 1.4.9~dfsg0-1 ii libpng12-0 1.2.50-1 ii libqt4-opengl 4:4.8.6+dfsg-2 ii libqtcore4 4:4.8.6+dfsg-2 ii libqtgui4 4:4.8.6+dfsg-2 ii libraw10 0.16.0-5 ii libsm6 2:1.2.1-2 ii libstdc++6 4.9.0-6 ii libtiff5 4.0.3-8 ii libwebp5 0.4.0-4.1 ii libx11-6 2:1.6.2-2 ii libxext6 2:1.3.2-1 ii zlib1g 1:1.2.8.dfsg-1 openimageio-tools recommends no packages. openimageio-tools suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750475: No locking when sleeping
Package: xautolock Version: 1:2.2-4 Severity: important I'm a bit puzzled by the behavior of xautolock when putting a laptop to sleep. Manual page for -detectsleep says by _default_ sleep is not detected if -detectsleep is not used. So, if I put a laptop to sleep for more than the primary timeout, I would expect that the locking program is triggered as soon as the laptop is awakened. But this doesn't happen (thus important priority, as xautolock fails to call the locking program here). I would always want to lock the screen if the primary timeout is expected, *especially* when the laptop has been put to sleep. Using -detectsleep doesn't actually change anything for me. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-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 xautolock depends on: ii libc6 2.18-7 ii libx11-6 2:1.6.2-2 ii libxext6 2:1.3.2-1 ii libxss1 1:1.2.2-1 Versions of packages xautolock recommends: pn xtrlock | xscreensaver none xautolock suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747233: New upstream (r3248)
Package: mkgmap Version: 0.0.0+svn2981-1 Severity: wishlist A new upstream release is available (r3248). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600547: python-scipy: Scipy Documentation not in Debian
Package: python-scipy Version: 0.13.3-2 Followup-For: Bug #600547 I'd also vouch for having a proper python-scipy-doc package, pretty-please :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743215: write: you are uid ???, but your login is as uid 0
Package: bsdmainutils Version: 9.0.5 Followup-For: Bug #743215 I'd like to point out this is actually Debian-specific behavior (the original source doesn't have this restriction). Could somebody address as to why this check was put in place? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745028: udisks.umount times out without real error
Package: udisks Version: 1.0.5-1 Severity: important udisks.umount has some sort of built-in timeout (maybe default dbus call timeout?) If you are unmounting a slow device with a large dirty cache, this is what you usually get: $ umount /media/usb_shtick Unmount failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. This is, of course, not a real error. unmount should *must* not fail here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743203: Address canonicalization is suboptimal
Package: openssh-client Version: 1:6.6p1-1 Severity: minor I'm trying hard to use address canonicalization in my favor. 6.6 adds re-parsing if hostname is changed as a result of it, but that doesn't make canonicalization generally more useful as I hoped. Assume the following ssh_config: === Host * CanonicalizeHostname yes # enable canonicalization Host hostname CanonicalDomains hostname.domain # make hostname fully qualified Host *.domain # general settings for the domain name User exception Host * User normal # fallback === Since the first settings that matches wins, that what happens: - second rule matches, changes hostname - fourth rule matches, sets fallback username - reparsing - first/second/third rule matches, username already set so setting is skipped With this first-match-wins/reparsing logic, it's impossible to have a common fallback block. Thus, to have exceptions, you must put them directly in the first matching block (in this case, rule 2), thus defeating the purpose of re-parsing. I'm wondering why CanonicalDomains cannot *immediately* update the processed hostname for Host/Match blocks, so that rule 3 would match on the *first* scan, correctly setting the exception, without the need of a second pass. Not to mention that [verified using ssh -v] /etc/ssh/ssh_config options are applied before the rescan, meaning that global options (declared as Host *) will always override user's exceptions (thus minor priority of this report as opposed to wishlist). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743215: write: you are uid ???, but your login is as uid 0
Package: bsdmainutils Version: 9.0.5 Severity: minor write(1) refuses to write when eid/uid are different: write: you are uid 1001, but your login is as uid 0 Yes, but why would it matter when uid=0? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742905: No default for no_playlist
Package: podget Version: 0.6.16-1 Severity: normal When upgrading podget with an existing config, no_playlist seem to have no default and thus the following errors are shown: /usr/bin/podget: line 1004: [: -eq: unary operator expected /usr/bin/podget: line 1066: [: -eq: unary operator expected /usr/bin/podget: line 1080: [: -eq: unary operator expected -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742683: RFP: rr -- rr records nondeterministic executions and debugs them deterministically
Package: wnpp Severity: wishlist * Package name: rr Version : - Upstream Author : Mozilla * URL : http://rr-project.org/ * License : MPL Programming Lang: C Description : rr records nondeterministic executions and debugs them deterministically rr allows to record a program trace and replay the trace with the aid of a debugger, allowing you to debug non-deterministic executions in a deterministic fascion by replaying the trace. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742253: wish not provided anymore
Package: tk8.5 Version: 8.5.14-2 Severity: normal I believe there is a problem with how wish is provided. In the newer version of tk8.5, wish is not provided anymore, but only by the latest tk version. tk simply depends on the newer package version, but it shouldn't break old releases unless there is a real reason to do so. I cannot install isag (for example), which doesn't depend on any specific tk version. 'isag' depends on tk|wish, but since 8.5 doesn't provide wish anymore, tk is selected and tk breaks 8.5 (of course, I cannot remove 8.5 yet as many packages depend on it). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742253: [Pkg-tcltk-devel] Bug#742253: wish not provided anymore
On 03/21/2014 12:14 PM, Sergei Golovan wrote: Hi Yuri, On Fri, Mar 21, 2014 at 2:33 PM, Yuri D'Elia wav...@thregr.org wrote: I believe there is a problem with how wish is provided. In the newer version of tk8.5, wish is not provided anymore, but only by the latest tk version. Currently, no tk8.* packages provide /usr/bin/wish interpreter anymore. Only the tk package contains /usr/bin/wish. And for now, /usr/bin/wish is a symlink to /usr/bin/wish8.6, so if a program specifically requires Tcl/Tk 8.5 then it must depend on tk8.5 and use /usr/bin/wish8.5 as a wish interpreter. tk simply depends on the newer package version, but it shouldn't break old releases unless there is a real reason to do so. I don't really follow you in break old releases. Sorry, I didn't see the Breaks was versioned. I had 8.5 on hold so I though installing tk wasn't possible. Sorry for the noise. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741454: Allow users in group netdev to use rfkill
On 03/13/2014 08:00 PM, Marco d'Itri wrote: On Mar 13, Michael Biebl bi...@debian.org wrote: I don't think we should do that. Udev rules should only use a limited subset of groups which are guaranteed to exist. netdev is no such case. We *cannot* use users/groups which are not in the default /etc/passwd indeed, or annoying things will happen. I do not object in principle to having /dev/rfkill in group netdev (but I do not know anything about how software rfkill is used), but the rule must be shipped by a package which creates the group. By grepping on my system, I see wicd-daemon, ifupdown and wpasupplicant trying to create the group netdev when missing, so there's no single package. Out of those, I would say netbase. If you think that's ok, could you re-assign the bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741454: Allow users in group netdev to use rfkill
On 03/21/2014 05:10 PM, Yuri D'Elia wrote: Out of those, I would say netbase. Sorry there, I meant ifupdown. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741613: RFP: glslang -- OpenGL / OpenGL ES Shading Language Reference Compiler
Package: wnpp Severity: wishlist * Package name: glslang Version : - Upstream Author : Khronos Group * URL : https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/ * License : BSD Programming Lang: C, C++ Description : OpenGL / OpenGL ES Shading Language Reference Compiler Glslang is the official reference compiler front end for the OpenGL ES and OpenGL shading languages. It implements a strict interpretation of the specifications for these languages. It is open and free for anyone to use, either from a command line or programmatically. The OpenGL and OpenGL ES working groups are committed to maintaining consistency between the reference compiler and the corresponding shading language specifications. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741614: RFP: vogl -- OpenGL capture / playback debugger
Package: wnpp Severity: wishlist * Package name: vogl Version : - Upstream Author : Valve Software * URL : https://github.com/ValveSoftware/vogl * License : BSD Programming Lang: C++ Description : OpenGL capture / playback debugger vogl is a suite of programs to trace/capture OpenGL calls through dynamic library preloading. The trace file can then be analyzed for performance and debugging issues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741454: Allow users in group netdev to use rfkill
Package: udev Version: 204-7 Severity: wishlist It makes sense to allow users in the group netdev (which are already able to bring up/down network interfaces) to also use rfkill without root privileges, by changing rules.d/91-permissions.rules: KERNEL==rfkill, MODE=0664 GROUP=netdev Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740824: Additional rules to match body and urgency
Package: dunst
Version: 1.0.0-2
Followup-For: Bug #740824
I noticed my last patch was missing some required changes to config.def.h.
Re-attaching the complete patch.
diff -rud dunst-1.0.0.Orig/dunstrc dunst-1.0.0/dunstrc
--- dunst-1.0.0.Orig/dunstrc 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/dunstrc 2014-03-05 14:18:34.002606394 +0100
@@ -166,7 +166,7 @@
# Every section that isn't one of the above is interpreted as a rules
# to override settings for certain messages.
-# Messages can be matched by 'appname', 'summary', 'body' or 'icon'
+# Messages can be matched by 'appname', 'summary', 'body', 'icon' or 'msg_urgency'.
# and you can override the 'timeout', 'urgency', 'foreground', 'background'
# and 'format'.
# Shell-like globbing will get expanded.
diff -rud dunst-1.0.0.Orig/rules.c dunst-1.0.0/rules.c
--- dunst-1.0.0.Orig/rules.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/rules.c 2014-03-05 14:20:56.246612633 +0100
@@ -49,6 +49,7 @@
r-body = NULL;
r-icon = NULL;
r-timeout = -1;
+r-msg_urgency = -1;
r-urgency = -1;
r-fg = NULL;
r-bg = NULL;
@@ -64,6 +65,7 @@
return ((!r-appname || !fnmatch(r-appname, n-appname, 0))
(!r-summary || !fnmatch(r-summary, n-summary, 0))
(!r-body || !fnmatch(r-body, n-body, 0))
- (!r-icon || !fnmatch(r-icon, n-icon, 0)));
+ (!r-icon || !fnmatch(r-icon, n-icon, 0))
+ (r-msg_urgency == -1 || r-msg_urgency == n-urgency));
}
/* vim: set ts=8 sw=8 tw=0: */
diff -rud dunst-1.0.0.Orig/rules.h dunst-1.0.0/rules.h
--- dunst-1.0.0.Orig/rules.h 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/rules.h 2014-03-05 14:21:44.014614729 +0100
@@ -13,6 +13,7 @@
char *summary;
char *body;
char *icon;
+int msg_urgency;
/* actions */
int timeout;
diff -rud dunst-1.0.0.Orig/settings.c dunst-1.0.0/settings.c
--- dunst-1.0.0.Orig/settings.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/settings.c 2014-03-05 14:21:23.242613817 +0100
@@ -31,6 +31,27 @@
}
+static int ini_get_urgency(char *section, char *key, int def)
+{
+int ret = def;
+char *urg = ini_get_string(section, key, );
+
+if (strlen(urg) 0) {
+if (strcmp(urg, low) == 0)
+ret = LOW;
+else if (strcmp(urg, normal) == 0)
+ret = NORM;
+else if (strcmp(urg, critical) == 0)
+ret = CRIT;
+else
+fprintf(stderr,
+unknown urgency: %s, ignoring\n,
+urg);
+free(urg);
+}
+return ret;
+}
+
void load_settings(char *cmdline_config_path)
{
@@ -280,22 +301,8 @@
r-body = ini_get_string(cur_section, body, r-body);
r-icon = ini_get_string(cur_section, icon, r-icon);
r-timeout = ini_get_int(cur_section, timeout, r-timeout);
-{
-char *urg = ini_get_string(cur_section, urgency, );
-if (strlen(urg) 0) {
-if (strcmp(urg, low) == 0)
-r-urgency = LOW;
-else if (strcmp(urg, normal) == 0)
-r-urgency = NORM;
-else if (strcmp(urg, critical) == 0)
-r-urgency = CRIT;
-else
-fprintf(stderr,
-unknown urgency: %s, ignoring\n,
-urg);
-free(urg);
-}
-}
+r-urgency = ini_get_urgency(cur_section, urgency, r-urgency);
+r-msg_urgency = ini_get_urgency(cur_section, msg_urgency, r-msg_urgency);
r-fg = ini_get_string(cur_section, foreground, r-fg);
r-bg = ini_get_string(cur_section, background, r-bg);
r-format = ini_get_string(cur_section, format, r-format);
--- dunst-1.0.0.Orig/config.def.h 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/config.def.h 2014-03-06 12:43:56.981454478 +0100
@@ -81,11 +81,11 @@
rule_t default_rules[] = {
/* name can be any unique string. It is used to identify the rule in dunstrc to override it there */
-/* name, appname, summary, body, icon, timeout, urgency, fg,bg, format, script */
-{empty, NULL, NULL, NULL, NULL, -1, -1, NULL, NULL, NULL, NULL},
-/* { rule1, notify-send, NULL,NULL, NULL, -1, -1, NULL, NULL, %s %b, NULL }, */
-/* { rule2, Pidgin, *says*, NULL, NULL, -1,
Bug#705607: 1.0 breaks alignment != left
Package: dunst Followup-For: Bug #705607 I upgraded again to dunst 1.0 today, and it seems that it has been resolved, suggesting some likely library issue. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-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 dunst depends on: ii libc62.18-4 ii libcairo21.12.16-2 ii libdbus-1-3 1.8.0-2 ii libfreetype6 2.5.2-1 ii libglib2.0-0 2.38.2-5 ii libpango-1.0-0 1.36.2-2 ii libpangocairo-1.0-0 1.36.2-2 ii libx11-6 2:1.6.2-1 ii libxdg-basedir1 1.2.0-1 ii libxext6 2:1.3.2-1 ii libxft2 2.3.1-2 ii libxinerama1 2:1.1.3-1 ii libxss1 1:1.2.2-1 dunst recommends no packages. dunst suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740823: alignment=center|right doesn't work with width=0
Package: dunst Version: 1.0.0-2 Severity: minor With: [global] alignment = right geometry = -0-0 the text is not actually flushed right. The geometry here is aligning the frame to the top-right corner of the screen. Width is empty/0, which means automatic width. If I set a width manually: geometry = 100x-0-0 the text is actually centered/aligned right, suggesting that dunst is not taking the lenght of the longest message before performing the layout of the individual lines, which is what I would like it to do. This used to work in dunst 0.5. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-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 dunst depends on: ii libc62.18-4 ii libcairo21.12.16-2 ii libdbus-1-3 1.8.0-2 ii libfreetype6 2.5.2-1 ii libglib2.0-0 2.38.2-5 ii libpango-1.0-0 1.36.2-2 ii libpangocairo-1.0-0 1.36.2-2 ii libx11-6 2:1.6.2-1 ii libxdg-basedir1 1.2.0-1 ii libxext6 2:1.3.2-1 ii libxft2 2.3.1-2 ii libxinerama1 2:1.1.3-1 ii libxss1 1:1.2.2-1 dunst recommends no packages. dunst suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740824: Additional rules to match body and urgency
Package: dunst Version: 1.0.0-2 Severity: wishlist It seems that I cannot match on the urgency of a message (to format it in a different way only for a particular application), and also cannot match the body (which would be helpful to format messages without body). For the first request, this would be my use case: [rule] appname = test ... [rule-exception] appname = test match_urgency = critical script = call a different script so that I don't have to call the script for _every_ notification and do rule-checking again. 'urgency' is already use to _set_ the message urgency, so some new name should be used. Second request use case: [global] format = %s: %b [no-body] body = format = %s Pretty obvious. Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-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 dunst depends on: ii libc62.18-4 ii libcairo21.12.16-2 ii libdbus-1-3 1.8.0-2 ii libfreetype6 2.5.2-1 ii libglib2.0-0 2.38.2-5 ii libpango-1.0-0 1.36.2-2 ii libpangocairo-1.0-0 1.36.2-2 ii libx11-6 2:1.6.2-1 ii libxdg-basedir1 1.2.0-1 ii libxext6 2:1.3.2-1 ii libxft2 2.3.1-2 ii libxinerama1 2:1.1.3-1 ii libxss1 1:1.2.2-1 dunst recommends no packages. dunst suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740825: RFP: xuserrun -- Run commands as the currently-active X11 user
Package: wnpp Severity: wishlist * Package name: xuserrun Version : - Upstream Author : Todd Partridge toddrpartri...@gmail.com, Brain Mattern https://github.com/rephormE * URL : https://github.com/Gen2ly/xuserrun * License : GPLv3+ Programming Lang: Bash Description : Run commands as the currently-active X11 user xuserrun allows a command to be run on the X.org user's display. It determines the DISPLAY and USER environmental variables of the logged-in user necessary to run a program through the X.org server display. Its primary use is to be able to run a X.org program from within another environment (different user, console, cron, boot script...). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740824: Additional rules to match body and urgency
Package: dunst
Version: 1.0.0-2
Followup-For: Bug #740824
With the attached patch I provide a way to match on message urgency using
'msg_urgency' as a new filter.
I didn't notice that 'body' could already be used, sorry.
diff -rud dunst-1.0.0.Orig/dunstrc dunst-1.0.0/dunstrc
--- dunst-1.0.0.Orig/dunstrc 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/dunstrc 2014-03-05 14:18:34.002606394 +0100
@@ -166,7 +166,7 @@
# Every section that isn't one of the above is interpreted as a rules
# to override settings for certain messages.
-# Messages can be matched by 'appname', 'summary', 'body' or 'icon'
+# Messages can be matched by 'appname', 'summary', 'body', 'icon' or 'msg_urgency'.
# and you can override the 'timeout', 'urgency', 'foreground', 'background'
# and 'format'.
# Shell-like globbing will get expanded.
diff -rud dunst-1.0.0.Orig/rules.c dunst-1.0.0/rules.c
--- dunst-1.0.0.Orig/rules.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/rules.c 2014-03-05 14:20:56.246612633 +0100
@@ -49,6 +49,7 @@
r-body = NULL;
r-icon = NULL;
r-timeout = -1;
+r-msg_urgency = -1;
r-urgency = -1;
r-fg = NULL;
r-bg = NULL;
@@ -64,6 +65,7 @@
return ((!r-appname || !fnmatch(r-appname, n-appname, 0))
(!r-summary || !fnmatch(r-summary, n-summary, 0))
(!r-body || !fnmatch(r-body, n-body, 0))
- (!r-icon || !fnmatch(r-icon, n-icon, 0)));
+ (!r-icon || !fnmatch(r-icon, n-icon, 0))
+ (r-msg_urgency == -1 || r-msg_urgency == n-urgency));
}
/* vim: set ts=8 sw=8 tw=0: */
diff -rud dunst-1.0.0.Orig/rules.h dunst-1.0.0/rules.h
--- dunst-1.0.0.Orig/rules.h 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/rules.h 2014-03-05 14:21:44.014614729 +0100
@@ -13,6 +13,7 @@
char *summary;
char *body;
char *icon;
+int msg_urgency;
/* actions */
int timeout;
diff -rud dunst-1.0.0.Orig/settings.c dunst-1.0.0/settings.c
--- dunst-1.0.0.Orig/settings.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/settings.c 2014-03-05 14:21:23.242613817 +0100
@@ -31,6 +31,27 @@
}
+static int ini_get_urgency(char *section, char *key, int def)
+{
+int ret = def;
+char *urg = ini_get_string(section, key, );
+
+if (strlen(urg) 0) {
+if (strcmp(urg, low) == 0)
+ret = LOW;
+else if (strcmp(urg, normal) == 0)
+ret = NORM;
+else if (strcmp(urg, critical) == 0)
+ret = CRIT;
+else
+fprintf(stderr,
+unknown urgency: %s, ignoring\n,
+urg);
+free(urg);
+}
+return ret;
+}
+
void load_settings(char *cmdline_config_path)
{
@@ -280,22 +301,8 @@
r-body = ini_get_string(cur_section, body, r-body);
r-icon = ini_get_string(cur_section, icon, r-icon);
r-timeout = ini_get_int(cur_section, timeout, r-timeout);
-{
-char *urg = ini_get_string(cur_section, urgency, );
-if (strlen(urg) 0) {
-if (strcmp(urg, low) == 0)
-r-urgency = LOW;
-else if (strcmp(urg, normal) == 0)
-r-urgency = NORM;
-else if (strcmp(urg, critical) == 0)
-r-urgency = CRIT;
-else
-fprintf(stderr,
-unknown urgency: %s, ignoring\n,
-urg);
-free(urg);
-}
-}
+r-urgency = ini_get_urgency(cur_section, urgency, r-urgency);
+r-msg_urgency = ini_get_urgency(cur_section, msg_urgency, r-msg_urgency);
r-fg = ini_get_string(cur_section, foreground, r-fg);
r-bg = ini_get_string(cur_section, background, r-bg);
r-format = ini_get_string(cur_section, format, r-format);
Bug#705607: 1.0 breaks alignment != left
Package: dunst
Version: 1.0.0-2
Followup-For: Bug #705607
The problem is caused by pango not knowing the final layout width when
rendering.
The attached patch fixes the problem.
--- dunst-1.0.0.Orig/x.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/x.c 2014-03-05 14:46:01.670678667 +0100
@@ -160,6 +160,17 @@
}
+static void r_update_layouts_width(GSList *layouts, int width)
+{
+width -= 2 * settings.h_padding;
+width -= 2 * settings.frame_width;
+
+for (GSList *iter = layouts; iter; iter = iter-next) {
+colored_layout *cl = iter-data;
+pango_layout_set_width(cl-l, width * PANGO_SCALE);
+}
+}
+
static void free_colored_layout(void *data)
{
colored_layout *cl = data;
@@ -379,6 +390,10 @@
int width = dim.w;
int height = dim.h;
+ if (have_dynamic_width() settings.align != left) {
+r_update_layouts_width(layouts, width);
+}
+
cairo_t *c;
cairo_surface_t *image_surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, width, height);
c = cairo_create(image_surface);
Bug#740840: Pausing dunst with visible notifications results in endless loop
Package: dunst
Version: 1.0.0-2
Severity: important
Tags: patch
Doing the following:
$ notify-send 'test'; notify-send DUNST_COMMAND_PAUSE
will cause dunst to enter an infinite loop.
Possibly related to bug #729690.
In the attached patch, we see how it's obvious that we keep popping from the
wrong queue.
Also in the patch, a double call to run(NULL) can be avoided while processing a
new notification (which I discovered while tracking down this bug).
Thanks.
diff -rud dunst-1.0.0.Orig/dbus.c dunst-1.0.0/dbus.c
--- dunst-1.0.0.Orig/dbus.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/dbus.c 2014-03-05 15:12:11.750747537 +0100
@@ -278,13 +278,11 @@
n-color_strings[ColBG] = bgcolor;
int id = notification_init(n, replaces_id);
-wake_up();
-
GVariant *reply = g_variant_new((u), id);
g_dbus_method_invocation_return_value(invocation, reply);
g_dbus_connection_flush(connection, NULL, NULL, NULL);
-run(NULL);
+wake_up();
}
static void onCloseNotification(GDBusConnection * connection,
diff -rud dunst-1.0.0.Orig/dunst.c dunst-1.0.0/dunst.c
--- dunst-1.0.0.Orig/dunst.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/dunst.c 2014-03-05 15:12:00.806747057 +0100
@@ -105,7 +105,7 @@
if (pause_display) {
while (displayed-length 0) {
-g_queue_insert_sorted(queue, g_queue_pop_head(queue),
+g_queue_insert_sorted(queue, g_queue_pop_head(displayed),
notification_cmp_data, NULL);
}
return;
Bug#740823: alignment=center|right doesn't work with width=0
Package: dunst
Version: 1.0.0-2
Followup-For: Bug #740823
I wrongly filed this fix under the wrong bug report before, sorry for the noise.
The problem is caused by pango not knowing the final layout width when
rendering.
The attached patch fixes the problem.
--- dunst-1.0.0.Orig/x.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/x.c 2014-03-05 14:46:01.670678667 +0100
@@ -160,6 +160,17 @@
}
+static void r_update_layouts_width(GSList *layouts, int width)
+{
+width -= 2 * settings.h_padding;
+width -= 2 * settings.frame_width;
+
+for (GSList *iter = layouts; iter; iter = iter-next) {
+colored_layout *cl = iter-data;
+pango_layout_set_width(cl-l, width * PANGO_SCALE);
+}
+}
+
static void free_colored_layout(void *data)
{
colored_layout *cl = data;
@@ -379,6 +390,10 @@
int width = dim.w;
int height = dim.h;
+ if (have_dynamic_width() settings.align != left) {
+r_update_layouts_width(layouts, width);
+}
+
cairo_t *c;
cairo_surface_t *image_surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, width, height);
c = cairo_create(image_surface);
Bug#729690: dunst: Dunst causes high cpu usage on kde screenserver
Package: dunst
Version: 1.0.0-2
Followup-For: Bug #729690
Indeed, I also experienced this problem using i3lock.
dunst is forcedly raising its window, which is broken behavior anyway.
The _NET_WM_STATE_ABOVE property should be set on the window instead to avoid
conflicting behaviors with other above windows.
The attached patch fixes this bug.
--- dunst-1.0.0.Orig/x.c 2014-03-05 12:41:03.274349758 +0100
+++ dunst-1.0.0/x.c 2014-03-05 18:49:30.659319475 +0100
@@ -498,10 +513,6 @@
case SelectionNotify:
if (ev.xselection.property == xctx.utf8)
break;
-case VisibilityNotify:
-if (ev.xvisibility.state != VisibilityUnobscured)
-XRaiseWindow(xctx.dpy, xctx.win);
-break;
case ButtonPress:
if (ev.xbutton.window == xctx.win) {
x_handle_click(ev);
@@ -798,6 +809,12 @@
CopyFromParent, DefaultVisual(xctx.dpy,
DefaultScreen(xctx.dpy)),
CWOverrideRedirect | CWBackPixmap | CWEventMask, wa);
+
+Atom _NET_WM_STATE = XInternAtom(xctx.dpy, _NET_WM_STATE, false);
+Atom _NET_WM_STATE_ABOVE = XInternAtom(xctx.dpy, _NET_WM_STATE_ABOVE, false);
+XChangeProperty(xctx.dpy, xctx.win, _NET_WM_STATE, XA_ATOM, 32,
+PropModeReplace, (unsigned char *)_NET_WM_STATE_ABOVE, 1L);
+
settings.transparency =
settings.transparency 100 ? 100 : settings.transparency;
setopacity(xctx.win,
Bug#681991: setting scroll-margin breaks redisplay on emacs24
Source: emacs24 Followup-For: Bug #681991 This bug is now fixed. You can close the report. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703884: Setting window title with ^]2; escape fails if sent too early
Package: zsh Followup-For: Bug #703884 This was fixed at least in zsh 5.0.4 already. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740348: Should suggest python-statsmodels-doc
Source: python-statsmodels Severity: wishlist As for all packages with relevant documentation, python-statsmodels should suggest python-statsmodels-doc. Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-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#739956: Fails with linux-vdso.so.1 not found
On 02/28/2014 04:58 PM, Thomas Preud'homme wrote: Indeed. I'm hardcoding the value for now as having a regex is less easy. Anyway, although I started a process to make pstack more platform independant, the work is currently stalled and thus pstack only has to deal with x86 (and amd64 is a bit broken for now). You can pull from git clone git://git.celest.fr/pstack.git I'd like to at least finish fixing amd64 before doing a new release but if it takes time (let's say, more than 3 months or so) I'll release with just this fix as a bugfix release. If the fix works for you, I'll upload a patched version in Debian. So what's broken currently on amd64? (because that's the only platform I'm planning to use anyway). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740061: RFP: ktap -- lightweight script-based dynamic tracing tool for Linux
Package: wnpp Severity: wishlist * Package name: ktap Version : 0.3 Upstream Author : Jovi Zhangwei jovi.zhang...@gmail.com * URL : http://www.ktap.org/ * License : GPL Programming Lang: C, Lua Description : lightweight script-based dynamic tracing tool for Linux ktap is a new script-based dynamic tracing tool for Linux, it uses a scripting language and lets users trace the Linux kernel dynamically. ktap is designed to give operational insights with interoperability that allows users to tune, troubleshoot and extend kernel and application. It's similar with Linux Systemtap and Solaris Dtrace. ktap have different design principles from Linux mainstream dynamic tracing language in that it's based on bytecode, so it doesn't depend upon GCC, doesn't require compiling kernel module for each script, safe to use in production environment, fulfilling the embedded ecosystem's tracing needs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739956: Fails with linux-vdso.so.1 not found
Package: pstack Version: 1.3.1-1 Severity: important pstack 11019 11019: test.debug 'linux-vdso.so.1': opening object file: No such file or directory Could not open object file. Trying to locate linux-vdso is never going to work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739689: PubMed ID metadata loop-up fails
Package: referencer Version: 1.2.1-1+b1 Severity: normal Any reference lookup involving PMID fails for me. (Documents - Add reference with ID - Pubmed ID). Get metadata does not import anything. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-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 referencer depends on: ii libatkmm-1.6-12.22.7-2 ii libboost-regex1.54.0 1.54.0-4+b1 ii libc6 2.17-97 ii libgcc1 1:4.8.2-16 ii libgconfmm-2.6-1c22.28.0-1 ii libgdk-pixbuf2.0-02.30.5-1 ii libglib2.0-0 2.38.2-5 ii libglibmm-2.4-1c2a2.36.2-1 ii libgtk2.0-0 2.24.22-1 ii libgtkmm-2.4-1c2a 1:2.24.4-1 ii libpangomm-1.4-1 2.34.0-1 ii libpoppler-glib8 0.22.5-4 ii libpython2.7 2.7.6-5 ii libsigc++-2.0-0c2a2.2.11-3 ii libstdc++64.8.2-16 ii libxml2 2.9.1+dfsg1-3 referencer recommends no packages. referencer suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739635: Recommend trend
Source: science-viewing Severity: wishlist I was browsing through science-viewing, and found 'feedgnuplot' as a recommendation. Though not as flexible as feedgnuplot+gnuplot, I'm using 'trend' for realtime data visualization since gnuplot is just too slow. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-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#739313: Cannot set per monitor/output profile
Package: xicc Version: 0.2-3 Severity: wishlist xicc should support a way to set the display profile per-output using the following specification: http://www.oyranos.org/wiki/index.php?title=ICC_Profiles_in_X_Specification_0.4 possibly accepting a valid xrandr output name. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737980: Wired/wireless pointless switching
Package: wicd Version: 1.7.2.4-4.1 Severity: minor I have both wireless and wired connections. I have always switch to wired connection when available and automatically reconnect on network connection loss set. If I turn on the laptop with the cable plugged in, wicd first connects to a known wireless network which was set to automatically connect, *then* disconnects and reconnects again to the wired connection. Roughly takes 3 minutes to actually get an usable network. If aways switch to a wired connection is set, wicd should waste no time in trying wireless at all if a wired network can be configured. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-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 wicd depends on: ii wicd-cli [wicd-client] 1.7.2.4-4.1 ii wicd-curses [wicd-client] 1.7.2.4-4.1 ii wicd-daemon1.7.2.4-4.1 ii wicd-gtk [wicd-client] 1.7.2.4-4.1 wicd recommends no packages. wicd suggests no packages. Versions of packages wicd-cli depends on: ii python 2.7.5-5 ii wicd-daemon 1.7.2.4-4.1 Versions of packages wicd-cli recommends: ii sudo 1.8.9p5-1 Versions of packages wicd-gtk depends on: ii python 2.7.5-5 ii python-glade2 2.24.0-3+b1 ii python-gtk22.24.0-3+b1 ii wicd-daemon1.7.2.4-4.1 Versions of packages wicd-gtk recommends: ii gksu 2.0.2-6 ii python-notify 0.1.1-3 Versions of packages wicd-curses depends on: ii python2.7.5-5 ii python-urwid 1.1.1-1+b1 ii wicd-daemon 1.7.2.4-4.1 Versions of packages wicd-curses recommends: ii sudo 1.8.9p5-1 Versions of packages wicd-daemon depends on: ii adduser 3.113+nmu3 ii dbus 1.8.0-1 ii debconf 1.5.52 ii dhcpcd 2:1.0.0 ii ethtool 1:3.13-1 ii iproute 1:3.12.0-1 ii iputils-ping 3:20121221-5 ii isc-dhcp-client 4.2.4-7 ii lsb-base 4.1+Debian12 ii net-tools1.60-25 ii psmisc 22.20-1 ii python 2.7.5-5 ii python-dbus 1.2.0-2+b1 ii python-gobject 3.10.2-2 ii python-wicd 1.7.2.4-4.1 ii wireless-tools 30~pre9-8 ii wpasupplicant1.0-3.1 Versions of packages wicd-daemon recommends: ii rfkill 0.5-1 ii wicd-cli [wicd-client] 1.7.2.4-4.1 ii wicd-curses [wicd-client] 1.7.2.4-4.1 ii wicd-gtk [wicd-client] 1.7.2.4-4.1 Versions of packages wicd-daemon suggests: ii pm-utils 1.4.1-13 Versions of packages python-wicd depends on: ii python 2.7.5-5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738112: No support for XRandR
Package: xcalib Version: 0.8.dfsg1-2 Severity: normal I'm using an Intel HD4000 with Xorg, which supports XRandR. Multiple displays are correctly recognized by xrandr-aware applications, but not by xcalib. As a result I can only manipulate the first display/output using xcalib. For a laptop, this is pretty limiting. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737046: RFS: entr/2.6-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package entr * Package name: entr Version : 2.6-1 Upstream Author : Eric Radman ericsh...@eradman.com * URL : http://entrproject.org/ * License : ISC, BSD-2-Clause Section : misc It builds those binary packages: entr - Run arbitrary commands when files change To access further information about this package, please visit the following URL: http://mentors.debian.net/package/entr Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/e/entr/entr_2.6-1.dsc Changes since the last upload: * New upstream release. * Override build to use shared copy of strlcpy (and friends) using libbsd. * Fixes build on kFreeBSD. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516489: pinentry-gtk2 should treat pressing the escape key as cancel
Package: pinentry-gtk2 Version: 0.8.3-1 Followup-For: Bug #516489 Is there any chance to integrate the patch that I have provided? I received no response from upstream, but I cannot really follow the development. Maybe the maintainer would have some more attention in pinging the developers? Thanks a lot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735538: Should suggest portaudio19-doc
Package: portaudio19-dev Version: 19+svn2021-2 Severity: wishlist It would be nice if portaudio19-dev could Suggest portaudio19-doc. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735541: Should suggest libfftw3-doc
Package: libfftw3-dev Version: 3.3.3-7 Severity: wishlist It would be nice if libfftw3-dev would Suggest: libfftw3-doc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735542: Should Suggest: python-pyparsing-doc
Package: python-pyparsing Version: 2.0.1+dfsg1-1 Severity: wishlist It would be nice if the package would Suggest: python-pyparsing-doc -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-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 python-pyparsing depends on: ii python 2.7.5-5 python-pyparsing recommends no packages. python-pyparsing suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735545: Should also Suggest: gmp-doc
Package: libgmp-dev Version: 2:5.1.3+dfsg-1 Severity: wishlist The info documentation of GNU MP is located in gmp-doc. It would be nice if gmp-doc was also suggested by libgmp-dev. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735156: Does not use desktop notifications anymore
Package: icedove Version: 24.2.0-1 Severity: whishlist It seems like Icedove 24 cannot use desktop notifications for new mail anymore (17.* could). The configurable alert shows only the thunderbird popup. Needless to say, it would be nice if proper desktop notification integration could be restored. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733767: RFS: entr/2.5-1 [ITP] -- Run arbitrary commands when files change
Package: sponsorship-requests Severity: whishlist Dear mentors, I am looking for a sponsor for my package entr: * Package name: entr Version : 2.5 Upstream Author : Eric Radman ericsh...@eradman.com * URL : http://entrproject.org/ * License : ISC, BSD-3-Clause, BSD-2-Clause Programming Lang: C Description : Run arbitrary commands when files change It builds those binary packages: entr - Run arbitrary commands when files change To access further information about this package, please visit the following URL: http://mentors.debian.net/package/entr The Event Notify Test Runner (entr) runs arbitrary commands when files change. Changes are detected through the kqueue/inotify kernel interface. For the prospective sponsor/reviewer: entr is a nice, portable (runs both on BSD an Linux), zero-configuration alternative to iwatch, inotify-tools or fileschanged. entr is a simple single-binary package, is properly documented and includes a small test suite. The package source is maintained through git, and publicly available: https://github.com/wavexx/debian-entr/ Upstream is very responsive. Release 2.4 and 2.5 address minor packaging concerns I had. I also use entr on a daily basis. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733563: ITP: entr -- Run arbitrary commands when files change
Package: wnpp Severity: wishlist Owner: Yuri D'Elia wav...@thregr.org * Package name: entr Version : 2.5 Upstream Author : Eric Radman ericsh...@eradman.com * URL : http://entrproject.org/ * License : ISC, BSD-3-Clause, BSD-2-Clause Programming Lang: C Description : Run arbitrary commands when files change The Event Notify Test Runner (entr) runs arbitrary commands when files change. Changes are detected through the kqueue/inotify kernel interface. For Debian: entr is a nice, portable (runs both on BSD an Linux), zero-configuration alternative to iwatch, inotify-tools or fileschanged. entr is a simple single-binary package, is properly documented and includes a small test suite. The package is already available: https://github.com/wavexx/debian-entr/ Upstream is very responsive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733161: Requires different import for updated python-pil
Package: rest2web
Version: 0.5.2~alpha+svn-r248-2
Severity: minor
Tags: patch
The gallery plugin of rest2web requires python-imaging. python-imaging
though is being replaced by python-pil, which is recommended already by
python-docutils.
For this, the Image import needs to be updated (see the attached patch).
I would also suggest to add a direct Recommend: python-pil to the
dependencies of rest2web.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.4.3-kvm-i386-20120618
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 rest2web depends on:
ii python 2.7.5-5
ii python-docutils 0.11-3
ii python-support 1.0.15
rest2web recommends no packages.
Versions of packages rest2web suggests:
ii rest2web-doc 0.5.2~alpha+svn-r248-2
--- gallery.py.Orig 2013-12-26 16:33:17.0 +0100
+++ gallery.py 2013-12-26 16:33:30.0 +0100
@@ -36,7 +36,7 @@
# image imports
try:
-import Image
+from PIL import Image
except ImportError:
raise ImportError('Importing PIL - Python Imaging Library - failed.')
Bug#732146: Incompatibile with the latest dovecot-imapd
Package: dovecot-antispam Severity: important Dovecot was recently updated to 2.2.9, and dovecot-antispam cannot be installed anymore. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727217: libusbx debug noise
Package: gphoto2 Version: 2.4.14-1 Severity: normal I'm getting a ton of libusbx debug output when invoking gphoto2: $ gphoto2 -L libusbx: debug [libusb_get_device_list] libusbx: debug [discovered_devs_append] need to increase capacity libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_exit] libusbx: debug [libusb_exit] destroying default context libusbx: debug [libusb_get_device_list] libusbx: debug [discovered_devs_append] need to increase capacity libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [parse_configuration] skipping descriptor 0xb libusbx: debug [parse_endpoint] skipping descriptor 25 libusbx: debug [libusb_exit] libusbx: debug [libusb_exit] destroying default context libusbx: debug [libusb_get_device_list] libusbx: debug [discovered_devs_append] need to increase capacity libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_device_descriptor] libusbx: debug [libusb_get_config_descriptor] index 0 libusbx: debug [libusb_exit] libusbx: debug [libusb_exit] destroying default context There is no file in folder '/'. The manual page states something about the --debug flag or USB_DEBUG environment variable, neither of which I'm using. Using --debug-logfile doesn't redirect it either. The level of noise is so high that makes the command unuseable. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-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 gphoto2 depends on: ii libc6 2.17-93 ii libcdk5 5.0.20060507-4 ii libexif12 0.6.21-1 ii libgphoto2-2 2.4.14-2.3 ii libgphoto2-port0 2.4.14-2.3 ii libncurses5 5.9+20130608-1 ii libpopt0 1.16-7 ii libreadline6 6.2+dfsg-0.1 gphoto2 recommends no packages. Versions of packages gphoto2 suggests: pn gthumb none pn gtkam 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#727219: smbnetfs mountpoints incorrectly listead as a device
Package: gphoto2 Version: 2.4.14-1 Severity: normal I'm using smbnetfs FUSE driver to access some SMB mountpoints. gphoto2 thinks it's a camera: $ gphoto2 --list-ports Devices found: 9 Path Description -- disk:/net/ Media 'smbnetfs' ptpip: PTP/IP Connection serial:/dev/ttyS0Serial Port 0 serial:/dev/ttyS1Serial Port 1 serial:/dev/ttyS2Serial Port 2 serial:/dev/ttyS3Serial Port 3 usb:004,003 Universal Serial Bus usb:003,004 Universal Serial Bus usb:003,003 Universal Serial Bus Moreover, it's the first detected device, so simply using gphoto2/gphotofs without --ports will not work. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-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 gphoto2 depends on: ii libc6 2.17-93 ii libcdk5 5.0.20060507-4 ii libexif12 0.6.21-1 ii libgphoto2-2 2.4.14-2.3 ii libgphoto2-port0 2.4.14-2.3 ii libncurses5 5.9+20130608-1 ii libpopt0 1.16-7 ii libreadline6 6.2+dfsg-0.1 gphoto2 recommends no packages. Versions of packages gphoto2 suggests: pn gthumb none pn gtkam 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#727220: just crashes in libusb
Package: gphoto2 Version: 2.4.14-1 Severity: normal I cannot use gphoto2 in unstable. Everything I do results in a crash. $ gphoto2 --list-ports Devices found: 10 Path Description -- ptpip: PTP/IP Connection serial:/dev/ttyS0Serial Port 0 serial:/dev/ttyS1Serial Port 1 serial:/dev/ttyS2Serial Port 2 serial:/dev/ttyS3Serial Port 3 usb:004,003 Universal Serial Bus usb:003,004 Universal Serial Bus usb:003,003 Universal Serial Bus usb:001,008 Universal Serial Bus $ lsusb -s 1:8 Bus 001 Device 008: ID 04a9:3245 Canon, Inc. PowerShot SX240 HS (watch out for huge libusbx noise following) $ gphoto2 --port usb:001,008 -L libusbx: debug [libusb_init] libusbx v1.0.17.10830 libusbx: debug [find_usbfs_path] found usbfs at /dev/bus/usb libusbx: debug [op_init] bulk continuation flag supported libusbx: debug [op_init] zero length packet flag supported libusbx: debug [op_init] sysfs can relate devices libusbx: debug [op_init] sysfs has complete descriptors libusbx: debug [linux_get_device_address] getting address for device: usb1 detached: 0 libusbx: debug [linux_get_device_address] scan usb1 libusbx: debug [linux_get_device_address] bus=1 dev=1 libusbx: debug [linux_enumerate_device] busnum 1 devaddr 1 session_id 257 libusbx: debug [linux_enumerate_device] allocating new device for 1/1 (session 257) libusbx: debug [linux_get_device_address] getting address for device: 1-2 detached: 0 libusbx: debug [linux_get_device_address] scan 1-2 libusbx: debug [linux_get_device_address] bus=1 dev=8 libusbx: debug [linux_enumerate_device] busnum 1 devaddr 8 session_id 264 libusbx: debug [linux_enumerate_device] allocating new device for 1/8 (session 264) libusbx: debug [linux_get_parent_info] Dev 0x10a0f90 (1-2) has parent 0x10a0ed0 (usb1) port 2 libusbx: debug [linux_get_device_address] getting address for device: 1-3 detached: 0 libusbx: debug [linux_get_device_address] scan 1-3 libusbx: debug [linux_get_device_address] bus=1 dev=2 libusbx: debug [linux_enumerate_device] busnum 1 devaddr 2 session_id 258 libusbx: debug [linux_enumerate_device] allocating new device for 1/2 (session 258) libusbx: debug [linux_get_parent_info] Dev 0x10a1050 (1-3) has parent 0x10a0ed0 (usb1) port 3 libusbx: debug [linux_get_device_address] getting address for device: 1-3.1 detached: 0 libusbx: debug [linux_get_device_address] scan 1-3.1 libusbx: debug [linux_get_device_address] bus=1 dev=3 libusbx: debug [linux_enumerate_device] busnum 1 devaddr 3 session_id 259 libusbx: debug [linux_enumerate_device] allocating new device for 1/3 (session 259) libusbx: debug [linux_get_parent_info] Dev 0x10a1a10 (1-3.1) has parent 0x10a1050 (1-3) port 1 libusbx: debug [linux_get_device_address] getting address for device: 1-3.1.2 detached: 0 libusbx: debug [linux_get_device_address] scan 1-3.1.2 libusbx: debug [linux_get_device_address] bus=1 dev=5 libusbx: debug [linux_enumerate_device] busnum 1 devaddr 5 session_id 261 libusbx: debug [linux_enumerate_device] allocating new device for 1/5 (session 261) libusbx: debug [linux_get_parent_info] Dev 0x10a1ad0 (1-3.1.2) has parent 0x10a1a10 (1-3.1) port 2 libusbx: debug [linux_get_device_address] getting address for device: 1-3.2 detached: 0 libusbx: debug [linux_get_device_address] scan 1-3.2 libusbx: debug [linux_get_device_address] bus=1 dev=4 libusbx: debug [linux_enumerate_device] busnum 1 devaddr 4 session_id 260 libusbx: debug [linux_enumerate_device] allocating new device for 1/4 (session 260) libusbx: debug [linux_get_parent_info] Dev 0x10a2cd0 (1-3.2) has parent 0x10a1050 (1-3) port 2 libusbx: debug [linux_get_device_address] getting address for device: usb2 detached: 0 libusbx: debug [linux_get_device_address] scan usb2 libusbx: debug [linux_get_device_address] bus=2 dev=1 libusbx: debug [linux_enumerate_device] busnum 2 devaddr 1 session_id 513 libusbx: debug [linux_enumerate_device] allocating new device for 2/1 (session 513) libusbx: debug [linux_get_device_address] getting address for device: usb3 detached: 0 libusbx: debug [linux_get_device_address] scan usb3 libusbx: debug [linux_get_device_address] bus=3 dev=1 libusbx: debug [linux_enumerate_device] busnum 3 devaddr 1 session_id 769 libusbx: debug [linux_enumerate_device] allocating new device for 3/1 (session 769) libusbx: debug [linux_get_device_address] getting address for device: 3-1 detached: 0 libusbx: debug [linux_get_device_address] scan 3-1 libusbx: debug [linux_get_device_address] bus=3 dev=2 libusbx: debug [linux_enumerate_device] busnum 3 devaddr 2 session_id 770 libusbx: debug
Bug#727221: Debug noise
Package: libusb-1.0-0 Version: 2:1.0.17-1+b1 Severity: normal Any application linked with libusb outputs tons of debugging output to the terminal. Using CLI applications like gphoto2 is hell. I was thinking gphoto2 was at fault here, but then I realized all applications linked with libusb were doing the same. The gphoto2 manual page states something about the USB_DEBUG environment variable for controlling libusb debug, which is unset. Setting it to any value though doesn't have any effect either. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-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 libusb-1.0-0 depends on: ii libc6 2.17-93 ii libudev1 204-5 ii multiarch-support 2.17-93 libusb-1.0-0 recommends no packages. libusb-1.0-0 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#727217: debug noise
I filed another bug against libusb-1.0-1: #727221 Since I discovered other applications linked to libusb-1.0 have the same issue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687299: Please compile using --without-gsettings
On 09/25/2013 08:08 PM, Rob Browning wrote: Yuri D'Elia wav...@thregr.org writes: emacs24-lucid will still try to honour gsettings if built without --without-gsettings, most notably it will ignore common X11 resources such as the font. Hmm. I'm using emacs24-lucid, and I have my fonts set in .Xresources. That doesn't work for you? (Just want to try to make sure I understand the problem.) I was able to debug the problem in the emacs ML, and fixed it. Indeed, with emacs24-lucid I don't have this problem. Sorry for leaving this report open. :/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687299: Please compile using --without-gsettings
On 09/26/2013 04:45 PM, Rob Browning wrote: Yuri D'Elia wav...@thregr.org writes: I was able to debug the problem in the emacs ML, and fixed it. Indeed, with emacs24-lucid I don't have this problem. Sorry for leaving this report open. :/ No problem -- and how do you feel about the other report, or more to the point, did your discussions with upstream leave you feeling like --without-gsettings was still desirable for the lucid and nox builds? I was using the gtk build before (as gtk widgets are definitely nicer than lucid), but more and more gtk means gnome nowdays, so I switched. Since I only see widgets for the customize interface (as I hide every gui element anyway), I'm actually happier with the lucid build. I don't use gnome. I mostly use vanilla GTK and (increasingly) QT apps when I have to. I literally have no idea how to set gsettings without installing half of the gnome desktop. I'm certainly not going to use any of these graphical tools to customize *emacs*. Frankly, I don't see any benefit for gsettings in the lucid build. If you don't have gnome and some application sets font settings for you, good luck finding the right key/value with gconf. fontconfig support with the lucid build is excellent, and Xresources have very nice cascading properties that also apply to lucid widgets. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721818: Should allow to install/remove packages even when dependencies are broken
Package: aptitude Version: 0.6.8.2-1.2 Severity: normal There is no way currently to proceed to package (re)installation/remove/purge if dependencies are broken. Pressing 'g' only shows the dependency resolution prompt. When using unstable/experimental I sometimes *need* to break dependencies. I'd like to have something akin to the Yes, I am aware this is a very bad idea prompt and/or an option to proceed when I'm already in preview and I'm pressing g again. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721818: [Aptitude-devel] Bug#721818: Should allow to install/remove packages even when dependencies are broken
On 09/04/2013 01:04 PM, Axel Beckert wrote: Huh? I use aptitude on a lot of Sid/Experimental machines daily and I need that only in very, very seldom cases. And if so, it's usually easily to solve with a dpkg --remove --force-depends before running aptitude at all. I also need it very rarely. But right now I want to install a newer version of a package and break some other dependencies (without uninstalling them as aptitude recommends). I dropped to dpkg in the past, but in some situations it's just way easier to use aptitude. But since aptitude saves your current state of planned actions (unless you quit it with Ctrl-C), it's easy to call dpkg --remove --force-depends without losing your planned actions. Does running dpkg --force-depends keep the auto state of the packages in this case? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721818: [Aptitude-devel] Bug#721818: Should allow to install/remove packages even when dependencies are broken
On 09/04/2013 01:40 PM, David Kalnischkies wrote: On Wed, Sep 4, 2013 at 12:49 PM, Yuri D'Elia yuri.de...@eurac.edu wrote: When using unstable/experimental I sometimes *need* to break dependencies. No. Even in unstable/experimental there is no reason to have a broken system. If there is it is a glaring bug in the packages which require it and its a feature that these packages are not installable and/or removed. I am an unstable users myself for years and never had the need to break the system. Either the package manager can work out a valid solution or I wait 6 hours for the next dinstall run to bring in a valid solution. Everything else is not worth the pain. It depends (see my previous answer to Axel). Waiting for a package to get rebuilt against a new library (think about -dev packages) sometimes takes time. Sometimes days. If I need the new package, I'd rather force the installation and deal with the broken dependencies (that I don't care about) later. Upgrading systems is already very similar to juggling chainsaws, I don't see what we would gain by switch them on. Very funny analogy btw :P So from an APT point of view: Hell no, wontfix, close. But this bugreport is against aptitude, so feel free to disagree of course. I absolutely agree it's not important. I needed that very few times. The last time was maybe last year, on a system with had broken dependencies after a dist-upgrade and aptitude failed to find any solution and/or refused to accept any change I made. With a lot of packages, using apt manually was a major pain. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721744: [Pkg-xfce-devel] Bug#721744: Pollutes home with .Xauthority.* files (with bad permissions)
On 09/04/2013 09:35 PM, Yves-Alexis Perez wrote: I don't have .Xauthority files polluting my homedir so I'm not sure what happens to you, but the 0644 perms indeed don't look too good. A quick test revealed that those .Xauthority.* files are created when the machine is shutdown (via halt, or acpi power button event) and then brought up again. I assume that lightdm tries to make backup copies when .Xauthority is already present. It should try to query the X server for validity instead and zap the file. I had around 50 files or so in my home directory. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721744: [Pkg-xfce-devel] Bug#721744: Pollutes home with .Xauthority.* files (with bad permissions)
On 09/04/2013 09:46 PM, Yuri D'Elia wrote: On 09/04/2013 09:35 PM, Yves-Alexis Perez wrote: I don't have .Xauthority files polluting my homedir so I'm not sure what happens to you, but the 0644 perms indeed don't look too good. A quick test revealed that those .Xauthority.* files are created when the machine is shutdown (via halt, or acpi power button event) and then brought up again. I should add that I'm using systemd, which might affect how the X session is brought down. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721744: Pollutes home with .Xauthority.* files (with bad permissions)
Package: lightdm Version: 1.6.0-3 Severity: important I noticed this issue a couple of months ago. lightdm likes to create (backup?) copies of .Xauthority files for some reason. I never paid attention to the dynamics, but I have a dozen .Xauthority.* files in my ~ which look like stale cookies and/or temporary files created by mkstemp(2) or a similar function. Moreover, all these files, *including* the current .Xauthority file are created 0644, which is a (grave) security issue by itself. This effect also seems to be reported in ubuntu, with no action: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1175023 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii consolekit 0.4.5-3.1 ii dbus 1.6.12-1 ii debconf [debconf-2.0] 1.5.51 ii libc6 2.17-92+b1 ii libgcrypt111.5.3-2 ii libglib2.0-0 2.36.4-1 ii libpam0g 1.1.3-9 ii libxcb11.9.1-3 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter [lightdm-greeter] 1.6.0-1 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+3 Versions of packages lightdm suggests: pn accountsservice none pn upower none -- debconf information: lightdm/daemon_name: /usr/sbin/lightdm * shared/default-x-display-manager: lightdm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670132: Happens when the session is closed
On 08/05/2013 05:08 PM, Nicolas François wrote: Hello Yuri, Could you try with the attached patch. su is catching the TERM signals so that it can transfer them to its child. At this point in time, su already decided that the child has to be terminated. So su can finish the child cleanup before closing the PAM session. It still seems strange that systemd sends TERM signals. This assumes that the tool has a TERM handler or has finished its cleanup when it closes the PAM session. I have systemd + libpam-systemd from sid (whereas I had upstart at the time), but I cannot reproduce the problem anymore. I switched back to sysvinit for a while (I had too many problems with upstart in general), and when I went back to try systemd 2/3 months ago I never noticed the message again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718257: Use the current timezone by default
Package: gpscorrelate Version: 1.6.1-4 Severity: wishlist It would be nice if gpscorrelate would actually make use of the current timezone for correlating photos instead of defaulting to '0'. All cameras that I used write the time in the local timezone, and even the manpage seems to suggest that -z should basically always be used. I'm currently using the following alias: gpscorrelate -z $(date +%::z) but it feels like unnecessary burden. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714880: inline references are not resolved
On 07/03/2013 10:03 PM, Jakub Wilk wrote: But it doesn't work. bug.rst produces a bogus link to b_ using rst2html. The page you quoted says that this syntax works only since Docutils 0.11. So it's expected that it doesn't work yet. Hah.. oh well. Thanks for noticing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714880: inline references are not resolved
Package: python-docutils Version: 0.10-3 Severity: minor See the attached test case, pasted here for reference: `a b_`_ ... _b: http://example.com/ `a b_`_ is an inline reference to b_, which is an external reference to http://example.com/. The purpose of this concoction is to have a link while changing its anchor text. Example: `a link to python_`_. ... _python: http://www.python.org/ Which should produce a link to http://www.python.org/;. This is actually documented in the RST reference: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#embedded-uris-and-aliases But it doesn't work. bug.rst produces a bogus link to b_ using rst2html. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-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 python-docutils depends on: ii docutils-common 0.10-3 ii python 2.7.5-2 ii python-roman 1.4.0-2 ii python-support 1.0.15 -- no debconf information `a b_`_ b_ ... _b: c
Bug#714880: Acknowledgement (inline references are not resolved)
Wrong number of dots in my example. Attaching a new test. `a b_`_ b_ .. _b: c
Bug#714448: Improve dependencies
Package: roundcube Version: 0.9.2-1 Severity: whishlist Could you downgrade the php5-gd and php5-pspell packages from Depends to Recommends? Both gd and pspell are not hard requirements for roundcube (depending on your configuration file). In fact, I've been running without them through an equivs package for quite a while. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712997: Move/Drag panel not dragging
On 06/24/2013 11:45 AM, Yuri D'Elia wrote: On 06/23/2013 08:11 AM, Andreas Metzler wrote: I downgraded hugin/hugin-data/hugin-tools together (hopefully this feature doesn't depend on external libs?). I have a couple of other hugin installations that I don't use regularly, I'll check on those and let you know. Ok, I tried on another box, and 2011.4 works as expected. Literally no idea why. Could that be a GL driver bug? On this particular box I have an hd4000, whereas on the working machine I have an nvidia card. I do have this on the console: ERROR: 11:50:48.468061 (/build/hugin-vgSB2_/hugin-2013.0.0~beta1+dfsg/src/hugin1/hugin/TextureManager.cpp:624) SetParameters(): GL Error when setting texture parameters: invalid operation. (noticed just now). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712997: Move/Drag panel not dragging
On 06/23/2013 08:11 AM, Andreas Metzler wrote: I downgraded hugin/hugin-data/hugin-tools together (hopefully this feature doesn't depend on external libs?). I have a couple of other hugin installations that I don't use regularly, I'll check on those and let you know. Ok, I tried on another box, and 2011.4 works as expected. Literally no idea why. Could that be a GL driver bug? On this particular box I have an hd4000, whereas on the working machine I have an nvidia card. Perhaps the local configuration broke. - You could try renaming ~/.hugin to let hugin start with its default settings. First thing I tried too. Though rotating the image through the third mouse button works (!). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712997: Move/Drag panel not dragging
Package: hugin Version: 2013.0.0~beta1+dfsg-3 Severity: normal I can't seem to be able to drag any image in the Move/Drag panel in any mode (normal, mosaic or the individual combinations). This used to work some time ago, as I used this feature regularly. Interestingly, dragging with the third mouse button instead works and rotates the image. Applying the raw/pitch manually also works. This seems to be a problem with dragging with the first mouse button only. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-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 hugin depends on: ii enblend 4.0+dfsg-5 ii enfuse4.0+dfsg-5 ii hugin-tools 2013.0.0~beta1+dfsg-3 ii libboost-signals1.53.01.53.0-5 ii libboost-system1.53.0 1.53.0-5 ii libboost-thread1.53.0 1.53.0-5 ii libc6 2.17-5 ii libexiv2-12 0.23-1 ii libgcc1 1:4.8.1-3 ii libgl1-mesa-glx [libgl1] 9.1.3-6 ii libglew1.71.7.0-3 ii libglu1-mesa [libglu1]8.0.5-7 ii libimage-exiftool-perl9.13-1 ii libpano13-2 2.9.18+dfsg-6 ii libstdc++64.8.1-3 ii libtiff4 3.9.6-11 ii libwxbase2.8-02.8.12.1-13 ii libwxgtk2.8-0 2.8.12.1-13 ii make 3.81-8.2 hugin recommends no packages. hugin 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#705607: 1.0 breaks alignment != left
Package: dunst Version: 1.0.0-1 Severity: normal In the last update, if the alignment setting is set to anything but left, the content of the notification is broken. With center, only half of the text is visible. With right no text is visible at all, and dunst sometimes enter in an endless loop (and needs to be killed). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689226: spectrwm: please package the latest version
Package: spectrwm Followup-For: Bug #689226 Is there any news on the repackaging? I'm running spectrwm 2.2.0 (hand-build) and there are *many* fixed issues that I couldn't work with. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
