Bug#1071383: gnome-core should not recommend network-manager-gnome
Package: gnome-core Version: 1:43+1 Severity: normal X-Debbugs-Cc: inasprec...@disroot.org Dear Maintainer, to this day, gnome-core still recommends network-manager-gnome. While this may sound reasonable given the package names, the situation is misleading: what network-manager-gnome offers boils down to two tools: nm-applet and nm-connection-editor. Now, nm-applet is, ironically, useless in a vanilla GNOME desktop with no extensions, since GNOME hasn't had tray icon support in quite a few years, including the gnome-core parckage in bookworm (1:43+1). The other tool, nm-connection-editor, merely duplicates functionality that is already present in the built-in gnome-control-center. For these reasons, I feel that network-manager-gnome by itself is largely unnecessary nowadays when running a GNOME desktop and should not be installed by default (not even recommneded). However, this raises an important point: as of now, it is technically possible to install gnome-core without network-manager (the package which provides the actual NetworkManager subsystem, not the network-manager-gnome applet!) even without disabling the installation of "Recommends" packages. In my opinion, this is undesirable for most people, since tihs would leave you with no way to manage connections graphically from gnome-control-center (unless of course there are other tools installed). Right now, if gnome-core is installed through the default apt policy of installing recommended packages by default, network-manager-gnome is pulled in, which then depends on network-manager, pulling it in as well. The result is that network-manager is installed when gnome-core is installed with its "Recommends" packages, but only because of an indirect and (in my opinion) legacy "Recommends" relationship with network-manager-gnome and not a proper, direct "Recommends" relationship with network-manager. To conclude, I propose the following dependency changes (which as of now still persist in the gnome-core package included in Sid). 1. gnome-core should not recommend network-manager-gnome. Remove it from "Recommends". 1. gnome-core *should* recommend network-manager. Include it in "Recommends". Thank you for your time. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-core depends on: ii adwaita-icon-theme43-1 ii at-spi2-core 2.46.0-5 ii baobab43.0-1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii eog 43.2-1 ii evince43.1-2+b1 ii evolution-data-server 3.46.4-2 ii fonts-cantarell 0.303.1-1 ii gdm3 43.0-3 ii gkbd-capplet 3.28.1-1 ii glib-networking 2.74.0-4 ii gnome-backgrounds 43.1-1 ii gnome-bluetooth-sendto42.5-3 ii gnome-calculator 1:43.0.1-2 ii gnome-characters 43.1-1+deb12u1 ii gnome-console 43.0-2 ii gnome-contacts43.1-1 ii gnome-control-center 1:43.6-2~deb12u1 ii gnome-disk-utility43.0-1 ii gnome-font-viewer 43.0-1 ii gnome-keyring 42.1-1+b2 ii gnome-logs43.0-1 ii gnome-menus 3.36.0-1.1 ii gnome-online-accounts 3.46.0-1 ii gnome-session 43.0-1+deb12u1 ii gnome-settings-daemon 43.0-4 ii gnome-shell 43.9-0+deb12u2 ii gnome-shell-extensions43.1-1 ii gnome-software43.5-1~deb12u1 ii gnome-sushi 43.0-2 ii gnome-system-monitor 42.0-2 ii gnome-text-editor 43.2-1 ii gnome-themes-extra3.28-2 ii gnome-user-docs 43.0-2 ii gnome-user-share 43.0-1 ii gsettings-desktop-schemas 43.0-1 ii gstreamer1.0-packagekit 1.2.6-5 ii gstreamer1.0-plugins-base 1.22.0-3+deb12u1 ii gstreamer1.0-plugins-good 1.22.0-5+deb12u1 ii gvfs-backends 1.50.3-1 ii gvfs-fuse 1.50.3-1 ii libatk-adaptor2.46.0-5 ii libcanberra-pulse 0.30-10 ii libglib2.0-bin2.74.6-2+deb12u2 ii libpam-gnome-keyring 42.1-1+b2 ii libproxy1-plugin-gsettings0.4.18-1.2 ii libproxy1-plugin-webkit 0.4.18-1.2 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 ii nautilus 43.2-1 ii pipewire-audio0.3.65-3+deb12u1 ii sound-theme-freedesktop 0.8
Bug#1070664: emacs: Emacs 28.2: ELPA key expired
Package: emacs Version: 1:28.2+1-15 Severity: important X-Debbugs-Cc: inasprec...@disroot.org Dear Maintainer, The key for signing the GNU Emacs packages in the official GNU ELPA archive has changed. The key included in this GNU Emacs version has expired. This disables the download of the archive list as well as any package from elpa. In order to allow GNU ELPA packages to be downloaded again, the key needs to be updated manually. A possible solution is to run the following ELisp snippet from within Emacs: (let ((package-check-signature nil)) (package-refresh-contents) (package-install 'gnu-elpa-keyring-update)) After restarting GNU Emacs, downloading and installing packages from GNU ELPA works again. If possible, they key included with the Emacs package itself should be updated in order to avoid having to resort to similar workarounds. Thank you for your attention. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:28.2+1-15 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#1070204: gnome-boxes: Missing dependency on qemu-utils and libvirt-clients
Package: gnome-boxes Version: 43.2-1 Severity: important X-Debbugs-Cc: inasprec...@disroot.org Dear Maintainer, The problem is present on the gnome-boxes pacakge distributed in the current Debian stable branch, Bullseye. When creating a new virtual machine with the "+" button on the upper left corner, GNOME Boxes was hanging on the "Review and Create" menu, without showing anything inside the popup window. On a terminal, I saw the following messages: Boxes-Message: 20:12:50.764: libvirt-machine.vala:268: Failed to connection to system libvirt: Unable to open qemu+unix:///system: Failed to connect socket to '/var/run/libvirt/libvirt-sock-ro': No such file or directory (gnome-boxes:8952): GLib-GObject-WARNING **: 20:12:50.820: ../../../gobject/gsignal.c:2722: handler '2749' of instance '0x561b3992a600' is not blocked (gnome-boxes:8952): Boxes-WARNING **: 20:12:56.637: review-page.vala:44: Box setup failed: Failed to create volume: internal error: creation of non-raw file images is not supported without qemu-img. (gnome-boxes:8952): Boxes-CRITICAL **: 20:12:56.637: boxes_assistant_review_page_populate: assertion 'machine != NULL' failed I then installed the qemu-utils package, which contains the qemu-img command, and the problem went away, with GNOME Boxes now proceeding on the "Review and Create" menu and showing the options to select how much RAM and disk space to allocate for the new virtual machine. However, I also saw a message on the popup window, containing the following text: "Virtualization extensions are unavailable on your system. Check your BIOS settings to enable them.". I found this odd, as I double checked that I indeed had virtualization support enabled in my BIOS. On the terminal, I saw the following messages: libvirt-machine.vala:268: Failed to connection to system libvirt: Unable to open qemu+unix:///system: Failed to connect socket to '/var/run/libvirt/libvirt-sock-ro': No such file or directory (gnome-boxes:5406): GLib-GObject-WARNING **: 20:23:34.328: ../../../gobject/gsignal.c:2722: handler '2748' of instance '0x55a59ef865c0' is not blocked (gnome-boxes:5406): Boxes-WARNING **: 20:23:40.894: util-app.vala:442: Failed to execute child process ?virsh? (No such file or directory) I then installed the package libvirt-clients, which contains the virsh command, and this problem too went away. >From my observation, it seems that the gnome-boxes package should depend (or at least recommend) the qemu-utils and libvirt-clients packages. At the moment, gnome-boxes in Bullseye has no dependency on either package, not "Depends", not "Recommends" and not "Suggests" either. Since creating virtual machines is, in my opinion, an important feature for a graphical frontend to virtualization software, I think gnome-boxes should at least have a "Recommends" dependency on both libvirt-clients and qemu-utils, if not a mandatory "Depends" relationship. This is partially addressed in the testing branch (Trixie): there, gnome-boxes does have a "Depends" on libvirt-clients, but still no dependency of any kind on qemu-utils. Thank you for your attention. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-boxes depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii genisoimage 9:1.1.11-3.4 ii libarchive13 3.6.2-1 ii libc62.36-9+deb12u6 ii libcairo21.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libgudev-1.0-0 237-2 ii libhandy-1-0 1.8.1-1 ii libosinfo-1.0-0 1.10.0-2 ii libosinfo-bin1.10.0-2 ii libsecret-1-00.20.5-3 ii libsoup-3.0-03.2.2-2 ii libspice-client-glib-2.0-8 0.42-1 ii libspice-client-gtk-3.0-50.42-1 ii libtracker-sparql-3.0-0 3.4.2-1 ii libusb-1.0-0 2:1.0.26-1 ii libvirt-daemon 9.0.0-4 ii libvirt-glib-1.0-0 4.0.0-2 ii libwebkit2gtk-4.1-0 2.42.5-1~deb12u1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii tracker
Bug#1070023: dict-freedict-eng-jpn: Failure to stop dictd.service on purge even if unit is not loaded
Package: dict-freedict-eng-jpn Version: 2022.12.07-2 Severity: normal X-Debbugs-Cc: inasprec...@disroot.org Dear Maintainer, when uninstalling (purging) the package, I got the following error message: Failed to stop dictd.service: Unit dictd.service not loaded. invoke-rc.d: initscript dictd, action "stop" failed. Apt reports that the subprocess returned error code 5 (five). I did not have dictd running as a service, so this error was unexpected, but I got it regardless. The package seems to have been purged successfully anyway. Thus, it is only a minor annoyance, but the post-build script should check properly whether dictd.service is actually running before attempting to stop it. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled dict-freedict-eng-jpn depends on no packages. dict-freedict-eng-jpn recommends no packages. Versions of packages dict-freedict-eng-jpn suggests: pn dict | kdict | gnome-dictionary | goldendict pn dictd | dicod
Bug#1037087: chromium-l10n: The following packages have unmet dependencies: chromium-l10n : Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be installed
Hi, I tried installing chromium-l10n again on a freshly updated Bullseye machine (with the bullseye-security and bullseye-updates repositories enabled, of course) and this time the operation succeeded with no conflicts. Unless there are new reports about this problem persisting, I think this bug can be closed. Best regards.
Bug#1022025: fixed in linux 5.10.149-2
On Thu, 27 Oct 2022 21:01:15 +0200 Salvatore Bonaccorso wrote: > Can you please fill a new bug for your issue, which would still > be > present in the 5.10.149-2 release? There are two users which > report > that they still have problems with the amdgpu driver still in > 5.10.149-2. I think bug 1022806 is a recent one referring to 5.10.149-2 specifically, which is about this same issue. I don't think there is a need to report yet another bug about it. Best regards. -- inasprecali
Bug#1022025: fixed in linux 5.10.149-2
On Thu, 27 Oct 2022 06:17:10 + Debian FTP Masters wrote: > Source: linux > Source-Version: 5.10.149-2 > Done: Salvatore Bonaccorso > > We believe that the bug you reported is fixed in the latest version of > linux, which is due to be installed in the Debian FTP archive. I'm sorry, but your belief seems to be mistaken, since we have multiple reports o 5.10.149-2 still not booting with the amdgpu driver. Best regards. -- inasprecali
Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics
Diederik de Haas writes: > Then I'm inclined to think this *is* a separate issue, which is > due to the upgrade to -19, but that you happen to have an AMD > GPU is 'not' relevant. > > I realize it's not what you want, but may result in an useful > extra data point if you (for this test) switch those parameters > to enable radeon support and disable amdgpu support. Can you try > that? > > If that test does not make a difference, then I'm quite sure > it's a separate issue and it would be best to open a new bug > report for that. I tried booting 5.10.0-19 with an empty command line string and it worked, although it’s now using the "radeon" gpu driver while I’d like to use the "amdgpu" driver instead, mainly for better Vulkan support. Booting with command line options to disable "radeon" and enable "amdgpu" works for 5.10.0-18 and earlier. I don’t know if this an entirely separate issue, however. I can file a separate bug if you think it is appropriate. Best regards. -- inasprecali
Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics
Diederik de Haas writes: > Then I'm inclined to think this *is* a separate issue, which is > due to the upgrade to -19, but that you happen to have an AMD > GPU is 'not' relevant. > I realize it's not what you want, but may result in an useful > extra data point if you (for this test) switch those parameters > to enable radeon support and disable amdgpu support. Can you try > that? > > If that test does not make a difference, then I'm quite sure > it's a separate issue and it would be best to open a new bug > report for that.
Bug#1022042: kernel 5.10.149-2 does not help
On Sun, 23 Oct 2022 13:43:30 +0200 Diederik de Haas wrote: > Andreas and inasprecali, > > On zondag 23 oktober 2022 09:17:44 CEST Andreas Wirooks wrote: > > Kernel parameters are: > > radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 > > amdgpu.cik_support=1 amdgpu.gpu_recovery=1 > > You both have kernel parameters like these. Can you explain why? > I have an AMD GPU on a machine and I have never set parameters like these. In my case, it's because, without command line parameters, the kernel will select the "radeon" driver, while I want to use the "amdgpu" driver instead. The options "radeon.si_support=0 amdgpu.si_support=1" disable radeon support and enable amdgpu support respectively. 5.10.0-18 and earlier have always worked as expected. 5.10.0-19, even with the very latest stable update, fails to boot. Best regards. -- inasprecali
Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics
On Sun, 23 Oct 2022 13:40:26 +0200 Diederik de Haas wrote: > Does it really not boot? Or does the screen not work properly? > > The cases in this bug report all boot AFAIK, it's just that the screen does > not work properly, but people were able to SSH into the machine. > If your system actually does not boot, then I'm inclined to think that that is > a different problem. It does not boot at all, I'm unable to SSH into it. It's not merely that the display does not work. At the moment, I'm unable to provide additional information, but I'll try looking into it as soon as possible. Best regards -- inasprecali
Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics
After updating to the latest version (5.10.149-2), my system running an AMD GPU and CPU still does not boot. I am unable to retrieve any logs from the systemd journal. CPU: AMD FX-8350 GPU: AMD R9 270X (Southern Islands Family) Kernel command line parameters: GRUB_CMDLINE_LINUX="radeon.si_support=0 amdgpu.si_support=1" 5.10.0-19 fails to boot, while 5.10.0-18 does. Best regards. -- inasprecali
Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics
I can confirm this same exact problem on a machine of mine. CPU: AMD FX-8350 GPU: AMD R9 270X (Southern Islands Family) 5.10.0-19 fails to boot, while 5.10.0-18 does. Best regards. -- inasprecali
