Bug#716715: Still reproducible
Unfortunately, the bug is not fixed.
There is a typo in the bug report:
> This can be fixed by uncommenting the line
> ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $tempnode",
> GOTO="cdrom_end"
This should say: "This can be fixed by COMMENTING the line".
This is explained in the linked blog post.
As of udev 245.5-1, the line above is still present in
/lib/udev/rules.d/60-cdrom_id.rules , and "eject -i on" still does not
lock the eject button.
If the line is removed/commented, "eject -i on" works as expected.
I have reopened this bug. Or maybe this should be filed against udev?
It's unclear who is "at fault" here...
Bug#601135: Bug is difficult and unlikely to be fixed
Control: tag -1 + wontfix Control: severity -1 normal Gilles gave me access to an example Garmin file from a real device (thanks!). With that file, I can reproduce the problem described in this bug. It seems the current Garmin maps from Garmin use a format that has not yet been reverse-engineered, and OP most likely used such a map. It seems very unlikely that Navit will be the first to do this reverse engineering work, as this is out of scope for Navit, and rather difficult: The existing support for Garmin maps is based on an external library (libgarmin), which has seen little development during the last years. Also, the projects I could find that deal with Garmin maps focus on creating Garmin maps (often from OpenStreetMap data), not on reading original (and proprietary) Garmin maps (which, at any rate, may be illegal in some countries). I have documented this limitation in the Navit wiki under http://wiki.navit-project.org/index.php/Garmin_maps . Thus I'm tagging this bug as "wontfix". Sebastian Leske Navit developer -- -- Details of analysis -- I tried to load the file using QMapShack (installed from the Debian package). QMapShack reports that it is a "NT Format file", which QMapShack cannot read. Some googling revealed that apparently there are several variants of Garmin files. In particular, some years ago (2009?) Garmin introduced a major format change, called "NT Format". See: https://www.mail-archive.com/qlandkartegt-users@lists.sourceforge.net/msg01482.html https://forum.garmin.de/showthread.php?50375-OSM-Karten-Routing-F%E4higkeit-ausschalten In particular, in QMapShack issue #12, "Cannot import NT Format map file" someone writes: > No, sorry, I don't think there will be support of newer proprietary > maps. First the data in the gmapsupp is structured different. This is > not that much of a problem, as it is quite easy to find out. However > the coding of the elements is different, too. And so far no one > started to reverse engineer that part. Reverse engineering stopped at > the point where the community could create own maps. ( https://bitbucket.org/maproom/qmapshack/issues/12/cannot-import-nt-format-map-file ) I also could not find any library/program that claims to read "NT Format" Garmin files (apparently there are "pseudo-NT" files, which can be read, but Garmin themselves produce "true" NT Files, which are different).
Bug#784500: Qt GUI of Navit can be removed
Hi, the Qt graphics plugin in Navit is currently unmaintained, so it's probably best to drop it from the Debian package - it's barely usable at the moment. Once it starts being maintained, it will probably be migrated to Qt 5. Greetings Sebastian Leske P.S. You forwarded this bug to the GitHub issue tracker, which was only enabled temporarily by mistake. Navit bugs should be reported to http://trac.navit-project.org/ . Thanks!
Bug#601135: Cannot be fixed without an example file
Hi, thanks for bringing up this bug report. Unfortunately, I think as it stands this bug will need to be closed as unreproducible. Without having the file the bug reporter used, it's next to impossible to tell what the problem was - in particular because there are different versions / variations of the Garmin file format. To test Navit's Garmin map driver, I just randomly grabbed a Garmin map file off the Internet - I used the file from http://www.miscjunk.org/mj/mp_mnohv.html , specifically http://www.miscjunk.org/mj/downloads/mnohv_install.exe . Running it (e.g. with wine) produces a file 8801.img , which can be loaded as a Navit map (map entry with type="garmin", enabled="yes", data="/path/to/8801.img"). Then moving to coordinates 47.4874N 92.4679W shows the streets of Gilbert, Minnesota. So the Garmin map driver (still) works in principle. Thus without a reproducible test case (including a map file), I propose to close this bug. Greetings Sebastian Leske
Bug#643294: Seems fixed in 2.8.12.2
On my system (Debian jessie), I cannot reproduce this bug (using the test case) with CMake 2.8.11 and 2.8.12. I can reproduce it with an older CMake. So it looks like this was fixed at some point between 2.8.5 and 2.8.11. Can this bug be closed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738642: Fixed using python-lxml 3.2.0-1+b1
Confirmed with calibre 1.22.0+dfsg1-1. Updating python-lxml to 3.2.0-1+b1 fixes the problem; converting a moderatly complex DOCX file works. So the problem really seems to be the old version of python-lxml. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736543: navit: Drop build-depends on libdevil-dev
Package: navit Version: 0.5.0~svn5126+dfsg.1-2 Severity: normal Hi, the Navit source package currently build-depends on libdevil-dev. Navit does not use libdevil, the build-depends can be dropped. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723046: navit: Drop lc_all.patch, bump libgps version requirements
Package: navit Version: 0.5.0~svn5126+dfsg.1-2 Severity: normal Tags: patch As of SVN rev. 5642, Navit requires libgps V 3.1+. Therefore, the patch lc_all.patch can be dropped, as it was a workaround for a bug in older versions of libgps. Also, the build-depends on libgps-dev will have to be bumped to =3.1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716715: eject -i fails to block eject button with current udev rules
Package: eject
Version: 2.1.5+deb1+cvs20081104-13
Severity: normal
eject -i on should lock the hardware eject button of a CD-ROM drive,
to prevent the tray from opening if the eject button is pressed.
However, this does not work on my system (Thinkpad T43, standard DVD
drive):
~# eject -i on
CD-Drive may NOT be ejected with device button
However, pressing the eject button still opens the tray.
This can be fixed by uncommenting the line
ENV{DISK_EJECT_REQUEST}==?*, RUN+=cdrom_id --eject-media $tempnode,
GOTO=cdrom_end
in /lib/udev/rules.d/60-cdrom_id.rules (udev version 175-7.2).
(Source:
http://www.poweradded.net/2009/09/cddvd-tray-lockunlock-under-linux.html )
Apparently, udev and eject somehow conflict.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages eject depends on:
ii libc62.17-3 Embedded GNU C Library: Shared lib
ii libdevmapper1.02.1 2:1.02.48-2 The Linux Kernel Device Mapper use
eject recommends no packages.
Versions of packages eject suggests:
pn cdtoolnone (no description available)
pn setcd none (no description available)
-- 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#690809: navit: Patches qt-cmake.patch and qt-qpainter-missing-symbol.patch can be dropped
Package: navit Version: 0.5.0~svn5126+dfsg.1-2 Severity: normal The Debian patches qt-cmake.patch and qt-qpainter-missing-symbol.patch can be dropped: qt-cmake.patch: CMake configuration of Qt was corrected upstream in Subversion rev. 5251, and should now work without a patch. qt-qpainter-missing-symbol.patch: The problem was corrected upstream in rev. 5235 (the patch is different, but it also fixes the problem). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565225: Not sure I can help
Hi, thanks for picking up this old issue. I'm afraid I can't say much more than what I wrote in my comments - that's really all I know about this. However, feel free to ask for help if I can help with implementing / testing - I'll try to help where I can. Greetings, SL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637932: Seems fixed in 4.42-1
Update: With version 3:4.42-1 of stunnel4, the error no longer occurs. Now I get a message about the cert being unreadable, as expected: LOG3[25485:3077458800]: error queue: : error:20074002:BIO routines:FILE_CTRL:system lib LOG3[25485:3077458800]: SSL_connect: 200100D: error:0200100D:system library:fopen:Permission denied Maybe this was fixed as part of the heap vulnerability fix (see #638758). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637932: stunnel4: segfault if certificate file cannot be read during verification
Package: stunnel4 Version: 3:4.40-1 Severity: normal I use certificate verification with stunnel4 (verify=2 in stunnel.conf). I accidentally changed the access rights of a PEM file required for verification to be unreadable. As a consequence, stunnel4 incorrectly reports Verification error: self signed certificateVerification error: self signed certificate (the cert in question is not self-signed), then segfaults. With stunnel4 version 4.29-1_i386, this does not occur: stunnel4 correctly reports that it cannot access the PEM file. Log and backtrace (generated with setting foreground=yes in stunnel.conf): Starting program: /usr/bin/stunnel4 /etc/stunnel/stunnel.conf [Thread debugging using libthread_db enabled] 2011.08.15 21:16:54 LOG5[9584:3082946768]: stunnel 4.40 on i486-pc-linux-gnu platform 2011.08.15 21:16:54 LOG5[9584:3082946768]: Compiled/running with OpenSSL 1.0.0d 8 Feb 2011 2011.08.15 21:16:54 LOG5[9584:3082946768]: Threading:PTHREAD SSL:ENGINE Auth:LIBWRAP Sockets:POLL,IPv6 2011.08.15 21:16:54 LOG5[9584:3082946768]: Reading configuration from file /etc/stunnel/stunnel.conf 2011.08.15 21:16:54 LOG6[9584:3082946768]: Compression enabled using zlib method 2011.08.15 21:16:54 LOG6[9584:3082946768]: Initializing SSL context for service pop3sl 2011.08.15 21:16:54 LOG6[9584:3082946768]: SSL context initialized 2011.08.15 21:16:54 LOG6[9584:3082946768]: Initializing SSL context for service https 2011.08.15 21:16:54 LOG6[9584:3082946768]: SSL context initialized 2011.08.15 21:16:54 LOG6[9584:3082946768]: Initializing SSL context for service ssmtp 2011.08.15 21:16:54 LOG6[9584:3082946768]: SSL context initialized 2011.08.15 21:16:54 LOG5[9584:3082946768]: Configuration successful [New Thread 0xb7fdfb70 (LWP 9593)] 2011.08.15 21:16:57 LOG5[9584:3086875504]: Service pop3sl accepted connection from 127.0.0.1:60903 2011.08.15 21:16:57 LOG6[9584:3086875504]: connect_blocking: connecting 213.187.93.221:995 2011.08.15 21:16:57 LOG5[9584:3086875504]: connect_blocking: connected 213.187.93.221:995 2011.08.15 21:16:57 LOG5[9584:3086875504]: Service pop3sl connected remote server from 192.168.1.101:39914 2011.08.15 21:16:57 LOG4[9584:3086875504]: CERT: Verification error: self signed certificate in certificate chain 2011.08.15 21:16:57 LOG4[9584:3086875504]: Certificate check failed: depth=2, /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA 2011.08.15 21:16:57 LOG3[9584:3086875504]: error queue: 14090086: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7fdfb70 (LWP 9593)] 0xb7ca2119 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 (gdb) bt #0 0xb7ca2119 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #1 0xb7ca3c1b in calloc () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0x0804cd20 in ?? () #3 0x080574bf in ?? () #4 0x08057529 in ?? () #5 0x08058129 in ?? () #6 0x0804d945 in ?? () #7 0x0804e79b in ?? () #8 0x0804fafe in ?? () #9 0xb7f98c39 in start_thread () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #10 0xb7d0196e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 (gdb) -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages stunnel4 depends on: ii adduser 3.110 add and remove users and groups ii libc6 2.13-10Embedded GNU C Library: Shared lib ii libssl1.0.0 1.0.0d-3 SSL shared libraries ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra ii netbase 4.34 Basic TCP/IP networking system ii openssl 1.0.0d-3 Secure Socket Layer (SSL) binary a ii perl-modules 5.12.4-2 Core Perl modules stunnel4 recommends no packages. Versions of packages stunnel4 suggests: pn logcheck-database none (no description available) -- 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#630566: Fixed in linux-image-3.0.0
With kernel 2.6.39-2, I can replicate the problems described here (i.e. hciconfig up reports error Invalid argument (22)). With kernel 2.6.32-5, this used to work. With kernel 3.0.0-1 (package linux-image-3.0.0-1-686-pae, version 3.0.0-1), it works again. So the bug appears to have been fixed in 3.0.0-1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565225: Resume device should be detected when creating initramfs, or not at all
Hi,
I got bitten by this bug as well, similarly to Michael Conner above:
I installed uswsusp to be able to hibernate/resume.
s2disk worked flawlessly, but on booting the system simply did not
bother to resume, booting normally instead.
My analysis:
After digging through the initramfs scripts, I discovered that this is
because on booting resume is only triggered if $resume is set.
As far as I understand, the initramfs takes $resume from the kernel
command line (if set), and from /etc/initramfs-tools/conf.d/resume
otherwise.
In my case /etc/initramfs-tools/conf.d/resume did not exist.
It should have been created by the preinst of initramfs-tools; however
the preinst ( /var/lib/dpkg/info/initramfs-tools.preinst ) uses vol_id:
---snip
# First time install. Can we autodetect the RESUME partition?
if [ -r /proc/swaps ]; then
RESUME=$(tail -n $(($(wc -l /proc/swaps | awk ' { print
$1 } ') - 1)) /proc/swaps | sort -rk3 | head -n 1 | awk ' { print $1 } ')
if command -v vol_id /dev/null 21; then
UUID=$(vol_id -u $RESUME || true)
elif [ -x /lib/udev/vol_id ]; then
UUID=$(/lib/udev/vol_id -u $RESUME || true)
fi
if [ -n $UUID ]; then
RESUME=UUID=$UUID
fi
fi
---snap---
This will always fail, because vol_id is no longer part of Debian (it was
removed from udev for version 146-1, see
/usr/share/doc/udev/changelog.Debian.gz ).
In summary:
* Resume from hibernation will only work if /etc/initramfs-tools/conf.d/resume
sets RESUME
* However, there is no (working) code to write
/etc/initramfs-tools/conf.d/resume, and no documentation explaining that it
needs to be set manually to make resume work
Thus, resume will probably fail to work in most cases.
I believe there are actually several bugs here:
1) The code in the preinst of initramfs-tools to detect the swap partition does
not work, because it uses vol_id.
2) Even if 1) were fixed, there may be cases where the swap partition is
incorrectly detected at installation time, or later changes. So fixing
preinst is not enough.
I agree with bug submitter jidanni that the swap partition should be detected
when building the initramfs, not during preinst.
3) Additionally, I don't quite understand why uswsusp refuses to resume if
$resume is not set (in
/usr/share/initramfs-tools/scripts/local-premount/uswsusp ).
The script does not actually use the value of $resume, it just aborts if it
is not set :-(.
I guess this could be considered a bug in uswsusp; I can report it against
uswsusp if discussion of this bug indicates that this makes sense.
To fix this, I would propose the following:
* Drop the code in initramfs-tools.preinst which tries to write RESUME to
/etc/initramfs-tools/conf.d/resume , which does not work anyway.
* Document (e.g. in /usr/share/doc/initramfs-tools/README.Debian ) that
/etc/initramfs-tools/conf.d/resume can be used to set the resume device.
* When building the initramfs, use the value from
/etc/initramfs-tools/conf.d/resume
if it exists; otherwise try to find it yourself:
- if /etc/uswsusp.conf exists, it probably makes sense to read it (resume
device =)
- otherwise grab the current swap device (the config script from uswsusp
already has code for that)
This is still problematic if there is 1 swap device. Even better probably
would be to use debconf to prompt for the resume device, if this is
practical...
I am willing to help implement / test this, but first I'll wait for some
feedback if I'm even on the right track :-).
Greetings,
S.Leske
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593295: icewm-common: README.Debian does not mention /usr/share/icewm/preferences
Package: icewm-common Version: 1.3.7~pre2-1 Severity: minor Tags: patch icewm has loads of preference settings. Debian helpfully includes the file /usr/share/icewm/preferences in package icewm-common, which lists all preference settings with explanations. Unfortunately, I could not find any mention of this file in the documentation, making it rather hard to find. I therefore propose to add a new paragraph to README.Debian.gz (probably near the top). Proposal for text: ---snip--- Configuration - IceWM is configured using several text files (mainly: preferences, keys, toolbar, menu and winoptions). These files can be placed under ~/.icewm/ (personal configuration) or /etc/X11/icewm/ (system-wide configuration). A file under ~/.icewm/ will override the corresponding file under /etc/X11/icewm/. Sample configuration files with comments are provided under /usr/share/icewm/. Just copy the files there to ~/.icewm/ or /etc/X11/icewm/ and edit as required. Note that many settings are commented out in the sample files (using a leading #). ---snap--- -- System Information: Debian Release: 5.0.2 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash icewm-common depends on no packages. Versions of packages icewm-common recommends: ii menu 2.1.41 generates programs menu for all me Versions of packages icewm-common suggests: pn grun none (no description available) pn iceme none (no description available) pn icepref none (no description available) ii icewm-themes 1.2.26-1 Theme files for the Ice Window Man ii xlockmore 1:5.27-1 Lock X11 display until password is -- 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#593296: icewm: Mention that battery display now defaults to graphics not text
Package: icewm Version: 1.3.7~pre2-1 Severity: minor Tags: patch Since 1.3.7pre1, icewm defaults to displaying the battery charge level as graphics (a small box), insted of as text. It would be nice to mention this (probably in NEWS.Debian.gz). I therefore propose to add this paragraph to NEWS.Debian.gz: ---snip--- icewm 1.3.7pre1 Noteworthy changes / new features: In version 1.3.7pre1, a new graphic display for the battery charge level was added. This is now the default battery display. To get the old numeric percentage display, put the line TaskBarShowAPMGraph=0 into your preferences file under ~/.icewm or /etc/icewm. ---snap--- -- System Information: Debian Release: 5.0.2 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages icewm depends on: ii icewm-common1.3.7~pre2-1 wonderful Win95-OS/2-Motif-like wi ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libesd0 0.2.41-5 Enlightened Sound Daemon - Shared ii libfontconfig1 2.8.0-2.1generic font configuration library ii libgcc1 1:4.4.4-7GCC support library ii libglib2.0-02.24.0-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libice6 2:1.0.5-1X11 Inter-Client Exchange library ii libsm6 2:1.1.0-2X11 Session Management library ii libx11-62:1.3.3-3X11 client-side library ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxinerama12:1.1-3 X11 Xinerama extension library ii libxrandr2 2:1.3.0-2X11 RandR extension library icewm recommends no packages. Versions of packages icewm suggests: pn icewm-gnome-support none (no description available) pn ttf-bitstream-veranone (no description available) -- 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#591623: plymouth: Improve documentation in README.debian: KMS for ATI cards
Package: plymouth Version: 0.8.3-5 Severity: normal Tags: patch Hi, at the moment README.debian says the following about setting up KMS: plymouth 0.7 works only with KMS (kernel mode setting). Make sure to have it enabled in your initrd with the following lines in /etc/initramfs-tools/modules and don't forget to update your initrd by running 'update-initramfs -u' as root afterwards. # KMS intel_agp drm i915 modeset=1 This however only addresses Intel graphics cards (while KMS also works with ATI cards). Furthermore, listing drm is not necessary (update-initramfs will include it automatically), and intel_agp is not even part of Debian. Finally, modeset=1 is no longer necessary, as KMS is now the default on Debian for both Intel and ATI Radeon (see packages xserver-xorg-video-intel, xserver-xorg-video-radeon). I therefore propose to reword this part. Proposed text: ---snip plymouth 0.7 only works if KMS (kernel mode setting) is enabled at boot time. KMS is (as of August 2010) supported only for Intel and ATI graphics cards. It needs at least kernel version 2.6.29 for Intel and 2.6.32 for ATI Radeon cards (2.6.34 for the R800). To enable KMS at boot time, put the following lines into /etc/initramfs-tools/modules and don't forget to update your initrd by running 'update-initramfs -u' as root afterwards. For Intel cards / builtin graphics: # KMS i915 For ATI Radeon: # KMS radeon Note: You will need the latest versions of packages xserver-xorg-video-intel (Intel cards) or xserver-xorg-video-radeon (ATI Radeon cards) installed for this to work. Future versions of this package may depend on them, in which case this advice will be moot. ---snap Greetings, S.Leske -- System Information: Debian Release: 5.0.2 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages plymouth depends on: ii initramfs-tools 0.92o tools for generating an initramfs ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libdrm-intel1 2.4.18-6 Userspace interface to intel-speci ii libdrm-nouveau1 2.4.18-6 Userspace interface to nouveau-spe ii libdrm-radeon12.4.18-6 Userspace interface to radeon-spec ii libdrm2 2.4.18-6 Userspace interface to kernel DRM ii libglib2.0-0 2.24.0-1 The GLib library of C routines ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libpng12-01.2.38-1 PNG library - runtime ii ttf-dejavu-core 2.31-1 Vera font family derivate with add Versions of packages plymouth recommends: ii plymouth-themes-all 0.8.3-5Graphical Boot Animation and Logge Versions of packages plymouth suggests: pn gdm none (no description available) -- 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#591623: Correction
On second thought: There's no need to have xserver-xorg-video-intel/radeon installed to use plymouth, so mentioning them is probably somewhat misleading. So probably the following wording is better: --snip-- For Intel cards / builtin graphics: # KMS i915 modeset=1 For ATI Radeon: # KMS radeon modeset=1 --snap-- and omit the paragraph about xserver-xorg-video-*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591706: plymouth does not work with old cryptsetup
Package: plymouth Version: 0.8.3-5 Severity: important Hi, plymouth does not work with old versions of cryptsetup for encrypted root filesystems. If / is encrypted, crypsetup needs to prompt for the passphrase before mounting /. If plymouth is running, the normal console prompt will not work, which will cause the boot to hang and effectively make the system unbootable (unless there is an alternative kernel installed). This was apparently fixed in crypsetup 2:1.1.3-1 (or shortly before). So maybe plymouth could conflict with crypsetup 2:1.1.3-1 ? Greetings, S.Leske -- System Information: Debian Release: 5.0.2 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages plymouth depends on: ii initramfs-tools 0.92o tools for generating an initramfs ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libdrm-intel1 2.4.18-6 Userspace interface to intel-speci ii libdrm-nouveau1 2.4.18-6 Userspace interface to nouveau-spe ii libdrm-radeon12.4.18-6 Userspace interface to radeon-spec ii libdrm2 2.4.18-6 Userspace interface to kernel DRM ii libglib2.0-0 2.24.0-1 The GLib library of C routines ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libpng12-01.2.38-1 PNG library - runtime ii ttf-dejavu-core 2.31-1 Vera font family derivate with add Versions of packages plymouth recommends: ii plymouth-themes-all 0.8.3-5Graphical Boot Animation and Logge Versions of packages plymouth suggests: pn gdm none (no description available) -- 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#564169: [Pkg-acpi-devel] Bug#564169: acpi-support should depend on rfkill
Hi, On Tue, 12 Jan 2010 16:15:31 +0100, Michael Meskes mes...@debian.org wrote: They press Fn-F5, but nothing happens. They look into the system logs: nothing. They conclude that acpi-support does not support Fn-F5. Your fix will not really help that user. True. But don't forget that your package manager will tell you about rfkill, so you could have installed it. yes, that is true. That was my point: the package manager will tell me that rfkill is a Suggest or Recommend, but it will not say what it's needed for. That's why I wrote that it would be useful to have some kind of comment with a Suggest/Recommend to tell users *why* it's recommended. Maybe that'll come one day... * Explain in the package description where rfkill is needed: Install rfkill to enable toggling WLAN on Thinkpad laptops. No, this will bloat the description. I don't think this is acceptable either. I think the best place to put this is /usr/share/doc/acpi-support/README.thinkpad. Yes, that sounds reasonable. Maybe the package description could note that /usr/share/doc/acpi-support/README.thinkpad. (or /usr/share/doc/acpi-support/README* ) contains useful information for users :-). * Put some hint into ibm-wireless.sh about rfkill, e.g.: Replace test -x /usr/sbtest -x /usr/sbin/rfkill || exit 0 with if (! test -x /usr/sbin/rfkill) then logger Error: Please install package rfkill to enable toggling of wireless devices. ;exit 0 fi This sounds good. That's good :-). Greetings, S.Leske -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564169: [Pkg-acpi-devel] Bug#564169: acpi-support should depend on rfkill
Hi, thanks for the prompt reply. On Fri, Jan 08, 2010 at 06:35:57AM +0100, Sebastian Leske wrote: acpi-support should depend on rfkill, as it is used in /etc/acpi/ibm-wireless.sh A Suggest has to be sufficient because it is not needed for other laptops. But ibm-wireless.sh should also test for its existance. Thanks, but I fear that will not really help. Put yourself into the position of a user: They install acpi-support because someone told them it will make the Thinkpad's special buttons work. They press Fn-F5, but nothing happens. They look into the system logs: nothing. They conclude that acpi-support does not support Fn-F5. Your fix will not really help that user. The simplest thing would be to just depend on rfkill. I understand that not all laptops will need it, but then again, it's small ;-). The problem with recommends/suggests is that it's difficult for a user to tell which packages they need; users may not know which packages they really need. If depending on rfkill is not possible, I'd suggest: * Explain in the package description where rfkill is needed: Install rfkill to enable toggling WLAN on Thinkpad laptops. and * Put some hint into ibm-wireless.sh about rfkill, e.g.: Replace test -x /usr/sbtest -x /usr/sbin/rfkill || exit 0 with if (! test -x /usr/sbin/rfkill) then logger Error: Please install package rfkill to enable toggling of wireless devices. ;exit 0 fi (or similar). The idea is to give the user a hint why the functionality isn't working. Of course, this is really a problem with recommends/suggests; I believe it could help if they had an extra field to explain why the packages is recommended / suggested. Maybe that'll come some day... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564169: acpi-support should depend on rfkill
Package: acpi-support Version: 0.131-5 Severity: normal acpi-support should depend on rfkill, as it is used in /etc/acpi/ibm-wireless.sh -- System Information: Debian Release: 5.0.2 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages acpi-support depends on: ii acpi-support-base 0.131-5scripts for handling base ACPI eve ii acpid 1:2.0.0-1 Advanced Configuration and Power I ii dmidecode 2.9-1 Dump Desktop Management Interface ii libc6 2.9-12 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii pm-utils 1.1.2.4-1 utilities and scripts for power ma ii x11-xserver-utils 7.3+5 X server utilities Versions of packages acpi-support recommends: ii dbus 1.2.1-5simple interprocess messaging syst ii hal 0.5.11-8 Hardware Abstraction Layer ii radeontool1.5-5 utility to control ATI Radeon back ii toshset 1.75-1 Access much of the Toshiba laptop ii vbetool 1.1-2 run real-mode video BIOS code to a ii xscreensaver 5.05-3 Automatic screensaver for X Versions of packages acpi-support suggests: pn nvclock none (no description available) -- 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#225077: Use stunnel4 for TLS support
While having SSL/TLS support in pop3browser would be nice, you can also use stunnel4 to access POP3 over TLS. Install package stunnel4, and add this to the end of /etc/stunnel/stunnel.conf: snip [pop3s] accept=localhost:9998 connect=my.pop3mailserver.com:995 sslVersion = SSLv3 snip Then uses pop3browser to connect to localhost:9998 (username + password as usual). Voila, POP3 over TLS. Note that for secure operation you need to set verify=2 and CApath = /etc/ssl/certs then install package ca-certificates, and run update-ca-certificates to activate it. Then TLS certificate validation should work. If you do not set verify=2, stunnel4 will be vulnerable to man-in-the-middle attacks. S.Leske -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533372: gosmore map rebuild fails with Assertion seg failed
Package: gosmore Version: 0.0.0.20080704-1 Severity: grave Justification: renders package unusable gosmore rebuild fails with an assertion failure: ~$ gosmore rebuild map.osm 1 while (xmlTextReaderRead (xml)) 2 while (fread (nd, sizeof (nd), 1, groupf[i]) == 1) 3 while (fread (s, sizeof (s), 1, groupf[i + NGROUPS]) == 1) -- about 200 lines skipped -- 258 rewind (groupf[i]) 259 rewind (groupf[i]) 260 rewind (groupf[i]) 261 rewind (groupf[i]) 262 rewind (groupf[i]) 263 rewind (groupf[i]) 264 rewind (groupf[i]) gosmore: gosmore.cpp:1989: int main(int, char**): Assertion `seg' failed. Aborted As gosmore will not run without the map file (.pak) generated by gosmore rebuild, this makes gosmore completely useless. I suspect this is because the format of OSM's XML data changed recently (April 2009, see http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6 ), while the gosmore in Debian is from July 2008. This error does not occur with gosmore built from current SVN (2009-06-16). gosmore should be updated to the latest upstream, or removed from Debian. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages gosmore depends on: ii libatk1.0-0 1.20.0-1The ATK accessibility toolkit ii libc62.9-6 GNU C Library: Shared libraries ii libcairo21.8.6-2 The Cairo 2D vector graphics libra ii libflite11.2-release-2.3 a small run-time speech synthesis ii libgcc1 1:4.3.2-1.1 GCC support library ii libglib2.0-0 2.20.0-2The GLib library of C routines ii libgtk2.0-0 2.14.7-5The GTK+ graphical user interface ii libpango1.0-01.24.0-3+b1 Layout and rendering of internatio ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii libxml2 2.6.29.dfsg-1 GNOME XML library Versions of packages gosmore recommends: ii gpsd 2.37-6 GPS (Global Positioning System) da Versions of packages gosmore suggests: pn josm none (no description available) -- 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#529376: taxbird should depend on libgeier0= 0.10, not 0.9
Package: taxbird Version: 0.12-1+b1 Severity: grave Justification: renders package unusable To work correctly, taxbird 0.12 requires libgeier 0.10. However, package taxbird 0.12-1 only requires libgeier0 (= 0.9). With libgeier0 V0.9 taxbird runs, but data submission to the Finanzamt fails (error msg: Das exportierte Dokument konnte nicht validiert werden). See e.g. http://www.g-n-u.de/archive/taxbird/de/mail626.html (in German, sorry). Marking grave, as the whole point of taxbird is submitting tax data, which this bug makes impossible. Note: The System information lists libgeier0 V 0.10-1, but only because I updated it manually. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages taxbird depends on: ii guile-1.8-libs1.8.4+1-2 Main Guile libraries ii libart-2.0-2 2.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libbonobo2-0 2.24.1-1 Bonobo CORBA interfaces library ii libbonoboui2-02.18.0-5 The Bonobo UI library ii libc6 2.9-6 GNU C Library: Shared libraries ii libcairo2 1.8.6-2The Cairo 2D vector graphics libra ii libfontconfig12.4.1-2generic font configuration library ii libfreetype6 2.3.5-1+b1 FreeType 2 font engine, shared lib ii libgconf2-4 2.26.0-1 GNOME configuration database syste ii libgeier0 0.10-1 Elster client library (German tax ii libglade2-0 1:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.20.0-2 The GLib library of C routines ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library ii libgnome2-0 2.26.0-1 The GNOME library - runtime files ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeui-0 2.24.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-01:2.22.0-3 GNOME Virtual File System (runtime ii libgtk2.0-0 2.14.7-5 The GTK+ graphical user interface ii libgtkhtml2-0 2.11.1-2 HTML rendering/editing library - r ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libltdl7 2.2.6a-4 A system independent dlopen wrappe ii liborbit2 1:2.14.13-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.24.0-3+b1Layout and rendering of internatio ii libpopt0 1.14-3 lib for parsing cmdline parameters ii libsm62:1.0.3-1 X11 Session Management library ii libxml2 2.6.29.dfsg-1 GNOME XML library Versions of packages taxbird recommends: ii cupsys-bsd [lpr] 1.3.6-3Common UNIX Printing System(tm) - Versions of packages taxbird suggests: ii html2ps 1.0b5-5HTML to PostScript converter ii html2text 1.3.0.2-1 An advanced HTML to text converter -- 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#451641: Edit/Replace should default to Range if selection exists
Hm, I'm not sure I agree with the gnumeric developers, but they do have a point. I guess both behaviours are reasonable. No point in discussing this further. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451641: Edit/Replace should default to Range if selection exists
Package: gnumeric Version: 1.6.3-6 If I mark/select some cells in gnumeric, then invoke Edit/Replace..., then in the dialog gnumeric helpfully (and correctly) fills the field Range (under Scope) with the range of cells which I selected. However, under Scope, the option Range is not marked, but the default Entire Workbook. So just clicking OK will _not_ limit the Search/Replace to the selected cells. If I select something and then invoke a function, my general expectation is that the function should only act on what I selected, if applicable. That is how Copy, Cut, Paste, Fill, Clear, Delete in the Edit menu work. Therefore, if Edit/Replace... is invoked with an active selection, the dialog should default to Scope=Range, not Scope=Entire Workbook, since that is probably what the user intended by selecting some cells. If nothing is selected, the currend default of Scope=Entire Workbook seems reasonable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445668: Improve error message for unknown device
Package: ppp Version: 2.4.4rel-9 Severity: minor If pppd is invoked with a command line parameter that specifies a device that does not exist, the error message unrecognized option xxx is printed. E.g.: pppd noauth crtscts local connect \ /usr/sbin/chat -v -f /etc/chatscripts/provider2 /dev/ircomm0 115200 may produce the error message: pppd: unrecognized option '/dev/ircomm0' This is misleading, as the problem is not that pppd does not know the option, rather the device node does not exist. Therefor I propose to change the message to: pppd: unrecognized option or problem opening device: '/dev/ircomm0' or similar. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438631: =?ISO-8859-1?Q?Spurious(?) I/O error?= s at end of CD-R
Package: cdck Version: 0.6.0-1 If I use cdck to verify a CD-R or CD-RW, it reports unreadable sectors at the end of the disc for several discs which are perfectly readable (I even verified MD5 sums for one disc). Log: iota:~$ cdck Reading sectors 1-27280 ! unable to read sector 27259, reason: Input/output error [...all sectors in between with same message...] ! unable to read sector 27280, reason: Input/output error CD overall: Sectors total: 27280: Good sectors: 27258: Bad sectors (incl. with poor timing): 22 CD timings: Minimal = 5 usec (0.05s) Maximal = 99340 usec (0.099340s) Average = 1161 usec (0.001161s) Conclusion: Disc contains BAD or even readable sectors, put it into trash can! This occured for several discs. The number of bad sectors reported varies from 14 to 24, but it is always the last sectors. Maybe cdck incorrectly detects the end of a CD? I also tried a real, pressed CD from retail: The problem did not occur. additional info- Here are excerpted logs for some CDs I tested. They were burnt on different drives. I also included the volume size as reported by isoinfo -d (the line Volume size is:). Strangely, it does not agree with what cdck reports. CD-R, burnt on Windows: Reading sectors 1-197640 ! unable to read sector 197627, reason: Input/output error ! unable to read sector 197640, reason: Input/output error Volume size is: 197488 CD-RW, burnt with mkisofs/cdrecord: Reading sectors 1-68879 ! unable to read sector 68859, reason: Input/output error ... ! unable to read sector 68879, reason: Input/output error Volume size is: 68877 CD-RW, burnt with mkisofs/cdrecord: Reading sectors 1-245488 ! unable to read sector 245435, reason: Input/output error ... ! unable to read sector 245488, reason: Input/output error Volume size is: 245486 CD-R, burnt on Windows: Reading sectors 1-27280 ! unable to read sector 27259, reason: Input/output error ! unable to read sector 27280, reason: Input/output error Volume size is: 27128 Tests done on CD drive: DVD/CD-RW, Compaq Armada M700 builtin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438631:
Hi, thanks for the super-fast reply. I'm not sure if this is a bug -- or actually a feature. cdcd's purpose is not to check for un/readable files but for bad sectors. From the README: The known fact is that even if all files on the disc are readable, some sectors having bad timing can easily turn into unreadable ones in the future. In my understanding cdck tries to find problematic factors that _might_ make sectors unreadable in the _future_, and it warns about these sectors. Yes, that is true. However, the message unable to read sector XXX, reason: Input/output error looks to me like cdck found a hard error, not just bad timing. That would mean that that sector is already unreadable, and the file which uses it should in consequence also be unreadable. Still, all files on the disc are OK, that is what I do not understand. Maybe cdck incorrectly detects the end of a CD? I'll check with the upstream author. Good idea. Maybe I'm just misunderstanding the output of cdck, or maybe my test CDs where burnt incorrectly. In that case, it might be enough to add a note to the docs about possible reasons for read errors and when these are harmless - or not. Greetings, Sebastian Leske -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438169: Warn about missing hash in /etc/crypttab
Package: cryptsetup Version: 2:1.0.4+svn26-1 As described in bug #406317 and documented in README.initramfs.gz, the initramfs scripts default to using the sha256 hash function while the plain cryptsetup binary defaults to using the ripemd160 hash function. That means that on upgrade from initrd to initramfs, a root partition that was encrypted using plain cryptsetup will become unbootable, unless the correct hash is given as an option in /etc/crypttab (hash=ripemd160). While this is documented in README.initramfs.gz, it is unlikely everyone will read all the README's when instaling initramfs. Therefore, as a migration help I propose that mkinitramfs should warn if the entry for the root partition in /etc/crypttab lacks the hash= option. The enclosed patch (to /usr/share/initramfs-tools/hooks/cryptroot) does just that. If the line for the root device in crypttab does not contain the options hash= or luks, it prints: WARNING: Option hash= missing in crypttab for target $target, assuming sha256. If this is wrong, this initramfs image will not boot. Please read /usr/share/doc/cryptsetup/README.initramfs.gz and add the correct hash= option to your /etc/crypttab (or add luks if you are running LUKS). That will give users a chance to correct their crypttab. Even if sha256 would have been correct, it doesn't hurt to add it explicitly. To avoid breaking things, the patch does not change the behaviour of mkinitramfs, it only warns. The patch skips the warning if option luks is present, to avoid bothering LUKS users, who don't need to specify the hash anyway. [--- patch follows, format: unified diff ---] --- /usr/share/initramfs-tools/hooks/cryptroot-orig 2007-07-23 18:08:34.0 +0200 +++ /usr/share/initramfs-tools/hooks/cryptroot 2007-08-12 12:10:17.0 +0200 @@ -197,17 +197,20 @@ fi # We have all the basic options, let's go trough them OPTIONS=target=$target,source=$source,key=$key local IFS=, + unset HASH_FOUND + unset LUKS_FOUND for opt in $rootopts; do case $opt in cipher=*) OPTIONS=$OPTIONS,$opt ;; hash=*) OPTIONS=$OPTIONS,$opt + HASH_FOUND=1 ;; size=*) OPTIONS=$OPTIONS,$opt ;; lvm=*) @@ -221,16 +224,28 @@ fi KEYSCRIPT=$opt opt=$(basename $opt) OPTIONS=$OPTIONS,keyscript=/keyscripts/$opt ;; + luks) + LUKS_FOUND=1 + ;; *) # Presumably a non-supported option ;; esac done +# Warn for missing hash option, unless we have a LUKS partition (which does not need it) + if [ -z $HASH_FOUND ] [ -z $LUKS_FOUND ]; then + echo WARNING: Option hash= missing in crypttab for target $target, assuming sha256. 2 + echo If this is wrong, this initramfs image will not boot. 2 + echo Please read /usr/share/doc/cryptsetup/README.initramfs.gz and add 2 + echo the correct hash= option to your /etc/crypttab (or add 2 + echo 'luks' if you are running LUKS). 2 + fi + # If keyscript is set, the key is just an argument to the script if [ $key != none ] [ -z $KEYSCRIPT ]; then echo cryptsetup: WARNING: target $target uses a key file, skipped 2 return 1 fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405325: Known bug in XMMS
This is a long standing bug/misfeature in XMMS: Can't read/edit id3v2 tags in file info dialog. http://bugs.xmms.org/show_bug.cgi?id=335 It would be nice to at least have a workaround. Maybe a warning that you can only change the id3v1 tag. Or a warning when editing a file that contains id3v2 tags... but that's probably a job for upstream. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365791: Discussed elsewhere
This is a longstanding upstream bug. See #405325. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436752: Improve error message for altered initramfs
Package: initramfs-tools
Version: 0.88
Severity: minor
If the initramfs has been altered by a tool different from
update-initramfs, then update-initramfs will refuse to update it,
complaining:
${initramfs} has been altered. Cannot update.
I found this message to be a bit confusing. It wasn't clear to my what
has been altered means, and what I can do about the message. Therefore
I propose a new wording for the message:
${initramfs} has been altered since last run of
update-initramfs; not updating. Use option -t to override.
This explains just why update-initramfs is bailing, and tells users what
to do if they still want to go ahead.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434574: Note that id3ed does not support ID3v2
Package: id3ed Version: 1.10.4-2 Severity: minor The documentation does not mention that id3ed only edits ID3v1 tags. Since most modern players use ID3v2 tags, that might be confusing. Proposal: Mention that in the pkg description and manpage. E.g.: package description, 1st sentence: A command-line program that allows you to add/edit/remove id3 tags on mp3 files (only ID3v1 tags supported). Manpage: id3ed - edit id3v1 description tags in mpeg3 files DESCRIPTION id3ed edits the id3 tag for mpeg layer3 files (only ID3v1, ID3v2 is not supported). [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397726: No longer reproducible with 1.6.0
The problem is no longer reproducible with linphone 1.6.0-1 (from experimental). I guess the bug can be closed once 1.6.0-1 migrates to unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397726: Still happens with linphone1.5.1
Just upgraded to linphone V1.5.1. The same crash still occurs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397726: linphone: segfaults immediately on startup
Package: linphone
Version: 1.5.0-1
Severity: important
On invocation, linphone (invoked as linphone from an xterm) briefly
pops up its main window (only partially painted), then Gnome's (?) crash
dialog appears: Die Anwendung linphone wurde unerwartet beendet etc.
(application linphone terminated unexpectedly).
I deleted my .linphonerc and .gnome2/linphonerc, which didn't make a
difference.
---
Strace shows a segfault:
~$ strace linphone
[...]
recvmsg(15, {msg_name(12)={sin_family=AF_NETLINK, {sa_family=16,
sa_data=\0\0\0\0\0\0\0\0\0\0\2006\206\277},
msg_iov(1)=[{\24\0\0\0\3\0\2\0*QE\250\31\0\0\0\0\0\0\1\0\0\0\24\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
close(15) = 0
--- SIGSEGV (Segmentation fault) ---
write(3, \33\0\2\0\0\0\0\0, 8)= 8
write(3, \0\2\0\0\0\0\0, 8) = 8
write(3, +\0\1\0, 4) = 4
[...]
GDB backtrace (not sure if helpful w/o debugging symbols):
[...]
(no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225872800 (LWP 6612)]
0x0804ff48 in ?? ()
(gdb) bt
#0 0x0804ff48 in ?? ()
#1 0x0001 in ?? ()
#2 0x08069b60 in stderr ()
#3 0xbfd36588 in ?? ()
#4 0xb73ddc0d in freeifaddrs () from /lib/tls/libc.so.6
#5 0x08050094 in ?? ()
#6 0x in ?? ()
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages linphone depends on:
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libatk1.0-0 1.12.3-1 The ATK accessibility toolkit
ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library
ii libbonoboui2-02.10.1-2 The Bonobo UI library
ii libc6 2.3.6-7GNU C Library: Shared libraries
ii libcairo2 1.2.4-1The Cairo 2D vector graphics libra
ii libfontconfig12.4.1-2generic font configuration library
ii libgconf2-4 2.14.0-4 GNOME configuration database syste
ii libglib2.0-0 2.12.3-2 The GLib library of C routines
ii libgnome-keyring0 0.4.8-1GNOME keyring services library
ii libgnome2-0 2.14.1-3 The GNOME 2 library - runtime file
ii libgnomecanvas2-0 2.12.0-2 A powerful object-oriented display
ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf
ii libgnomevfs2-02.14.2-1 GNOME virtual file-system (runtime
ii libgtk2.0-0 2.8.12-1 The GTK+ graphical user interface
ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library
ii liblinphone1 1.3.5-1linphone web phone's library (supp
ii libmediastreamer0 1.5.0-1linphone web phone's media library
ii liborbit2 1:2.10.2-1.1 libraries for ORBit2 - a CORBA ORB
ii libortp5 1.5.0-1Real-time Transport Protocol stack
ii libosip2-32.2.2-3.1 Session Initiation Protocol (SIP)
ii libpanel-applet2-02.14.3-1 library for GNOME 2 panel applets
ii libpango1.0-0 1.14.7-1 Layout and rendering of internatio
ii libpopt0 1.10-3 lib for parsing cmdline parameters
ii libsm64.3.0.dfsg.1-8 X Window System Session Management
ii libx11-6 2:1.0.0-8 X11 client-side library
ii libxcursor1 1.1.7-4X cursor management library
ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar
ii libxfixes31:4.0.1-4 X11 miscellaneous 'fixes' extensio
ii libxi61:1.0.0-5 X11 Input extension library
ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library
ii libxml2 2.6.26.dfsg-4 GNOME XML library
ii libxrandr24.3.0.dfsg.1-8 X Window System Resize, Rotate and
ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra
ii linphone-nox 1.5.0-1web phone
linphone recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376773: Manpage does not mention how to set http proxy
On Fri, Jul 07, 2006 at 06:12:15PM +0200, Florian Weimer wrote: This can by accomplished by setting the environment variable http_proxy, e.g. export http_proxy=http://myproxy:8080; This useful behaviour is not documented in the manpage. Even though I deliberately inherited it from urllib2. 8-) Yes, that is just why it should be documented :-). Is there a definite reference for the syntax of http_proxy? IIRC, some programs only handle the myproxy:8080 syntax, while others (like urllib2) can deal with both forms. I'm not aware of any definite reference. I think http_proxy is a kind of defacto standard (like so many in computing), without an authoritative formal definition. I just did a quick googling for http_proxy, and most of the software described seems to accept the syntax http://proxy:8000/; syntax. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376773: Manpage does not mention how to set http proxy
Package: debsecan Version: 0.4.2 In order to use debsecan from behind a firewall, it is useful/necessary to let it connect via a http proxy. This can by accomplished by setting the environment variable http_proxy, e.g. export http_proxy=http://myproxy:8080; This useful behaviour is not documented in the manpage. Please include a section like - Using a HTTP proxy To make debsecan use a proxy, set the environment variable http_proxy, e.g. export http_proxy=http://myproxy:8080; . - Or you might mention that in the standard manpage section VARIABLES. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372730: Provide hints if APM/ACPI/cpufreq cannot be found
Package: cpufreqd Version: 2.0.0-1 On installation, cpufreqd probes to see whether power management (APM, ACPI or PMU) and CPUFreq are available. If they are not, it aborts configuration with an explanatory message. These messages should provide some pointers to the user as to what do to. At the moment, they just say please enable ACPI, APM or PMU in your kernel or please enable a CpuFreq driver in your kernel without any hint as to what to do. For people without in-depth knowledge about power management on Linux (like me :-) ) it is not at all obvious how to get cpufreqd to work. Proposed fix: Make the texts a bit more verbose. Append some lines to the power management warning dialog, like: To enable ACPI or APM, you may need to configure your kernel appropriately (not normally necessary for stock Debian kernels) and load appropriate modules. It is recommended to install the package acpid or apmd respectively, which will automatically load the required modules. ACPI is more powerful than APM, so you should generally try it first. Append some lines to the cpufreq management warning dialog, like: To enable the CpuFreq interface, you may need to configure your kernel appropriately (not normally necessary for stock Debian kernels) and load appropriate modules. Try loading the modules under /lib/modules/kernel-version/kernel/arch/architecture/kernel/cpu/cpufreq/ and /lib/modules/kernel-version/kernel/drivers/cpufreq (replace kernel-version and architecture with the values of your system). The texts are, of course, only proposals, which may not even be correct :-). If the texts grow longer, it might be better to put them into a file under /usr/share/doc/cpufreqd and refer to that in the dialog texts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372729: Add configuration entry for sleep button
Package: acpid Version: 1.0.4-5 Severity: wishlist acpid contains a sample entry /etc/acpi/events/powerbtn , which shuts down the system if the power button is pressed. I propose to add a similar entry for the sleep button, which activates suspend-to-RAM. That way the sleep button should automatically work on most systems :-). Add the following files to the package: file /etc/acpi/sleepbtn.sh -cut- #!/bin/sh # /etc/acpi/sleepbtn.sh # Initiates suspend-to-RAM when the sleep putton has been # pressed. # If powersaved is running, let it process the acpi event if pidof powersaved; then exit 0 fi sync # just to be safe :-) # initiate suspend-to-RAM via sysfs interface echo -n mem /sys/power/state -cut- file /etc/acpi/events/sleepbtn -cut- # /etc/acpi/events/sleepbtn # This is called when the user presses the sleep button and calls # /etc/acpi/sleepbtn.sh for further processing. # Optionally you can specify the placeholder %e. It will pass # through the whole kernel event message to the program you've # specified. # We need to react on button sleep.* and button/sleep.* because # of kernel changes. event=button[ /]sleep action=/etc/acpi/sleepbtn.sh -cut- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372729: Add configuration entry for sleep button
On Sun, Jun 11, 2006 at 06:18:12PM +0200, martin f krafft wrote: also sprach Sebastian Leske [EMAIL PROTECTED] [2006.06.11.1237 +0200]: acpid contains a sample entry /etc/acpi/events/powerbtn , which shuts down the system if the power button is pressed. Please see #285779. We are possibly removing this feature in a future release. Or at least make debconf ask about it. Yes, I read that. I actually considered filing a similar bug before seeing this one. I agree with the problem of data loss outlined there. Still, please do not just remove the scripts, as they are very useful for those people who want them. I'd propose to disable them by default, and tell the user how to activate / customize them. Doing this through debconf would probably be a good idea. Something like do you want to enable the power and sleep button?. I propose to add a similar entry for the sleep button, which activates suspend-to-RAM. That way the sleep button should automatically work on most systems :-). ... and we'll do the same to this suggestion, although it's way more likely this will come through... That could also be enabled at the user's request, for those who want it (and on whose systems suspend-to-RAM works...). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372730: Provide hints if APM/ACPI/cpufreq cannot be found
On Sun, Jun 11, 2006 at 02:06:01PM +0200, Mattia Dongili wrote: Hello, thanks for your suggestions. On Sun, Jun 11, 2006 at 12:16:49PM +0200, Sebastian Leske wrote: Package: cpufreqd Version: 2.0.0-1 [...] The texts are, of course, only proposals, which may not even be correct :-). If the texts grow longer, it might be better to put them into a file under /usr/share/doc/cpufreqd and refer to that in the dialog texts. Yes, I'd rather put them there, in README.Debian. That may actually be a better place for them. But in that case please add a short note to the debconf failure messages, so people will know to look into README.Debian, something like Additional configuration may be needed to activate this feature. See /usr/share/doc/cpufreqd/README.Debian for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347872: lspci: Wrong error message for invalid slot number
Package: pciutils Version: 2.1.11-15.3 The -s option of lspci produces a misleading error number: $ lspci -s abc lspci: -f: Invalid slot number Obviously, this should read lspci: -s: Invalid slot number This considerably complicated my debugging of a script using lspci, since I could not understand which command produced the above error message. I assumed it could not come from lspci, since lspci does not have a -f option. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347872: Fixed in upstream 2.2.0
This bug is fixed in upstream version 2.2.0 and 2.2.1. tags 347872 fixed-upstream -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347877: lspci: output format differs from upstream version
Package: pciutils Version: 2.1.11-15.3 The output of lspci and lspci -m in the Debian package differs from the output format used by the upstream version: # Debian package V 2.1.11-15.3 ## $ lspci [...] :05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5782 Gigabit Ethernet (rev 03) $ lspci -m [...] 05:02.0 Ethernet controller Broadcom Corporation NetXtreme BCM5782 Gigabit Ethernet 03 00 Hewlett-Packard Company HP d530 CMT (DG746A) # Upstream version pciutils-2.1.11 ### $ lspci [...] 05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5782 Gigabit Ethernet (rev 03) $ lspci -m [...] 05:02.0 Ethernet controller Broadcom Corporation NetXtreme BCM5782 Gigabit Ethernet -r03 Hewlett-Packard Company 12bc Note the different format for the device ID (with an extra leading :) in the Debian output and the missing quotes in the -m output. This can break scripts that parse the output of lspci, such as the scanModem script from http://linmodems.technion.ac.il/#scanmodem Ideally, the output format of lspci should not be changed from the upstream version. If this is unavoidable, this change should at least be clearly documented, in the manpage, in the README.Debian and in the output of lspci -h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338461: Missing file menuutil.pl, examples do not run
Package: libperlmenu-perl Version: 4.0-3 The included example Perl programs under /usr/share/doc/libperlmenu-perl/examples/ all require the file menuutil.pl to run. This file is present in the source distribution of perlmenu (it's also present in Debian's libperlmenu-perl_4.0.orig.tar.gz ), but it is not included in the regular Debian package. Without this file, the examples programs under examples/ cannot be run. Since there is relatively little documentation apart from the example programs, it is difficult to use perlmenu without this file. menuutil.pl should not be stripped out of the Debian package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334485: Outdated documentation in package
Package: cryptsetup Version: 20050111-3 The packages includes the file /usr/share/doc/cryptsetup/README.html which was obviously downloaded from http://www.saout.de/misc/dm-crypt/ The web document, however, is newer than the version included in the package. In particular, it mentions how to avoid the watermark attack, which can be used against dm-crypt (and cryptoloop) in its default configuration. (See http://mareichelt.de/pub/notmine/diskenc.pdf for a paper discussing this vulnerability ). This information is important to avoid the vulnerability. The README.html should be updated to the newest version (possibly minus any changes which only apply to the latest version of cryptsetup). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334490: Document use of ESSIV to avoid watermark attack
Package: cryptsetup Version: 20050111-3 Cryptsetup with the default parameters is vulnerable to a watermark attack (just like cryptoloop). See http://mareichelt.de/pub/notmine/diskenc.pdf for details. This attack can be avoided by using the IV generation mode ESSIV, which is supported from Kernel 2.6.10 onwards. This is documented in the current version of the dm-crypt README at http://www.saout.de/misc/dm-crypt/ (search for watermark). A similar comment should be added to the (otherwise excellent) CryptoRoot.HowTo, warning users that the default parameters are vulnerable to the attack. I propose the following wording: Change # Edit /etc/crypttab and add the following line # Replace /dev/hda4 with your backing device (lvm is ok, as is raid) root/dev/hda4 to # Edit /etc/crypttab and add the following line # Replace /dev/hda4 with your backing device (lvm is ok, as is raid) root/dev/hda4nonecipher=aes-cbc-essiv:sha256 # Note: Specifying this cipher and IV generation through the cipher= # parameter mode avoids the watermark # attack mentioned in README.html. However, unlike the default parameters, # it creates an encrypted partition that is incompatible with the old # cryptoloop implementation. If that matters to you, omit the cipher # specification (and live with the watermark attack). (Note: Didn't test this line, as I do not have a kernel with dm-crypt handy, but it should work. Maybe you can run a quick test.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
