Bug#1081252: [libell0] missing symbol breaks iwd
Can confirm that things are fixed with the updated iwd and libell0 packages today (2.21-1 and 0.69-2 respectively). Appreciate the quick action! I'll leave for maintainer to close, in consideration that possible action may still be warranted regarding bumping soname and properly transitioning.
Bug#1081252: [libell0] missing symbol breaks iwd
Package: libell0 Version: 0.69-1 Severity: critical I just updated my Sid install, wifi (iwd based) was broken afterwards. Found the following in journalctl indicating that the libell0 update was responsible. Booted a recovery disc and had to downgrade both libell0 and iwd to versions from testing, rebooted again and wifi is back. /usr/libexec/iwd: symbol lookup error: /usr/libexec/iwd: undefined symbol: l_genl_attr_next, version ELL_0.10 Second time in the past few weeks Sid has been critically broken due to such a symbol error. Perhaps we could benefit from some infrastructure that automatically checks for missing symbol issues when updated lib packages are uploaded and blocks them unless they have a suitable breaks statement.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Wed, 2024-05-29 at 18:58 +0200, Andreas Metzler wrote: > Hello, > > That is false dichotomy. data-loss will occur when people use /tmp or > /var/tmp for persistent data-storage because "This has (for a couple > of > years) worked on Debian systems" not because "This has (for a couple > of > years) worked on *this* *specific* Debian system.". > > cu Andreas I think you might be missing the point that this is the *DEFAULT* behaviour. You're free to override it. If you personally have no precious data in tmp storage to worry about then after upgrade you can simply tweak the config to enable the new behaviour, as I have done. I'm using Sid and after doing a little reading up on the topic yesterday after the upgrade I believe all that needed doing was to delete the /etc/tmpfiles.d/tmp.conf file, which as I understand it contains a simple override of the new behaviour defined in /usr/lib/tmpfiles.d/tmp.conf. FWIW I think Luca made a perfectly sensible choice here.
Bug#1071368: [gpgv] cmd-arg parse error with apt/aptitude update
On Sun, 2024-05-19 at 07:41 +0200, Andreas Metzler wrote: > Thanks for the quick reply. You have installed gpgv-from-sq which > diverts "our" gpgv. (I will check a little bit more and reassign to > apt.) Oh okay. I'd assumed that gpgv had dropped support for the argument either accidentally through a mistake with build args, or in a planned way that overlooked use by apt, I wasn't expecting some third party drop in to suddenly get installed with an imperfect emulation, I didn't even know there were alternative implementations available. I did notice the installation of the 'sq' packages but it happened as part of a normal upgrade, I didn't ask for them, and I assumed that it was just another splitting up of code to minimise attack surface after the recent high profile supply chain attack against ssh. So the 'sq' packages are actually a Rust-based alternative, that's great, big fan of Rust. However somehow it's gotten pulled in as a replacement now, without explicitly asking for it, when it's not actually fully ready for use as a replacement in Debian considering it's emulation is incomplete and it impacts something as critical as apt. Why did it get installed? Here's my apt log from early morning 2024-05- 17 having run `aptitude upgrade`: Install: gpgv-sq:amd64 (0.8.0-5, automatic), gpgv-from-sq:amd64 (0.8.0- 5, automatic), sq:amd64 (0.33.0-3, automatic) Upgrade: libwireshark17t64:amd64 (4.2.4-1, 4.2.5-1), libwireshark- data:amd64 (4.2.4-1, 4.2.5-1), udev:amd64 (256~rc2-1, 256~rc2-3), systemd-oomd:amd64 (256~rc2-1, 256~rc2-3), libgdk-pixbuf2.0-bin:amd64 (2.42.10+dfsg-3+b3, 2.42.12+dfsg-1), systemd-container:amd64 (256~rc2- 1, 256~rc2-3), libnss-myhostname:amd64 (256~rc2-1, 256~rc2-3), libpam- systemd:amd64 (256~rc2-1, 256~rc2-3), busybox:amd64 (1:1.36.1-6+b1, 1:1.36.1-7), gir1.2-gdkpixbuf-2.0:amd64 (2.42.10+dfsg-3+b3, 2.42.12+dfsg-1), python3-typing-extensions:amd64 (4.10.0-1, 4.11.0-1), libjavascriptcoregtk-4.1-0:amd64 (2.44.1-1+b1, 2.44.2-1), libsystemd0:amd64 (256~rc2-1, 256~rc2-3), gir1.2-javascriptcoregtk- 4.1:amd64 (2.44.1-1+b1, 2.44.2-1), python3-requests:amd64 (2.31.0+dfsg- 1, 2.31.0+dfsg-2), gir1.2-javascriptcoregtk-6.0:amd64 (2.44.1-1+b1, 2.44.2-1), libnss-systemd:amd64 (256~rc2-1, 256~rc2-3), gir1.2-webkit2- 4.1:amd64 (2.44.1-1+b1, 2.44.2-1), libgdk-pixbuf-2.0-0:amd64 (2.42.10+dfsg-3+b3, 2.42.12+dfsg-1), libjavascriptcoregtk-6.0-1:amd64 (2.44.1-1+b1, 2.44.2-1), libwiretap14t64:amd64 (4.2.4-1, 4.2.5-1), systemd:amd64 (256~rc2-1, 256~rc2-3), libudev1:amd64 (256~rc2-1, 256~rc2-3), libnss-mymachines:amd64 (256~rc2-1, 256~rc2-3), wireshark- common:amd64 (4.2.4-1, 4.2.5-1), gpgv:amd64 (2.2.43-3, 2.2.43-5), systemd-resolved:amd64 (256~rc2-1, 256~rc2-3), python3-numpy:amd64 (1:1.26.4+ds-8, 1:1.26.4+ds-9), libyuv0:amd64 (0.0.1888.20240509-3, 0.0.1888.20240509-4), libwebkit2gtk-4.1-0:amd64 (2.44.1-1+b1, 2.44.2- 1), libnss-resolve:amd64 (256~rc2-1, 256~rc2-3), libwsutil15t64:amd64 (4.2.4-1, 4.2.5-1), gir1.2-webkit-6.0:amd64 (2.44.1-1+b1, 2.44.2-1), libsystemd-shared:amd64 (256~rc2-1, 256~rc2-3), systemd-sysv:amd64 (256~rc2-1, 256~rc2-3), libwebkitgtk-6.0-4:amd64 (2.44.1-1+b1, 2.44.2- 1), wireshark:amd64 (4.2.4-1, 4.2.5-1), linux-libc-dev:amd64 (6.7.12-1, 6.8.9-1), libgdk-pixbuf2.0-common:amd64 (2.42.10+dfsg-3, 2.42.12+dfsg- 1) Having a quick look now at `gpgv-from-sq` and `gpgv-sq` in `aptitude - i`, I see nothing depending on the former, and only the former depends on the latter. There's also the `sq` package... I see `dpkg-dev` (which I have installed) lists `sq` as an alternative to a dependency on both `gpgv` and `gnupg`. Hmm. Ah, I recall that some gpg packages were held back from upgrade during this time. Only the `gpgv` package got upgraded in the above log. Only later in the day did the rest get upgraded: Install: linux-image-6.8.9-amd64:amd64 (6.8.9-1, automatic), linux- headers-6.8.9-common:amd64 (6.8.9-1, automatic), linux-kbuild- 6.8.9:amd64 (6.8.9-1, automatic), linux-headers-6.8.9-amd64:amd64 (6.8.9-1, automatic) Upgrade: gpg:amd64 (2.2.43-3, 2.2.43-6), linux-headers-amd64:amd64 (6.7.12-1, 6.8.9-1), gnupg:amd64 (2.2.43-3, 2.2.43-6), gpg-wks- server:amd64 (2.2.43-3, 2.2.43-6), gpg-agent:amd64 (2.2.43-3, 2.2.43- 6), linux-image-amd64:amd64 (6.7.12-1, 6.8.9-1), gpgv:amd64 (2.2.43-5, 2.2.43-6), gpgsm:amd64 (2.2.43-3, 2.2.43-6), dirmngr:amd64 (2.2.43-3, 2.2.43-6), 7zip:amd64 (24.05+dfsg-2, 24.05+dfsg-3), gnupg-utils:amd64 (2.2.43-3, 2.2.43-6), gnupg-l10n:amd64 (2.2.43-3, 2.2.43-6), gpg-wks- client:amd64 (2.2.43-3, 2.2.43-6), gpgconf:amd64 (2.2.43-3, 2.2.43-6), intel-microcode:amd64 (3.20240312.1, 3.20240514.1) So it seems that with some of the gpg packages held back, including `gnupg`, `aptitude upgrade` chose to pull in `sq` as a replacement. :/
Bug#1071368: [gpgv] cmd-arg parse error with apt/aptitude update
On Sat, 2024-05-18 at 16:24 +0200, Andreas Metzler wrote: > On 2024-05-17 Lyndon Brown wrote: > > Package: gpgv > > Version: 2.2.43-4 > > Severity: important > > > Since sometime last night I'm seeing an error as below when using > > `apt- > > get update` or `aptitude update`. I'm guessing wrt. the earliest > > affected version. I've no idea how important an issue this may be, > > so > > cautiously marking important. > [...] > > $ sudo aptitude update > > Hit https://deb.debian.org/debian sid InRelease > > Hit https://deb.debian.org/debian rc-buggy InRelease > > W: https://deb.debian.org/debian/dists/sid/InRelease: Unknown > > response from gpgv to --assert-pubkey-algo check: gpgv: error: > > Error parsing command-line arguments > [...] > > Hello, > > afaict that happens in apt-key, what does > > env LC_ALL=C.UTF-8 gpgv --assert-pubkey-algo > > output on your system? $ env LC_ALL=C.UTF-8 gpgv --assert-pubkey-algo gpgv: error: Error parsing command-line arguments gpgv: because: Unknown argument "assert-pubkey-algo"
Bug#1071368: [gpgv] cmd-arg parse error with apt/aptitude update
Package: gpgv Version: 2.2.43-4 Severity: important Since sometime last night I'm seeing an error as below when using `apt- get update` or `aptitude update`. I'm guessing wrt. the earliest affected version. I've no idea how important an issue this may be, so cautiously marking important. I'm running Sid. I typically update multiple times a day. I noticed that there were gpg package updates yesterday and today and the error message references gpgv, so I'm filing against gpgv. $ sudo aptitude update Hit https://deb.debian.org/debian sid InRelease Hit https://deb.debian.org/debian rc-buggy InRelease W: https://deb.debian.org/debian/dists/sid/InRelease: Unknown response from gpgv to --assert-pubkey-algo check: gpgv: error: Error parsing command-line arguments W: https://deb.debian.org/debian/dists/rc-buggy/InRelease: Unknown response from gpgv to --assert-pubkey-algo check: gpgv: error: Error parsing command-line arguments $ sudo apt-get update Hit:1 https://deb.debian.org/debian sid InRelease Hit:2 https://deb.debian.org/debian rc-buggy InRelease Reading package lists... Done W: https://deb.debian.org/debian/dists/sid/InRelease: Unknown response from gpgv to --assert-pubkey-algo check: gpgv: error: Error parsing command-line arguments W: https://deb.debian.org/debian/dists/rc-buggy/InRelease: Unknown response from gpgv to --assert-pubkey-algo check: gpgv: error: Error parsing command-line arguments
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
On Fri, 2023-12-22 at 11:08 +0900, Mike Hommey wrote: > Would you mind filing these issues upstream? > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Widget%3A%20Gtk > > Mike Okay, done!
Bug#1059242: [firefox] quick scrolling tab list instead now shows context menu
Note, "correct" behaviour is restored when run with MOZ_ENABLE_WAYLAND=0
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
On Fri, 2023-12-22 at 10:31 +0900, Mike Hommey wrote: > What happens if you run with MOZ_ENABLE_WAYLAND=0 ? > > Mike Back to normal. I can scroll the full list, and the list is no longer 100% of screen height, it's located just below the button and extends down just short of the bottom of the screen. I happened to noticed that this also makes bug #1059242 go away.
Bug#1059243: [evolution] touch action on message body does not change focus
Package: evolution Version: 3.50.2-1 I have a laptop with a touchscreen. It's annoyed me for some time now that if I touch the main message body control, it fails to switch focus. Touch works just fine on the other controls. I could just tab to body from subject when ready, or I could click, when my touchpad isn't being temperamental, but I find myself often wanting to just reach forward and tap the large message body area on the screen to switch focus to it, but I can't because it doesn't work. Touching the screen does work to move the cursor location within my message body text however. The lack of focus switching seems to be a bug or small oversight.
Bug#1059242: [firefox] quick scrolling tab list instead now shows context menu
Package: firefox Version: 121.0-0 I have a laptop with a touchscreen. With previous versions if I touched and held my finger on the left or right arrow buttons either side of the tab list to scroll through them, it would "quick scroll" (as opposed to a single press making one short scroll movement). Now when I try this with version 121 it just results in a context menu being displayed with options like 'new tab'. Perhaps this was a deliberate change rather than a bug, I don't know, but disappointing if so as I used this all the time.
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
Package: firefox Version: 121.0-0 Severity: important The vertical tab list (accessed via the 'down arrow' in the tab bar, to the right of the new tab '+' button) is now no longer working correctly for Hi-DPI as of version 121.0-1. I have many windows with many tabs. Previously with version 120 I had no problem scrolling the entire tab list. Now, depending upon which tab I have selected, I cannot scroll a certain number of tabs at the top and/or bottom of the list into view. Notably when trying to scroll to the very top/bottom I see the scrollbar going out of view beyond the limits of the screen height. I have a Hi-DPI screen set to 200% scaling. Experimenting, if I switch to 100% scaling then the problem goes away, being able to scroll the full list as previously (with the list drawn with 100% screen height regardless of whether the window is maximized or not). So it seems that a small regression was introduced.
Bug#1056559: [firefox] visible state of spellcheck lang checkboxes not toggling
package:firefox version: 120.0-1 I just tried switching spell-check language via the context menu on a textbox in a webpage, and I noticed an issue with the language checkboxes. The menu had two entries, UK English and US English, the wrong one was selected. I clicked on one to toggle it and nothing appeared to happen. Experimenting I've found that the state does change, it's just that the drawn state of the checkbox is not immediately updated as expected. Once you change the selected menu entry, either by moving the cursor or using the up/down keyboard keys, the checkbox is then redrawn to show its new state. It just fails to be redrawn whilst its menu entry remains selected. I also noticed that context menu checkboxes seem to not be responding to the spacebar in terms of toggling state. I checked the w3schools checkbox example and no issues with the behaviour of that, nor it seems the checkboxes within about:preferences. I can't think of a similar context menu example on my system to check against. Behaviour is the same whether I select Arc or Adwaita in the Gnome tweak tool. Reproduction: 1) Load slashdot.org 2) Right-click in the search box, top-right 3) Ensure 'check spelling' is enabled, otherwise enable it and retry 4) Select the 'languages' submenu 5) Try toggling the language checkboxes
Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout
On Wed, 2023-06-21 at 03:06 +0200, Michael Biebl wrote: > As a quick/temporary workaround, you can run > > ln -s /etc/default/keyboard /etc/vconsole.conf Indeed removing the the latter file and creating the suggested symlink works. Thanks. Should it be of interest to you, the `localectl` output before doing this was as follows: System Locale: LANG=en_GB.UTF-8 VC Keymap: uk X11 Layout: (unset) And after: System Locale: LANG=en_GB.UTF-8 VC Keymap: (unset) X11 Layout: gb X11 Model: pc105
Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout
package: src:systemd version: 253-3 severity: critical The latest package update (to unstable) has broken login keyboard- layout support. I'm marking this as critical due to the chaotic potential for locking many users out of their accounts / systems, some of whom unlike myself may have no clue what's wrong and how to get around it, if they can. I'm from the UK and my locale / keyboard-layout is setup accordingly. Systemd packages were updated from 252.11-1 to 253-3 today on my unstable/sid system. I happened to hit an OOM condition that killed my user session a little while after having installed these updates, kicking me back to the Gnome login screen. I tried to log back in but I couldn't. After many tries, confident I was typing in my password correctly, and rebooting having made no difference, I toggled the feature to see what I was typing and discovered that a certain special character was not matching what I typed. I was able to find a key with which to enter the correct symbol and thus was able to get back in. I presume it's defaulting to US layout for some reason. I checked out the updates that had been installed today and I then tried downgrading all of the systemd packages (listed below) to those from testing (252.11-1). This solves the problem. With 253-3 installed, if I lock my account it seems to be using the correct layout, but if I logout or reboot then it's using the wrong one. With the 252.11-1 downgrade everything uses the correct layout again. Reinstating 253-3 the problem is back, confirming that the problem relates to the upgrade of systemd packages. Apt package log (systemd only): Install: systemd-dev:amd64 (253-3, automatic) Upgrade: udev:amd64 (252.11-1, 253-3), systemd-container:amd64 (252.11- 1, 253-3), libnss-myhostname:amd64 (252.11-1, 253-3), libpam- systemd:amd64 (252.11-1, 253-3), libsystemd0:amd64 (252.11-1, 253-3), libudev-dev:amd64 (252.11-1, 253-3), systemd:amd64 (252.11-1, 253-3), libudev1:amd64 (252.11-1, 253-3), libnss-mymachines:amd64 (252.11-1, 253-3), libsystemd-shared:amd64 (252.11-1, 253-3), systemd-sysv:amd64 (252.11-1, 253-3), libsystemd-dev:amd64 (252.11-1, 253-3) Apt term log (systemd only): Preparing to unpack .../0-libnss-mymachines_253-3_amd64.deb ... Unpacking libnss-mymachines:amd64 (253-3) over (252.11-1) ... Preparing to unpack .../1-systemd-container_253-3_amd64.deb ... Unpacking systemd-container (253-3) over (252.11-1) ... Preparing to unpack .../2-systemd-oomd_253-3_amd64.deb ... Unpacking systemd-oomd (253-3) over (252.11-1) ... Preparing to unpack .../3-libpam-systemd_253-3_amd64.deb ... Unpacking libpam-systemd:amd64 (253-3) over (252.11-1) ... Preparing to unpack .../4-systemd_253-3_amd64.deb ... Unpacking systemd (253-3) over (252.11-1) ... Preparing to unpack .../5-libsystemd-shared_253-3_amd64.deb ... Unpacking libsystemd-shared:amd64 (253-3) over (252.11-1) ... Preparing to unpack .../6-libsystemd0_253-3_amd64.deb ... Unpacking libsystemd0:amd64 (253-3) over (252.11-1) ... Setting up libsystemd0:amd64 (253-3) ... Preparing to unpack .../archives/udev_253-3_amd64.deb ... Unpacking udev (253-3) over (252.11-1) ... Selecting previously unselected package systemd-dev. Preparing to unpack .../systemd-dev_253-3_all.deb ... Unpacking systemd-dev (253-3) ... Setting up systemd-dev (253-3) ... Setting up libsystemd-shared:amd64 (253-3) ... Setting up systemd (253-3) ... Installing new version of config file /etc/systemd/journald.conf ... Installing new version of config file /etc/systemd/system.conf ... Installing new version of config file /etc/systemd/user.conf ... Preparing to unpack .../systemd-sysv_253-3_amd64.deb ... Unpacking systemd-sysv (253-3) over (252.11-1) ... Preparing to unpack .../libsystemd-dev_253-3_amd64.deb ... Unpacking libsystemd-dev:amd64 (253-3) over (252.11-1) ... Preparing to unpack .../libudev-dev_253-3_amd64.deb ... Unpacking libudev-dev:amd64 (253-3) over (252.11-1) ... Preparing to unpack .../libudev1_253-3_amd64.deb ... Unpacking libudev1:amd64 (253-3) over (252.11-1) ... Setting up libudev1:amd64 (253-3) ... Preparing to unpack .../libnss-myhostname_253-3_amd64.deb ... Unpacking libnss-myhostname:amd64 (253-3) over (252.11-1) ... Setting up systemd-sysv (253-3) ... Setting up udev (253-3) ... Setting up libnss-myhostname:amd64 (253-3) ... Setting up libudev-dev:amd64 (253-3) ... Setting up systemd-container (253-3) ... Setting up libpam-systemd:amd64 (253-3) ... Setting up systemd-oomd (253-3) ... Setting up libsystemd-dev:amd64 (253-3) ... Setting up libnss-mymachines:amd64 (253-3) ... Processing triggers for initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.3.0-1-amd64 Processing triggers for libc-bin (2.36-9) ... Processing triggers for man-db (2.11.2-2) ... Processing triggers for dbus (1.14.8-1) ... I noticed that the systemd changelog for 253-rc2-1 states "make /etc/default/locale a symlink to /etc/locale.conf". With 253-3 installed I indeed have this symlink (with owner root:ro
Bug#964279: [deluge] TypeError: '>' not supported between instances of 'NoneType' and 'NoneType'
fixed 964279 2.1.1-1 thanks Hi, Thanks for taking this package on and updating it. I believe I meant journalctl, though you can also see it simply from running in a terminal. Having just updated to 2.1.x from experimental and running in a terminal, a whole ton of errors/warnings, including this one, that 2.0.x was generating, have now disappeared - yay! So yes, this can be closed. Thanks again. On Mon, 2023-02-20 at 09:13 +0100, Daniel Baumann wrote: > Hi Lyndon, > > thank you for your report. > > I didn't find any of these with deluge 2.1.1-1, in order to confirm > that > this is fixed - where exactly would I find these messages? > > Regards, > Daniel
Bug#1028099: [libtepl-6-2] package upgrade error
Package: libtepl-6-2
Version: 6.4.0-3
Severity: serious
Ran into an upgrade issue on Sid today. Seems libtepl-6-1 did not get
removed before trying to install libtepl-6-2, causing the libtepl-6-2
install to fail, and consequently cascading failures from there.
Output of first aptitude upgrade command:
```
$ sudo aptitude upgrade
Resolving dependencies...
The following NEW packages will be installed:
libtepl-6-2{a}
The following packages will be REMOVED:
libtepl-6-1{u}
The following packages will be upgraded:
gedit gedit-plugin-bookmarks gedit-plugin-bracket-completion
gedit-plugin-character-map
gedit-plugin-code-comment gedit-plugin-color-picker
gedit-plugin-color-schemer
gedit-plugin-draw-spaces gedit-plugin-git gedit-plugin-join-lines
gedit-plugin-multi-edit
gedit-plugin-session-saver gedit-plugin-smart-spaces gedit-plugin-synctex
gedit-plugin-terminal gedit-plugin-text-size gedit-plugin-word-completion
gedit-plugins-common gnustep-base-common gnustep-base-runtime imagemagick
imagemagick-6-common imagemagick-6.q16 libapache-pom-java libbcmail-java
libbcpkix-java
libbcprov-java libbcutil-java libgnustep-base1.28 libmagick++-6.q16-8
libmagickcore-6.q16-6
libmagickwand-6.q16-6
The following packages are RECOMMENDED but will NOT be installed:
libmagickcore-6.q16-6-extra
32 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 16.3 MB of archives. After unpacking 1,024 B will be freed.
Do you want to continue? [Y/n/?] y
Get: 1 https://deb.debian.org/debian sid/main amd64 libtepl-6-2 amd64 6.4.0-3
[122 kB]
Get: 2 https://deb.debian.org/debian sid/main amd64 gedit amd64 43.2-2+b1 [364
kB]
Get: 3 https://deb.debian.org/debian sid/main amd64 gedit-plugins-common amd64
43.1-1+b1 [293 kB]
Get: 4 https://deb.debian.org/debian sid/main amd64 gedit-plugin-draw-spaces
amd64 43.1-1+b1 [19.9 kB]
Get: 5 https://deb.debian.org/debian sid/main amd64 imagemagick-6-common all
8:6.9.11.60+dfsg-1.4 [165 kB]
Get: 6 https://deb.debian.org/debian sid/main amd64 libmagickcore-6.q16-6 amd64
8:6.9.11.60+dfsg-1.4 [1,780 kB]
Get: 7 https://deb.debian.org/debian sid/main amd64 libmagickwand-6.q16-6 amd64
8:6.9.11.60+dfsg-1.4 [407 kB]
Get: 8 https://deb.debian.org/debian sid/main amd64 gedit-plugin-bookmarks
amd64 43.1-1+b1 [30.6 kB]
Get: 9 https://deb.debian.org/debian sid/main amd64
gedit-plugin-bracket-completion amd64 43.1-1+b1 [17.9 kB]
Get: 10 https://deb.debian.org/debian sid/main amd64 gedit-plugin-character-map
amd64 43.1-1+b1 [21.1 kB]
Get: 11 https://deb.debian.org/debian sid/main amd64 gedit-plugin-code-comment
amd64 43.1-1+b1 [22.0 kB]
Get: 12 https://deb.debian.org/debian sid/main amd64 gedit-plugin-color-picker
amd64 43.1-1+b1 [22.4 kB]
Get: 13 https://deb.debian.org/debian sid/main amd64 gedit-plugin-color-schemer
amd64 43.1-1+b1 [18.9 kB]
Get: 14 https://deb.debian.org/debian sid/main amd64 gedit-plugin-git amd64
43.1-1+b1 [24.4 kB]
Get: 15 https://deb.debian.org/debian sid/main amd64 gedit-plugin-join-lines
amd64 43.1-1+b1 [22.1 kB]
Get: 16 https://deb.debian.org/debian sid/main amd64 gedit-plugin-multi-edit
amd64 43.1-1+b1 [28.4 kB]
Get: 17 https://deb.debian.org/debian sid/main amd64 gedit-plugin-session-saver
amd64 43.1-1+b1 [20.4 kB]
Get: 18 https://deb.debian.org/debian sid/main amd64 gedit-plugin-smart-spaces
amd64 43.1-1+b1 [10.7 kB]
Get: 19 https://deb.debian.org/debian sid/main amd64 gedit-plugin-synctex amd64
43.1-1+b1 [20.0 kB]
Get: 20 https://deb.debian.org/debian sid/main amd64 gedit-plugin-terminal
amd64 43.1-1+b1 [20.6 kB]
Get: 21 https://deb.debian.org/debian sid/main amd64 gedit-plugin-text-size
amd64 43.1-1+b1 [19.0 kB]
Get: 22 https://deb.debian.org/debian sid/main amd64
gedit-plugin-word-completion amd64 43.1-1+b1 [24.6 kB]
Get: 23 https://deb.debian.org/debian sid/main amd64 libgnustep-base1.28 amd64
1.28.1-2 [1,595 kB]
Get: 24 https://deb.debian.org/debian sid/main amd64 gnustep-base-runtime amd64
1.28.1-2 [445 kB]
Get: 25 https://deb.debian.org/debian sid/main amd64 gnustep-base-common all
1.28.1-2 [296 kB]
Get: 26 https://deb.debian.org/debian sid/main amd64 imagemagick-6.q16 amd64
8:6.9.11.60+dfsg-1.4 [338 kB]
Get: 27 https://deb.debian.org/debian sid/main amd64 imagemagick amd64
8:6.9.11.60+dfsg-1.4 [121 kB]
Get: 28 https://deb.debian.org/debian sid/main amd64 libapache-pom-java all
29-1 [5,340 B]
Get: 29 https://deb.debian.org/debian sid/main amd64 libbcprov-java all 1.72-2
[8,225 kB]
Get: 30 https://deb.debian.org/debian sid/main amd64 libbcutil-java all 1.72-2
[580 kB]
Get: 31 https://deb.debian.org/debian sid/main amd64 libbcpkix-java all 1.72-2
[856 kB]
Get: 32 https://deb.debian.org/debian sid/main amd64 libbcmail-java all 1.72-2
[149 kB]
Get: 33 https://deb.debian.org/debian sid/main amd64 libmagick++-6.q16-8 amd64
8:6.9.11.60+dfsg-1.4 [242 kB]
Fetched 16.3 MB in 12s (1,351 kB/s)
Bug#1026291: [deluge] please update
Package: deluge Version: 2.0.3-3.2 Please update. It's been a year since 2.0.4 and 2.0.5 were released, and since then there's also been 2.1.0 and 2.1.1 a few months ago.
Bug#1026241: [python3-cryptography] new version breaks deluge
Package: python3-cryptography Version: 38.0.4-1 Severity: important Please be aware that the new version breaks deluge, see bug #1026240. Presumably needs the deluge maintainer to just update the packaged version rather than a bug fix being needed on this package. (Deluge is at v2.0.3; there's been 2.0.4, 2.0.5, 2.1.0 and 2.1.1 since). Filing this bug primarily to raise awareness.
Bug#1026240: Acknowledgement ([deluge] crashes on load)
Downgrading python3-cryptography from 38.0.4-1 to 3.4.8-2 is a temporary workaround.
Bug#1026240: [deluge] crashes on load
Package: deluge
Version: 2.0.3-3.2
Severity: grave
Worked yesterday, now won't start.
Loading in a terminal reveals the following output:
Traceback (most recent call last):
File "/usr/bin/deluge", line 33, in
sys.exit(load_entry_point('deluge==2.0.3', 'gui_scripts', 'deluge')())
File "/usr/lib/python3/dist-packages/deluge/ui/ui_entry.py", line 143, in
start_ui
ui.start()
File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/__init__.py", line 43, in
start
from .gtkui import GtkUI
File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/gtkui.py", line 27, in
from twisted.internet import defer, gtk3reactor
File "/usr/lib/python3/dist-packages/twisted/internet/gtk3reactor.py", line
22, in
from twisted.internet import gireactor
File "/usr/lib/python3/dist-packages/twisted/internet/gireactor.py", line 27,
in
from twisted.internet import _glibbase
File "/usr/lib/python3/dist-packages/twisted/internet/_glibbase.py", line 19,
in
from twisted.internet import base, posixbase, selectreactor
File "/usr/lib/python3/dist-packages/twisted/internet/posixbase.py", line 19,
in
from twisted.internet import error, tcp, udp
File "/usr/lib/python3/dist-packages/twisted/internet/tcp.py", line 38, in
from twisted.internet._newtls import (
File "/usr/lib/python3/dist-packages/twisted/internet/_newtls.py", line 18,
in
from twisted.protocols.tls import TLSMemoryBIOFactory, TLSMemoryBIOProtocol
File "/usr/lib/python3/dist-packages/twisted/protocols/tls.py", line 50, in
Connection(Context(TLSv1_METHOD), None)
File "/usr/lib/python3/dist-packages/OpenSSL/SSL.py", line 674, in __init__
res = _lib.SSL_CTX_set_ecdh_auto(context, 1)
AttributeError: module 'lib' has no attribute 'SSL_CTX_set_ecdh_auto'
Bug#1025347: [iwd] hidden network connection failures without rebooting things
package: iwd version: 2.0-1 I reported the first issue I encountered trying to switch to iwd v2.0 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025345 (iwd service not starting after installation). Continuing... With a reboot having fixed the issue starting the iwd service, I was still not connected to wifi, so I opened gnome's wifi settings. It was now giving me a list of access points again, and mine was listed, but connecting failed every time I tried to select it. I then deleted and recreated the access point (a hidden type as previously mentioned), having remembered having needed to do this last time I tried iwd. This made no difference. I then toggled wifi on/off and immediately it tried auto-connecting and was successful. WTH, why was that necessary. It then worked just fine for the next X number of hours until I shut down my laptop for the night. The router remained on. Coming back to it today, router still on, I turned on my laptop, and no auto-connected wifi. I went into gnome wifi settings and selected the access point, but it failed to connect, over and over. I tried toggling wifi on/off like before, but no difference. It just outright refused to connect. I then turned off and restarted the router. Laptop still refused to connect. I then rebooted the laptop, and then it worked. WTH. This is reminiscent of my troubles last time. I'd hoped that they'd have fixed this by now. :/ Btw, I'm now using an Intel wifi module. At some point in the past I'd had a different brand's, but I can't remember which of the two I was using the last time I tried iwd. The following is a chunk of journalctl output from when the laptop was refusing to connect today: Dec 02 19:02:28 debian1 kernel: iwlwifi :3a:00.0: Not associated and the session protection is over already... Dec 02 19:02:28 debian1 kernel: wlan0: Connection to AP 8c: lost Dec 02 19:02:28 debian1 kernel: wlan0: send auth to 8c: (try 2/3) Dec 02 19:02:29 debian1 kernel: iwlwifi :3a:00.0: Not associated and the session protection is over already... Dec 02 19:02:29 debian1 kernel: wlan0: Connection to AP 8c: lost Dec 02 19:02:29 debian1 kernel: wlan0: send auth to 8c: (try 3/3) Dec 02 19:02:30 debian1 kernel: iwlwifi :3a:00.0: Not associated and the session protection is over already... Dec 02 19:02:30 debian1 kernel: wlan0: Connection to AP 8c: lost Dec 02 19:02:30 debian1 kernel: wlan0: authentication with 8c: timed out Dec 02 19:02:30 debian1 iwd[818]: connect event timed out, reason=2 Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7101] device (wlan0): Activation: (wifi) Network.Connect failed: GDBus.Error:net.connman.iwd.Failed: Operation failed Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7107] device (wlan0): state change: config -> failed (reason 'no-secrets', sys-iface-state: 'managed') Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7121] manager: NetworkManager state is now CONNECTED_LOCAL Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7133] device (wlan0): Activation: failed for connection '' Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7136] device (wlan0): new IWD device state is disconnected Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7149] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Dec 02 19:02:38 debian1 sudo[2919]:: TTY=pts/0 ; PWD=/home/ ; USER=root ; COMMAND=/usr/bin/journalctl -n100 Dec 02 19:02:38 debian1 sudo[2919]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000) Dec 02 19:05:01 debian1 CRON[2939]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0) Dec 02 19:05:01 debian1 CRON[2940]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 02 19:05:01 debian1 CRON[2939]: pam_unix(cron:session): session closed for user root Dec 02 19:07:42 debian1 sudo[2919]: pam_unix(sudo:session): session closed for user root Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5780] device (wlan0): Activation: starting connection '' () Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5781] audit: op="connection-activate" uuid="" name="" pid=2800 uid=1000 result="> Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5782] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5785] manager: NetworkManager state is now CONNECTING Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5787] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5860] device (wlan0): new IWD device state is connecting Dec 02 19:07:45 debian1 kernel: wlan0: authenticate with 8c: Dec 02 19:07:45 debian1 kernel: wlan0: bad VHT capabilities, disabling VHT Dec 02 19:07:45 debian1 kernel: wlan0: Invalid HE e
Bug#1025345: [iwd] service would not start after installation until after restart
package: iwd version: 2.0-1 I thought I'd give iwd another go with the newly released version 2.0. It's been quite some time since I last tried it, having previously encountered issues relating to my hidden network that resulted in switching back to wpa_spplicant. My network is still hidden, which I may change at some point, but it is what it is for now. FYI I have a WPA2-based ISP supplied router. So last night, after the v2.0 update hit upstable, I made the switch by: 1) Installing iwd (plus a few updates) 2) Creating the /etc/NetworkManager/conf.d/iwd.conf file with the following contents: [device] wifi.backend=iwd 3) Disabling wpa_supplicant, initially with `sudo systemctl mask wpa_supplicant` following some old notes, before undoing this and doing the following instead: sudo systemctl stop NetworkManager sudo systemctl disable --now wpa_supplicant sudo systemctl restart NetworkManager Having done this I opened up gnome wifi settings and was faced with an empty access point list and a spinning activity indicator. The problem turned out to be that the iwd service was failing to start. Trying to get it started with a manual `systemctl start` command failed. Toggling wifi on/off made no difference. I couldn't see any indication of what was wrong in dmesg or journalctl, so I tried a reboot. The iwd service started successfully upon rebooting. Is it expected that switching over to iwd like this can't work without a reboot, or is there a bug?
Bug#1021140: vlc: No video when "Integrate video in interface" is enabled
>From the log, this looks to be a duplicate of #1021032.
Bug#1021032: vlc: playing mp4 videos results in a black screen
On Mon, 03 Oct 2022 03:07:30 +0100 Lyndon Brown wrote: > I have no idea at this time what the relevant difference is between > them that's causing this. Update. So first of all I wondered whether differences in configure options could be relevant. Before, I'd just used --disable-skins2. So I rebuilt the upstream codebase with the following to duplicate much of the debian package config: ../configure --disable-skins2 --config-cache -- disable-update-check --enable-fast-install --enable-a52 --enable-aa -- enable-aribsub --enable-avahi --enable-bluray --enable-caca --enable- chromaprint --enable-chromecast --enable-dav1d --enable-dbus --enable- dca --enable-dvbpsi --enable-dvdnav --enable-faad --enable-flac -- enable-fluidsynth --enable-freetype --enable-fribidi --enable-gles2 -- enable-gnutls --enable-harfbuzz --enable-jack --enable-kate --enable- libass --enable-libmpeg2 --enable-libxml2 --enable-lirc --enable-mad -- enable-matroska --enable-mod --enable-mpc --enable-mpg123 --enable-mtp --enable-ncurses --enable-notify --enable-ogg --enable-opus --enable- pulse --enable-qt --enable-realrtsp --enable-samplerate --enable-sdl- image --enable-sftp --enable-shine --enable-shout --enable-skins2 -- enable-sndio --enable-soxr --enable-spatialaudio --enable-speex -- enable-srt --enable-svg --enable-svgdec --enable-taglib --enable-theora --enable-twolame --enable-upnp --enable-vdpau --enable-vnc --enable- vorbis --enable-x264 --enable-x265 --enable-zvbi --disable-aom -- disable-crystalhd --disable-d3d11va --disable-decklink --disable- directx --disable-dsm --disable-dxva2 --disable-fdkaac --disable- fluidlite --disable-freerdp --disable-goom --disable-gst-decode -- disable-libtar --disable-libva --disable-live555 --disable-macosx -- disable-macosx-avfoundation --disable-macosx-qtkit --disable-mfx -- disable-microdns --disable-opencv --disable-projectm --disable- schroedinger --disable-sparkle --disable-telx --disable-vpx --disable- vsxu --disable-wasapi This made no difference; it still worked fine unlike the debian package rebuild. So then I wondered about the possible affect of old artefacts within the build directory of the upstream code build. (It wasn't clean, since I'd previously used it for VLC dev work). Interestingly, deleting the build directory to create a fresh start DID make a difference. Using the same big configure command as above I now encounter the same issue as the debian package. This obviously might suggest that the "dirty" build directory contained a plugin binary from a previous build and this was causing some difference. I wondered about your use of --disable-libva and so with that removed from the above configure command, it was back to working again. So long story short, the problem would seem to be connected somehow to your use of --disable-libva.
Bug#1021032: vlc: playing mp4 videos results in a black screen
On Mon, 03 Oct 2022 00:52:41 +0100 Lyndon Brown wrote: > On Mon, 2022-10-03 at 01:24 +0200, Sebastian Ramacher wrote: > > On 2022-10-03 00:09:25 +0100, Lyndon Brown wrote: > > > As you can see, mostly minor Qt updates. > > > > But those are the only packages relevant for vlc in your upgrade. So > > it's probably Qt breaking vlc … and my test with 3.0.18 rc2 just > > worked > > as I built it with the current Qt version in unstable. > > > > Cheers > > Indeed, that's what I'm wondering. > > Note that in the Ubuntu bug report > (https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1991418) Remi said > that he could see the problem in Sid, but failed to reproduce with a > custom rebuild of VLC. > > I haven't tried a local package rebuild just yet to see if that's all > that's needed. I may try one shortly unless you beat me to it. Will be > great if so. Hmm, so firstly I started with the upstream 3.0.x branch, at the 3.0.17.3 tagged commit 426513d88e3e3dc671434db8e724ee5d1b7e1038 (not finding a 3.0.17.4 tag). I cherry-picked two build fixes, 2202c892c8dc1381b596c53c2ebd3ca680061f95 (dav1d) and b689202d9f1621e82acb0976b6bb31455735a535 (caca). I compiled this successfully, and it just works, indicating that indeed just a rebuild is needed. However, I then rebuilt the debian package itself, and installed all of the rebuilt versions of every vlc package I had installed, and it still exhibits the issue. (I used these instructions: https://www.ducea.com/2008/03/06/howto-recompile-debian-packages/). I have no idea at this time what the relevant difference is between them that's causing this.
Bug#1021032: vlc: playing mp4 videos results in a black screen
On Mon, 2022-10-03 at 01:24 +0200, Sebastian Ramacher wrote: > On 2022-10-03 00:09:25 +0100, Lyndon Brown wrote: > > As you can see, mostly minor Qt updates. > > But those are the only packages relevant for vlc in your upgrade. So > it's probably Qt breaking vlc … and my test with 3.0.18 rc2 just > worked > as I built it with the current Qt version in unstable. > > Cheers Indeed, that's what I'm wondering. Note that in the Ubuntu bug report (https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1991418) Remi said that he could see the problem in Sid, but failed to reproduce with a custom rebuild of VLC. I haven't tried a local package rebuild just yet to see if that's all that's needed. I may try one shortly unless you beat me to it. Will be great if so.
Bug#1021032: vlc: playing mp4 videos results in a black screen
Control: retitle -1 vlc: playing videos results in a black screen Control: severity -1 grave Ran into this today after installing daily Sid updates. Was fine yesterday. I think that some updates from yesterday, or perhaps the day before may have been delayed until today due to a dependency issue, so that may explain why I've only just experienced this. This is not limited to mp4, I've also tried avi & mpg. Logs indicate video format conversion failure, as per the original reporter's logs. >From my apt log, these are the package updates that were installed today: - autoconf-archive:amd64 (20220903-1, 20220903-2) - chromium:amd64 (106.0.5249.61-1, 106.0.5249.91-1) - chromium-common:amd64 (106.0.5249.61-1, 106.0.5249.91-1) - chromium-sandbox:amd64 (106.0.5249.61-1, 106.0.5249.91-1) - flex:amd64 (2.6.4-8, 2.6.4-8.1) - libexempi8:amd64 (2.6.2-1, 2.6.2-2) - libfido2-1:amd64 (1.11.0-1+b1, 1.12.0-1) - libfl2:amd64 (2.6.4-8, 2.6.4-8.1) - libfl-dev:amd64 (2.6.4-8, 2.6.4-8.1) - libmediastreamer11:amd64 (1:5.0.37+dfsg-4, 1:5.0.37+dfsg-4+b1) - libopenmpt0:amd64 (0.6.5-1, 0.6.6-1) - libopenmpt-dev:amd64 (0.6.5-1, 0.6.6-1) - libpixie-java:amd64 (1:1.1.6-4, 1:1.1.6-5) - libqpdf29:amd64 (11.1.0-1, 11.1.1-1) - libqt5concurrent5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5core5a:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5dbus5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5designer5:amd64 (5.15.4-2+b1, 5.15.6-2) - libqt5gui5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5multimedia5:amd64 (5.15.4-2, 5.15.6-2) - libqt5multimediagsttools5:amd64 (5.15.4-2, 5.15.6-2) - libqt5multimediaquick5:amd64 (5.15.4-2, 5.15.6-2) - libqt5multimediawidgets5:amd64 (5.15.4-2, 5.15.6-2) - libqt5network5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5opengl5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5opengl5-dev:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5printsupport5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5qml5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5qmlmodels5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5qmlworkerscript5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5quick5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5quickcontrols2-5:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2) - libqt5quickparticles5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5quickshapes5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5quicktemplates2-5:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2) - libqt5quicktest5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5quickwidgets5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - libqt5sql5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5sql5-sqlite:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5svg5:amd64 (5.15.4-2, 5.15.6-2) - libqt5svg5-dev:amd64 (5.15.4-2, 5.15.6-2) - libqt5test5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5texttospeech5:amd64 (5.15.4-2, 5.15.6-2) - libqt5waylandclient5:amd64 (5.15.4-2, 5.15.6-2) - libqt5waylandclient5-dev:amd64 (5.15.4-2, 5.15.6-2) - libqt5waylandcompositor5:amd64 (5.15.4-2, 5.15.6-2) - libqt5waylandcompositor5-dev:amd64 (5.15.4-2, 5.15.6-2) - libqt5widgets5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt5x11extras5:amd64 (5.15.4-2, 5.15.6-2) - libqt5x11extras5-dev:amd64 (5.15.4-2, 5.15.6-2) - libqt5xml5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2) - libqt6concurrent6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6core6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6dbus6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6gui6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6network6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6opengl6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6openglwidgets6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6printsupport6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6shadertools6:amd64 (6.3.1-2, 6.3.1-3) - libqt6sql6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6sql6-sqlite:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6test6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6widgets6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - libqt6xml6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10) - linphone-desktop:amd64 (4.3.2-2, 4.3.2-2+b1) - qml:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - qml-module-qtgraphicaleffects:amd64 (5.15.4-2, 5.15.6-2) - qml-module-qt-labs-platform:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2) - qml-module-qtmultimedia:amd64 (5.15.4-2, 5.15.6-2) - qml-module-qtqml:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - qml-module-qtquick2:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - qml-module-qtquick-controls2:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2) - qml-module-qtquick-controls:amd64 (5.15.4-2, 5.15.6-2) - qml-module-qtquick-dialogs:amd64 (5.15.4-2, 5.15.6-2) - qml-module-qtquick-extras:amd64 (5.15.4-2, 5.15.6-2) - qml-module-qtquick-layouts:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - qml-module-qtquick-privatewidgets:amd64 (5.15.4-2, 5.15.6-2) - qml-module-qtquick-shapes:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - qml-module-qtquick-templates2:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2) - qml-module-qtquick-window2:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2) - qml-module-qtwayland-compositor:amd64 (5.15.4-
Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes
ping.
Bug#1009074: [usbguard] this action needs authorisation
Package: usbguard Version: 1.1.1+ds-2 I installed this update to my Sid install today and now if my Gnome session gets locked, after unlocking I get presented with a 'this usbguard action needs authorisation' password prompt. I dismissed it and immediately got a second, which I also dismissed.
Bug#1008916: [gnome-online-accounts] invalidated credentials
Package: gnome-online-accounts Version: 3.44.0-1 Severity: serious Please forgive me if I try to block the migration to testing temporarily. Some days ago when the big Gnome v42 update was pushed, for some reason it invalidated the gmail credentials on both my machine and my mother's (which I also have running Sid - please don't criticise). Whilst I was able to log back into my own accounts, since I have 2FA and such properly set up, my mother's primary account unfortunately was in a much poorer state, and she is being blocked from regaining access to her account by an impassible verification page, both in g-o-a and when trying to alternatively log in via a web browser. She is desperate to recover her gmail account and will be bringing her computer over to me to look at within the next couple of days if things go to plan. I intend to try downgrading g-o-a/evolution packages to testing versions to see if the existing stored credentials will work once more under those previous versions. If so then perhaps this may help allow her to login through a webpage to set up better verification info, or at least migrate the contents of her account to a new one.
Bug#1004104: [qt5-gtk-platformtheme] HiDPI support
Package: qt5-gtk-platformtheme Version: version 5.15.2+dfsg-14 I just installed this to see whether or not it would help enable an in- development Qt app adapt to the Gnome system theme. (Please consider packaging qgnomeplatform from [1]). I noticed that there seems to be an issue with HiDPI with this package, with various GUI text components being too large in that app with this package installed. [1]: https://github.com/FedoraQt/QGnomePlatform
Bug#1002817: [openssh-client] package setup error: and can't be the same
Package: openssh-client Version: 1:8.7p1-3 Upgrading to this new version just now on Sid I encountered errors. Relevant `sudo aptitude upgrade` output: Preparing to unpack .../openssh-client_1%3a8.7p1-3_amd64.deb ... Unpacking openssh-client (1:8.7p1-3) over (1:8.7p1-2) ... Preparing to unpack .../libpipeline1_1.5.4-2_amd64.deb ... Unpacking libpipeline1:amd64 (1.5.4-2) over (1.5.4-1) ... Preparing to unpack .../archives/lzip_1.22-5_amd64.deb ... Unpacking lzip (1.22-5) over (1.22-4) ... Setting up libpipeline1:amd64 (1.5.4-2) ... Setting up openssh-client (1:8.7p1-3) ... update-alternatives: and can't be the same Use 'update-alternatives --help' for program usage information. dpkg: error processing package openssh-client (--configure): installed openssh-client package post-installation script subprocess returned error exit status 2 Setting up lzip (1.22-5) ... update-alternatives: using /usr/bin/lzip.lzip to provide /usr/bin/lzip (lzip) in auto mode update-alternatives: using /usr/bin/lzip.lzip to provide /usr/bin/lzip-compressor (lzip-compressor) in auto mode update-alternatives: using /usr/bin/lzip.lzip to provide /usr/bin/lzip-decompressor (lzip-decompressor) in auto mode Processing triggers for libc-bin (2.33-1) ... Processing triggers for man-db (2.9.4-4) ... Processing triggers for install-info (6.8-3) ... Errors were encountered while processing: openssh-client needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up openssh-client (1:8.7p1-3) ... update-alternatives: and can't be the same Use 'update-alternatives --help' for program usage information. dpkg: error processing package openssh-client (--configure): installed openssh-client package post-installation script subprocess returned error exit status 2 Errors were encountered while processing: openssh-client Current status: 0 (-3) upgradable
Bug#970561: [usbguard] service start issues - start request repeated too quickly??
control: fixed -1 1.0.0+ds-1
Bug#996596: [linux-image-amd64] dkms error on kernel image removal
Package: linux-image-amd64 Version: 5.14.12-1 I tried to purge linux-image-5.14.0-1-amd64 yesterday and ran into an error. I additionally tried to purge linux-image-5.14.0-2-amd64 today following the release of linux-image-5.14.0-3-amd64 and ran into the same error, which I've copied below. Please can you advise how to clean up after the failure, is removal of the old '/lib/modules/5.14.0-x-amd64' directories and their contents sufficient? $ sudo dpkg --purge linux-image-5.14.0-2-amd64 (Reading database ... 274461 files and directories currently installed.) Removing linux-image-5.14.0-2-amd64 (5.14.9-2) ... /etc/kernel/prerm.d/dkms: dkms: removing: (5.14.0-2-amd64) (x86_64) Error! Arguments and are not specified. Usage: remove / or remove -m / or remove -m -v I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.14.0-3-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-5.14.0-3-amd64 /etc/kernel/postrm.d/initramfs-tools: update-initramfs: Deleting /boot/initrd.img-5.14.0-2-amd64 /etc/kernel/postrm.d/zz-update-grub: Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.14.0-3-amd64 Found initrd image: /boot/initrd.img-5.14.0-3-amd64 Adding boot menu entry for EFI firmware configuration done Purging configuration files for linux-image-5.14.0-2-amd64 (5.14.9-2) ... rmdir: failed to remove '/lib/modules/5.14.0-2-amd64': Directory not empty dpkg: warning: while removing linux-image-5.14.0-2-amd64, directory '/lib/modules/5.14.0-2-amd64' not empty so not removed
Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes
With bullseye now released, can we please now progress with the necessary transition to upgrade and thus address the security issue?
Bug#776917: fails to debootstrap without systemd
reopen -1 retitle -1 cannot switch init to sysvinit thanks Fixing #992916 ([1]) was made more complicated by the fact that this bug still exists in debootstrap. On sid, if I use the following command, the chroot ends up with both sysvinit and systemd packages installed. sudo debootstrap --arch=amd64 --include=sysvinit-core --exclude=systemd,systemd-sysv,systemd-timesyncd --components=main --verbose sid chroot http://deb.debian.org/debian/ $ sudo chroot chroot dpkg --list | grep systemd ii libsystemd0:amd64247.9-1 amd64systemd utility library ii systemd 247.9-1 amd64system and service manager ii systemd-timesyncd247.9-1 amd64 minimalistic service to synchronize local time with NTP servers $ sudo chroot chroot dpkg --list | grep sysv ii sysv-rc 2.96-7 all System-V-like runlevel change mechanism ii sysvinit-core2.96-7 amd64 System-V-like init ii sysvinit-utils 2.96-7 amd64 System-V-like utilities I had to spend significant additional time implementing a hack based upon [2] to get around this. Re-opening - It's been ~5 years since this was closed upon a basis that a separate bit of work was being undertaken that would supposedly solve it. I have not had the time to investigate what happened to that work, but it clearly has not worked out in some way. A perfect demonstration of why bugs should not be closed under such circumstances. [1]: https://salsa.debian.org/live-team/live-build/-/merge_requests/257 [2]: https://www.notinventedhere.org/articles/linux/debootstrapping-debian-jessie-without-systemd.html
Bug#992916: [live-build] broken sysvinit support
Package: live-build Version: 1:20210407 As just discussed on the mailing list (see the thread starting at [1]), the author of the thread would like to use the sysvinit init system instead of systemd. We already provide an option for selecting this (`- -initsystem`), however it does not work. All it achieves is to put a different `live-config-*` package along with `sysvinit-core` into a live package list. I expect that the reason why the author cannot build a sysvinit image currently is because debootstrap is installing `systemd-sysv` and we do nothing in our `boostrap_debootstrap` script to get debootstrap to alternatively install `sysvinit-core` like the procedure described at [2]. [1]: https://lists.debian.org/debian-live/2021/08/msg00014.html [2]: https://www.notinventedhere.org/articles/linux/debootstrapping-debian-jessie-without-systemd.html
Bug#987120: [libtorrent-rasterbar10] Please update - security fixes
Package: libtorrent-rasterbar10 Version: 1.2.9-0.2+b2 Tags: security Version 1.2.12 (released 5th Jan 2021) includes some security fixes, per [1]. [1]: https://libtorrent.org/security-audit.html
Bug#987118: [deluge] force-recheck not working
Package: deluge Version: 2.0.3-3 The force-recheck feature fails to work. I discovered that I was downloading something that I had already downloaded previously. It had reached about 11%. It was not making any progress at the time I noticed. I copied and pasted the old copy of the file over the top of the new partially downloaded one and then used the force-recheck feature to try to seed. What happened was that it changed briefly to 'checking', then reset it to 0% and moved it to the end of the queue (entry number was changed). I repeated this several times, always resulting in the same thing. I tried closing and reopening the program, no difference. I've rebooted since and retried, no difference. The torrent is about 1.3 GiB in size.
Bug#983203: your mail
On Sat, 2021-04-03 at 02:10 +0200, Chris Hofstaedtler wrote: > Control: severity -1 important > > * Lyndon Brown [210308 22:09]: > > # set severity to grave since it appears that the package is > > completely > > # broken currently. > > severity 983203 grave > > "completely broken" appears to be a gross overstatement. The > firewalld integration might be broken - and I agree it should be > fixed - but sshguard supports other firewall tools as well. You're absolutely right, I don't know why I thought differently at the time.
Bug#983203: [Pkg-utopia-maintainers] Bug#983203: [firewalld] error - invalid ipset sshguard4
On Sun, 2021-02-21 at 20:01 +0100, Michael Biebl wrote: > Unfortunately I have no idea what sshguard is. > Is that another firewall? I expect you've found out yourself by now, but fwiw, sshguard adds brute-force protection to ssh. It analyses log files for signs of brute force attempts and updates firewall rules to block connections as appropriate. > Does it install iptables / nftables rules (which might clash with > firewalld). The latest package version uses the nftables backend. Setup when using firewalld involves adding a couple of rich-rules as below. I do not know what sshguard specifically does internally to make things work, but some part of this setup, presumably with the switch to nftables, is clearly broken. > What exactly do you mean with "sshguard config"? The sshguard firewalld config is described in [1] & [2], and is essentially this: 1. # firewall-cmd --zone=zone-name --permanent --add-rich-rule="rule source ipset=sshguard4 drop" 2. # firewall-cmd --zone=zone-name --permanent --add-rich-rule="rule source ipset=sshguard6 drop" [1]: https://manpages.debian.org/testing/sshguard/sshguard-setup.7.en.html [2]: https://wiki.archlinux.org/index.php/Sshguard On Sun, 2021-02-21 at 20:10 +0100, Michael Biebl wrote: > After looking at the package description, I think this is a sshguard > issue. Ok, fair enough :) > Looking at the git log of sshguard, maybe upgrading to a newer > sshguard > version helps. > It has commits like > > https://bitbucket.org/sshguard/sshguard/commits/5927e696a8f0bc323f66d1edcce1365a70972320 > which look related. Indeed that does look very much related and I agree that it would be good to test a newer version of sshguard with those changes to see if that resolves it. I was too exhausted yesterday to think about looking at sshguard developments; sorry about that.
Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes
On Sun, 21 Feb 2021 04:16:21 + Lyndon Brown wrote: > I'm also having trouble getting DLNA working with minidlna on one > system and vlc on another, with little idea so far why it's not > working. Getting an updated libupnp13 with all the fixes they've made > may help eliminate some possible causes. Weird, having spent hours on this, I switched back to vlc after firing off the email and the remote system was suddenly right there in vlc's list... I can't explain that. I don't think I'd made any changes since the last time I checked. Something I did earlier must have fixed it but with some sort of delay to updating something. I think that the only big difference to where I started from is no longer having minissdpd on the server. Interestingly with it now fixed I refreshed the x.x.x.x:8200 webpage in the browser and noticed the client type field changed, from 'Unknown' to 'Generic UPnP 1.0'. Hmm... Well that did not last. A little fiddling, and now it's gone again and I'm not having any success at getting it back. The client has also gone back to 'Unknown'. :/ Anyway, please update at least for the CVE, and fingers crossed it may help with this also.
Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes
Package: libupnp13 Version: 1:1.8.4-2 Severity: critical According to the changelog upstream version 1.14.0 includes a security fix for CVE-2020-12695 (currently not tracked for pupnp in the debian security tracker). Please update to 1.14.x. Thanks. I'm also having trouble getting DLNA working with minidlna on one system and vlc on another, with little idea so far why it's not working. Getting an updated libupnp13 with all the fixes they've made may help eliminate some possible causes.
Bug#983203: [firewalld] error - invalid ipset sshguard4
Package: firewalld
Version: 0.9.3-2
Severity: important
I'm experiencing problems on a Sid system with firewalld and sshguard -
firewalld does
not seem happy with the sshguard config for some reason.
I set things up for sshguard a while ago and today happened to notice a problem
when trying to
add a temporary firewall rule while playing around with DLNA which resulted in
an error...
`firewall-cmd --add-port=1900/udp` gave:
Error: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could
not process rule: No such file or directory
JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain": "filter_IN_public_allow",
"expr": [{"match": {"left": {"payload": {"protocol": "udp", "field": "dport"}},
"op": "==", "right": 1900}}, {"match": {"left": {"ct": {"key": "state"}}, "op":
"in", "right": {"set": ["new", "untracked"]}}}, {"accept": null}]}}}]}
Checking `systemctl status firewalld` led to the discovery that firewalld did
not seem
happy with the existing permanent sshguard config, which had been added with
the following
commands (per sshguard setup instructions):
1. firewall-cmd --permanent --zone=public --add-rich-rule="rule source
ipset=sshguard4 drop"
2. firewall-cmd --permanent --zone=public --add-rich-rule="rule source
ipset=sshguard6 drop"
`firewall-cmd --info-ipset=sshguard4` gives:
Error: INVALID_IPSET: sshguard4
`firewall-cmd --state` gives:
failed
`systemctl status firewalld` gives:
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor
preset: enabled)
Active: active (running) since Sun 2021-02-21 00:44:38 GMT; 34min ago
Docs: man:firewalld(1)
Main PID: 1973 (firewalld)
Tasks: 2 (limit: 4636)
Memory: 25.1M
CPU: 1.328s
CGroup: /system.slice/firewalld.service
└─1973 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid
Feb 21 00:44:37 debian systemd[1]: Starting firewalld - dynamic firewall
daemon...
Feb 21 00:44:38 debian systemd[1]: Started firewalld - dynamic firewall daemon.
Feb 21 00:44:38 debian firewalld[1973]: ERROR: INVALID_IPSET: sshguard4
Feb 21 00:44:38 debian firewalld[1973]: ERROR: 'python-nftables' failed:
internal:0:0-0: Error: Could not process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
JSON blob:
{"nftables": [{"metainfo":
{"json_schema_version": 1}}, {"insert": {"rule": {"family": "inet", "table":
"firewalld", "chain": "filter_INPUT_ZONES", "expr": [>
Feb 21 00:44:38 debian firewalld[1973]: ERROR: COMMAND_FAILED:
'python-nftables' failed: internal:0:0-0: Error: Could not process rule: No
such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could not
process rule: No such file or directory
internal:0:0-0: Error: Could
Bug#976434: [Pkg-rust-maintainers] Bug#976434: [cargo] please update to v1.44+
Hi, Yes I do know about experimental. I rarely ever use anything from it though so sometimes I forget to check it. I did check for rustc 1.48 and preferred to wait for the final copy rather than use the beta that was available, but with cargo, I just completely forgot to look (I was so not thinking clearly at the time of submission that I failed to even put the package and version info into the original report). Sorry about that. I've jumped onto the experimental cargo package and it's working just fine. Thanks! I was not aware of the transition. Thanks again. I appreciate the effort you put into maintaining the packages. I rely on it. :D On Sat, 2020-12-05 at 13:15 +, Ximin Luo wrote: > Control: block -1 by 971571 > Control: tags -1 + pending > > Hi Lyndon > > Do you know about Debian experimental? cargo 0.47 has been in there > for a few months. > > We are waiting on the libgit2 transition before we can upload it to > unstable. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971571 > > X > > Lyndon Brown: > > Package: cargo > > Version: 0.43.1-4 > > > > Please can cargo be updated to v1.44 (0.46). It would be nice to be > > able to make use of `cargo tree`. > > > > Thanks for getting rustc updated the other day to 1.48 which means > > I > > can play with intra-doc-links. :D > > > > ___ > > Pkg-rust-maintainers mailing list > > pkg-rust-maintain...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers > > > >
Bug#976434: [cargo] please update to v1.44+
Package: cargo Version: 0.43.1-4 Please can cargo be updated to v1.44 (0.46). It would be nice to be able to make use of `cargo tree`. Thanks for getting rustc updated the other day to 1.48 which means I can play with intra-doc-links. :D
Bug#970561: [usbguard] service start issues - start request repeated too quickly??
Package: usbguard
Version: 0.7.8+ds-2
I'm experiencing some failures getting the service started cleanly.
I'll briefly explain how I got to this, if I can recall correctly. I
just had a need to use my printer (unused for quite some time), which I
connected via USB. Nothing was happening when I tried to print, so I
suspected usbguard, and indeed the printer was being blocked as
unauthorised per dmesg output. Not wanting to have to try to craft my
own rule for the printer, I deleted the rules.conf, had aptitude
reinstall usbguard to auto-generate a new one with the printer included
(double checking the details, confirming that it just added an entry).
I believe at this point I re-added the following custom rules to the
end and got the service restarted, before successfully printing, or
maybe I printed first:
```
allow with-interface equals { 08:*:* }
reject with-interface all-of { 08:*:* 03:00:* }
reject with-interface all-of { 08:*:* 03:01:* }
reject with-interface all-of { 08:*:* e0:*:* }
reject with-interface all-of { 08:*:* 02:*:* }
```
I then plugged in a USB pendrive (which usbguard has never blocked
before), but could not access it, and dmesg was indicating usbguard
blocking it, strangely. Restarting the service did not help, so I had
to reboot, at which point it then worked. (Does the service have an
issue re-reading the rules on restarting?).
(Edit: To be clear with the above, I'm pretty certain that I stopped
the service first, then started it again, and repeatedly asked it to
start until it did so successfully, per status output, and it would not
let me use the pendrive until after rebooting).
Getting to the point, when trying to restart the service, I also
checked the status afterwards to double check, only to find the
following:
```
$ sudo systemctl start usbguard
$ sudo systemctl status usbguard
● usbguard.service - USBGuard daemon
Loaded: loaded (/lib/systemd/system/usbguard.service; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2020-09-18 17:12:58
BST; 15s ago
Docs: man:usbguard-daemon(8)
Process: 2673 ExecStart=/usr/sbin/usbguard-daemon -k -c
/etc/usbguard/usbguard-daemon.conf (code=exited, status=1/FAILURE)
Main PID: 2673 (code=exited, status=1/FAILURE)
Sep 18 17:12:58 debian1 systemd[1]: usbguard.service: Scheduled restart
job, restart counter is at 5.
Sep 18 17:12:58 debian1 systemd[1]: Stopped USBGuard daemon.
Sep 18 17:12:58 debian1 systemd[1]: usbguard.service: Start request
repeated too quickly.
Sep 18 17:12:58 debian1 systemd[1]: usbguard.service: Failed with
result 'exit-code'.
Sep 18 17:12:58 debian1 systemd[1]: Failed to start USBGuard daemon.
Sep 18 17:13:00 debian1 systemd[1]: usbguard.service: Start request
repeated too quickly.
Sep 18 17:13:00 debian1 systemd[1]: usbguard.service: Failed with
result 'exit-code'.
Sep 18 17:13:00 debian1 systemd[1]: Failed to start USBGuard daemon.
```
It would take multiple attempts at asking it to start for it to report
started successfully.
Now, upon that reboot, I noticed red error indicators in the console
output (they may well have been there before without my noticing),
against services usbguard and usbguard-dbus.
So the first thing I did upon logging in was to double-check the
status, and finding them failed, tried to restart them. I asked first
usbguard to start, then usbguard-dbus, with the latter reporting
failure due to "a dependency job" failing. I checked the usbguard
status, finding it still down due to some failure. I asked it to start
again, checked the status, and it was then up. I then again asked
usbguard-dbus to start, which did not result in a dependency error this
time. But then I immediately checked the usbguard (not usbguard-dbus)
status, and found it down again for some reason, yet then checking
usbguard-dbus status, that was up. I double checked usbguard, and
indeed it was still down, while usbguard-dbus was up. So I asked
usbguard to start once more, and again it then reported being up.
I've just double checked the status after writing this, and usbguard is
down again with error for some reason, while usbguard-dbus remains up.
Bug#963827: closed by Gianfranco Costamagna (Re: [virtualbox] guests limited to 800x600)
Re-opening. This is most certainly *not* fixed. I have a Debian Sid installation (with a Gnome environment) in a VBox VM, fully up-to-date, and the problem still exists with this. When the problem surfaced, I had to restore from backup and place a hold on kernel and virtualbox-guest-* package updates to keep the VM usable (but insecure), while maintaining a duplicate copy that I install the updates on to test if each new version fixes it, wasting a chunk of my disk space. This has not been at all ideal. AS I said, I've just double checked things, and the problem is definitely still there. Frustratingly, when I looked at the VBox bug tracker some weeks ago, others were in the same position; VBox guys were just asking if those users were using wayland, and stating that the resizing simply does not work for wayland, contradicting the simple fact that it clearly was working fine up until the point release that broke it as people tried to point out. There was also some suggestion of an environment variable being involved, and possibly not used correctly by some distros, if I recall correctly. I have not been holding my breath for a quick fix. Interestingly I have just discovered something useful - I tried selecting 'gnome on xorg' at the login screen, and was pleased to find that the login environment under that at least works fine. I guess this must have been one of the later fixes and I did not previously think to recheck. So the problem only affects the default (wayland) environment. This eases some of the impact upon myself - I guess I can manage with an X11 environment for the time being. Fundamentally though, the problem is only partially fixed, it's still broken for wayland, which *was* working previously, despite the illogical claims of VBox guys. And thus since the problem partially still exists, the bug should remain open - the small login screen is mostly just cosmetic in nature, but not being able to have a usable wayland session is problematic. On Tue, 2020-09-15 at 08:09 +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:virtualbox package: > > #963827: [virtualbox] guests limited to 800x600 > > It has been closed by Gianfranco Costamagna >. > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Gianfranco > Costamagna by > replying to this email. > >
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: Bug#969319: wifi cannot connect after combined suspend & gateway reboot
On Tue, 2020-09-08 at 23:35 +0200, Michael Biebl wrote: > In any case, it might be a good idea to involve NM upstream and file > an > issue at > https://gitlab.freedesktop.org/NetworkManager/NetworkManager done: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/531 also: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/550
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot
reassigning to iwd for now, since my latest experiences are that having updated to iwd v1.9 connecting to my hidden SSID home network is now completely broken. which may very possibly relate to the original issues i was experiencing under v1.8.
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot
this is driving me a little crazy today. some hours ago i was in the middle of getting some stuff transferred over an rsync connection, when suddenly the transfers stopped progressing. the connection had gone bad. so, since previously a solution seemed to be closing some programs, i started closing things down and trying to reconnect (having turned the wifi off temporarily via the gnome menu). this time, no luck, i'd closed all my open programs and it still would not connect. of course it could be a background task, but whatever the case, i needed to reboot. i rebooted, and unlike before, it just would not connect. it has taken me ***2 whole damn hours*** of fiddling to get connected again. i rebooted the laptop multiple times; i rebooted the gateway multiple times; it just would not work. i tried moving myself a few feet away from the router to ensure a strong signal. i told NM to forget the connection and re-added it, multiple times. i tried using iwctl to connect, but it just immediately reported failure on every attempt. i tried forcing a change of MAC with macchanger, no difference. my android smartphone connected fine when i fetched it and turned on the wifi... i turned off the gateway to scan visible networks with the smartphone to check that there wasn't a neighbour with the same router- model SSID, nope. so i pushed the reset button on the gateway, told NM to forget the connection, and interestingly had absolutely no trouble at all connecting this time. i restored a backup of the gateway's config and it rebooted. i then again had NM forget the connection and tried to re-add it, and it just kept refusing, giving me an 'activation of network connection failed' popup at the top of my screen. note, i'd been copying and pasting the password, so i know that's not the issue, i even compared the password in the NM connection config and that stored in the gateway (via a wired connection from an old machine). i switched the gateway wifi channel, no difference. i set the SSID to un-hidden. finally, shortly after doing this, it suddenly connected fine. i switched it back to hidden, then i went and sat down with the laptop to type this up, and after a minute or so, i notice the connection suddenly disappear, and again it's refusing to connect. interestingly it was yesterday that iwd was updated to v1.9; i'd left the laptop sleeping overnight, and just rebooting earlier today (if i recall correctly), so perhaps the 1.9 update has either introduced yet another problem on top, or otherwise made things much worse. since it's gone down again after switched back to hidden, i'll spend a little more time experimenting... so, rebooted, no difference. moved next to gateway, no difference. logged back into gateway via wired connection of older machine, changed wifi to non-hidden, saved, turned around and boom, it's suddenly got a wifi connection. turned back to the old machine, changed to hidden again, turned back to laptop, saw the wifi icon change to the '...' reconnect one temporarily, but if i recall now correctly it remained up, i then turned off and back on the wifi (on the laptop) and fails to connect. switched back to unhidden, and connects perfectly. so yeah, functionality for connecting to hidden networks is completely broken. so i switched things back to wpa_supplicant and rebooted. straight away, no issues at all connecting to the hidden SSID (after forgetting and re-adding again of course). i'm connected now and getting work done again. well, it's almost working perfectly back on wpasupplicant, i was back getting data transferred via rsync, and then eventually something went wrong preventing further transfer, but turning the wifi off and back on again fixed it. i recall that always being a bad as things had gotten previously with wpasupplicant.
Bug#969319: Info received ([Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot)
a further update since the experimentation done this morning. for the past ~12 hours since then i've been getting a lot of work done on the laptop, and have **NOT** let it sleep during this time. somewhat randomly the problem has surfaced again, thus suggesting that sleeping has nothing to do with the source of the problem. i was doing something else for a few minutes before returning to the laptop. the lid was left up, so not sleeping, but it had turned off the screen. i unlocked my account. as best as i can recall, my next action was then to try to check for updates, only to find the command hung and finally failed. the wifi was still connected. i checked the lights on the gateway and they were good, so the internet connection was fine. it became apparent that the connection had gone bad somehow, refusing to let anything through. i've experienced this numerous times before, including, i'm certain, before i even installed iwd, let alone configured NM properly to use it (which was just a few weeks ago). so i turned the wifi off and back on (via the gnome menu), and it was refusing to connect. i captured activity with iwmon whilst trying numerous times to ask it to connect, sometimes turning wifi off and back on, and even waiting a full minute before trying again. it just would not connect. dmesg was showing the same issues as before. i was starting to shutdown some of the apps i had open, but then remembered that sometimes when i've experienced this before it was whilst deluge was running (which was not open this time), and closing deluge immediately fixed the problem. (immediately reopening deluge was not a problem). so i closed a couple of things with no change, then closed evolution, and bang, it connected perfectly fine having done so. so it seems to be the case that something occasionally manages to go wrong and jams up the connection (i'm not sure that it's a complete block on all apps sending messages over the connection, but certainly some), in a way that's linked to one of the running apps, which only gets fixed upon closing that app. i.e. an app (evolution it seems in this case, deluge commonly in others) is obtaining some locked access to the connection and failing to release it, even letting itself get blocked by the failed release of that resource. i've previously researched the problem with respect to deluge and found at least one other person experiencing this problem, which the deluge guys could not get to the bottom of as i recall. note, again, to be absolutely clear, deluge was not running in this instance, it seems to have been evolution this time. if this results from the same exact bug as is causing the originally reported problem, it's a little strange since in the experiments i was doing this morning i typically only had terminal and gedit open. of course there may be things like gnome-online-accounts automatically running in the background (which i have accounts setup in). in fact just in case it's relevant, i frequently get timeout errors and such in evolution relating to failures to fetch calendars and such from google.
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot
On Mon, 2020-08-31 at 14:02 +0200, Michael Biebl wrote: > Am 31.08.20 um 12:22 schrieb Lyndon Brown: > > Package: network-manager > > Version: 1.26.2-1 > > Severity: important > > > > I'm on Debian Sid, with network manager configured to use iwd. I > > have > > an Intel AX200 wifi card. > > > > Can you reproduce that with wpasupplicant? short answer no. details of hours of experimentation today follows... firstly, i forgot previously to mention that it's a hidden network. also, it can be noted that the other day i tried leaving the gateway on over night for a change, while leaving the laptop sleeping (lid shut), and when i returned to it the next day, it successfully reconnected. so time left sleeping does not seem to be a particularly significant factor, whilst the gateway being off for a while during that sleep definitely does. however, i've been doing that for the past few days now, and today experienced the same connection failure, despite the gateway having remained on the entire time. (unless there was a power cut while i slept i guess; i didn't check). so that's interesting. since that has forced me to close down all of the work i'm in the middle of (which is why i'm leaving it sleeping) for a reboot, i've taken the opportunity to investigate further as asked... firstly i felt the need to test reproducibility before any switch to wpa_supplicant. so i started off doing the following: 1. rebooted and logged in. 2. it connected automatically and i took the opportunity to install package updates. 3. i shut the lid and waited for approximately one minute. 4. turned off the gateway and waited for approximately one minute. 5. turned the gateway back on and waited for approximately one and a half minutes. 6. opened the lid of the laptop and unlocked it. unfortunately it had no issue reconnecting (which it did automatically). dmesg output: ``` [ 362.938616] PM: suspend exit [ 364.687381] wlan0: authenticate with «MAC» [ 364.691259] wlan0: send auth to «MAC» (try 1/3) [ 365.590534] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 365.590626] wlan0: Connection to AP «MAC» lost [ 366.175547] wlan0: send auth to «MAC» (try 2/3) [ 366.183586] wlan0: authenticated [ 366.183659] wlan0: associating with AP with corrupt probe response [ 366.186737] wlan0: associate with «MAC» (try 1/3) [ 366.198772] wlan0: RX AssocResp from «MAC» (capab=0x411 status=0 aid=1) [ 366.214860] wlan0: associated [ 366.512295] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready ``` so although it did not connect exactly cleanly, it still connected. perhaps there's a time factor and i need to leave it for longer? so i tried again, this time with the following differences: 1. directly locked the desktop first (win+l) 2. did not reboot since the last experiment 3. expanded the time periods from parts 3-5 of the previous experiment to 3min, 5min and 3min respectively. having returned to the laptop, this time it's not automatically reconnected. good. dmesg: ``` [ 1776.902728] PM: suspend exit [ 1778.750632] wlan0: authenticate with «MAC» [ 1778.753331] wlan0: send auth to «MAC» (try 1/3) [ 1779.321626] wlan0: send auth to «MAC» (try 2/3) [ 1780.220436] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1780.220475] wlan0: Connection to AP «MAC» lost [ 1780.281716] wlan0: send auth to «MAC» (try 3/3) [ 1781.180748] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1781.180849] wlan0: Connection to AP «MAC» lost [ 1781.304939] wlan0: authentication with «MAC» timed out ``` explicitly selecting the network fails, ah but damn, turning it off then back on it's now successfully connected, which is not what has been happening previously. ``` [ 1776.902728] PM: suspend exit [ 1778.750632] wlan0: authenticate with «MAC» [ 1778.753331] wlan0: send auth to «MAC» (try 1/3) [ 1779.321626] wlan0: send auth to «MAC» (try 2/3) [ 1780.220436] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1780.220475] wlan0: Connection to AP «MAC» lost [ 1780.281716] wlan0: send auth to «MAC» (try 3/3) [ 1781.180748] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1781.180849] wlan0: Connection to AP «MAC» lost [ 1781.304939] wlan0: authentication with «MAC» timed out [ 1978.199366] wlan0: authenticate with «MAC» [ 1978.204215] wlan0: send auth to «MAC» (try 1/3) [ 1979.103492] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1979.103593] wlan0: Connection to AP «MAC» lost [ 1979.322185] wlan0: send auth to «MAC» (try 2/3) [ 1980.221124] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1980.221207] wlan0: Connection to AP «MAC» lost [ 1980.282051] wlan0: send auth to
Bug#969319: wifi cannot connect after combined suspend & gateway reboot
Package: network-manager Version: 1.26.2-1 Severity: important I'm on Debian Sid, with network manager configured to use iwd. I have an Intel AX200 wifi card. Normally the wifi of my laptop connects to my home gateway automatically, but there's a issue where it cannot connect until rebooted after a combined suspending of the laptop and rebooting of the router. My normal daily routine involves turning the gateway on first (no point wasting electricity leaving it on over night), then getting out the laptop and turning that on. There's no problem in this scenario. If at any time during the day I reboot the gateway, it handles this fine (or at least if it doesn't automatically reconnect it connects fine on manually selecting the network from the list Gnome provides). A lot of the time when I go off to do something else, I leave the lid open, so no suspending, but sometimes I do close the lid and thus let the laptop sleep, and similarly, no real issues with connecting when I get back on it. I can select the 'turn off' wifi option and turn it back on, and it reconnects fine. However, something I've done instead for the past couple of nights is to lock the user account, close the lid to let it sleep, and then turn off the gateway. The problem I'm experiencing is that after turning the gateway back on, and then (minutes later) returning to the laptop, it's impossible to reconnect without rebooting. Selecting the network from the list Gnome provides, the wifi connecting icon appears for a few seconds, then just disappears. Checking dmesg, this is what I'm seeing (MAC censored): [223484.493130] wlan0: authenticate with «MAC» [223484.496051] wlan0: send auth to «MAC» (try 1/3) [223485.395342] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223485.395383] wlan0: Connection to AP «MAC» lost [223485.759776] wlan0: send auth to «MAC» (try 2/3) [223486.658815] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223486.658853] wlan0: Connection to AP «MAC» lost [223486.751809] wlan0: send auth to «MAC» (try 3/3) [223487.650547] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223487.650625] wlan0: Connection to AP «MAC» lost [223487.710943] wlan0: authentication with «MAC» timed out [223503.680212] wlan0: authenticate with «MAC» [223503.685609] wlan0: send auth to «MAC» (try 1/3) [223504.585038] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223504.585098] wlan0: Connection to AP «MAC» lost [223504.735885] wlan0: send auth to «MAC» (try 2/3) [223505.634822] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223505.634869] wlan0: Connection to AP «MAC» lost [223505.759800] wlan0: send auth to «MAC» (try 3/3) [223506.658534] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223506.658564] wlan0: Connection to AP «MAC» lost [223506.718845] wlan0: authentication with «MAC» timed out [223803.377295] wlan0: authenticate with «MAC» [223803.382092] wlan0: send auth to «MAC» (try 1/3) [223804.281508] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223804.281602] wlan0: Connection to AP «MAC» lost [223804.736105] wlan0: send auth to «MAC» (try 2/3) [223805.635147] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223805.635194] wlan0: Connection to AP «MAC» lost [223805.728010] wlan0: send auth to «MAC» (try 3/3) [223806.627041] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223806.627081] wlan0: Connection to AP «MAC» lost [223806.719201] wlan0: authentication with «MAC» timed out [223878.248338] wlan0: authenticate with «MAC» [223878.255331] wlan0: send auth to «MAC» (try 1/3) [223879.154749] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223879.154801] wlan0: Connection to AP «MAC» lost [223879.776037] wlan0: send auth to «MAC» (try 2/3) [223880.675073] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223880.675113] wlan0: Connection to AP «MAC» lost [223880.735862] wlan0: send auth to «MAC» (try 3/3) [223881.634760] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223881.634804] wlan0: Connection to AP «MAC» lost [223881.727233] wlan0: authentication with «MAC» timed out I tried turning wifi off and back on again (via the Gnome menu) and manually selecting the network, which did not help, same failure. I have macchanger installed, and tried switching to a new random MAC to see if that helped (with the wifi off temporarily, obviously), but it did not help. I tried rebooting the gateway again, which also did not help. I tried closing the lid for a few moments to recycle through a sleep state, which did not help. So I rebooted, as I did the day before when this happened, and it connected just fin
Bug#969197: [gitk] search misses commits
Package: gitk Version: 1:2.28.0-1 Severity: important Sometimes when I use the search functionality in gitk, it misses commits. For example, just right now I am rebasing some work I did for the VLC codebase. I had a need to search for all commits adding/removing the string "set_capability". It is important that I find all commits with this so that I can find relevant changes to reflect in my rebased work. This search found commit 66c7fc04d7d0d944215c99012cbcb94dc42c3531 for instance. Another was 888451fe5146a49de8d49e830dbe57dd478e358f, though this is unhelpful since it involves renaming files (it would be much better if gitk excluded such commits), but then crucially missed the commit after that - 46650ad3f7f92d2757c43b42aa170965dc1df25c - which most definitely is relevant. An accurate search is crucially important. I have literally thousands of commits to rebase this work upon to catch up before resubmitting it, including some very large commits, and having the search facility miss commits like this is not at all helpful. FYI, I have encountered this numerous times in the past, but was only now frustrated enough to bother reporting it. Please fix it :)
Bug#964279: [deluge] TypeError: '>' not supported between instances of 'NoneType' and 'NoneType'
Package: deluge-gtk Version: 2.0.3-2 finding a lot of this in my system log (logged as deluge.desktop): TypeError: '>' not supported between instances of 'NoneType' and 'NoneType' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/listview.py", line 233, in stabilized result = sort_func(model, iter1, iter2, data) File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/torrentview.py", line 106, in progress_sort return cmp(state1, state2) File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/common.py", line 45, in cmp return (x > y) - (x < y)
Bug#963827: [virtualbox] guests limited to 800x600
Package: src:virtualbox Version: 6.1.10-dfsg-1 Severity: important After installing a handful of updates in a Sid guest and rebooting it, it's now stuck with an unusable display area of 800x600.
Bug#960533: apt: parser error : xmlParseEntityRef
Multiple users including myself are experiencing this. I also do not know the source of the problem. I first noticed it yesterday, also using apt 2.1.1. There are others discussing it on the debian-users mailing list ([1]), with some insight into the source of the strings the errors refer to at least. [1]: https://www.mail-archive.com/debian-user@lists.debian.org/msg756341.html On Wed, 13 May 2020 18:35:00 +0200 Nicolas Patrois < nicolas.patr...@gmail.com> wrote: > Package: apt > Version: 2.1.1 > Severity: normal > > Dear Maintainer, > > I don’t know if it is an apt bug or not. > Just after having read the sources, apt complains about malformed XML files: > > Entity: line 4: parser error : xmlParseEntityRef: no name > e original message barList of languages in a config file instead iso- codesFind > & > ^ > Entity: line 8: parser error : EntityRef: expecting ';' > - get haircut @s 24 @r d &i 14 @o r >^ > Entity: line 11: parser error : EntityRef: expecting ';' > @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU >^ > Entity: line 11: parser error : EntityRef: expecting ';' > @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU > ^ > Entity: line 11: parser error : EntityRef: expecting ';' > @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU > ^ > Entity: line 11: parser error : EntityRef: expecting ';' > @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU > ^
