Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[Max Nikulin]

On 28/09/2024 22:04, George at Clug wrote:

To get the earlier installations to discover the later installed
installations, I ran grub-mkconfig


I have never tried it, but my impression is that in the case of UEFI 
boot, rEFInd may detect installed OSes dynamically without explicit 
configuration.

Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[Florent Rougon]

Hi,

Thanks for your report!

Le 29/09/2024, George at Clug  a écrit:

> # grub-mkconfig -o /boot/grub/grub.cfg
> https://averagelinuxuser.com/dual-boot-arch-linux-with-linux/

Alternatively, you could have used a simple 'update-grub' because:

$ cat $(which update-grub)
#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
$

(This use of 'set -e' is funny.)

Regards

-- 
Florent

Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[George at Clug]

Hi,

I decided I should again test setting up 'multi boot linux installations' on a 
single PC with multiple disk drives, to verify my previous failures at doing 
this.

The result of this test?  It seems that Grub does a great job of booting from 
multiple linux installations.

For testing I created a KVM VM using Virt-Manager. I added up to five virtual 
disk drives to the VM (later I hope to add more).

So far I have installed three separate Debian Bookworm installations, each with 
a different Desktop Environment (Gnome, XFCE, KDE).

In each case (e.g. installation) I installed grub to the installation's own 
virtual disk drive (i.e. if I was installing to vdc then I installed grub to 
vdc. 

This means I can take out the drive and put it into another computer (e.g. in 
my test case a different VM). When I put a drive into its own computer, Grub 
will complain that the other drives are not available, but grub config can be 
edited to remove the non existent drives. 

While installing each of the installations, each installation discovered the 
previous installations and configure grub to boot from them. Hence only the 
last installed Linux installation's grub contained all other installations.

To get the earlier installations to discover the later installed installations, 
I ran grub-mkconfig as per the below web site's instructions. This worked very 
well. Later on I want to try this on a physical PC that I wanted to use the 
ability of grub.

# grub-mkconfig -o /boot/grub/grub.cfg
https://averagelinuxuser.com/dual-boot-arch-linux-with-linux/

Thanks to all who replied to this query, you encouraged me to do a bit more 
research, and all I can say is I am embarrassed how easy it was to set up. 

George.




On Thursday, 26-09-2024 at 07:19 George at Clug wrote:
> My experiences - George.
> 
> On Wednesday, 25-09-2024 at 12:37 Max Nikulin wrote:
> > On 25/09/2024 04:52, George at Clug wrote:
> > > An other example would be to boot Debian Gnome, Debian KDE, and Debian 
> > > Mate, Debian XFCE.
> > 
> > What issues you have faced trying to install multiple desktop 
> > environment to the same Debian installation? 
> 
> Grub did not find other existing Linux distributions. Found Windows, but not 
> other linux distributions.
> 
> I did not try hard to determine the reason. I decided if it did not work, 
> don't pursue the issue.
> 
> > Display managers allow to 
> > select session type before login (but some can not remember per-user 
> > preferences).
> 
> Using a different display manager is not the same as using a different 
> installation.
> 
> > 
> > I do not expect serious issues with multiple Linux flavors. Perhaps 
> > installer should be switched to expert mode to adjust some defaults.
> 
> I do use expert mode when installing Debian.
> 
> > 
> > If you still prefer to have independent Debian installations then in the 
> > case of UEFI and shim-signed+grub-efi-amd64 (for Secure Boot) on the 
> > same ESP partition see
> > <https://lists.debian.org/msgid-search/vc31n1$ahn$1...@ciao.gmane.io>
> > [SUMMARY] Re: UEFI multiboot. Sat, 14 Sep 2024 10:59:29 +0700
> 
> When ever possible, I do not use Secure Boot. Though in my attempt to have 
> multiple Linux installations, I did try (once).
> 
> > 
> > You need grub 2.12 from bookworm-backports and custom GRUB_DISTRIBUTOR 
> > in /etc/default/grub.
> > 
> > Despite in that thread I was trying to concentrate on selecting OS from 
> > UEFI firmware menu, Felix Miata repeatedly insisted on using grub menu 
> > for this purpose. In your case grub menu may be easier to maintain. 
> > Perhaps Felix may provide more details now to do it conveniently.
> > 
> > 
> 
> 

Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[Max Nikulin]

On 27/09/2024 18:53, George at Clug wrote:

3) I am not confident that constant switching between display manager,
e.g. LightDM, SLiM, XDM, GDM, SDDM, KDM, Ly will not cause issues.
Besides the frustration of changing the configuration each time you want
  to jump into another DE.


