from:"mYnDstrEAm"

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)