Bug#1083103: apt-cacher-ng: Breaks certificate verification
Package: apt-cacher-ng Version: 3.7.4-1+b2 Severity: important I'm using apt-cacher-ng (running on a different system) with SSL passthrough. It works fine for the official Debian repositories, and for some third-party ones, but fails for other third-party ones: ~# apt update Ign:1 https://deb.torproject.org/torproject.org sid InRelease Ign:2 https://repository.mullvad.net/deb/stable trixie InRelease Hit:3 http://deb.debian.org/debian sid InRelease Hit:4 https://dl.winehq.org/wine-builds/debian bullseye InRelease Hit:5 https://packages.element.io/debian default InRelease Ign:2 https://repository.mullvad.net/deb/stable trixie InRelease Ign:1 https://deb.torproject.org/torproject.org sid InRelease Ign:2 https://repository.mullvad.net/deb/stable trixie InRelease Ign:1 https://deb.torproject.org/torproject.org sid InRelease Err:2 https://repository.mullvad.net/deb/stable trixie InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142] Err:1 https://deb.torproject.org/torproject.org sid InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142] All packages are up to date. Warning: Failed to fetch https://repository.mullvad.net/deb/stable/dists/trixie/InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142] Warning: Failed to fetch https://deb.torproject.org/torproject.org/dists/sid/InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142] Warning: Some index files failed to download. They have been ignored, or old ones used instead. (All repositories work fine with a direct connection, without apt-cacher-ng.) I first encountered this a couple of years ago: https://lists.debian.org/debian-user/2022/05/msg00084.html At the time I thought that it might have had to do with the fact that the Tor site used a CNAME, and was related to this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986356 but now I'm experiencing the same problem with the Mullvad site, which does not use a CNAME. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.10.11-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-cacher-ng depends on: ii adduser 3.137 ii debconf [debconf-2.0] 1.5.87 ii dpkg1.22.11 ii libbz2-1.0 1.0.8-6 ii libc6 2.40-3 pn libcares2 ii libevent-2.1-7t64 2.1.12-stable-10 pn libevent-pthreads-2.1-7t64 pn libfuse2t64 ii libgcc-s1 14.2.0-5 ii liblzma55.6.2-2 ii libssl3t64 3.3.2-1 ii libstdc++6 14.2.0-5 ii libsystemd0 256.6-1 ii libwrap07.6.q-33 ii lsb-base11.6 ii sysvinit-utils [lsb-base] 3.10-2 ii zlib1g 1:1.3.dfsg+really1.3.1-1 Versions of packages apt-cacher-ng recommends: ii ca-certificates 20240203 Versions of packages apt-cacher-ng suggests: ii avahi-daemon 0.8-13+b2 pn doc-base
Bug#1076561: Excessive initramfs size with firmware-nvidia-graphics and plymouth
On Sun, 28 Jul 2024 22:33:21 +0200 Ben Hutchings wrote: > Hello all, > > This issue was fixed by initramfs-tools version 0.143 in experimental. > I have just uploaded version 0.143.1 to unstable, so you should be able > to get the fix through a regular upgrade in a few hours (if using > unstable) or days (if using testing). The fix seems to be working for me as well - thanks so much for your work on this, as well as on Debian in general -- Celejar
Bug#1076561: linux-image-6.9.9-amd64: Kernel 6.9.9 (amd64) results in huge initramfs size
Package: src:linux Version: 6.9.9-1 Severity: normal Hello, I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to running out of space on /boot: * update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 zstd: error 70 : Write error : cannot write block : No space left on device E: mkinitramfs failure zstd -q -9 -T0 70 update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. * It turns out that the initrd for 6.9.9 is more than 7x the size of the one for 6.9.8: * ~$ ls -l /boot/initrd.img* -rw-r--r-- 1 root root 27491557 Jul 8 13:45 /boot/initrd.img-6.9.8-amd64 -rw-r--r-- 1 root root 205739589 Jul 16 14:29 /boot/initrd.img-6.9.9-amd64 * Diffing the two initrd files suggests that the problem stems from the fact that 6.9.9 is including the NVIDIA GPU System Processor (GSP) firmware in the initrd: https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html Arch Linux dealt with this 6 months ago - they claim that the problem actually began in kernel 6.7: https://bbs.archlinux.org/viewtopic.php?id=291900 https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/238 I suggest that we either figure out a mechanism for reducing the size of the initrd, or else document the change, as users with modest /boot partitions will otherwise be in for an unpleasant surprise. Discussion on debian-user: https://lists.debian.org/debian-user/2024/07/msg00614.html -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 20E2CTO1WW product_version: ThinkPad W550s chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N11ET54W (1.30 ) board_vendor: LENOVO board_name: 20E2CTO1WW board_version: SDK0J40705 WIN ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) Subsystem: Lenovo Device [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: bdw_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2225] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09) Subsystem: Lenovo Device [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Device [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI Controller #1 [8086:9cba] (rev 03) Subsystem: Lenovo Device [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) I218-V [8086:15a3] (rev 03) Subsystem: Lenovo Device [17aa:2226] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e Kernel modules: e1000e 00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition Audio Controller [8086:9ca0] (rev 03) Subsystem: Lenovo Device [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root Port #6 [8086:9c9a] (rev e3) (prog-if 00 [Normal decode]) Subsystem: Lenovo Device [17aa:2223] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Steppin
Bug#1065024: rclone: storj backend missing
On Sat, 30 Mar 2024 13:58:31 +0800 Maytham wrote: > Hi, > > > Debian's rclone package is missing the storj backend. I assume that is > > due to this patch: > > > > > https://sources.debian.org/src/rclone/1.60.1+dfsg-3/debian/patches/ignore_tardigrade_backend.patch/ > > > > What is the reason for this? Does it have to do with unpackaged > > dependencies? > > This is because the storj.io/uplink dependency is not available in Debian, as > well as its > dependencies: ... > > Is this documented somewhere? > > Usually the patch should be enough. (IMO this should warrant a NEWS entry.) > > > I assume that this is related to this bug: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983445 > > Several backends have been disabled in rclone due to their dependencies not > being available in > Debian. > > FYI, unless someone backports rclone (or somehow gets it into a Bookworm > point release), then you'll > have to wait until the next release of Debian for any backends to be > reenabled. This is pretty much what I assumed. I do think that this needs to be properly documented in a file included in the package itself. > Kind regards, > Maytham > > > -- Celejar
Bug#1065024: rclone: storj backend missing
Package: rclone Version: 1.60.1+dfsg-2+b5 Severity: normal X-Debbugs-Cc: cele...@gmail.com Debian's rclone package is missing the storj backend. I assume that is due to this patch: https://sources.debian.org/src/rclone/1.60.1+dfsg-3/debian/patches/ignore_tardigrade_backend.patch/ What is the reason for this? Does it have to do with unpackaged dependencies? Is this documented somewhere? I assume that this is related to this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983445 In any event, if Debian is going to be disabling significant parts of upstream functionality, this should be documented somewhere. Thanks for your work on rclone! -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rclone depends on: ii libc6 2.36-9+deb12u4 rclone recommends no packages. Versions of packages rclone suggests: ii fuse 2.9.9-6+b1 -- no debconf information
Bug#1038815: xfce4-settings: Please expose keyboard layout management setting in Settings Manager
Package: xfce4-settings Version: 4.18.2-1 Severity: wishlist Tags: upstream Hello, I've been using Xfce4 for years, with multiple keyboard layouts. Until recently, the layouts were managed globally, across applications; recently, this somehow switched to per application - I don't know why. When I eventually realized what was going on, I looked for a setting that controlled this, and it seems that such a configuration knob is only available via the Properties of the Xfce4 xkb plugin. I suggest that this setting be exposed in the Keyboard section of the Settings Manager. https://askubuntu.com/questions/938103/xubuntu-17-04-different-keyboard-layout-for-each-window -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-settings depends on: ii exo-utils4.18.0-1 ii libatk1.0-0 2.48.3-1 ii libc62.36-9 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libcolord2 1.4.6-2.2 ii libexo-2-0 4.18.0-1 ii libfontconfig1 2.14.1-4 ii libgarcon-1-04.18.1-1 ii libgarcon-common 4.18.1-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libnotify4 0.8.2-1 ii libpango-1.0-0 1.50.14+ds-1 ii libpangocairo-1.0-0 1.50.14+ds-1 ii libupower-glib3 0.99.20-2 ii libx11-6 2:1.8.6-1 ii libxcursor1 1:1.2.1-1 ii libxfce4ui-2-0 4.18.4-1 ii libxfce4util74.18.1-2 ii libxfconf-0-34.18.1-1 ii libxi6 2:1.8-1+b1 ii libxklavier165.4-4 ii libxrandr2 2:1.5.2-2+b1 ii xfce4-helpers4.18.2-1 ii xfconf 4.18.1-1 Versions of packages xfce4-settings recommends: ii colord 1.4.6-2.2 ii x11-utils 7.7+5 ii xiccd 0.3.0-2 xfce4-settings suggests no packages. -- no debconf information
Bug#1036956: xscreensaver: U2F instructions should be clearer
Package: xscreensaver Version: 6.06+dfsg1-3 Severity: minor Hello, I have configured xscreensaver to unlock via U2F (a hardware Yubico device, in my case), as per the attached /etc/pam.d/xscreensaver file. When unlocking, xscreensaver displays the message "Please touch the device." along with two buttons, "New Login" and "OK." For unlocking to work, the "OK" button must be pressed *first*, and only *afterward* does touching the device work. I think the message should more clearly indicate this sequence - the current message implies that touching the device immediately will work. -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.65.2 ii libatk1.0-0 2.46.0-5 ii libc62.36-9 ii libcrypt11:4.4.33-2 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libpam0g 1.5.2-6 ii libsystemd0 252.6-1 ii libx11-6 2:1.8.4-2 ii libxext6 2:1.3.4-1+b1 ii libxft2 2.3.6-1 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxml2 2.9.14+dfsg-1.2 ii libxrandr2 2:1.5.2-2+b1 ii libxt6 1:1.2.1-1.1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data6.06+dfsg1-3 Versions of packages xscreensaver recommends: ii fonts-urw-base35 20200910-7 ii libjpeg-turbo-progs 1:2.1.5-2 ii perl 5.36.0-7 ii wamerican [wordlist] 2020.12.07-2 Versions of packages xscreensaver suggests: ii chromium [www-browser] 113.0.5672.126-1 ii firefox [www-browser]113.0.2-1 pn fortune pn gdm3 | kdm-gdmcompat ii lynx [www-browser] 2.9.0dev.12-1 pn qcam | streamer pn xdaliclock pn xfishtank pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- Configuration Files: /etc/pam.d/xscreensaver changed: auth sufficient pam_u2f.so cue debug @include common-auth @include common-account -- no debconf information
Bug#1036768: gxkb: shows question mark instead of flag
Package: gxkb Version: 0.9.3-1 Severity: normal The applet functions correctly, but when I switch from my default 'us,dvorak' layout to my alternate 'il' one, a question mark is displayed instead of the appropriate flag. My /etc/defaults/keyboard contains: XKBMODEL="pc105" XKBLAYOUT="us,il" XKBVARIANT="dvorak," XKBOPTIONS="terminal:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps" -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gxkb depends on: ii libayatana-appindicator3-1 0.5.92-1 ii libc6 2.36-9 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-02.74.6-2 ii libgtk-3-0 3.24.37-2 ii libwnck-3-0 43.0-3 ii libxklavier16 5.4-4 gxkb recommends no packages. gxkb suggests no packages. -- no debconf information
Bug#1036222: extrepo-offline-data: Element GPG key is expired
Package: extrepo-offline-data Version: 1.0.3 Severity: normal When extrepo's element repo is enabled, 'apt update' throws the following error: ~# apt update ... Err:3 https://packages.element.io/debian bullseye InRelease The following signatures were invalid: EXPKEYSIG C2850B265AC085BD riot.im packages Reading package lists... Done W: GPG error: https://packages.element.io/debian bullseye InRelease: The following signatures were invalid: EXPKEYSIG C2850B265AC085BD riot.im packages E: The repository 'https://packages.riot.im/debian bullseye InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. See here: https://github.com/vector-im/element-desktop/issues/807 Following upstream's directions to add the key and repo manually works fine: https://element.io/download#linux Cf.: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030956 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1014782: The problem remains
On Mon, 20 Feb 2023 16:58:37 -0800 Jamie Zawinski wrote: > If blanking is being inhibited by dbus, the verbose log will look like this: > > xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" (:1.48) with > "video-playing" cookie "0C765C49" > xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" since Mon Feb 20 > 16:54:30 2023 > xscreensaver-systemd: 16:54:30: exec: xscreensaver-command --verbose > -deactivate > xscreensaver: 16:54:30: ClientMessage DEACTIVATE: already inactive, resetting > activity time > xscreensaver-command: already inactive, resetting activity time > xscreensaver-systemd: 16:54:32: uninhibited by "firefox-esr" (:1.48) with > "video-playing" cookie "0C765C49" > > If blanking is being inhibited directly, you'll see only the "deactivate" > line. The DEACTIVATE events I found, that are apparently sent by the Xfce Power Manager, are not preceeded by xscreensaver-systemd lines, although other DEACTIVATE lines are, e.g. "inhibited by "chromium"". So apparently the systemd integration is working, but Xfce isn't using it? -- Celejar
Bug#1014782: The problem remains
On Mon, 20 Feb 2023 11:13:58 -0800 Jamie Zawinski wrote: > On Feb 20, 2023, at 9:44 AM, Celejar wrote: > > > > It turns out that the DEACTIVATEs were being sent by the Xfce Power > > Manager's Presentation Mode. I'm not sure I was even aware of that > > mode's existence, but it apparently has a long history of becoming > > turned on without the conscious intention or awareness of the user :) > > Good to know! > > So, it sounds like you were seeing XFCE invoking "xscreensaver-command > -deactivate" directly, is that right? That would have been happening here: > > https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L122 > > However it looks like that's a fallback, and first it would have tried to > connect to DBus, meaning you should have seen diagnostics from > xscreensaver-systemd instead: > > https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L233 > > Is xscreensaver-systemd not running for you? It's running: ~$ ps ax | grep xscree 145156 pts/6S 0:35 xscreensaver -v -v -v --log /home/username/xsvr-log 145158 pts/6S 0:00 xscreensaver-systemd --verbose 242602 pts/6S+ 0:00 grep xscree I don't know whether I'm seeing "xscreensaver-command -deactivate" or xscreensaver-systemd diagnostics. Where should I look for these? The xscreensaver log just contains lines of the form: xscreensaver: nn:nn:nn: ClientMessage DEACTIVATE: already inactive, resetting activity time I don't see any mentions of "xscreensaver-command -deactivate" or systemd. Should I be looking somewhere else? Thanks for the help, and thanks for your work on xscreensaver! -- Celejar
Bug#1014782: The problem remains
On Sun, 19 Feb 2023 10:21:48 +0100 Tormod Volden wrote: > On Fri, Feb 17, 2023 at 5:48 PM Celejar wrote: > > Sorry - I just saw this. I'm currently on 6.06 (Sid package). The > > "Preview" button is currently working, but the screensaver isn't > > activating on its own. I started it with logging enabled, and I see > > regular deactivate events like the following logged every 20 seconds: > > > > ClientMessage DEACTIVATE: already inactive, resetting activity time > > > > I saw this: > > > > https://www.jwz.org/xscreensaver/faq.html#no-blank > > > > I guess I have to figure out what application is sending these messages? > > Firefox? I do tend to keep a lot of tabs open. > > Yes, try freezing Firefox and see if those DEACTIVATEs stop. I use It turns out that the DEACTIVATEs were being sent by the Xfce Power Manager's Presentation Mode. I'm not sure I was even aware of that mode's existence, but it apparently has a long history of becoming turned on without the conscious intention or awareness of the user :) https://bugzilla.xfce.org/show_bug.cgi?id=14210 > this script when I need to save laptop battery, it might come handy > here: ... Thank you! > BTW, if you keep many tabs open, I can recommend the Auto Tab Discard > extension! Thanks - I think I've tried it in the past, but I don't currently have it installed. Perhaps I'll give it another try. Thanks again for the help. -- Celejar
Bug#1014782: The problem remains
On Fri, 27 Jan 2023 22:40:17 +0100 Tormod Volden wrote: > OK. Maybe you can try 6.06, it is in salsa but is awaiting sponsoring > and uploading. In any case, please attach the verbose log from > xscreensaver -v -v -v -log your.log > > I am not able to reproduce the issue. > > Tormod Sorry - I just saw this. I'm currently on 6.06 (Sid package). The "Preview" button is currently working, but the screensaver isn't activating on its own. I started it with logging enabled, and I see regular deactivate events like the following logged every 20 seconds: ClientMessage DEACTIVATE: already inactive, resetting activity time I saw this: https://www.jwz.org/xscreensaver/faq.html#no-blank I guess I have to figure out what application is sending these messages? Firefox? I do tend to keep a lot of tabs open. If you think the log may contain more useful information, I'm happy to attach it. -- Celejar
Bug#1014782: The problem remains
Hello, Just for the record, I want to report that I'm still experiencing the problem I reported in my original report. My /usr/lib/X11 is empty. -- Celejar
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
On Mon, 11 Jul 2022 09:53:50 +0200 Christopher Schramm wrote: > Alright, so... > > according to your first test and as expected a notification daemon does > not seem to be available. According to your report, you do have > notification-daemon installed, so running > /usr/lib/notification-daemon/notification-daemon in your desktop session > should solve that. Desktop environments often include a specific daemon. > notification-daemon is Gnome's. Plasma, Xfce, LxQt, MATE, Cinnamon etc. > have their own and the respective packages all provide > notification-daemon, see > https://packages.debian.org/bookworm/notification-daemon. A common > choice by folks on i3 and similar is dunst. Thanks for the explanation - I'm using Xfce4, so I guess I'd want xfce4-notifyd > As no notification daemon seems to be running, blueman uses its fallback > and shows a GTK MessageDialog. Just like any GTK window, they should get > decorated by the window manager by default. A simple test in Python (run > with python3 -c as before or just in the interactive interpreter), > independent of blueman: > > from gi.repository import Gtk > Gtk.MessageDialog().show() > Gtk.main() No decorations. > Boiled down to a GTK Window (MessageDialog is a special case of a Window): > > from gi.repository import Gtk > Gtk.Window().show() > Gtk.main() Decorations. > Both should show decorations, as that's the default > (https://docs.gtk.org/gtk3/method.Window.set_decorated.html). I can > force missing decoration with: > > from gi.repository import Gtk > Gtk.Window(decorated=False).show() > Gtk.main() > > Maybe you can make it work with the opposite: > > from gi.repository import Gtk > Gtk.Window(decorated=True).show() > Gtk.main() Still no decorations (with Gtk.MessageDialog(decorated=True).show() followed by Gtk.main()) > That's totally unexpected, though, and you seem to have a more generic > issue between GTK and your window manager, unrelated to blueman. Okay, so this is probably some sort of GTK / Xfce4 problem? Should I report it against some other package (which?), or reassign this report? -- Celejar
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Package: xscreensaver
Version: 6.02+dfsg1-2
Severity: important
I have been using xscreensaver for years. Recently (a few weeks or
months ago), it has stopped activating when the "Preview" button is
clicked and (rather more importantly) as per the delay specified via the
"Blank after" setting. It still activates fine via command line
invocation ("xscreensaver-command -activate"), and when the system goes to
sleep (hibernate).
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xscreensaver depends on:
ii init-system-helpers 1.64
ii libatk1.0-0 2.38.0-1
ii libc62.33-7
ii libcrypt11:4.4.28-1
ii libglib2.0-0 2.72.3-1
ii libgtk2.0-0 2.24.33-2
ii libpam0g 1.4.0-13
ii libpango-1.0-0 1.50.7+ds-1
ii libsystemd0 251.2-8
ii libx11-6 2:1.7.5-1
ii libxext6 2:1.3.4-1
ii libxft2 2.3.4-1
ii libxi6 2:1.8-1
ii libxinerama1 2:1.1.4-3
ii libxml2 2.9.14+dfsg-1
ii libxrandr2 2:1.5.2-2+b1
ii libxt6 1:1.2.1-1
ii libxxf86vm1 1:1.1.4-1+b2
ii xscreensaver-data6.02+dfsg1-2
Versions of packages xscreensaver recommends:
ii gsfonts-x11 0.28
ii libjpeg-turbo-progs 1:2.1.2-1
ii perl 5.34.0-5
ii wamerican [wordlist] 2020.12.07-2
Versions of packages xscreensaver suggests:
ii chromium [www-browser] 103.0.5060.53-1
ii firefox [www-browser]102.0-1
pn fortune
pn gdm3 | kdm-gdmcompat
ii lynx [www-browser] 2.9.0dev.10-1
pn qcam | streamer
pn xdaliclock
pn xfishtank
pn xscreensaver-data-extra
pn xscreensaver-gl
pn xscreensaver-gl-extra
-- Configuration Files:
/etc/pam.d/xscreensaver changed:
auth sufficient pam_u2f.so cue debug
@include common-auth
@include common-account
-- no debconf information
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
On Wed, 6 Jul 2022 23:44:21 +0200
Christopher Schramm wrote:
> > Shouldn't
> > there be some sort of "Okay" button, or some window decoration that
> > allows them to be closed?
>
> Yes, window decorations are expected if those are the fallback windows.
> They are GTK MessageDialogs which by default shall get decorated by the
> window manager.
>
> Another possibility would be that what you see is generated by some kind
> of notification daemon.
>
> You can test both facilities to check:
>
> Standard notification (default):
>
> python3 -c 'from blueman.gui.Notification import _NotificationBubble as
> Notification; Notification("Test", "Test").show()'
~$ python3 -c 'from blueman.gui.Notification import _NotificationBubble as
Notification; Notification("Test", "Test").show()'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/blueman/gui/Notification.py", line 193,
in __init__
self._capabilities = self.GetCapabilities()
File "/usr/lib/python3/dist-packages/gi/overrides/Gio.py", line 349, in
__call__
result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.GError: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Notifications was not provided by any .service files (2)
(No window appears.}
> Dialog (fallback):
>
> python3 -c 'from blueman.gui.Notification import _NotificationDialog as
> Notification; Notification("Test", "Test").show(); from gi.repository
> import GLib; GLib.MainLoop().run()'
~$ python3 -c 'from blueman.gui.Notification import _NotificationDialog as
Notification; Notification("Test", "Test").show(); from gi.repository import
GLib; GLib.MainLoop().run()'
^CTraceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/gi/overrides/GLib.py", line 495, in run
with register_sigint_fallback(self.quit):
File "/usr/lib/python3.10/contextlib.py", line 142, in __exit__
next(self.gen)
File "/usr/lib/python3/dist-packages/gi/_ossighelper.py", line 237, in
register_sigint_fallback
signal.default_int_handler(signal.SIGINT, None)
KeyboardInterrupt
(Window appears, looking much like the ones I filed this report about -
no decorations or any obvious means of closing.)
I realized, BTW, that the easy way to close these windows is ALT-F4
when they have focus, but I still think they should have some labeled
method of closing / dismissal.
I really don't know much about notification daemons and fallback
windows. What expected pieces are my system missing?
--
Celejar
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
On Mon, 4 Jul 2022 17:18:33 +0200 Christopher Schramm wrote: > Those popup windows are a fallback for when the required > notification-daemon does not work. blueman is intended to be used with a > running notification-daemon. I have no problem with such popups - but they should be *somehow* dismissable! I currently have six of them on my desktop, they have been there for days, and I have no idea how to make them go away! Shouldn't there be some sort of "Okay" button, or some window decoration that allows them to be closed? -- Celejar
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
Package: blueman Version: 2.2.5-1 Severity: normal Blueman leaves stray "Connected" and "Disconnected" popup windows, with no buttons or obvious means of dismissal, on my desktop. I have attached an example. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages blueman depends on: ii adwaita-icon-theme42.0-2 ii bluez 5.64-2 ii bluez-obexd 5.64-2 ii dbus 1.14.0-1 ii dbus-user-session [default-dbus-session-bus] 1.14.0-1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gir1.2-ayatanaappindicator3-0.1 0.5.91-1 ii gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1 ii gir1.2-glib-2.0 1.72.0-1+b1 ii gir1.2-gtk-3.03.24.34-1 ii gir1.2-nm-1.0 1.38.2-1 ii gir1.2-pango-1.0 1.50.7+ds-1 ii libbluetooth3 5.64-2 ii libc6 2.33-7 ii libpulse-mainloop-glib0 15.0+dfsg1-4+b1 ii librsvg2-common 2.54.4+dfsg-1 ii notification-daemon 3.20.0-4+b1 ii policykit-1 0.105-33 ii python3 3.10.4-1+b1 ii python3-cairo 1.20.1-3 ii python3-gi3.42.1-1 ii python3-gi-cairo 3.42.1-1 Versions of packages blueman recommends: ii pulseaudio-module-bluetooth 15.0+dfsg1-4+b1 blueman suggests no packages. -- no debconf information
Bug#1014185: blueman: please add an "Always deny" button to the authentication popup window
Package: blueman Version: 2.2.5-1 Severity: wishlist I have connected a bluetooth headset to my system, to use as an output device. It works, but I keep getting "Authorization request" popup windows from "Bluetooth Authentication" for "Service: Phonebook Access (PBAP) - PSE". My device doesn't need phonebook access, so I keep clicking "Deny," but while that dismisses the popup, it keeps coming back every minutes or two. This is really annoying - it interrupts my workflow, and the popup steals focus suddenly from whatever I'm doing. There is an "Always accept" button, so I suggest the addition of an "Always deny" button. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages blueman depends on: ii adwaita-icon-theme42.0-2 ii bluez 5.64-2 ii bluez-obexd 5.64-2 ii dbus 1.14.0-1 ii dbus-user-session [default-dbus-session-bus] 1.14.0-1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gir1.2-ayatanaappindicator3-0.1 0.5.91-1 ii gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1 ii gir1.2-glib-2.0 1.72.0-1+b1 ii gir1.2-gtk-3.03.24.34-1 ii gir1.2-nm-1.0 1.38.2-1 ii gir1.2-pango-1.0 1.50.7+ds-1 ii libbluetooth3 5.64-2 ii libc6 2.33-7 ii libpulse-mainloop-glib0 15.0+dfsg1-4+b1 ii librsvg2-common 2.54.4+dfsg-1 ii notification-daemon 3.20.0-4+b1 ii policykit-1 0.105-33 ii python3 3.10.4-1+b1 ii python3-cairo 1.20.1-3 ii python3-gi3.42.1-1 ii python3-gi-cairo 3.42.1-1 Versions of packages blueman recommends: ii pulseaudio-module-bluetooth 15.0+dfsg1-4+b1 blueman suggests no packages. -- no debconf information
Bug#1012722: wireguard-tools: wg-quick DNS server setup should remove existing /etc/resolv.conf lines
Package: wireguard-tools Version: 1.0.20210914-1 Severity: normal I use wg-quick to setup a tunnel to my home LAN from various wireless (WiFi) networks that I don't control. My /etc/wireguard/wg0.conf contains the line: DNS = yy.yy.yy.yy where yy.yy.yy.yy is a DNS server on my LAN. With a typical WiFi network, when I initially connect to it, /etc/resolv.conf becomes populated with something like the following: nameserver xx.xx.xx.xx search nnn.nnn.nnn When I then do 'wg-quick' up, resolv.conf ends up like this: nameserver yy.yy.yy.yy nameserver xx.xx.xx.xx search nnn.nnn.nnn So DNS queries will generally go through my designated DNS server, which is good, but if something goes wrong with my server, queries will leak out to the DNS server supplied by the WiFi network, which is not good. Similarly, queries for addresses like 'example.com.nnn.nnn.nnn' sometimes end up going out into the DNS system, which is also not good. I would think that the correct behavior would be for wg-quick to *replace* the existing contents of resolv.conf, rather than just *prepending* the specified DNS server. I understand that as per the man page, I can presumably get this behavior by using the PostUp and PostDown keys, but I think the default should be changed, or at least that users should be warned of the leak potential in the documentation. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireguard-tools depends on: ii libc6 2.33-7 Versions of packages wireguard-tools recommends: ii iptables 1.8.8-1 ii linux-image-amd64 [wireguard-modules] 5.18.2-1 ii nftables 1.0.4-1 Versions of packages wireguard-tools suggests: ii resolvconf 1.91 -- no debconf information
Bug#1011558: extrepo: configuration set to bookworm even when installed on sid
Package: extrepo Version: 0.10 Severity: normal The default /etc/extrepo/config/yaml sets "version: bookworm", even when installed on sid, so newer entries to the repo list aren't available. Setting "version: sid" makes them available - shouldn't this be the default for the sid version of the package? -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages extrepo depends on: ii gpgv 2.2.35-2 ii libcryptx-perl0.076-1+b1 ii libdpkg-perl 1.21.7 ii libwww-perl 6.66-1 ii libyaml-libyaml-perl 0.83+ds-1+b1 ii perl 5.34.0-4 Versions of packages extrepo recommends: ii apt [apt-transport-https] 2.5.0 extrepo suggests no packages. -- Configuration Files: /etc/extrepo/config.yaml changed [not included] -- no debconf information
Bug#1010572: apt-cacher-ng: breaks deb.torproject.org
Package: apt-cacher-ng Version: 3.7.4-1~bpo11+1 Severity: normal X-Debbugs-Cc: cele...@gmail.com The upstream Tor Project repository, https://deb.torproject.org/torproject.org, works when accessed directly, but not when accessed via apt-cacher-ng: Err:1 https://deb.torproject.org/torproject.org sid InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: xx.xx.xx.xx 3142] I don't know if they're doing something wrong, or apt-cacher-ng is. I do not know if this is related to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986356 but other third party repos using HTTPS and CNAMES (e.g., https://download.vscodium.com/debs) seem to work fine. The Tor Project documentation: https://support.torproject.org/apt/tor-deb-repo/ -- Package-specific info: -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-cacher-ng depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.77 ii dpkg 1.20.9 ii libbz2-1.0 1.0.8-4 ii libc-ares2 1.17.1-1+deb11u1 ii libc62.31-13+deb11u3 ii libevent-2.1-7 2.1.12-stable-1 ii libevent-pthreads-2.1-7 2.1.12-stable-1 ii libfuse2 2.9.9-5 ii libgcc-s110.2.1-6 ii liblzma5 5.2.5-2.1~deb11u1 ii libssl1.11.1.1n-0+deb11u1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-7 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-2+deb11u1 Versions of packages apt-cacher-ng recommends: ii ca-certificates 20210119 Versions of packages apt-cacher-ng suggests: ii avahi-daemon 0.8-5 pn doc-base -- Configuration Files: /etc/apt-cacher-ng/acng.conf changed [not included] /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: '/etc/apt-cacher-ng/security.conf' -- debconf information: * apt-cacher-ng/tunnelenable: false apt-cacher-ng/gentargetmode: No automated setup apt-cacher-ng/proxy: keep apt-cacher-ng/port: keep apt-cacher-ng/cachedir: keep apt-cacher-ng/bindaddress: keep
Bug#1010441: upstream reports
https://github.com/micahflee/torbrowser-launcher/pull/599 https://github.com/micahflee/torbrowser-launcher/issues/628 https://github.com/micahflee/torbrowser-launcher/issues/636 -- Celejar
Bug#1006468: cups: misleading documentation regarding root login credentials
Package: cups Version: 2.4.1op1-1 Severity: normal Hello, On a fresh CUPS install, I logged into the web interface as root to add a printer, and was denied with a 401 Forbidden error. The problem seems to be that root is not a member of a group in @SYSTEM (which by default only includes lpadmin). I understand that Debian has decided that this is not a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616718 but Debian's documentation seems quite misleading and inconsistent on this point. README.Debian states: 'Administration' is where you need to be to set up a local print queue. At some point you will be required to authenticate. A User Name of 'root' and root's password is always acceptable. Any other user must be a member of the lpadmin group. This clearly indicates that root does *not* need to be a member of the lpadmin group. OTOH, 'man cupsd.conf' is more accurate: Note: The 'root' user is not special and must be granted privileges like any other user account. I suggest that the language of the README be modified to resemble that of the man page. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.4.1op1-1 ii cups-common2.4.1op1-1 ii cups-core-drivers 2.4.1op1-1 ii cups-daemon2.4.1op1-1 ii cups-filters 1.28.12-1 ii cups-ppdc 2.4.1op1-1 ii cups-server-common 2.4.1op1-1 ii debconf [debconf-2.0] 1.5.79 ii ghostscript9.55.0~dfsg-3 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.33-7 ii libcups2 2.4.1op1-1 ii libgcc-s1 12-20220222-1 ii libstdc++6 12-20220222-1 ii libusb-1.0-0 2:1.0.25-1 ii poppler-utils 20.09.0-3.1 ii procps 2:3.3.17-6 Versions of packages cups recommends: ii avahi-daemon 0.8-5 ii colord1.4.6-1 Versions of packages cups suggests: pn cups-bsd pn cups-pdf pn foomatic-db-compressed-ppds | foomatic-db pn smbclient ii udev 250.3-2 -- debconf information excluded
Bug#1006392: xfce4-session: xflock4 fails if xfce4-screensaver is installed but not running
Package: xfce4-session Version: 4.16.0-1 Severity: normal xflock4 silently fails to lock the screen if xfce4-screensaver is installed but not running. This is due to the fact that (unlike, say, 'xscreensaver-command') 'xfce4-screensaver-command' returns 0 / success even if xfce4-screensaver is not running. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-session depends on: ii libatk1.0-02.36.0-3 ii libc6 2.33-7 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libglib2.0-0 2.70.4-1 ii libgtk-3-0 3.24.31-1 ii libice62:1.0.10-1 ii libpango-1.0-0 1.50.4+ds-1 ii libpolkit-gobject-1-0 0.105-32 ii libsm6 2:1.2.3-1 ii libwnck-3-040.0-2 ii libx11-6 2:1.7.2-2+b1 ii libxfce4ui-2-0 4.16.1-1 ii libxfce4util7 4.16.0-1 ii libxfconf-0-3 4.16.0-2 ii x11-xserver-utils 7.7+9 ii xfce4-settings 4.16.2-1 ii xfconf 4.16.0-2 Versions of packages xfce4-session recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.20-4 ii libpam-systemd [logind] 250.3-2 ii light-locker 1.8.0-3 ii systemd-sysv 250.3-2 ii upower0.99.16-1 ii xfdesktop44.16.0-1 ii xfwm4 4.16.1-1 Versions of packages xfce4-session suggests: pn fortunes-mod pn sudo -- no debconf information
Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start
Thanks for all your work on behalf of Debian. I certainly didn't mean to blame you for the lack of documentation, and I understand that these problems are usually upstream's fault. On Wed, 1 Dec 2021 09:47:37 +0100 Ola Lundqvist wrote: > Hi > > Thank you. > > I guess the main reason for the lack of documentation is that it is not > provided by upstream. This was the case also for tightvnc, vnc4 and vnc(3). > I wrote some documentation for those other packages but I guess it was > never done for tigervnc. > > I do not think you made anything wrong. > > Cheers > > // Ola > > On Wed, 1 Dec 2021 at 00:12, Celejar wrote: > > > Primarily the segfault, although the problem is compounded by the > > absence of documentation, which makes it difficult to know whether I'm > > doing something wrong with my invocation. > > > > On Tue, 30 Nov 2021 23:07:11 +0100 > > Ola Lundqvist wrote: > > > > > Hi > > > > > > Just a check question. Is your bug about the lack of useful documentation > > > or the fact that it segfaults? > > > It should not segfault... > > > > > > // Ola > > > > > > On Tue, 30 Nov 2021 at 15:03, Celejar wrote: > > > > > > > Package: tigervnc-standalone-server > > > > Version: 1.11.0+dfsg-3 > > > > Severity: important > > > > X-Debbugs-Cc: cele...@gmail.com > > > > > > > > This package contains no useful documentation or explanation of how to > > > > start the server in /usr/share/doc. As per 'man tigervncserver', I > > > > tried: > > > > > > > > * > > > > > > > > ~$ tigervncserver > > > > > > > > * > > > > > > > > And the server promptly segfaulted: > > > > > > > > * > > > > > > > > New Xtigervnc server '.:1 ()' on port 5901 for > > > > display :1. > > > > Use xtigervncviewer -SecurityTypes VncAuth -passwd > > > > /home//.vnc/passwd :1 to connect to the VNC server. > > > > > > > > > > > > === tail /home//.vnc/.:5901.log > > > > === > > > > Segmentation fault > > > > X connection to :1 broken (explicit kill or server shutdown). > > > > ComparingUpdateTracker: 0 pixels in / 0 pixels out > > > > ComparingUpdateTracker: (1:-nan ratio) > > > > Killing Xtigervnc process ID 9433... success! > > > > > > > > > > == > > > > > > > > Session startup via '/etc/X11/Xtigervnc-session' 'startxfce4' cleanly > > > > exited too early (< 3 seconds)! > > > > > > > > Maybe try something simple first, e.g., > > > > tigervncserver -xstartup /usr/bin/xterm > > > > The Xtigervnc server cleanly exited! > > > > The X session cleanly exited! > > > > > > > > * > > > > > > > > As per the above output, I tried: > > > > > > > > * > > > > > > > > ~$ tigervncserver -xstartup /usr/bin/xterm > > > > > > > > * > > > > > > > > No segfault, but it still didn't work: > > > > > > > > * > > > > > > > > New Xtigervnc server '.:1 ()' on port 5901 for > > > > display :1. > > > > Use xtigervncviewer -SecurityTypes VncAuth -passwd > > > > /home//.vnc/passwd :1 to connect to the VNC server. > > > > > > > > > > > > === tail /home//.vnc/.:5901.log > > > > === > > > > > > > > > > == > > > > > > > > Session startup via '/usr/bin/xterm' 'startxfce4' cleanly exited too > > early > > > > (< 3 seconds)! > > > > > > > > Maybe try something simple first, e.g., > > > > tigervncserver -xstartup /usr/bin/xterm > > > > The X session cleanly exited! > > > > Killing Xtigervnc process ID 9525... success! > > > > > > > > * > > > > > >
Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start
Primarily the segfault, although the problem is compounded by the absence of documentation, which makes it difficult to know whether I'm doing something wrong with my invocation. On Tue, 30 Nov 2021 23:07:11 +0100 Ola Lundqvist wrote: > Hi > > Just a check question. Is your bug about the lack of useful documentation > or the fact that it segfaults? > It should not segfault... > > // Ola > > On Tue, 30 Nov 2021 at 15:03, Celejar wrote: > > > Package: tigervnc-standalone-server > > Version: 1.11.0+dfsg-3 > > Severity: important > > X-Debbugs-Cc: cele...@gmail.com > > > > This package contains no useful documentation or explanation of how to > > start the server in /usr/share/doc. As per 'man tigervncserver', I > > tried: > > > > * > > > > ~$ tigervncserver > > > > * > > > > And the server promptly segfaulted: > > > > * > > > > New Xtigervnc server '.:1 ()' on port 5901 for > > display :1. > > Use xtigervncviewer -SecurityTypes VncAuth -passwd > > /home//.vnc/passwd :1 to connect to the VNC server. > > > > > > === tail /home//.vnc/.:5901.log > > === > > Segmentation fault > > X connection to :1 broken (explicit kill or server shutdown). > > ComparingUpdateTracker: 0 pixels in / 0 pixels out > > ComparingUpdateTracker: (1:-nan ratio) > > Killing Xtigervnc process ID 9433... success! > > > > == > > > > Session startup via '/etc/X11/Xtigervnc-session' 'startxfce4' cleanly > > exited too early (< 3 seconds)! > > > > Maybe try something simple first, e.g., > > tigervncserver -xstartup /usr/bin/xterm > > The Xtigervnc server cleanly exited! > > The X session cleanly exited! > > > > * > > > > As per the above output, I tried: > > > > * > > > > ~$ tigervncserver -xstartup /usr/bin/xterm > > > > * > > > > No segfault, but it still didn't work: > > > > * > > > > New Xtigervnc server '.:1 ()' on port 5901 for > > display :1. > > Use xtigervncviewer -SecurityTypes VncAuth -passwd > > /home//.vnc/passwd :1 to connect to the VNC server. > > > > > > === tail /home//.vnc/.:5901.log > > === > > > > == > > > > Session startup via '/usr/bin/xterm' 'startxfce4' cleanly exited too early > > (< 3 seconds)! > > > > Maybe try something simple first, e.g., > > tigervncserver -xstartup /usr/bin/xterm > > The X session cleanly exited! > > Killing Xtigervnc process ID 9525... success! > > > > * > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers unstable > > APT policy: (500, 'unstable') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE > > not set > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages tigervnc-standalone-server depends on: > > ii libaudit1 1:3.0.6-1+b1 > > ii libbsd0 0.11.3-1 > > ii libc6 2.32-4 > > ii libfile-readbackwards-perl 1.06-1 > > ii libgcrypt20 1.9.4-4 > > ii libgl1 1.3.4-2+b1 > > ii libgnutls30 3.7.2-2 > > ii libjpeg62-turbo 1:2.1.2-1 > > ii libpam0g1.4.0-10 > > ii libpixman-1-0 0.40.0-1 > > ii libselinux1 3.3-1+b1 > > ii libstdc++6 11.2.0-12 > > ii libsystemd0 249.7-1 > > ii libunwind8 1.3.2-2 > > ii libxau6 1:1.0.9-1 > > ii libxdmcp6 1:1.1.2-3 > > ii libxfont2 1:2.0.5-1 > > ii perl5.32.1-6 > > ii tigervnc-common 1.11.0+dfsg-3 > > ii x11-xkb-utils 7.7+5 > > ii xauth 1:1.
Bug#1000871: tigervnc-standalone-server: server fails to start
Package: tigervnc-standalone-server Version: 1.11.0+dfsg-3 Severity: important X-Debbugs-Cc: cele...@gmail.com This package contains no useful documentation or explanation of how to start the server in /usr/share/doc. As per 'man tigervncserver', I tried: * ~$ tigervncserver * And the server promptly segfaulted: * New Xtigervnc server '.:1 ()' on port 5901 for display :1. Use xtigervncviewer -SecurityTypes VncAuth -passwd /home//.vnc/passwd :1 to connect to the VNC server. === tail /home//.vnc/.:5901.log === Segmentation fault X connection to :1 broken (explicit kill or server shutdown). ComparingUpdateTracker: 0 pixels in / 0 pixels out ComparingUpdateTracker: (1:-nan ratio) Killing Xtigervnc process ID 9433... success! == Session startup via '/etc/X11/Xtigervnc-session' 'startxfce4' cleanly exited too early (< 3 seconds)! Maybe try something simple first, e.g., tigervncserver -xstartup /usr/bin/xterm The Xtigervnc server cleanly exited! The X session cleanly exited! * As per the above output, I tried: * ~$ tigervncserver -xstartup /usr/bin/xterm * No segfault, but it still didn't work: * New Xtigervnc server '.:1 ()' on port 5901 for display :1. Use xtigervncviewer -SecurityTypes VncAuth -passwd /home//.vnc/passwd :1 to connect to the VNC server. === tail /home//.vnc/.:5901.log === == Session startup via '/usr/bin/xterm' 'startxfce4' cleanly exited too early (< 3 seconds)! Maybe try something simple first, e.g., tigervncserver -xstartup /usr/bin/xterm The X session cleanly exited! Killing Xtigervnc process ID 9525... success! * -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tigervnc-standalone-server depends on: ii libaudit1 1:3.0.6-1+b1 ii libbsd0 0.11.3-1 ii libc6 2.32-4 ii libfile-readbackwards-perl 1.06-1 ii libgcrypt20 1.9.4-4 ii libgl1 1.3.4-2+b1 ii libgnutls30 3.7.2-2 ii libjpeg62-turbo 1:2.1.2-1 ii libpam0g1.4.0-10 ii libpixman-1-0 0.40.0-1 ii libselinux1 3.3-1+b1 ii libstdc++6 11.2.0-12 ii libsystemd0 249.7-1 ii libunwind8 1.3.2-2 ii libxau6 1:1.0.9-1 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.5-1 ii perl5.32.1-6 ii tigervnc-common 1.11.0+dfsg-3 ii x11-xkb-utils 7.7+5 ii xauth 1:1.1-1 ii xkb-data2.33-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages tigervnc-standalone-server recommends: ii libgl1-mesa-dri21.2.6-1 ii x11-xserver-utils 7.7+9 ii xfonts-base1:1.0.5 Versions of packages tigervnc-standalone-server suggests: ii xfonts-100dpi1:1.0.4+nmu1.1 ii xfonts-75dpi 1:1.0.4+nmu1.1 ii xfonts-scalable 1:1.0.3-1.2 -- no debconf information
Bug#991411: munin: "Permission denied" when trying to create /var/run/munin/munin-update.lock
Package: munin Version: 2.0.67-2 Severity: important X-Debbugs-Cc: cele...@gmail.com My munin installation, which had been working for several years, broke after an upgrade this morning from 2.0.67-1 -> 2.0.67-2. Now, munin-cron fails with: Creating lock /var/run/munin/munin-update.lock failed: Permission denied at /usr/share/perl5/Munin/Master/Update.pm line 127 [At least, that's the contents of an email to root every five minutes.] -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages munin depends on: ii cron [cron-daemon] 3.0pl1-137 ii debconf [debconf-2.0]1.5.77 ii fonts-dejavu-core2.37-2 ii init-system-helpers 1.60 ii libdate-manip-perl 6.85-1 pn libdigest-md5-perl ii libfile-copy-recursive-perl 0.45-1 ii libhtml-template-perl2.97-1.1 ii libio-socket-inet6-perl 2.72-2.1 ii liblog-log4perl-perl 1.54-1 ii librrds-perl 1.7.2-3+b7 pn libstorable-perl ii liburi-perl 5.08-1 ii lsb-base 11.1.0 ii munin-common 2.0.67-2 ii netbase 6.3 ii perl [libtime-hires-perl]5.32.1-4 ii rrdtool 1.7.2-3+b7 ii systemd-sysv 247.3-6 Versions of packages munin recommends: pn libcgi-fast-perl ii munin-doc 2.0.67-2 ii munin-node2.0.67-2 Versions of packages munin suggests: ii chromium [www-browser] 90.0.4430.212-1 ii firefox [www-browser] 88.0.1-1 pn httpd pn libapache2-mod-fcgid ii libnet-ssleay-perl 1.88-3+b1 ii links2 [www-browser]2.21-1+b1 ii lynx [www-browser] 2.9.0dev.6-2 -- debconf information: munin/postrm_remove_rrd_files: false
Bug#987624: dnscrypt-proxy: should declare dependency on ca-certificates
Package: dnscrypt-proxy Version: 2.0.45+ds1-1+b2 Severity: normal X-Debbugs-Cc: cele...@gmail.com If the ca-certificates package isn't installed, dnscrypt-proxy will fail to start using its default configuration, since it can't verify the download of the public resolvers file: [CRITICAL] Unable to use source [public-resolvers]: [Get https://download.dnscrypt.i nfo/resolvers-list/v2/public-resolvers.md: x509: certificate signed by unknown authority] The package should either declare a dependency on ca-certificates, or at least document the fact that the default configuration file won't work without that package. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dnscrypt-proxy depends on: ii adduser 3.118 ii libc6 2.31-11 ii lsb-base 11.1.0 dnscrypt-proxy recommends no packages. Versions of packages dnscrypt-proxy suggests: pn resolvconf -- no debconf information
Bug#987293: lxc: unprivileged containers don't have permission to access their configuration files
Package: lxc Version: 1:4.0.6-1 Severity: normal The default location for the configuration files of unprivileged containers created by non-root users seems to be $HOME/.local/share, but such containers will fail to start, since they don't have permission to access that directory, since it isn't world accessible. On this Sid system, $HOME and $HOME/.local are 755, but $HOME/.local/share is 700. On a Buster system of mine, $HOME is 755, but the other two are only 700. On both these systems, starting unprivileged containers fails with something like: lxc-start: my-container: start.c: print_top_failing_dir: 125 Permission denied - Could not access /home/username/.local/share. Please grant it x access, or add an ACL for the container root lxc-start: my-container: sync.c: __sync_wait: 62 An error occurred in another process (expected sequence number 3) lxc-start: my-container: start.c: __lxc_start: 1951 Failed to spawn container "my-container" lxc-start: my-container: tools/lxc_start.c: main: 330 The container failed to start lxc-start: my-container: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the --logfile and --logpriority options The solution is obviously to grant the appropriate permissions, but I think this should be handled automatically by the system, or at the very least, documentation should be added explaining the issue, instead of requiring users to figure this out on their own. Here's a suggestion for a paragraph to be added to the "Unprivileged containers" section of README.Debian: * Unprivileged containers started by non-root users store their configuration in ~/.local/share, and so must have permission to access that directory. This can be granted via a command like (assuming the acl package is installed): setfacl --modify user::x . .local .local/share where is the subuid mapped to 0 in ~/.config/lxc/default.conf * -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii bridge-utils 1.7-1 ii debconf [debconf-2.0]1.5.76 ii dnsmasq-base [dnsmasq-base] 2.85-1 ii iproute2 5.10.0-4 ii iptables 1.8.7-1 ii libc62.31-11 ii libcap2 1:2.44-1 ii libgcc-s110.2.1-6 ii liblxc1 1:4.0.6-1 ii libseccomp2 2.5.1-1 ii libselinux1 3.1-3 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.6-10 ii debootstrap1.0.123 ii dirmngr2.2.27-1 ii gnupg 2.2.27-1 pn libpam-cgfs ii lxc-templates 3.0.4-5 pn lxcfs ii openssl1.1.1k-1 ii rsync 3.2.3-4 ii uidmap 1:4.8.1-1 ii wget 1.21-1+b1 Versions of packages lxc suggests: ii btrfs-progs 5.10.1-1 ii lvm2 2.03.11-2.1 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#982158: xfce4-session-logout --suspend
I should have reported that the command bound to the keyboard shortcut is "xfce4-session-logout --suspend". When run from the command line, I get a popup window with the message "Received error while trying to log out GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, "(yb)", does not match expected type "(b")"" and the command line message: "Received error while trying to log out, error was GDBus.Error:org.xfce.SessionManager.Error.Failed: Failed to lock the screen." Celejar
Bug#982158: xfce4-power-manager: suspend is broken
Package: xfce4-power-manager Version: 4.16.0-1 Severity: normal Suspend (to RAM) has been working on my machine for years, but it broke a couple of months ago. When I try the keyboard shortcut I've configured (that has worked for years), I get an error popup window: Received error while trying to log out GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, "(yb)", does not match expected type "(b") (I've googled this message and found other references to it, but no clear solution / interpretation: https://unix.stackexchange.com/questions/626284/thunar-bug-should-i-report-to-xfce-or-ubuntu https://askubuntu.com/questions/1233288/unable-to-logout-from-guest-session-on-xubuntu-20-04 https://bugzilla.redhat.com/show_bug.cgi?id=1729059 https://forums.freebsd.org/threads/xfce-wont-let-me-log-out-anymore.76968/ https://www.reddit.com/r/xfce/comments/bej4xx/received_error_while_trying_to_log_out/ ) When I try the little "sleepy moon" icon, I get a different popup window: Failed to run action "Suspend" GDBus.Error:org.xfce.SessionManager.Error.Failed: Failed to lock the screen. Suspending via "systemctl suspend" works fine. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-power-manager depends on: ii libc6 2.31-9 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.6-1 ii libgtk-3-03.24.24-1 ii libnotify40.7.9-3 ii libpango-1.0-01.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libupower-glib3 0.99.11-2 ii libx11-6 2:1.7.0-2 ii libxext6 2:1.3.3-1.1 ii libxfce4ui-2-04.16.0-1 ii libxfce4util7 4.16.0-1 ii libxfconf-0-3 4.16.0-2 ii libxrandr22:1.5.1-1 ii upower0.99.11-2 ii xfce4-power-manager-data 4.16.0-1 Versions of packages xfce4-power-manager recommends: ii libpam-systemd [logind] 247.3-1 ii xfce4-power-manager-plugins 4.16.0-1 xfce4-power-manager suggests no packages. -- no debconf information
Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles
I've been suffering with this problem for a while as well. I have four extensions installed from Debian packages: HTTPS Everywhere, NoScript, Privacy Badger, and uBlock Origin. They all keep disappearing from the toolbar and stop functioning. I agree that this is an important bug, since besides being annoying, it can cause real privacy breaches. It's not due to cruft in old profiles; I've deleted and regenerated new profiles. It hits me on two different Debian unstable systems. I'm currently seeing the problem with Firefox 83.0 from Debian package 83.0-1. Celejar
Bug#623336: rdiff-backup: --max-file-size breaks --exclude instructions
On Wed, 14 Oct 2020 15:24:52 -0300 Pablo Mestre wrote: > Hi > > Thank you very much for reporting this error. > > I would like to ask you if this error is still present in the most > recent versions of rdiff-backup. Currently after a series of > improvements and bug fixes, rdiff-backup is at version 2.0.5 [1] > > It would be very helpful if you checked again if this bug is still present. > Otherwise we can agree to close the bug, > > [1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 Hi, I haven't used rdiff-backup in years, but I just did a quick check using Zachary's test example, and the behavior now seems to be correct: with or without --max-file-size, only the 'a' directory is created. Celejar
Bug#972109: iperf3: opaque error message when attempting to connect to a non-running iperf3 server
Package: iperf3 Version: 3.9-1 Severity: wishlist Hi, When running iperf3 and attempting to connect to a non-running iperf3 server (i.e., a closed TCP port), this error message is returned: ~$ iperf3 -c somehost iperf3: error - unable to send control message: Bad file descriptor iperf3's current message isn't a very clear description of the problem. Earlier versions of iperf3 (such as 3.6-2, in Stable) print out the much clearer: ~$ iperf3 -c somehost iperf3: error - unable to connect to server: Connection refused I suggest that the earlier message be reinstated. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iperf3 depends on: ii libc6 2.31-4 ii libiperf0 3.9-1 iperf3 recommends no packages. iperf3 suggests no packages. -- no debconf information
Bug#961189: mc: include Markdown viewing support
Package: mc Version: 3:4.8.24-2 Severity: wishlist I suggest that mc include support for proper viewing of Markdown files out of the box. They are ubiquitious these days, due to the popularity of GitHub. I'm currently using this snippet in $HOME/.config/mc.ext: # Markdown shell/i/.md View=pandoc %f | lynx -stdin mc gurus can likely come up with something better - there are a bunch of suggestions here: https://unix.stackexchange.com/questions/4140/markdown-viewer -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mc depends on: ii libc6 2.30-8 ii libext2fs21.45.6-1 ii libglib2.0-0 2.64.2-1 ii libgpm2 1.20.7-6 ii libslang2 2.3.2-4 ii libssh2-1 1.8.0-2.1 ii mc-data 3:4.8.24-2 Versions of packages mc recommends: ii mime-support 3.64 ii perl 5.30.2-1 ii unzip 6.0-25 Versions of packages mc suggests: pn arj ii bzip2 1.0.8-2 pn catdvi | texlive-binaries pn dbview pn djvulibre-bin pn epub-utils ii evince [pdf-viewer] 3.36.1-1 ii file 1:5.38-5 ii genisoimage 9:1.1.11-3.1 pn gv ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2 pn libaspell-dev ii lynx 2.9.0dev.5-1 ii mupdf [pdf-viewer]1.16.1+ds1-2 pn odt2txt ii poppler-utils 0.71.0-6 ii python2.7.17-2 pn python-boto pn python-tz ii qpdfview [pdf-viewer] 0.4.18-1+b1 ii zathura-pdf-poppler [pdf-viewer] 0.3.0-1 ii zip 3.0-11+b1 -- no debconf information
Bug#956501: console-setup: keyboard layout in /etc/default/keyboard is not set correctly on startup
On Sun, 12 Apr 2020 00:31:29 -0400 Celejar wrote: > Package: console-setup > Version: 1.195 > Severity: normal > > Hi, > > I'm not sure if this is a problem with console-setup or > keyboard-configuration. > > ~$ cat /etc/default/keyboard > # KEYBOARD CONFIGURATION FILE > > # Consult the keyboard(5) manual page. > > XKBMODEL="pc105" > XKBLAYOUT="us,il" > XKBVARIANT="dvorak," > XKBOPTIONS="terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps" > > BACKSPACE="guess" > > Until recently, these settings were all correctly set on system startup, > but the keyboard layout settings are currently not set correctly on > startup: > > ~$ setxkbmap -query > rules: evdev > model: pc105 > layout: us > variant:dvorak > options:terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps Additionally: I checked /var/log/Xorg.0.log (attached), and it claims that the options are indeed set correctly. But the fact is that they are not, as per the above "setxkbmap -query" command. Celejar
Bug#958194: libtext-vcard-perl: address_book->load_string() dies on missing name
Package: libtext-vcard-perl
Version: 3.09-1
Severity: normal
While writing an Android contacts -> VCF converter, I discovered that
the vCard::Addressbook "load_string" method dies when called on a vCard
(created using standard Perl vCard methods) that is missing name data.
The following script demonstrates the problem:
#! /usr/bin/perl -w
use vCard;
use strict;
my $vcard = vCard->new;
$vcard->phones([{type => ['home'], number => '651-290-'}]);
my $address_book = vCard::AddressBook->new();
$address_book->load_string($vcard->as_string);
This dies with the error:
Can't call method "family" on an undefined value at
/usr/share/perl5/vCard/AddressBook.pm line 208.
I understand that such a vCard may violate RFC 6350:
https://tools.ietf.org/html/rfc6350
(and may not be all that useful anyway), but in my opinion, the module
should handle this case better, rather than force the programmer to
write eval or try / catch semantics, or to figure out some way to verify
the vCard's correctness before calling "load_string".
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libtext-vcard-perl depends on:
ii libmoo-perl2.004000-1
ii libpath-tiny-perl 0.108-1
ii libtext-vfile-asdata-perl 0.08-1
ii libunicode-linebreak-perl 0.0.20190101-1+b2
ii liburi-perl1.76-2
ii perl 5.30.0-10
libtext-vcard-perl recommends no packages.
libtext-vcard-perl suggests no packages.
-- no debconf information
Bug#956501: console-setup: keyboard layout in /etc/default/keyboard is not set correctly on startup
Package: console-setup Version: 1.195 Severity: normal Hi, I'm not sure if this is a problem with console-setup or keyboard-configuration. ~$ cat /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL="pc105" XKBLAYOUT="us,il" XKBVARIANT="dvorak," XKBOPTIONS="terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps" BACKSPACE="guess" Until recently, these settings were all correctly set on system startup, but the keyboard layout settings are currently not set correctly on startup: ~$ setxkbmap -query rules: evdev model: pc105 layout: us variant:dvorak options:terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps As per 'man 5 keyboard', this can be corrected by directing the system to (re)read /etc/default/keyboard: ~# udevadm trigger --subsystem-match=input --action=change ~$ setxkbmap -query rules: evdev model: pc105 layout: us,il variant:dvorak, options:terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps But why is this not happening correctly on startup, requiring manual intervention? -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages console-setup depends on: ii console-setup-linux 1.195 ii debconf 1.5.73 ii keyboard-configuration 1.195 ii xkb-data2.29-2 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales 2.30-4 ii lsb-base 11.1.0 Versions of packages keyboard-configuration depends on: ii debconf 1.5.73 ii liblocale-gettext-perl 1.07-4 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.57 ii initscripts 2.96-3 ii kbd 2.0.4-4 ii keyboard-configuration 1.195 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools pn gnome-control-center ii kbd 2.0.4-4 ii systemd 245.4-3 -- debconf information: * keyboard-configuration/toggle: Alt+Shift debian-installer/console-setup-udeb/title: console-setup/fontsize-text47: 8x16 console-setup/use_system_font: * keyboard-configuration/layout: console-setup/fontsize-fb47: 8x16 console-setup/framebuffer_only: keyboard-configuration/unsupported_config_options: true * keyboard-configuration/compose: No compose key * keyboard-configuration/layoutcode: us,il * keyboard-configuration/switch: No temporary switch keyboard-configuration/unsupported_options: true * keyboard-configuration/model: Generic 105-key PC (intl.) * keyboard-configuration/variant: English (US) - English (Dvorak) keyboard-configuration/unsupported_config_layout: true * keyboard-configuration/xkb-keymap: us console-setup/fontsize: 8x16 console-setup/store_defaults_in_debconf_db: true console-setup/fontface47: Fixed * keyboard-configuration/optionscode: terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps * keyboard-configuration/store_defaults_in_debconf_db: true * keyboard-configuration/modelcode: pc105 console-setup/guess_font: keyboard-configuration/unsupported_layout: true console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages * keyboard-configuration/other: keyboard-configuration/ctrl_alt_bksp: true console-setup/codesetcode: Lat15 console-setup/charmap47: UTF-8 * keyboard-configuration/altgr: The default for the keyboard layout * keyboard-configuration/variantcode: dvorak,
Bug#946996: wireguard-tools: 'wg-quick down' segfaults
On Mon, 09 Mar 2020 17:22:57 -0400 Daniel Kahn Gillmor wrote: > On Mon 2020-02-03 13:20:22 -0500, Celejar wrote: > > Okay, now I've gotten it. I've uninstalled nftables and put in the > > debug line, and I get this (with 1.0.20200121-2): > > > > ~# ifdown wg0 > > [#] ip -4 rule delete table 51820 > > [#] ip -4 rule delete table main suppress_prefixlength 0 > > [#] ip link delete dev wg0 > > [#] resolvconf -d tun.wg0 -f > > RESTORING: *filter > > COMMIT > > *nat > > COMMIT > > *mangle > > -D PREROUTING -p udp -m comment --comment "wg-quick(8) rule for wg0" -j > > CONNMARK --restore-mark --nfmask 0x --ctmask 0x > > -D POSTROUTING -p udp -m mark --mark 0xca6c -m comment --comment > > "wg-quick(8) rule for wg0" -j CONNMARK --save-mark --nfmask 0x > > --ctmask 0x > > COMMIT > > *raw > > COMMIT > > [#] iptables-restore -n > > /usr/bin/wg-quick: line 29: 2284068 Segmentation fault "$@" > > > OK, so it looks to me like the problem comes when feeding this set of > commands into iptables-restore. > > But hm, i'm still having trouble replicating the segfault. > > Is this still happening for you? Yes (with 1.0.20200206-2) > Can you send the output of these two commands? > > dpkg -l iptables wireguard ~$ dpkg -l iptables wireguard Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionArchitecture Description ++ +-==-==-- ii iptables 1.8.4-3amd64administration tools for packet filtering and NAT ii wireguard 1.0.20200206-2 all fast, modern, secure kernel VPN tunnel (metapackage) > dpkg -S $(readlink -f $(which iptables-restore)) ~# dpkg -S $(readlink -f $(which iptables-restore)) iptables: /usr/sbin/xtables-nft-multi > That might help us narrow down the cause of the segfault. > > Sorry for how long this is taking to debug! Hey, wireguard itself seems entirely functional here - I'm just trying to do my tiny bit to help Debian! Thank you for all your work on this and Debian in general (and your privacy work). Celejar
Bug#952724: "warning: ICC support is not available" warnings
Package: mupdf Version: 1.16.1+ds1-1 Severity: normal Recently, mupdf has begun to spew the following warning, on startup and every time I navigate to a new page: warning: ICC support is not available Perhaps this is because colord is not installed? -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mupdf depends on: ii libc62.29-10 ii libfreetype6 2.10.1-2 ii libharfbuzz0b2.6.4-1 ii libjbig2dec0 0.17-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libopenjp2-7 2.3.1-1 ii libx11-6 2:1.6.9-2 ii libxext6 2:1.3.3-1+b2 ii zlib1g 1:1.2.11.dfsg-2 mupdf recommends no packages. Versions of packages mupdf suggests: pn mupdf-tools -- no debconf information
Bug#952723: mupdf: Major changes to functionality / keybindings should be mentioned in the changelogs or elsewhere
Package: mupdf Version: 1.16.1+ds1-1 Severity: normal After a recent upgrade, '<' to skip ten pages back and '>' to skip ten pages forward no longer work. Digging through current and old manpages indicates that these keys have been repurposed to decrease / increase EPUB / XHTML font size, and there's no mention of any way to get the skip functionality in current mupdf. I see no mention of this change in the changelogs. These keys were a major part of my mupdf usage, and I think that their repurposing should be better documented. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mupdf depends on: ii libc62.29-10 ii libfreetype6 2.10.1-2 ii libharfbuzz0b2.6.4-1 ii libjbig2dec0 0.17-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libopenjp2-7 2.3.1-1 ii libx11-6 2:1.6.9-2 ii libxext6 2:1.3.3-1+b2 ii zlib1g 1:1.2.11.dfsg-2 mupdf recommends no packages. Versions of packages mupdf suggests: pn mupdf-tools -- no debconf information
Bug#946996: wireguard-tools: 'wg-quick down' segfaults
On Tue, 28 Jan 2020 14:14:01 -0500 Daniel Kahn Gillmor wrote: > On Mon 2020-01-27 19:45:36 -0500, Celejar wrote: > > I think I'm probably missing something, but lately "ifdown wg0" isn't > > segfaulting (even after downgrading back to 1.0.20200102-1) - but it > > doesn't seem to be calling iptables-restore at all, but only nft: > > Ah, that'd be because you installed nft. If you only had iptables > installed, and you didn't have nft installed, then you'd exercise the > different codepath in wg-quick. Okay, now I've gotten it. I've uninstalled nftables and put in the debug line, and I get this (with 1.0.20200121-2): ~# ifdown wg0 [#] ip -4 rule delete table 51820 [#] ip -4 rule delete table main suppress_prefixlength 0 [#] ip link delete dev wg0 [#] resolvconf -d tun.wg0 -f RESTORING: *filter COMMIT *nat COMMIT *mangle -D PREROUTING -p udp -m comment --comment "wg-quick(8) rule for wg0" -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -D POSTROUTING -p udp -m mark --mark 0xca6c -m comment --comment "wg-quick(8) rule for wg0" -j CONNMARK --save-mark --nfmask 0x --ctmask 0x COMMIT *raw COMMIT [#] iptables-restore -n /usr/bin/wg-quick: line 29: 2284068 Segmentation fault "$@" Celejar
Bug#946996: wireguard-tools: 'wg-quick down' segfaults
On Thu, 23 Jan 2020 12:16:07 -0500 Daniel Kahn Gillmor wrote: > On Thu 2020-01-23 00:01:57 -0500, Celejar wrote: > > So right after my last email, I upgraded to 1.0.20200121-1, and now I > > no longer get a segfault. Is there anything further I should do? Should > > I do a downgrade and try your modification? > > If you don't mind downgrading (just the wireguard-tools package), > modifying wg-quick as described, and retrying "ifdown wg0", that would > be useful data to the iptables maintainers, as it should be input that > produces a segmentation fault -- something that is not supposed to > happen. > > Then, you can probably upgrade wireguard-tools again and move on :) I think I'm probably missing something, but lately "ifdown wg0" isn't segfaulting (even after downgrading back to 1.0.20200102-1) - but it doesn't seem to be calling iptables-restore at all, but only nft: ~# ifdown wg0 [#] ip -4 rule delete table 51820 [#] ip -4 rule delete table main suppress_prefixlength 0 [#] ip link delete dev wg0 [#] resolvconf -d tun.wg0 -f [#] nft -f /dev/fd/63 ~# apt-cache policy wireguard-tools wireguard-tools: Installed: 1.0.20200102-1 Candidate: 1.0.20200121-2 Version table: 1.0.20200121-2 500 500 http://deb.debian.org/debian sid/main amd64 Packages *** 1.0.20200102-1 100 100 /var/lib/dpkg/status Celejar
Bug#946996: wireguard-tools: 'wg-quick down' segfaults
On Wed, 22 Jan 2020 16:47:17 -0500
Daniel Kahn Gillmor wrote:
> Control: tags 946996 + moreinfo
>
> On Tue 2020-01-21 22:18:45 -0500, Celejar wrote:
> > Sorry, I'm still getting it:
> >
> > ~# apt-cache policy wireguard-tools
> > wireguard-tools:
> > Installed: 1.0.20200102-1
> > Candidate: 1.0.20200102-1
> > Version table:
> > *** 1.0.20200102-1 500
> > 500 http://deb.debian.org/debian sid/main amd64 Packages
> > 100 /var/lib/dpkg/status
> >
> > ~# ifdown wg0
> > [#] ip -4 rule delete table 51820
> > [#] ip -4 rule delete table main suppress_prefixlength 0
> > [#] ip link delete dev wg0
> > [#] resolvconf -d tun.wg0 -f
> > [#] iptables-restore -n
> > /usr/bin/wg-quick: line 29: 186243 Segmentation fault "$@"
>
> Interesting. Can you modify wg-quick locally to expose what is being
> piped into iptables-restore -n in this instance?
>
> For example, a change like this:
>
>
> --- wg-quick.orig 2020-01-22 16:05:42.456100207 -0500
> +++ wg-quick 2020-01-22 16:45:35.936536027 -0500
> @@ -198,6 +198,7 @@
> [[ $line == "-A"* ]] && found=1
> printf -v restore '%s%s\n' "$restore"
> "${line/#-A/-D}"
> done < <($iptables-save 2>/dev/null)
> +[[ $found -ne 1 ]] || echo -n "RESTORING: $restore"
> >&2
> [[ $found -ne 1 ]] || echo -n "$restore" | cmd
> $iptables-restore -n
> done
> fi
>
>
> Then report back what is printed there, and see whether feeding it into
> "iptables-restore -n" on its own is sufficient to cause a segfault.
So right after my last email, I upgraded to 1.0.20200121-1, and now I
no longer get a segfault. Is there anything further I should do? Should
I do a downgrade and try your modification?
> thanks for taking the time to report and debug!
Celejar
Bug#946996: wireguard-tools: 'wg-quick down' segfaults
On Tue, 21 Jan 2020 10:36:25 -0500 Daniel Kahn Gillmor wrote: > Control: reassign 946996 iptables > Control: affects 946996 + wireguard-tools > > Hi Celejar-- > > On Thu 2019-12-19 00:00:39 -0500, Celejar wrote: > > Package: wireguard-tools > > Version: 0.0.20191212-1 > > Severity: normal > > > > I use wireguard to establish a very simple point-to-point VPN. 'wg-quick > > up wgo' works fine; 'wg-quick down wg0' also seems to work correctly, > > but it segfaults after doing (AFAICT) everything that it's supposed to > > do. Everything seems to be working fine, though, both before and afterward. ... > Thanks for this report. It looks to me like this is a segfault in > iptables-restore, not in wg-quick, so i'm reassigning the bug report to > the iptables package, which shouldn't segfault, no matter what input it > receives. (maybe this is due to sending it empty lines? > > In the meantime, i believe that more recent versions of wireguard-tools > do not send empty lines to iptables-restore. Can you verify that this > doesn't happen for you with a more recent version? Sorry, I'm still getting it: ~# apt-cache policy wireguard-tools wireguard-tools: Installed: 1.0.20200102-1 Candidate: 1.0.20200102-1 Version table: *** 1.0.20200102-1 500 500 http://deb.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status ~# ifdown wg0 [#] ip -4 rule delete table 51820 [#] ip -4 rule delete table main suppress_prefixlength 0 [#] ip link delete dev wg0 [#] resolvconf -d tun.wg0 -f [#] iptables-restore -n /usr/bin/wg-quick: line 29: 186243 Segmentation fault "$@" ... > Thanks for reporting this, Thank you for all your Debian, technology, and privacy work! Celejar
Bug#946996: wireguard-tools: 'wg-quick down' segfaults
Package: wireguard-tools Version: 0.0.20191212-1 Severity: normal I use wireguard to establish a very simple point-to-point VPN. 'wg-quick up wgo' works fine; 'wg-quick down wg0' also seems to work correctly, but it segfaults after doing (AFAICT) everything that it's supposed to do. Everything seems to be working fine, though, both before and afterward. I tried figuring out what, exactly, the script is doing when it segfaults, but I couldn't quite make it out. It seems to successfully do 'del_if', 'unset_dns', and 'remove_firewall', but then do something wrong in the 'execute_hooks' stage? ~# wg-quick down wg0 [#] ip -4 rule delete table 51820 [#] ip -4 rule delete table main suppress_prefixlength 0 [#] ip link delete dev wg0 [#] resolvconf -d tun.wg0 -f [#] iptables-restore -n /usr/bin/wg-quick: line 29: 1411585 Segmentation fault "$@" -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireguard-tools depends on: ii libc62.29-6 ii libmnl0 1.0.4-2+b1 Versions of packages wireguard-tools recommends: ii iptables1.8.4-1 ii wireguard-dkms 0.0.20191212-1 wireguard-tools suggests no packages. -- no debconf information
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
On Fri, 13 Dec 2019 15:29:23 +1030 Andrew Bettison wrote: > On Sun, 08 Sep 2019 23:43:04 -0400 Celejar wrote: > > > Package: firmware-iwlwifi > > Version: 20190717-2 > > Followup-For: Bug #934781 > > > > I did some further digging - in my case, at least, the problem seems to > > be triggered by some relatively recent kernel change. I combed through > > the system journal for the last few months, and the problem first starts > > appearing in the logs a few days after I began running kernel 5.2.x > > (from 5.2.7 through 5.2.9). Previously, while running 4.19.x, the > > problem never appears. > > > > I haven't done a bisection, but it seems pretty clear at this point that > > there's a microcode bug that has begun to be triggered by something in > > newer kernels. > As an experiment, I downloaded the tarball from > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tag/?h=20190815 > > (as recommended in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262 ), and manually > copied its intel/* and iwlwifi-* files into /lib/firmware (overwriting > the ones installed by the firmware-iwlwifi package). > > After rebooting kernel 5.3.0-2 (amd64) I still get "iwlwifi: Microcode > SW error" messages accompanied by "ieee80211 phy0: Hardware restart was > requested" during periods of high Wi-Fi throughput, but they do not > cause the Wi-Fi to hang. So the newer firmware appears to rectify the > worst part of the problem (Wi-Fi freeze) but does not fully resolve the > problem. On my system, the problem last appeared on Sep. 17 (with a Debian kernel version 5.2.9-2). Since then, I have not seen any "Microcode SW" errors. I've been running 4.19.72 (self-built), 5.2.17-1, 5.3.7-1, 5.3.9 (-1, -2, -3), and 5.3.15-1 (Debian). [I examined the boot logs with: ~# journalctl -S 2019-06-01 | grep "Linux ver\|Microcode SW" ] Celejar
Bug#946129: xfce4-session: documentation claiming that shutdown requires sudo or HAL is outdated or inaccurate
Package: xfce4-session Version: 4.14.0-1+b1 Severity: normal The README claims that either sudo or HAL is required for system shutdown. My system has neither and shutdown / suspend work fine. I assume this is currently handled by systemd / polkit? In any event, the documentation, either ours or upstream's as appropriate, should be updated to reflect the current state of affairs. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-session depends on: ii libatk1.0-02.34.1-1 ii libc6 2.29-3 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-1 ii libglib2.0-0 2.62.3-1 ii libgtk-3-0 3.24.13-1 ii libice62:1.0.9-2 ii libpango-1.0-0 1.42.4-7 ii libpolkit-gobject-1-0 0.105-26 ii libsm6 2:1.2.3-1 ii libwnck-3-03.32.0-1 ii libx11-6 2:1.6.8-1 ii libxfce4ui-2-0 4.14.1-1+b1 ii libxfce4util7 4.14.0-1 ii libxfconf-0-3 4.14.1-1 ii xfce4-settings 4.14.1-1 ii xfconf 4.14.1-1 Versions of packages xfce4-session recommends: ii dbus-x11 1.12.16-2 ii libpam-systemd 243-9 ii light-locker 1.8.0-3 ii systemd-sysv 243-9 ii upower 0.99.11-1 ii x11-xserver-utils 7.7+8 ii xfdesktop4 4.14.1-1 ii xfwm4 4.14.0-2 Versions of packages xfce4-session suggests: pn fortunes-mod pn sudo -- no debconf information
Bug#945508: fastboot: hangs indefinitely when trying to flash a recovery
Package: fastboot Version: 1:8.1.0+r23-5 Severity: important I'm trying to flash a TWRP recovery to a Xiaomi Mix 2s phone: ~$ fastboot devices fastboot ~$ fastboot flash recovery twrp-3.3.1-1-polaris.img The command hangs - it does not return, display any message to the terminal, or log anything, until 120 seconds have passed, at which point the following appears in syslog: Nov 25 13:06:22 lila kernel: [ 363.660869] INFO: task fastboot:2753 blocked for more than 120 seconds. Nov 25 13:06:22 lila kernel: [ 363.660877] Tainted: G OE 5.3.0-2-amd64 #1 Debian 5.3.9-3 Nov 25 13:06:22 lila kernel: [ 363.660880] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 25 13:06:22 lila kernel: [ 363.660884] fastbootD0 2753 2497 0x Nov 25 13:06:22 lila kernel: [ 363.660889] Call Trace: Nov 25 13:06:22 lila kernel: [ 363.660902] ? __schedule+0x2b9/0x6c0 Nov 25 13:06:22 lila kernel: [ 363.660908] schedule+0x39/0xa0 Nov 25 13:06:22 lila kernel: [ 363.660914] schedule_timeout+0x20f/0x300 Nov 25 13:06:22 lila kernel: [ 363.660941] ? usb_hcd_submit_urb+0xc0/0xbf0 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.660948] wait_for_completion_timeout+0x126/0x170 Nov 25 13:06:22 lila kernel: [ 363.660954] ? wake_up_q+0x60/0x60 Nov 25 13:06:22 lila kernel: [ 363.660974] usb_start_wait_urb+0x83/0x160 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.660998] proc_bulk+0x175/0x310 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.661018] usbdev_do_ioctl+0x311/0xf50 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.661038] usbdev_ioctl+0xa/0x10 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.661045] do_vfs_ioctl+0x40e/0x670 Nov 25 13:06:22 lila kernel: [ 363.661052] ksys_ioctl+0x5e/0x90 Nov 25 13:06:22 lila kernel: [ 363.661057] __x64_sys_ioctl+0x16/0x20 Nov 25 13:06:22 lila kernel: [ 363.661063] do_syscall_64+0x53/0x140 Nov 25 13:06:22 lila kernel: [ 363.661067] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 25 13:06:22 lila kernel: [ 363.661072] RIP: 0033:0x7ff70cb255b7 Nov 25 13:06:22 lila kernel: [ 363.661082] Code: Bad RIP value. Nov 25 13:06:22 lila kernel: [ 363.661085] RSP: 002b:7fffb4e068a8 EFLAGS: 0246 ORIG_RAX: 0010 Nov 25 13:06:22 lila kernel: [ 363.661089] RAX: ffda RBX: 7fffb4e068c0 RCX: 7ff70cb255b7 Nov 25 13:06:22 lila kernel: [ 363.661091] RDX: 7fffb4e068d0 RSI: c0185502 RDI: 0004 Nov 25 13:06:22 lila kernel: [ 363.661093] RBP: 0006 R08: 557ae441bca0 R09: 7fffb4e06b50 Nov 25 13:06:22 lila kernel: [ 363.661095] R10: R11: 0246 R12: 7fffb4e068d0 Nov 25 13:06:22 lila kernel: [ 363.661097] R13: 557ae441bc80 R14: 0040 R15: 0040 The same thing appears every 120 seconds. When the USB cable is disconnected, fastboot prints this rather incoherent message to the terminal and then terminates: target didn't report max-download-size sending 'recovery' (59720 KB)... FAILED (command write failed (Success)) finished. total time: 0.000s -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fastboot depends on: ii android-libadb 1:8.1.0+r23-5 ii android-libbase1:8.1.0+r23-5 ii android-libcutils 1:8.1.0+r23-5 ii android-libf2fs-utils 8.1.0+r23-2 ii android-libsparse 1:8.1.0+r23-5 ii android-libutils 1:8.1.0+r23-5 ii android-libziparchive 1:8.1.0+r23-5 ii libc6 2.29-3 ii libgcc11:9.2.1-19 ii libstdc++6 9.2.1-19 Versions of packages fastboot recommends: ii android-sdk-platform-tools 27.0.0+12 fastboot suggests no packages. -- no debconf information
Bug#941884: bbswitch-dkms: bbswitch is broken
Package: bbswitch-dkms Version: 0.8-8 Severity: important bbswitch seems completely broken on my system. On boot, it loads, and first reports: bbswitch: disabling discrete graphics but immediately follows this with: bbswitch: Succesfully loaded. Discrete card :08:00.0 is on # cat /proc/acpi/bbswitch :08:00.0 ON # tee /proc/acpi/bbswitch << -- no debconf information ct 6 22:44:26 lila kernel: [ 118.730214] bbswitch: disabling discrete graphics Oct 6 22:44:26 lila kernel: [ 118.744071] [ cut here ] Oct 6 22:44:26 lila kernel: [ 118.744072] pci :08:00.0: disabling already-disabled device Oct 6 22:44:26 lila kernel: [ 118.744082] WARNING: CPU: 1 PID: 2205 at drivers/pci/pci.c:1924 pci_disable_device+0x8a/0xa0 Oct 6 22:44:26 lila kernel: [ 118.744083] Modules linked in: acpi_call(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpud p nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nf_tables nfnetlink tun bridge stp llc cpufreq_cons ervative cpufreq_userspace cpufreq_powersave ipmi_devintf ipmi_msghandler snd_hda_codec_hdmi btusb btrtl btbcm btintel bluetooth drbg ansi_cprng ecdh_ generic ecc rmi_smbus rmi_core binfmt_misc intel_rapl arc4 x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass iwlmvm mac80211 crct 10dif_pclmul crc32_pclmul iTCO_wdt rtsx_pci_ms mei_wdt iTCO_vendor_support i915 memstick snd_hda_codec_realtek iwlwifi watchdog rtsx_pci_sdmmc wmi_bmo f mmc_core snd_hda_codec_generic ghash_clmulni_intel snd_hda_intel intel_cstate intel_uncore snd_hda_codec xhci_pci e1000e thinkpad_acpi intel_rapl_pe rf snd_hda_core cfg80211 tpm_tis mei_me xhci_hcd drm_kms_helper nvram snd_hwdep ehci_pci snd_pcm tpm_tis_core joydev i2c_i801 pcspkr Oct 6 22:44:26 lila kernel: [ 118.744106] snd_timer ledtrig_audio ehci_hcd drm snd ptp rtsx_pci sg intel_pch_thermal usbcore mei pps_core soundcore tpm rfkill lpc_ich i2c_algo_bit usb_common mfd_core pcc_cpufreq wmi ac battery rng_core video button parport_pc ppdev lp parport sunrpc bbswitch(OE) ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod sd_mod crc32c_intel aesni_intel ahci libahci libata psmouse aes_x86_ 64 glue_helper crypto_simd cryptd scsi_mod evdev serio_raw Oct 6 22:44:26 lila kernel: [ 118.744124] CPU: 1 PID: 2205 Comm: tee Tainted: G OE 5.2.0-3-amd64 #1 Debian 5.2.17-1 Oct 6 22:44:26 lila kernel: [ 118.744124] Hardware name: LENOVO 20E2CTO1WW/20E2CTO1WW, BIOS N11ET42W (1.18 ) 09/13/2017 Oct 6 22:44:26 lila kernel: [ 118.744127] RIP: 0010:pci_disable_device+0x8a/0xa0 Oct 6 22:44:26 lila kernel: [ 118.744128] Code: 48 85 ed 75 07 48 8b ab b0 00 00 00 48 8d bb b0 00 00 00 e8 58 ef 11 00 48 89 ea 48 c7 c7 d0 83 8c 8 2 48 89 c6 e8 50 55 c5 ff <0f> 0b eb 8f 48 89 df e8 ea fe ff ff 80 a3 c1 07 00 00 df 5b 5d c3 Oct 6 22:44:26 lila kernel: [ 118.744129] RSP: 0018:b6578343fe58 EFLAGS: 00010282 Oct 6 22:44:26 lila kernel: [ 118.744130] RAX: RBX: 89e783c08000 RCX: Oct 6 22:44:26 lila kernel: [ 118.744131] RDX: 0033 RSI: 8300fb93 RDI: 0246 Oct 6 22:44:26 lila kernel: [ 118.744131] RBP: 89e7841c6140 R08: 8300fb60 R09: 00029940 Oct 6 22:44:26 lila kernel: [ 118.744132] R10: 004867c2b172 R11: 089d R12: 7ffdcf072890 Oct 6 22:44:26 lila kernel: [ 118.744133] R13: b6578343ff08 R14: 7ffdcf072890 R15: Oct 6 22:44:26 lila kernel: [ 118.744134] FS: 7fda3f0f0580() GS:89e785e4() knlGS: Oct 6 22:44:26 lila kernel: [ 118.744135] CS: 0010 DS: ES: CR0: 80050033 Oct 6 22:44:26 lila kernel: [ 118.744135] CR2: 5651db4940f8 CR3: 00021b9b8001 CR4: 003606e0 Oct 6 22:44:26 lila kernel: [ 118.744136] Call Trace: Oct 6 22:44:26 lila kernel: [ 118.744141] bbswitch_off.cold.5+0xc1/0x1d1 [bbswitch] Oct 6 22:44:26 lila kernel: [ 118.744143] bbswitch_proc_write+0xaf/0xc6 [bbswitch] Oct 6 22:44:26 lila kernel: [ 118.744146] proc_reg_write+0x39/0x60 Oct 6 22:44:26 lila kernel: [ 118.744148] vfs_write+0xa5/0x1a0 Oct 6 22:44:26 lila kernel: [ 118.744150] ksys_write+0x59/0xd0
Bug#940690: nvidia-kernel-dkms: build fails with kernel built with different gcc version
On Thu, 19 Sep 2019 12:07:54 +0200 Andreas Beckmann wrote: > Control: tag -1 wontfix > > On 19/09/2019 05.52, Celejar wrote: > > Build fails on a Sid system, with gcc symlinked to gcc-9, running a > > kernel built on a Buster system with gcc-8. Based on make.log and the > > The kernel headers store information which compiler was used to build > the kernel, and this compiler is used for the out-of-tree modules, too. > In your case the kernel was built with (unversioned) 'gcc' and that will > be used for the out-of-tree modules, too, even if the symlink now points > elsewhere. (Official Debian kernels are built with versioned compiler > binaries (e.g. gcc-8, gcc-9) only, and the headers have dependencies on > the corresponding packages, to avoid mismatches if the default compiler > changes. (The kernel compiler is usually switched independently from the > default system compiler.) > > Therefore: Always build custom kernels with versioned compilers. Ah, thanks. Just one question: how do I do that, and where is this documented, either in the Debian kernel handbook or in general kernel build guides? I can't find an option within the kernel config system for versioned compilers. Do I need to use environment variables? Celejar
Bug#940690: nvidia-kernel-dkms: build fails with kernel built with different gcc version
Package: nvidia-kernel-dkms Version: 430.50-1 Severity: normal Build fails on a Sid system, with gcc symlinked to gcc-9, running a kernel built on a Buster system with gcc-8. Based on make.log and the documentation in README.txt, I tried setting the CC environment variable with: CC=/usr/bin/gcc-8 export CC aptitude ... But the results were the same, with the installation process still trying to use gcc 9.x. -- Package-specific info: uname -a: Linux lila 4.19.72-lila #1 SMP Fri Sep 13 17:42:52 EDT 2019 x86_64 GNU/Linux /proc/version: Linux version 4.19.72-lila (@alice) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Fri Sep 13 17:42:52 EDT 2019 lspci 'display controller [030?]': 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 5500 [17aa:2225] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 08:00.0 3D controller [0302]: NVIDIA Corporation GM108GLM [Quadro K620M / Quadro M500M] [10de:137a] (rev a2) Subsystem: Lenovo GM108GLM [Quadro K620M / Quadro M500M] [17aa:2225] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Sep 17 23:28 /dev/dri/card0 crw-rw+ 1 root render 226, 128 Sep 17 23:28 /dev/dri/renderD128 /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Sep 17 23:28 pci-:00:02.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Sep 17 23:28 pci-:00:02.0-render -> ../renderD128 video:x:44: OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root25 Nov 13 2018 /etc/alternatives/glx -> /usr/lib/nvidia/bumblebee lrwxrwxrwx 1 root root51 Nov 13 2018 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1 lrwxrwxrwx 1 root root48 Nov 13 2018 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root48 Nov 13 2018 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root50 Nov 13 2018 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root50 Nov 13 2018 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root57 Nov 13 2018 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root57 Nov 13 2018 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root54 Nov 13 2018 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root54 Nov 13 2018 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root40 Nov 13 2018 /etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> /usr/lib/i386-linux-gnu/libGLX_mesa.so.0 lrwxrwxrwx 1 root root40 Nov 13 2018 /etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> /usr/lib/i386-linux-gnu/libGLX_mesa.so.0 lrwxrwxrwx 1 root root42 Nov 13 2018 /etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 lrwxrwxrwx 1 root root42 Nov 13 2018 /etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 lrwxrwxrwx 1 root root51 Nov 13 2018 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root42 Nov 13 2018 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root36 Nov 13 2018 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root32 Nov 13 2018 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root23 Sep 18 08:03 /etc/alternatives/nvidia -> /usr/lib/nvidia/current lrwxrwxrwx 1 root root50 Sep 18 08:03 /etc/alternatives/nvidia--libEGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/curre
Bug#940002: wireguard-dkms: kernel module fails to build for kernel 4.19.72
Package: wireguard-dkms Version: 0.0.20190905-1 Severity: important Installation fails for kernel version 4.19.72, self-built (on a different, Stable system) from vanilla kernel.org sources: Building module: cleaning build area... make -j4 KERNELRELEASE=4.19.72-lila -C /lib/modules/4.19.72-lila/build M=/var/lib/dkms/wireguard/0.0.20190905/build...(bad exit status: 2) Error! Bad return status for module build on kernel: 4.19.72-lila (x86_64) Consult /var/lib/dkms/wireguard/0.0.20190905/build/make.log for more information. make.log attached. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireguard-dkms depends on: ii dkms 2.7.1-4 ii perl 5.28.1-6 Versions of packages wireguard-dkms recommends: ii wireguard-tools 0.0.20190905-1 wireguard-dkms suggests no packages. -- no debconf information DKMS make.log for wireguard-0.0.20190905 for kernel 4.19.72-lila (x86_64) Tue 10 Sep 2019 10:10:55 PM EDT make: Entering directory '/usr/src/linux-headers-4.19.72-lila' CC [M] /var/lib/dkms/wireguard/0.0.20190905/build/main.o CC [M] /var/lib/dkms/wireguard/0.0.20190905/build/noise.o CC [M] /var/lib/dkms/wireguard/0.0.20190905/build/device.o CC [M] /var/lib/dkms/wireguard/0.0.20190905/build/peer.o In file included from ./include/linux/compat.h:16, from ./include/linux/ethtool.h:17, from ./include/linux/netdevice.h:41, from ./include/linux/icmpv6.h:13, from /var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876, from : ./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory 28 | #include/* for struct sockaddr. */ | ^~ compilation terminated. In file included from ./include/linux/compat.h:16, from ./include/linux/ethtool.h:17, from ./include/linux/netdevice.h:41, from ./include/linux/icmpv6.h:13, from /var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876, from : ./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory 28 | #include/* for struct sockaddr. */ | ^~ compilation terminated. In file included from ./include/linux/compat.h:16, from ./include/linux/ethtool.h:17, from ./include/linux/netdevice.h:41, from ./include/linux/icmpv6.h:13, from /var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876, from : ./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory 28 | #include/* for struct sockaddr. */ | ^~ compilation terminated. make[1]: *** [scripts/Makefile.build:303: /var/lib/dkms/wireguard/0.0.20190905/build/noise.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: *** [scripts/Makefile.build:303: /var/lib/dkms/wireguard/0.0.20190905/build/main.o] Error 1 make[1]: *** [scripts/Makefile.build:303: /var/lib/dkms/wireguard/0.0.20190905/build/peer.o] Error 1 In file included from ./include/linux/compat.h:16, from ./include/linux/ethtool.h:17, from ./include/linux/netdevice.h:41, from ./include/linux/icmpv6.h:13, from /var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876, from : ./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory 28 | #include/* for struct sockaddr. */ | ^~ compilation terminated. make[1]: *** [scripts/Makefile.build:303: /var/lib/dkms/wireguard/0.0.20190905/build/device.o] Error 1 make: *** [Makefile:1519: _module_/var/lib/dkms/wireguard/0.0.20190905/build] Error 2 make: Leaving directory '/usr/src/linux-headers-4.19.72-lila'
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
Package: firmware-iwlwifi Version: 20190717-2 Followup-For: Bug #934781 I did some further digging - in my case, at least, the problem seems to be triggered by some relatively recent kernel change. I combed through the system journal for the last few months, and the problem first starts appearing in the logs a few days after I began running kernel 5.2.x (from 5.2.7 through 5.2.9). Previously, while running 4.19.x, the problem never appears. I haven't done a bisection, but it seems pretty clear at this point that there's a microcode bug that has begun to be triggered by something in newer kernels. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.135 -- no debconf information
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
Package: firmware-iwlwifi Version: 20190717-2 Followup-For: Bug #934781 Hi, I'm also seeing Microcode SW errors on my Sid system (see attached). I'm not sure when they started, but I do look at my logs fairly often, and I've never noticed them before. Sometimes performance is not affected, but sometimes I see throughput drop from about 240-260 Mbps to about 30-40 Mbps. ~$ uname -a Linux lila 5.2.0-2-amd64 #1 SMP Debian 5.2.9-2 (2019-08-21) x86_64 GNU/Linux ~$ lspci | grep Wireless 03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 99) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.135 -- no debconf information Sep 5 23:42:30 lila kernel: [ 1480.015788] iwlwifi :03:00.0: Microcode SW error detected. Restarting 0x200. Sep 5 23:42:30 lila kernel: [ 1480.015915] iwlwifi :03:00.0: Start IWL Error Log Dump: Sep 5 23:42:30 lila kernel: [ 1480.015919] iwlwifi :03:00.0: Status: 0x0080, count: 6 Sep 5 23:42:30 lila kernel: [ 1480.015921] iwlwifi :03:00.0: Loaded firmware version: 29.1044073957.0 Sep 5 23:42:30 lila kernel: [ 1480.015924] iwlwifi :03:00.0: 0x105C | ADVANCED_SYSASSERT Sep 5 23:42:30 lila kernel: [ 1480.015926] iwlwifi :03:00.0: 0x00A00220 | trm_hw_status0 Sep 5 23:42:30 lila kernel: [ 1480.015928] iwlwifi :03:00.0: 0x | trm_hw_status1 Sep 5 23:42:30 lila kernel: [ 1480.015930] iwlwifi :03:00.0: 0x00043D54 | branchlink2 Sep 5 23:42:30 lila kernel: [ 1480.015932] iwlwifi :03:00.0: 0x0004AFDA | interruptlink1 Sep 5 23:42:30 lila kernel: [ 1480.015934] iwlwifi :03:00.0: 0x | interruptlink2 Sep 5 23:42:30 lila kernel: [ 1480.015936] iwlwifi :03:00.0: 0xDEADBEEF | data1 Sep 5 23:42:30 lila kernel: [ 1480.015938] iwlwifi :03:00.0: 0xDEADBEEF | data2 Sep 5 23:42:30 lila kernel: [ 1480.015940] iwlwifi :03:00.0: 0xDEADBEEF | data3 Sep 5 23:42:30 lila kernel: [ 1480.015942] iwlwifi :03:00.0: 0x8517 | beacon time Sep 5 23:42:30 lila kernel: [ 1480.015944] iwlwifi :03:00.0: 0x30C1A8EB | tsf low Sep 5 23:42:30 lila kernel: [ 1480.015946] iwlwifi :03:00.0: 0x03DA | tsf hi Sep 5 23:42:30 lila kernel: [ 1480.015948] iwlwifi :03:00.0: 0x | time gp1 Sep 5 23:42:30 lila kernel: [ 1480.015950] iwlwifi :03:00.0: 0x7931 | time gp2 Sep 5 23:42:30 lila kernel: [ 1480.015952] iwlwifi :03:00.0: 0x0001 | uCode revision type Sep 5 23:42:30 lila kernel: [ 1480.015954] iwlwifi :03:00.0: 0x001D | uCode version major Sep 5 23:42:30 lila kernel: [ 1480.015957] iwlwifi :03:00.0: 0x3E3B4DE5 | uCode version minor Sep 5 23:42:30 lila kernel: [ 1480.015959] iwlwifi :03:00.0: 0x0210 | hw version Sep 5 23:42:30 lila kernel: [ 1480.015961] iwlwifi :03:00.0: 0x00489200 | board version Sep 5 23:42:30 lila kernel: [ 1480.015963] iwlwifi :03:00.0: 0x0A44001C | hcmd Sep 5 23:42:30 lila kernel: [ 1480.015965] iwlwifi :03:00.0: 0x2402200A | isr0 Sep 5 23:42:30 lila kernel: [ 1480.015967] iwlwifi :03:00.0: 0x | isr1 Sep 5 23:42:30 lila kernel: [ 1480.015968] iwlwifi :03:00.0: 0x0002 | isr2 Sep 5 23:42:30 lila kernel: [ 1480.015970] iwlwifi :03:00.0: 0x0041A8C1 | isr3 Sep 5 23:42:30 lila kernel: [ 1480.015972] iwlwifi :03:00.0: 0x | isr4 Sep 5 23:42:30 lila kernel: [ 1480.015974] iwlwifi :03:00.0: 0x0048012C | last cmd Id Sep 5 23:42:30 lila kernel: [ 1480.015976] iwlwifi :03:00.0: 0x | wait_event Sep 5 23:42:30 lila kernel: [ 1480.015978] iwlwifi :03:00.0: 0x0084 | l2p_control Sep 5 23:42:30 lila kernel: [ 1480.015980] iwlwifi :03:00.0: 0x00018030 | l2p_duration Sep 5 23:42:30 lila kernel: [ 1480.015982] iwlwifi :03:00.0: 0x000F | l2p_mhvalid Sep 5 23:42:30 lila kernel: [ 1480.015984] iwlwifi :03:00.0: 0x0085 | l2p_addr_match Sep 5 23:42:30 lila kernel: [ 1480.015986] iwlwifi :03:00.0: 0x0005 | lmpm_pmg_sel Sep 5 23:42:30 lila kernel: [ 1480.015988] iwlwifi :03:00.0: 0x14031202 | timestamp Sep 5 23:42:30 lila kernel: [ 1480.015990] iwlwifi :03:00.0: 0x5860 | flow_handler Sep 5 23:42:30 lila kernel: [ 1480.016016] iwlwifi :03:00.0: Fseq Registers: Sep 5 23:42:30 lila kernel: [ 1480.016033] iwlwifi :03:00.0: 0x | FSEQ_ERROR_CODE Sep 5 23:42:30 lila kernel: [ 1480.016049] iwlwifi :03:00.0: 0x
Bug#929675: mojolicious: HTTPS / SSL / TLS is broken
On Wed, 3 Jul 2019 09:49:14 +0100 Nick Morrott wrote: > On Sun, 23 Jun 2019 at 01:58, Nick Morrott wrote: > > > > > Upstream tried to help, but seems to be out of ideas: > > > > > > https://groups.google.com/forum/#!topic/mojolicious/gjz-0uvUDLk > > > > I have posted an update to that thread (currently held for > > moderation). I have also created an upstream PR [2] which provides a > > TLS 1.2-compliant keypair: > > > > [2] https://github.com/mojolicious/mojo/pull/1371 > > Upstream have now created a new TLS keypair which will be included in > the next Mojolicious release. > > My current plan is to review the update and upload a new 8.12 build > targetting the first Debian "buster" point release which includes the > updated keypair. Thank you! Celejar
Bug#929675: mojolicious: HTTPS / SSL / TLS is broken
Package: libmojolicious-perl Version: 8.12+dfsg-1 Severity: important File: mojolicious Tags: upstream Mojolicious's HTTPS functionality is completely broken on my system (ordinary HTTP access works fine): ~$ mojo daemon -l https://*:3000 Server available at https://127.0.0.1:3000 ~$ curl -v -k https://127.0.0.1:3000 * Expire in 0 ms for 6 (transfer 0x55d756de3dd0) * Trying 127.0.0.1... * TCP_NODELAY set * Expire in 200 ms for 4 (transfer 0x55d756de3dd0) * Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 127.0.0.1:3000 * Closing connection 0 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 127.0.0.1:3000 ~$ openssl s_client -connect localhost:3000 CONNECTED(0003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 283 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ~$ wget -v https://localhost:3000 --2019-05-21 11:17:27-- https://localhost:3000/ Resolving localhost (localhost)... ::1, 127.0.0.1 Connecting to localhost (localhost)|::1|:3000... failed: Connection refused. Connecting to localhost (localhost)|127.0.0.1|:3000... connected. GnuTLS: Error in the pull function. Unable to establish SSL connection. ~$ mojo get -k https://127.0.0.1:3000 SSL connect attempt failed at /usr/share/perl5/Mojolicious/Command/get.pm line 77. The above is with Debian's versions of all software. I also tried using locally installed, newer versions of IO::Socket::SSL, Net::SSLeay, and Mojolicious itself, but it still does not work. Upstream tried to help, but seems to be out of ideas: https://groups.google.com/forum/#!topic/mojolicious/gjz-0uvUDLk -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmojolicious-perl depends on: ii libjs-jquery 3.3.1~dfsg-3 ii libjs-prettify 2015.12.04+dfsg-1.1 pn libscalar-list-utils-perl ii perl 5.28.1-6 Versions of packages libmojolicious-perl recommends: pn libcpanel-json-xs-perl ii libev-perl 4.25-1 pn libio-socket-ip-perl pn libio-socket-socks-perl ii libio-socket-ssl-perl2.060-3 pn libmojo-server-fastcgi-perl ii librole-tiny-perl2.06-1 libmojolicious-perl suggests no packages. -- no debconf information
Bug#662960: ssmtp doesn't validate server TLS certificates
On Wed, 6 Mar 2019 04:11:41 +0100 Matija Nalis wrote: ... > I do agree completely with you that package should strongly indicate > in its docs and description about it's TLS deficiencies. If someone > would write such a documentation patch, perhaps it might have a > chance to be included. > > [ As a side note, even with certificate checking in place there are a > lot of problems in todays "zillion untrusted CAs which we trust > anyway" security model, and even more so if you move from web > world (where clients try to be secure, and even people might > sometimes check basic credentials) to unattended MTA world where > almost nobody does, and vast majority of MTAs will simply by > default silently downgrade to plaintext if they think anything > might be problematic with TLS support etc. ] Attached are some documentation suggestions (I didn't touch the manpage). Celejar ssmtp-doc Description: Binary data
Bug#917260: msmtp: hangs after message termination [.]
[Sorry, I didn't see this email until today.] On Fri, 4 Jan 2019 22:45:04 +0100 Martin Lambers wrote: > Hi, > > this only happens with the zoho SMTP server if your test mail has no > blank line that separates mail headers and mail body. > > Please try (for example) 'echo -e "test-header\n\ntest-body"' instead > of just 'echo "test"'; it should work fine. Yes, this works fine. > Explanation: if the mail-terminating "." line appears when the zoho > SMTP server thinks we are still in the mail headers, it will not > interpret it as end-of-data, and thus will wait for more data instead > of answering with "250 Message received". > > A mail that does not have the blank line separating headers and body is > malformed according to the RFCs, so one could argue that the zoho SMTP > server behavior is ok, but on the other hand it seems to be the only > SMTP server working this way and breaking the typical 'echo "test" > | ...' pattern... Thanks for the explanation! I'm not sure if I only discovered this problem when using the somewhat artificial 'echo "test"' sequence, or whether I ran into it in a real world scenario - in other words, in normal usage, will msmtp always have a newline between headers and body? > Best, > Martin Celejar
Bug#662960: ssmtp doesn't validate server TLS certificates
On Wed, 6 Mar 2019 04:11:41 +0100 Matija Nalis wrote: ... > "Severity: important" would indicate that package is just one small > step away from "rendering it completely unusable to everyone", which According to the documentation, "important" denotes: "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone." I would say that that misleading the user about certificate verification should be considered "a major effect on the usability of [the] package", but I think we've beat this horse to death, so I defer to your judgment. > looks too harsh to me in this case (as in many cases ssmtp is used > only for non-TLS plaintext SMTP delivery on LAN from satellite > machines to main MTA, which would then speak TLS to outside world > etc.) > > "Severity: wishlist" however (as opposed to "normal") subtly > indicates that there is some functionality that is *missing*, and > that someone needs to think it over and write it, and that it might > be a more complicated task and probably not an one-line-fix (and thus > it would probably left to upstream to fix it, as Debian maintainer in > most cases won't be fixing it h[im/er]self unless upstream is dead > and someone else provides a verified good patch). It also indicates > it might be due to design decisions, like here. > > I do agree completely with you that package should strongly indicate > in its docs and description about it's TLS deficiencies. If someone > would write such a documentation patch, perhaps it might have a > chance to be included. I'll try to write something and submit it here. > [ As a side note, even with certificate checking in place there are a > lot of problems in todays "zillion untrusted CAs which we trust > anyway" security model, and even more so if you move from web > world (where clients try to be secure, and even people might > sometimes check basic credentials) to unattended MTA world where > almost nobody does, and vast majority of MTAs will simply by > default silently downgrade to plaintext if they think anything > might be problematic with TLS support etc. ] Celejar
Bug#662960: ssmtp doesn't validate server TLS certificates
On Tue, 5 Mar 2019 23:26:58 +0100 Matija Nalis wrote: > Hi Celejar, > > you have raised severity to "serious" on ssmtp Debian package > in bug #662960, which is reserved for "Serious policy violations" as > described at https://www.debian.org/Bugs/Developer#severities > > It is customary to indicate exactly which section of Debian policy > Manual (at https://www.debian.org/doc/debian-policy/) the bug > breaks when setting "serious" severity. I concede that I was probably mistaken in raising the severity to "serious". I was probably just so aggravated at the package promising TLS support but silently failing to perform certificate validation that I conflated the normal English meaning of "serious" with its technical meaning in this context ;) > While I do agree that limitations of TLS implementation should be > prominently noted in package documentation and even description, I do > not think that even completely non-existent TLS support qualifies for > more than "important" severity (and more likely "normal" or > "wishlist"). I do stand by my position that this is at least an "important" bug. I agree that non-existent TLS support would be merely "wishlist" priority - but not if the package assured the user that it was providing TLS but silently failed to do so! Another email in this report argues: > Given its purpose - "extremely simple MTA [...]" - should this issue > really be considered "serious" (and Release Critical) ? Again, while I concede that this may not technically be RC, pointing to the software's self-description as an "extremely simple MTA [...]" misses the point: I have no problem with insecure software (I'm not filing any bugs against telnet ;)), only with software that assures the user of a certain level of security but does not provide it. > Unless someone objects with specific Debian policy section that this > package runs afoul, I'm going to revert its severity back to wishlist. Thank you for your work on Debian, and I apologize for my initial error. Celejar
Bug#823286: xserver-xorg-input-libinput: -libinput doesn't really 'essentially replace' -synaptics
Package: xserver-xorg-input-libinput Version: 0.28.2-1 Followup-For: Bug #823286 I tried removing xserver-xorg-input-synaptics, as suggested by the language in the xserver-xorg-input-libinput package description, and my trackpad behavior changed drastically, including losing vertical scrolling. I tried to get back the old behavior via the Xfce configuration tool,, but discovered that in my Xfce 'mouse and touchpad' settings, the whole touchpad section was missing (and, for some reason, the 'restore to defaults' button in the still existing 'buttons and feedback' section was grayed out and non-working). Reinstalling -synaptics (even while leaving -libinput) got me back the missing configuration section and the desired behavior. I don't think the -libinput package description should claim: It can handle keyboards, mice and touchpads, and essentially replaces the separate -evdev and -synaptics drivers. Or at the very least, it should clarify that some configuration tools may not work well with libinput, and major functionality may be lost by removing -synaptics. -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.7.0
Bug#919444: postfix: document real-world smarthost configuration
Package: postfix
Version: 3.3.2-1
Severity: normal
Tags: patch
Hi,
Debconf offers a 'satellite system' configuration option, where "All
mail is sent to another machine, called a 'smarthost', for delivery."
but this merely points Postfix toward the smarthost. With real-world,
third-party smarthosts, a number of other steps are required to make
this actually work, which are not explained to the user. I've included
a slightly Debian-centric guide to this configuration for inclusion with
the Postfix package, if deemed appropriate.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages postfix depends on:
ii adduser3.118
ii cpio 2.12+dfsg-6
ii debconf [debconf-2.0] 1.5.69
ii dpkg 1.19.2
ii e2fsprogs 1.44.5-1
ii libc6 2.28-5
ii libdb5.3 5.3.28+dfsg1-0.2
ii libicu63 63.1-5
ii libsasl2-2 2.1.27~rc8-1
ii libssl1.1 1.1.1a-1
ii lsb-base 10.2018112800
ii netbase5.5
ii ssl-cert 1.0.39
Versions of packages postfix recommends:
ii python3 3.7.1-3
Versions of packages postfix suggests:
pn dovecot-common
ii libsasl2-modules 2.1.27~rc8-1
ii mailutils [mail-reader] 1:3.5-2
pn postfix-cdb
ii postfix-doc 3.3.2-1
pn postfix-ldap
pn postfix-lmdb
pn postfix-mysql
ii postfix-pcre 3.3.2-1
pn postfix-pgsql
pn postfix-sqlite
pn procmail
ii resolvconf 1.79
ii sasl2-bin2.1.27~rc8-1
ii sylpheed [mail-reader] 3.7.0-4
pn ufw
-- debconf information excluded
Postfix can be configured to relay mail to a 'smarthost' for delivery. In
practice, with real world smarthosts, considerable configuration is required to
make this work. Some of this configuration can be done via debconf
('dpkg-reconfigure postfix'), but much of it will usually need to be done
manually. This document provides instructions for such configuration.
1. Set the smarthost
This can be set via debconf. To do it manually, add a line like the following
to /etc/postfix/main.cf:
relayhost = [relayhost.example.com]:465
If the port number is omitted, the default is 25. Most smarthosts use TLS/SSL,
and accordingly generally use either 465 or 587. Consult the smarthost's
documentation for the port used.
2. Enable TLS/SSL
As above, most smarthosts use TLS/SSL. To configure Postfix to use TLS, add the
following lines to main.cf:
smtp_tls_security_level = verify
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
If 'encrypt' is used instead of 'verify', the second line may be omitted, in
which case TLS will be used but Postfix will not verify the smarthost's
certificate, potentially allowing a man-in-the-middle attack and the stealing
of the smarthost authentication credentials. See postconf(5) for details.
If 'legacy' SMTPS (sometimes called 'SSL', usually used in conjunction with
port 465) is desired, add the following additional line to main.cf:
smtp_tls_wrappermode = yes
For STARTTLS (usually used in conjunction with port 587), omit this line (or
use the value 'no'). Consult the smarthost's documentation for the version of
TLS/SSL used.
3. Configure authentication
Most smarthosts require authentication. To enable it, ensure that the package
'libsasl2-modules' is installed, and add the following lines to main.cf:
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
[See postconf(5) for more information about 'security options'. The above
version, with no options, is generally fine.]
To specify the authentication credentials, create an arbitrarily named file
(e.g., '/etc/postfix/example-passwd'), with appropriately restrictive
permissions (e.g., 600) containing a single line of the following form:
smtp.example.com usern...@example.com:secret_password
Where 'smtp.example.com' is the name of the smarthost, 'usern...@example.com'
is the login name, and 'secret_password' is the login password.
After creating the file, run the command:
postmap /etc/postfix/example.com-passwd
and add the following line to main.cf:
smtp_sasl_password_maps = hash:/etc/postfix/example-passwd
4. Address rewriting
Most smarthosts require that the sender (envelope FROM and perhaps also the
email From: header) be set to the user's correct mail address with the
smarthost. Postfix therefore needs to be configured to rewrite the sender
address accordingly. There are multiple ways to do this, including canonical
mapping an
Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'
On Mon, 14 Jan 2019 16:27:18 -0800 Jonathan Nieder wrote: > # missing Depends > severity 919296 serious > quit > > Celejar wrote: > >> Celejar wrote: > > >>> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per > >>> README.debian) fails with: > >>> > >>> warning: git-daemon: unable to open supervise/ok: file does not exist > [...] > > ii runit 2.1.2-22 amd64system-wide service supervision > > ii runit-helper 2.7.3all dh-sysuser implementation > > detail > > un runit-init (no description available) > > un runit-systemd(no description available) > > un runit-sysv (no description available) > > > > I don't install recommends by default, and I do run into trouble > > sometimes because of that ;). Should I try installing one of them to see > > if that solves the problem? > > Yes, please. Please install runit-systemd and then run > "dpkg-reconfigure git-daemon-run". Okay, I've installed runit-systemd: ~# dpkg-reconfigure git-daemon-run Service git-daemon already added. warning: git-daemon: unable to open supervise/ok: file does not exist > If I'm lucky then that will get it working. I'll try to reproduce it > here and set the right dependencies. Sorry :/ Again, thanks for the help. I'm likely doing something basic wrong, so thanks for bearing with me. > It appears that runit-sysv depends on sysvinit-core, which conflicts > with systemd-sysv, so adding a Depends by git-daemon-run on > 'runit-init | runit-systemd | runit-sysv' should do the trick. I'll > experiment. > > Thanks, > Jonathan Celejar
Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'
On Mon, 14 Jan 2019 13:26:37 -0800 Jonathan Nieder wrote: > Hi again, > > Celejar wrote: > > Severity: grave > > > > Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per > > README.debian) fails with: > > > > warning: git-daemon: unable to open supervise/ok: file does not exist > [...] > > Versions of packages git-daemon-run depends on: > > ii adduser 3.118 > > ii git 1:2.20.1-1 > > ii runit2.1.2-22 > > What is the output of "dpkg -l runit*"? In particular, do you have > runit-sysv or runit-systemd installed? ~# dpkg -l runit* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii runit 2.1.2-22 amd64system-wide service supervision ii runit-helper 2.7.3all dh-sysuser implementation detail un runit-init (no description available) un runit-systemd(no description available) un runit-sysv (no description available) I don't install recommends by default, and I do run into trouble sometimes because of that ;). Should I try installing one of them to see if that solves the problem? Celejar
Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'
Package: git-daemon-run Version: 1:2.20.1+next.20190104-1 Severity: grave Justification: renders package unusable Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per README.debian) fails with: warning: git-daemon: unable to open supervise/ok: file does not exist I see that there's an old, archived bug about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570094 But I'm getting the same thing on my uptodate Sid system (and even on another Sid system with the version of the package from experimental installed). I know nothing about runit, so perhaps I'm doing something obvious wrong, but I'm just trying to follow the directions from the README, and getting this. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-daemon-run depends on: ii adduser 3.118 ii git 1:2.20.1-1 ii runit2.1.2-22 git-daemon-run recommends no packages. git-daemon-run suggests no packages. -- no debconf information
Bug#917932: dma: no support for PLAIN authentication
Package: dma Version: 0.11-1+b1 Severity: important Tags: upstream Hi, I'm trying to use dma to send mail via Zoho.com (smtp.zoho.com), but it fails with: smarthost authentication: AUTH cram-md5 not available: 501 Could not do Unknown Authentication Apparently, dma doesn't support PLAIN authentication, and Zoho doesn't offer any authentication protocol that it does support. There's an issue about this upstream: https://github.com/corecode/dma/issues/50 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dma depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.28-4 ii libssl1.1 1.1.1a-1 ii ucf3.0038+nmu1 dma recommends no packages. dma suggests no packages. -- Configuration Files: /etc/dma/auth.conf [Errno 13] Permission denied: '/etc/dma/auth.conf' -- debconf information excluded
Bug#915366: perlfaq4: the section on indented here documents should mention the ~ modifier
On Thu, 6 Dec 2018 23:04:50 + Dominic Hargreaves wrote: > On Sun, Dec 02, 2018 at 11:17:47PM -0500, Celejar wrote: > > perlfaq4 has a question "Why don't my < > of the answer deals with ways to write indented here documents. These > > are largely kludges, however, and the faq should really mention the ~ > > modifier (desribed in perlop), which was introduced precisely in order > > to provide a clean way to do this. > > Hi, > > Thanks for pointing this out. Would you be able to contribute > a suggested text (either as a diff, or otherwise) for this that > we can forward upstream? Sorry for the delay - Gmail has been leaving some of my Debian mail in the spam folder lately. I'm not sure that I feel comfortable making significant revisions to the whole FAQ answer - I'm not much of a Perl guru - so I'm just going to supply a paragraph that can be added to the end of "Why don't my < Cheers, > Dominic. Thanks, Celejar
Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup
On Fri, 28 Dec 2018 12:00:14 +0100 Michael Biebl wrote: > Am 28.12.18 um 07:04 schrieb Ben Hutchings: > > > And if you downgrade udev and libudev1 to version 239-15, that will > > trigger an update of the 4.19 initramfs (only) and you should then be > > able to boot with Linux 4.19. > > Or upgrade to udev 240-2, which should fix this issue. I'm on 240-2 now, and the issue does indeed seem to be fixed. Thanks much to both of you! Celejar
Bug#917559: msmtp: fails to verify TLS certificate when the mail host is not the CN but only a SAN
Package: msmtp Version: 1.6.7-1 Severity: important Hi, I've been using msmtp for years with a GMX mail account. Recently, I tried to use it with the mail server provided by a webhost of mine, but msmtp fails to verify the TLS certificate: msmtp: TLS certificate verification failed: the certificate owner does not match hostname mail.bdld.info It seems that the problem is that the supplied certificate for mail.bdld.info has bdld.info as the CN. But since mail.bdld.info is in the list of SANs, the verification should succeed. Indeed, 'openssl s_client -connect mail.bdld.info:465' reports "Verification: OK", and swaks successfully sends mail through the server. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages msmtp depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.28-3 ii libgnutls303.6.5-2 ii libgsasl7 1.8.0-8+b2 ii ucf3.0038+nmu1 Versions of packages msmtp recommends: ii ca-certificates 20180409 Versions of packages msmtp suggests: ii msmtp-mta 1.6.7-1 -- debconf information excluded
Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup
On Wed, 26 Dec 2018 15:39:19 + Ben Hutchings wrote: > On Tue, Dec 25, 2018 at 09:58:33PM -0500, Celejar wrote: > > On Tue, 25 Dec 2018 20:52:46 + > > Ben Hutchings wrote: > > > > > Control: reassign -1 udev 240-1 > > > Control: forcemerge 917124 -1 > > > > > > This seems to be a bug in udev, not the kernel. You will only have > > > noticed it once you rebooted for the kernel upgrade. > > > > Nope - in my system's current state, when rebooting into 4.19 there's > > no /dev/mapper symlink, but when rebooting into 4.18 there is. I've > > gone back and forth several times, and the behavior is consistent. > > There's clearly something that 4.19 is doing differently from 4.18. [I > > guess it might still be a udev bug, which is being exposed by some > > change in 4.19.] > > This is probably because the initramfs for 4.18 contains the old > version of udev. Okay, I think I understand. So if I were to update the 4.18 initramfs (with update-initramfs -k 4.18-nnn) now, I would expect to see the same problem with that kernel? Celejar
Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup
On Tue, 25 Dec 2018 20:52:46 + Ben Hutchings wrote: > Control: reassign -1 udev 240-1 > Control: forcemerge 917124 -1 > > This seems to be a bug in udev, not the kernel. You will only have > noticed it once you rebooted for the kernel upgrade. Nope - in my system's current state, when rebooting into 4.19 there's no /dev/mapper symlink, but when rebooting into 4.18 there is. I've gone back and forth several times, and the behavior is consistent. There's clearly something that 4.19 is doing differently from 4.18. [I guess it might still be a udev bug, which is being exposed by some change in 4.19.] Celejar
Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup
Package: src:linux Version: 4.19.12-1 Severity: important Hi, [I'm not sure whether this is the right package to report against - feel free to reassign as appropriate.] I have / on a luks volume, mounted with dm-crypt (automatically, via /etc/fstab - /etc/crypttab). As recently as kernel 4.18.0-3, everything was normal. With 4.19.0-1, the volume mounts, and the system seems basically functional - but /dev/mapper is empty aside for 'control'! ~# ls -al /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Dec 23 23:32 . drwxr-xr-x 18 root root3340 Dec 23 23:32 .. crw--- 1 root root 10, 236 Dec 23 23:32 control 'mount' shows that the dm-crypt mount is actually present: ~# mount | grep sda /dev/mapper/sda2_crypt on / type ext4 (rw,relatime,errors=remount-ro) /dev/sda1 on /boot type ext4 (rw,relatime) ~# This situation causes update-initramfs to fail: ~# update-initramfs -u update-initramfs: Generating /boot/initrd.img-4.19.0-1-amd64 mkinitramfs: failed to determine device for / mkinitramfs: workaround is MODULES=most, check: grep -r MODULES /etc/initramfs-tools Error please report bug on initramfs-tools Include the output of 'mount' and 'cat /proc/mounts' update-initramfs: failed for /boot/initrd.img-4.19.0-1-amd64 with 1. ~# Which in turn is causing things like kernel updates to fail ... Running 'dmsetup mknodes' manually adds the proper symlink. Additionally, running cryptsetup on an additional encrypted luks volume results in the proper symlink creation for that volume. -- Package-specific info: ** Version: Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.12-1 (2018-12-22) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-1-amd64 root=UUID=db4c898d-57d7-4b0b-8dc1-c1622e451d68 ro quiet crashkernel=384M-:128M ** Tainted: WOE (12800) * Taint on warning. * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: LENOVO product_name: 20E2CTO1WW product_version: ThinkPad W550s chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N11ET42W (1.18 ) board_vendor: LENOVO board_name: 20E2CTO1WW board_version: SDK0J40705 WIN ** Loaded modules: cpuid ctr algif_skcipher af_alg ses enclosure scsi_transport_sas nft_chain_route_ipv4 xt_CHECKSUM nft_chain_nat_ipv4 ipt_MASQUERADE nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ipt_REJECT nf_reject_ipv4 nft_counter xt_tcpudp nft_compat tun bridge stp llc acpi_call(OE) btusb btrtl btbcm btintel bluetooth drbg ebtable_filter ebtables devlink ansi_cprng ecdh_generic nf_tables nfnetlink cpufreq_conservative cpufreq_userspace cpufreq_powersave ipmi_devintf ipmi_msghandler uas usb_storage nls_utf8 cifs ccm dns_resolver fscache snd_hda_codec_hdmi bbswitch(OE) arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp iwlmvm coretemp kvm_intel mac80211 iTCO_wdt kvm rtsx_pci_sdmmc mmc_core rtsx_pci_ms memstick iTCO_vendor_support wmi_bmof i915 irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate snd_hda_codec_realtek intel_uncore drm_kms_helper snd_hda_codec_generic intel_rapl_perf ehci_pci xhci_pci ehci_hcd iwlwifi xhci_hcd sg snd_hda_intel mei_me drm snd_hda_codec mei cfg80211 e1000e pcspkr snd_hda_core usbcore rtsx_pci joydev snd_hwdep snd_pcm i2c_i801 i2c_algo_bit usb_common lpc_ich thinkpad_acpi intel_pch_thermal snd_timer wmi nvram ac tpm_tis snd tpm_tis_core tpm soundcore rfkill rng_core battery video pcc_cpufreq button parport_pc ppdev lp parport sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb dm_crypt dm_mod sd_mod crc32c_intel ahci libahci aesni_intel libata aes_x86_64 crypto_simd cryptd scsi_mod psmouse glue_helper evdev serio_raw thermal -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.19.0-1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-2 ii linux-base 4.5 Versions of packages linux-image-4.19.0-1-amd64 recommends: ii apparmor 2.13.1-3+b1 ii firmware-linux-free 3.4 ii irqbalance 1.5.0-0.1 Versions of packages linux-image-4.19.0-1-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.02+dfsg1-9 pn linux-doc-4.19 Versions of packages linux-image-4.19.0-1-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x
Bug#917260: msmtp: hangs after message termination [.]
Package: msmtp Version: 1.6.7-1 Severity: important Hi, I've been successfully using msmtp for a while with a GMX account. I recently tried using it with a Zoho account, and it does not work: after transmitting the message and apparently sending ., it just hangs, and eventually dies: ~# echo "test" | msmtp -d -a default x...@gmail.com loaded system configuration file /etc/msmtprc ignoring user configuration file /root/.msmtprc: No such file or directory using account default from /etc/msmtprc host = smtp.zoho.com port = 465 proxy host = (not set) proxy port = 0 timeout = off protocol = smtp domain = localhost auth = choose user = x...@zoho.com password = * passwordeval = (not set) ntlmdomain = (not set) tls = on tls_starttls = off tls_trust_file = /etc/ssl/certs/ca-certificates.crt tls_crl_file = (not set) tls_fingerprint = (not set) tls_key_file = (not set) tls_cert_file = (not set) tls_certcheck = on tls_min_dh_prime_bits = (not set) tls_priorities = (not set) auto_from = off maildomain = (not set) from = x...@zoho.com add_missing_from_header = on add_missing_date_header = on remove_bcc_headers = on dsn_notify = (not set) dsn_return = (not set) logfile = (not set) syslog = LOG_MAIL aliases = (not set) reading recipients from the command line TLS certificate information: Owner: Common Name: *.zoho.com Issuer: Common Name: Thawte RSA CA 2018 Organization: DigiCert Inc Organizational unit: www.digicert.com Country: US Validity: Activation time: Thu 02 Aug 2018 08:00:00 PM EDT Expiration time: Thu 01 Oct 2020 08:00:00 AM EDT Fingerprints: SHA256: 6E:51:AA:92:96:77:6A:D8:04:D0:C8:6A:AB:7D:DB:F7:49:87:00:67:DB:BD:61:8D:77:A0:20:A5:94:31:A7:C3 SHA1 (deprecated): 8B:F7:EE:CF:D3:6A:FC:AB:CC:61:92:4E:87:E6:5E:B9:88:9D:B2:CC <-- 220 mx.zohomail.com SMTP Server ready December 24, 2018 7:19:35 PM PST --> EHLO localhost <-- 250-mx.zohomail.com Hello localhost <-- 250-AUTH LOGIN PLAIN <-- 250 SIZE 53477376 --> AUTH PLAIN <-- 235 Authentication Successful --> MAIL FROM: <-- 250 Sender OK --> RCPT TO: <-- 250 Recipient OK --> DATA <-- 354 Ok Send data ending with . --> From: x...@zoho.com --> Date: Mon, 24 Dec 2018 22:19:35 -0500 --> test --> . msmtp: the server sent an empty reply msmtp: could not send mail (account default from /etc/msmtprc) Sending via Zoho works fine with Sylpheed, or Swaks: ~$ swaks -t x...@gmail.com -f x...@zoho.com --protocol SSMTP -s smtp.zoho.com -a Username: x...@zoho.com Password: === Trying smtp.zoho.com:465... === Connected to smtp.zoho.com. === TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-SHA:256 === TLS no local certificate set === TLS peer DN="/CN=*.zoho.com" <~ 220 mx.zohomail.com SMTP Server ready December 24, 2018 7:08:53 PM PST ~> EHLO <~ 250-mx.zohomail.com Hello <~ 250-AUTH LOGIN PLAIN <~ 250 SIZE 53477376 ~> AUTH LOGIN <~ 334 ~> <~ 334 ~> <~ 235 Authentication Successful ~> MAIL FROM: <~ 250 Sender OK ~> RCPT TO: <~ 250 Recipient OK ~> DATA <~ 354 Ok Send data ending with . ~> Date: Mon, 24 Dec 2018 22:08:36 -0500 ~> To: x...@gmail.com ~> From: x...@zoho.com ~> Subject: test Mon, 24 Dec 2018 22:08:36 -0500 ~> Message-Id: ~> X-Mailer: swaks v20181104.0 jetmore.org/john/code/swaks/ ~> ~> This is a test mailing ~> ~> ~> . <~ 250 Message received ~> QUIT <~ 221 mx.zohomail.com closing connection === Connection closed with remote host. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages msmtp depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.28-3 ii libgnutls303.6.5-2 ii libgsasl7 1.8.0-8+b2 ii ucf3.0038+nmu1 Versions of packages msmtp recommends: ii ca-certificates 20180409 Versions of packages msmtp suggests: ii msmtp-mta 1.6.7-1 -- debconf information: msmtp/port: 587 msmtp/sysconfig: true msmtp/auto_from: true msmtp/tls: on /etc/ssl/certs/ca-certificates.crt msmtp/maildomain: * msmtp/host: mail.gmx.com
Bug#915366: perlfaq4: the section on indented here documents should mention the ~ modifier
Package: perl-doc Version: 5.28.1-1 Severity: normal perlfaq4 has a question "Why don't my <
Bug#915064: geany: syntax highlighting broken for Perl here-documents with ~ modifier
Package: geany Version: 1.33-1 Followup-For: Bug #915064 I realized that the problem stems from the fact that the ~ modifier to here documents is apparently relatively new to Perl. While the example code I provided runs fine on 5.28.1, it fails on 5.24.2 (the version in Stable). I suppose Scintilla syntax highlighting is lagging behind Perl development. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geany depends on: ii geany-common 1.33-1 ii libatk1.0-0 2.30.0-1 ii libc62.28-1 ii libcairo-gobject21.16.0-1 ii libcairo21.16.0-1 ii libfribidi0 1.0.5-3 ii libgcc1 1:8.2.0-10 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libgtk-3-0 3.24.1-2 ii libpango-1.0-0 1.42.4-4 ii libpangocairo-1.0-0 1.42.4-4 ii libstdc++6 8.2.0-10 geany recommends no packages. Versions of packages geany suggests: pn doc-base ii libvte9 1:0.28.2-5+b3 -- no debconf information
Bug#915064: geany: syntax highlighting broken for Perl here-documents with ~ modifier
Package: geany
Version: 1.33-1
Severity: normal
Dear Maintainer,
Syntax highlighting is broken for Perl here-documents with ~ modifier.
The parser apparently doesn't understand that the whitespace-prefixed delimiter
ends the quoted text, and continues to highlight the following text as
quoted.
For example, with the attached file, Geany continues to highlight the
keywords 'my', 'print', and 'exit', as well as the closing brace, in green,
as quoted text, despite the fact that the Perl interpreter correctly
interprets and runs the code.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages geany depends on:
ii geany-common 1.33-1
ii libatk1.0-0 2.30.0-1
ii libc62.27-8
ii libcairo-gobject21.16.0-1
ii libcairo21.16.0-1
ii libfribidi0 1.0.5-3
ii libgcc1 1:8.2.0-10
ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6
ii libglib2.0-0 2.58.1-2
ii libgtk-3-0 3.24.1-2
ii libpango-1.0-0 1.42.4-4
ii libpangocairo-1.0-0 1.42.4-4
ii libstdc++6 8.2.0-10
geany recommends no packages.
Versions of packages geany suggests:
pn doc-base
ii libvte9 1:0.28.2-5+b3
-- no debconf information
#!/usr/bin/perl -w
{
print <<~EOF;
some text
EOF
}
my $foo = "Done\n";
print $foo;
exit;
Bug#662960: ssmtp doesn't validate server TLS certificates
Package: ssmtp Version: 2.64-8+b2 Followup-For: Bug #662960 Dear Maintainer, I'm changing the severity of this bug to 'serious'. I apologize if this is presumptuous, but it seems to me that software that advertises TLS functionality but neglects to check the supplied certificates is seriously flawed. At the very least, the documentation should contain a Big Fat Warning that the TLS functionality is limited to encryption and does not include authentication of the server. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.95-lila (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ssmtp depends on: ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u3 ii libgnutls-openssl273.5.8-5+deb9u3 ssmtp recommends no packages. ssmtp suggests no packages. -- Configuration Files: /etc/logcheck/ignore.d.server/ssmtp [Errno 13] Permission denied: '/etc/logcheck/ignore.d.server/ssmtp' /etc/ssmtp/revaliases changed [not included] -- debconf information: ssmtp/overwriteconfig: true ssmtp/port: 25 ssmtp/root: postmaster ssmtp/mailname: ssmtp/mailhub: mail ssmtp/fromoverride: false ssmtp/hostname: ssmtp/rewritedomain:
Bug#895258: installation-reports: installer fails to report missing NIC firmware
Package: installation-reports Severity: important Tags: d-i Dear Maintainer, The installation went mostly okay, except that I spent a while quite frustrated with mysterious network configuration failures. I assumed that the problem was with my cabling or DHCP configuration, until it finally occurred to me to check the logs (with Alt+F4), where I discovered that my new R210 II's NICs [Broadcom Limited NetXtreme II BCM5716 Gigabit Ethernet (rev 20), driven by the bnx2 driver] required non-free firmware, which the installer could not provide. I am perfectly satisfied with the Debian policy to not include such firmware in the installer, but the user should be notified in this case, and not simply be provided with the almost useless message "Network configuration failure". The logs make the problem very clear, but the main installer screen doesn't provide even a hint about the real issue. Thanks, however, for the greatness that is Debian! -- Package-specific info: Boot method: usb flash drive Image version: 9.3, 9.4 netinstall images Date: Machine: Dell PowerEdge R210 II Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O ] Detect network card:[O ] Configure network: [E ] Detect CD: [O ] Load installer modules: [O ] Clock/timezone setup: [O ] User/password setup:[O ] Detect hard drives: [ O] Partition hard drives: [ O] Install base system:[ O] Install tasks: [ O] Install boot loader:[ O] Overall install:[ E] == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u3" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux alice 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller [8086:0108] (rev 09) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a4) lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation C202 Chipset Family LPC Controller [8086:1c52] (rev 04) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller [8086:1c02] (rev 04) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: 01:00.0 Ethernet controller [0200]: Broadcom Limited NetXtreme II BCM5716 Gigabit Ethernet [14e4:163b] (rev 20) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: Kernel driver in use: bnx2 lspci -knn: Kernel modules: bnx2 lspci -knn: 01:00.1 Ethernet controller [0200]: Broadcom Limited NetXtreme II BCM5716 Gigabit Ethernet [14e4:163b] (rev 20) lspci -knn: Subsystem: Dell Device [1028:04dd] lspci -knn: Kernel driver in use: bnx2 lspci -knn: Kernel modules: bnx2 lspci -knn: 02:03.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 [102b:0532] (rev 0a) lspci -knn: Subsystem: Dell Device [1028:04dd] usb-list: usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 4.9.0-6-amd64 ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 01 Device 02: EHCI Host Controller [8087:0024] usb-list:Level 01 Parent 01 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 01 Device 03: USB Composite Device-0 [062
Bug#869851: mupdf: screen tearing (regression?)
Package: mupdf Version: 1.9a+ds1-4 Severity: important I've been a happy user of mupdf in Jessie. I recently upgraded my system to Stretch, and now mupdf exhibits terrible screen tearing when paging through or resizing documents. Other pdf readers, such as evince and qpdfview, do not exhibit any tearing. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.38-lila (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mupdf depends on: ii libc62.24-11+deb9u1 ii libfreetype6 2.6.3-3.2 ii libharfbuzz0b1.4.2-1 ii libjbig2dec0 0.13-4.1 ii libjpeg62-turbo 1:1.5.1-2 ii libopenjp2-7 2.1.2-1.1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii zlib1g 1:1.2.8.dfsg-5 mupdf recommends no packages. Versions of packages mupdf suggests: pn mupdf-tools -- no debconf information
Bug#869849: upgrade-reports: Successful upgrade (Jessie->Stretch) on a W550s
Package: upgrade-reports Severity: normal I just performed a reasonably smooth and successful upgrade from Jessie to Stretch on a Lenovo W550. The system was previously mostly Jessie, with some stuff from backports, some packages from unstable, one or two from third party repositories, and perhaps some still left from deb-multimedia. The upgrade went smoothly. Deciding what to do about new configuration files is always difficult, and one doesn't always have that much patience during an upgrade, but I haven't seen any problems yet arising out of my choices (generally keep mine when I know I've made significant changes, otherwise allow installations of the new one). My new Stretch system did suffer from a bad bug in the chrony package that broke the whole ifupdown system: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868491 But this was easily fixed by manually downloading and installing the fixed version from unstable. I was a bit nonplussed when upon reboot I ended up in lightdm's login screen, rather than my usual VT - this is apparently because xfce4-session now recommends light-locker, which depends on lightdm. I use xscreensaver, but I learned a while ago that for security, I probably should be logging in via a dm rather than doing startx from a console (since X crashing or being shutdown could leave an attacker with a logged in console), so I decided to leave lightdm installed. The system did lockup shortly after the actual installation (while I was performing some post-installation housekeeping, purging removed packages, IIRC), but the problem has not recurred. I'm probably still in the process of finding kinks in the new system, and I'll report them here as I do, but on the whole, the upgrade went quite well. Thank you all for maintaing this great operating system! -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.38-lila (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#857330: bluefish: GTK+ Unicode input somewhat broken
Package: bluefish Version: 2.2.9-1+b1 Severity: normal Entering Unicode via the GTK+ mechanism of ctrl-shift-u fails when any of the hex digits are keyboard accelerators, as they are grabbed by the program in their accelerator capacity. E.g., trying to enter the RLM mark (U+200F) fails since ctrl-F is mapped to "Find". Additionally, even the basic ctrl-shift-u combination frequently does some really weird things with font scaling / zooming - the fonts of the text in the editor window often expand and contract erratically as I'm hitting the ctrl-shift-u combination. This is not consistent, and I don't know what is happening or what, exactly triggers it, but it happens frequently and is a pretty annoying breakage. -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.13-lila (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 Init: systemd (via /run/systemd/system) Versions of packages bluefish depends on: ii bluefish-data2.2.9-1 ii bluefish-plugins 2.2.9-1+b1 ii gvfs-backends1.22.2-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-18+deb8u7 ii libcairo-gobject21.14.0-2.1+deb8u2 ii libcairo21.14.0-2.1+deb8u2 ii libenchant1c2a 1.6.0-10.1 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5 ii libglib2.0-0 2.42.1-1+b1 ii libgtk-3-0 3.14.5-1+deb8u1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpython2.7 2.7.9-2+deb8u1 ii libxml2 2.9.1+dfsg1-5+deb8u4 bluefish recommends no packages. Versions of packages bluefish suggests: ii chromium [www-browser] 56.0.2924.76-1~deb8u1 pn csstidy pn dos2unix ii firefox [www-browser] 51.0.1-3~bpo80+1 ii libxml2-utils 2.9.1+dfsg1-5+deb8u4 ii links2 [www-browser]2.8-2+b3 pn php-codesniffer pn pylint pn tidy pn weblint-perl | weblint -- no debconf information
Bug#857328: jmtpfs: Can't create files on MTP device
Package: jmtpfs Version: 0.5-2 Severity: important My Zte Zmax Pro mounts fine with jmtpfs, and I can browse the device's filesystem, but no files can be created on the device: ~/mnt$ touch test touch: cannot touch ‘test’: Input/output error The same error occurs with any attempt to transfer a local file to the device. This occurs even when the phone's screen is unlocked. The underlying mtp functionality is working fine on my system - I was able to transfer a file to the device with mtp-sendfile. -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.13-lila (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 Init: systemd (via /run/systemd/system) Versions of packages jmtpfs depends on: ii fuse 2.9.3-15+deb8u2 ii libc6 2.19-18+deb8u7 ii libfuse2 2.9.3-15+deb8u2 ii libgcc1 1:4.9.2-10 ii libmagic1 1:5.22+15-2+deb8u3 ii libmtp9 1.1.10-1~bpo8+1 ii libstdc++64.9.2-10 ii libusb-1.0-0 2:1.0.19-1 jmtpfs recommends no packages. jmtpfs suggests no packages. -- no debconf information
Bug#851684: apt-cacher-ng: once again breaks apt-listbugs
Package: apt-cacher-ng Version: 0.9.1-1~bpo8+1 Severity: normal ~# aptitude Retrieving bug reports... 0% Fail Error retrieving bug reports from the server with the following error message: E: end of file reached It could be because your network is down, or because of broken proxy servers, or the BTS server itself is down. Check network configuration and try again Retry downloading bug information? [Y/n] n Continue the installation anyway? [y/N] E: Exiting with error E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (1) E: Failure running script /usr/sbin/apt-listbugs apt Failed to perform requested operation on package. Trying to recover: Press Return to continue. I've seen these: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453277 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775126 But they're both marked as fixed, the latter in 0.8.2-1, and I still have the problem with 0.9.1-1~bpo8+1 (jessie-backports). I don't currently have a testing or unstable distribution to test. -- Package-specific info: -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.17-lila (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 Init: systemd (via /run/systemd/system) Versions of packages apt-cacher-ng depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.27 ii init-system-helpers1.22 ii libbz2-1.0 1.0.6-7+b3 ii libc6 2.19-18+deb8u7 ii libgcc11:4.9.2-10 ii liblzma5 5.1.1alpha+20120614-2+b3 ii libssl1.0.01.0.1t-1+deb8u5 ii libstdc++6 4.9.2-10 ii libsystemd0215-17+deb8u6 ii libwrap0 7.6.q-25 ii zlib1g 1:1.2.8.dfsg-2+b1 apt-cacher-ng recommends no packages. Versions of packages apt-cacher-ng suggests: pn avahi-daemon pn doc-base ii libfuse2 2.9.3-15+deb8u2 -- Configuration Files: /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: u'/etc/apt-cacher-ng/security.conf' -- debconf information: apt-cacher-ng/cachedir: keep apt-cacher-ng/bindaddress: keep apt-cacher-ng/gentargetmode: No automated setup apt-cacher-ng/tunnelenable: false apt-cacher-ng/proxy: keep apt-cacher-ng/port: keep
Bug#684425: /usr/bin/conky: sensor monitoring is broken with recent kernels
Package: conky-std Followup-For: Bug #684425 I've been quite frustrated by this problem of non-persistent hwmon numbering breaking conky's sensor monitoring functionality. The 'net is full of people with similar problems (often with other software, such as fancontrol), but there does not appear to be any good solution. Klugdes proposed include tricks to manually force a specific module load order, giving up on conky's internal sensor-related objects and using text tools to process the output of 'sensors', and writing conditionals in .conkyrc, but none of these are satisfactory, and all implicitly concede that conky's internal sensor monitoring functionality is basically broken with respect to recent kernels. Here are some related bug reports / discussions: http://lm-sensors.lm-sensors.narkive.com/f8LZrwfZ/module-load-order-dependency https://bugzilla.redhat.com/show_bug.cgi?id=1340949 https://bbs.archlinux.org/viewtopic.php?id=80012 https://bbs.archlinux.org/viewtopic.php?id=63974 https://bbs.archlinux.org/viewtopic.php?id=144515 http://www.gossamer-threads.com/lists/linux/kernel/1917797 https://forums.gentoo.org/viewtopic-t-955576-start-0.html https://bugs.launchpad.net/ubuntu/+source/lm-sensors-3/+bug/576602 -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.15-lila (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 Init: systemd (via /run/systemd/system) Versions of packages conky-std depends on: ii libc6 2.19-18+deb8u6 ii libglib2.0-0 2.42.1-1+b1 ii libiw30 30~pre9-8 ii liblua5.1-0 5.1.5-7.1 ii libncurses5 5.9+20140913-1+b1 ii libtinfo5 5.9+20140913-1+b1 ii libx11-6 2:1.6.2-3 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxft2 2.3.2-1 conky-std recommends no packages. Versions of packages conky-std suggests: pn apcupsd pn audacious pn moc pn mpd pn xmms2 -- no debconf information
Bug#620105: gliv: Segmentation fault not while loading an image
Package: gliv Version: 1.9.7-2 Followup-For: Bug #620105 I'm also getting segfaults when opening gliv on a certain directory: $ gliv /media/wd-storage/images/ /media/wd-storage/images/VID_20160830_201544309.mp4: unknown extension /media/wd-storage/images/VID_20161121_083651899.mp4: unknown extension /media/wd-storage/images/VID_20161020_130906695.mp4: unknown extension /media/wd-storage/images/VID_20161020_124222333.mp4: unknown extension /media/wd-storage/images/VID_20161020_124658707.mp4: unknown extension /media/wd-storage/images/VID_20161117_194524695.mp4: unknown extension /media/wd-storage/images/VID_20161007_133446359.mp4: unknown extension /media/wd-storage/images/VID_20161117_194549577.mp4: unknown extension /media/wd-storage/images/VID_20160916_132902300.mp4: unknown extension /media/wd-storage/images/VID_20160927_180455254.mp4: unknown extension /media/wd-storage/images/VID_20161020_123225413.mp4: unknown extension /media/wd-storage/images/VID_20161014_165823281.mp4: unknown extension /media/wd-storage/images/VID_20161010_132201604.mp4: unknown extension /media/wd-storage/images/VID_20160916_133842020.mp4: unknown extension /media/wd-storage/images/VID_20160927_180516577.mp4: unknown extension Segmentation fault not while loading an image Segmentation fault -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.14-lila (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 Init: systemd (via /run/systemd/system) Versions of packages gliv depends on: ii libc6 2.19-18+deb8u6 ii libgdk-pixbuf2.0-02.31.1-2+deb8u5 ii libgl1-mesa-glx [libgl1] 10.3.2-1+deb8u1 ii libglib2.0-0 2.42.1-1+b1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libgtkglext1 1.2.0-3.2 ii libpango1.0-0 1.36.8-3 ii libx11-6 2:1.6.2-3 gliv recommends no packages. gliv suggests no packages. -- no debconf information
Bug#847299: tp-smapi-dkms: does not work with newer ThinkPads
Package: tp-smapi-dkms Version: 0.41-1 Severity: normal Dear Maintainer, I tried loading tp-smapi on my W550s - it doesn't work: root@lila:~# modprobe tp-smapi modprobe: ERROR: could not insert 'tp_smapi': No such device or address Apparently, tp-smapi doesn't work on Ivy Bridge or newer chipsets, according to various sources, including ThinkWiki: http://www.thinkwiki.org/wiki/Tp_smapi#Model-specific_status I suggest that this be documented, along with the suggestion that the user consider an acpi-call based solution, such as TLP (Debian packages tlp and acpi-call-dkms). -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.12 (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 Init: systemd (via /run/systemd/system) Versions of packages tp-smapi-dkms depends on: ii dkms 2.2.0.3-2 tp-smapi-dkms recommends no packages. tp-smapi-dkms suggests no packages. -- no debconf information
Bug#845277: undocumented need for large tmp directory when archiving large mailboxes
Package: archivemail
Version: 0.9.0-1.1
Severity: normal
archivemail fails on large mailboxes:
Traceback (most recent call last):
File "/usr/bin/archivemail", line 1951, in
main()
File "/usr/bin/archivemail", line 700, in main
archive(mailbox_path)
File "/usr/bin/archivemail", line 1133, in archive
_archive_dir(mailbox_name, "mh")
File "/usr/bin/archivemail", line 1266, in _archive_dir
archive.write(msg)
File "/usr/bin/archivemail", line 566, in write
self.mbox_file.write(body)
File "/usr/lib/python2.7/gzip.py", line 243, in write
self.fileobj.write( self.compress.compress(data) )
IOError: [Errno 28] No space left on device
This is despite the output directory ("-o some_directory") having plenty of
space. The problem is that archivemail constructs a temporary mailbox
containing all the messages to archive in the default temporary directory, and
will therefore fail if that directory is not large enough. I do not believe
this is documented in the program's documentation, and the program itself should
exit more gracefully and provide the user with a clearer explanation of the
problem. In any event, the solution is to use environment
variables to point archivemail toward a tmp directory with enough space, by
prefacing the call to archivemail with something like:
export TMPDIR=/some_dir
-- System Information:
Debian Release: 8.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.30-lizzie (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
Init: systemd (via /run/systemd/system)
Versions of packages archivemail depends on:
ii python 2.7.9-1
archivemail recommends no packages.
archivemail suggests no packages.
-- no debconf information
Bug#794881: My mistake
Hi, Really sorry for the noise - ERRNOCOFFEE - I had a typo in the key file names. Once again, sorry. Celejar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#794881: bogus reports of "Warning: can't find id_rsa; skipping"
Package: keychain Version: 2.7.1-1 Severity: important On my main, normal desktop linux system (recently upgraded to Jessie with systemd), keychain seems to work fine. On a little NAS box (Seagate Go FLex Net, running a very stripped down Debian install), it used to work fine under Wheezy, but I recently upgraded (reinstalled) to Jessie (using sysv as init), and now whatever I do, I get that "Warning ..." message. I've tried the `eval keychain --eval id_rsa`" syntax, the straightforward "keychain id_rsa" syntax, but I always get the same error. This is from a root account on the NAS box - I created a test normal user, and that seems to work fine. [On my normal box, both the normal and root users work fine.] Any way I can provide further debugging information? -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.19-lizzie (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 Init: systemd (via /run/systemd/system) Versions of packages keychain depends on: ii grep 2.20-4.1 ii openssh-client [ssh-client] 1:6.7p1-5 keychain recommends no packages. Versions of packages keychain suggests: ii gnupg-agent 2.0.26-6 ii ssh-askpass 1:1.2.4.1-9 -- 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#793438: opens in confused and inconsistent maximized / unmaximized state
Package: mupdf Version: 1.5-1+b2 Severity: normal I'm usinng Xfce4. mupdf opens unmaximized, but with its window decoration indicating it in maximized state (two overlapping windows). Hitting F10 leaves the window in unmaximized state, but changes the decoration to correctly show this (one window). Hitting F10 again does the correct thing (maximizes the window, and changes the decoration correctly to two overlapping windows). Subsequently, everything behaves correctly, with F10 toggling the window (and its decoration) between maximized and unmaximized states. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.19-lizzie (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 Init: systemd (via /run/systemd/system) Versions of packages mupdf depends on: ii libc62.19-18 ii libfreetype6 2.5.2-3 ii libjbig2dec0 0.11+20120125-1 ii libjpeg62-turbo 1:1.3.1-12 ii libopenjp2-7 2.1.0-2 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii zlib1g 1:1.2.8.dfsg-2+b1 mupdf recommends no packages. Versions of packages mupdf suggests: pn mupdf-tools -- 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#793317: Mute toggle mutes both Master and Speaker, but only unmutes Master
Package: alsa-utils Version: 1.0.28-1 Severity: normal Toggling mute (via my ThinkPad's hardware mute button, 'm' when Master is selected in alsamixer, or 'amixer set Master toggle') mutes both Master and Speaker, but unmuting (by any of the above three methodes) only unmutes Master, and Speaker must be unmuted separately. I recently upgraded from Wheezy to Jessie - the problem was not present before the upgrade. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.18-lizzie (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 Init: systemd (via /run/systemd/system) Versions of packages alsa-utils depends on: ii kmod18-3 ii libasound2 1.0.28-1 ii libc6 2.19-18 ii libncursesw55.9+20140913-1+b1 ii libsamplerate0 0.1.8-8 ii libtinfo5 5.9+20140913-1+b1 ii lsb-base4.1+Debian13+nmu1 ii whiptail0.52.17-1+b1 alsa-utils recommends no packages. 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#793175: successful upgrade, but with a number of bumps and bugs post-upgrade
Package: upgrade-reports Severity: normal I upgraded from Wheezy to Jessie using apt-get, following the instructions in the release notes. The upgrade worked, but I experienced a number of problems and bumps on the way, needed to fix various problems post-upgrade, and still haven't figured some out. 1) I use rungetty via inittab with the --autologin option; this seems to have stopped working (systemd related?) 2) xfce4-utils no longer exists in stable, so it was removed - and I lost xfrun4. Took a bit of sleuthing to find that what I now need is xfce4-appfinder. Perhaps some sort of transitional package should be established? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793073 . 3) I did the upgrade in X. At some point during the process, X terminated and I was dumped back at the console, and could have lost data. The notes are ambiguous on whether upgrading in an xterm is acceptable - they initially recommend a textmode virtual console, but subsequently imply that an xterm is fine as long as one isn't using a display manager (which I wasn't - startx from a virtual console). 4) I had to run several rounds of apt-get upgrade / dist-upgrade. A different kernel was required, and when I rebooted (somewhere in between apt-get runs), the system hung on starting bluetooth. The only way to continue the upgrade was by entering recovery mode and disabling the bluetooth service. 5) Various things I don't particularly want got installed (NetworkManager, PulseAudio). 6) On my old install, I had my ThinkPad mute button working properly. Now, it toggles both 'Master' and 'Speaker' off, but only toggles 'Master back on, requiring a manual toggling of 'Speaker'. 7) Iceweasel's used to look good under Wheezy. Many pages look quite ugly now (pixelated, jagged). I can't describe exactly which pages or fonts. There's probably more to say, but this is a start. Thanks much for all the hard work on Debian! -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.18-lizzie (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 Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793073: [Pkg-xfce-devel] Bug#793073: appfinder is created under other windows
On Tue, 21 Jul 2015 22:19:57 +0200 Yves-Alexis Perez wrote: > On mar., 2015-07-21 at 16:17 -0400, Celejar wrote: > > > xfrun4 from a terminal sure doesn't use startup notification. Use a > > > shortcut for that. > > > > Okay - I have Settings / Keyboard / Application Shortcuts restored to > > their defaults, where F2 triggers 'xfce4-appfinder --collapsed', > > and I'm seeing this behavior. What setting needs to be adjusted to > > invoke "startup notification"? > > Tick the adequately named “Use startup notification” checkbox in the > shorcut edit dialogs. Got it - seems to work now. Yes, the box is adequately named - but how to bring up the edit dialog is not. I had no idea the thing even existed. I had tried clicking and double clicking on the shortcut, but apparently only on the "Shortcut" field, which brings up the shortcut key selection, not the edit dialog. It is hardly clear to the user that something interesting and different happens when the "Command" field is double-clicked (nor does the documentation here http://docs.xfce.org/xfce/xfce4-settings/4.10/keyboard say anything about this). Some hint or button might be a good idea. Additionally, there's no explanation of what startup notification is, and why it might be important. In fact, the Xfce FAQ itself implies that all it does is cause an hourglass to be displayed while applications are loading: > What is the "use startup notification" option? > > If you select this option, the window manager will show an hourglass > while the program is loading. The startup notification libraries have > to be installed. They are probably available with your distribution. https://wiki.xfce.org/faq#panels Anyway, thanks much for the explanation, but I do think we need better documentation / better defaults. > Regards, > -- > Yves-Alexis Celejar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793073: [Pkg-xfce-devel] Bug#793073: appfinder is created under other windows
On Tue, 21 Jul 2015 21:49:39 +0200 Yves-Alexis Perez wrote: > On mar., 2015-07-21 at 10:50 -0400, Celejar wrote: > > Explain please? As I reported, the problem occurs even when simply > > typing "xfrun4" from a terminal. What should I check? > > xfrun4 from a terminal sure doesn't use startup notification. Use a > shortcut for that. Okay - I have Settings / Keyboard / Application Shortcuts restored to their defaults, where F2 triggers 'xfce4-appfinder --collapsed', and I'm seeing this behavior. What setting needs to be adjusted to invoke "startup notification"? Celejar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793073: [Pkg-xfce-devel] Bug#793073: appfinder is created under other windows
On Tue, 21 Jul 2015 08:01:04 +0200 Yves-Alexis Perez wrote: > On lun., 2015-07-20 at 22:59 -0400, Celejar wrote: > > > > Not sure whether this is a bug in xfwm4 or xfce4-appfinder. I just upgraded > > from Wheezy to Jessie, and I now find that the xfce4-appfinder (formerly > > xfrun4) window opens under other windows (whether opened with ' F2' or > > 'xfrun4' from a terminal). In fact, I first thought that something was > > broken > > and xfrun wasn't doing anything at all, until I realized that the window was > > indeed opening, just under other windows. This can't be right. > > Make sure the way you run it (either from a keyboard shortcut or from a > panel shortcut) uses startup notification. Explain please? As I reported, the problem occurs even when simply typing "xfrun4" from a terminal. What should I check? Celejar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793064: [pkg-dhcp-devel] Bug#793064: syntax error in dhclient-script
On Tue, 21 Jul 2015 08:56:20 +0200
Axel Beckert wrote:
...
> One of these lines from
> resolvconf-1.76.1/etc/dhcp/dhclient-enter-hooks.d/resolvconf look
> promising for this kind of issue:
>
> 28 if [ "$new_domain_name_servers" ] && [ "$new_domain_name" ] ; then
> 32 if [ "$new_domain_name_servers" ] && [ "$new_domain_search" ] ; then
> 40 [ ! "$interface" ] || echo -n "$R" | /sbin/resolvconf -a
> "${interface}.dhclient"
>
> One possibility I can imagine to cause such an issue would be if the
> DHCP server gives out strange values for either the domain name server
> list or the domains itself.
Here's the DHCP negotiation, captured with dhcpdump:
TIME: 2015-07-21 10:36:02.880
IP: 0.0.0.0 () > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 1fa8c813
SECS: 4
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: :00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER)
OPTION: 50 ( 4) Request IP address192.168.1.3
OPTION: 12 ( 6) Host name lizzie
OPTION: 55 ( 7) Parameter Request List 1 (Subnet mask)
28 (Broadcast address)
2 (Time offset)
3 (Routers)
15 (Domainname)
6 (DNS server)
12 (Host name)
---
TIME: 2015-07-21 10:36:04.168
IP: 192.168.1.1 () > 192.168.1.3 ()
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 1fa8c813
SECS: 4
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.1.3
SIADDR: 192.168.1.1
GIADDR: 0.0.0.0
CHADDR: :00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER)
OPTION: 54 ( 4) Server identifier 192.168.1.1
OPTION: 51 ( 4) IP address leasetime 86400 (24h)
OPTION: 1 ( 4) Subnet mask 255.255.255.0
OPTION: 28 ( 4) Broadcast address 192.168.1.255
OPTION: 2 ( 4) Time offset 0 ()
OPTION: 3 ( 4) Routers 192.168.1.1
OPTION: 15 ( 4) Domainnamehome
OPTION: 6 ( 4) DNS server192.168.1.1
OPTION: 12 ( 6) Host name lizzie
---
Anything out of the ordinary here?
Celejar
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