Is it really necessary to switch DM to start another DE? OK, when I 
tried GNOME last time ~3 years ago on Ubuntu, there was vendor lock-in 
to GDM due to usage of some API outside of XDG specs. I faced some 
issues with GDM (so I am avoiding it), but it was possible to use 
another session type. LightDM and SDDM have menus to select session type 
as well.


I would avoid using the same home directory for running different 
versions of some application (different distributions or 
stable/unstable), but I do not expect much issues after logging in with 
different session type from the same installation.


Certainly "clean" GNOME and KDE installs and a mixed case may reveal 
different bugs. An intermediate approach is to create a user per DE.



4) Logging into different DEs does not provide for Windows/Arch
Linux/Ubuntu/Linux Mint/Manjaro multiboot scenario.


I just expect that more corner cases might arise for booting multiple 
variants of specific distribution than for different distributions.



Booting into completely different installations on different disk drives
  works very well,


I am completely confused. From my point of view it is in contradiction with


I have often wanted to boot several Linux distributions, but have failed
to dual or multi boot from multiple Linux installations.


Does it mean that you physically replace drives instead of configuring 
UEFI or Grub menu?

Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[George at Clug]

On Friday, 27-09-2024 at 12:40 David Wright wrote:
> On Thu 26 Sep 2024 at 09:52:18 (+0100), Joe wrote:
> > On Thu, 26 Sep 2024 07:19:26 +1000 George at Clug wrote:
> > > On Wednesday, 25-09-2024 at 12:37 Max Nikulin wrote:
> > > > On 25/09/2024 04:52, George at Clug wrote:  
> > > > > An other example would be to boot Debian Gnome, Debian KDE, and
> > > > > Debian Mate, Debian XFCE.  
> > > > 
> > 
> > > 
> > > > Display managers allow to 
> > > > select session type before login (but some can not remember
> > > > per-user preferences).  
> > > 
> > > Using a different display manager is not the same as using a
> > > different installation.
> > > 
> > No, for that you need multi-boot.
> > 
> > But to compare Gnome, KDE etc. you would be staying within one
> > installation and using the display manager to switch between desktop
> > environments, which is what these things are. You could also compare
> > with other environments such as window managers, but generally only
> > heavy professional users find it convenient to eliminate the desktop
> > environments, such as you mention (also LXDE and Cinnamon).
> > 
> > If you look around your login screen, it may not be obvious, but there
> > should be a way to select different types of session. Even with a
> > default Debian installation you should find a session control widget in
> > the top right corner of the screen while the login box is shown, though
> > it will only contain the desktop you selected on installation. But you
> > can install others, and they will appear on this session menu.
> 
> Is it safe to assume that the environment a sole DE gives you is the
> same as the environment when you've switched to that DE from running
> several others, or even when other DEs are installed on the system?

See issues I raised below. The main issue with installing multiple DEs, is that 
you get a very different installation to that of a single DE installation.

For example, when I install XFCE (my favourite DE) I often also install 
Cinnamon and/or Mate, but only ever log into XFCE. Installing in this manner 
installs many other programs that I like, e.g. gedit, System Monitor to be 
installed which I would otherwise have to install separately and later after 
the initial OS installation. 

One thing I find annoying about XFCE, if I only install XFCE, Thunar is unable 
to connect to SAMBA shares, but if I also install Cinnamon, then when logging 
into XFCE, Thunar can connect to SAMBA shares. 

There are packages I can install to get Thunar in an XFCE only installation to 
connect to SAMBA shares, but it is so much easier just to install both XFCE and 
Cinnamon when initially installing Debian. 



> Particularly (but sticking with Debian) in the context of:
> 
> > > > > For example if I could do this I would be able to test
> > > > > various GUIs or distributions for applications/games
> > > > > using the same hardware and gauge performance.
> 
> Also, do DEs ever disagree over how they use their dotfiles?

You have raised a good point.

