Re: icônes de kde disparus
Le 24/04/2024 à 13:40, Sébastien NOBILI a écrit : Bonjour, Le 2024-04-24 12:20, Kohler Gerard a écrit : avez vous des indications pour retrouver mes icônes ? Qu'est-ce que ça donne avec un compte utilisateur de test ? - si il a le même problème, alors c'est côté système qu'il faudra chercher (apt-get) - si il n'a pas le même problème, alors c'est du côté de tes préférences utilisateur (ton homedir) qu'il faudra chercher. Sébastien bien vu, l'utilisateur test a tout ses icônes, je viens de déplacer les répertoires de configuration de plasma, et en relançant ma session j'ai retrouvé des icônes. je n'ai plus qu'a reconfigurer mon bureau. merci encore désolé pour le bruit, j'aurai pus effectivement trouver cela tout seul ! Gérard -- == https://www.leregardduchat.fr/ ==
Re: icônes de kde disparus
Bonjour, Le 2024-04-24 12:20, Kohler Gerard a écrit : avez vous des indications pour retrouver mes icônes ? Qu'est-ce que ça donne avec un compte utilisateur de test ? - si il a le même problème, alors c'est côté système qu'il faudra chercher (apt-get) - si il n'a pas le même problème, alors c'est du côté de tes préférences utilisateur (ton homedir) qu'il faudra chercher. Sébastien
Re: icônes de kde disparus
Regardes dans: kde-style-oxygen-qt5 et que donne : systemsettings
Re: icônes de kde disparus
Regardes dans: kde-style-oxygen-qt5 et que donne : systemsettings
icônes de kde disparus
bonjour, suite à une manœuvre hasardeuse de ma part je me retrouve avec un problème d'absence d’icône sous KDE. mon répertoire personnel se trouve sur un DD indépendant du DD contenant les partitions système. il y a quelques mois je suis passé sous Trixie et après quelques jours de test j'ai intégré mon répertoire personnel sous Trixie (j'étais auparavant sous Bullseye) mais récemment les mises à jour de Trixie on rendu le système instable et surtout avec la perte de certains programmes importants (entre autre le retrait de Thunderbird des paquets Debian par exemple) je me suis vu contraint de revenir sous Bullseye. la manœuvre c'est bien passée sauf en ce qui concerne les icônes de KDE que j'ai perdus. j'ai tout mis à jour (apt-get update & apt-get upgrade) mais rien n'y fait. je n'ai pas trouvé les paquets contenant les icônes pour les mettre à jour, et je sèche sur les manœuvres à effectuer. avez vous des indications pour retrouver mes icônes ? merci Gérard -- == https://www.leregardduchat.fr/ ==
kde troubles (was: tbird troubles)
On 2024-04-15, gene heskett wrote: > 32 gigs of memory. But the constraint is a 30-45 second delay in opening a new > write path to nv storage. This totally disables digikam's ability to import digikam is a kde application, so you need the kde stuff at least for it. I use it too, have less memory, and still have no delay problems.
Re: Gel écran XFCE4 et KDE
Bonjour Je me souviens avoir eu ce problème il y a environ 2 ou 3 ans. Ca avait l'air de coïncider avec l'activation de l'économiseur d'écran ou son extinction programmée pour l'économie d'énergie. La solution était de remplacer un paquet par une version plus récente, pas encore dispo dans la distribution. J'étais sous xubuntu. Essaye de voir si le délai d'inactivité coïncide avec l'extinction de l'écran ou la mise en route de l'écran de veille. Malheureusement je ne me souviens plus du paquet. Seulement que j'ai réussi à trouver la solution sur internet en tâtonnant sur les mots clés de ma recherche. Je me souviens que j'ai eu un peu de mal à avoir des résultats pertinents. Es tu à jour ? Le sam. 20 janv. 2024 à 11:10, Frederic Zulian a écrit : > Bonjour, > > Sous XFCE4 et KDE, mon écran se gèle après quelques minutes > d'inutilisation sauf pour le curseur de la souris que je peux bouger mais > sans pouvoir faire quelques actions que ce soient. Les notifications > continuent à apparaitre. > Je n'ai pas ce problème avec lxde ou lxqt > > Matériel : Lenovo Thinkbook > Versions : xfce4 4.18 kde-full 5:147 > > Une idée ? > > Frédéric ZULIAN > >
Gel écran XFCE4 et KDE
Bonjour, Sous XFCE4 et KDE, mon écran se gèle après quelques minutes d'inutilisation sauf pour le curseur de la souris que je peux bouger mais sans pouvoir faire quelques actions que ce soient. Les notifications continuent à apparaitre. Je n'ai pas ce problème avec lxde ou lxqt Matériel : Lenovo Thinkbook Versions : xfce4 4.18 kde-full 5:147 Une idée ? Frédéric ZULIAN
Re: Change suspend type from kde menu
Il 12/01/2024 22:51, Valerio Vanni ha scritto: As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) Yes, it's what I'm going to try :-) I found another issue: kaffeine also records DVB channels. So, if I stop play but it's recording, module cannot be removed. In method I find a "toggle instant record", but it doesn't help because it changes between on and off. If it's not recording and I "toggle", then it starts recording and grabs device. It doesn't seem simple to tell *if* it's recording.
Re: Change suspend type from kde menu
Il 14/01/2024 05:04, Max Nikulin ha scritto: lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled. Which package does tags.so belong to in your case? I believe you that file indexer is disabled, but some components may still be called for reasons unclear for me. Maybe they do something useful. tags.so belongs to baloo-kf5, but "balooctl --status" says that it's disabled.
Ironically, in freshly installed Debian-12.3 KDE (debian-live-12.4.0-amd64-kde.iso) when session is restored, 'konsole' is not restored
Hello All, I wanted to file a bug using the official Debian bug filing system, but since I do not know against what package to file the bug I'm writing to this list. Essentially, the subject says it all. Session restore mechanism works as expected except for the fact that 'konsole' is not restored. Other terminal emulators (like 'xterm') and other applications (like 'firefox') are restored OK. The bug happens always. I didn't exclude any application from session restore - as I said above, it was a fresh install (on a totally formatted disk). Anyway, I checked in system settings that no application is excluded from session restore. Thanks in advance, Sergei.
Re: Change suspend type from kde menu
On 13/01/2024 22:37, Valerio Vanni wrote: Il 13/01/2024 16:20, Max Nikulin ha scritto: And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled. Which package does tags.so belong to in your case? I believe you that file indexer is disabled, but some components may still be called for reasons unclear for me. Maybe they do something useful. Leaking of file descriptors to child processes is not uncommon issue. Ideally both sides should take measures to avoid it, but to mitigate it is enough that any party handle file descriptors with care. However it is just my guess, maybe actual cause of the issue with tags.so is completely different. P.S. Years ago KDE developers decided to remove controls that allowed to disable file indexer. Otherwise nobody would use it since previous version caused enough troubles. Fortunately that times have gone.
Re: Change suspend type from kde menu
Il 13/01/2024 16:20, Max Nikulin ha scritto: And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled.
Re: Change suspend type from kde menu
On 13/01/2024 04:39, Valerio Vanni wrote: Il 12/01/2024 17:24, Max Nikulin ha scritto: On 12/01/2024 21:36, Valerio Vanni wrote: dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop It seems implementation of MPRIS in kaffeine differs from what other KDE components expect. E.g. media control buttons does not appear on the lock screen. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior. And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved.
Re: Change suspend type from kde menu
Il 12/01/2024 21:15, Franco Martelli ha scritto: > Tried, it works on DVB play. > > dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) Yes, it's what I'm going to try :-) Force module unloading cannot work, it requires a specific option in kernel config that I've never enabled. You can also try to not remove the module and check if stop Kaffeine, suspend/resume, play Kaffeine is enough. The module does not support suspend / resume at all. If you boot the system, *don't* open kaffeine or anything, suspend and resume, module is already in an unworkable state.
Re: Change suspend type from kde menu
Il 12/01/2024 17:24, Max Nikulin ha scritto: On 12/01/2024 21:36, Valerio Vanni wrote: Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop The question is if this action can be a replacement for killing kaffeine before unloading the dvb kernel module. I'll try. It could make the script simpler. If I launch kaffeine without --lastchannel, it should work. That way I'd have to open tv interface by hand when I start kaffeine. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior. This is a file descriptors list of kioslave process, with a plain launch: lrwx-- 1 valerio valerio 64 12 gen 20.53 0 -> /dev/pts/1 lrwx-- 1 valerio valerio 64 12 gen 20.53 1 -> /dev/pts/1 lrwx-- 1 valerio valerio 64 12 gen 20.53 19 -> '/memfd:pulseaudio (deleted)' lrwx-- 1 valerio valerio 64 12 gen 20.53 2 -> /dev/pts/1 lr-x-- 1 valerio valerio 64 12 gen 20.53 25 -> /run/user/1000/dvbpipe.m2t l-wx-- 1 valerio valerio 64 12 gen 20.53 26 -> /run/user/1000/dvbpipe.m2t lrwx-- 1 valerio valerio 64 12 gen 20.53 3 -> 'anon_inode:[eventfd]' lr-x-- 1 valerio valerio 64 12 gen 20.53 31 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.53 4 -> 'socket:[10323613]' And this is one with a --lastchannel launch: lr-x-- 1 valerio valerio 64 12 gen 20.52 0 -> 'pipe:[9256505]' lrwx-- 1 valerio valerio 64 12 gen 20.52 1 -> 'socket:[71658]' lrwx-- 1 valerio valerio 64 12 gen 20.52 19 -> '/memfd:pulseaudio (deleted)' lrwx-- 1 valerio valerio 64 12 gen 20.52 2 -> 'socket:[71658]' lr-x-- 1 valerio valerio 64 12 gen 20.52 25 -> /run/user/1000/dvbpipe.m2t l-wx-- 1 valerio valerio 64 12 gen 20.52 26 -> /run/user/1000/dvbpipe.m2t lrwx-- 1 valerio valerio 64 12 gen 20.52 3 -> 'anon_inode:[eventfd]' lr-x-- 1 valerio valerio 64 12 gen 20.52 31 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 12 gen 20.52 36 -> 'pipe:[9253331]' l-wx-- 1 valerio valerio 64 12 gen 20.52 37 -> 'pipe:[9253331]' lrwx-- 1 valerio valerio 64 12 gen 20.52 4 -> 'socket:[9247546]' lr-x-- 1 valerio valerio 64 12 gen 20.52 48 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.52 54 -> '/memfd:pulseaudio (deleted)' But perhaps it says nothing new.
Re: Change suspend type from kde menu
On 12/01/24 at 15:38, Valerio Vanni wrote: ~$ busctl --user tree | grep mpris Service org.mpris.kaffeine: Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? Yes, it has play/stop button. I saw that in another post you have find the dbus object and method to stop/play Kaffeine: > Tried, it works on DVB play. > > dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) You can also try to not remove the module and check if stop Kaffeine, suspend/resume, play Kaffeine is enough. -- Franco Martelli
Re: Change suspend type from kde menu
On 12/01/2024 21:36, Valerio Vanni wrote: Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop The question is if this action can be a replacement for killing kaffeine before unloading the dvb kernel module. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior.
Re: Change suspend type from kde menu
Il 12/01/2024 15:03, Franco Martelli ha scritto: On 11/01/24 at 15:10, Valerio Vanni wrote: Yes, I tried, but I didn't see any "stop". There is a .Quit, but for this I already have "kill" command and I have to start it again. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / Out of curiosity could you post the output of the following command: ~$ busctl --user tree | grep mpris Service org.mpris.kaffeine: Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? Yes, it has play/stop button.
Re: Change suspend type from kde menu
Il 12/01/2024 12:08, Valerio Vanni ha scritto: Il 12/01/2024 03:52, Max Nikulin ha scritto: I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method - - - I saw that, but I think it's for media player component of kaffeine. With that, you could stop the play of an audio or video file. Do you think it can also act on DVB channels? I can give it a try. Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Play
Re: Change suspend type from kde menu
On 11/01/24 at 15:10, Valerio Vanni wrote: Yes, I tried, but I didn't see any "stop". There is a .Quit, but for this I already have "kill" command and I have to start it again. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / Out of curiosity could you post the output of the following command: ~$ busctl --user tree | grep mpris Don't forget to run Kaffeine first. Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? -- Franco Martelli
Re: Change suspend type from kde menu
Il 12/01/2024 03:52, Max Nikulin ha scritto: I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method - - - I saw that, but I think it's for media player component of kaffeine. With that, you could stop the play of an audio or video file. Do you think it can also act on DVB channels? I can give it a try. So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. Baloo is already disabled. Finally I am confused. If tags.so processes die after some interval of time, does it mean that the kernel module can be unloaded even when kaffeine is started with --lastchannel and enough time has passed since its start? From its stop, not from its start. There are two main cases: plain kaffeine and lastchannel one. I open kaffeine without options, I play a DVB channel. kioslave process is active, but has no lock on /dev/dvb/* I stop play and I can immediately remove module. Even if that kioslave process is active. I open kaffeine with --lastchannel, and kioslave process already has a lock on /dev/dvb/* I stop play and cannot remove module, it's locked from kioslave. When some minute has passed, kioslave disappears and I can remove module. Now I see another case: even during channel play, some time kioslave process disappears. At that point, if I stop play, I can remove module.
Re: Change suspend type from kde menu
On 11/01/2024 22:45, Valerio Vanni wrote: Il 11/01/2024 16:25, Max Nikulin ha scritto: On 11/01/2024 21:10, Valerio Vanni wrote: valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method- -- I have no idea if MPRIS API spec prescribes to implement /org/mpris/MediaPlayer2 or /Player /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket lsof, unlike ps, reports a kind of access, e.g. CWD why some file is opened. So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. Have you checked if the tags.so process opens some devices under /dev/dvb? An idea is that this process seizes its read attempts after some timeout. I would not expect it from an indexing framework. From my point of view it should read only regular files, otherwise it is a bug. I do not know which way file tags are implemented in KDE (a hidden file inside a directory or some DB in the user home directory), so it hard to reason why baloo holds something in /dev Maybe it is something with "recently used" (~/.local/share/recently-used.xbel), but I am unsure if kaffeine intentionally notifies desktop environment or it calls a method that is not appropriate in the context of /dev/ Finally I am confused. If tags.so processes die after some interval of time, does it mean that the kernel module can be unloaded even when kaffeine is started with --lastchannel and enough time has passed since its start? From another message: I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error "Failed to connect to bus: No medium found" I can confirm it. Actually I was asking about "$kafdis XDG_CURRENT_DESKTOP=KDE", but Thunderbird broke formatting around. It has hidden notion of cited text and it affects wrapping in the case of flowed text format. E.g. "> some text" typed directly does not become a part of citation, it is necessary to paste "copy text" from clipboard using [Ctrl+Shift+O]. On the other hand "this line contains cited text" state may persist for lines having no text. Sometimes it happens during adding text between cited lines. I have not steps to reproduce suitable for bug report yet.
Re: Change suspend type from kde menu
Il 11/01/2024 16:25, Max Nikulin ha scritto: On 11/01/2024 21:10, Valerio Vanni wrote: There is a .Quit, but for this I already have "kill" command and I have to start it again. Applications might handle D-Bus messages more gracefully than SIGINT or SIGTERM signals. However in the case of kaffeine it is unlikely that some data may be lost. It's what I think too. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. I am surprised that it dies immediately if you kill kaffeine. It seems to always die, I've never had an error during rmmod.
Re: Change suspend type from kde menu
Il 11/01/2024 15:21, Valerio Vanni ha scritto: Il 11/01/2024 04:57, Max Nikulin ha scritto: On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? It's all left there from when I used setpriv to launch directly kaffeine, before I decided to use systemd-run. I'll try to remove it, now I checked and they are all listed in systemd user environment. I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error "Failed to connect to bus: No medium found"
Re: Change suspend type from kde menu
On 11/01/2024 21:10, Valerio Vanni wrote: There is a .Quit, but for this I already have "kill" command and I have to start it again. Applications might handle D-Bus messages more gracefully than SIGINT or SIGTERM signals. However in the case of kaffeine it is unlikely that some data may be lost. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy org.freedesktop.MediaPlayer interface - - - .Identity method - s - .MprisVersion method - (qq) - .Quit method - - - Looks quite useless. Does ".Stop" appear when kaffeine is playing some channel? lsof | grep /dev/dvb shows 10315 ? S 0:00 /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. I am surprised that it dies immediately if you kill kaffeine. Actually I run out of ideas. It seems you have a working solution and further polishing is optional. On 10/01/2024 01:32, Valerio Vanni wrote: So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. I don't see authentication requests, but it still stays under system.slice. By mistake, I tried something like (missed --user) setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --slice=app.slice -- \ xterm and I wrongly decided that systemd *user* session rejects D-Bus messages basing on some process attributes, e.g. looking into /proc/PID/sessionid (set by pam_loginuid) and comparing it with logind state (loginctl list-sessions). The user is not added to any groups with higher privileges. Fortunately proper command works and no tricks are required besides setting the path where D-Bus socket should be found.
Re: Change suspend type from kde menu
Il 11/01/2024 04:57, Max Nikulin ha scritto: On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? It's all left there from when I used setpriv to launch directly kaffeine, before I decided to use systemd-run. I'll try to remove it, now I checked and they are all listed in systemd user environment. I find it not really safe to use $kafdis without quotes. Yes, neither I liked to catch that string. But I considered it a temporary solution.
Re: Change suspend type from kde menu
Il 11/01/2024 05:10, Max Nikulin ha scritto:
On 10/01/2024 01:59, Valerio Vanni wrote:
Il 06/01/2024 17:38, Max Nikulin ha scritto:
I would expect something like "Stop" either from /Player or from
org.mpris.kaffeine.
I too expected something similar: stop and play (play for resume)
Have you tried "tree" and "introspect" for org.mpris.kaffeine (not
org.kde.kaffeine)? It works for mpv:
Yes, I tried, but I didn't see any "stop". There is a .Quit, but for
this I already have "kill" command and I have to start it again.
valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /
NAMETYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer interface - --
.GetMachineId method- s-
.Ping method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv --
.PropertiesChanged signalsa{sv}as --
org.freedesktop.MediaPlayer interface - --
.Identity method- s-
.MprisVersion method- (qq) -
.Quit method- --
busctl --user call org.mpris.MediaPlayer2.mpv \
/org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \
Stop
For this we don't need to look here:
"rmmod: ERROR: Module cx23885 is in use" seems enough to see that
kernel module cannot be removed.
I am surprised by it. You have shown that kaffeine closes the device, so
it should be possible to remove the kernel module:
Started with --lastchannel
Video stopped:
lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0
no more /dev/dvb/, but still unable to remove module cx23885
My hypotheses:
- there are more kaffeine processes (ps xuwf)
No, it has only one.
- some external process is holding the device, e.g. pulseaudio or
pipeware sound server. Tools that might help to find it: lsof or fuser
(unsure concerning proper options)
- Some other IPC exposed by the driver and used by kaffeine.
- I have not idea if it is possible to create direct connection between
the dvb device and the video card so that data pass without intermediate
interaction with kaffeine.
fuser -a /dev/dvb/adapter0/demux0 shows nothing
lsof | grep /dev/dvb shows
10315 ?S 0:00
/lib/x86_64-linux-gnu/libexec/kf5/kioslave5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags
local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket
But after some minutes this process disappeared, and I could rmmod.
Perhaps with --lastchannel it's slower to release it?
Re: Change suspend type from kde menu
Il 11/01/2024 04:48, Max Nikulin ha scritto: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. It is independent ideas: - Do not deal with user processes in system context (like /usr/lib/systemd/system-sleep/ scripts) - Try to release dvb tuner device, so module can be unloaded. I believe, it is a bug in the cx23885 module that it can not handle suspend/resume (and probably hibernate/thaw). I agree. If cx23885 module could handle suspend/resume, we wouldn't need all this mess. Since we are talking about this module, I quote from another of your messages: P.S. You have explicit modprobe cx23885. Does it mean that this module is not autoloaded when udev discovers the device? The module is autoloaded when system boots. But if I (after having moved away the script from /usr/lib/systemd/system-sleep/) rmmod systemctl-suspend resume pc the module is not loaded. When I used pm-suspend, remove and reload was managed from the line SUSPEND_MODULES="cx23885" in /etc/pm/config.d/modules And now from rmmod and modprobe in my script. By itself... no load. The following is related to avoiding "setpriv" in system context and listening for D-Bus events in user session scope: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" suspend: signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep^^^ boolean true resume: signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false ---^ A tiny python script may be more convenient than dbus-monitor and similar tools. Killing and starting kaffeine in response to these signals may be a workaround if the application does not allow to release the device. Not stopping playback and not releasing the device in response to the PrepareForSleep signal, from my point of view, is a bug in kaffeine. I have no idea if vlc (broken hardware acceleration in bookworm) or another application may be an alternative for you. To watch television, kaffeine seems very good to me.
Re: Change suspend type from kde menu
On 10/01/2024 01:59, Valerio Vanni wrote: Il 06/01/2024 17:38, Max Nikulin ha scritto: I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I too expected something similar: stop and play (play for resume) Have you tried "tree" and "introspect" for org.mpris.kaffeine (not org.kde.kaffeine)? It works for mpv: busctl --user call org.mpris.MediaPlayer2.mpv \ /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \ Stop For this we don't need to look here: "rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel module cannot be removed. I am surprised by it. You have shown that kaffeine closes the device, so it should be possible to remove the kernel module: Started with --lastchannel Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0 no more /dev/dvb/, but still unable to remove module cx23885 My hypotheses: - there are more kaffeine processes (ps xuwf) - some external process is holding the device, e.g. pulseaudio or pipeware sound server. Tools that might help to find it: lsof or fuser (unsure concerning proper options) - Some other IPC exposed by the driver and used by kaffeine. - I have not idea if it is possible to create direct connection between the dvb device and the video card so that data pass without intermediate interaction with kaffeine.
Re: Change suspend type from kde menu
On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? I find it not really safe to use $kafdis without quotes. The pattern in grep is rather loose one, it may capture several variables and some of variables may have spaces in their values. On the other hand the current pattern should capture WAYLAND_DISPLAY. The point is that kaffeine inherits environment from systemd user session. I have all necessary variables set in systemctl --user show-environment My command works for me without explicit environment tricks. systemd-run --user --slice=app.slice /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 P.S. You have explicit modprobe cx23885. Does it mean that this module is not autoloaded when udev discovers the device?
Re: Change suspend type from kde menu
On 11/01/2024 02:32, Valerio Vanni wrote: Il 08/01/2024 04:29, Max Nikulin ha scritto: On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. It is independent ideas: - Do not deal with user processes in system context (like /usr/lib/systemd/system-sleep/ scripts) - Try to release dvb tuner device, so module can be unloaded. I believe, it is a bug in the cx23885 module that it can not handle suspend/resume (and probably hibernate/thaw). The following is related to avoiding "setpriv" in system context and listening for D-Bus events in user session scope: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" suspend: signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep^^^ boolean true resume: signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false ---^ A tiny python script may be more convenient than dbus-monitor and similar tools. Killing and starting kaffeine in response to these signals may be a workaround if the application does not allow to release the device. Not stopping playback and not releasing the device in response to the PrepareForSleep signal, from my point of view, is a bug in kaffeine. I have no idea if vlc (broken hardware acceleration in bookworm) or another application may be an alternative for you. Stopping playback through D-Bus by a custom script might be performed either from PrepareForSleep D-Bus signal listener or from a system-sleep script. I will respond to another message.
Re: Change suspend type from kde menu
Il 08/01/2024 04:29, Max Nikulin ha scritto: On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 comm="dbus-monitor --system type='signal',interface='org") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. signal time=1704679328.754948 sender=org.freedesktop.DBus -> destination=:1.1080 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1080" signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false A tiny python script may be more convenient than dbus-monitor and similar tools. It seems too complex for me.
Re: Change suspend type from kde menu
Il 07/01/2024 06:44, Max Nikulin ha scritto: It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm I have realized that earlier I forgot to add --user to systemd-run. To my surprise, it does not work if I set BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of XDG_RUNTIME_DIR. I expected that the former is required for systemd-run. This command works from a root shell prompt, I hope it should work during resume as well. It works :-) setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ systemd-run --user --slice=app.slice /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Even during resume it goes into right slice.
Re: Change suspend type from kde menu
Il 06/01/2024 17:38, Max Nikulin ha scritto: On 06/01/2024 00:07, Valerio Vanni wrote: Now I'm looking: services are ├─/MainApplication ├─/Player ├─/Television ├─/TrackList └─/org └─/org/kde └─/org/kde/kaffeine I tried to introspect the more likely, MainApplication and Television .RemoveProgram method u - - Do you have any idea what it should do? I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I too expected something similar: stop and play (play for resume) If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. What should I find here? If no file descriptor is resolved to /dev/ (or maybe /sys) then likely the kernel module may be removed without killing the application. For this we don't need to look here: "rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel module cannot be removed. Compare opened file descriptors when video is playing and when it is stopped. Started with --lastchannel Video playing: lr-x-- 1 valerio valerio 64 9 gen 19.47 0 -> /dev/null lrwx-- 1 valerio valerio 64 9 gen 19.47 34 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.47 35 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.47 40 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 41 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 42 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 43 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 44 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.47 55 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 56 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 57 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 59 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.47 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0 no more /dev/dvb/, but still unable to remove module cx23885 Started without --lastchannel Video playing: lrwx-- 1 valerio valerio 64 9 gen 19.56 37 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.56 43 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.56 47 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 49 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 50 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 51 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 52 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.56 58 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 59 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 60 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 It all seems like before, but this time module can be removed.
Re: Change suspend type from kde menu
Il 06/01/2024 16:19, Max Nikulin ha scritto: On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 I have not figured out how to do it, but systemd-run should not use --uid since this way it makes the application a part of system.slice. Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. I confirm, it's under system.slice. So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. I don't see authentication requests, but it still stays under system.slice.
Re: Change suspend type from kde menu
On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 comm="dbus-monitor --system type='signal',interface='org") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. signal time=1704679328.754948 sender=org.freedesktop.DBus -> destination=:1.1080 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1080" signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false A tiny python script may be more convenient than dbus-monitor and similar tools.
Re: Change suspend type from kde menu
On 06/01/2024 22:19, Max Nikulin wrote: On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm I have realized that earlier I forgot to add --user to systemd-run. To my surprise, it does not work if I set BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of XDG_RUNTIME_DIR. I expected that the former is required for systemd-run. This command works from a root shell prompt, I hope it should work during resume as well.
Re: Change suspend type from kde menu
On 06/01/2024 00:07, Valerio Vanni wrote: Now I'm looking: services are ├─/MainApplication ├─/Player ├─/Television ├─/TrackList └─/org └─/org/kde └─/org/kde/kaffeine I tried to introspect the more likely, MainApplication and Television .RemoveProgram method u - - Do you have any idea what it should do? I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I have not tried MPRIS D-Bus interface in action though. If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. What should I find here? If no file descriptor is resolved to /dev/ (or maybe /sys) then likely the kernel module may be removed without killing the application. Compare opened file descriptors when video is playing and when it is stopped.
Re: Change suspend type from kde menu
On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 I have not figured out how to do it, but systemd-run should not use --uid since this way it makes the application a part of system.slice. Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. I tried command from a ssh session root@... Behavior may be different from suspend/resume tasks since the session is associated with a pty.
Re: Change suspend type from kde menu
Il 06/01/2024 01:04, Greg Wooledge ha scritto: On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote: This way works, I don't know if it has security flaws. systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 systemd-run(1) appears to have its own --uid and --gid options. If you can live without supplementary groups and the variables that are set by --reset-env, you can probably drop the setpriv part and just use systemd-run's --uid and --gid. On the other hand, if it ain't broke I tried the options when I tried systemd-run, but it didn't work. I only added them, but now I see that you have to choose: or them or setpriv. Now it's: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Outcome is the same. The only difference is that a line is added to syslog about unit creation: Started kaffeine-resumed.service - /usr/bin/env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine --lastchannel.
Re: Change suspend type from kde menu
On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote: > This way works, I don't know if it has security flaws. > > systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid > "$kafgid" --init-groups --reset-env \ > env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis > XDG_CURRENT_DESKTOP=KDE \ > /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 > systemd-run(1) appears to have its own --uid and --gid options. If you can live without supplementary groups and the variables that are set by --reset-env, you can probably drop the setpriv part and just use systemd-run's --uid and --gid. On the other hand, if it ain't broke
Re: Change suspend type from kde menu
Il 05/01/2024 21:47, Valerio Vanni ha scritto: Il 05/01/2024 21:24, Valerio Vanni ha scritto: For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. If I use "su" method instead of "setpriv" one, kaffeine doesn't go into systemd-suspend.service unit, and neither to user@1000.service one. Instead, it goes to session-c2.scope. And works. And systemd-suspend.service is finished and deactivated at the moment of resume. It seems that systemd-suspend.service wants to end as soon as possible, but it cannot because it has kaffeine inside. So it waits 90 seconds, and then terminates kaffeine. This way works, I don't know if it has security flaws. systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 All is launched from systemd-run. I choosed kaffeine-resumed as unit name, but if you don't put any a casual name one is created. So systemd-suspend.service unit is free and can close.
Re: Change suspend type from kde menu
Il 05/01/2024 21:24, Valerio Vanni ha scritto: For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. And I found now that whole script cannot continue after this "takeover": final "rm" commands are not run. - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend. If I use "su" method instead of "setpriv" one, kaffeine doesn't go into systemd-suspend.service unit, and neither to user@1000.service one. Instead, it goes to session-c2.scope. And works. And systemd-suspend.service is finished and deactivated at the moment of resume. It seems that systemd-suspend.service wants to end as soon as possible, but it cannot because it has kaffeine inside. So it waits 90 seconds, and then terminates kaffeine.
Re: Change suspend type from kde menu
Il 05/01/2024 20:47, Franco Martelli ha scritto: On 05/01/24 at 20:01, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. Could it be that he doesn't run Kaffeine in the background? ... /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 & If I add that final &, kaffeine doesn't start at all. For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. And I found now that whole script cannot continue after this "takeover": final "rm" commands are not run. - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend.
Re: Change suspend type from kde menu
On 05/01/24 at 20:01, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. Could it be that he doesn't run Kaffeine in the background? ... /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 & ^ Cheers, -- Franco Martelli
Re: Change suspend type from kde menu
Il 05/01/2024 20:10, Valerio Vanni ha scritto: My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. If you see my latest message, it goes in a different unit and is shut down at the end of resume. Perhaps I could try to remove --reset-env and set some parameter by hand If I remove --reset-env and set HOME, kaffeine starts. It seems that issue was to find file in home directory. But still in systemd-suspend.service unit. If, in a root shell, I launch setpriv --reuid 1000 --regid 1000 --init-groups \ env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 HOME=/home/valerio XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1 kaffeine starts in user@1000.service. Also with --reset-env. It's only during resume that it gets into systemd-suspend.service.
Re: Change suspend type from kde menu
Il 05/01/2024 20:01, Greg Wooledge ha scritto: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. If you see my latest message, it goes in a different unit and is shut down at the end of resume. Perhaps I could try to remove --reset-env and set some parameter by hand
Re: Change suspend type from kde menu
On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: > setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups > --reset-env \ > env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis > XDG_CURRENT_DESKTOP=KDE \ > /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 > - > Uid, gid and display are saved and restored, so it can works also for other > users and x servers. > But with setpriv kaffeine was complaining it couldn't find .config/, > database etc and so it wasn't able to start. It seems that was ignorming > original user's home and tried to access root home. > > Adding the parameter --reset-env seems to fix, kaffeine restarts. > But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later.
Re: Change suspend type from kde menu
Il 05/01/2024 17:52, Valerio Vanni ha scritto: Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. -Kaffeine launched by hand stays up -Kaffeine restored with "su" method stays up -Kaffeine restored with "setpriv" method lasts only some minute I looked better: it lasts 90 seconds. Not from kaffeine launch, from PC resume. If I try to set a delay inside the script, so that kaffeine launches after 80 seconds, it starts and then after 10 seconds it's closed. If I set the delay after 90 seconds, it doesn't start at all. I tried to redirect output to a file /usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1 The file is created and gets data, but nothing is added at the moment of termination. In syslog I found these lines at that moment: - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend. 2024-01-05T19:39:20.505334+01:00 newton NetworkManager[3208]: [1704479960.5049] manager: sleep: wake requested (sleeping: yes enabled: yes) 2024-01-05T19:39:20.505722+01:00 newton ModemManager[3206]: [sleep-monitor-systemd] system is resuming -- It seems that something of resume process is ending 90 seconds after resume. And Service ":1.299" that gets unregistered is just kaffeine. And now I see a difference between kaffeine launched by hand and resumed one: busctl --user | grep kaffeine with manual start -- :1.30544374 kaffeinevalerio :1.305user@1000.service - - :1.30644374 kaffeinevalerio :1.306user@1000.service - - :1.30744374 kaffeinevalerio :1.307user@1000.service - - org.kde.kaffeine 44374 kaffeinevalerio :1.305user@1000.service - - org.mpris.kaffeine44374 kaffeinevalerio :1.305user@1000.service - - -- after resume -- 1.31245857 kaffeinevalerio :1.312systemd-suspend.service - - :1.31345857 kaffeinevalerio :1.313systemd-suspend.service - - :1.31445857 kaffeinevalerio :1.314systemd-suspend.service - - org.kde.kaffeine 45857 kaffeinevalerio :1.312systemd-suspend.service - - org.mpris.kaffeine45857 kaffeinevalerio :1.312systemd-suspend.service - - --
Re: Change suspend type from kde menu
Il 04/01/2024 17:11, Max Nikulin ha scritto:
On 04/01/2024 22:21, Valerio Vanni wrote:
Il 04/01/2024 15:48, Max Nikulin ha scritto:
Is it really necessary to kill kaffeine or it is enough to pause or
to stop playing? It might be possible using a D-Bus query.
[...]
If it's started normally, it's enough to stop playing
But how would you try to request it to stop?
I would play with "busctl --user", "busctl --user tree SERVICE", "busctl
--user introspect SERVICE OBJECT" to figure out if suitable methods are
available.
I never used busctl.
Now I'm looking: services are
├─/MainApplication
├─/Player
├─/Television
├─/TrackList
└─/org
└─/org/kde
└─/org/kde/kaffeine
I tried to introspect the more likely, MainApplication and Television
/MainApplication
AMETYPE SIGNATURE RESULT/VALUE
FL>
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method- s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method- s -
.Ping method- - -
org.freedesktop.DBus.Properties interface - - -
.Getmethodssv -
.GetAll methods a{sv} -
.Setmethodssv - -
.PropertiesChanged signalsa{sv}as - -
org.qtproject.Qt.QApplication interface - - -
.aboutQtmethod- - -
.autoSipEnabled method- b -
.closeAllWindowsmethod- - -
.setAutoSipEnabled methodb - -
.setStyleSheet methods - -
lines 1-17
/Television
AMETYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer interface - --
.GetMachineId method- s-
.Ping method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv --
.PropertiesChanged signalsa{sv}as --
org.freedesktop.MediaPlayer interface - --
.DigitPressed methodi --
.ListProgramSchedulemethod- a(uib) -
.PlayChannelmethods --
.PlayLastChannelmethod- --
.RemoveProgram methodu --
If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.
Is there an action that releases the device? "ls -l /proc/PID/fd" to check.
What should I find here?
Ideally kaffeine should implement the Inhibit interface and should close
devices on suspend or on user session switch.
Ideally...
Re: Change suspend type from kde menu
Il 04/01/2024 16:27, Greg Wooledge ha scritto: On Thu, Jan 04, 2024 at 03:07:59PM +0100, Valerio Vanni wrote: Il 03/01/2024 17:41, Greg Wooledge ha scritto: The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. Can you explain better? http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html Thank you. Now I'm trying this way: - #!/bin/bash case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending kafpid=$(pgrep kaffeine) kafuid=$(stat -c "%u" /proc/$kafpid) kafgid=$(stat -c "%g" /proc/$kafpid) kafdis=$(cat /proc/$kafpid/environ | tr '\0' '\n' | grep DISPLAY) echo $kafuid > /temp/kafuid.txt echo $kafgid > /temp/kafgid.txt echo $kafdis > /temp/kafdis.txt kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 kaffeine_killed=$(cat /temp/kafstate.txt) kafuid=$(cat /temp/kafuid.txt) kafgid=$(cat /temp/kafgid.txt) kafdis=$(cat /temp/kafdis.txt) if [[ $kaffeine_killed == "" ]]; then setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 fi rm -f /temp/kafstate.txt rm -f /temp/kafuid.txt rm -f /temp/kafgid.txt rm -f /temp/kafdis.txt ;; esac - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. -Kaffeine launched by hand stays up -Kaffeine restored with "su" method stays up -Kaffeine restored with "setpriv" method lasts only some minute
Re: Change suspend type from kde menu
On 04/01/2024 22:21, Valerio Vanni wrote: Il 04/01/2024 15:48, Max Nikulin ha scritto: Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. [...] If it's started normally, it's enough to stop playing But how would you try to request it to stop? I would play with "busctl --user", "busctl --user tree SERVICE", "busctl --user introspect SERVICE OBJECT" to figure out if suitable methods are available. If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. Ideally kaffeine should implement the Inhibit interface and should close devices on suspend or on user session switch.
Re: Change suspend type from kde menu
On Thu, Jan 04, 2024 at 03:07:59PM +0100, Valerio Vanni wrote: > Il 03/01/2024 17:41, Greg Wooledge ha scritto: > > The su command is not an ideal choice for this, in fact. The setpriv(1) > > command is better suited for running programs as other user accounts, > > without doing crazy PAM stuff like su does. > > Can you explain better? http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html
Re: Change suspend type from kde menu
Il 04/01/2024 15:48, Max Nikulin ha scritto: On 04/01/2024 21:03, Valerio Vanni wrote: kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. My expectation is that the device should be closed. I choosed to kill it because it seemed easier. If it's started normally, it's enough to stop playing But how would you try to request it to stop? If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again.
Re: Change suspend type from kde menu
On 04/01/2024 21:03, Valerio Vanni wrote: kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. My expectation is that the device should be closed.
Re: Change suspend type from kde menu
Il 03/01/2024 17:41, Greg Wooledge ha scritto: The UID of 1000 will have to be verified, as well as the YOURUSER. UID 1000 is what Debian uses for the initial user account that's created during installation, but if for some reason that's not the account who's currently logged in, then obviously this won't work. In my case it's ok The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. Can you explain better? It also has the advantage of not needing a username -- it can work with just the UID. uid=1000 gid=1000 setpriv --reuid "$uid" --regid "$gid" --init-groups \ env XDG_RUNTIME_DIR=/run/user/"$uid" DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE \ keffeine >/dev/null 2>&1 & In a (used like a) single user system like this, I know both username and uid. In a multi-user one, you have to find them. And it doesn't seem simple.
Re: Change suspend type from kde menu
Il 03/01/2024 23:52, Valerio Vanni ha scritto: Il 03/01/2024 17:18, Franco Martelli ha scritto: On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: I had an idea to do a relaunch, but it's not always running. Now I've done this, to relaunch only if it was running: -- #!/bin/bash case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 kaffeine_killed=$(cat /temp/kafstate.txt) if [[ $kaffeine_killed == "" ]]; then /usr/bin/su valerio -c 'XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 &' fi rm -f /temp/kafstate.txt ;; esac --
Re: Change suspend type from kde menu
Il 03/01/2024 17:18, Franco Martelli ha scritto: On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: I had an idea to do a relaunch, but it's not always running. In the end don't put your script in /usr/sbin or /usr/bin use /usr/local/bin or /usr/local/sbin instead. I'll do :-)
Re: Change suspend type from kde menu
Am 03.01.2024 um 17:41 schrieb Greg Wooledge:
...
Bear in mind that this entire approach is a bit of a hack, with some
baked-in assumptions about who's logged in on which DISPLAY. If this
works for you, then that's great.
Manually restarting whatever application was affected would be simpler,
but...
But some people might need to extend
this to check for the actual logged-in account, rather than assuming it's
the primary user. (Left as an exercise, because unfortunately there is
no good way to do that, as far as I know anyway.)
I would start with something like
w | awk -e '$3==":0" { print $1 }'
A cleaner approach would be to record what was killed in the pre-suspend
phase and recreate that post wakeup, in my opinion.
Cheers,
Arno
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
Re: Change suspend type from kde menu
On Wed, Jan 03, 2024 at 05:18:19PM +0100, Franco Martelli wrote:
> /usr/bin/su YOURUSER -c 'XDG_RUNTIME_DIR=/run/user/1000
> DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine >/dev/null 2>&1 &'
> In place of YOURUSER you've to put your username, if you doubt the command
> "whoami" will tell you. Check if XDG_RUNTIME_DIR, XDG_CURRENT_DESKTOP and
> DISPLAY have the same value that I set, use the command "echo $variableName"
> to verify.
The UID of 1000 will have to be verified, as well as the YOURUSER.
UID 1000 is what Debian uses for the initial user account that's
created during installation, but if for some reason that's not the
account who's currently logged in, then obviously this won't work.
The su command is not an ideal choice for this, in fact. The setpriv(1)
command is better suited for running programs as other user accounts,
without doing crazy PAM stuff like su does. It also has the advantage
of not needing a username -- it can work with just the UID.
uid=1000 gid=1000
setpriv --reuid "$uid" --regid "$gid" --init-groups \
env XDG_RUNTIME_DIR=/run/user/"$uid" DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE \
keffeine >/dev/null 2>&1 &
Bear in mind that this entire approach is a bit of a hack, with some
baked-in assumptions about who's logged in on which DISPLAY. If this
works for you, then that's great. But some people might need to extend
this to check for the actual logged-in account, rather than assuming it's
the primary user. (Left as an exercise, because unfortunately there is
no good way to do that, as far as I know anyway.)
Re: Change suspend type from kde menu
On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: #!/bin/sh # Run from systemd-suspend.service to place under /usr/lib/systemd/system-sleep/ PATH=/sbin:/usr/sbin:/bin:/usr/bin case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending /usr/bin/killall kaffeine /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 /usr/bin/su YOURUSER -c 'XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine >/dev/null 2>&1 &' /usr/bin/sleep 1 ;; esac exit 0 In place of YOURUSER you've to put your username, if you doubt the command "whoami" will tell you. Check if XDG_RUNTIME_DIR, XDG_CURRENT_DESKTOP and DISPLAY have the same value that I set, use the command "echo $variableName" to verify. In the end don't put your script in /usr/sbin or /usr/bin use /usr/local/bin or /usr/local/sbin instead. Cheers -- Franco Martelli
Re: Change suspend type from kde menu
Il 28/12/2023 23:17, Valerio Vanni ha scritto: I found that pm-suspend works because it unloads and reloades that module In "/etc/pm/config.d/modules" there is --- SUSPEND_MODULES="cx23885" --- Now I've replicated this on systemd side with this script similar to yours: /usr/lib/systemd/system-sleep/dvb-suspend.sh --- #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885 exit 0 Now I've made a little change: #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/tv-sleep exit 0 and tv-sleep does: #!/bin/bash /usr/bin/killall kaffeine sleep 2 /usr/sbin/rmmod cx23885 This way, I don't have to remember to close kaffeine before suspend. At this point, there's a couple of improvements from pm-suspend method. One is this, the other is that pm-suspend required sudo.
Re: Change suspend type from kde menu
Il 29/12/2023 02:53, Max Nikulin ha scritto: systemd-sleep(8) does not mention /etc/systemd/system-sleep/ I am a bit puzzled by the following: https://www.freedesktop.org/software/systemd/man/latest/systemd-sleep.html Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor interface. https://www.freedesktop.org/wiki/Software/systemd/inhibit/ From my point of view dealing with D-Bus just to unload a kernel module is inconvenient. It is not an application that is started before suspend and should be running after resume. I am curious what is the recommended way for this particular use case. It seems to me something that should be done from an application. For example, in my case kaffeine could: stop dvb stream, unload module, and inverse actions after resume. But it wouldn't help: it would work only if kaffeine is open. This kernel module is unable to be suspended and resumed regardless of applications.
Re: Change suspend type from kde menu
On 29/12/2023 08:26, Valerio Vanni wrote: Il 29/12/2023 00:12, Charles Curley ha scritto: That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". This way it doesn't work. systemd-sleep(8) does not mention /etc/systemd/system-sleep/ I am a bit puzzled by the following: https://www.freedesktop.org/software/systemd/man/latest/systemd-sleep.html Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor interface. https://www.freedesktop.org/wiki/Software/systemd/inhibit/ From my point of view dealing with D-Bus just to unload a kernel module is inconvenient. It is not an application that is started before suspend and should be running after resume. I am curious what is the recommended way for this particular use case.
Re: Change suspend type from kde menu
Il 29/12/2023 00:12, Charles Curley ha scritto: On Thu, 28 Dec 2023 23:17:06 +0100 Valerio Vanni wrote: /usr/lib/systemd/system-sleep/dvb-suspend.sh That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". This way it doesn't work. I don't have an /etc/systemd/system-sleep directory. I created it by hand, but scripts inside are ignored.
Re: Change suspend type from kde menu
On Thu, 28 Dec 2023 23:17:06 +0100 Valerio Vanni wrote: > /usr/lib/systemd/system-sleep/dvb-suspend.sh That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Change suspend type from kde menu
Il 28/12/2023 15:48, Franco Martelli ha scritto: Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. My system, if I don't restart Picom, freeze after a resume from suspend. To fix it I've placed this shell script in "/usr/lib/systemd/system-sleep/" directory ~$ cat /usr/lib/systemd/system-sleep/00_sleep.sh I found that pm-suspend works because it unloads and reloades that module In "/etc/pm/config.d/modules" there is --- SUSPEND_MODULES="cx23885" --- Now I've replicated this on systemd side with this script similar to yours: /usr/lib/systemd/system-sleep/dvb-suspend.sh --- #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885 exit 0 --- This way it works, both with "systemctl suspend" and from kde menu.
Re: Change suspend type from kde menu
On 27/12/23 at 21:54, Valerio Vanni wrote: Il 25/12/2023 04:25, Valerio Vanni ha scritto: Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that It seems that kde uses "systemctl suspend": if I use it from shell, result is bad as if I suspend from menu. The defective kernel module cx23885: it doesn't support suspend and resume. It's a module for a DVB-T PCIe card. If I'm using kaffeine to watch DVB-T channels, I have to close it before suspending. If I leave it opened, kernel module comes up in a broken state. Closing and opening again kaffeine doesn't help, I have to -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. My system, if I don't restart Picom, freeze after a resume from suspend. To fix it I've placed this shell script in "/usr/lib/systemd/system-sleep/" directory ~$ cat /usr/lib/systemd/system-sleep/00_sleep.sh #!/bin/sh # Run from systemd-suspend.service to place under /usr/lib/systemd/system-sleep/ PATH=/sbin:/usr/sbin:/bin:/usr/bin case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending ;; post) #code execution AFTER resuming /usr/bin/sleep 5 /usr/bin/touch /home/frank/.config/picom.conf /usr/bin/sleep 1 ;; esac exit 0 So I think you've to do the same once you'll have a system that suspend to RAM properly. kind regards -- Franco Martelli
Re: Change suspend type from kde menu
On 28/12/2023 03:54, Valerio Vanni wrote: -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. I have never tried to tune suspend systemd settings, but I would try to create a single-shot service with "ExecStart=rmmod cx23885" that is "WantedBy" and "Before" suspend.target. Perhaps it is possible to find more details related to suspend.target and hibernate.target.
Re: Change suspend type from kde menu
Il 25/12/2023 04:25, Valerio Vanni ha scritto: Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that It seems that kde uses "systemctl suspend": if I use it from shell, result is bad as if I suspend from menu. The defective kernel module cx23885: it doesn't support suspend and resume. It's a module for a DVB-T PCIe card. If I'm using kaffeine to watch DVB-T channels, I have to close it before suspending. If I leave it opened, kernel module comes up in a broken state. Closing and opening again kaffeine doesn't help, I have to -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running.
Change suspend type from kde menu
Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that
Re: OT: Debian KDE no me abre enlances de whatsapp
Uso Chrome, perdón por no especificar antes
Re: OT: Debian KDE no me abre enlances de whatsapp
O 30/09/23 ás 23:36, Marcelo Eduardo Giordano escribiu: Tengo un problema menor pero muy molesto. Encuentro muchas páginas, como esta que tienen links a sus propias whatsapp https://www.simmons.com.ar/ cuando hago click abajo a la derecha en WhatsApp y posteriormente ir al chat me dice "Parece que no tienes instalada la aplicación WhatsApp." Me da la posibilidad de usar whatsappweb, pero le doy click ahi y tampoco funciona. Alguna idea? Gracias a la lista ¿Qué navegador usas? Yo uso KDE con el Firefox de Mozilla (no el empaquetado en Debian) y me funciona perfectamente.
OT: Debian KDE no me abre enlances de whatsapp
Tengo un problema menor pero muy molesto. Encuentro muchas páginas, como esta que tienen links a sus propias whatsapp https://www.simmons.com.ar/ cuando hago click abajo a la derecha en WhatsApp y posteriormente ir al chat me dice "Parece que no tienes instalada la aplicación WhatsApp." Me da la posibilidad de usar whatsappweb, pero le doy click ahi y tampoco funciona. Alguna idea? Gracias a la lista
Re: Please verify Gnome and KDE wiki articles for correctness
g...@wooledge.org wrote: >On Sat, Aug 26, 2023 at 07:40:46AM -0500, Nate Bargmann wrote: >> >> I was able to successfully change my password and update my Wiki home >> page a little while ago. It has been a long time since I created the >> account and don't recall what the process entailed. > >If I recall correctly, it used to be possible to create an account with >the standard wiki mechanisms, but that was discontinued due to spammers >abusing it. So, those of us who happened to create an account in the >early days got to do it the easy way, but now any new accounts need to >be approved by the wiki admins. Yup, that's exactly it. We used to cope with some scripts to do auto-whitelisting, but the spammers got worse and worse. So now we need to do manual approval. We try to be as responsive as possible to new signup requests, and we normally respond within a few hours. Not enough spammers on fire. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: Please verify Gnome and KDE wiki articles for correctness
It got delayed a year however: https://www.omgubuntu.co.uk/2023/08/ubuntu-23-10-wont-use-cups-snap Den fre 25 aug. 2023 kl 19:27 skrev Jeffrey Walton : > > Hi Everyone, > > A popular Debian-derived distro is preparing to change some printing > components from *.deb packages to Snapd. That is going to cause > trouble for users who remove Snapd, and still use *.deb packages. I > expect some users will want to move from the other distro to Debian. > > Two of the wiki articles that will help with a migration to Debian are > <https://wiki.debian.org/Gnome> and <https://wiki.debian.org/KDE>. > > It would be helpful if folks with Gnome and KDE experience would look > over the articles and provide corrections and updates. > > Jeff >
Re: Please verify Gnome and KDE wiki articles for correctness
On 8/26/23 06:17, Peter Ehlert wrote: On 8/25/23 13:22, Greg Wooledge wrote: On Fri, Aug 25, 2023 at 01:17:25PM -0700, Peter Ehlert wrote: I'm a Mate user, and I never thought to read https://wiki.debian.org/MATE until now. I see no flaws but there are several things that should be updated since it's last edit on December 24,2019 Who does that? You do. That's what a wiki is. "Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact w...@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online translation services.." I sent the requested email, I will wait and see I got a rapid reply from Steve McIntyre and have my new account created.
Re: Please verify Gnome and KDE wiki articles for correctness
* On 2023 26 Aug 07:57 -0500, Greg Wooledge wrote: > On Sat, Aug 26, 2023 at 07:40:46AM -0500, Nate Bargmann wrote: > > * On 2023 26 Aug 07:13 -0500, Anssi Saari wrote: > > > Nate Bargmann writes: > > > > > > > This Wiki is semi-private in that editing is not open to just everyone > > > > but may only be done through an account (apparently I have one and now > > > > have to figure out how to reset my password). > > > > > > Good for you. I tried creating an account but after putting in name > > > password and email it says no, send email to w...@debian.org instead. I > > > think I'll pass. While I have KDE on one Debian machine, I don't use it > > > much so not that much to contribute. > > > > I was able to successfully change my password and update my Wiki home > > page a little while ago. It has been a long time since I created the > > account and don't recall what the process entailed. > > If I recall correctly, it used to be possible to create an account with > the standard wiki mechanisms, but that was discontinued due to spammers > abusing it. So, those of us who happened to create an account in the > early days got to do it the easy way, but now any new accounts need to > be approved by the wiki admins. I think you're right. Given the text I updated in my profile/Wiki home page I'm guessing I created the account ten to fifteen years ago. At least Firefox still had the username stored with an expired password otherwise I'd forgotten all about it! - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Please verify Gnome and KDE wiki articles for correctness
On Sat, Aug 26, 2023 at 10:29:02AM -0400, Jeffrey Walton wrote: > On Sat, Aug 26, 2023 at 10:15 AM Dan Ritter wrote: [...] > > The basic problem with popcon is that it is opt-in, and nobody > > who is at all privacy conscious opts-in. > > > > (I fully support this decision. It is absolutely correct.) > > A quick note with an opposing view... learning that I run libc or kde > on my Debian machine reveals information with little to no value. [...] > Telling the Debian maintainers I run libc and kde benefits me and the > community. Maintainers and developers learn where to allocate > resources [...] I think this is the wrong angle. Opt-in is a sign of respect towards the users -- whatever reasons the user has is actually totally irrelevant. It might be privacy, it might be something else. This attitude is one of the things why I love Debian. Cheers -- t signature.asc Description: PGP signature
Re: Please verify Gnome and KDE wiki articles for correctness
On Sat, Aug 26, 2023 at 10:15 AM Dan Ritter wrote: > > Jeffrey Walton wrote: > > Popularity Contest (https://popcon.debian.org/) would be good to > > consult. But it looks like something is sideways. It does not provide > > usage statistics for packages like kde-full and gnome. I'm getting the > > message, "No Popularity contest entry for kde-full" (and friends). I > > use kde-full and I have popularity contest enabled, so there should be > > at least one entry. > > The basic problem with popcon is that it is opt-in, and nobody > who is at all privacy conscious opts-in. > > (I fully support this decision. It is absolutely correct.) A quick note with an opposing view... learning that I run libc or kde on my Debian machine reveals information with little to no value. Speaking for myself, I am not concerned about a privacy leak in this particular case. Telling the Debian maintainers I run libc and kde benefits me and the community. Maintainers and developers learn where to allocate resources. I think it's worth the leak since it benefits the distro and the community. > The result is that when a popcon entry exists, it represents the > people who have opted-in to popcon, who are (in my opinion): > > - new users > - individual users (not organization) > - laptop users > - desktop users > > If you are looking at a package and wondering about large > organizations or servers, it's probably a bad source of data. If an organization does not wish to share, then that's their business. It's not the first time a company takes but does not give back. It won't be the last time. > For this particular purpose, it's actually useful: > > #rank nameinst vote old recent no-files > (maintainer) > 1 perl-base 219693 20327417 1636537 (Niko > Tyni) > 2 libc6 219636 201427 609 1758119 (Gnu > Libc Maintainers) > > gnome-shell is the default window manager for GNOME: > > 738 gnome-shell 53530 40495 4216 880415 (Debian > Gnome Maintainers) > > kwin is the KDE window manager, so it's more or less as popular as KDE. > > 1402 kwin-common22176 15401 3453 3315 7 (Debian > Qt/kde Maintainers) Jeff
Re: Please verify Gnome and KDE wiki articles for correctness
On 8/25/23 13:22, Greg Wooledge wrote: On Fri, Aug 25, 2023 at 01:17:25PM -0700, Peter Ehlert wrote: I'm a Mate user, and I never thought to read https://wiki.debian.org/MATE until now. I see no flaws but there are several things that should be updated since it's last edit on December 24,2019 Who does that? You do. That's what a wiki is. "Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact w...@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online translation services.." I sent the requested email, I will wait and see
Re: Please verify Gnome and KDE wiki articles for correctness
On Sat, Aug 26, 2023 at 07:40:46AM -0500, Nate Bargmann wrote: > * On 2023 26 Aug 07:13 -0500, Anssi Saari wrote: > > Nate Bargmann writes: > > > > > This Wiki is semi-private in that editing is not open to just everyone > > > but may only be done through an account (apparently I have one and now > > > have to figure out how to reset my password). > > > > Good for you. I tried creating an account but after putting in name > > password and email it says no, send email to w...@debian.org instead. I > > think I'll pass. While I have KDE on one Debian machine, I don't use it > > much so not that much to contribute. > > I was able to successfully change my password and update my Wiki home > page a little while ago. It has been a long time since I created the > account and don't recall what the process entailed. If I recall correctly, it used to be possible to create an account with the standard wiki mechanisms, but that was discontinued due to spammers abusing it. So, those of us who happened to create an account in the early days got to do it the easy way, but now any new accounts need to be approved by the wiki admins.
Re: Please verify Gnome and KDE wiki articles for correctness
* On 2023 26 Aug 07:13 -0500, Anssi Saari wrote: > Nate Bargmann writes: > > > This Wiki is semi-private in that editing is not open to just everyone > > but may only be done through an account (apparently I have one and now > > have to figure out how to reset my password). > > Good for you. I tried creating an account but after putting in name > password and email it says no, send email to w...@debian.org instead. I > think I'll pass. While I have KDE on one Debian machine, I don't use it > much so not that much to contribute. I was able to successfully change my password and update my Wiki home page a little while ago. It has been a long time since I created the account and don't recall what the process entailed. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Please verify Gnome and KDE wiki articles for correctness
Nate Bargmann writes: > This Wiki is semi-private in that editing is not open to just everyone > but may only be done through an account (apparently I have one and now > have to figure out how to reset my password). Good for you. I tried creating an account but after putting in name password and email it says no, send email to w...@debian.org instead. I think I'll pass. While I have KDE on one Debian machine, I don't use it much so not that much to contribute. Looks like some IP address bans in the wiki may have been lifted recently or I was just lucky.
Re: Please verify Gnome and KDE wiki articles for correctness
* On 2023 25 Aug 23:57 -0500, Jeffrey Walton wrote: > On Fri, Aug 25, 2023 at 3:50 PM Greg Wooledge wrote: > > > > On Fri, Aug 25, 2023 at 01:26:29PM -0400, Jeffrey Walton wrote: > > > Two of the wiki articles that will help with a migration to Debian are > > > <https://wiki.debian.org/Gnome> and <https://wiki.debian.org/KDE>. > > > > > > It would be helpful if folks with Gnome and KDE experience would look > > > over the articles and provide corrections and updates. In order the help the OP since I apparently deleted this thread when it started, the GNOME page looks reasonably accurate. I do not have AMD hardware so I cannot comment on that section. The mouse cursor theme can be changed through the Tweaks GUI, but that only takes effect once GNOME Shell actually starts and doesn't affect gdm, as I understand it. > > You're kinda asking the wrong crowd. A significant portion of the > > active posters on this mailing list use neither of those things. > > > > This probably explains the state of the wiki pages as well, if one > > assumes that the users of this list correlate with the wiki editors > > to a certain degree, at least in terms of desktop choices. > > Yeah, it's hit or miss. > > But I disagree with your assessment. I am proof by counter-example. I > use KDE, and I've made some edits to the KDE article. I'm guessing > there will be other folks on the list who could make edits. Or this is > an extremely small list. I've been a Debian user and member of this list for quite a long time, since the late 1990s at least. In all that time I don't recall the Debian Project approaching this list requesting our assistance in updating/maintaining the Wiki. This Wiki is semi-private in that editing is not open to just everyone but may only be done through an account (apparently I have one and now have to figure out how to reset my password). The Wiki front page is rather adamant that addition of content to the Wiki by everyone is welcome and desired. In particular solutions are provided on this list that should make it onto the Wiki. I'm not volunteering for that "job" but it is something we might all consider in the future. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Please verify Gnome and KDE wiki articles for correctness
On Sat, 2023-08-26 at 00:55 -0400, Jeffrey Walton wrote: > I'm getting the > message, "No Popularity contest entry for kde-full" (and friends). I > use kde-full and I have popularity contest enabled, so there should be > at least one entry. Perhaps because they're metapackages? -- Tixy
Re: Please verify Gnome and KDE wiki articles for correctness
On Fri, Aug 25, 2023 at 3:50 PM Greg Wooledge wrote: > > On Fri, Aug 25, 2023 at 01:26:29PM -0400, Jeffrey Walton wrote: > > Two of the wiki articles that will help with a migration to Debian are > > <https://wiki.debian.org/Gnome> and <https://wiki.debian.org/KDE>. > > > > It would be helpful if folks with Gnome and KDE experience would look > > over the articles and provide corrections and updates. > > You're kinda asking the wrong crowd. A significant portion of the > active posters on this mailing list use neither of those things. > > This probably explains the state of the wiki pages as well, if one > assumes that the users of this list correlate with the wiki editors > to a certain degree, at least in terms of desktop choices. Yeah, it's hit or miss. But I disagree with your assessment. I am proof by counter-example. I use KDE, and I've made some edits to the KDE article. I'm guessing there will be other folks on the list who could make edits. Or this is an extremely small list. Popularity Contest (https://popcon.debian.org/) would be good to consult. But it looks like something is sideways. It does not provide usage statistics for packages like kde-full and gnome. I'm getting the message, "No Popularity contest entry for kde-full" (and friends). I use kde-full and I have popularity contest enabled, so there should be at least one entry. Jeff
Re: Please verify Gnome and KDE wiki articles for correctness
On 26/8/23 04:22, Greg Wooledge wrote: On Fri, Aug 25, 2023 at 01:17:25PM -0700, Peter Ehlert wrote: I'm a Mate user, and I never thought to read https://wiki.debian.org/MATE until now. I see no flaws but there are several things that should be updated since it's last edit on December 24,2019 Who does that? You do. That's what a wiki is. :) .. Bret Busby Armadale West Australia (UTC+0800) ..
Re: Please verify Gnome and KDE wiki articles for correctness
On Fri, Aug 25, 2023 at 01:17:25PM -0700, Peter Ehlert wrote: > I'm a Mate user, and I never thought to read > https://wiki.debian.org/MATE > until now. > I see no flaws but there are several things that should be updated since > it's last edit on December 24,2019 > Who does that? You do. That's what a wiki is.
Re: Please verify Gnome and KDE wiki articles for correctness
On August 25, 2023 12:49:44 PM Greg Wooledge wrote: On Fri, Aug 25, 2023 at 01:26:29PM -0400, Jeffrey Walton wrote: Two of the wiki articles that will help with a migration to Debian are <https://wiki.debian.org/Gnome> and <https://wiki.debian.org/KDE>. It would be helpful if folks with Gnome and KDE experience would look over the articles and provide corrections and updates. You're kinda asking the wrong crowd. A significant portion of the active posters on this mailing list use neither of those things. Probably true, but maybe there are a couple here. This probably explains the state of the wiki pages as well, if one assumes that the users of this list correlate with the wiki editors to a certain degree, at least in terms of desktop choices. I'm a Mate user, and I never thought to read https://wiki.debian.org/MATE until now. I see no flaws but there are several things that should be updated since it's last edit on December 24,2019 Who does that?
Re: Please verify Gnome and KDE wiki articles for correctness
On Fri, Aug 25, 2023 at 01:26:29PM -0400, Jeffrey Walton wrote: > Two of the wiki articles that will help with a migration to Debian are > <https://wiki.debian.org/Gnome> and <https://wiki.debian.org/KDE>. > > It would be helpful if folks with Gnome and KDE experience would look > over the articles and provide corrections and updates. You're kinda asking the wrong crowd. A significant portion of the active posters on this mailing list use neither of those things. This probably explains the state of the wiki pages as well, if one assumes that the users of this list correlate with the wiki editors to a certain degree, at least in terms of desktop choices.
Please verify Gnome and KDE wiki articles for correctness
Hi Everyone, A popular Debian-derived distro is preparing to change some printing components from *.deb packages to Snapd. That is going to cause trouble for users who remove Snapd, and still use *.deb packages. I expect some users will want to move from the other distro to Debian. Two of the wiki articles that will help with a migration to Debian are <https://wiki.debian.org/Gnome> and <https://wiki.debian.org/KDE>. It would be helpful if folks with Gnome and KDE experience would look over the articles and provide corrections and updates. Jeff
Screensaver in KDE (Plasma5)
Hi folks, it would be nice if someone could send me the correct settings of libs and binaries, which are related for the screensaver in plasma5. Also I would like to know, if the user hast to be member in a special group related to the screensaver. The problem here is, that I can not deactivate a started screensaver of my own session, although I know the correct password (of course). For me, it looks some wrong settings in the rights, so that I myself can not stop the screensaver process. The process can be stopped by root. Thanks for any help. Best regards Hans
Re: [Solved] Re: xrdp and KDE Plasma desktop
Am Dienstag, 18. Juli 2023, 05:36:56 CEST schrieb Max Nikulin:
> On 15/07/2023 00:04, Petric Frank wrote:
> > After some debugging i found a working solution. Allocated file in/etc/
> > polkit-1/rules.d/99-networkmanager.rules containing:
> >
> > --- cut --
> > polkit.addRule(function(action, subject) {
> >
> > if (action.id == "org.freedesktop.NetworkManager.network-control") {
> >
> > if (subject.isInGroup("netdev")) {
> >
> > return polkit.Result.YES;
> >
> >}
> >
> > }
> >
> > });
> > --- cut --
> >
> > Hope that helps others.
>
> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.
> en.html#changes-to-polkit-configuration "5.1.13. Changes to polkit
> configuration":
>
> For consistency with upstream and other distributions, the polkit
> (formerly PolicyKit) service, which allows unprivileged programs to
> access privileged system services, has changed the syntax and location
> for local policy rules. You should now write local rules for customizing
> the security policy in JavaScript, and place them at
> /etc/polkit-1/rules.d/*.rules. Example rules using the new format can be
> found in /usr/share/doc/polkitd/examples/, and polkit(8) has further
> information.
>
> Previously, rules could be written in pkla format, and placed in
> subdirectories of /etc/polkit-1/localauthority or
> /var/lib/polkit-1/localauthority. However, .pkla files should now be
> considered deprecated, and will only continue to work if the
> polkitd-pkla package is installed. This package will usually be
> installed automatically when you upgrade to bookworm, but it is likely
> not to be included in future Debian releases, so any local policy
> overrides will need to be migrated to the JavaScript format.
Thanks for the link. It was a little problematic for me to find the correct
rules using the big "trash dump" like google and others. Finally i got it and
posted it here to help others with the same problem.
There are other services (device mount, etc.) affected by the "password
request" dialogs which also have to be covered this way when connecting via
xrdp. Maybe also driven by group membership.
Re: [Solved] Re: xrdp and KDE Plasma desktop
On 15/07/2023 00:04, Petric Frank wrote:
After some debugging i found a working solution. Allocated file in/etc/
polkit-1/rules.d/99-networkmanager.rules containing:
--- cut --
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.NetworkManager.network-control") {
if (subject.isInGroup("netdev")) {
return polkit.Result.YES;
}
}
});
--- cut --
Hope that helps others.
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-polkit-configuration
"5.1.13. Changes to polkit configuration":
For consistency with upstream and other distributions, the polkit
(formerly PolicyKit) service, which allows unprivileged programs to
access privileged system services, has changed the syntax and location
for local policy rules. You should now write local rules for customizing
the security policy in JavaScript, and place them at
/etc/polkit-1/rules.d/*.rules. Example rules using the new format can be
found in /usr/share/doc/polkitd/examples/, and polkit(8) has further
information.
Previously, rules could be written in pkla format, and placed in
subdirectories of /etc/polkit-1/localauthority or
/var/lib/polkit-1/localauthority. However, .pkla files should now be
considered deprecated, and will only continue to work if the
polkitd-pkla package is installed. This package will usually be
installed automatically when you upgrade to bookworm, but it is likely
not to be included in future Debian releases, so any local policy
overrides will need to be migrated to the JavaScript format.
[Solved] Re: xrdp and KDE Plasma desktop
Am Freitag, 14. Juli 2023, 08:08:41 CEST schrieb Petric Frank:
> Am Donnerstag, 13. Juli 2023, 12:27:22 CEST schrieb Max Nikulin:
> > On 12/07/2023 20:51, Petric Frank wrote:
> > > If i look at the nmcli general permissions for the id i get:
> > >org.freedesktop.NetworkManager.network-control auth
> > >
> > > If i log in locally i get:
> > >org.freedesktop.NetworkManager.network-control yes
> > >
> > > It seems that something goes wrong - but what and how to fix it ?
> > > I use the same userid both times.
> >
> > Perhaps it is polkit that grants to local users more privileges than to
> > remote ones, e.g. to reboot or to power off. Moreover, it (or some other
> > daemon) may pass access e.g. to sound card on switch of currently active
> > session when several local users are logged in.
> >
> > Likely it is possible to change default policy to give more rights to a
> > specific user even when a remote session is started.
>
> Thanks for the hint.
After some debugging i found a working solution. Allocated file in /etc/
polkit-1/rules.d/99-networkmanager.rules containing:
--- cut --
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.NetworkManager.network-control") {
if (subject.isInGroup("netdev")) {
return polkit.Result.YES;
}
}
});
--- cut --
Hope that helps others.
kind regards
Petric
Re: xrdp and KDE Plasma desktop
Am Donnerstag, 13. Juli 2023, 12:27:22 CEST schrieb Max Nikulin:
> On 12/07/2023 20:51, Petric Frank wrote:
> > If i look at the nmcli general permissions for the id i get:
> >org.freedesktop.NetworkManager.network-control auth
> >
> > If i log in locally i get:
> >org.freedesktop.NetworkManager.network-control yes
> >
> > It seems that something goes wrong - but what and how to fix it ?
> > I use the same userid both times.
>
> Perhaps it is polkit that grants to local users more privileges than to
> remote ones, e.g. to reboot or to power off. Moreover, it (or some other
> daemon) may pass access e.g. to sound card on switch of currently active
> session when several local users are logged in.
>
> Likely it is possible to change default policy to give more rights to a
> specific user even when a remote session is started.
Thanks for the hint.
I found the page
https://c-nergy.be/blog/?p=12073
which posts 2 possibilities for a similar problem on ubuntu.
The unsafe way (set Allow_Any = yes) works, but the safer one (define file in
/etc/polkit-1/localauthority.conf.d) not.
I created afiler named 02-networkmanager.conf containing:
--- cut
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.NetworkManager.network-control") &&
subject.isInGroup("{netdev}")) {
return polkit.Result.YES;
}
});
--- cut
I looks to me that either the directory is wrong and/or the file name is
wrong.
Any ideas ?
regards
Re: xrdp and KDE Plasma desktop
On 12/07/2023 20:51, Petric Frank wrote: If i look at the nmcli general permissions for the id i get: org.freedesktop.NetworkManager.network-control auth If i log in locally i get: org.freedesktop.NetworkManager.network-control yes It seems that something goes wrong - but what and how to fix it ? I use the same userid both times. Perhaps it is polkit that grants to local users more privileges than to remote ones, e.g. to reboot or to power off. Moreover, it (or some other daemon) may pass access e.g. to sound card on switch of currently active session when several local users are logged in. Likely it is possible to change default policy to give more rights to a specific user even when a remote session is started.
xrdp and KDE Plasma desktop
Hello, i'm not sure where to look for this problem. Entering here because the Debian Bookworm is used. Installed Debian with Plasma desktop. The installed xrdp anf tigervnc- standalone-server to allow RDP connections. If i connect to this machine using xfreerdp the desktop is correctly shown. But immediately a password request popup window is displayed containing this (freely translated from german): - cut Title: Authentication required Action: Allow control of network connections Identity: org.freedesktop.NetworkManager.network-control ... - cut If i look at the nmcli general permissions for the id i get: org.freedesktop.NetworkManager.network-control auth If i log in locally i get: org.freedesktop.NetworkManager.network-control yes It seems that something goes wrong - but what and how to fix it ? I use the same userid both times. kind regards Petric
