Bug#717367: rlwrap: build fails with rbgen: command not found
Package: rlwrap Version: 0.37-3 Dear Maintainer, *** Please consider answering these questions, where appropriate *** I have all the build-dependencies of rlwrap installed, but when I try to build the latest version from git (git://git.debian.org/git/collab-maint/rlwrap.git), it fails with rbgen completion.rb completion.c /bin/bash: rbgen: command not found I have found references to this program, but I can't seem to find it in any Debian package. Makes me scratch my head since it seems I don't know how it could ever build. Am I doing something stupid? Andrew *** End of the template - remove these lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 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 rlwrap depends on: ii libc6 2.17-7 ii libncurses5 5.9+20130608-1 ii libreadline6 6.2+dfsg-0.1 ii libtinfo5 5.9+20130608-1 rlwrap recommends no packages. rlwrap 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#717367: rlwrap: build fails with rbgen: command not found
Excerpts from Mike Miller's message of Fri Jul 19 13:48:48 -0700 2013: No, I suspect you are right that rbgen is not in the Debian archive, but it is also not normally needed to build the package. In particular, it should only be needed if src/completion.rb is modified. Can you tell me what commands you run to build the source package? Hmm... I don't think I can reconstruct what I did to cause the error. Maybe I was unlucky and src/completion.rb had a newer timestamp than completion.c in my git checkout. Is that possible? I did first try building without the debian scripts, just by running ./configure make. However, I don't think any of the commands I ran would have either deleted completion.c (make clean doesn't do it) or updated completion.rb. So I can't explain it. Anyhow, when I do a fresh git clone and run ./debian/rules build, it works fine. Sorry for the false report. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711826: no more unattended upgrades since Wheezy is out
Excerpts from Michael Vogt's message of Sun Jul 14 23:18:14 -0700 2013:
The current version of unattended-upgrades has the following lines:
Unattended-Upgrade::Origins-Pattern {
origin=Debian,archive=${distro_codename},label=Debian-Security;
This should fix the problem. As a workaround you can put oldstable
into the allowed origins for now.
Cool, thanks!
Andrew
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711826: no more unattended upgrades since Wheezy is out
Jumping into this bug...
It would definitely help me to have one unattended-upgrades
configuration that works without change across multiple Debian releases,
even when I choose to stay behind the current stable for a while. The
problem is, the archive/suite in Debian release files seems to be
oldstable or stable, while ${distro_codename} is squeeze or wheezy. So
there's nothing I can put in Allowed-Origins to track my current
release.
I think the easiest fix would be to add something like ${distro_archive}
with the current archive name. (I don't know where to get this from,
though, since it's not part of lsb_release.get_distro_information().) A
more flexible alternative would be to extend the Allowed-Origins syntax
to allow matching on the codename and label of the release. For
example, if you could match on the label Debian-Security, you could
really limit unattended-upgrades to security upgrades.
(By the way, the Allowed-Origins entries like
${distro_id} ${distro_codename}-security;
seem to be meaningless for Debian and should probably be removed to
reduce confusion.)
Andrew
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685310: aptitude: Apt::AutoRemove::SuggestsImportant defaults to true
Package: aptitude Version: 0.6.8-1 Severity: normal Dear Maintainer, I have a package intalled that is not depended upon by any other intalled package, or recommended, but is suggested by another installed package (specifically, libterm-readline-gnu-perl). If I run aptitude markauto libterm-readline-gnu-perl it is not proposed for removal. The manual says this should be guided by Apt::AutoRemove::SuggestsImportant, which defaults to false. However, this does not seem to be the case, because if I run aptitude -o Apt::AutoRemove::SuggestsImportant=false markauto libterm-readline-gnu-perl it proposes to remove the package. I checked to make sure that my ~/.aptitude/config (pasted here) does not have any relevant options: aptitude ; aptitude::UI ; aptitude::UI::New-Package-Commands true; aptitude::UI::Package-Header-Format %N %n #%B %u %o; aptitude::UI::Package-Status-Format %d; aptitude::UI::Package-Display-Format %c%a%M %p %t %15v %15V; aptitude::UI::Default-Grouping filter(missing),task,status; aptitude::UI::Advance-On-Action true; aptitude::UI::Description-Visible-By-Default true; aptitude::UI::Minibuf-Download-Bar false; aptitude::UI::Pause-After-Download false; aptitude::UI::Prompt-On-Exit true; aptitude::UI::Exit-On-Last-Close true; aptitude::UI::Incremental-Search true; aptitude::UI::Minibuf-Prompts true; aptitude::UI::Menubar-Autohide true; aptitude::UI::HelpBar false; aptitude::UI::Auto-Show-Reasons true; aptitude::Pkg-Display-Limit ; aptitude::Auto-Install true; aptitude::Auto-Fix-Broken true; aptitude::Delete-Unused true; aptitude::Purge-Unused true; aptitude::Delete-Unused-Pattern ; aptitude::Auto-Upgrade true; aptitude::AutoClean-After-Update true; aptitude::Changelog-URL-Template http://cgi.debian.org/cgi-bin/get-changelog?package=%s;; aptitude::Display-Planned-Action true; aptitude::Forget-New-On-Update false; aptitude::Forget-New-On-Install false; aptitude::Warn-Not-Root true; aptitude::Log /var/log/aptitude; aptitude::Keep-Unused-Pattern ; By the way, typos: the manual incorrectly refers to Apt::AutoRemove::Suggests-Important and Apt::AutoRemove::Recommends-Important in a few places (note the hyphens). Andrew -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.8 compiled at Jun 9 2012 10:02:58 Compiler: g++ 4.7.0 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.2.10 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20110404 cwidget version: 0.5.16 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 = (0x7fffa3dff000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7f1d155bd000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f1d1538d000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f1d15163000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f1d14f5e000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f1d14c5e000) libept.so.1.0.5.4.12 = /usr/lib/libept.so.1.0.5.4.12 (0x7f1d149bd000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f1d145d8000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f1d143c1000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f1d14115000) libboost_iostreams.so.1.49.0 = /usr/lib/libboost_iostreams.so.1.49.0 (0x7f1d13efc000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1d13ce) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f1d139d8000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f1d13756000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1d1354) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f1d131b8000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f1d12fb5000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1d12db1000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f1d12ba) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f1d1299b000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f1d12792000) /lib64/ld-linux-x86-64.so.2 (0x7f1d15f4b000) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-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 aptitude depends on: ii aptitude-common 0.6.8-1 ii libapt-pkg4.120.9.7.2 ii libboost-iostreams1.49.0
Bug#683942: xterm: alternate screen scrolling
Excerpts from Thomas Dickey's message of Sun Aug 05 11:06:02 -0700 2012: On Sun, Aug 05, 2012 at 09:40:22AM -0700, Andrew Pimlott wrote: Is there another way for me to get this behavior? It's fairly simple as an addition to xterm, probably hard other ways... That sounds like a note that I made with reference to a comment about konsole early this year: 120207 if mouse-mode enabled, wheel mouse _does_ same. arch-user wants it to send up/down arrows, sez konsole does this. **120208 better, add a control sequence for switching between sets of mouse translations, including konsole's combination. (I'm currently working on complicated changes in vile and lynx, thinking I'll work on xterm next...) Awesome, I'll be glad if you get to this. Happy hacking, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683859: [Aptitude-devel] Bug#683859: closed by Daniel Hartwig mand...@gmail.com (Re: Bug#683859: aptitude: APT::Get::Build-Dep-Automatic is not honored)
Excerpts from Daniel Hartwig's message of Sun Aug 05 02:41:30 -0700 2012: [then, after make foo] # aptitude --remove-user-tag foo-builddep '?user-tag(foo-builddep)' Did you mean to add an unmarkauto to this command? No, actually it should have 'remove' which I missed. The build deps are not marked auto by the first command. The second should have been: # aptitude --remove-user-tag foo-builddep remove '?user-tag(foo-builddep)' Oh, right. Actually, I meant markauto, which may be better, in case something else has depended upon a foo-builddep package in the meantime. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683863: libfprint0: udev rules not applied when libfprint0 is installed
Excerpts from Didier Raboud's message of Sun Aug 05 02:33:45 -0700 2012: Le samedi, 4 août 2012 23.56:02, Andrew Pimlott a écrit : libfprint0 installs some udev rules to make fingerprint readers accessible to the plugdev group. However, since many fingerprint readers are built-in to computers, they are never plugged in, and thus the udev rules never fire. In my experience, that's partially wrong: the udev rules get run (at least) at boot time. Are you really experiencing this problem for a device or is it a theoretical problem? Right, I should have said: the udev rules never fire until a reboot. So the fingerprint reader doesn't work until a reboot. libfprint0 should trigger the udev rules when it installs them. I don't think that libfprint should be special-cased here. On my system, there are 32 different packages installing udev rules under /lib/udev/rules.d and libfprint is certainly not the only one that would benefit from udevadm trigger runs. That sound reasonable. I would definitely be happy with a solution that covers other packages. The only thing that might be different is that most other devices you can simply remove and plug in again. I can't do that with my build-in fingerprint reader. In my understanding of the situation of the udev rules, there is a requirement to reboot to have things working correctly; and that's nothing libfprint should fix for its own benefit. That doesn't sound reasonable to me! I'm not used to rebooting after I install packages, even if they are desktop-oriented. Thanks, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683937: grub-pc: install scripts should back up the MBR
Package: grub-pc
Version: 1.99-22.1
Severity: wishlist
Dear Maintainer,
When the grub-pc scripts install grub, they do not back up what was in
the MBR. Even if grub itself is reliable, the user may want to go back
to the old MBR. For example, I found after installing grub on my
Thinkpad X220 that pressing the ThinkVantage key during boot no longer
worked, because this functionality was in the original MBR.
Backing up the MBR should be cheap so there's really no reason not to do
it. (Same applies to installing grub to a partition.)
Andrew
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/main-root / ext4
rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0
/dev/sda3 /boot ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-SAMSUNG_MZ7PA128HMCD-010L1_S0MUNEAC122394
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=0
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 3.2.0-3-amd64' --class debian --class
gnu-linux --class gnu --class os {
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root
42ca7814-d762-4c2b-b92e-be29b9523705
echo'Loading Linux 3.2.0-3-amd64 ...'
linux /vmlinuz-3.2.0-3-amd64 root=/dev/mapper/main-root ro quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-3.2.0-3-amd64
}
menuentry 'Debian GNU/Linux, with Linux 3.2.0-3-amd64 (recovery mode)' --class
debian --class gnu-linux --class gnu --class os {
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root
42ca7814-d762-4c2b-b92e-be29b9523705
echo'Loading Linux 3.2.0-3-amd64 ...'
linux /vmlinuz-3.2.0-3-amd64 root=/dev/mapper/main-root ro single
echo'Loading initial ramdisk ...'
initrd /initrd.img-3.2.0-3-amd64
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/30_os-prober ###
menuentry Windows 7 (loader) (on /dev/sda1) --class windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 8AE45333E45320AD
chainloader +1
}
menuentry Windows 7 (loader) (on /dev/sda2) --class windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root CEB255D0B255BDA1
chainloader +1
}
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
*** END /boot/grub/grub.cfg
*** BEGIN /proc/mdstat
cat: /proc/mdstat: No such file or directory
*** END /proc/mdstat
*** BEGIN /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root 9 Aug 3 15:39
ata-SAMSUNG_MZ7PA128HMCD-010L1_S0MUNEAC122394 - ../../sda
lrwxrwxrwx 1 root root 10 Aug 3 15:39
ata-SAMSUNG_MZ7PA128HMCD-010L1_S0MUNEAC122394-part1 - ../../sda1
lrwxrwxrwx 1 root root 10 Aug 3 15:39
ata-SAMSUNG_MZ7PA128HMCD-010L1_S0MUNEAC122394-part2 - ../../sda2
lrwxrwxrwx 1 root root 10 Aug 3 15:39
ata-SAMSUNG_MZ7PA128HMCD-010L1_S0MUNEAC122394-part3 - ../../sda3
lrwxrwxrwx 1 root root 10 Aug 3 15:39
ata-SAMSUNG_MZ7PA128HMCD-010L1_S0MUNEAC122394-part4 - ../../sda4
lrwxrwxrwx 1 root root 10 Aug 3 08:39 dm-name-main-root - ../../dm-1
lrwxrwxrwx 1 root root 10 Aug 3 08:39 dm-name-main-swap - ../../dm-2
lrwxrwxrwx 1 root root 10 Aug 3 08:39 dm-name-sda4_crypt - ../../dm-0
lrwxrwxrwx
Bug#683942: xterm: alternate screen scrolling
Package: xterm Version: 278-1 Severity: wishlist Dear Maintainer, I used gnome-terminal recently and noticed that using the mouse wheel caused scrolling within apps like vim. I thought that was strange, because I disabled mouse support in vim. It turns out gnome-terminal has a feature called alternate screen scrolling. When you are in the alternate screen, it translates the mouse wheel into three up or down arrow presses. This is obviously a hack, but I want it. (I don't like enabling mouse support in vim because it takes over the mouse entirely, and as far as I understand there is no way for it to only take the wheel.) I thought I might be able to set up my own translations, but I don't think there is a way to define translations that apply only in the alternate screen. Is there another way for me to get this behavior? Andrew -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-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 xterm depends on: ii libc6 2.13-33 ii libfontconfig1 2.9.0-6 ii libice6 2:1.0.8-2 ii libtinfo5 5.9-10 ii libutempter01.1.5-4 ii libx11-62:1.5.0-1 ii libxaw7 2:1.0.10-2 ii libxft2 2.3.1-1 ii libxmu6 2:1.1.1-1 ii libxt6 1:1.1.3-1 ii xbitmaps1.1.1-1 Versions of packages xterm recommends: ii x11-utils 7.7~1 Versions of packages xterm suggests: pn xfonts-cyrillic 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#683859: aptitude: APT::Get::Build-Dep-Automatic is not honored
Package: aptitude Version: 0.6.8-1 Severity: normal Dear Maintainer, The apt-get build-dep command honors the APT::Get::Build-Dep-Automatic option (to mark installed packages as automatically installed). The aptitude build-dep command does not honor this option. It would be less confusing if both would honor this option. Andrew -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.8 compiled at Jun 9 2012 10:02:58 Compiler: g++ 4.7.0 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.2.10 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20110404 cwidget version: 0.5.16 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 = (0x7fff9e7ff000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7f039a89e000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f039a66e000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f039a444000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f039a23f000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f0399f3f000) libept.so.1.0.5.4.12 = /usr/lib/libept.so.1.0.5.4.12 (0x7f0399c9e000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f03998b9000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f03996a2000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f03993f6000) libboost_iostreams.so.1.49.0 = /usr/lib/libboost_iostreams.so.1.49.0 (0x7f03991dd000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f0398fc1000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f0398cb9000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f0398a37000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f0398821000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f0398499000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f0398296000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0398092000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f0397e81000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f0397c7c000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f0397a73000) /lib64/ld-linux-x86-64.so.2 (0x7f039b228000) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-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 aptitude depends on: ii aptitude-common 0.6.8-1 ii libapt-pkg4.120.9.7.2 ii libboost-iostreams1.49.0 1.49.0-3.1 ii libc6 2.13-33 ii libcwidget3 0.5.16-3.4 ii libept1.4.12 1.0.9 ii libgcc1 1:4.7.1-2 ii libncursesw5 5.9-10 ii libsigc++-2.0-0c2a2.2.10-0.2 ii libsqlite3-0 3.7.13-1 ii libstdc++64.7.1-2 ii libtinfo5 5.9-10 ii libxapian22 1.2.12-1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages aptitude recommends: ii apt-xapian-index0.45 pn aptitude-doc-en | aptitude-doc none pn libparse-debianchangelog-perl none ii sensible-utils 0.0.7 Versions of packages aptitude suggests: pn debtags none ii tasksel 3.11 -- 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#683863: libfprint0: udev rules not applied when libfprint0 is installed
Package: libfprint0 Version: 1:0.4.0-4-gdfff16f-4 Severity: normal Dear Maintainer, libfprint0 installs some udev rules to make fingerprint readers accessible to the plugdev group. However, since many fingerprint readers are built-in to computers, they are never plugged in, and thus the udev rules never fire. The result is that after installing the package, the fingerprint reader does not work for non-root users. libfprint0 should trigger the udev rules when it installs them. I think this can be done with the udevadm trigger command. By default, this will trigger change events for all devices. I'm not sure whether that could have undesirable consequences. You could limit the events to just fingerprint readers with a series of udevadm trigger --attr-match=idVendor= --attr-match=idProduct= Possible dh_installudev should help you with this. Andrew -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-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 libfprint0 depends on: ii libc6 2.13-33 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libnspr42:4.9.1-1 ii libnspr4-0d 2:4.9.1-1 ii libnss3 2:3.13.5-1 ii libnss3-1d 2:3.13.5-1 ii libusb-1.0-02:1.0.11-1 ii multiarch-support 2.13-33 libfprint0 recommends no packages. libfprint0 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#683866: aptitude does not have an autoremove command
Package: aptitude Version: 0.6.8-1 Severity: wishlist Dear Maintainer, aptitude does not have the autoremove command that apt-get has. There does not appear to be any way to uninstall automatically installed packages from the command line with aptitude. (I don't know if it is a goal to be able to do everything from the command line with aptitude, or to mirror every function of apt-get. The reason I would rather use aptitude than apt-get is that aptitude maintains a simple log file that is handy to refer to.) Andrew -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.8 compiled at Jun 9 2012 10:02:58 Compiler: g++ 4.7.0 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.2.10 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20110404 cwidget version: 0.5.16 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 = (0x7fffa89ff000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7fdb8e1e6000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fdb8dfb6000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fdb8dd8c000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fdb8db87000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7fdb8d887000) libept.so.1.0.5.4.12 = /usr/lib/libept.so.1.0.5.4.12 (0x7fdb8d5e6000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7fdb8d201000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fdb8cfea000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fdb8cd3e000) libboost_iostreams.so.1.49.0 = /usr/lib/libboost_iostreams.so.1.49.0 (0x7fdb8cb25000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fdb8c909000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fdb8c601000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fdb8c37f000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fdb8c169000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fdb8bde1000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fdb8bbde000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fdb8b9da000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fdb8b7c9000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fdb8b5c4000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fdb8b3bb000) /lib64/ld-linux-x86-64.so.2 (0x7fdb8eb7) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-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 aptitude depends on: ii aptitude-common 0.6.8-1 ii libapt-pkg4.120.9.7.2 ii libboost-iostreams1.49.0 1.49.0-3.1 ii libc6 2.13-33 ii libcwidget3 0.5.16-3.4 ii libept1.4.12 1.0.9 ii libgcc1 1:4.7.1-2 ii libncursesw5 5.9-10 ii libsigc++-2.0-0c2a2.2.10-0.2 ii libsqlite3-0 3.7.13-1 ii libstdc++64.7.1-2 ii libtinfo5 5.9-10 ii libxapian22 1.2.12-1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages aptitude recommends: ii apt-xapian-index0.45 pn aptitude-doc-en | aptitude-doc none pn libparse-debianchangelog-perl none ii sensible-utils 0.0.7 Versions of packages aptitude suggests: pn debtags none ii tasksel 3.11 -- 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#683859: [Aptitude-devel] Bug#683859: aptitude: APT::Get::Build-Dep-Automatic is not honored
Excerpts from Axel Beckert's message of Sat Aug 04 14:51:35 -0700 2012: Andrew Pimlott wrote: The apt-get build-dep command honors the APT::Get::Build-Dep-Automatic option (to mark installed packages as automatically installed). The aptitude build-dep command does not honor this option. It would be less confusing if both would honor this option. I'm not sure if that would work as expected, because in comparison to apt-get (which just tells the user about no more needed packages by default), aptitude automatically uninstalls by default all packages which are marked as automatically installed and which have not at least one reverse dependency installed. This means aptitude would uninstall all those packages on the next aptitude run. I agree this may be less than ideal (a way to hold off the automatic uninstalls until ready would be nice), but it is still very useful: 1. Often you only want the build-deps for the duration of a build, so the next run of aptitude is the right time to uninstall. 2. aptitude won't automatically uninstall packages at the command line (except in the case you explicitly remove packages that allow others to be uninstalled). If you work mostly at the command line, there is no problem. (Except that the autoremove command is not there, as per my other bug, so you need to enter the UI for that.) 3. In the UI, you can hold off the uninstalls by installing with the 'I' command. So there would still be a lot of value for me! However, your point might argue for making it a different option, instead of reusing APT::Get::Build-Dep-Automatic. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683866: aptitude does not have an autoremove command
Excerpts from Andrew Pimlott's message of Sat Aug 04 20:06:36 -0700 2012: Excerpts from Daniel Hartwig's message of Sat Aug 04 17:53:08 -0700 2012: aptitude does not have the autoremove command that apt-get has. There does not appear to be any way to uninstall automatically installed packages from the command line with aptitude. Aptitude operates under the principal that you either wish for it to manage unused packages, or you do not. The default is the manage unused packages but this can be changed by setting Aptitude::Delete-Unused 0. When managing unused packages any action will cause their removal: Thanks for the explanation. I have had Delete-Unused set to true forever, so I guess I forgot that this is the default behavior. Wait, I got confused: so Delete-Unused true (my setting) is the default behavior. I definitely don't see automatically installed but unused packages deleted on any action. For example, right now, I have an automatically installed but unused package. If I go into the UI and press 'g', the unused package is about to be removed. But if run aptitude install on some random package: % sudo aptitude install -s unclutter The following NEW packages will be installed: unclutter 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded It is not about to remove the unused package. So it's far from true that any action will cause their removal. In my experience, typical command line use practically never causes automatic removal. Still, your workaround for lack of autoremove holds, so I no longer have a complaint! Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683859: closed by Daniel Hartwig mand...@gmail.com (Re: Bug#683859: aptitude: APT::Get::Build-Dep-Automatic is not honored)
Excerpts from owner's message of Sat Aug 04 18:15:03 -0700 2012: On 5 August 2012 06:49, Andrew Pimlott and...@pimlott.net wrote: (a way to hold off the automatic uninstalls until ready would be nice), Such an option exists: Aptitude::Delete-Unused. Fair. 1. Often you only want the build-deps for the duration of a build, so the next run of aptitude is the right time to uninstall. Build-Dep-Automatic is a hack used by apt-get because it lacks a better means of tracking sets of packages. Auto-installed is not intended for temporary installs but tracking packages which are installed only as dependencies of another. Aptitude provides for tracking sets of packages: # aptitude --add-user-tag foo-builddep build-dep foo I had no idea, thanks for making me aware of this! It seems like a much better solution. I'll definitely start using it. [then, after make foo] # aptitude --remove-user-tag foo-builddep '?user-tag(foo-builddep)' Did you mean to add an unmarkauto to this command? Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683866: aptitude does not have an autoremove command
Excerpts from Daniel Hartwig's message of Sat Aug 04 17:53:08 -0700 2012: aptitude does not have the autoremove command that apt-get has. There does not appear to be any way to uninstall automatically installed packages from the command line with aptitude. Aptitude operates under the principal that you either wish for it to manage unused packages, or you do not. The default is the manage unused packages but this can be changed by setting Aptitude::Delete-Unused 0. When managing unused packages any action will cause their removal: Thanks for the explanation. I have had Delete-Unused set to true forever, so I guess I forgot that this is the default behavior. An explicit autoremove command is useful for a user who has Delete-Unused set false. In this case it would be equivalent to: # aptitude -oAptitude::Delete-Unused=1 install Thanks for the tip, that helps me! Generally it is not our goal to mirror every function of apt-get, that is not particularly useful. Aptitude is a high-level interface with semantics different to the apt-utils: if you need apt-get for a given task, use apt-get. One reason I prefer to do everything with aptitude is its handy log. If I switch to apt-get for some operations, some thing are logged and others are not. (I do know about dpkg's log.) Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683747: installation-reports: partitioning gets wedged after selecting empty partitions for LVM
Package: installation-reports Severity: normal Tags: d-i Dear Maintainer, My computer came with three NTFS partitions, primaries 1-3. During install, I resized partitions 2 and 3, leaving: primary 1 (NTFS) primary 2 (NTFS) empty space primary 3 (NTFS) empty space I went to Configure Logical Volume Manager, created a volume group, and selected the two empty spaces to go into it. This resulted in a helpful dialog with title [!!] Partition Disks and contents ??? ???. After that, things went wrong: some menu options no longer appeared or didn't work. Finally, I went back to the main menu, and when I selected Partition disks, it just returned me to the main menu. I had to restart. I think the reason is that it is not possible to turn both empty spaces into partitions, due to the limit of 4 primary partitions. But the partitioning tool did not detect this condition gracefully. (I am reporting the bug from a different computer, but I don't think the hardware details matter.) Andrew PS. The ability to mount and examine NTFS partitions in the installer wolud be nice. Boot method: network Image version: Wheezy Alpha1 (http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/ as of 2012-08-02) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683770: installation-reports: when installing GRUB, says it can't find another operating system
Package: installation-reports Severity: normal Tags: d-i Dear Maintainer, When I got to the GRUB installation stage of my install, I got the message: It seems that this new installation is the only operating system on this computer. But this is incorrect: Windows 7 is occupying two primary NTFS partitions, /dev/sda1 and /dev/sda2. sda1 is the SYSTEM_DRV volume, and sda2 is Windows. Not sure why from reading syslog. If I mount /dev/sda2 on /mnt and run /usr/lib/os-probse/mounted/20microsoft /dev/sd2 /mnt ntfs, it prints: /dev/sda2:Windows Vista (loader):Windows1:chain I went ahead and install GRUB an the MBR, and found that /dev/sda1 and /dev/sda2 were both added to the GRUB menu as bootable Windows partitions (and booting them works). (Probably only /dev/sda1 should have been added because including both is redundant, but that's a detail.) I am reporting the bug from a different computer, but I don't think the hardware matters. Andrew Boot method: network Image version: Wheezy Alpha1 (http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/ as of 2012-08-02) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending
Excerpts from Ben Hutchings's message of Tue Jan 24 20:01:16 -0800 2012: I doubt it's going to make any difference, but could you please check whether this is fixed in the current version in unstable (3.2.1-2)? (You should install that anyway as it has an important security fix.) Thanks and sorry for not following up sooner. I don't believe I managed to reproduce the problem again after reporting the bug, even with the same kernel version. After further thought, I suspect it is more likely a computer issue than a kernel issue, with something physically triggering the resume. (One clue is that the resume only seemed to happen after I had put my computer away in the bag. Probably some motion or pressure was doing it.) I think you can close this and I'll open it again if I get new information. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657060: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending)
Excerpts from owner's message of Tue Apr 24 18:57:04 -0700 2012: It's conceivable that a lid switch might fail in such a way as to cause an unwanted wakeup. But I would usually suspect a software bug (or a hardware quirk that should probably be worked around in software). Since we've now moved on to 3.2, it may well be that such a bug has been fixed. Well, I've re-enabled the BIOS option to make a beep when resuming. That will help me pinpoint the problem if it happens again. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664217: synergy: crash when pasting client clipboard into Google Chrome
I can still reproduce the problem using synergyc from the same package version, 1.3.8-1. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664217: synergy: crash when pasting client clipboard into Google Chrome
Package: synergy Version: 1.3.8-1 Severity: normal Dear Maintainer, I can reproducibly crash my local synergys by copying text on the synergy client host, then trying to paste it into the Google Chrome URL bar by middle-clicking. When I run synergys --address 127.0.0.1 --no-daemon under gdb, I get the following stack trace: Program received signal SIGSEGV, Segmentation fault. 0xb7fbe18d in pthread_mutex_lock () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (gdb) where #0 0xb7fbe18d in pthread_mutex_lock () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #1 0x0811e15f in CArchMultithreadPosix::lockMutex(CArchMutexImpl*) () #2 0x0811be4d in CArch::lockMutex(CArchMutexImpl*) () #3 0x0811ce6e in IArchString::convStringWCToMB(char*, wchar_t const*, unsigned int, bool*) () #4 0x0811c7ec in CArch::convStringWCToMB(char*, wchar_t const*, unsigned int, bool*) () #5 0x081a1469 in CUnicode::UTF8ToText(std::string const, bool*) () #6 0x0815086c in CXWindowsClipboardTextConverter::fromIClipboard(std::string const) const () #7 0x08147a7f in CXWindowsClipboard::addSimpleRequest(unsigned long, unsigned long, unsigned long, unsigned long) () #8 0x08147896 in CXWindowsClipboard::addRequest(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long) () #9 0x0813ba01 in CXWindowsScreen::handleSystemEvent(CEvent const, void*) () #10 0x08142dbf in TMethodEventJobCXWindowsScreen::run(CEvent const) () #11 0x08123027 in CEventQueue::dispatchEvent(CEvent const) () #12 0x08118748 in ?? () #13 0x081189b9 in ?? () #14 0x08118a94 in ?? () #15 0x08119cc9 in main () There are no log messages from synergys immediatly before the crash. My synergyc is Debian version 1.3.1-5 from squeeze. It is tunnelled over ssh. Pasting into other applications, for example an xterm, works fine. It is only pasting into Chrome that breaks. And of course, pasting into Chrome from a local selection works. Andrew -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-1-486 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 synergy depends on: ii libc6 2.13-27 ii libgcc1 1:4.6.2-16 ii libice6 2:1.0.7-2 ii libsm62:1.2.0-2 ii libstdc++64.6.2-16 ii libx11-6 2:1.4.4-4 ii libxext6 2:1.3.0-3 ii libxi62:1.4.5-1 ii libxinerama1 2:1.1.1-3 ii libxtst6 2:1.2.0-4 synergy recommends no packages. synergy 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#663932: slapd: upgrade script does not handle /var/lib/ldap as symlink
Package: slapd Version: 2.4.23-7.2 Severity: normal On my system, /var/lib/ldap is a symlink (to higher-reliability storage than my root device). I'm not sure whether this configuration is intended to be supported, but it has worked for me so far. However, during the upgrade from lenny to squeeze, I had one problem. After the database was dumped and loaded, the upgrade script tries to chown the new data files to the openldap user/group. This is starting at line 249 of slapd.postinst: echo -n - chowning database directory ($SLAPD_USER:$SLAPD_GROUP)... [ -z $SLAPD_USER ] || \ chown -R $SLAPD_USER $dbdir [ -z $SLAPD_GROUP ] || \ chgrp -R $SLAPD_GROUP $dbdir echo done; This fails because it only changes the permission of the symlink, not the target. A simple fix would be to change it to chown -R $SLAPD_USER $dbdir/ chgrp -R $SLAPD_GROUP $dbdir/ In fact, this is done in other places in slapd.postinst, so maybe this one just got missed. This is the only problem I found. It would be nice for me if this change were applied, and if this configuration were officially supported. Thanks! Andrew -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages slapd depends on: ii adduser3.112+nmu2add and remove users and groups ii coreutils 8.5-1 GNU core utilities ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.11.3-2 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libgnutls262.8.6-1+squeeze1 the GNU TLS library - runtime libr ii libldap-2.4-2 2.4.23-7.2OpenLDAP libraries ii libltdl7 2.2.6b-2 A system independent dlopen wrappe ii libperl5.105.10.1-17squeeze3 shared Perl library ii libsasl2-2 2.1.23.dfsg1-7Cyrus SASL - authentication abstra ii libslp11.2.1-7.8 OpenSLP libraries ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii perl [libmime-base64-p 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii psmisc 22.11-1 utilities that use the proc file s ii unixodbc 2.2.14p2-1ODBC tools libraries Versions of packages slapd recommends: ii libsasl2-modules 2.1.23.dfsg1-7 Cyrus SASL - pluggable authenticat Versions of packages slapd suggests: ii ldap-utils2.4.23-7.2 OpenLDAP utilities -- Configuration Files: /etc/default/slapd changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546368: no database configured for that naming context on Squeeze upgrade
I had another case of this same problem on Squeeze upgrade. It was quite confusing to me, as I am not experienced with LDAP and only had it installed for another application. I changed the root DN after the initial install, because the other application required it. I had no idea that this would put my database in a conflicting state. It would be really nice to help the user with this issue. I agree with the suggestions from Dmitri. But even simpler than that, you could point to some troubleshooting documentation when the reload fails, with clear instructions on how to resolve the problem: Open up the .ldif backup in a text editor. Modify the DN of the first two entries to match the current rootdn. Or maybe just delete these first two entries? I'm not sure what they're for. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending
Package: linux-2.6 Version: 3.1.8-2 Severity: important Dear Maintainer, For the last several kernel releases, I have had an intermittent problem suspending my Thinkpad X40. A high fraction of the time, after I suspend (running pm-suspend), the system seems to go to sleep (the screen goes off and the moon light comes on), then comes back by itself a couple minutes later. Of course, the laptop is usually in my bag by this point. Worse, pm-suspend returns a successful 0 exit status, so there's no way I can sound an alert. The logs aren't very helpful, but I hope you can make something of them on at least point me to where I can get more help. In this instance, I ran pm-suspend at 09:13:45, and the system came back on its own at 09:15:22. Here is an excerpt from /var/log/pm-suspend.log: Mon Jan 23 09:13:45 PST 2012: performing suspend KMS graphics driver is in use, skipping quirks. Mon Jan 23 09:15:22 PST 2012: Awake. Here is an excerpt from /var/log/kern.log: Jan 23 09:13:46 apple kernel: [ 4407.572159] PM: Syncing filesystems ... done. Jan 23 09:13:46 apple kernel: [ 4407.574433] PM: Preparing system for mem sleep Jan 23 09:15:22 apple kernel: [ 4407.617900] Freezing user space processes ... (elapsed 0.01 seconds) done. Jan 23 09:15:22 apple kernel: [ 4407.632227] Freezing remaining freezable tasks ... (elapsed 0.11 seconds) done. Jan 23 09:15:22 apple kernel: [ 4407.744205] PM: Entering mem sleep ... Jan 23 09:15:22 apple kernel: [ 4408.352342] ACPI: Preparing to enter system sleep state S3 Jan 23 09:15:22 apple kernel: [ 4408.552054] PM: Saving platform NVS memory Jan 23 09:15:22 apple kernel: [ 4408.552127] Extended CMOS year: 2000 Jan 23 09:15:22 apple kernel: [ 4408.552127] ACPI: Low-level resume complete ... Jan 23 09:15:22 apple kernel: [ 4411.122275] PM: Finishing wakeup. Jan 23 09:15:22 apple kernel: [ 4411.122279] Restarting tasks ... done. (I realize that the syslog timestamp just reflects when the message got to syslogd, and the kernel timestamp isn't updated on resume.) There are no messages indicating that anything went wrong. So I don't understand why it woke up. The pattern of log messages is very similar (just some small ordering differences) whether the resume was at my command or not. Any ideas? I don't have any automated wake-ups, such as wake-on-lan or rtcwake, as far as I know. Complete pm-suspend.log and kern.log from the failed suspend are attached. Andrew -- Package-specific info: ** Version: Linux version 3.1.0-1-486 (Debian 3.1.8-2) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-11) ) #1 Tue Jan 10 04:55:10 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-486 root=UUID=73cf35da-d145-4e4b-b662-3849f9a0ae64 ro ** Not tainted ** Kernel log: [ 4409.648033] uhci_hcd :00:1d.0: power state changed by ACPI to D0 [ 4409.648042] uhci_hcd :00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10b) [ 4409.648057] uhci_hcd :00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x1821) [ 4409.648073] uhci_hcd :00:1d.0: restoring config space at offset 0x1 (was 0x280, writing 0x281) [ 4409.648085] uhci_hcd :00:1d.0: power state changed by ACPI to D0 [ 4409.648091] uhci_hcd :00:1d.0: power state changed by ACPI to D0 [ 4409.648099] uhci_hcd :00:1d.1: power state changed by ACPI to D0 [ 4409.648106] uhci_hcd :00:1d.1: power state changed by ACPI to D0 [ 4409.648114] uhci_hcd :00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b) [ 4409.648129] uhci_hcd :00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x1841) [ 4409.648144] uhci_hcd :00:1d.1: restoring config space at offset 0x1 (was 0x280, writing 0x281) [ 4409.648155] uhci_hcd :00:1d.1: power state changed by ACPI to D0 [ 4409.648161] uhci_hcd :00:1d.1: power state changed by ACPI to D0 [ 4409.648171] uhci_hcd :00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b) [ 4409.648186] uhci_hcd :00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x1861) [ 4409.648201] uhci_hcd :00:1d.2: restoring config space at offset 0x1 (was 0x280, writing 0x281) [ 4409.648223] ehci_hcd :00:1d.7: restoring config space at offset 0xf (was 0x400, writing 0x40b) [ 4409.648244] ehci_hcd :00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xd010) [ 4409.648256] ehci_hcd :00:1d.7: restoring config space at offset 0x1 (was 0x290, writing 0x2900102) [ 4409.648275] ehci_hcd :00:1d.7: power state changed by ACPI to D0 [ 4409.648282] ehci_hcd :00:1d.7: power state changed by ACPI to D0 [ 4409.648342] ata_piix :00:1f.1: restoring config space at offset 0x9 (was 0x0, writing 0x5000) [ 4409.648358] ata_piix :00:1f.1: restoring config space at offset 0x1 (was 0x285, writing 0x287) [ 4409.648409] snd_intel8x0
Bug#647955: ifplugd: Plug in cable while on wireless - no default route
Package: ifplugd Version: 0.28-19 Severity: normal Dear Maintainer, I run ifplugd on my eth0 ethernet interface, and use wpa_supplicant for my eth1 wireless interface. When I am on wireless and plug in my ethernet cable, I often (but not always) end up with a configured eth0 interface but no default route. This happens due to a race condition between eth1 going down and eth0 coming up. I don't think this is necesarily ifplugd's fault, but I file it here so you can help route it to the right place. Here is what happens: 1. ifplugd detects the ethernet interface. 2. ifplugd runs /etc/ifplugd/action.d/action_wpa. This calls wpa_cli -i eth1 disconnect, which takes down the eth1 interface asynchronously. 3. ifplugd runs /etc/ifplugd/action.d/ifupdown. This calls ifup eth0, which brings up the eth0 interface using dhcp (in my configuration). 4. When dhclient gets a lease, it calls /sbin/dhclient-script, which calls something like ip -4 route add default via 192.168.1.1 dev eth0 Unfortunately, at this point, since eth1 was taken down asynchronously, it may still have the default route. When this command is run while eth1 has the default route, it fails with RTNETLINK answers: File exists I can think of three possible solutions: - wpasupplicant provides a synchronous call to take down the interface. - ifplugd polls for the wireless interfaces to finish going down. - isc-dhcp-client enables setting multiple default routes, so eth0 and eth1 both have default routes for the brief period where they coexist. The last of these seems most logical to me, but from what I understand it may be difficult to configure. Maybe isc-dhcp-client could take over the default route unconditionally. Anyhow, I would appreciate your advice. Andrew -- Package-specific info: /sys/class/net/ interfaces: /sys/class/net/eth0/ /sys/class/net/eth1/ /sys/class/net/lo/ -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-486 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 ifplugd depends on: ii debconf [debconf-2.0] 1.5.41 ii libc6 2.13-21 ii libdaemon0 0.14-2 ii lsb-base 3.2-28 Versions of packages ifplugd recommends: ii ifupdown 0.7~alpha5+really0.6.16 Versions of packages ifplugd suggests: ii wpasupplicant 0.7.3-5 -- debconf information: * ifplugd/interfaces: eth0 * ifplugd/hotplug_interfaces: * ifplugd/args: -f -u0 -d10 -w -I --no-beep * ifplugd/suspend_action: stop -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647955: ifplugd: Plug in cable while on wireless - no default route
Log (daemon.log) for a problem case. Note the interleaving of eth0 and eth1 events. Nov 7 14:07:27 apple ifplugd(eth0)[27270]: Link beat detected. Nov 7 14:07:27 apple ifplugd(eth0)[27270]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Nov 7 14:07:27 apple ifplugd(eth0)[27270]: client: OK Nov 7 14:07:27 apple wpa_supplicant[1536]: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=0 Nov 7 14:07:28 apple dhclient: Internet Systems Consortium DHCP Client 4.2.2 Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: Internet Systems Consortium DHCP Client 4.2.2 Nov 7 14:07:28 apple dhclient: Copyright 2004-2011 Internet Systems Consortium. Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: Copyright 2004-2011 Internet Systems Consortium. Nov 7 14:07:28 apple dhclient: All rights reserved. Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: All rights reserved. Nov 7 14:07:28 apple dhclient: For info, please visit https://www.isc.org/software/dhcp/ Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: For info, please visit https://www.isc.org/software/dhcp/ Nov 7 14:07:28 apple dhclient: Nov 7 14:07:28 apple dhclient: Listening on LPF/eth0/00:0a:e4:26:95:59 Nov 7 14:07:28 apple dhclient: Sending on LPF/eth0/00:0a:e4:26:95:59 Nov 7 14:07:28 apple dhclient: Sending on Socket/fallback Nov 7 14:07:28 apple dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: Listening on LPF/eth0/00:0a:e4:26:95:59 Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: Sending on LPF/eth0/00:0a:e4:26:95:59 Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: Sending on Socket/fallback Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 Nov 7 14:07:28 apple dhclient: Internet Systems Consortium DHCP Client 4.2.2 Nov 7 14:07:28 apple dhclient: Copyright 2004-2011 Internet Systems Consortium. Nov 7 14:07:28 apple dhclient: All rights reserved. Nov 7 14:07:28 apple dhclient: For info, please visit https://www.isc.org/software/dhcp/ Nov 7 14:07:28 apple dhclient: Nov 7 14:07:28 apple dhclient: Listening on LPF/eth1/00:0c:f1:3e:02:61 Nov 7 14:07:28 apple dhclient: Sending on LPF/eth1/00:0c:f1:3e:02:61 Nov 7 14:07:28 apple dhclient: Sending on Socket/fallback Nov 7 14:07:28 apple avahi-daemon[1906]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::20a:e4ff:fe26:9559. Nov 7 14:07:28 apple avahi-daemon[1906]: New relevant interface eth0.IPv6 for mDNS. Nov 7 14:07:28 apple avahi-daemon[1906]: Registering new address record for fe80::20a:e4ff:fe26:9559 on eth0.*. Nov 7 14:07:28 apple dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Nov 7 14:07:28 apple dhclient: DHCPOFFER from 192.168.1.1 Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: DHCPOFFER from 192.168.1.1 Nov 7 14:07:28 apple dhclient: DHCPACK from 192.168.1.1 Nov 7 14:07:28 apple ifplugd(eth0)[27270]: client: DHCPACK from 192.168.1.1 Nov 7 14:07:29 apple dhclient: DHCPRELEASE on eth1 to 192.168.1.1 port 67 Nov 7 14:07:29 apple ifplugd(eth0)[27270]: client: Reloading /etc/samba/smb.conf: smbd only. Nov 7 14:07:29 apple avahi-daemon[1906]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.146. Nov 7 14:07:29 apple avahi-daemon[1906]: New relevant interface eth0.IPv4 for mDNS. Nov 7 14:07:29 apple avahi-daemon[1906]: Registering new address record for 192.168.1.146 on eth0.IPv4. Nov 7 14:07:30 apple dhclient: bound to 192.168.1.146 -- renewal in 38019 seconds. Nov 7 14:07:30 apple ifplugd(eth0)[27270]: client: bound to 192.168.1.146 -- renewal in 38019 seconds. Nov 7 14:07:30 apple avahi-daemon[1906]: Withdrawing address record for 192.168.1.102 on eth1. Nov 7 14:07:30 apple avahi-daemon[1906]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.1.102. Nov 7 14:07:30 apple avahi-daemon[1906]: Interface eth1.IPv4 no longer relevant for mDNS. Nov 7 14:07:30 apple avahi-daemon[1906]: Interface eth1.IPv6 no longer relevant for mDNS. Nov 7 14:07:30 apple avahi-daemon[1906]: Leaving mDNS multicast group on interface eth1.IPv6 with address fe80::20c:f1ff:fe3e:261. Nov 7 14:07:30 apple avahi-daemon[1906]: Withdrawing address record for fe80::20c:f1ff:fe3e:261 on eth1. Andrew Excerpts from Andrew Pimlott's message of Mon Nov 07 14:04:21 -0800 2011: Package: ifplugd Version: 0.28-19 Severity: normal Dear Maintainer, I run ifplugd on my eth0 ethernet interface, and use wpa_supplicant for my eth1 wireless interface. When I am on wireless and plug in my ethernet cable, I often (but not always) end up with a configured eth0 interface but no default route. This happens due to a race condition between eth1 going down and eth0 coming up. I don't think this is necesarily ifplugd's fault, but I file it
Bug#625782: exim4-config: dkim should not try sign when forwarding
Package: exim4-config
Version: 4.72-6
Severity: normal
I have dkim signing enabled using the debian DKIM_* macros. When mail
is forwarded using .forward, exim still tries to look up a key for the
domain. When it fails, it logs a warning that goes both to mainlog and
paniclog. (I think the latter is a separate issue, bug 567876.)
I can't immediately figure out how to disable signing for forwarded
messages. If you can give me a hint as to how I might accomplish this,
I'll try to work it out. It seems like this should be the default,
since forwarded mails are not generally from a domain I control, and
they should have already been signed upstream.
Andrew
-- Package-specific info:
Exim version 4.72 #1 built 31-Jan-2011 19:18:05
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 4.8.30: (April 9, 2010)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch
nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
GnuTLS compile-time version: 2.8.6
GnuTLS runtime version: 2.8.6
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to replace
# the DEBCONFsomethingDEBCONF strings in the configuration template files.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file
dc_eximconfig_configtype='internet'
dc_other_hostnames='pimlott.net;madstop.net'
dc_local_interfaces=''
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
mailname:pimlott.net
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30.5-xenU (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 exim4-config depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
exim4-config recommends no packages.
exim4-config suggests no packages.
-- Configuration Files:
/etc/exim4/conf.d/auth/30_exim4-config_examples changed:
plain_server:
driver = plaintext
public_name = PLAIN
server_condition = ${if
crypteq{$auth3}{${extract{1}{:}{${lookup{$auth2}lsearch{CONFDIR/passwd}{$value}{*:*}{1}{0}}
server_set_id = $auth2
server_prompts = :
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
cram_md5:
driver = cram_md5
public_name = CRAM-MD5
client_name =
${extract{1}{:}{${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$value}fail}}}
client_secret =
${extract{2}{:}{${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$value}fail}}}
PASSWDLINE=${sg{\
${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$value}fail}\
}\
{\\N[\\^]\\N}\
{^^}\
}
plain:
driver = plaintext
public_name = PLAIN
.ifndef AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS
client_send = ; ${if !eq{$tls_cipher}{}\
{^${extract{1}{:}{PASSWDLINE}}\
^${sg{PASSWDLINE}{\\N([^:]+:)(.*)\\N}{\\$2}}\
}fail}
.else
client_send = ; ^${extract{1}{:}{PASSWDLINE}}\
^${sg{PASSWDLINE}{\\N([^:]+:)(.*)\\N}{\\$2}}
.endif
login:
driver = plaintext
public_name = LOGIN
.ifndef AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS
# Return empty string if not non-TLS AND looking up $host in passwd-file
# yields a non-empty string; fail otherwise.
client_send = ; ${if and{\
{!eq{$tls_cipher}{}}\
{!eq{PASSWDLINE}{}}\
}\
{}fail}\
; ${extract{1}{::}{PASSWDLINE}}\
; ${sg{PASSWDLINE}{\\N([^:]+:)(.*)\\N}{\\$2}}
.else
# Return empty string if looking up $host in passwd-file yields a
# non-empty string; fail otherwise.
client_send = ; ${if !eq{PASSWDLINE}{}\
{}fail}\
; ${extract{1}{::}{PASSWDLINE}}\
;
Bug#607576: closed by Andreas Metzler ametz...@downhill.at.eu.org (Re: Bug#607576: exim4-config: after upgrade, /etc/exim4/exim4.conf is present and breaks exim)
A belated thank-you for informing me of this issue. I'm sure you are right and it is correct to close the bug. Andrew Excerpts from owner's message of Sun Apr 17 10:06:04 -0700 2011: This is an automatic notification regarding your Bug report which was filed against the exim4 package: #607542: exim4-config: after upgrade, /etc/exim4/exim4.conf is present and breaks exim It has been closed by Andreas Metzler ametz...@downhill.at.eu.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Andreas Metzler ametz...@downhill.at.eu.org by replying to this email. On 2010-12-20 Andreas Metzler ametz...@downhill.at.eu.org wrote: [...] Looks like your system has been hacked, [...] closing. cu andreas Package: exim4-config Version: 4.69-9+lenny1 Severity: important I have a locally-compiled exim4-daemon-custom package, along with the standard exim4, exim4-base, and exim4-config packages. Recently, they were all at 4.69-9 when 4.69-9+lenny1 hit security. aptitude prompted me to upgrade exim4, exim4-base, and exim4-config from 4.69-9 - 4.69-9+lenny1, and I accepted--probably foolishly, since exim4-daemon-custom was still at 4.69-9. The result was a major failure. All of my incoming mail that should have been delivered was rejected relay not permitted. For every reject, mainlog had: 2010-12-18 06:27:22 no IP address found for host MAIN_RELAY_NETS (during SMTP connection from [69.147.233.108]) 2010-12-18 06:27:22 H=[69.147.233.108] F=web...@jetline1.com rejected RCPT and...@pimlott.net: relay not permitted Actually, this did not happen right away, because the package updates didn't restart the daemon. It was only after a routine daemon restart that the failures started. I have resolved the problem, but I can't really figure out what happened. The odd thing I noticed is that when things weren't working, I had an /etc/exim4/exim4.conf. Since I've always used Debconf and the split configuration, I did not expect this file to be present. (But I am not positive it was not present before, and I don't have a convenient backup to check.) It looks like exim4 was taking this config file in preference to the auto-generated one. This exim4.conf is identical to exim4.conf.template, except for whitespace changes. Also, it is mode 0400 and owned by Debian-exim. When I move this file out of the way, things start working again. So is it possible that my upgrade somehow created the exim4.conf that broke my configuration? I understand that getting my packages out of sync the way I did is probably not supported, but I would still like to get to the bottom of this. By the way, my custom package was for SRS and DomainKeys. I don't have a lot of custom configuration. Andrew -- Package-specific info: Exim version 4.69 #1 built 03-Jan-2010 17:26:17 Copyright (c) University of Cambridge 2006 Berkeley DB: Berkeley DB 4.6.21: (September 27, 2007) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages Experimental_SRS Experimental_DomainKeys Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to replace # the DEBCONFsomethingDEBCONF strings in the configuration template files. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='internet' dc_other_hostnames='pimlott.net;madstop.net' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='' CFILEMODE='644' dc_use_split_config='true' dc_hide_mailname='' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:pimlott.net -- System Information: Debian Release: 5.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30.5-xenU (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 exim4-config
Bug#622821: wpasupplicant: reassociates after disconnect
Excerpts from Kel Modderman's message of Fri Apr 15 04:14:16 -0700 2011: On Fri, 15 Apr 2011 07:36:00 AM Andrew Pimlott wrote: * After a disconnected event, attempt to reassociate to a network when using wpa-roam. If I'm understanding this correctly, I don't see the sense in this. I tend to agree with you, and what's more I cannot recall what information or events led to the decision to introduce this behaviour. Would have to dig deep through the history... Would you be able to propose in patch form, the changes you would like? The original change is svn r1537, but it doesn't tell us why. I guess I'm suggesting to revert the change to debian/ifupdown/wpa_action in that commit: Index: debian/ifupdown/wpa_action === --- debian/ifupdown/wpa_action (revision 1578) +++ debian/ifupdown/wpa_action (working copy) @@ -54,7 +54,6 @@ wpa_hysteresis_check || exit 1 ifdown if_post_down_up - wpa_cli reassociate ;; stop|down) Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574376: [mod-security-users] ModSecurity segfaults
Following up on a very old thread (below). Brian, thanks for your very useful instructions, and sorry for not following them sooner. Excerpts from Brian Rectanus's message of Sat Mar 20 14:51:16 -0700 2010: Often if you upgrade/replace mod_security2.so on a running httpd you will see this (repeating segfaults) until you RESTART httpd. This is my In short, I did not (the Debian package did not) restart apache after installing mod_security, only graceful restarted, which you indicate is not a supported way to install or upgrade. That's all anyone needs to read, but just for completeness: I got the core dump using your instructions, but running gdb on it produced the same stack trace that I originally posted in the Debian bug: ... ap_process_request ap_run_log_transaction (mod_security) apr_global_mutex_lock segfault Not sure why the trace up to ap_run_error_log didn't look as expected. I am using the prefork MPM, apache 2.2.9 from Debian lenny (2.2.9-10+lenny9), and mod_security 2.5.11 from Debian lenny-backports (2.5.11-1~bpo50+1). The steps to reproduce: 1. Start apache without mod_security installed (or configured obviously). 2. Configure mod_security. My config is very simple: SecRuleEngine On SecAuditEngine RelevantOnly SecRequestBodyAccess On SecRequestBodyLimit 1073741824 SecRequestBodyNoFilesLimit 65536 SecAuditLog /var/log/apache2/post.log SecAuditLogParts AIZ SecRule REQUEST_METHOD POST nolog,auditlog No core rules or anything. 3. Install mod_security via the Debian package. This reloads (graceful restarts) apache. 4. Make a request that would trigger audit logging (POST request). Segfault. 5. Reload apache again--no more segfaults! Probably a fluke. I think the resolution, for the Debian bug, is that apache must be restarted, not just reloaded after libapache-mod-security is installed. Or, based on my experiments, you could reload it twice. :-) Andrew Excerpts from Brian Rectanus's message of Sat Mar 20 14:51:16 -0700 2010: Alberto Gonzalez Iniesta wrote: Hi, I got this [1] bug report about ModSecurity segfaulting. I couldn't reproduce it, it may be related to the arch of the reporter (x86_64). Please, feel free to write to the bug report (574...@bugs.debian.org) if you need further information. Thanks, Alberto [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574376 Normally a backtrace of the thread/process causing the core will show something like this: #0 0x7f05edc257d0 in ?? () No symbol table info available. #1 0x0044990d in ap_run_error_log () No symbol table info available. #2 0x00448678 in log_error_core () No symbol table info available. #3 0x004487a3 in ap_log_error () No symbol table info available. #4 0x0044f12a in sig_coredump () No symbol table info available. #5 signal handler called No symbol table info available. #6 0x7f05edc257d0 in ?? () No symbol table info available. #7 0x0044990d in ap_run_error_log () No symbol table info available. So I am thinking that this backtrace is not of the thread/process that caused the segfault. Often if you upgrade/replace mod_security2.so on a running httpd you will see this (repeating segfaults) until you RESTART httpd. This is my best guess given the info here. In order to do more I need a backtrace generated from a core. Can you configure Apache to dump core and reproduce it? Make sure there is a core dump area with something like: CoreDumpDirectory /tmp Make sure limits are set to dump core: ulimit -c unlimited Restart and trigger the error. A core file should be in the directory you specified. Then use gdb to get a backtrace: 1) gdb /path/to/httpd /path/to/core 2) within gdb enter: thread apply all bt full You can get it into a file with something like: gdb /path/to/httpd /path/to/core --batch --quiet \ -ex thread apply all bt full backtrace.log See also: http://httpd.apache.org/dev/debugging.html Other issues may be what MPM use used. There may be some issues with mod_security that was compiled with prefork Apache without threads in APR and then installed in an httpd with worker MPM (or vice versa). Alberto, can you shed some light here? Also, if it truly is failing around the global mutex lock, then you can avoid this by changing from the default Serial logging (which locks) to the non-locking Concurrent type: SecAuditLogType Concurrent If this fixes the issue, then I'd really want a proper backtrace so I can look into that further. ;) thanks, -B -- Brian Rectanus Breach Security -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622806: zsh: unset SHLVL not propertly propagated over exec
Package: zsh
Version: 4.3.11-4
Severity: normal
It seems that if you unset the SHLVL environment variable, the SHLVL is
not properly propagated over exec:
% zsh
% echo $SHLVL
2
% unset SHLVL
% echo $SHLVL
% perl -e 'print $ENV{SHLVL}\n'
% exec perl -e 'print $ENV{SHLVL}\n'
1
The last line is unexpeced. In bash, it is 0. zsh must be caching
SHLVL for some special handling during exec; but the cache is not
updated by unset. If you set SHLVL explicitly, things are as expected
(at least this is the same as bash):
% zsh
% SHLVL=9
% echo $SHLVL
9
% perl -e 'print $ENV{SHLVL}\n'
9
% exec perl -e 'print $ENV{SHLVL}\n'
8
Andrew
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.38-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 zsh depends on:
ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib
ii libcap2 1:2.20-1 support for getting/setting POSIX.
ii libncursesw5 5.9-1 shared libraries for terminal hand
Versions of packages zsh recommends:
ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib
ii libpcre3 8.12-3 Perl 5 Compatible Regular Expressi
Versions of packages zsh suggests:
ii zsh-doc 4.3.11-4 zsh documentation - info/HTML form
-- debconf information:
zsh/rcmove:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622821: wpasupplicant: reassociates after disconnect
Package: wpasupplicant Version: 0.7.3-2 Severity: normal In the changelog: * After a disconnected event, attempt to reassociate to a network when using wpa-roam. If I'm understanding this correctly, I don't see the sense in this. It definitely changes the user experience. Before, in wpa_gui, if I click Disconnect, I go off the wireless network and stay off. Now, I come right back on, which seems unintuitive. If I really want to stay off, I can't do it in wpa_gui, I have to ifdown. You might argue this is a better to do it, but I think people might be used to doing a disconnect (in wpa_gui and other front-ends) to get off the wireless network. Also, this change breaks /etc/wpa_supplicant/action_wpa.sh. The comments in that script indicate an expectation that disconnect implies disable. The ifplugd uses this script when it detects an ethernet cable plugged in. As a result of this change, both the ethernet and wireless interfaces stay up and may step on each other. (Which one gets the default route? Also, I am seeing weird DHCP behavior that seems to be related.) I'm not saying ifplugd is necessarily doing the right thing, but it was working before. Let me know if I'm misunderstanding something. Here is my wireless interface configuration in /etc/network/interfaces: iface eth1 inet manual wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf wpa-roam-default-iface default-wireless iface default-wireless inet dhcp Andrew -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.38-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 wpasupplicant depends on: ii adduser 3.112+nmu2 add and remove users and groups ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libdbus-1-3 1.4.6-1simple interprocess messaging syst ii libnl11.1-6 library for dealing with netlink s ii libpcsclite1 1.7.2-1Middleware to access a smart card ii libreadline6 6.1-3 GNU readline and history libraries ii libssl1.0.0 1.0.0d-2 SSL shared libraries ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip wpasupplicant recommends no packages. Versions of packages wpasupplicant suggests: pn libengine-pkcs11-openssl none (no description available) ii wpagui0.7.3-2graphical user interface for wpa_s -- 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#622827: vim-runtime: recent changelog not included in package
Package: vim-runtime Version: 2:7.3.154+hg~74503f6ee649-2 Severity: minor I can't find the recent changes to vim in the Debian package. ':help version7 gives me a list of all the patches through 7.3, but not the subsequent patches. It would be nice to add these to version7.txt when you apply new patches to the Debian package. If it is too much trouble to put it in version7.txt, it would be fine to put it in /usr/share/doc. (Actually, it might be nice to add a note in README.Debian indicating that changes are in the on-line documentation, since users might wonder why there is no changelog in /usr/share/doc. Just an idea.) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.38-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 vim-runtime depends on no packages. Versions of packages vim-runtime recommends: ii vim-gtk [vim 2:7.3.154+hg~74503f6ee649-2 Vi IMproved - enhanced vi editor - vim-runtime 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#612351: resolvconf: move VPN interfaces to the end of interface-order
Package: resolvconf Version: 1.48 Severity: wishlist Currently, tun* is ahead of eth* in /etc/resolvconf/interface-order. I think that putting the VPN interfaces at the end may be a better default. By VPN interfaces I mean the interfaces that are typically used to reach VPNs or other special networks--probably tun* and tap*--as opposed to the public internet, usually reached by eth*, etc. I suggest this because, in typical use, most resolver requests are for the public internet and can be handled by the standard resolver, which is usually faster and more reliable than the resolver on the VPN (typically running on a crappy VPN gateway and managed by an overworked, underfunded, or incompetent corporate IT department). Also, in bug 460200, the VPN crashed without running resolvconf -d, resulting delays attempting to reach the VPN's nameservers. This is probably a bug in vpnc, but bugs happen, and if the default is to use the standard resolver first, the bug is not as painful. Of course, this is just my use case, and you may have more information about other use cases where this thange would break things. Just offering it as an idea. Andrew -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable') 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 resolvconf depends on: ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip resolvconf recommends no packages. resolvconf suggests no packages. -- Configuration Files: /etc/resolvconf/resolv.conf.d/base [Errno 2] No such file or directory: u'/etc/resolvconf/resolv.conf.d/base' -- debconf information: resolvconf/bad-pppoeconf-hook: * resolvconf/downup-interfaces: * resolvconf/link-tail-to-original: false resolvconf/bad-pppconfig-hook: resolvconf/linkify-resolvconf: true resolvconf/disable-bad-hooks: true resolvconf/bad-xisp-hook: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#460200: vpnc does not always call resolvconf -d on terminaison
I have this problem too. I think there is a simple work-around. Just move tun* down in /etc/resolvconf/interface-order. This will put the VPN's nameservers at the end of /etc/resolv.conf, so your normal nameserver will be used first. In fact, I think that's a better default for /etc/resolvconf/interface-order, so I filed a wishlist bug: http://bugs.debian.org/612351 Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607576: exim4-config: after upgrade, /etc/exim4/exim4.conf is present and breaks exim
Package: exim4-config Version: 4.69-9+lenny1 Severity: important I have a locally-compiled exim4-daemon-custom package, along with the standard exim4, exim4-base, and exim4-config packages. Recently, they were all at 4.69-9 when 4.69-9+lenny1 hit security. aptitude prompted me to upgrade exim4, exim4-base, and exim4-config from 4.69-9 - 4.69-9+lenny1, and I accepted--probably foolishly, since exim4-daemon-custom was still at 4.69-9. The result was a major failure. All of my incoming mail that should have been delivered was rejected relay not permitted. For every reject, mainlog had: 2010-12-18 06:27:22 no IP address found for host MAIN_RELAY_NETS (during SMTP connection from [69.147.233.108]) 2010-12-18 06:27:22 H=[69.147.233.108] F=web...@jetline1.com rejected RCPT and...@pimlott.net: relay not permitted Actually, this did not happen right away, because the package updates didn't restart the daemon. It was only after a routine daemon restart that the failures started. I have resolved the problem, but I can't really figure out what happened. The odd thing I noticed is that when things weren't working, I had an /etc/exim4/exim4.conf. Since I've always used Debconf and the split configuration, I did not expect this file to be present. (But I am not positive it was not present before, and I don't have a convenient backup to check.) It looks like exim4 was taking this config file in preference to the auto-generated one. This exim4.conf is identical to exim4.conf.template, except for whitespace changes. Also, it is mode 0400 and owned by Debian-exim. When I move this file out of the way, things start working again. So is it possible that my upgrade somehow created the exim4.conf that broke my configuration? I understand that getting my packages out of sync the way I did is probably not supported, but I would still like to get to the bottom of this. By the way, my custom package was for SRS and DomainKeys. I don't have a lot of custom configuration. Andrew -- Package-specific info: Exim version 4.69 #1 built 03-Jan-2010 17:26:17 Copyright (c) University of Cambridge 2006 Berkeley DB: Berkeley DB 4.6.21: (September 27, 2007) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages Experimental_SRS Experimental_DomainKeys Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to replace # the DEBCONFsomethingDEBCONF strings in the configuration template files. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='internet' dc_other_hostnames='pimlott.net;madstop.net' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='' CFILEMODE='644' dc_use_split_config='true' dc_hide_mailname='' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:pimlott.net -- System Information: Debian Release: 5.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30.5-xenU (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 exim4-config depends on: ii adduser 3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy exim4-config recommends no packages. exim4-config suggests no packages. -- debconf information: * exim4/dc_other_hostnames: pimlott.net;madstop.net * exim4/dc_eximconfig_configtype: internet site; mail is sent and received directly using SMTP exim4/dc_noalias_regenerate: false exim4/no_config: true exim4/hide_mailname: * exim4/dc_postmaster: andrew exim4/dc_smarthost: * exim4/dc_relay_domains: * exim4/dc_relay_nets: * exim4/mailname: pimlott.net exim4/dc_readhost: * exim4/use_split_config: true exim4/exim4-config-title: * exim4/dc_localdelivery: mbox format in /var/mail/ * exim4/dc_local_interfaces: * exim4/dc_minimaldns: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607118: aptitude: after 'q' is cancelled with ctrl-q, it doesn't work again
Package: aptitude Version: 0.6.3-3.2 Severity: minor Start aptitude. Hit 'q', and the dialog Really quit Aptitude? [n]y appears. Hit ctrl-g to cancel, and the dialog is dismissed. Hit 'q' again, and nothing happens. Andrew -- Package-specific info: aptitude 0.6.3 compiled at Oct 18 2010 22:11:25 Compiler: g++ 4.4.5 Compiled against: apt version 4.10.1 NCurses version 5.7 libsigc++ version: 2.2.4.2 Ept support enabled. Gtk+ support disabled. Current library versions: NCurses version: ncurses 5.7.20100313 cwidget version: 0.5.16 Apt version: 4.10.1 linux-gate.so.1 = (0xb7862000) libapt-pkg.so.4.10 = /usr/lib/libapt-pkg.so.4.10 (0xb7752000) libncursesw.so.5 = /lib/libncursesw.so.5 (0xb770c000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7705000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7645000) libept.so.1 = /usr/lib/libept.so.1 (0xb75f4000) libxapian.so.22 = /usr/lib/sse2/libxapian.so.22 (0xb7419000) libz.so.1 = /usr/lib/libz.so.1 (0xb7405000) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0xb7378000) libboost_iostreams.so.1.42.0 = /usr/lib/libboost_iostreams.so.1.42.0 (0xb735f000) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7346000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb7251000) libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb722b000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb720d000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb70c6000) libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb70c2000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb70be000) libuuid.so.1 = /lib/libuuid.so.1 (0xb70ba000) libbz2.so.1.0 = /lib/libbz2.so.1.0 (0xb70a9000) librt.so.1 = /lib/i686/cmov/librt.so.1 (0xb709f000) /lib/ld-linux.so.2 (0xb7863000) Terminal: xterm $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') 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 aptitude depends on: ii apt [libapt-pkg4.10]0.8.10 Advanced front-end for dpkg ii libboost-iostreams1.42. 1.42.0-4 Boost.Iostreams Library ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcwidget3 0.5.16-3 high-level terminal interface libr ii libept1 1.0.4High-level library for managing De ii libgcc1 1:4.4.5-10 GCC support library ii libncursesw55.7+20100313-4 shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.2.4.2-1type-safe Signal Framework for C++ ii libsqlite3-03.7.3-1 SQLite 3 shared library ii libstdc++6 4.4.5-10 The GNU Standard C++ Library v3 ii libxapian22 1.2.3-2 Search engine library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages aptitude recommends: ii apt-xapian-index 0.41 maintenance and search tools for a ii aptitude-doc-en [aptitude-doc 0.6.3-3.2 English manual for aptitude, a ter ii libparse-debianchangelog-perl 1.1.1-2.1 parse Debian changelogs and output ii sensible-utils0.0.6 Utilities for sensible alternative Versions of packages aptitude suggests: pn debtags none (no description available) ii tasksel 2.88 Tool for selecting tasks for insta -- 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#152354: aptitude: q q should quit
'q' is also used to go up a level of nested screens. So users may hit 'q' several times to get back to the top level (and then 'n' to avoid quitting). If hitting 'q' one extra time caused aptitude to quit, it would be quite a surprising and frustrating change. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605200: linux-image-2.6.32-5-686: ipw2100 fatal interrupts using TKIP (WPA2-PSK)
Package: linux-2.6
Version: 2.6.32-27
Severity: normal
I set up a new wireless router and started getting frequent network
dropouts associated with the message ipw2100: Fatal interrupt.
Scheduling firmware restart. I have narrowed down the problem to TKIP
encryption in WPA2-PSK. If I use WEP or no encryption, or if I switch
my encryption to AES, I don't have this problem.
computer
- IBM Thinkpad X40
- Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)
- ipw2100 firmware 1.3
- Debian unstable
- linux-image-2.6.32-5-686 (no other kernel/driver versions tested)
- wpa_supplicant 0.6.10-2 with a hand-edited wpa_supplicant.conf. My
entry for this network is:
network={
ssid=ESSID
key_mgmt=WPA-PSK
psk=passphrase
}
access point
- Ubee (Ambit) U10C019
- All advanced wireless settings at their default (I played with them,
but none made a difference)
- WPA2-PSK set to enabled, WPA-PSK set to disabled (I don't WPA vs WPA2
makes a difference though)
Then, I switch the option WPA/WPA2 Encryption between TKIP and AES.
In the first case only, I get frequent fatal interrupts. They coincide
with me initiating network activity and happen very reliably, ie, an
interactive ssh session is unusable.
I have used other WPA-PSK networks in the past without trouble, but I
don't know whether they were using TKIP.
Let me know if I can provide more information.
Andrew
-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-27) (m...@debian.org) (gcc version
4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 22:47:19 UTC 2010
** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686
root=UUID=73cf35da-d145-4e4b-b662-3849f9a0ae64 ro
** Not tainted
** Kernel log:
[535890.008817] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[535900.432028] eth1: no IPv6 routers present
[535936.909959] ipw2100: Fatal interrupt. Scheduling firmware restart.
[535940.454914] ADDRCONF(NETDEV_UP): eth1: link is not ready
[535942.552687] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[535952.932024] eth1: no IPv6 routers present
[536157.662633] ADDRCONF(NETDEV_UP): eth1: link is not ready
[536183.396795] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[536193.756138] eth1: no IPv6 routers present
[537151.793914] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537180.200072] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537183.648274] ADDRCONF(NETDEV_UP): eth1: link is not ready
[537185.444772] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[537196.296144] eth1: no IPv6 routers present
[537236.830482] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537273.668774] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537277.457861] ADDRCONF(NETDEV_UP): eth1: link is not ready
[537279.448683] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[537289.548137] eth1: no IPv6 routers present
[537302.730971] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537316.785067] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537328.839142] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537405.981689] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537416.051722] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537425.833668] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537435.119690] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537448.773420] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537461.787196] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537469.185193] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537488.759275] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537516.269445] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537519.809102] ADDRCONF(NETDEV_UP): eth1: link is not ready
[537522.784864] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[537532.824135] eth1: no IPv6 routers present
[537759.989349] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537829.116000] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537973.187184] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537985.113332] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538002.191421] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538026.917427] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538077.083697] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538091.265583] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538547.819491] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538551.373429] ADDRCONF(NETDEV_UP): eth1: link is not ready
[538553.800688] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[538564.068035] eth1: no IPv6 routers present
[538593.374828] ADDRCONF(NETDEV_UP): eth1: link is not ready
[538595.436766] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[538606.396146] eth1: no IPv6 routers present
[538621.281997] ipw2100: Fatal interrupt. Scheduling firmware restart.
Bug#601033: apache2.2-common: AddOutputFilterByType is deprecated but used in deflate.conf
Excerpts from Stefan Fritsch's message of Tue Nov 16 15:03:05 -0800 2010: On Friday 22 October 2010, Andrew Pimlott wrote: It gets weirder: if I change text/plain to text/html, the encoding is not added. It seems that AddOutputFilterByType catches proxied requests if text/plain appears in its list of mime types, as if all proxied requests were considered text/plain. Do you have DefaultType text/plain set somewhere? If yes, try to not set that for the reverse proxied requests. I could imaging (but have not checked) that the processing order is like this: - DefaultType sets the content type - AddOutputFilterByType looks at the content type - mod_proxy sets the content type to what was received from the backend server I thought surely this was right, but I tried it, and no. The only DefaultType setting is in /etc/apache2/apache2.conf, and when I change it from text/plain to foo/bar (or comment it out), it still gzip-encodes when text/plain is in the AddOutputFilterByType, and doesn't otherwise. Even if it were the case, it wouldn't matter, because I still couldn't control gzip-encoding by mime type using AddOutputFilterByType. It looks like AddOutputFilterByType just doesn't work right (by design?) in the proxy case. So I still think it should not be enabled by default. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601033: apache2.2-common: AddOutputFilterByType is deprecated but used in deflate.conf
Package: apache2.2-common Version: 2.2.16-3 Severity: normal AddOutputFilterByType is deprecated, however it is used in the Debian package in mods-available/deflate.conf. http://httpd.apache.org/docs/2.2/mod/core.html#addoutputfilterbytype I had a problem in a reverse proxy configuration that I believe is caused by this. I found a bunch of similar reports, eg: https://issues.apache.org/bugzilla/show_bug.cgi?id=31226 https://issues.apache.org/bugzilla/show_bug.cgi?id=14335 The response is always to stop using AddOutputFilterByType and use mod_filter instead. What is funny is that the above reports that AddOutputFilterByType was being ignored in reverse proxied requests. It seems that that problem has been fixed. What I am seeing is that AddOutputFilterByType is triggering for all mime types, even though the config line is reduced to AddOutputFilterByType DEFLATE text/plain Eg, I request a file of type application/zip through the reverse proxy, and the proxy adds a Content-Encoding: gzip. I have verified that the origin site did not use a Content-Encoding. Commenting out the AddOutputFilterByType caused the Content-Encoding: gzip not to be added. It gets weirder: if I change text/plain to text/html, the encoding is not added. It seems that AddOutputFilterByType catches proxied requests if text/plain appears in its list of mime types, as if all proxied requests were considered text/plain. This caused me greate pain because Internet Explorer mis-handles application/zip downloads with Content-Encoding: gzip: http://support.microsoft.com/kb/2002350 I don't have much time to continue debugging this. My plan is to turn off mod_deflate for now, and investigate mod_filter shortly. But I think my experience implies that mod_deflate should not be configured this way by default. It doesn't work reliably enough, and the fallout when it breaks is obscure, hard to diagnose corruption. Andrew -- Package-specific info: List of enabled modules from 'apache2 -M': alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi dir env mime negotiation perl reqtimeout setenvif status userdir -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') 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 apache2.2-common depends on: ii apache2-utils 2.2.16-3 utility programs for webservers ii apache2.2-bin 2.2.16-3 Apache HTTP Server common binary f ii libmagic1 5.04-5 File type determination library us ii lsb-base 3.2-26 Linux Standard Base 3.2 init scrip ii mime-support 3.48-1 MIME files 'mime.types' 'mailcap ii perl 5.10.1-15 Larry Wall's Practical Extraction ii procps1:3.2.8-9 /proc file system utilities Versions of packages apache2.2-common recommends: ii ssl-cert 1.0.27 simple debconf wrapper for OpenSSL Versions of packages apache2.2-common suggests: pn apache2-doc none (no description available) pn apache2-suexec | apache2-su none (no description available) ii iceweasel [www-browser] 3.5.13-1 Web browser based on Firefox ii lynx-cur [www-browser] 2.8.8dev.5-1 Text-mode WWW Browser with NLS sup ii w3m [www-browser] 0.5.2-9 WWW browsable pager with excellent Versions of packages apache2.2-common is related to: pn apache2-mpm-event none (no description available) pn apache2-mpm-itk none (no description available) ii apache2-mpm-prefork 2.2.16-3 Apache HTTP Server - traditional n pn apache2-mpm-workernone (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#600294: Need to turn off 'Headphone Jack Sense' and 'Line Jack Sense'
Package: alsa-utils Version: 1.0.23-2 Severity: wishlist Five years on, bug 297343 (archived, so I couldn't reply to it) takes me out for a few frustrating hours. I was playing with mixer levels to get my mic capture working and turned on Headphone Jack Sense, no doubt thinking that turning things on could hardly hurt. Googling did not get me the solution; I just checked the ALSA faq and it's there, but this did not come up in my searches. I looked at the Debian fix, and it seems that I could have run /etc/init.d/alsa reset to get my sound working again. That's great, thought it's a little obscure and I never found it documented. What I tried was alsactl init, but this didn't do it. It would be have been better for me if this fix could have been made in alsactl init. Any chance for some of the Debian sanity checks to be ported to alsactl init? Should I file an upstream bug about this? Andrew -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') 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 alsa-utils depends on: ii libasound21.0.23-2 shared library for ALSA applicatio ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libncursesw5 5.7+20100313-4 shared libraries for terminal hand ii linux-sound-base 1.0.23+dfsg-1 base package for ALSA and OSS soun ii lsb-base 3.2-25 Linux Standard Base 3.2 init scrip ii module-init-tools 3.12-1 tools for managing Linux kernel mo ii udev 161-1 /dev/ and hotplug management daemo ii whiptail 0.52.11-1 Displays user-friendly dialog boxe Versions of packages alsa-utils recommends: ii alsa-base 1.0.23+dfsg-1 ALSA driver configuration files ii pciutils 1:3.1.7-5 Linux PCI Utilities alsa-utils 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#600294: [Pkg-alsa-devel] Bug#600294: Need to turn off 'Headphone Jack Sense' and 'Line Jack Sense'
Excerpts from Elimar Riesebieter's message of Fri Oct 15 10:12:00 -0700 2010: * Andrew Pimlott [101015 08:46 -0700]: Package: alsa-utils Version: 1.0.23-2 Severity: wishlist Five years on, bug 297343 (archived, so I couldn't reply to it) takes me out for a few frustrating hours. I was playing with mixer levels to get my mic capture working and turned on Headphone Jack Sense, no doubt thinking that turning things on could hardly hurt. Googling did not get me the solution; I just checked the ALSA faq and it's there, but this did not come up in my searches. ??? Sorry for the confusion. I'm referring to Debian bug 297343, http://bugs.debian.org/297343. Does it make sense now? and it seems that I could have run /etc/init.d/alsa reset to get my sound working again. reset wqas never an option of the alsa script. Sorry, I meant /etc/init.d/alsa-utils That's great, thought it's a little obscure and I never found it documented. What did you never found? /etc/init.d/alsa-utils reset. I've never seen an init script with a reset command, so I didn't think to look there. Sorry, but what or where is the bug? What do you want? Which Debian sanity checks do you mean? I mean the sanify_levels_on_card function in /etc/init.d/alsa-utils. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547231: closed by Salvatore Bonaccorso salvatore.bonacco...@gmail.com ([rt.cpan.org #59832] clobbers binmode layers on filehandles)
Salvatore, thanks for following up on this report. I have some
questions below.
Excerpts from owner's message of Wed Aug 18 04:30:08 -0700 2010:
This is an automatic notification regarding your Bug report
...
Hi Andrew
I'm forwarding you the reply from upstream according to your report.
From: Hiroo_HAYASHI via RT bug-term-readline-...@rt.cpan.org
If I call
Term::ReadLine-new('test', \*IN, \*OUT);
any encoding layers I have set on OUT seem to be removed. I tracked
Term::Gnu::ReadLine is an implementation of Term::ReadLine using the
GNU Readline/History Library. as described in the document.
The GNU Readline Library may call low level APIs directly. So this is
not a bug.
I realize that Readline has to do some low-level things. But I don't
understand why it has to clobber the encoding layers on the filehandle.
Is it possible to preserve them? Do you not agree that the test program
I sent is terribly confusing? If Term::ReadLine::Gnu changes the
behavior of the filehandles like this, it should at least be documented.
BTW if the reporter wants to handle multibyte (ex. UTF-8) characters,
the GNU Readline Library support them and, as the result,
Term::Gnu::ReadLine also support them. Refer the documents for the GNU
Readline Library for details.
I couldn't find the documentation you are refering to, or how I'm
supposed to handle multibyte characters with Term::ReadLine::GNU in
Perl. I notice that if I set the encoding layer back to UTF-8, it seems
to work. In this test program, the first and third print statements
output the expected character, and only the second is broken:
use Term::ReadLine;
binmode(STDOUT, ':encoding(UTF-8)');
print STDOUT , chr(0xf3), \n;
$Term::ReadLine::Gnu::Attribs{outstream} = \*STDOUT;
print STDOUT , chr(0xf3), \n;
binmode(STDOUT, ':encoding(UTF-8)');
print STDOUT , chr(0xf3), \n;
Will I have problems if I do it this way? If this works, I don't see
why Term::ReadLine::GNU had to remove the encoding layer in the first
place.
it
down to the line in the perl source that sets $Attribs{outstream}. I
looked briefly at the .xs source for _rl_store_iostream, but I can't
see
what's causing this. I hope someone who knows perl internals can
figure
it out.
Here is a comment in Gnu.pm;
---
# Each variable in the GNU Readline Library is tied to an entry of
# this hash (%Attribs). By accessing the hash entry, you can read
# and/or write the variable in the GNU Readline Library. See the
# package definition of Term::ReadLine::Gnu::Var and following code
# for more details.
I understand that part. I traced the setting of $Attribs{outstream}
through the tie into _rl_store_iostream in Gnu.xs. The code there looks
like
rl_outstream = PerlIO_findFILE(stream);
Somehow this breaks my encoding layers, but I don't understand why.
Andrew
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
Excerpts from Christian Kastner's message of Wed May 19 10:10:25 -0700 2010: I just re-read #443615. I understand the wish for such a feature, and have added it to my ideas list (among #373152 et al). Such a feature could be added in squeeze+1, via a --strict flag or similar, but I won't promise it. For now, I suggest Andrew do the inverse of your suggestion and add || echo FOO failed to those entries for which a mail should be sent on non-zero exit. Yes, now that I know about the problem, I try to do something like this. Thanks for considering the problem. I really think that reporting a non-zero exit should be the default. There's little point in a --strict flag, because those who know about the problem can work-around it as you showed. I understand if you can't make this change in the current release cycle, but I think it would be a good idea for the next one. Making failures visible will make the whole system more solid in the end. (And I won't have to explain to the boss why the reports weren't running when I thought they were.) Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#374861: rsync: an option to pretend that the sources have trailing slashes
I second this wish. In a wrapper, you may want the clone this object to this name behavior without knowing whether the source object is a file or directory. There is no way to do this. If you append the trailing slash and the object is a file, rsync will complain that the object is not a directory. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577836: mysql-server-5.0: Aborted cached query causes next query to hang (mysql bug 40264)
Package: mysql-server-5.0 Version: 5.0.51a-24+lenny3 Severity: important Mysql bug 40264: When query caching is enabled, large amounts of queries are sent to the server in succession, and a query is aborted, the query cache is put into a state which hangs indefinitely the next time that query is executed. http://bugs.mysql.com/bug.php?id=40264 Query caching is enabled by default and this problem could strike at any time, causing mysterious and possibly serious failures. Would you consider applying the simple patch to the Debian package? Andrew -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-302-rs (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/bash Versions of packages mysql-server-5.0 depends on: ii adduser3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libdbi-perl1.605-1 Perl5 database interface by Tim Bu ii libgcc11:4.3.2-1.1 GCC support library ii libmysqlclient15off5.0.51a-24+lenny3 MySQL database client library ii libncurses55.7+20081213-1shared libraries for terminal hand ii libreadline5 5.2-3.1 GNU readline and history libraries ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii mysql-client-5.0 5.0.51a-24+lenny3 MySQL database client binaries ii mysql-common 5.0.51a-24+lenny3 MySQL database common files ii passwd 1:4.1.1-6+lenny1 change and administer password and ii perl 5.10.0-19lenny2 Larry Wall's Practical Extraction ii psmisc 22.6-1Utilities that use the proc filesy ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages mysql-server-5.0 recommends: ii bsd-mailx [mailx] 8.1.2-0.20071201cvs-3 A simple mail user agent ii heirloom-mailx [ma 12.3+cvs20080629-1feature-rich BSD mail(1) pn libhtml-template-p none(no description available) Versions of packages mysql-server-5.0 suggests: pn tinycanone (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574376: libapache-mod-security: seg fault first time using (goes away on reload)
Package: libapache-mod-security Version: 2.5.11-1~bpo50+1 Severity: normal I just started using mod_security. I installed it on a test system, created a configuration, then copied the configuration to several other system and installed mod_security. The install enables mod_security and reloads apache. At that point, I thought my configuration should be working. But I noticed that it wasn't logging what I thought it should (specifically, nothing was in the audit log), then I noticed lines like this in the error log: [Wed Mar 17 18:58:56 2010] [notice] child pid 18662 exit signal Segmentation fault (11) They seem to correlate with when mod_security should be writing to the audit log. The strangest thing is that when I run /etc/init.d/apache reload, the problem goes away and audit logging happens as expected. I attached to the child with gdb and managed to get a backtrace: #0 0x7fa7b2a17ea4 in apr_global_mutex_lock () from /usr/lib/libapr-1.so.0 #1 0x7fa7ac52976d in ?? () from /usr/lib/apache2/modules/mod_security2.so #2 0x7fa7ac524d66 in ?? () from /usr/lib/apache2/modules/mod_security2.so #3 0x7fa7ac542f6e in ?? () from /usr/lib/apache2/modules/mod_security2.so #4 0x0042b5aa in ap_run_log_transaction () #5 0x004495eb in ap_process_request () #6 0x004467a8 in ?? () #7 0x00440403 in ap_run_process_connection () #8 0x0044dc80 in ?? () #9 0x0044dfd4 in ?? () #10 0x0044ec16 in ap_mpm_run () #11 0x00425be5 in main () Not the most helpful, I know. If you are interested in debugging this, I can leave apache running in this state on one system. Otherwise, I will probable just reload apache and watch for further problems. Here is my mod_security configuration. It is set at the top-level of the apache log file. SecRuleEngine On SecAuditEngine RelevantOnly SecRequestBodyAccess On SecRequestBodyNoFilesLimit 16384 SecAuditLog /var/log/apache2/post.log SecAuditLogParts AIZ SecRule REQUEST_METHOD POST auditlog Andrew -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-302-rs (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/bash Versions of packages libapache-mod-security depends on: ii apache2.2-common2.2.9-10+lenny6 Apache HTTP Server common files ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii liblua5.1-0 5.1.3-1 Simple, extensible, embeddable pro ii libpcre37.6-2.1 Perl 5 Compatible Regular Expressi ii libxml2 2.6.32.dfsg-5+lenny1 GNOME XML library ii mod-security-common 2.5.11-1~bpo50+1 Tighten web applications security libapache-mod-security recommends no packages. libapache-mod-security 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#570568: mysql-server-5.0: replication fails when dropping non-existent view
Package: mysql-server-5.0 Version: 5.0.51a-24+lenny3 Severity: important My replication setup just stopped working. I found it is because of http://bugs.mysql.com/bug.php?id=30998 Replication breaks any time you try to drop a view that did not exist, because mysql includes it in its binary log anyway. Wow! Obviously, makes the system unreliable. I noticed that bug 463515 is a backport of another replication bug, so I see that this sort of fix has been applied before, but this was before the lenny release. Would a backport of this fix be pushed into stable? I can look at doing the work if it would help you. Andrew -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570423: cron: hostname abbreviated
Package: cron
Version: 3.0pl1-106
Severity: wishlist
Tags: patch
When cron sends email, it includes the hostname in the subject. Except,
it abbreviates it to the part before the first .. That seems kind of
pointless for me except as a matter of overzealous brevity. Moreover, I
have systems in different domains with the same first part of the
hostname. So I would like cron to report the whole thing.
This isn't a big deal as I can easily distinguish the mails by their
email addresses, but it's nice for the subject to be clear. Anyway, up
to you.
I'm appending a patch. Nobody else was using the function first_word,
so I removed it.
Andrew
--- cron.h.orig 2010-02-18 18:01:19.0 +
+++ cron.h 2010-02-18 18:01:21.0 +
@@ -235,7 +235,6 @@
char *env_get __P((char *, char **)),
*arpadate __P((time_t *)),
*mkprints __P((unsigned char *, unsigned int)),
- *first_word __P((char *, char *)),
**env_init __P((void)),
**env_copy __P((char **)),
**env_set __P((char **, char *));
--- do_command.c.orig 2010-02-18 18:00:49.0 +
+++ do_command.c2010-02-18 18:01:42.0 +
@@ -511,7 +511,7 @@
fprintf(mail, From: root (Cron Daemon)\n);
fprintf(mail, To: %s\n, mailto);
fprintf(mail, Subject: Cron %...@%s %s\n,
- usernm, first_word(hostname, .),
+ usernm, hostname,
e-cmd);
# if defined(MAIL_DATE)
fprintf(mail, Date: %s\n,
--- misc.c.orig 2010-02-18 18:01:31.0 +
+++ misc.c 2010-02-18 18:01:04.0 +
@@ -580,40 +580,6 @@
}
-/* two warnings:
- * (1) this routine is fairly slow
- * (2) it returns a pointer to static storage
- */
-char *
-first_word(s, t)
- register char *s; /* string we want the first word of */
- register char *t; /* terminators, implicitly including \0 */
-{
- static char retbuf[2][MAX_TEMPSTR + 1]; /* sure wish C had GC */
- static int retsel = 0;
- register char *rb, *rp;
-
- /* select a return buffer */
- retsel = 1-retsel;
- rb = retbuf[retsel][0];
- rp = rb;
-
- /* skip any leading terminators */
- while (*s (NULL != strchr(t, *s))) {
- s++;
- }
-
- /* copy until next terminator or full buffer */
- while (*s (NULL == strchr(t, *s)) (rp rb[MAX_TEMPSTR])) {
- *rp++ = *s++;
- }
-
- /* finish the return-string and return it */
- *rp = '\0';
- return rb;
-}
-
-
/* warning:
* heavily ascii-dependent.
*/
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-trunk-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 cron depends on:
ii adduser 3.112 add and remove users and groups
ii debianutils 3.2.2 Miscellaneous utilities specific t
ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib
ii libpam0g 1.1.1-1Pluggable Authentication Modules l
ii libselinux1 2.0.89-4 SELinux runtime shared libraries
ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip
Versions of packages cron recommends:
ii exim4 4.71-3 metapackage to ease Exim MTA (v4)
ii exim4-daemon-light [mail-tran 4.71-3 lightweight Exim MTA (v4) daemon
pn lockfile-progsnone (no description available)
Versions of packages cron suggests:
pn anacron none (no description available)
pn checksecurity none (no description available)
ii logrotate 3.7.8-4Log rotation utility
-- 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#566600: state of the bell
I'm having trouble with my X11 bell too (in current unstable), and I see a few bugs outstanding (564200, 564464, 566600). It seems to me that there are multiple issues, and they might be getting confused. I'll add my observations here and try to help sort things out. First, my .xsession has two calls to xset to control the bell: xset b 50 2000 50 xset b off (The first is there so if I do turn on the bell, it has the pitch I want.) But when I starts and I open an xterm and run xset q, I see bell percent: 50bell pitch: 400bell duration: 100 So something is resetting the bell. I haven't been able to figure out what. In fact, it even continues to happen after my X session is running. I run xset b off and a few minutes later, it is back on. I haven't figured out if there's a pattern to what I've been doing in between. Second, the xset b setting isn't even having an effect. Programs like gvim that ring the bell continue to sound, even when I've run xset b off and xset q shows it off. Nor does the pitch setting have any effect. I've read about xkbbell, but I'm not clear on the relationship to the old bell or moreover what setting will turn it off. Third, xterm isn't ringing the bell when it should. This seems to be acknowledged in 564200, though I don't see what the plan to fix it is. I'm pretty perplexed by these observations, both because it seem strange for all of them to be happening at once (this is all due to to upgrades within the last month), and because I can't imagine that everyone's bell started going loco or there would be more reports. Let me know what I can do to help track this down. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#443615: cron: warn if a cronjob fails
There seem to be several issues in this bug, but I want to chime in on the one that matters most to me: Justin Pryzby wrote: However [the cron job] returns nonzero exit status, so I think it should log that, and also warn the user by mail (even if the command output nothing else). I sent patches to #155109 to implement that. I've been burned by cron job that were failing with no mail from cron. Is there any plan to apply this or other of Justin's patches? Would it be easier to apply a smaller patch that only added a report about non-zero exit status of a cron job? Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561999: mysql-server-5.0: flush logs corrupts mysql-bin.index
Package: mysql-server-5.0 Version: 5.0.51a-24+lenny2 Severity: normal I have uncommented the log_bin setting in /etc/mysql/my.cnf in order to to make my server a replication master. This has been working fine, but one day I executed flush logs, and the slave started throwing errors: Dec 21 20:31:46 web3 mysqld.replica[23069]: 091221 20:31:46 [ERROR] Error reading packet from server: File '.07' not found (Errcode: 2) ( server_errno=29) Dec 21 20:31:46 web3 mysqld.replica[23069]: 091221 20:31:46 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.07' position 4 Dec 21 20:31:46 web3 mysqld.replica[23069]: 091221 20:31:46 [Note] Slave: connected to master 'r...@db1:3306',replication resumed in log 'mysql-bin.07' at position 4 Dec 21 20:31:46 web3 mysqld.replica[23069]: 091221 20:31:46 [ERROR] Error reading packet from server: Could not find first log file name in binary log index file ( server_errno=1236) Dec 21 20:31:46 web3 mysqld.replica[23069]: 091221 20:31:46 [ERROR] Got fatal error 1236: 'Could not find first log file name in binary log index file' from master when reading data from binary log Dec 21 20:31:46 web3 mysqld.replica[23069]: 091221 20:31:46 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.07', position 4 Wondering what had happened, I looked at my log directory: % cd /var/log/mysql % ls -l -rw-rw 1 mysql adm 13813 2009-12-19 18:32 mysql-bin.01 -rw-rw 1 mysql adm 117 2009-12-19 18:41 mysql-bin.02 -rw-rw 1 mysql adm 117 2009-12-19 18:43 mysql-bin.03 -rw-rw 1 mysql adm 1833587 2009-12-20 07:39 mysql-bin.04 -rw-rw 1 mysql adm 4698347 2009-12-21 07:53 mysql-bin.05 -rw-rw 1 mysql adm 8683203 2009-12-21 20:32 mysql-bin.06 -rw-rw 1 mysql adm 98 2009-12-21 20:32 mysql-bin.07 -rw-rw 1 mysql adm 224 2009-12-21 20:32 mysql-bin.index That looks all right... but % cat mysql-bin.index /var/log/mysql/mysql-bin.01 /var/log/mysql/mysql-bin.02 /var/log/mysql/mysql-bin.03 /var/log/mysql/mysql-bin.04 /var/log/mysql/mysql-bin.05 /var/log/var/log/mysql/mysql-bin.07 This really looks bad. First, mysql-bin.06 has disappeared, and second, the path to mysql-bin.07 is wrong. I have not been able to reproduce this problem, but since it is fairly serious I thought I should report it. I think I managed to recover from this without stopping the database. I edited the mysql-bin.index file to fix it, then I issued another flush logs. Now, mysql-bin.index has files 1-8 as expected, and I can resume the replication successfully. Andrew # # The MySQL database server configuration file. # # You can copy this to one of: # - /etc/mysql/my.cnf to set global options, # - ~/.my.cnf to set user-specific options. # # One can use all long options that the program supports. # Run program with --help to get a list of available options and with # --print-defaults to see which it would actually understand and use. # # For explanations see # http://dev.mysql.com/doc/mysql/en/server-system-variables.html # This will be passed to all mysql clients # It has been reported that passwords should be enclosed with ticks/quotes # escpecially if they contain # chars... # Remember to edit /etc/mysql/debian.cnf when changing the socket location. [client] port= 3306 socket = /var/run/mysqld/mysqld.sock # Here is entries for some specific programs # The following values assume you have at least 32M ram # This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice= 0 [mysqld] # # * Basic Settings # user= mysql pid-file= /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port= 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language= /usr/share/mysql/english skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 16M max_allowed_packet = 16M thread_stack= 128K thread_cache_size = 8 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam-recover = BACKUP #max_connections= 100 #table_cache= 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 1M query_cache_size= 16M # # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. #log= /var/log/mysql/mysql.log # # Error logging goes to syslog. This is a Debian improvement :) # # Here you can see queries
Bug#525315: better hysteresis for wpa_action
I have been much happier since I installed the attached script and configured /etc/wpa_supplicant/ifupdown.sh to use it instead of /sbin/wpa_action. It delays disconnect events for 5 seconds, and if a new connect comes within that time, it cancels the disconnect. Other than that, events are passed along to the real wpa_action script. It's not done, because it doesn't check whether a connect event is for a new network, in which case we need to disconnect and reconnect. I think it would be much better to integrate this into wpa_cli, as that would probably reduce the locking complexity and be more reliable than a shell script. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525315: better hysteresis for wpa_action
attached
#!/bin/sh
IFACE=$1
ACTION=$2
SELF=$$
PENDING_FILE=/tmp/pending_disconnect.$IFACE.lock
log () {
echo $(date '+%F %T') $@ /tmp/wpa_action.$IFACE.log
}
lock () {
lockfile /tmp/wpa_action.$IFACE.lock
}
unlock () {
rm -f /tmp/wpa_action.$IFACE.lock
}
# Note: wpa_cli runs us synchronously, so go into the background to wait
case $ACTION in
CONNECTED)
lockfile /tmp/wpa_action.lock
if [ -e $PENDING_FILE ]; then
log CONNECTED, cancelling pending disconnect
rm $PENDING_FILE
else
log CONNECTED, doing real connect
/sbin/wpa_action $@
fi
rm -f /tmp/wpa_action.lock
;;
DISCONNECTED)
log DISCONNECTED, scheduling disconnect ($SELF)
echo $SELF $PENDING_FILE
(
sleep 5
lockfile /tmp/wpa_action.lock
if [ -e $PENDING_FILE $SELF = $(cat $PENDING_FILE) ]; then
log resuming $SELF, doing real disconnect
rm $PENDING_FILE
/sbin/wpa_action $@
else
log resuming $SELF, cancelled
fi
rm -f /tmp/wpa_action.lock
)
;;
*)
log whah?? $ACTION
;;
esac
Bug#547231: libterm-readline-gnu-perl: clobbers binmode layers on filehandles
Package: libterm-readline-gnu-perl
Version: 1.19-1
Severity: normal
If I call
Term::ReadLine-new('test', \*IN, \*OUT);
any encoding layers I have set on OUT seem to be removed. I tracked it
down to the line in the perl source that sets $Attribs{outstream}. I
looked briefly at the .xs source for _rl_store_iostream, but I can't see
what's causing this. I hope someone who knows perl internals can figure
it out.
Here's a complete test program. I run it on a utf-8 terminal. The
first print works correctly (the correct utf-8 byte sequence is output),
and the second shows a unicode unknown character (U+fffd), because perl
outputs the byte \xf3.
use Term::ReadLine;
binmode(STDOUT, ':encoding(utf-8)');
print STDOUT , chr(0xf3), \n;
$Term::ReadLine::Gnu::Attribs{outstream} = \*STDOUT;
print STDOUT , chr(0xf3), \n;
Andrew
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-1-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 libterm-readline-gnu-perl depends on:
ii libc6 2.9-26 GNU C Library: Shared libraries
ii libncurses5 5.7+20090803-2 shared libraries for terminal hand
ii libreadline5 5.2-6 GNU readline and history libraries
ii perl 5.10.0-25 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.10.0 5.10.0-25 minimal Perl system
libterm-readline-gnu-perl recommends no packages.
libterm-readline-gnu-perl 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#525315: handling disconnect/reconnect
I have some comments on this issue. I don't think there is any loop going on, and I think the hysteresis check is probably the wrong way to deal with this. First, I think the reason the reporter is seeing dhclient repeatedly obtaining and releasing is not because there is any kind of loop, but because there is simply a backlog of disconnect/reconnect actions. That is, wpa_supplicant generates a bunch of disconnect/reconnect events, wpa_cli processes them one at a time, executing wpa_action synchronously. Since wpa_action takes a while to finish (obtaining a lease), a bunch of events pile up while wpa_action is running. wpa_cli isn't smart enough to know that it really only has to process the latest event. So even when wpa_supplicant has stabilized and is not generating an more events, wpa_cli keeps calling wpa_action to bring the interface down and up. I don't think there are any artificial events as suggested in the comments to wpa_hysteresis_event and wpa_hysteresis_check (unless that is in reference to a different problem). I don't think that refusing to process events that come in quick succession is the answer at all. Unless you have a separate justification for that, I would get rid of it. What really needs to happen is that wpa_cli needs to understand that some of the events it gets obviate earlier events. If there are a bunch of disconnect/connect events queued, only act on the last. If you add in a short delay before processing a disconnect event, any connect events that come in during the the delay will result in the disconnect being ignored. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544944: rlfe does not always write history file
Package: rlfe
Version: 6.0-3
Severity: normal
Tags: patch
I found rlfe sometimes doesn't save its command history as expected. I
tracked this down to the two different ways rlfe can exit. (Search for
exit (0) in the source.) The first is SIGCHLD from its inferior, the
second is read error from its inferior. History was not being saved in
the second case. The attached patch fixes this.
It seems that normally the first path is run. I don't know exactly why
I caused the second path, but perhaps it happens when the inferior
closes its output then takes a while longer to exit. If you don't think
the change is legitimate, I'll do some more digging to figure out what
triggers this case.
Andrew
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-1-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 rlfe depends on:
ii libc6 2.9-25 GNU C Library: Shared libraries
ii libncurses5 5.7+20090803-2 shared libraries for terminal hand
ii libreadline6 6.0-4 GNU readline and history libraries
rlfe recommends no packages.
rlfe suggests no packages.
-- no debconf information
--- rlfe.c.orig 2009-09-03 13:42:35.0 -0700
+++ rlfe.c 2009-09-03 13:41:06.0 -0700
@@ -154,21 +154,27 @@
static pid_t child = -1;
static void
-sig_child (int signo)
+finish_up()
{
- int status;
- wait (status);
if (hist_file != 0)
{
write_history (hist_file);
if (hist_size)
history_truncate_file (hist_file, hist_size);
}
- DPRINT0 ((Child process died.)\n);
tcsetattr(STDIN_FILENO, TCSANOW, orig_term);
exit (0);
}
+static void
+sig_child (int signo)
+{
+ int status;
+ wait (status);
+ DPRINT0 ((Child process died.)\n);
+ finish_up();
+}
+
volatile int propagate_sigwinch = 0;
/* sigwinch_handler
@@ -703,8 +709,7 @@
if (count = 0)
{
DPRINT0 ((Connection closed by foreign host.)\n);
- tcsetattr(STDIN_FILENO, TCSANOW, orig_term);
- exit (0);
+ finish_up();
}
old_count = buf_count;
Bug#532613: Possible cause?
I tried this workaround with poor results. If I crank the first of those four mixer levels all the way up and turn the volume of my speakers all the way up, I can hear something. But it's nowhere near reasonable. The other three levels have no effect. I have a VIA MII1 with this sound chip: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) I also did a diff of kernel messages between 2.6.26 and 2.6.30. Here is the relevant section: +VIA 82xx Audio :00:11.5: PCI INT C - Link[LNKC] - GSI 5 (level, low) - IRQ 5 VIA 82xx Audio :00:11.5: VIA VLink IRQ fixup, from 9 to 5 -PCI: Setting latency timer of device :02:00.0 to 64 +VIA 82xx Audio :00:11.5: setting latency timer to 64 Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541117: xserver-xorg-video-intel: high CPU usage after 2.7.1-1 - 2.8.0-1 upgrade
On Thu, Aug 20, 2009 at 08:56:16AM +0200, Brice Goglin wrote: According to errors in your log, something's going bad with DRM. Does this log come from a second X server while another X server was already using the DRM device? Damn, I don't know why I didn't notice that. No, it was the only X server running. But I took a look at my configuration and noticed that I had Disable dri because of bug 525123. I don't know what dri has to do with drm, but seeing that they have the first two letters I decided to comment that out and try running 2.8 again. Now, it performs well again! And, I don't see any of the issues from bug 525123 either (even though I can't remember quite what that looked like). In sum, on my X40: 2.7.1 2.8.0 empty configbug 525123 :-) Disable dri :-) bug 541117 I'm attaching two diffs of the log files. 2.7.1-2.8.0.diff compares 2.7.1 with 2.8.0, both with Disable dri. (I should have run this diff before I filed the bug, sorry.) enable_dri.diff compares 2.8.0 with Disable dri and without. Thanks for your help! Andrew --- /var/log/Xorg.0.log 2009-08-20 08:05:19.0 -0700 +++ /var/log/Xorg.0.log.old 2009-08-20 08:02:58.0 -0700 @@ -11,7 +11,7 @@ Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. -(==) Log file: /var/log/Xorg.0.log, Time: Thu Aug 20 08:05:15 2009 +(==) Log file: /var/log/Xorg.0.log, Time: Thu Aug 20 08:02:44 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. @@ -111,7 +111,7 @@ (II) LoadModule: intel (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor=X.Org Foundation - compiled for 1.6.3, module version = 2.7.1 + compiled for 1.6.2.901, module version = 2.8.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, @@ -119,7 +119,8 @@ E7221 (i915), 915GM, 945G, 945GM, 945GME, IGD_GM, IGD_G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, - Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 + Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41, IGDNG_D, + IGDNG_M (II) Primary Device is: PCI 0...@00:02:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x - 0x (0x1) MX[B] @@ -149,6 +150,8 @@ (II) Loading sub module ramdac (II) LoadModule: ramdac (II) Module ramdac already built-in +(EE) intel(0): [drm] Failed to open DRM device for : No such file or directory +(EE) intel(0): Failed to become DRM master. (II) intel(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 (==) intel(0): Depth 24, (--) framebuffer bpp 32 @@ -157,9 +160,9 @@ (II) intel(0): Integrated Graphics Chipset: Intel(R) 855GME (--) intel(0): Chipset: 852GM/855GM (--) intel(0): Linear framebuffer at 0xE000 -(--) intel(0): IO registers at addr 0xD000 +(--) intel(0): IO registers at addr 0xD000 size 524288 (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB -(==) intel(0): Using EXA for acceleration +(II) intel(0): No SDVO device is found in VBT (II) intel(0): 2 display pipes available. (II) Loading sub module ddc (II) LoadModule: ddc @@ -179,14 +182,14 @@ (II) LoadModule: sil164 (II) Loading /usr/lib/xorg/modules/drivers//sil164.so (II) Module sil164: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_E initialized. (II) Loading sub module ch7xxx (II) LoadModule: ch7xxx (II) Loading /usr/lib/xorg/modules/drivers//ch7xxx.so (II) Module ch7xxx: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_E removed. (II) intel(0): I2C bus DVOI2C_E initialized. @@ -194,7 +197,7 @@ (II) LoadModule: ivch (II) Loading /usr/lib/xorg/modules/drivers//ivch.so (II) Module ivch: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_E removed. (II) intel(0): I2C bus DVOI2C_B initialized. @@ -202,7 +205,7 @@ (II) LoadModule: tfp410 (II) Loading /usr/lib/xorg/modules/drivers//tfp410.so (II) Module tfp410: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_B removed. (II) intel(0): I2C bus DVOI2C_E initialized. @@ -210,13 +213,12 @@ (II)
Bug#525123: xserver-xorg-video-intel on Intel 82852/855GM: display corrupted
Following up on my message to this bug When I upgraded to driver version 2.8.0, I had terrible performance. I reported it as bug 541117. It turned out that I had to re-enable dri to fix that. Fortunately, I don't see this bug any more! Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541117: xserver-xorg-video-intel: high CPU usage after 2.7.1-1 - 2.8.0-1 upgrade
Package: xserver-xorg-video-intel Version: 2:2.8.0-1 Severity: important After upgrading from 2.7.1-1, firefox is terribly slow and causes xorg to pin the CPU for several seconds when (for example) switching tabs. I'm running kernel linux-image-2.6.30-1-686 on a Thinkpad X40. I've looked through the other bugs, and I don't think my problem matches any of them. I also observe that when I resume from suspend to ram, my background is corrupt. And I've had a couple crashes. None of this happened with 2.7.1-1. 2:2.8.0-2 has the same behavior. Finding a hint in bug 538283, I tried adding the i915 module with modeset=1. I made the changes in /etc/modules and /etc/modprobe.d/local.conf and rebooted. The effect on the text VCs was obvious, but when I tried to startx, it hung with a blank screen. BTW, the Xorg.0.log file included below is actually Xorg.0.log.old, since I'm running the downgraded X now. It is the log file that corresponds with the bad behavior. Any hints on where to look? Thanks, Andrew PS. How do you downgrade these days, since snapshot.debian.net is stale? I found a source package at Ubuntu launchpad, but it was a pain. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2008-10-22 10:53 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1689976 2009-08-06 09:55 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 865 2009-05-10 10:55 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Module # bugs.debian.org/525123 Disable dri EndSection Section Device Identifier Configured Video Device EndSection # Mouse wheel emulation now configured in # /etc/hal/fdi/policy/20thirdparty/10-x11-evdev.fdi # Progress! Xorg X server log files on system: -rw-rw-r-- 1 root root 67514 2006-01-12 14:22 /var/log/Xorg.2.log -rw-rw-r-- 1 root root 36581 2009-05-11 12:18 /var/log/Xorg.1.log -rw-rw-r-- 1 root root 53946 2009-08-11 11:00 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log.old: X.Org X Server 1.6.3 Release Date: 2009-7-31 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.30.4-dsa-ia32 i686 Debian Current Operating System: Linux apple 2.6.30-1-686 #1 SMP Mon Aug 3 16:18:30 UTC 2009 i686 Build Date: 06 August 2009 04:49:57PM xorg-server 2:1.6.3-1+b1 (bui...@murphy.debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Tue Aug 11 10:21:00 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No device specified for screen Default Screen Section. Using the first device section listed. (**) | |--Device Configured Video Device (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) Loader magic: 0x6c0 (II) Module ABI
Bug#541153: sun-java5-plugin: update-alternatives complains on purge
Package: sun-java5-plugin Version: 1.5.0-20-1 Severity: minor When I purged, I got lots of messages like update-alternatives: warning: alternative /usr/lib/jvm/java-1.5.0-sun/bin/HtmlConverter (part of link group HtmlConverter) doesn't exist. Removing from list of alternatives. I think this because the update-alternatives calls are in the postrm, after the files are gone, instead of the prerm. But the files are gone and I didn't go back and check. Andrew -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-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 sun-java5-plugin depends on: ii iceweasel 3.0.12-1 lightweight web browser based on M ii libasound21.0.20-3 shared library for ALSA applicatio ii libx11-6 2:1.2.2-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.2.1-2 X11 Input extension library ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension pn sun-java5-bin none (no description available) sun-java5-plugin recommends no packages. sun-java5-plugin 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#541154: sun-java6-plugin: mention that plugins don't show up when Enable Java not selected in iceweasel
Package: sun-java6-plugin Version: 6-15-1 Severity: wishlist This is definitely a user error, but since it frustrated me, I thought you could mention it in the documentation (eg README.Debian). If in your iceweasel Edit/Preferences, under Content, you have Enable Java unchecked, the java plug-in will not show up in about:plugins even if it is available. I had it unchecked (for some reason), which made me think the sun-java6-plugin wasn't working. And it was unexpected that there was another setting that would override the availability of the plug-in. So maybe you could just suggest verifying that Enable Java is checked. (If you go to Tools/Add-ons under Plugins, the Java plug-in is visible but greyed out.) Andrew -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-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 sun-java6-plugin depends on: ii iceweasel 3.0.12-1 lightweight web browser based on M ii libasound21.0.20-3 shared library for ALSA applicatio ii libx11-6 2:1.2.2-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.2.1-2 X11 Input extension library ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension ii sun-java6-bin 6-15-1 Sun Java(TM) Runtime Environment ( ii xulrunner-1.9 1.9.0.12-1 XUL + XPCOM application runner sun-java6-plugin recommends no packages. sun-java6-plugin 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#337132: atjobs/.SEQ has wrong ownership
I see this problem with 3.1.10.2: % at midnight Cannot open lockfile /var/spool/cron/atjobs/.SEQ: Permission denied However, contrary to the original poster, atd is running on my system. The rpoblem for me is that atjobs/.SEQ is owned by root: % sudo ls -l /var/spool/cron/atjobs/.SEQ -rw--- 1 root root 0 2008-10-22 10:17 /var/spool/cron/atjobs/.SEQ On a stable system, it is owned by daemon.daemon. Changing ownership back to daemon.daemon allows at to work again. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537885: nosql: refers to buildd directory
Package: nosql Version: 4.0.14-5 Severity: grave Justification: renders package unusable The 4.0.14-5 build refers to a buildd directory: % /usr/lib/nosql/jointable mawk: cannot open /build/buildd-nosql_4.0.14-5-i386-ba5oQD/nosql-4.0.14/debian/nosql/usr/lib/nosql/lib/jointable.awk (No such file or directory) Also, the master nosql executable refers to /usr/local/nosql/bin instead of /usr/lib/nosql: % nosql jointable /usr/bin/nosql: 62: /usr/local/nosql/bin/jointable: not found Both of these worked in 4.0.14-4. Andrew -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.29-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 nosql depends on: ii coreutils 7.4-2 The GNU core utilities ii dash 0.5.5.1-2 POSIX-compliant shell ii debianutils 3.2Miscellaneous utilities specific t ii libc6 2.9-21 GNU C Library: Shared libraries ii mawk 1.3.3-14 a pattern scanning and text proces ii perl 5.10.0-24 Larry Wall's Practical Extraction ii procmail 3.22-16Versatile e-mail processor nosql recommends no packages. Versions of packages nosql suggests: ii rcs 5.7-25 The GNU Revision Control System -- 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#496740: cannot execute binary file
I just ran across this issue in a different way, where it wasn't obvious what was going on. Basically, I confused my su syntax and ran something like % su andrew id Password: /usr/bin/id: /usr/bin/id: cannot execute binary file What a baffling message that is! It looks like a system error (rather than an arbitrary decision by bash), and bash doesn't even mention that it's involved. A clear message would have saved me some grief. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475097: powersaved: Thinkpad T60: Fn+F4 no longer suspends-to-ram machine
There appears to have been some progress on this bug. powersaved now responds to Fn+F4. It seems to get the event from HAL (when I stop hal, powersaved no longer responds). Wow, is the future really here?? No, things are still badly broken: - Fn+F4 suspends to disk, not ram. - Fn+F12 does nothing. - In /etc/powersave/events, there appears to be only one event (EVENT_BUTTON_SLEEP) we can respond to. - Have they never heard of separate sleep and hibernate buttons? - Where are the events even documented? (nowhere!) - In /etc/powersave/events, the possible actions appear to be suspend_to_disk and suspend_to_ram. - Have they never heard of the most useful hybrid (aka s2both) mode? - Is there any setting to use hybrid mode for suspend? (no, it goes through HAL, and HAL offers no such configurability) - Digging through powersave_manual.txt.gz reveals several instances of the string novell, which pretty much explains all of the above. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526823: getaddrinfo still fails
On Tue, May 12, 2009 at 01:31:40AM +0200, Aurelien Jarno wrote: On Mon, May 11, 2009 at 11:53:17AM -0700, Andrew Pimlott wrote: This problem is back for me as well, after being fixed in 2.9-6. 2.9-7 works, 2.9-10 fails. options single-request in my resolv.conf does nothing. (Could you verify that is the correct syntax?) Here is my DNS trace with single-request set. Yes, this option is the correct one. Note that this has improved in version 2.9-12. You should try this version. That test was under 2.9-12. Sorry for not mentioning. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525123: xserver-xorg-video-intel on Intel 82852/855GM: display corrupted
I observe the same on my Thinkpad X40, and use the workaround of disabling DRI (thanks Joe!). This is the first version of the -intel driver I've tried; the -i810 driver worked fine. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526823: getaddrinfo still fails
This problem is back for me as well, after being fixed in 2.9-6. 2.9-7 works, 2.9-10 fails. options single-request in my resolv.conf does nothing. (Could you verify that is the correct syntax?) Here is my DNS trace with single-request set. 11:51:45.491726 IP (tos 0x0, ttl 64, id 26230, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.43124 192.168.0.1.53: [udp sum ok] 39751+ A? google.com. (28) 11:51:45.497307 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72) 192.168.0.1.53 192.168.0.101.43124: [udp sum ok] 39751- q: A? google.com. 1/0/0 google.com. A 74.125.67.100 (44) 11:51:45.497435 IP (tos 0x0, ttl 64, id 26231, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.43124 192.168.0.1.53: [udp sum ok] 48239+ ? google.com. (28) 11:51:45.521547 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.1.53 192.168.0.101.43124: [udp sum ok] 48239- q: ? google.com. 0/0/0 (28) 11:51:45.522358 IP (tos 0x0, ttl 64, id 26237, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.56385 192.168.0.1.53: [udp sum ok] 39751+ A? google.com. (28) 11:51:45.525636 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72) 192.168.0.1.53 192.168.0.101.56385: [udp sum ok] 39751- q: A? google.com. 1/0/0 google.com. A 74.125.67.100 (44) 11:51:45.525705 IP (tos 0x0, ttl 64, id 26238, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.56385 192.168.0.1.53: [udp sum ok] 48239+ ? google.com. (28) 11:51:45.550947 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.1.53 192.168.0.101.56385: [udp sum ok] 48239- q: ? google.com. 0/0/0 (28) 11:51:45.551705 IP (tos 0x0, ttl 64, id 26245, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.57011 192.168.0.1.53: [udp sum ok] 37693+ A? google.com. (28) 11:51:45.555200 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72) 192.168.0.1.53 192.168.0.101.57011: [udp sum ok] 37693- q: A? google.com. 1/0/0 google.com. A 74.125.67.100 (44) 11:51:45.555263 IP (tos 0x0, ttl 64, id 26246, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.57011 192.168.0.1.53: [udp sum ok] 14101+ ? google.com. (28) 11:51:45.578284 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.1.53 192.168.0.101.57011: [udp sum ok] 14101- q: ? google.com. 0/0/0 (28) 11:51:45.578958 IP (tos 0x0, ttl 64, id 26251, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.43912 192.168.0.1.53: [udp sum ok] 37693+ A? google.com. (28) 11:51:45.582282 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72) 192.168.0.1.53 192.168.0.101.43912: [udp sum ok] 37693- q: A? google.com. 1/0/0 google.com. A 74.125.67.100 (44) 11:51:45.582343 IP (tos 0x0, ttl 64, id 26252, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.101.43912 192.168.0.1.53: [udp sum ok] 14101+ ? google.com. (28) 11:51:45.610221 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 56) 192.168.0.1.53 192.168.0.101.43912: [udp sum ok] 14101- q: ? google.com. 0/0/0 (28) Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528261: xserver-xorg: new mouse configuration needs examples
Package: xserver-xorg Version: 1:7.4+1 Severity: wishlist I found out from NEWS.Debian about the changes to configuration of input devices in X. It all seems fine, except that it took me a while to figure out exactly how to port over my xorg.conf to HAL (file location, syntax, restarting hald). I think a template fdi file would go a long way towards helping users figure out where to put their options. For example, you could install the following as /etc/hal/fdi/policy/x11-mouse.fdi: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.mouse match key=/org/freedesktop/Hal/devices/computer:system.kernel.name string=Linux !-- Add mouse options from xorg.conf here. For example, if you had Option EmulateWheel on, add merge key=input.x11_options.EmulateWheel type=stringon/merge Don't forget to run /etc/init.d/hal restart! -- /match /match /device /deviceinfo Andrew -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2008-10-22 10:53 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1695356 2009-04-15 04:47 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 865 2009-05-10 10:55 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Module # bugs.debian.org/525123 Disable dri EndSection Section Device Identifier Configured Video Device EndSection # Mouse wheel emulation now configured in # /etc/hal/fdi/policy/20thirdparty/10-x11-evdev.fdi # Progress! Xorg X server log files on system: -rw-rw-r-- 1 root root 67514 2006-01-12 14:22 /var/log/Xorg.2.log -rw-rw-r-- 1 root root 36581 2009-05-10 10:54 /var/log/Xorg.1.log -rw-rw-r-- 1 root root 35864 2009-05-10 10:59 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.26-1-amd64 x86_64 Package files: 100 /var/lib/dpkg/status release a=now 500 http://ftp.debian.org sid/main Packages release o=Debian,a=unstable,l=Debian,c=main origin ftp.debian.org Pinned packages: Current Operating System: Linux apple 2.6.29-1-686 #1 SMP Fri Apr 17 14:35:16 UTC 2009 i686 Build Date: 15 April 2009 11:46:22AM xorg-server 2:1.6.1-1 (bgog...@debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun May 10 10:59:18 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No device specified for screen Default Screen Section. Using the first device section listed. (**) | |--Device Configured Video Device (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available,
Bug#516218: getaddrinfo not working while gethostbyname works
My DSL router also triggered this issue. I just want to add the note that for me, getaddrinfo does occasionally return correct results, indicating that the flakiness of the DNS server is timing dependent. What a maddening problem to diagnose! Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517256: #517256 xpdf claims exclusive access to audio device
On Thu, Feb 26, 2009 at 06:30:55PM +, Steve Cotton wrote: This sounds like #496958 . Could that xpdf-reader instance have been launched from IceWeasel? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496958 Oh, of course. I don't know why I didn't think of this other than that it is so stupid. :-/ Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517256: xpdf-reader: xpdf claims exclusive access to audio device /dev/snd/pcmC0D0p
Package: xpdf-reader Version: 3.02-1.4 Severity: normal Sound seemed to stop working on my system one day, with errors like ALSA lib pcm_dmix.c:996:(snd_pcm_dmix_open) unable to open slave Using strace, I found a failure to open /dev/snd/pcmC0D0p. And lsof revealed % sudo lsof /dev/snd/pcmC0D0p COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME xpdf.bin 1514 andrew 75u CHR 116,16 4909 /dev/snd/pcmC0D0p Closing xpdf indeed fixed the problem. However, I can't replicate this. I opened up the same PDF file again, and this time xpdf did not open a sound device, nor did it open anywhere near 75 file descriptors. I have no idea what I did to cause this. I'll only follow up on this if it happens again. Andrew -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-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 xpdf-reader depends on: ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre ii lesstif2 1:0.95.0-2.1 OSF/Motif 2.1 implementation relea ii libc6 2.7-18 GNU C Library: Shared libraries ii libfreetype6 2.3.7-2FreeType 2 font engine, shared lib ii libgcc1 1:4.3.3-3 GCC support library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libpaper1 1.1.23+nmu1library for handling paper charact ii libsm62:1.0.3-2 X11 Session Management library ii libstdc++64.3.3-3The GNU Standard C++ Library v3 ii libt1-5 5.1.2-3Type 1 font rasterizer library - r ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxp61:1.0.0.xsf1-2 X Printing Extension (Xprint) clie ii libxpm4 1:3.5.7-1 X11 pixmap library ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii xpdf-common 3.02-1.4 Portable Document Format (PDF) sui xpdf-reader recommends no packages. Versions of packages xpdf-reader suggests: ii conkeror [www-browser] 0.9~git080629-2 keyboard focused web browser with ii iceweasel [www-browser] 3.0.6-1 lightweight web browser based on M ii lynx-cur [www-browser] 2.8.7dev13-1Text-mode WWW Browser with NLS sup ii w3m [www-browser]0.5.2-2+b1 WWW browsable pager with excellent -- 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#465454: fvwm: EdgeMoveResistance does not affect top edge
Package: fvwm Version: 1:2.5.24-1 Severity: normal I just upgraded from 1:2.5.23-2, and had EdgeResistance 0 100 in my .fvwm2rc. When I restarted, windows being moved would properly resist on the left, bottom, and right edges, but not the top. Moving windows off the top of the screen happened with no resistence. I followed the instructions to upgrade my EdgeResistance directive to EdgeResistance, EdgeMoveDelay, and EdgeMoveResistance: EdgeResistance 0 Style * EdgeMoveDelay 0 Style * EdgeMoveResistance 100 However, the behavior persists. My full .fvwm2rc is attached. (And if you want to try it, note that you can pick move from the middle button root menu.) Andrew -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-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 fvwm depends on: ii libc6 2.7-6 GNU C Library: Shared libraries ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype6 2.3.5-1+b1FreeType 2 font engine, shared lib ii libfribidi00.10.9-1 Free Implementation of the Unicode ii libglib1.2ldbl 1.2.10-19 The GLib library of C routines ii libglib2.0-0 2.14.6-1 The GLib library of C routines ii libgtk1.2 1.2.10-18.1 The GIMP Toolkit set of widgets fo ii libgtk2.0-02.12.7-1 The GTK+ graphical user interface ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libncurses55.6+20080119-1Shared libraries for terminal hand ii libpng12-0 1.2.15~beta5-3PNG library - runtime ii libreadline5 5.2-3 GNU readline and history libraries ii librplay3 3.3.2-11 Shared libraries for the rplay net ii librsvg2-2 2.20.0-1 SAX-based renderer library for SVG ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstroke0 0.5.1-6 mouse strokes library -- runtime f ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor11:1.1.9-1 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxft22.1.12-2 FreeType-based font drawing librar ii libxi6 2:1.1.3-1 X11 Input extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxpm41:3.5.7-1 X11 pixmap library ii libxrender11:0.9.4-1 X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime Versions of packages fvwm recommends: ii fvwm-icons 2001.08.13-6 XPMs icons from fvwm development s -- debconf information: fvwm/upgrade/pre_2.5.8: false Style * ForeColor black, BackColor darkgrey Style * HilightFore white, HilightBack steelblue Style * NoTitle Style * BorderWidth 1, HandleWidth 1 ButtonStyle 2 Vector 17 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 4 Vector 5 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 6 Vector 4 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Style * MinOverlapPercentPlacement Style XTerm ManualPlacement Style xvncviewer HandleWidth 0 Style Vncviewer HandleWidth 0 Style Vmware HandleWidth 0 Style GQview HandleWidth 0 MenuStyle * Font xft:sans-serif:Medium # work-around for buggy default in FvwmForm. # NB, not actually necessary anymore; bug 264016 *FvwmFormDefault: Font -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-* *FvwmFormDefault: InputFont -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-* *FvwmFormDefault: ButtonFont -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-* *FvwmFormDefault: TimeoutFont -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-* Style * SnapAttraction 10 Windows EdgeThickness 0 EdgeResistance 0 Style * EdgeMoveDelay 0 Style * EdgeMoveResistance 100 Style * SloppyFocus DeskTopSize 3x3 Style * MWMFunctions Style * MWMDecor Style * HintOverride Style * OLDecor # mouse bindings # ButtonContext Modifi Function Mouse 1 R A Menu Utilities mouse -1p -1p Mouse 2 R A Menu Window mouse -1p -1p Mouse 3 R A
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
On Sat, Jul 14, 2007 at 11:08:30AM +0200, martin f krafft wrote: also sprach Andrew Pimlott [EMAIL PROTECTED] [2007.07.13.2224 +0200]: One solution would be for hibernate to recognize the 0x20 exit status from s2ram -n. There could be an option USuspendRamUnsureOk yes that tells hibernate to proceed in this case, and not pass -f to s2ram. Just an idea, maybe you know a better way. Good idea. I've implemented this; does the following patch work for you? Not quite--the unsure check should be in EnsureUSuspendCapable, since -n mode is the only place where s2ram exits with a non-zero status for unsure systems. Here is an alternative, that I've quickly tested, but be warned that I don't do much shell scripting. Andrew --- ususpend.bak2007-07-16 21:09:42.0 -0700 +++ ususpend2007-07-16 23:03:21.0 -0700 @@ -6,6 +6,7 @@ AddConfigHelp USuspendMethod disk|ram|both Enables use of the uswsusp suspend method of newer kernels (= 2.6.17rc1) AddConfigHelp USuspendRamForce boolean Passes the -f flag to s2ram to force suspending even if the machine is not recognised +AddConfigHelp USuspendRamUnsureOk boolean Instructs s2ram to continue when it's unsure about the system type, thus not requiring -f to be passed AddConfigHelp USuspendRamVbeSave boolean Passes the -s flag to s2ram to save VBE state before suspending and restore after resume AddConfigHelp USuspendRamVbePost boolean Passes the -p flag to s2ram to VBE POST the graphics card after resume AddConfigHelp USuspendRamVbeMode boolean Passes the -m flag to s2ram to get VBE mode before suspend and set it after resume @@ -18,6 +19,7 @@ USUSPEND_DEVICE=/dev/snapshot USUSPEND_PROG=s2disk USUSPEND_RAM_FORCE=0 +USUSPEND_RAM_UNSUREOK=0 USUSPEND_RAM_VBESAVE=0 USUSPEND_RAM_VBEPOST=0 USUSPEND_RAM_VBEMODE=0 @@ -49,6 +51,9 @@ ususpendramforce) BoolIsOn $1 $2 USUSPEND_RAM_FORCE=1 || return 0 ;; + ususpendramunsureok) + BoolIsOn $1 $2 USUSPEND_RAM_UNSUREOK=1 || return 0 + ;; ususpendramvbesave) BoolIsOn $1 $2 USUSPEND_RAM_VBESAVE=1 || return 0 ;; @@ -110,10 +115,21 @@ vecho 0 $USUSPEND_PROG not installed. return 2 fi -if [ $USUSPEND_PROG = s2ram ] [ $USUSPEND_RAM_FORCE -eq 0 ] \ -! $USUSPEND_PROG -n /dev/null; then - vecho 0 $USUSPEND_PROG: unknown machine, see s2ram(8) and the USuspendRamForce option - return 2 +if [ $USUSPEND_PROG = s2ram ] [ $USUSPEND_RAM_FORCE -eq 0 ]; then + $USUSPEND_PROG -n /dev/null + ret=$? + case $ret/$USUSPEND_RAM_UNSUREOK in + 0/*) :;; + 32/1) :;; # unsure, but USuspendRamUnsureOk passed + 32/*) + vecho 0 $USUSPEND_PROG: unsure about your machine, see the USuspendRamUnsureOk option + return 2 + ;; + *) + vecho 0 $USUSPEND_PROG: unknown machine, see s2ram(8) and the USuspendRamForce option + return 2 + ;; + esac fi if ! test -f $USUSPEND_STATE_FILE ; then vecho 0 Your kernel does not have power management built in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
On Tue, Jul 17, 2007 at 12:13:25PM +0200, martin f krafft wrote: Please try the following patch against the original ususpend scriptlet (the one provided by the package): [snip] + USUSPEND_PROG -n /dev/null You left off a $ here. :-) Other than that, it works fine. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
Package: hibernate Version: 1.96~pre-svn.r1136-1 Severity: normal I am using hibernate with the ususpend-ram configuration. When I run s2ram -n, it comes back with ATTENTION: Your machine is in the whitelist but the entry has not been confirmed. and the program exits with status 0x20 (UNSURE in s2ram-x86.c). As a result, hibernate refuses to continue unless I set USuspendRamForce yes. The problem with this is, when you use s2ram -f, s2ram does not consult its whitelist at all, so it doesn't use the settings for my system. (Even though they're UNSURE, they're probably better than nothing.) One solution would be for hibernate to recognize the 0x20 exit status from s2ram -n. There could be an option USuspendRamUnsureOk yes that tells hibernate to proceed in this case, and not pass -f to s2ram. Just an idea, maybe you know a better way. Andrew -- Package-specific info: --- configuration == /etc/hibernate/common.conf == Verbosity 0 LogFile /var/log/hibernate.log LogVerbosity 1 Distribution debian SaveClock restore-only UnloadBlacklistedModules yes LoadModules auto SwitchToTextMode yes == /etc/hibernate/disk.conf == TryMethod ususpend-disk.conf TryMethod sysfs-disk.conf == /etc/hibernate/hibernate.conf == TryMethod suspend2.conf TryMethod disk.conf TryMethod ram.conf == /etc/hibernate/ram.conf == TryMethod ususpend-ram.conf TryMethod sysfs-ram.conf == /etc/hibernate/suspend2.conf == UseSuspend2 yes Reboot no EnableEscape yes DefaultConsoleLevel 1 Compressor lzf Encryptor none FullSpeedCPU yes Include common.conf == /etc/hibernate/sysfs-disk.conf == UseSysfsPowerState disk Include common.conf == /etc/hibernate/sysfs-ram.conf == UseSysfsPowerState mem Include common.conf == /etc/hibernate/ususpend-both.conf == USuspendMethod both Include common.conf == /etc/hibernate/ususpend-disk.conf == USuspendMethod disk Include common.conf == /etc/hibernate/ususpend-ram.conf == USuspendMethod ram Include common.conf --- /sys/power == /sys/power/disk == platform == /sys/power/image_size == 524288000 == /sys/power/resume == 0:0 == /sys/power/state == mem disk --- s2ram -n Machine unknown This machine can be identified by: sys_vendor = sys_product = sys_version = bios_version = --- log hibernate.log file not readable. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-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 hibernate depends on: ii console-tools 1:0.2.3dbs-65 Linux console and font utilities Versions of packages hibernate recommends: ii dash 0.5.3-9 The Debian Almquist Shell ii hdparm 7.5-1 tune hard disk parameters for high ii uswsusp0.6~cvs20070618-1 tools to use userspace software su ii vbetool0.7-1.1 run real-mode video BIOS code to a -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429715: cupsys-client: printing to a remote IPP printer is dang hard
Package: cupsys-client Version: 1.2.11-3 Severity: important My friend gave me the IPP URL of his printer. Not knowing much about this newfangled protocol, I installed cupsys-client, thinking (based on the package description) it would be a cinch to access the printer. It turned out to be an ordeal. I'm filing this bug as important even though nothing is necessarily (?) broken, because basic functionality is either missing or exceedingly difficult and frustrating to figure out. If this should be routed upstream, let me know, but I thought it would be best to start in the Debian BTS. The URL was of the form ipp://192.168.0.10/printers/HPLJ1012 I started by looking in the lp and lpstat man pages, expecting to find a URL option. Nothing. Then I tried to find some documentation on what to do with the URL, what parts of it to pass to what options of lp/lpstat. All I found was the IPP URL RFC, which isn't very accessible and is not helpful directly. So I experimented. I started with the lpstat program. Passing 192.168.0.10 to the -h option was fairly obvious. Using the -r option, I was able to ping the server. But using, say, -t returned several repetitions of lpstat: Forbidden and nothing else useful. I figured maybe I had to query this printer specifically. The first problem is I didn't know whether the name of the printer should be /printers/HPLJ1012, HPLJ1012, or something else. I tried passing variations to -a, -p, and -v, but I always got lpstat: Unknown destination \HPLJ1012\!. So it seemed like the remote server didn't recognize the printer name. But when I investigated further by running the command under strace, I found that the string HPLJ1012 was never even sent to the server! In fact, the Unknown destination message was printed after failed attempts to read a file called lpoptions. Why it needs to read a local file about a remote printer I have no idea. I looked at the lpoptions man page, but I didn't see anything that looked relevant. At a loss, I turned my attention to lp, and finally I caught a break. I passed HPLJ1012 to the -d option, gave a PDF file on the command line (although the man page says nothing about what format the file should be in, so that was a guess), and got a printout. Looking at the strace of the run, I found it curious that there were several POST / requests that all got 403 Forbidden responses, before finally a POST /printers/HPLJ1012 (hey--this program does know how to construct the URL, it just doesn't accept it!) succeeded. I don't know whether this represents a misconfiguration of the server, or futility on the part of the client. And even after this, I never figured out how to use lpstat to get job status, etc. So in the end, I can at least print (though not query), but I still don't know how I was supposed to figure it out. If I missed something, maybe it could be documented more prominently. Andrew -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-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 cupsys-client depends on: ii adduser 3.102 Add and remove users and groups ii cupsys-common 1.2.11-3 Common UNIX Printing System(tm) - ii libc6 2.5-11 GNU C Library: Shared libraries ii libcupsys21.2.11-3 Common UNIX Printing System(tm) - ii libgnutls13 1.6.3-1the GNU TLS library - runtime libr ii zlib1g1:1.2.3-15 compression library - runtime Versions of packages cupsys-client recommends: ii cupsys-bsd1.2.11-3 Common UNIX Printing System(tm) - -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418910: HOWTO replace dsearch in dc_other_hostnames
On Thu, May 17, 2007 at 01:04:02PM +0200, Andreas Metzler wrote: ... That is correct afaict ( for the non-split-config case.) cu andreas I assume you're not implying that it is incorrect for the split-config case, because that's what I'm using. :-) In other words, it should work for everyone. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418910: HOWTO replace dsearch in dc_other_hostnames
NEWS.Debian suggests using the macro mechanism to replace the no-longer-working dsearch entry in dc_other_hostnames. I thought it would be helpful to include an example, since this seems to affect many people. Could someone verify that this is correct, and perhaps include it in the documentation? In short, if you used to enter pimlott.net:dsearch;/etc/exim4/virtual in dc_other_hostnames (ie, the question Other destinations for which mail is accepted:), then you should instead add the following line to exim4.conf.localmacros: MAIN_LOCAL_DOMAINS = @:localhost:pimlott.net:dsearch;/etc/exim4/virtual What you put in dc_other_hostnames is no longer used. Works for me! Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421526: gij bug not fixed--wrong upload
Hi. The upload with which you closed this bug does not include the gij-4.1 package, so the bug is still in fact open in the archive. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#252214: /usr/X11R6/bin/xev: xev -id misses events
On Thu, Apr 12, 2007 at 10:15:01PM +0200, Brice Goglin wrote: About 3 years ago, you reported a bug to the Debian BTS regarding xev -id missing some events. Did you reproduce this problem recently? With Xorg/Etch? If not, I will close this bug in the next weeks. Thank you again for following up! On a current unstable system, the behavior is the same as indicated in the bug log. In case it helps, here are more explicit steps to reproduce: 1. Open an xterm. 2. Run xprop | grep -w id, click on the xterm, and note the id. 3. Run xev -id 0x, where the last argument is the id. 4. Play around in the xterm and note the mysterious behavior. This bug probable needs a NOBODYCARES tag. :-) Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264016: fvwm: FvwmForm uses bad fonts in utf-8 locale
On Fri, Apr 13, 2007 at 03:49:40AM +0200, Brice Goglin wrote: About 3 years ago, you reported a bug to the Debian BTS regarding FvwmForm using bad fonts in utf8 locale. Do you still experience this problem today? No. It seems that fonts with the iso8859-1 encoding now display fine in a UTF-8 locale. Perhaps it was only a bug in X that made it break before. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264017: iso8859-1 fonts work fine in a UTF-8 locale
In following up on bug 264016, I found that this bug no longer occurs (in unstable). A font with an iso8859-1 displays just fine in my UTF-8 locale. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241423: xserver-xfree86: [nv] fails for GeForce FX Go5200 rev 161
On Tue, Jan 16, 2007 at 08:40:32PM +0100, Brice Goglin wrote: About 2 years ago, you reported (or replied to) a bug in the Debian BTS regarding a failure of the X server on a nVidia GeForce RX Go2500 board. Did any of you guys reproduce this problem recently? This hardware is long gone for me. Thanks for following up though! Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216161: xserver-xfree86: font resolution not following the rules
On Sun, Jan 14, 2007 at 02:59:38AM +0100, Brice Goglin wrote: About 3 years ago, you reported a bug to the Debian BTS regarding font resolution not following the rules. Did you reproduce this problem recently? If not, I will close this bug in the next weeks. Well, I can confirm the same behavior as I reported on a current unstable system. However, in the process of testing I noticed something I probably missed before. When I remove the gsfonts-x11 aliases, the font chosen when I run xfd -fn '-adobe-times-bold-r-normal--17-120-100-100-p-86-iso8859-1' is -adobe-times-bold-r-normal--17-120-100-100-p-87-iso8859-1 Note the 86 becomes 87. (This is the average width field, measured in tenths of pixels according to X(7).) This caused me to suspect that the bitmap font was being skipped according to the rule in /usr/share/X11/doc/fonts.txt: When matching fonts, the server makes two passes over the font path: during the first pass, it searches for an exact match; during the second, it searches for fonts suitable for scaling. But here's the wicked thing: If you look at /usr/share/fonts/X11/100dpi/fonts.dir, you find timB12-ISO8859-1.pcf.gz -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1 Note the width is 88! So where did the 87 come from? That I have no idea. Anyhow, if I restore the gsfonts-x11 aliases and ask for -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1 then I get the expected bitmap font. I have no idea anymore where the example font string came from; probably I changed it in some config file long ago. At this point, the issue doesn't matter to me, and based on the above investigation, the behavior in fact looks pretty sane. The only reason to keep this bug open, IMO, would be to understand the 86/87 quirk. But you can close it for all I care. Sorry for the long mail, and thanks again for following up. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366184: libghc6-c2hs-dev: should pre-depend on ghc6
On Fri, Sep 08, 2006 at 05:05:11PM +0200, Arjan Oosting wrote: Sorry for the long delay and thanks for the extra information, it has been useful. Thanks to you for coming back to this--I meant to and just haven't gotten around to it. So because ghc6 is being upgraded /usr/bin/ghc-pkg is not available and the prerm script of libghc6-c2hs-dev fails. This can be fixed by calling /usr/lib/ghc-6.4.1/bin/ghc-pkg or calling /usr/bin/ghc-pkg6 in the prerm script. So the bug has been found. As libghc6-c2hs-dev is not available in unstable anymore I am closing this bug. Sounds good. I assume that the same issue would arise for any Debian package containing a GHC package, right? If so, I guess this should be advertised as the correct way to register/deregister GHC packages. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
I suspect I have a similar problem to the reporter of this bug. I have a swap partition that is set up as an encrypted dm device with a random key, using the cryptsetup package. cryptsetup now has a test that calls vol_id, which thinks that my partition is vfat: % sudo /lib/udev/vol_id /dev/hda2 ID_FS_USAGE=filesystem ID_FS_TYPE=vfat ID_FS_VERSION=FAT32 ID_FS_UUID= ID_FS_LABEL= ID_FS_LABEL_SAFE= % sudo mount -t vfat /dev/hda2 /mnt/tmp mount: /dev/hda2: can't read superblock Inspecting this partition, I see clearly MSDOS5.0, presumably the long-preserved remnants of a vfat filesystem. However, since the kernel refuses to mount the partition as vfat, it seems that vol_id could apply a stricter check. I realize that vol_id can never be perfect, since the device metadata may be consistent with multiple formats. And I agree that device initialization tools (like mkswap) should zero out part of the device. But it would still help to make vol_id more exact, because this issue evidently bites users in practice. Perhaps there could be flags for quick-and-dirty check versus more complete check. I can send the strace output from running vol_id on this partition if somebody would like to look at it. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383581: util-linux: mkswap should zero start of device
Package: util-linux Version: 2.12r-10 Severity: wishlist mkswap does not touch the first 1k of the device. This means that if the device was formatted before, it may look like it still has the old format. This fools format detection tools, such as vol_id in the udev package. Some responders to bug 366853 against udev suggested that mkswap should zero the first 64k of the device to avoid this problem. I am opening this bug to discuss that suggestion. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages util-linux depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libncurses5 5.5-2 Shared libraries for terminal hand ii libslang2 2.0.6-2The S-Lang programming library - r ii libuuid1 1.39-1 universally unique id library ii lsb-base 3.1-10 Linux Standard Base 3.1 init scrip ii zlib1g1:1.2.3-12 compression library - runtime util-linux recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
To follow up, I just filed bug 383581 against util-linux (the package of mkswap). I chose to pick on mkswap because that was the case I could reproduce--indeed, it leaves the first 1k (containing MSDOS5.0) untouched; whereas mke2fs overwrote it. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Fri, Aug 18, 2006 at 02:13:53PM +0200, Kay Sievers wrote: It's almost impossible to make libvolume_id stricter, in most cases, even the kernel mounts a mkswap formatted (and obviously corrupt) fat volume just fine and allows writing to it. Ok, thanks for the explanation. It's mkswap which is horribly broken here and needs to be fixed. Hopefully the bug I filed with util-linux will produce some change. You can just use dd and clean the volume before reformatting it. Right--I've done that to the partition, and now I have no problem. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383106: libio-socket-ssl-perl: new version breaks Net::HTTPS
Package: libio-socket-ssl-perl
Version: 0.998-1
Severity: important
After some recent unstable upgrades, one of my perl programs could no
longer connect to SSL servers. The problem appears to be an interaction
between IO::Socket::INET, IO::Socket::SSL, and Net::HTTPS. I believe it
was a change in IO::Socket::SSL that triggered it, so I'm filing the bug
here (even if IO::Socket::SSL is not necessarily to blame) to make you
aware of it. I suppose you can either work around the issue or pass the
buck to libww-perl.
First, here is a test program that demonstrates the problem:
#!/usr/bin/perl
use IO::Socket::SSL ();
use Net::HTTPS ();
my $s = Net::HTTPS-new(
PeerAddr= localhost:443,
)
or die problem connecting;
This program will die without even trying to connect. Here is a
backtrace just before the failure:
$ = Net::HTTPS::blocking(ref(Net::HTTPS), 1) called from file
`/usr/lib/perl/5.8/IO/Socket/INET.pm' line 150
$ = IO::Socket::INET::configure(ref(Net::HTTPS), ref(HASH)) called from
file `/usr/share/perl5/IO/Socket/SSL.pm' line 97
$ = IO::Socket::SSL::configure(ref(Net::HTTPS), ref(HASH)) called from file
`/usr/share/perl5/Net/HTTPS.pm' line 43
$ = Net::HTTPS::http_connect(ref(Net::HTTPS), ref(HASH)) called from file
`/usr/share/perl5/Net/HTTP/Methods.pm' line 49
$ = Net::HTTP::Methods::http_configure(ref(Net::HTTPS), ref(HASH)) called
from file `/usr/share/perl5/Net/HTTPS.pm' line 38
$ = Net::HTTPS::configure(ref(Net::HTTPS), ref(HASH)) called from file
`/usr/lib/perl/5.8/IO/Socket.pm' line 48
$ = IO::Socket::new('Net::HTTPS', 'PeerAddr', 'localhost:443', 'Proto',
'tcp') called from file `/usr/lib/perl/5.8/IO/Socket/INET.pm' line 32
$ = IO::Socket::INET::new('Net::HTTPS', 'PeerAddr', 'localhost:443',
'Proto', 'tcp') called from file `try' line 6
Note that in IO::Socket::SSL::configure line 93 forces the socket to be
blocking:
$arg_hash-{Blocking} = 1;
IO::Socket::INET::configure line 149 takes this to mean
if (defined $arg-{Blocking}) {
defined $sock-blocking($arg-{Blocking})
or return _error($sock, $!, $!);
}
Unfortunately, Net::HTTPS::blocking does not return a defined value.
Net::HTTP is probably broken here, but I'm giving IO::Socket::SSL the
bug first because setting the socket to blocking in
IO::Socket::SSL::configure appears to be new behavior. You can reassign
to libwww-perl if you'd like.
Oh, there is an additional twist: IO::Socket::SSL must be loaded before
Net::HTTPS, or the latter will prefer to use Net::SSL instead.
I am using libwww-perl (Net::HTTPS) 5.805-1 and perl-base
(IO::Socket::INET) 5.8.8-6.1. I have upgraded many packages since my
program was known to work. I believe it was working with perl-base
5.8.8-6, libio-socket-ssl-perl 0.97-2, and the same libwww-perl. It
looks like the relevant code in IO::Socket::INET did not change.
However, the blocking setting was not in IO::Socket::SSL 0.97-2.
Oh dear, I just discovered that further complications arise from the
same problem. In IO::Socket::SSL::write, the call to $self-blocking
goes very wrong, because it is made in list context and
Net::HTTPS::blocking returns an empty list. Well, after making
Net::HTTPS::blocking return 0, my program is working again. But it's
not clear that this is a complete solution.
Andrew
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libio-socket-ssl-perl depends on:
ii libnet-ssleay-perl1.30-1 Perl module for Secure Sockets Lay
ii netbase 4.25 Basic TCP/IP networking system
ii perl 5.8.8-6.1 Larry Wall's Practical Extraction
libio-socket-ssl-perl recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366184: libghc6-c2hs-dev: should pre-depend on ghc6
Forgive my delay On Fri, Jun 23, 2006 at 08:29:17PM +0200, Arjan Oosting wrote: This does not seem to be a bug in libghc6-c2hs-dev. When the postinst script of libghc6-c2hs-dev is called, all the Depends should already be configured and ghc-pkg should be available. I looked more closely at the logs I have. (I don't have the screen output, but thankfully there is now dpkg.log.) Actually, even my initial bug report had a clue I missed. It is not the postinst of libghc6-c2hs-dev that failed, it is the prerm. Here are the relevant excerpts of dpkg.log: 2006-05-05 14:51:42 upgrade ghc6 6.4.1-2 6.4.1-2.1 2006-05-05 14:51:42 status half-configured ghc6 6.4.1-2 2006-05-05 14:51:44 status unpacked ghc6 6.4.1-2 2006-05-05 14:51:44 status half-installed ghc6 6.4.1-2 2006-05-05 14:51:46 status half-installed ghc6 6.4.1-2 2006-05-05 14:51:48 status unpacked ghc6 6.4.1-2.1 2006-05-05 14:51:48 status unpacked ghc6 6.4.1-2.1 ... 2006-05-05 14:52:17 upgrade libghc6-c2hs-dev 0.13.6-4 0.13.6-4.1 2006-05-05 14:52:17 status half-configured libghc6-c2hs-dev 0.13.6-4 ... 2006-05-05 14:54:48 status unpacked ghc6 6.4.1-2.1 2006-05-05 14:54:48 status half-configured ghc6 6.4.1-2.1 2006-05-05 14:54:49 status installed ghc6 6.4.1-2.1 So the sequence was - ghc6.prerm, removing the ghc-pkg alternative. - unpack the new ghc6 - libghc6-c2hs-dev.prerm, failing to ghc-pkg unregister - ghc6.postinst, reinstalling the ghc-pkg alternative There were a few related packages involved, c2hs, ghc6-prof, ghc6-libsrc, but I don't think they matter. You probably encountered some circular dependency during your upgrade which was broken somewhere by apt and caused this. Maybe you have more information about the upgrade, so we can reassign the bug to the right package? Otherwise I will close the bug. I will append the aptitude log for this run so you can inspect the full graph. I don't know off hand how to tell if there was a circular dependency, but I don't think there was one involving ghc and c2hs. Andrew Aptitude 0.4.1: log report Fri, May 5 2006 14:49:36 -0700 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 230 packages, and remove 0 packages. 858kB of disk space will be used === [INSTALL, DEPENDENCIES] gcj-4.1-base [INSTALL, DEPENDENCIES] libdevmapper1.02 [INSTALL, DEPENDENCIES] liblzo-dev [INSTALL, DEPENDENCIES] libvolume-id0 [INSTALL, DEPENDENCIES] postgresql-client-common [INSTALL, DEPENDENCIES] python-minimal [INSTALL] gnutls-bin [INSTALL] libatk1.0-data [INSTALL] libpaper-utils [INSTALL] libsasl2-modules [INSTALL] python2.3-iconvcodec [INSTALL] xorg [UPGRADE] alsa-base 1.0.10-3 - 1.0.11-1 [UPGRADE] alsa-utils 1.0.10-1 - 1.0.11-2 [UPGRADE] autoconf 2.59a-8 - 2.59a-9 [UPGRADE] base-files 3.1.11 - 3.1.12 [UPGRADE] bash 3.1-3 - 3.1-4 [UPGRADE] bash-doc 3.1-3 - 3.1-4 [UPGRADE] bin86 0.16.14-1.2 - 0.16.14-1.3 [UPGRADE] c2hs 0.13.6-4 - 0.13.6-4.1 [UPGRADE] console-common 0.7.55.1 - 0.7.58 [UPGRADE] console-data 20060311 - 20060421 [UPGRADE] console-tools 1:0.2.3dbs-60 - 1:0.2.3dbs-62 [UPGRADE] cpp-3.3 1:3.3.6-12 - 1:3.3.6-13 [UPGRADE] cron 3.0pl1-93 - 3.0pl1-94 [UPGRADE] darcs 1.0.5-3 - 1.0.6-1 [UPGRADE] dbus 0.61-4 - 0.61-5 [UPGRADE] dctrl-tools 2.7 - 2.9.0 [UPGRADE] debconf-utils 1.4.71 - 1.5.0 [UPGRADE] debhelper 5.0.24 - 5.0.34 [UPGRADE] dhcp3-client 3.0.3-7 - 3.0.3-8 [UPGRADE] dhcp3-common 3.0.3-7 - 3.0.3-8 [UPGRADE] dia 0.94.0-17.1 - 0.95.0-2 [UPGRADE] dia-common 0.94.0-17.1 - 0.95.0-2 [UPGRADE] dia-libs 0.94.0-17.1 - 0.95.0-2 [UPGRADE] dmidecode 2.8-1 - 2.8-2 [UPGRADE] doc-debian 3.1.2 - 3.1.3 [UPGRADE] docbook-dsssl 1.79-3 - 1.79-4 [UPGRADE] dpatch 2.0.18 - 2.0.19 [UPGRADE] dpkg 1.13.16 - 1.13.18 [UPGRADE] dpkg-dev 1.13.16 - 1.13.18 [UPGRADE] e2fslibs 1.38+1.39-WIP-2005.12.31-1 - 1.38+1.39-WIP-2006.04.09-1 [UPGRADE] e2fsprogs 1.38+1.39-WIP-2005.12.31-1 - 1.38+1.39-WIP-2006.04.09-1 [UPGRADE] exim4-base 4.60-4 - 4.62-1 [UPGRADE] exim4-config 4.60-4 - 4.62-1 [UPGRADE] exim4-daemon-light 4.60-4 - 4.62-1 [UPGRADE] exuberant-ctags 1:5.5.4-1 - 1:5.5.4-2 [UPGRADE] fakeroot 1.5.7 - 1.5.8 [UPGRADE] fastjar 1:4.0.3-1 - 1:4.1.0-2 [UPGRADE] fetchmail 6.3.2-3 - 6.3.4-1 [UPGRADE] file 4.15-2 - 4.17-1 [UPGRADE] findutils 4.2.27-1 - 4.2.27-2 [UPGRADE] firefox 1.5.dfsg+1.5.0.1-4 - 1.5.dfsg+1.5.0.2-3 [UPGRADE] flex 2.5.33-2 - 2.5.33-3 [UPGRADE] foomatic-db 20060113-1 - 20060408-1 [UPGRADE] foomatic-db-engine 3.0.2-20060113-1 - 3.0.2-20060318-1 [UPGRADE] foomatic-filters 3.0.2-20060113-1 - 3.0.2-20060318-2 [UPGRADE] g++ 4:4.0.2-2 - 4:4.0.3-3 [UPGRADE] g++-3.3 1:3.3.6-12 - 1:3.3.6-13 [UPGRADE] gaim 1:1.5.0+1.5.1cvs20051015-2 - 1:1.5.0+1.5.1cvs20051015-3 [UPGRADE] gaim-data 1:1.5.0+1.5.1cvs20051015-2 - 1:1.5.0+1.5.1cvs20051015-3 [UPGRADE] gcc 4:4.0.2-2 - 4:4.0.3-3 [UPGRADE] gcc-3.3 1:3.3.6-12 - 1:3.3.6-13 [UPGRADE] gcc-3.3-base 1:3.3.6-12 - 1:3.3.6-13 [UPGRADE] gcj 4:4.0.2-2 -
Bug#366184: libghc6-c2hs-dev: should pre-depend on ghc6
I can reproduce this problem. I used packages from snapshot.debian.net: http://snapshot.debian.net/archive/2006/03/27/debian/pool/main/g/ghc6/ghc6_6.4.1-2_i386.deb http://snapshot.debian.net/archive/2006/03/27/debian/pool/main/g/ghc6/ghc6_6.4.1-2.1_i386.deb http://snapshot.debian.net/archive/2006/04/17/debian/pool/main/c/c2hs/libghc6-c2hs-dev_0.13.6-4_i386.deb http://snapshot.debian.net/archive/2006/04/17/debian/pool/main/c/c2hs/libghc6-c2hs-dev_0.13.6-4.1_i386.deb The first step is downgrading to ghc6_6.4.1-2 and libghc6-c2hs-dev_0.13.6-4. The latter seems quite broken; I had to create a symlink ln -s /usr/lib/libghc6-c2hs-dev /usr/lib/c2hs-0.13.6 to convince it to install. I also got a warning from ghc-pkg (can't find GHCi lib c2hs.o), but it doesn't seem relevant. Anyhow, once I had those two versions installed, I tried to upgrade: # dpkg --install ghc6_6.4.1-2.1_i386.deb libghc6-c2hs-dev_0.13.6-4.1_i386.deb (Reading database ... 102699 files and directories currently installed.) Preparing to replace ghc6 6.4.1-2 (using ghc6_6.4.1-2.1_i386.deb) ... Unpacking replacement ghc6 ... Preparing to replace libghc6-c2hs-dev 0.13.6-4 (using libghc6-c2hs-dev_0.13.6-4.1_i386.deb) ... /var/lib/dpkg/info/libghc6-c2hs-dev.prerm: line 22: ghc-pkg: command not found dpkg: warning - old pre-removal script returned error exit status 127 dpkg - trying script from the new package instead ... /var/lib/dpkg/tmp.ci/prerm: line 25: ghc-pkg: command not found dpkg: error processing libghc6-c2hs-dev_0.13.6-4.1_i386.deb (--install): subprocess new pre-removal script returned error exit status 127 /var/lib/dpkg/info/libghc6-c2hs-dev.postinst: line 26: ghc-pkg: command not found dpkg: error while cleaning up: subprocess post-installation script returned error exit status 127 Setting up ghc6 (6.4.1-2.1) ... Errors were encountered while processing: libghc6-c2hs-dev_0.13.6-4.1_i386.deb dpkg.log: 2006-07-04 12:54:10 upgrade ghc6 6.4.1-2 6.4.1-2.1 2006-07-04 12:54:10 status half-configured ghc6 6.4.1-2 2006-07-04 12:54:11 status unpacked ghc6 6.4.1-2 2006-07-04 12:54:11 status half-installed ghc6 6.4.1-2 2006-07-04 12:54:14 status half-installed ghc6 6.4.1-2 2006-07-04 12:54:16 status unpacked ghc6 6.4.1-2.1 2006-07-04 12:54:16 status unpacked ghc6 6.4.1-2.1 2006-07-04 12:54:16 upgrade libghc6-c2hs-dev 0.13.6-4 0.13.6-4.1 2006-07-04 12:54:16 status half-configured libghc6-c2hs-dev 0.13.6-4 2006-07-04 12:54:16 status unpacked ghc6 6.4.1-2.1 2006-07-04 12:54:16 status half-configured ghc6 6.4.1-2.1 2006-07-04 12:54:17 status installed ghc6 6.4.1-2.1 This shows that dpkg is happy to deconfigure ghc6 (and leave it deconfigured) before deconfiguring libghc6-c2hs-dev. My dpkg is 1.13.21. By the way, if I reverse the order of the packages on the dpkg --install line, it works fine because dpkg deconfigures libghc6-c2hs-dev first. So it is currently a problem for a package to assume that a Depended-upon package will be configured during prerm. I note that the policy excerpt already cited in this bug is ambiguous: The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. Note, however, that the postrm cannot rely on any non-essential packages to be present during the purge phase. It isn't clear whether present means configured. Another excerpt from the same section: A Depends field takes effect _only_ when a package is to be configured. It isn't clear whether configured means (de)configured. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Sun, Jun 25, 2006 at 04:13:20PM +0200, Jonas Meurer wrote: On 21/06/2006 Andrew Pimlott wrote: True, but this can't be configured in crypttab, which makes it effectively unavailable. Moreover, it wouldn't provide much additional safety. Presumably, a hypothetical luksrandom keyword in crypttab would mean: check that it's a luks partition, than re-luksFormat and luksOpen with the same random key. do you see any advantages in providing this? i don't like the idea of invoking luksFormat automatically in any case. No, just thinking out loud. Cool. So you would special case a key of /dev/*random, and perform only those two checks? In other words, would my existing configuration swap/dev/hda2 /dev/urandom swap start working again? That sounds like a nice resolution. that's the plan. Wonderful. Thank you. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Tue, Jun 20, 2006 at 11:28:57PM +0200, Jonas Meurer wrote: On 20/06/2006 Andrew Pimlott wrote: On Tue, Jun 20, 2006 at 10:10:24PM +0200, Jonas Meurer wrote: But as I understand, a randomly keyed partition can't be done with Luks (or can it?). first, LUKS devices with random key are possible, you just need to store the random key after luksFormat, to reuse it for luksOpen. afterwards you can shred/wipe the key. True, but this can't be configured in crypttab, which makes it effectively unavailable. Moreover, it wouldn't provide much additional safety. Presumably, a hypothetical luksrandom keyword in crypttab would mean: check that it's a luks partition, than re-luksFormat and luksOpen with the same random key. The problem is, this would happily trash any normal (non-randomly-keyed) luks partition. So you really want an explicit marker that says I am disposable. However it may still be overkill. I would be happy enough if there were a check for randomly keyed swap partitions that verifies that the source device is 1) not a formatted, unencrypted volume and 2) not Luks. That's still a good measure of safety. yes, that's exactly what i suggested as well. in my opinion, up to now all other proposed checks are compromises which have disadvantages as well. Cool. So you would special case a key of /dev/*random, and perform only those two checks? In other words, would my existing configuration swap/dev/hda2 /dev/urandom swap start working again? That sounds like a nice resolution. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
