Bug#756519: Toggling session with F1 key does not work anymore
Package: slim Version: 1.3.6-3 Severity: normal It seems like toggling the session with F1 does not work anymore - pressing the F1 key yields no reaction at all (no message on the screen, after login the default session is started). The keyboard setup is o.k. (F1 otherwise works normally ;-). Triggering the screenshot_cmd with F11 still works. When I downgrade to version 1.3.4-2 everything works normal again. (All this is on an up-to-date jessie i386 installation; the same also seems to be the case when installing slim_1.3.6-3~bpo70 on wheezy) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754722: Security upgrade causes severe network packet loss
On Sun, 13 Jul 2014 18:06:16 +0100, Ben Hutchings wrote: See https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=44;bug=754173. Thanks - I can confirm that my problem is indeed caused by the same issue and is gone with the kernel you supplied :-) Regards, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754722: Security upgrade causes severe network packet loss
Package: linux-image-3.2.0-4-amd64 Version: 3.2.60-1+deb7u1 Severity: important After installing security upgrade 3.2.60-1+deb7u1 on my machines, a pool of machines providing virtual desktop to end users turned pretty much unusable. To explain the situation, here's a little picture: /- VM0 /- N0 -/ - VM1 Srv G / \ - ... \ \ -N1... . N0, N1, .. a bunch of diskless machines running virtual machines based on QEMU/KVM; network connectivity for the VMs via bridges G coordinates the pool and connects it to the rest of the network under a single IP address (SNAT) Srv stands for any of a bunch of other servers (mostly Samba) Most machines are running with the 3.2.60-1+deb7u1 kernel without any visible problems, only on the machine named G in my picture, it had devastating effects (for the moment, I downgraded to the previous kernel, 3.2.57-3+deb7u2, with which everything works fine). VMs running Windows XP (unfortunately, this means almost all involved virtual desktops)-: don't have get any useable network connections to the rest of the network anymore. Smaller packets seem to be totally unaffected, but anything involving larger packets is unusable: reading a 50k file from a Samba share takes ~ 1 minute (effects when writing seem to be less extreme). It seems like VMs running Linux are affected, too, but to a much lesser degree. I am no networking expert, but as far as I can figure out from tracing the traffic, there seems to be some problems with fragmentation involved. It seems, that machine G with kernel 3.2.60-1+deb7u1 drops not all, but most packets using the full MTU of 1500 bytes (and sending ICMP messages recommending a MTU of 1500 bytes). I am pretty sure that no bigger packet gets on the wire. The network interfaces use their default settings, which also includes tcp-segmentation-offload, so packets captured on a given machine may bigger, Why the effects on Windows XP are so extreme, while other systems are still working mostly riddles me ... All involved machines run Debian wheezy amd64 (up to date except the kernel on machine G), all have Intel network interfaces using the e1000e driver, usually 2 of them connected via bonding. Almost all network connections involve 802.1q VLAN interfaces. Unfortunately, I can't come up with some easier setup to reproduce the problem. Maybe somebody else hase similar problems, too? I can't experiment too heavily, because the systems are in productive use, but at least 1 thing is clear and 100% reproducible: all my problems are caused by some change between kernel 3.2.57-3+deb7u2 and 3.2.60-1+deb7u1 (and probably not the ptrace bug that was the major reason for the upgrade). I am a little worried that whatever breaks my VDI pool may be included in all future kernel versions ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729480: SSL connections with client certificates no longer working
On 2013-11-13 18:39, Stefan Bühler wrote: I updated our advisory at [...] with the diff from revision 2925: http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2925/diff/ Thanks a lot for the quick reaction! I can confirm that with your patch added to the debian package version 1.4.31-4+deb7u1 my problem is solved! Regards, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729480: SSL connections with client certificates no longer working
Package: lighttpd Version: 1.4.31-4+deb7u1 Severity: important I am running a webserver that only offers https and normally requires client certificates. When I install the security upgrade 1.4.31-4+deb7u1 and restart lighttpd, with some delay (when I keep hitting reload in a client, it works 5-10 times) no more connections with client certificates succeed. Firefox reports connection was interrupted, chrome ERR_SSL_PROTOCOL_ERROR, lighttpd's error log fills with messages saying: (connections.c.305) SSL: 1 error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized regualar https-Connections (w/o client certificate) continue to work. After restarting lighttpd, everything works again for a little while, then trouble starts again. With lighttpd 1.4.31-4 everything works fine; this problem definitely has been introduced with the security patches for 1.4.31-4+deb7u1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696988: live-build 3.x: --chroot-filesystem plain/none ?
Package: live-build
Version: 3.0~a51-1
Severity: normal
I have been using live-build to generate a NFS-root system
to be booted via PXE:
lb config
--architecture i386 \
--linux-flavours 686 \
--distribution wheezy \
--chroot-filesystem plain
--binary-images net \
--net-root-path '/nfsroot/live' --net-root-server '$nfsroot_srv' \
...
On sqeeze, everything works o.k (with minor adjustments).
After moving to a wheezy system, generating the system fails:
No matter what I do, live-build won't install a kernel in the
chroot area. Because various scripts rely on it to be installed
in chroot/boot (first error in lb_binary_linux-image, trying
to copy chroot/boot/vmlinuz-*) the build is aborted.
In the generated binary image (binary/live/filesystem.dir/boot/),
kernel and initrd are correctly installed.
Eventually, I discovered, that the man page for lb_config now
among the possible values for --chroot-filesystem does not mention
plain anymore. Instead, it now mentions a none, which sounds
like it should replace the pvrevious plain.
Unfortunatly, --chroot-filesystem none did not get me any further:
Now the build is aborted in lb_binary_manifest, which tries to copy
chroot.packages.live to binary/${INITFS}/filesystem.${SUFFIX},
i.e. the non-existant directory binary/live.
After looking closer, I am not even sure anymore, whether it
really was intended to replace --chroot-filesystem plain with
--chroot-filesystem plain: At least in lb_binary_rootfs there
are branches for both, plain and none, but with different
actions.
In any case, it looks like for generating nfs-root systems, the
different scripts just don't fit together anymore ...
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages live-build depends on:
ii debootstrap 1.0.44
Versions of packages live-build recommends:
ii cpio2.11-8
ii gnu-fdisk 1.2.4-3.1
ii live-boot-doc 3.0~a35-1
ii live-config-doc 3.0~a43-1
ii live-manual 1:2.0.2-1
ii live-manual-epub [live-manual] 1:3.0~a13-1
ii live-manual-html [live-manual] 1:3.0~a13-1
ii live-manual-odf [live-manual] 1:3.0~a13-1
ii live-manual-pdf [live-manual] 1:3.0~a13-1
ii live-manual-txt [live-manual] 1:3.0~a13-1
Versions of packages live-build suggests:
ii dosfstools 3.0.13-1
ii fakeroot1.18.4-2
ii genisoimage 9:1.1.11-2
ii grub-legacy [grub] 0.97-66
ii memtest86 4.0s-1
ii mtools 4.0.17-1
pn parted none
pn squashfs-tools | mtd-tools none
ii sudo1.8.5p2-1
ii syslinux2:4.05+dfsg-6+deb7u1
pn uuid-runtimenone
pn win32-loadernone
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686776: cdrom image files should be opened read-only
Package: qemu-kvm Version: 1.0+dfsg-11 Severity: important qemu tries to open cdrom images read-write, so loading a cd will only work if the qemu process could write the file. It does not matter, if the readonly flag is set on the command line (I usually use: -drive if=ide,index=2,media=cdrom,readonly). I guess, this is the same issue as discussed here? http://comments.gmane.org/gmane.comp.emulators.qemu/163112 (with -snapshot, a work-around is to add something like file=/some/empty/dummy.iso to the command line.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624754: AF_INET6 sockets even if not specified nor available
Package: libio-socket-inet6-perl Version: 2.65-1 Severity: important Prior versions of IO::Socket::INET6 used domain AF_UNSPEC unless a domain was explicitly provided. This lead many other libraries (e.g. libnet-dns-perl, libio-socket-ssl-perl, probably more) to use IO::Socket::INET6 instead of IO::Socket::INET, assuming they'll get the best of both that way. The Documentation still suggests, that AF_UNSPEC was used as default value for parameter Domain. In current versions this is not true anymore: IO::Socket::INET6:new will now try to create an AF_INET6 socket unless explicitly told otherwise. This behavior also has a certain point to it (the module carries INET6 in it's name) but unfortunately, as a side effect this change breaks all programs that indirectly (via any of the libraries mentioned above) depend on IO::Socket::INET6 and run on a system without ipv6 (new will inevitably fail with Address family not supported by protocol. The simplest way to fix this problem is to just restore the previous default (Domain AF_UNSPEC). Another possibility would be to first try ipv6 but if this fails and ipv6 was not explicitly requested fall back to ipv4 instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613052: hisax: Elsa QuickStep 1000 not working
Package: linux-image-2.6.32-5-amd64 Version: 2.6.32-30 After upgrading to kernel 2.6.32, my ISDN card is not working anymore. It looks like the driver can't get the io ports. The same system with kernel 2.6.26 works alright. lspci says: 06:01.0 Network controller: Elsa AG QuickStep 1000 (rev 02) /proc/ioports: ... d000-dfff : PCI Bus :06 d480-d483 : :06:01.0 d480-d483 : qs1000.1 d800-d87f : :06:01.0 d800-d87f : qs1000.1 ... When I load the driver (options hisax type=18 protocol=2 id=teles0) the following is logged: ... ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2 loaded HiSax: Linux Driver for passive ISDN cards HiSax: Version 3.5 (module) HiSax: Layer1 Revision 2.46.2.5 HiSax: Layer2 Revision 2.30.2.4 HiSax: TeiMgr Revision 2.20.2.3 HiSax: Layer3 Revision 2.22.2.3 HiSax: LinkLayer Revision 2.59.2.4 HiSax: Total 1 card defined HiSax: Card 1 Protocol EDSS1 Id=teles0 (0) HiSax: Elsa driver Rev. 2.32.2.4 Elsa: Microlink PCI defined at 0xd480/0xd800 IRQ 22 HiSax: ELSA config port 0xd480-0xd482 already in use HiSax: Card Elsa PCI not installed ! Here for comparison the same thing with linux-image-2.6.26-2-amd64: ... ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2 loaded HiSax: Linux Driver for passive ISDN cards HiSax: Version 3.5 (module) HiSax: Layer1 Revision 2.46.2.5 HiSax: Layer2 Revision 2.30.2.4 HiSax: TeiMgr Revision 2.20.2.3 HiSax: Layer3 Revision 2.22.2.3 HiSax: LinkLayer Revision 2.59.2.4 HiSax: Total 1 card defined HiSax: Card 1 Protocol EDSS1 Id=teles0 (0) HiSax: Elsa driver Rev. 2.32.2.4 ACPI: PCI Interrupt :06:01.0[A] - GSI 22 (level, low) - IRQ 22 Elsa: Microlink PCI defined at 0xd480/0xd800 IRQ 22 Elsa: IPAC version 2 Elsa PCI: IRQ 22 count 0 Elsa PCI: IRQ 22 count 3 HiSax: DSS1 Rev. 2.32.2.3 HiSax: 2 channels added HiSax: MAX_WAITING_CALLS added -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593087: xinput buttons not recognized correctly
I investigated the issue further and found, that this problem is obviously not restricted to debian, but affecting all recent gtk+ versions, so I also submitted a bug report to the gtk maintainers, see: https://bugzilla.gnome.org/show_bug.cgi?id=627022 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593087: xinput buttons not recognized correctly
Package: libgtk2.0-0 Version: 2.20.1 In recent gtk2 versions, xinput button events (in my case from a wacom tablet, other devices probably as well) do not work correctly any more. Normal GUI usage is ok, only programs that actually handle extended input devices (gimp/inkscape) are affected: Button events on the canvas are only recognized, if 2 buttons are down at the same time. With a 2-button stylus for example, drawing (button 1, normally just by touching the tablet with the stylus) only works, if another button is pressed before the button hits the tablet. The other way around, normally the context menu is accessed by pressing button 3 (the rear of the rocker switch) without touching the tablet; this now only works if I 1st push the stylus on the tablet and then press the button. It is evident, that the problem lies within gtk2; on my base system (libgtk2.0-0 version 2.12.12-1~lenny2) the input buttons work as expected in inkscape and gimp. I 1st ran into this problem after having installed gtk 2.18 from backports.org, after downgrading back to 2.12 things work normal again. The same problem also occurs when running from a freshly installed squeeze in a chroot environment. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573054: packages in config/chroot_local-packages have lowest priority
Package: live-helper Version: 2.0~a8-1 When a package is put into config/chroot_local-packages for installation, but an equivalent package is also available from the default package sources, apt will always install the package from the default source and not the one in config/chroot_local-packages. There already had been a bug report referring to this issue for version live-helper/2.0~a6-1 (bug #569619) which is supposed to be fixed now by putting the local packages into /etc/apt/sources.list.d/local-packages.list. Unfortunately, this change does not resolve the problem, because /etc/apt/sources.list is always given a higher priority than anything in this directory (see also http://article.gmane.org/gmane.linux.debian.devel.live/7489/) I'd suggest to return to the previous solution to put the local packages into /etc/apt/sources.list but put them at the beginning of the file: This way, even if the same package version is available from different sources, apt will always install the package from config/chroot_local-packages -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#479585: (no subject)
There still is a whole bunch of repositories out there that don't
have Contents file, so I also think that some way of suppressing
messages about missing files (and the resulting emails if used in
a cron job) would be good.
Actually, the annoying message is not produced by the programm code,
but by the following line in /etc/apt/apt-file:conf:
error_cmd = ( rm -f cache/dest_tmp; \
echo Can't get uri/dists/dist/Contents-arch.gz )
One way to fix it, would be to change that configuration option to
something like:
error_cmd = ( rm -f cache/dest_tmp; \
[ -n missing_ok ] || \
echo Can't get uri/dists/dist/Contents-arch.gz )
in connection with the patch below.
Maybe some configuration option to selectively suppress the message
only for certain URLs like http://security.debian.org/ in connection
with the --non-interactive option also would make sense? ...
--- /tmp/apt-file 2008-08-23 18:57:55.0 +0200
+++ /usr/bin/apt-file 2009-09-30 10:50:40.0 +0200
@@ -172,8 +172,9 @@
my $cache = $Conf-{cache};
my $arch = $Conf-{arch};
my $cdrom = $Conf-{cdrom_mount};
+my $missing_ok= $Conf-{missing_ok} ? 'missing_ok' : '';
foreach my $var (
-qw/host port user passwd path dist pkg
+qw/host port user passwd path dist pkg missing_ok
cache arch uri cdrom/
)
{
@@ -487,6 +488,7 @@
package-only|l= \$Conf-{package_only},
fixed-string|F= \$Conf-{fixed_strings},
non-interactive|N = \$Conf-{non_interactive},
+missing-ok|q = \$Conf-{missing_ok},
help|h= \$Conf-{help},
version|V = \$Conf-{version},
);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548338: regular syslog messages error writing to client
package: libnss-ldapd version: 0.6.7.1 severity: normal I have several server that get their user base from a ldap directory. Particularly on one of them, I regularly get error messages in the syslog saying error writing to client. Usually, there are short burst of messages (several messages send within the same seconds) about every 10 minutes. I can't discover anything that happens at the same time and might trigger these messages. I searched the bug tracking system and mailing lists and discovered some older issues in connection with very large groups, but this does not seem to be the problem in my case. Actually, as far as I can tell everything works fine otherwise. When I restart nslcd, the messages will go away for some hours or even days. What is the significance of these messages? Are they a sign of some serious problem (in this case a more specific message telling what is going wrong would be great) or are they just debugging messages that can be safely ignored (in which case I'd suggest a lower priority; a more specific message still would be great). Should I be worried? Regards, Peter -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages libnss-ldapd depends on: ii adduser 3.110add and remove users and groups ii debconf [debcon 1.5.24 Debian configuration management sy ii libc6 2.7-18 GNU C Library: Shared libraries ii libkrb531.6.dfsg.4~beta1-5lenny1 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libsasl2-2 2.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra Versions of packages libnss-ldapd recommends: ii libpam-ldap 184-4.2Pluggable Authentication Module fo ii nscd 2.7-18 GNU C Library: Name Service Cache -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529060: Hook scripts (Pre/Post-Invoke ..) should be able to know their context
package: apt severity: wishlist I spent quite some time searching how to find out the package on behalf of which a hook script configured via DPkg::Post-Invoke is being run: I was sure, I must have overlooked something, until I eventually looked into the sources ... Hooks like DPkg::Pre/Post-Invoke could be far more versatile and efficient, if there was a simple way to find out the context they are running in. Currently, there is a separate option DPkg::Pre-Install-Pkgs (without a counterpart like Post-Install-Pkgs, see bug#107151). Imho, the most simple, useful and compatible way would be to just provide a set of environment variables describing the context (package name, action like install/remove, for post-something: status, apt version ...) so external programs being called by apt could find out what they need to know without breaking any established interfaces. I personally was originally looking for a way to always run a script after the kernel has been upgraded, but I could think of many more uses ... Regards, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505204: perlpanel: unhandled exception clicking Configure...
Package: perlpanel Tags: patch *** Failed to open file '': No such file or directory at /usr/share/perlpanel//PerlPanel/Applet/Configurator.pm line 167. ... The corresponding ubuntu packages differs in 1 tiny, but effective detail: diff -ruN debian/DEBIAN/postinst ubuntu/DEBIAN/postinst --- debian/DEBIAN/postinst 2008-04-05 16:28:16.0 +0200 +++ ubuntu/DEBIAN/postinst 2008-05-29 09:17:10.0 +0200 @@ -5,3 +5,8 @@ update-menus fi # End automatically added section +# Automatically added by dh_icons +if which update-icon-caches /dev/null 21 ; then + update-icon-caches /usr/share/icons/Bluecurve /usr/share/icons/crystalsvg /usr/share/icons/hicolor +fi +# End automatically added section -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514234: allow export of local repositories
On Thu, Feb 05, 2009, Eric Cooper wrote: This should already be possible. Note that the syntax for file URLs requires 3 leading slashes (2 for the URL syntax, and 1 for the root of the pathname): Oops -shame on me! I didn't see anything about this scenario in the documentation, so I experimented a little and when I saw the warning about no remote repository in the syslog, I thought, local repositories were not supported. Thanks for your quick reply - it works like a charm :-) Peter Daum -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