When trying to use a single Linux installation for multiple DEs (GUIs), I have 
had these concerns:

1) If you install multiple DEs you get many files/programs installed that are 
extra to a specific DE.  This alters greatly the DE experience such that it 
become meaningless in trying/testing the given DE.

2) I have had issues with /home/[user].config files being corrupted as each DE 
alters various config files in their own way, causing conflicts with other DEs.

3) I am not confident that constant switching between display manager, e.g. 
LightDM, SLiM, XDM, GDM, SDDM, KDM, Ly will not cause issues. Besides the 
frustration of changing the configuration each time you want to jump into 
another DE.

4) Logging into different DEs does not provide for Windows/Arch 
Linux/Ubuntu/Linux Mint/Manjaro multiboot scenario.

Booting into completely different installations on different disk drives works 
very well, if you can select which drive you are booting from. And allows for 
comparison of distributions on the same hardware.

George.


> 
> Cheers,
> David.
> 
> 

Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[David Wright]

On Thu 26 Sep 2024 at 09:52:18 (+0100), Joe wrote:
> On Thu, 26 Sep 2024 07:19:26 +1000 George at Clug wrote:
> > On Wednesday, 25-09-2024 at 12:37 Max Nikulin wrote:
> > > On 25/09/2024 04:52, George at Clug wrote:  
> > > > An other example would be to boot Debian Gnome, Debian KDE, and
> > > > Debian Mate, Debian XFCE.  
> > > 
> 
> > 
> > > Display managers allow to 
> > > select session type before login (but some can not remember
> > > per-user preferences).  
> > 
> > Using a different display manager is not the same as using a
> > different installation.
> > 
> No, for that you need multi-boot.
> 
> But to compare Gnome, KDE etc. you would be staying within one
> installation and using the display manager to switch between desktop
> environments, which is what these things are. You could also compare
> with other environments such as window managers, but generally only
> heavy professional users find it convenient to eliminate the desktop
> environments, such as you mention (also LXDE and Cinnamon).
> 
> If you look around your login screen, it may not be obvious, but there
> should be a way to select different types of session. Even with a
> default Debian installation you should find a session control widget in
> the top right corner of the screen while the login box is shown, though
> it will only contain the desktop you selected on installation. But you
> can install others, and they will appear on this session menu.

Is it safe to assume that the environment a sole DE gives you is the
same as the environment when you've switched to that DE from running
several others, or even when other DEs are installed on the system?
Particularly (but sticking with Debian) in the context of:

> > > > For example if I could do this I would be able to test
> > > > various GUIs or distributions for applications/games
> > > > using the same hardware and gauge performance.

Also, do DEs ever disagree over how they use their dotfiles?

Cheers,
David.

Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[Joe]

On Thu, 26 Sep 2024 07:19:26 +1000
George at Clug  wrote:

> My experiences - George.
> 
> On Wednesday, 25-09-2024 at 12:37 Max Nikulin wrote:
> > On 25/09/2024 04:52, George at Clug wrote:  
> > > An other example would be to boot Debian Gnome, Debian KDE, and
> > > Debian Mate, Debian XFCE.  
> > 

> 
> > Display managers allow to 
> > select session type before login (but some can not remember
> > per-user preferences).  
> 
> Using a different display manager is not the same as using a
> different installation.
> 
No, for that you need multi-boot.

But to compare Gnome, KDE etc. you would be staying within one
installation and using the display manager to switch between desktop
environments, which is what these things are. You could also compare
with other environments such as window managers, but generally only
heavy professional users find it convenient to eliminate the desktop
environments, such as you mention (also LXDE and Cinnamon).

If you look around your login screen, it may not be obvious, but there
should be a way to select different types of session. Even with a
default Debian installation you should find a session control widget in
the top right corner of the screen while the login box is shown, though
it will only contain the desktop you selected on installation. But you
can install others, and they will appear on this session menu.

There are also multiple display managers you can try, and again can
install several and select between them. 

https://wiki.debian.org/DisplayManager

Some further notes:

https://forums.debian.net/viewtopic.php?t=154871

Mostly different DMs just give you different login dialogs, they all do
the same things in terms of starting an X session. They don't make any
difference to the environment once the session has started.

-- 
Joe

Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

[Max Nikulin]

On 26/09/2024 04:19, George at Clug wrote:

