Bug#994791: During the Debian10->11 upgrade there is an rkhunter bug and the upgrade can fail due to lack of disk-space; after the upgrade the cursortheme isn't working, KDE Plasma doesn't start due t
Package: Debian Version: 11 Maybe these should be separate bug reports. However, I'm not sure about that and this is made more inconvenient and outdated by using emails for bug-reports. Filing it all under Debian rather than e.g. rkhunter or KDE Plasma packages is implying or calling for such things to be tested and solved prior to enabling upgrade by Debian contributors. Please split/link if needed. I upgraded multiple machines from Debian 10/KDE to 11/KDE stable. - After the partial upgrade with `sudo apt upgrade --without-new-pkgs` the console output quit with: Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /bin/which E: Problem executing scripts DPkg::Post-Invoke 'if [ -x /usr/bin/rkhunter ] && grep -qiE '^APT_AUTOGEN=.?(true|yes)' /etc/default/rkhunter; then /usr/share/rkhunter/scripts/rkhupd.sh; fi' E: Sub-process returned an error code I asked about it [here](https://unix.stackexchange.com/q/666356/233262) with more details. It's related to [#932594](https://bugs.debian.org/932594). If I just selected keep current version in a prompt during the upgrade this isn't a bug (even though it may be useful if these prompts showed an indication that the new conf file is needed/has updated). - I also had to remove package aide. Furthermore, unatteneded-upgr was blocked. I also asked about these two, in my case minor, issues in the question above. The unatteneded-upgrades had this output:Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2705 (unattended-upgr)... 30s - Another minor issue: after (fully) upgrading the initial boot screen asking for the grub password was red and looked a bit strange instead of blue but quickly changed back to the blue one and didn't look strange and/or red reboots afterwards or another machine. Could this have occurred because some /etc / conf file wasn't upgraded or was it a negligible glitch? - On one of my Debian10/KDE->11 machines after logging in I only had a black screen (with some windows on top). This is because plasmashell isn't running (the only thing that runs is startplasma-x11) so I started it with kstart5 plasmashell. However, it crashes right after it seems to have fully loaded. I asked about it [here](https://unix.stackexchange.com/q/17/233262) and the solution was to re/move the /home/username/.local/share/plasma/plasmoids/org.kde.plasma.eventcalendar folder. - The cursor was too small and changing it was not possible because the cursortheme wasn't working. I found the solution [here](https://forum.siduction.org/index.php?topic=8133.0): it was (re?)installing package qml-module-org-kde-newstuff. - The upgrade can fail if there is not enough disk-space. The upgrade process should (accurately) check how much disk space is available and needed and if needed do the upgrades in batches, leaving a bit of disk-space as a buffer, rather than trying to run the full upgrade and repeatedly failing. The upgrade should not fail due to lack of disk space. On one machine this was worked around by rerunning the upgrade and sudo dpkg --configure -a. - On one of my Debian10/KDE->11 machines the sound output wasn't working anymore before the upgrade, after running sudo apt-get dist-upgrade before changing the sources.list entries to "bullseye". I asked about it [here](https://unix.stackexchange.com/questions/669001/audio-missing-after-upgrading-from-debian-10-to-11). The solution was to (re?)install package plasma-pa.
Bug#993047: A libvirt-qemu user is added and shown on the login screen because the UID is too high
Package: libvirt Version: 5.0.0 I didn't create this user - I think it was added by installing the "Virtual Machine manager" (virt-manager) on Debian10/KDE, or more specifically by libvirt-daemon-system. `grep -E 'libvirt|qemu' /etc/passwd` returns `libvirt-qemu:x:64055:1xx:Libvirt Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin` KDE's User Manager doesn't show the account but it's displayed on the login screen on the left of the actual user account (not when locking the screen but at least after booting). This useraccount shouldn't be displayed as a normal user if adding it is indeed needed/useful. If the solution is to not remove the user but to hide it by creating the /users/libvirt-qemu file why isn't that done when the user is set up already? If the user is necessary I'd find it strange that iirc it was only added after installing virt-manager but not after installing and using aqemu. I asked about it here where users cas and A.B. made some helpful comments. A.B. suggested that "libvirt-qemu is a system account but with a specific UID not in the default system range ( < 500 or something like this): `grep LIBVIRT_QEMU_UID /var/lib/dpkg/info/libvirt`*" (it's over 6). Changing the UID or creating that config-file containing `SystemAccount=true` upon installation seem to be two ways of solving this issue. Per https://github.com/sddm/sddm/issues/816 it really seems to be a bug of virt-manager. I don't know if this has been fixed in newer versions. If the solution really is just changing the UID there may be an additional issue of 500 being too low. It should probably check which UIDs within that range are still available and then assign one of these. It seems like running `usermod -u 345 libvirt-qemu` would solve the issue for those affected, right? Per https://github.com/virt-manager/virt-manager/issues/293 the problem is the hard-coded UID here: https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/buster/debian/libvirt-daemon-system.config It would be great if people would set up a proper issue-tracking system for Debian (one that's modern, somewhat convenient to use, doesn't look outdated by decades and is Web-based).
Bug#1018003: comment
May also be related to "Plasmashell problems after changing the HDMI output and KDE does not recognize the new display": https://bugs.kde.org/show_bug.cgi?id=457755 Currently, it doesn't crash anymore but I often need to go to an alt+f3 (any number) terminal and run `loginctl unlock-session {id}` and `logout` to resume the session.
Bug#1018003: comment
In the totally outdated issue tracker I can't edit the text: it doesn't crash anymore because as a workaround I have the monitor HDMI cable disconnected except when I use it. When connecting the HDMI cable, the session ends only when the monitor that the HDMI cable is plugged into is turned off. The wallpaper is changed to a default one nevertheless. Currently, the remaining problem is that when doing one of these things to switch the monitor back again the sessions as well: a) pulling out the HDMI cable b) switching off the active second monitor c) press meta+p and selecting "Unify outputs" (haven't tried the other ones yet). For the workout to be complete, I only need to find out how to switch back to the formerly active display without the session ending. I'll try a few more things later such as going into standby, then pulling out the HDMI cable, and waking it again. If somebody knows a working workaround, please comment.
Bug#1023024: Session crashes when switching back to first display from a second one connected with HDMI when Wayland is used with KDE
Package: plasma-workspace Version: 5.20.5-6 First of all I don't know which package is causing this but it has to do with Wayland and KDE. Full description of the issue with some logs: https://unix.stackexchange.com/questions/722870/how-to-prevent-kde-session-from-quitting-when-switching-the-display-in-debian-11 In short: I have two displays and am using Debian 11/KDE with Wayland. As a workaround to prevent another bug, I have the HDMI cable to the second display disconnected except when I use it. I have found a workaround that allows me to use (switch to) the second display without the session crashing. When switching the monitor back again, the KDE session crashes (this means I need to login again and restart running apps and so on).
Bug#1068769: When removing a package with an entry in /etc/xdg/autostart/ ask the user whether the autostart file should be removed or remove it by default
Package: apt Version: 2.6.1 See https://unix.stackexchange.com/questions/774058/shouldnt-files-in-etc-xdg-autostart-be-removed-when-removing-a-package/774068 Please make apt-get remove autostart entries from the /etc/xdg/autostart/ folder also if the --purge option is not used. Alternatively, prompt the user whether that autostart entry should also be removed. Many or most users do not know about the --purge option and those who do probably don't always know which of all of their packages have an autostart entry. There is no command like apt-get clean to remove all dysfunctional autostart entries. Files that cause things to autostart are different from any /etc/ config file which just provides some configs if the application is running. Cleaning up autostart entries if a software is removed is good practice, improves security, and is generally what the user would like to do. If the package is installed again, a new autostart entry would or could be created anyway and keeping it after removing a package is more likely to cause problems than anything else in that case such as the app autostarting twice. It does not make sense to keep autostart entries when packages get removed.
Bug#1068774: When installing a package that is kept back with apt-get install do not mark it as manually installed or ask the user whether the mark should be added
Package: apt Version: 2.6.1 Could you please make apt not mark packages as manually installed when installing packages that have been kept back in specific? Alternatively, the user could be asked whether they want to have it marked if the mark would be added but I think most users would not want that. It makes little sense and only causes problems, partly because they then won't uninstall when removing packages that depend on them. The packages could also be marked differently such as "kept-back manually installed" and there could be a parameter for marking it as manually installed like it is now. This is a common problem and it's recommended or best practice to not mark them as manually installed, see: https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956330
Bug#956330: (No Subject)
I think this would good. Created a similar issue here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068774 However, I don't think it's common that one manually installs a package that one already had installed as a dependency and doesn't want to mark it as manually installed, or is it? I think example scenarios would be useful.
Bug#1042467: (No Subject)
Same here on multiple Debian/KDE machines after upgrading to Debian12. I think the title should be clearer or should this package actually be installed? I doubt it. For me it wants to remove way more than 30 packages, many of them being essential packages. See https://unix.stackexchange.com/questions/748950/after-upgrading-to-debian12-and-upgrading-packages-apt-shows-the-following-pack Also this issue tracker is totally outdated. By decades. And nearly unusable, which is a problem if the project is interested in getting more devs involved.
Bug#1068776: Apper and Discover ask to install "orphan-sysvinit-scripts" but not apt-get
Package: apper Version: 1.0.0 Why is that and is this a bug? If this is not the correct place to file it, please move this or tell me where to report it. sudo apt upgrade and sudo apt-get upgrade don't ask for this to be installed so I don't know why Apper and Discover ask for it to be installed since I thought they were using apt-get. This issue tracker is outdated by decades. See https://unix.stackexchange.com/questions/774015/why-does-kdes-discover-and-apper-show-orphan-sysvinit-scripts-should-be-updat
Bug#1068777: plasma-systemmonitor with the process manager is not installed anymore after upgrading to Debian12
Package: kde-plasma-desktop Version: 5:142 After upgrading from Debian11/KDE to Debian12, plasma-systemmonitor was not installed. This should definitely be an installed package and I think it is configured to be. On Debian11, KSysGuard was used. Now there only is KSysguard in "Background Services" which "Launches KSysguard on Ctrl + Escape" and launches systemd->systemmonitor. While this shortcut was kept, ctrl+shift+esc wasn't set anymore so one has to configure it again under "Custom Shortcuts" with command "plasma-systemmonitor". I checked /var/log/apt/history.log and there it says "plasma-systemmonitor:amd64 (5.27.5-2, automatic)" underneath apt-get full-upgrade in the packages next to "Install: ". However that process exited with "Error: Sub-process /usr/bin/dpkg returned an error code (1)" because of "FATAL ERROR: Both /lib/udev/mtp-probe and /usr/lib/udev/mtp-probe exist." after which I ran "apt --fix-broken install" before running "apt-get full-upgrade" again. Right after all this (that is upgrading to Debian12) I noticed this package was not installed and installed this specific package. plasma-systemmonitor, which includes the process manager, should always be installed by default on a new KDE setup as well as when upgrading from the prior Debian version which had KSysguard installed. In addition, the widely known and much used shortcut ctrl+shift+esc should also be there by default and launch plasma-systemmonitor (or alternatively systemmonitor).
Bug#1068778: geoclue and gpsd are running by default (they aren't needed and could be used for location tracking)
Package: general I wondered why Debian comes with geoclue-2.0 and gpsd running by default (which could be used for location tracking). Please do not install them by default or if you really must, please do not make them autostart. At most it could be useful for a few users if it was installed but not enabled and not running by default (so just an option one could enable in the configs or which could be enabled by the user through a prompt). If it's running by default this also means that after upgrades it could be running again. This is a privacy issue, an undesired bloat service that requires to spend time to remove it, and a larger attack surface even if there was a proper and vulnerability-free permissions-management for GPS-location-access.
Bug#1068779: Shortcuts for systemmonitor and plasma-systemmonitor are missing after upgrade or when installing it
Package: plasma-systemmonitor Version: 5.27.5-2 On one of the machines I upgraded to Debian12 from Deb11/KDE the Default shortcut Ctrl+Esc for "Show System Activity" in "KDE Daemon" under Shortcuts is disabled but not on the other. This meant that the process manager didn't show anymore when pressing ctrl+esc after upgrading which can be quite annoyance to users and seems like a problem that is easy to solve: just make sure that shortcut doesn't get disabled. Note that Ctrl+Esc is also set as a shortcut under File->Close. I don't know why it was disabled. It could also be enabled whenever plasma-systemmonitor / systemmonitor gets installed. That this is hard to find under "KDE Daemon" where most users wouldn't expect this entry makes it an even bigger problem but the shortcuts should be working by default without requiring any configuration in general anyway. In addition, the shortcut Ctrl+Shift+Esc should be set for opening plasma-systemmonitor; currently this has to be configured under Custom Shortcuts. It should be there by default or right after installing plasma-systemmonitor which should be installed by default. Related issue: plasma-systemmonitor with the process manager is not installed anymore after upgrading to Debian12 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068777
Bug#1068780: Two login screens with the same name and with no preview/image
Package: sddm Version: 0.19.0-5 In Debian12 with KDE5 (SDDM v0.19.0-5) after an Upgrade from Debian11 under System Settings -> Startup and Shutdown -> Login Screen (SDDM) there are two Login screens with the same name and no preview. Screenshot in the link below (this issue tracking system is outdated by decades). When hovering on the second login screen the trashbin button is also greyed out. Screenshot and some info that could be relevant: https://github.com/sddm/sddm/issues/1912 If I start systemsettings from the console when opening up this page to view the login screens this is the new output: QQmlEngine::setContextForObject(): Object already has a QQmlContext file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/InlineMessage.qml:257:13: QML SelectableLabel: Binding loop detected for property "implicitWidth" file:///usr/share/kpackage/kcms/kcm_sddm/contents/ui/main.qml:54:20: QML Image: Cannot open: file:///usr/share/sddm/themes/debian-maui/maui.jpg file:///usr/share/kpackage/kcms/kcm_sddm/contents/ui/main.qml:54:20: QML Image: Cannot open: file:///usr/share/sddm/themes/debian-maui/maui.jpg file:///usr/share/kpackage/kcms/kcm_sddm/contents/ui/main.qml:54:20: QML Image: Cannot open: file:///usr/share/sddm/themes/debian-maui/maui.jpg file:///usr/share/kpackage/kcms/kcm_sddm/contents/ui/main.qml:54:20: QML Image: Cannot open: file:///usr/share/sddm/themes/debian-theme/maui.jpg file:///usr/share/kpackage/kcms/kcm_sddm/contents/ui/main.qml:54:20: QML Image: Cannot open: file:///usr/share/sddm/themes/debian-maui/maui.jpg file:///usr/share/kpackage/kcms/kcm_sddm/contents/ui/main.qml:54:20: QML Image: Cannot open: file:///usr/share/sddm/themes/debian-theme/maui.jpg qml: The item SubCategoryPage_QMLTYPE_74(0x55b0a5ab7d50) is already in the PageRow Maybe this is because two display monitors are configured? I previously had a problem of a second smaller login screen above a larger one (mirrored content where I could login in either) before I disabled the other powered-off display monitor under "Display Configuration". Bug report in need of more info if anybody can provide it here: https://bugs.kde.org/show_bug.cgi?id=485199 I would expect that there only is one login screen and that it has a preview image.
Bug#993047: (No Subject)
This problem still exists in Debian12! Shouldn't the user be hidden there because the UID is larger than the Maximum user UID set for the login screen in SDDM?
Bug#1068783: After upgrading to Debian12 the session SDDM automatically logs in to is changed
Package: sddm Version: 0.19.0-5 On one of the machines upgraded from Debian11 to Debian12 I had configured that it automatically logs in. But it seems like in the dropdown next to "with session" after the upgrade this was changed to "Kodi" instead of "Plasma (X11)" (there was no noticeable difference to the standard X11 session and Kodi didn't autostart). It's probably because "Kodi" is the first value in the dropdown which seems to be sorted alphabetically. Please either make it so that the value before the upgrade is set there or that it's Wayland in specific.
Bug#1068784: When configuring Wayland to be the default at the login screen this doesn't change the session the user is automatically logged into
Package: sddm Version: 0.19.0-5 When configuring Wayland to be the default at the login screen (dropdown in the upper left) as recommended at places where people asked about how to switch from X11 to Wayland, this doesn't change the session the user is automatically logged into. I think it should be changed or the user be asked if they'd like to change the default after auto-login if they changed it at the lockscreen. Here I got this reply https://github.com/sddm/sddm/issues/1912 : >If you set > >[Autologin] >Session= > >it'll use the last used session for autologin. kcm_sddm does not support that, >so you'll have to put that into /etc/sddm.conf.d/y_autologin.conf to override >the value from kde_settings.conf.
Bug#1068785: Sometimes the keyboard is turned off when waking from standby after upgrading to Debian12
Package: sddm Version: 0.19.0-5 This could also be an issue of the Sleep function. I'm using a laptop that suspends to swap partition. After upgrading to Debian12 with KDE, sometimes the keyboard of a laptop is turned off while the touchpad still works. It doesn't work again after putting it back into standby and then waking it from standby. It really is in standby as one could hear if it wasn't. After waking from Hibernate or when just locking the screen the keyboard does work. Moreover, often if not always under some conditions (which I'll try to find out and then add) the laptop shows the prior screen for 0.2-4.0 seconds before it shows the lockscreen. This obviously is a privacy issue and could be linked to the prior problem. It hasn't occurred the last two days. When I just Log Out the keyboard works fine at the lockscreen. It only doesn't work when resuming from sleep (opening the lid after it was closed or pressing the power button after clicking Sleep). Once I started testing and asking about this the problem the keyboard didn't just stop working sometimes but never worked after resuming from Sleep for at least 10 different kinds tries. Now first clicking Sleep in the bottom left caused a shutdown (instead of sleep) again (I think it did some disk check when waking), and afterwards the keyboard now works again when resuming from sleep in two tries but I think it's only back to sometimes rather than always being dysfunctional. Please go here for further details: https://unix.stackexchange.com/questions/773987/sometimes-the-keyboard-is-turned-off-when-waking-from-standby-after-upgrading-to Also it may be useful to test or develop tests whether it's fully and without problems going to Sleep, see: https://unix.stackexchange.com/q/774151/233262
Bug#1068801: Apper shows Authorization failed error "You have failed to provide correct authentication." when trying to install packages
Package: apper Version: 1.0.0 I think I had this same problem already long ago sometimes and whenever it happened just used apt-get install instead of Apper (which works without any issues). I'm using Debian12 with KDE. The full error message in the box that plops up after confirming the packages to install is: >You have failed to provide correct authentication. >Please check any passwords or account settings. >Details >Failed to obtain authentication SDDM is version 0.19.0-5 polkit-kde-authentication-agent-1' process is running unattended-upgrades is not running and not installed anymore apt is not running, Discover is not running (only discover-notifier) The error is from apper.lib PackageKit at RoleInstallPackages and other messages in the console are basically just "kf.widgetsaddons: Invalid pixmap specified." Also see https://bugzilla.redhat.com/show_bug.cgi?id=1004323
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
Package: general A distro upgrade of Debian needs a lot of disk space on the root partition. That partition often doesn't have a large size. That could for example be because it's on a mobile device, on a SSD drive, has lots of installed software, or because the user simply followed the advice of guides that usually recommend the root partition to be relatively small. I had this problem when upgrading to Debian12 and also had it during the last distro upgrade. A problem is that the storage requirements displayed when running sudo apt-get upgrade --without-new-pkgs or sudo apt-get full-upgrade are lower than what is actually needed. Obviously, that shouldn't be the case. Solving this problem could be redundant if there was a way to make it upgrade incrementally in several steps. Could you please make stepwise distribution upgrades possible? With the two commands above one can already split it up into two steps but especially the second command still requires a lot of disk space. That it displays less storage requirements than actually needed makes it more difficult to avoid the problem. Avoiding and solving potential issues resulting from the upgrade breaking or from what the user tries to do to free up disk space requires skill and time, and makes the upgrade userunfriendly and far less smooth than it could be. Here's what I do to free up disk space and I had to do some of the things while the upgrade was ongoing as I noticed that it takes up more disk space than I previously freed up: https://unix.stackexchange.com/q/774199/233262 (such as deleting the cached packages after an unrelated fatal error breaking the upgrade so that it downloaded half of them again when I ran the full-upgrade command again after solving that). This could also be an issue for apt but it could probably also be done independently from that package which is why I filed it under general for now. One could also make it so that it dynamically adjusts depending on how much disk space is available throughout the upgrade. It could and probably should still only be one command. For example, I think a good approach to this would be something like this (if the user is low on root partition disk space): 1. asking for *at least* 400MB to be available 2. if a parameter for stepwise is set or it detected low free disk space: 3. downloading the first 300 MB or so of packages 4. installing these 5. deleting the cached packages from /var/cache/apt/archives/ 6. downloading the next batch up to the storage limit set at start 7. and so on (without exiting in-between)
Bug#1068829: Disabling the autostart of KDE Connect and screenreader KAccessible
Package: kde-plasma-desktop Version: 5:142 These aren't needed for most users and are a privacy and security risk. In principle, it makes sense to only autostart things one actually needs to reduce the likelihood of crashes, the number of irrelevant log entries, the hardware resource consumption, and the attack surface (for example due to potential vulnerabilities in any of the software, especially if they constantly listen on some port). Many people are looking for ways to disable these autostarts and don't like that they're just enabled by default, see for example https://unix.stackexchange.com/questions/384306/why-does-kdeconnect-listen-on-port-1716-tcp-all-the-time-how-to-close-the-port and https://discuss.kde.org/t/how-to-disable-kde-connect/7686/3 (there two devs clarified that this is not a KDE issue but "a distribution issue" which is why I'm filing it here). I thought Debian was a distro with great regard for security and stability and that it considers privacy and actual user needs/practices. A major issue with these autostarts is that there is no proper way to disable them. See https://unix.stackexchange.com/questions/774190/how-to-permanently-disable-autostarting-of-applications-on-linux-debian These methods do not only require time and are inconvenient (it's not even clear which one to use), they also get reset when the packages get upgraded such as during a distro upgrade. KDE Connect constantly listens on some ports and according to the second link has been a known vector for a DOS attack. I think "Calendar Reminders", screenreader "Orca", and "geoclue-2.0" also should not autostart but this issue is only about wireless file/device sharing app KDE Connection and KDE Accessible. I don't think these autostarts were enabled to give people a reason to get educated on autostarts and autostart-prevention and to harden these two apps. If that's why they were automatically starting by default so far, then they should still be disabled now. If needed, the user could be asked if they want to have these autostart during initial installation. Rather than bundling security-reducing bloat autostarts, I suggest that if these are installed by default at all, they are not configured to autostart. The user can easily configure them to autostart if they actually want that in the "Autostart" settings.
Bug#1068832: Apper does not show the installation history anymore
Package: apper Version: 1.0.0 I think the installation history of the GUI Apper is very useful: it shows a history of package installs and removals with timestamps. I think it should also show other installations made via the command-line (dpkg.log files and .deb file installs). I don't know of any other pre-installed GUI in KDE that also shows an installation log and I proposed that non-default KSystemLog includes it. It doesn't show any entries anymore under History which are still shown on another machine. I recently upgraded from Debian11 to 12. When running apper in the console and opening the History page, it shows: >QObject::connect: No such slot >PackageKit::Transaction::transaction(QDBusObjectPath,QString,bool,uint,uint,QString,uint,QString). Before opening the page there is: >QCommandLineParser: already having an option named "h" >QCommandLineParser: already having an option named "help-all" >QCommandLineParser: already having an option named "v" >QCommandLineParser: option not defined: "install-provide-file" >apper: >apper:
Bug#1068774: (No Subject)
> You found with #956330 already a feature request that asks for that No, that other issue is not about kept-back packages in specific. I don't see how the functionality of that issue would be very useful but for kept-back packages asking the user or by default not marking them as manually installed could be very useful and seems more like what one would expect it to do. > Note that "phases upgrades" have their own listing now Do you mean phased updates? Whether or not you meant that, I don't know what you mean there (what and how it relates to this issue). > it turns out that you 'install' things you care about and don't want removed > as unneeded later on This is about kept-back packages where install is used to make them install.
Bug#1068774: (No Subject)
> So, which is it: You install random things you don't care about because their > name appeared in the kept-back list or you explicitly install that package > from the kept-back list because you care very deeply about it? I and many others (this issue is not about me) install them like that because their name appeared in the kept-back list. So it's the former and I never said it wouldn't be that. > APT isn't keeping back a package because its bored. It has reasons ... Thanks for the explanations. One only sees which packages it would install or remove when one tries to install it, like so for sysv-rc-conf that wants to remove countless core packages: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042467 (still no reply there) / https://unix.stackexchange.com/q/748950/233262 (how to see why) This issue however is not what happens when one checks what it would do when installing a kept-back package or about what could go wrong with installing it, it's about how the package is marked when one already decided and went ahead with installing it. > that isn't how apt sees it. You might remember that in a previous request you > made apt might have said that about a package, but apt has no such memory Well then part of this would be to make it run a check if any of the packages to be installed is currently kept-back. I never said it would have to keep prior apt commands in mind, it just knows (can check) which packages are kept-back. In the usual scenario the notice about a kept-package displays during an apt-get upgrade/update command. > based on your explicit manual install request This issue is not about installs that are explicitly manual and it shouldn't be merged with other issues that are about something else.
Bug#1068774: (No Subject)
> And I tried to explain to you that many others believe in the exact opposite Sure, I'm aware of that. Once again, this is about kept-back packages. When kept-back packages in specific are installed through apt-get install, then that is usually not because the user wanted to mark them as manually installed, something many don't even know exists at all or for years, but because they want to solve the problem shown when upgrading their packages. Those who actually want to mark it as manually installed *for kept-back packages* could still do so. I'm not complaining, just pointing out an issue and that issue may not be clear to those who used Debian and apt-get for years/decades and for example assume that the users know everything they know or should be required to (and that right from the time of their first upgrade problems). Another option would be to display a prompt like "The following packages have been kept back ... If you want to install them as if they were dependencies, run sudo apt-get install --fix-held-back ..." so that the user just runs that instead of the normal install command but I don't think it would be as good as the thing proposed here for example because such a command doesn't exist. I think any issues you bring up that could, probably rarely, exist if the package is not marked as manually installed could be solved and they also exist for solutions like the top recommendation (--with-new-pkgs) in the top answers here https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it > Your sysv-rc-conf is kinda an example: A normal upgrade doesn't do it because > it is deemed not a good idea to prefer this over 20 other packages I guess I just remove it. But why does require so many packages to be removed, seems like it would need to be upgraded properly so it doesn't require that? > That is an explicit manual install request for some-pkg. Fair point, but then please change it so that the process of resolving kept-back is different. That could be a prompt the user needs to confirm, a prompt displaying another command the user could run (or several options), or something else. Basically this issue is broadly about how kept-back packages are installed with the only best feasible solution I came up with being that the install command simply doesn't mark them manually installed by default (except if for example a parameter is used). Yes, having a choice there would be good but if you're referring to the other issue with that, this one is only about kept-back package installation (that is ways that treat these different from any other package installations such as running certain code if it detected it to be a kept-back package).
Bug#1068823: (No Subject)
Thanks guys, these are very useful methods and I'll mention these as alternatives to disk cleanups recommended at https://unix.stackexchange.com/q/774199/233262 (this would probably very useful to have at places about upgrades failing due to disk space issues even though people only look these up once the problems already occurred). However, the problem of the upgrade requiring more disk space than displayed at first remains and the command by Zeimetz can't be used with a built-in rememberable well-known command like sudo apt-get upgrade --stepwise I don't think peripheral devices would be the common case for personal computers, rather one would simply specify a directory on a partition that is larger than the root partition. Upgrading individual packages is not what this is about in case that wasn't clear. It's one upgrade but it's separated into several steps where one batch of packages are download and installed, the cache deleted, and then the next batch. If the upgrade breaks in between due to disk space, because the user aborted it, a crash, or an error, then only some packages are upgraded...a stepwise upgrade could if anything be a way to *avoid* that (or at least interruptions due to disk space problems) and to make them less problematic. The key thing is that it would be usable with a simple command (such as by adding --stepwise)...if that command only executes a few already existing commands with no apt changes required for the basic functionality of this, that's all the better.
Bug#1068823: (No Subject)
> Personally, I don't think a machine that has that limited storage ought to be > upgraded using apt from one Debian stable release to another. It's not the machine but the partition. One can set up Debian to use a separate partition for the home directory. When the root partition on a SSD has 20 GB (about the size I think all guides I found on this suggest or use in their example) which should be large enough and the upgrade claims it needs 5 GB and actually needs 7 GB that can obviously be a problem. > it is not supported to arbitrarily break apt updates up like that ...which is why this an issue for a new functionality rather than already existing. It doesn't have to be arbitrary. It's common sense to break up GB-sized downloads into several steps. Last upgrade failed due to disk space issues; this upgrade I had to clean caches during the upgrade as workaround; I'm sure many have this problem and even if it's rare it would be best to have upgrades run smoothly and reliably (such as checking remaining disk space throughout the upgrade and adjusting accordingly). Those are not several upgrade but one upgrade that downloads not once initially but several times and cleans up the caches after each step.
Bug#1019438: (No Subject)
Control: reassign -1 kde-plasma-desktop [5:142] This problem still exists in Debian12 with Wayland. It only works with the VLC player where I can use the preview to change tracks but it doesn't work for apps like Dolphin, konsole, firefox, Discover and so on. I checked and there is this output when hovering over the panel item: > file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/PipeWireThumbnail.qml:11:1: > module "org.kde.pipewire" is not installed Do I need to install or configure anything for this to work?
Bug#1069325: A smaller lockscreen is shown above a larger one due to a second enabled powered-off display device
Package: kde-plasma-desktop Version: 5:142 This is occurring after upgrading to Debian12 whenever waking from sleep or locking the screen. First submitted this here: https://bugs.kde.org/show_bug.cgi?id=485199 I could click on both password boxes to enter the password and login (it doesn't matter if it's the smaller or larger lockscreen). The problem was solved by going to Display Configuration -> selecting the other monitor and disabling it. But it is occurring again now after I reenabled it. (I powered on the other display, enabled it, selected extend to side with meta+P, configured a few things like the wallpaper of the other display, and then powered it off without disabling it.) The two displays have different resolutions. I'm using Wayland now. I had plasmashell running from the kstart5 plasmashell command in the konsole and this is the output in the console that could be useful: > file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/PipeWireThumbnail.qml:11:1: > module "org.kde.pipewire" is not installed > Could not find the Plasmoid for Plasma::FrameSvgItem(0x55be4a604ee0) > QQmlContext(0x55be4763e640) > QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml") > Could not find the Plasmoid for Plasma::FrameSvgItem(0x55be4a604ee0) > QQmlContext(0x55be4763e640) > QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml") > qt.qpa.wayland: Wayland does not support QWindow::requestActivate() > qt.qpa.wayland: Wayland does not support QWindow::requestActivate() > Checking screens: available: (QScreen(0xid1, name="HDMI-A-1")) redundant: > QHash((QScreen(0xid2, name="HDMI-A-2"), QScreen(0xid1, name="HDMI-A-1"))) > fake: QSet() all: (QScreen(0xid1, name="HDMI-A-1"), QScreen(0xid2, > name="HDMI-A-2")) > Initializing > "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/kcms/systemsettings/kcm_fonts.so" > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:20: > TypeError: Cannot read property 'pluginName' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:75: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:78: > TypeError: Cannot read property 'pluginName' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:80: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:81: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:82: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:83: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:84: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:16: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:17: > TypeError: Cannot read property 'configuration' of null > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:18: > TypeError: Cannot read property 'configuration' of null This seems to happen at every resume from sleep but if the mouse is located on the larger lockscreen once it is moved just slightly the smaller lockscreen disappears. Also it would be useful if the two displays have different resolutions and Unify screen rather than Extend screen is used (as now) the larger resolution is kept on the display with the larger resolution. If there's something I should test or some logs I should check, please let me know.
Bug#1068801: (No Subject)
When I run apper from the console there is this: > apper.lib: errorCode: PackageKit::Transaction::ErrorNotAuthorized "Failed to > obtain authentication." > apper.lib: PackageKit::Transaction::ExitFailed > PackageKit::Transaction::RoleInstallPackages > kf.kwidgetsaddons: Invalid pixmap specified. The problems means when installing packages apt-get needs to be used. Something is broken there. I thought it used to happen because of unattended-upgrades which is not even installed anymore. Let me know if I should try or check something.