Grub did not find other existing Linux distributions. Found Windows, but not 
other linux distributions.


The following has been discussed on debian-user:

"GRUB no longer runs os-prober by default"
However I have no ideas since Windows is added to *grub* menu.


I did not try hard to determine the reason. I decided if it did not work, don't 
pursue the issue.


Then there is nothing to discuss.


I do not expect serious issues with multiple Linux flavors. Perhaps
installer should be switched to expert mode to adjust some defaults.


I do use expert mode when installing Debian.


Have you managed to disable ESP and to avoid updating NVRAM (assuming 
UEFI, not BIOS)?

boot Debian Gnome, Debian KDE, and Mate, XFCE

[George at Clug]

My experiences - George.

On Wednesday, 25-09-2024 at 12:37 Max Nikulin wrote:
> On 25/09/2024 04:52, George at Clug wrote:
> > An other example would be to boot Debian Gnome, Debian KDE, and Debian 
> > Mate, Debian XFCE.
> 
> What issues you have faced trying to install multiple desktop 
> environment to the same Debian installation? 

Grub did not find other existing Linux distributions. Found Windows, but not 
other linux distributions.

I did not try hard to determine the reason. I decided if it did not work, don't 
pursue the issue.

> Display managers allow to 
> select session type before login (but some can not remember per-user 
> preferences).

Using a different display manager is not the same as using a different 
installation.

> 
> I do not expect serious issues with multiple Linux flavors. Perhaps 
> installer should be switched to expert mode to adjust some defaults.

I do use expert mode when installing Debian.

> 
> If you still prefer to have independent Debian installations then in the 
> case of UEFI and shim-signed+grub-efi-amd64 (for Secure Boot) on the 
> same ESP partition see
> <https://lists.debian.org/msgid-search/vc31n1$ahn$1...@ciao.gmane.io>
> [SUMMARY] Re: UEFI multiboot. Sat, 14 Sep 2024 10:59:29 +0700

When ever possible, I do not use Secure Boot. Though in my attempt to have 
multiple Linux installations, I did try (once).

> 
> You need grub 2.12 from bookworm-backports and custom GRUB_DISTRIBUTOR 
> in /etc/default/grub.
> 
> Despite in that thread I was trying to concentrate on selecting OS from 
> UEFI firmware menu, Felix Miata repeatedly insisted on using grub menu 
> for this purpose. In your case grub menu may be easier to maintain. 
> Perhaps Felix may provide more details now to do it conveniently.
> 
> 

boot Debian Gnome, Debian KDE, and Mate, XFCE (was: Re: Finding/creating Debian documentation for an unserved audience)

[Max Nikulin]

On 25/09/2024 04:52, George at Clug wrote:

An other example would be to boot Debian Gnome, Debian KDE, and Debian Mate, 
Debian XFCE.


What issues you have faced trying to install multiple desktop 
environment to the same Debian installation? Display managers allow to 
select session type before login (but some can not remember per-user 
preferences).


I do not expect serious issues with multiple Linux flavors. Perhaps 
installer should be switched to expert mode to adjust some defaults.


If you still prefer to have independent Debian installations then in the 
case of UEFI and shim-signed+grub-efi-amd64 (for Secure Boot) on the 
same ESP partition see

<https://lists.debian.org/msgid-search/vc31n1$ahn$1...@ciao.gmane.io>
[SUMMARY] Re: UEFI multiboot. Sat, 14 Sep 2024 10:59:29 +0700

You need grub 2.12 from bookworm-backports and custom GRUB_DISTRIBUTOR 
in /etc/default/grub.


Despite in that thread I was trying to concentrate on selecting OS from 
UEFI firmware menu, Felix Miata repeatedly insisted on using grub menu 
for this purpose. In your case grub menu may be easier to maintain. 
Perhaps Felix may provide more details now to do it conveniently.

KDE, switching users (was: Re: Circumventing keyboard problem on Lenovo R64)

[Max Nikulin]

On 12/09/2024 21:54, Hans wrote:
If someone might also confirm of this little bug I mentioned here and 
knows better than me, he may just file a little bugreport to the 
developers of KDE. Maybe he also nows a little workaround???


[Ctrl+Alt+F8], [Ctrl+Alt+F7] work fine for me to switch between user 
sessions (minimal KDE, LightDM, amdgpu). I usually start new sessions 
using "dm-tool switch-to-user USER", sometimes I do it from KDE screen 
locker. I have not noticed any issue with unlocking user session from 
kscreenlocker password prompt or from lightlocker for fluxbox.


However what is broken in bookworm is unlocking user session from DM 
login prompt. Sometimes existing session is terminated and I have to 
login again. I have seen it with LightDM and SDDM, in qemu and without 
virtualization. A workaround is to leave DM greeter running after logout 
and to switch to another session using [Ctrl+Alt+F].


On my old laptop LightDM greeter reliably switches to the plasma session 
started for the selected user and unlocks that session. Currently 
Kubuntu-20.04 is installed and I do not remember any problem with 18.04 
or 16.04.

Re: KDE - Wayland vs X11

[George at Clug]

On Monday, 02-09-2024 at 18:03 Nicolas George wrote:
> Dan Ritter (12024-09-01):
> > It is unlikely that X will be actually abandoned until all of
> > these problems with Wayland are solved.
> 
> oneko and xeyes do not work properly with Wayland, that is definitely a
> deal breaker.

Thanks for making me smile !

George.


> 
> Regards,
> 
> -- 
>   Nicolas George
> 
> 

Re: KDE - Wayland vs X11

[Erwan David]

On Mon, Sep 02, 2024 at 10:03:32AM CEST, Nicolas George  said:
> Dan Ritter (12024-09-01):
> > It is unlikely that X will be actually abandoned until all of
> > these problems with Wayland are solved.
> 
> oneko and xeyes do not work properly with Wayland, that is definitely a
> deal breaker.
> 
> Regards,

I cannot say if it is wayland or plasma5, but
1) plasma does not start non wayland apps (emacs, firefox,
thunderbird) at statrtup. Considering my problems with emacs ans
ssh-agent, for this I would look to a startup ordering mess (apps
being started before xwayland).

2) I lose some shortcuts, because under wayland, I cannot have a
difference bewteen keys on the keypad, and keys on the main keyboard.

Due to this (and especially point 1) I stopped using wayland with
plasma. But I'll try again when plasma6 arrives in testing

However, with plasma5 wayland support is still incomplete, and X11
support won't disappear soon


-- 
Erwan David

Re: KDE - Wayland vs X11

[Nicolas George]

Dan Ritter (12024-09-01):
> It is unlikely that X will be actually abandoned until all of
> these problems with Wayland are solved.

oneko and xeyes do not work properly with Wayland, that is definitely a
deal breaker.

Regards,

-- 
  Nicolas George

Re: KDE - Wayland vs X11

[George at Clug]

Dan,

Thank you for your reply. 

George


On Monday, 02-09-2024 at 11:15 Dan Ritter wrote:
> George at Clug wrote: 
> > When installing KDE for people, I have been leaving Wayland as the
> > compositor, believing that X11 was no longer supported. However
> > recently I tested X11 and found the experience was much better.
> 
> This is not unusual. Wayland is young and immature.
> 
> Wayland has been in the process of replacing X11 for 15 years
> now. When X was 15 years old, the X.org domain name was created,
> and it wasn't for five more years that the X.org Foundation came
> into being.
> 
> > At this point of time my KDE with X11 experience is better than my
KDE
> > with Wayland experience. However I am concerned that at some
point,
> > somewhere, X11 will not be supported, sadly.
> 
> You can be concerned, but I recommend not worrying about it
> much.
> 
> It is unlikely that X will be actually abandoned until all of
> these problems with Wayland are solved.
> 
> (There is always somebody who pops up and claims that they have
> never had a problem with Wayland, or any such problems no longer
> exist. That's their subjective experience, and they are entitled
> to be happy about Wayland, but they are not entitled to tell you
> that your experience is invalid.)
> 
> -dsr-
> 
>

Re: KDE - Wayland vs X11

[Dan Ritter]

George at Clug wrote: 
> When installing KDE for people, I have been leaving Wayland as the
> compositor, believing that X11 was no longer supported. However
> recently I tested X11 and found the experience was much better.

This is not unusual. Wayland is young and immature.

Wayland has been in the process of replacing X11 for 15 years
now. When X was 15 years old, the X.org domain name was created,
and it wasn't for five more years that the X.org Foundation came
into being.

> At this point of time my KDE with X11 experience is better than my KDE
> with Wayland experience. However I am concerned that at some point,
> somewhere, X11 will not be supported, sadly.

You can be concerned, but I recommend not worrying about it
much.

It is unlikely that X will be actually abandoned until all of
these problems with Wayland are solved.

(There is always somebody who pops up and claims that they have
never had a problem with Wayland, or any such problems no longer
exist. That's their subjective experience, and they are entitled
to be happy about Wayland, but they are not entitled to tell you
that your experience is invalid.)

-dsr-

KDE - Wayland vs X11

[George at Clug]

Hi,


After being a long time XFCE users, on some computers I have been
installing KDE (on Bookworm) for people. Particularly people who had
previously been using Windows.


I don't have  a lot of experience with KDE. I am finding it a very
visually pleasing and easy to use GUI that has some nice mature
programs. For example Kdenlive, KPatience.


When installing KDE for people, I have been leaving Wayland as the
compositor, believing that X11 was no longer supported. However
recently I tested X11 and found the experience was much better.


For example:


1) In Virt-Manager in X11 I can select "Resize to VM" and it works,
where as in Wayland the resize does not happen.


2) In Chromium, if I do screen sharing in Jitsi, the Wayland
experience there are a number of times I have to select what I want to
share, but with X11 I can just select the item I want to share once.


3) Now I can run Steam games, OBS Studio, and Virt-Manager natively,
without Xwayland being used.


4) KDE using X11 works well on my PCs with Nvidia cards.



5) I also wonder if using X11 will mean that Firefox does not lock up
the whole computer when a certain (yet to be identified) ad is present
in a web page.


I want to ask if anyone knows is there any downsides to using using
KDE with X11 and not with Wayland?

It would be nice to be able to use X11 until finally Wayland has
sorted out the various issues that have yet to be resolved,
application maintainers have all produced a Wayland version of their
software, and Nvidia and Wayland are happily working well together.
(hopefully this will be in the near future)



At this point of time my KDE with X11 experience is better than my KDE
with Wayland experience. However I am concerned that at some point,
somewhere, X11 will not be supported, sadly.



George.


 

Re: do we have KDE expertise among us?

[George at Clug]

> On 22/08/24 at 19:20, DdB wrote:
> > Beloved debian users,
> > 
> >   After years of using GNOME (even back in my Ubuntu-days), i got fed up
> > with the ever changing behavior, which came on top of "development
> > politics". And since i was/am still on buster, i decided to move forward
> > to bookworm-KDE. But i am old and slow. It really took me a month to get
> > a sort of minimal version up and running. I call this step:
> > proof-of-concept. Now comes the harder part: to really take control of
> > this desktop, not like a developer, but as a user. (I am currently
> > evaluating to make use of ansible and redo the whole setup, but in a
> > reproducible way.)
> > And i got my VPN client working in KDE, only the iptable rules to
> > protect me from acidental leaks (kill switch) need to be reinstalled
> > after every boot. How to make them permanent the right way?


DdB,

I have little technical knowledge of Linux, compared to the things you 
indicated that you do. 

I use KDE but I do not modify it beyond using the UI's own methods for menus, 
etc. I also use XFCE where to make changes to the menus I install and use 
menulibre. 

In general, I use the base installed packages from the Debian repositories, and 
I do not alter the environment or its file systems.  I guess a bit boring for 
many people in this email list, however it provides me with a stable and 
working environment. Hence I cannot offer suggests for many of the things you 
mentioned. However I do use iptables and now nftables (thanks to help provided 
from people in this Debian User list).

Maybe the answer to your question "How to make them permanent the right way?" 
would be by installing and using "iptables-persistent". I first set up my 
working rules, then once they are correct, I install iptables-persistent and 
save my rules. The below Debian web site offers another way besides using 
iptables-persistent, but I have not used this method.

# apt install iptables-persistent

https://wiki.debian.org/iptables
Another way is to use the package iptables-persistent. Rules can be stored 
something like this:

  iptables-save > /etc/iptables/rules.v4
  ip6tables-save > /etc/iptables/rules.v6

https://www.cyberciti.biz/faq/how-to-save-iptables-firewall-rules-permanently-on-linux/

George.

Re: do we have KDE expertise among us?

[Jeffrey Walton]

On Thu, Aug 22, 2024 at 4:26 PM DdB
 wrote:
>
> Beloved debian users,
>
>  After years of using GNOME (even back in my Ubuntu-days), i got fed up
> with the ever changing behavior, which came on top of "development
> politics". And since i was/am still on buster, i decided to move forward
> to bookworm-KDE. But i am old and slow. It really took me a month to get
> a sort of minimal version up and running. I call this step:
> proof-of-concept. Now comes the harder part: to really take control of
> this desktop, not like a developer, but as a user. (I am currently
> evaluating to make use of ansible and redo the whole setup, but in a
> reproducible way.)
>
>  Several issues are bugging me:
> 1. I can't get Window rules to work, neither for wayland nor for x11, i
> seem to be doing those wrong.
> 2. I would really like to have a clickable menu only with my own
> commands/scripts in it, preferably in one single file, not spread out
> over many. Is such a thing available?
> 3. Some applications are not listed by wmctrl -l as if they were not
> managed by the window manager, therefore i cannot move them around in my
> scripts (and windows rules ... i told ya)
> 4. True story: after just one day of living in the new environment, it
> crashed hard, all the open applications were gone. Could be a strange
> are incident, in buster, i had such a thing happen to me only about 4
> times per year!
>
> Apart from the huge UI change, i also changed the root filesystem (it is
> zfs now, i used to have my data in it before, but this time, it is
> more). To achieve this, i went with zbm (zfsbootmanager) instead of
> grub. tbh: currently, i still use both, switching at least twice per day.
>
> And i got my VPN client working in KDE, only the iptable rules to
> protect me from acidental leaks (kill switch) need to be reinstalled
> after every boot. How to make them permanent the right way?
>
> That's it for today, any comment/hint/suggestion warmly welcome, DdB

Answering your titular question. There are debian-kde and
debian-qt-kde mailing lists. See
<https://lists.debian.org/completeindex.html>.

Jeff

Re: do we have KDE expertise among us?

[Anssi Saari]

DdB  writes:

> Beloved debian users,
>
>  After years of using GNOME (even back in my Ubuntu-days), i got fed up
> with the ever changing behavior, which came on top of "development
> politics". And since i was/am still on buster, i decided to move forward
> to bookworm-KDE.

I only dabble in KDE, my main desktop is still Awesome WM. I don't know
how to help with any of your KDE questions.

> And i got my VPN client working in KDE, only the iptable rules to
> protect me from acidental leaks (kill switch) need to be reinstalled
> after every boot. How to make them permanent the right way?

Hm, I don't know if there's a permanent right way for iptables in Debian
but I tend to think any way that does the job is right.

I used to have a script in /etc/init.d for iptables firewall but since
it became just a wrapper for nftables I switched to that and the Debian
package nftables comes with a systemd service ready to go.

Re: do we have KDE expertise among us?

[Franco Martelli]

Hi,

I'm a Debian KDE end-user from years, but in your post there are too 
many topics! Try to write an email for each of these.


On 22/08/24 at 19:20, DdB wrote:

Beloved debian users,

  After years of using GNOME (even back in my Ubuntu-days), i got fed up
with the ever changing behavior, which came on top of "development
politics". And since i was/am still on buster, i decided to move forward
to bookworm-KDE. But i am old and slow. It really took me a month to get
a sort of minimal version up and running. I call this step:
proof-of-concept. Now comes the harder part: to really take control of
this desktop, not like a developer, but as a user. (I am currently
evaluating to make use of ansible and redo the whole setup, but in a
reproducible way.)

  Several issues are bugging me:
1. I can't get Window rules to work, neither for wayland nor for x11, i
seem to be doing those wrong.

Do you mean that you have trouble using tools like xdotool or xprop?


2. I would really like to have a clickable menu only with my own
commands/scripts in it, preferably in one single file, not spread out
over many. Is such a thing available?

The only tool I know to rearrange KDE's menu is "kmenuedit"


3. Some applications are not listed by wmctrl -l as if they were not
managed by the window manager, therefore i cannot move them around in my
scripts (and windows rules ... i told ya)

Here wmctrl seems works fine in Xorg do you use Wayland?


4. True story: after just one day of living in the new environment, it
crashed hard, all the open applications were gone. Could be a strange
are incident, in buster, i had such a thing happen to me only about 4
times per year!
Me too had instability issue, I solved that changing the default setup, 
It may depend on driver, acceleration, compositor…




Apart from the huge UI change, i also changed the root filesystem (it is
zfs now, i used to have my data in it before, but this time, it is
more). To achieve this, i went with zbm (zfsbootmanager) instead of
grub. tbh: currently, i still use both, switching at least twice per day.

And i got my VPN client working in KDE, only the iptable rules to
protect me from acidental leaks (kill switch) need to be reinstalled
after every boot. How to make them permanent the right way?

That's it for today, any comment/hint/suggestion warmly welcome, DdB


Too many topics

Cheers
--
Franco Martelli

do we have KDE expertise among us?

[DdB]

Beloved debian users,

 After years of using GNOME (even back in my Ubuntu-days), i got fed up
with the ever changing behavior, which came on top of "development
politics". And since i was/am still on buster, i decided to move forward
to bookworm-KDE. But i am old and slow. It really took me a month to get
a sort of minimal version up and running. I call this step:
proof-of-concept. Now comes the harder part: to really take control of
this desktop, not like a developer, but as a user. (I am currently
evaluating to make use of ansible and redo the whole setup, but in a
reproducible way.)

 Several issues are bugging me:
1. I can't get Window rules to work, neither for wayland nor for x11, i
seem to be doing those wrong.
2. I would really like to have a clickable menu only with my own
commands/scripts in it, preferably in one single file, not spread out
over many. Is such a thing available?
3. Some applications are not listed by wmctrl -l as if they were not
managed by the window manager, therefore i cannot move them around in my
scripts (and windows rules ... i told ya)
4. True story: after just one day of living in the new environment, it
crashed hard, all the open applications were gone. Could be a strange
are incident, in buster, i had such a thing happen to me only about 4
times per year!

Apart from the huge UI change, i also changed the root filesystem (it is
zfs now, i used to have my data in it before, but this time, it is
more). To achieve this, i went with zbm (zfsbootmanager) instead of
grub. tbh: currently, i still use both, switching at least twice per day.

And i got my VPN client working in KDE, only the iptable rules to
protect me from acidental leaks (kill switch) need to be reinstalled
after every boot. How to make them permanent the right way?

That's it for today, any comment/hint/suggestion warmly welcome, DdB

kde troubles (was: tbird troubles)

[Michel Verdier]

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: Change suspend type from kde menu

[Valerio Vanni]

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

[Valerio Vanni]

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

[Sergei Steshenko]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Franco Martelli]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Valerio Vanni]

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&paste.


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

[Franco Martelli]

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

[Valerio Vanni]

Il 12/01/2024 03:52, Max Nikulin ha scritto:

I assume that "org/mpris/MediaPlayer2" after "/" was lost during 
copy&paste.


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

[Max Nikulin]

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&paste.


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

[Valerio Vanni]

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&paste.


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

[Valerio Vanni]

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

[Max Nikulin]

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&paste.


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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Max Nikulin]

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

[Max Nikulin]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Max Nikulin]

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

[Max Nikulin]

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

[Max Nikulin]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Greg Wooledge]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Franco Martelli]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Greg Wooledge]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Max Nikulin]

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

[Greg Wooledge]

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

[Valerio Vanni]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Arno Lehmann]

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

[Greg Wooledge]

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

[Franco Martelli]

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

[Valerio Vanni]

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

[Valerio Vanni]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Charles Curley]

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

[Valerio Vanni]

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

[Franco Martelli]

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

[Max Nikulin]

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

[Valerio Vanni]

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

[Valerio Vanni]

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: Please verify Gnome and KDE wiki articles for correctness

[Steve McIntyre]

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

[Luna Jernberg]

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

[Peter Ehlert]

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

[Nate Bargmann]

* 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

[tomas]

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

[Jeffrey Walton]

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-shell53530 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

[Peter Ehlert]

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

[Greg Wooledge]

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

[Nate Bargmann]

* 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

[Anssi Saari]

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

[Nate Bargmann]

* 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

[Tixy]

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

[Jeffrey Walton]

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