KLV-plasma-KDE-CE (stable Release )

[Clarity]

KLV-KDE v1.2 boot results published here.

Problem in booting via Ventoy still remain. SG2D boots works sames as direct ISO boots. All booting achieved via KLV-KDE's default menu entry (top menu entry; ie RAM0) with NO menu item stanza changes

Setup SAMBA(4).jpg (22.66 KiB) Viewed 1729 times

[Sofiya]

Catppuccin Macchiato -- Console with "Catppuccin Macchiato" color theme

open the settings menu -> create a new profile -> load the color theme "Catppuccin Macchiato" -> install -> select the created default profile

[Sofiya]

fastfetch

changes made same color of circles and changed separator

[Sofiya]

Neovim theme -Tokyo Night

[Sofiya]

My KDE customization for MAC OS

[Sofiya]

Conky

sudo xbps-install -Su fonts-roboto-ttf

[Sofiya]

VSCodium - Catppuccin-Macchiato

[geo_c]

I'm working my way methodically around KLV-Plasma now.

I installed Xfe, rebooted and changed the permissions to owner:root group:spot of one of the other locations I have Xfe installed (KLV-spectr/upper_changes/root/.config/xfe) and copied the configs and icons in Plasma in the /home/.config/xfe folder using Dolphin. That worked and now Xfe is working as user spot in Plasma.

So say I have gigs and gigs of stuff on the install (/mnt/home) drive, and I want to be able to read and write from it while running as user spot. What's the best way to do that without changing the group permissions of the whole drive recursively?

Is it something to do with running Dolphin as root?

Dolphin is an excellent file manager, not that I need Xfe in plasma so much, but I was using setting up Xfe as a test case for accessing files on the partition.

[williwaw]

So say I have gigs and gigs of stuff on the install (/mnt/home) drive, and I want to be able to read and write from it while running as user spot. What's the best way to do that without changing the group permissions of the whole drive recursively?

when logged in as spot, create a mountpoint in your user directory, ie /usr/home/spot/mnt

mount your other drive there and see if it works better for what you are trying to do

[geo_c]

I just did some work with running pipewire, which I was pleased to find already installed. Unfortunately I can't get any jack apps to work on plasma.

I tried Yoshimi synth, which works straight alsa or jack, and that one couldn't find a midi connection, though it appeared to be making sound internally in the program, I couldn't get it to show up on qpwgraph.

So I tried using modprobe snd seq in the terminal, then installing alsa-jack-plugins, but still not working. The pipewire sound controls in KDE are different than the a straight pulseaudio control with pipewire. So it needs further investigation.

For me it's mostly the challenge of it that motivates me to get it going, because in a crucial audio environment, I don't know that I'd want this much graphic overhead and specialized KDE configuration in the mix. It kind of reminds me of doing pro audio with windows, always having to make sure the windows audio drivers are not getting in the way.

That being said, I still want to get KDE going just to have a flagship wayland desktop functioning well, you know, to impress my linux-skeptical friends and all!

As I hover the mouse over task list in the tray, audio connections labeled "screencast" pop in qpwgraph, but they disappear as soon as move the mouse away.

Below is a screenshot of Yoshimi synth running and me hovering the mouse over it's task list icon.

[Clarity]

Hi @geo_c

Not sure if this will help in your XFE.

• Install and look at qpwgraph. Does the wiring look right to you for what you're seeking?

Hope this helps

[Clarity]

I've been away for days caught by a massive storm in US. Will arrive home on Monday. Today is 1st day I can get power to my laptop.

In the span of a couple days, I see KDE-Wayland is now official at v1.5 ... Wow! They are really rapidly at work to be so far ahead of GNOME that they may be impossible to catch. @Sofiya's implementation is beautiful! With the KDE features, nothing gets in the way. Smooth, robust, easy to navigate.

Runs like a bandit; namely FAST!

[geo_c]

Not sure if this will help in your XFE.

• Install and look at qpwgraph. Does the wiring look right to you for what you're seeking?

qpwgraph is already built in. It's working fine. But jack audio apps aren't finding the pipewire-jack framework, which also appears to be installed. So I'm not sure what's up with that. I installed and started a couple in the terminal and get the error message that the jack connection is not found by the apps.

Xfe is working great, my question with that wasn't about Xfe, but about accessing the /mnt/home drive from user spot, and what is the best way to be able to read and write to that drive. I booted another OS and changed permissions of a folder so I could copy the Xfe conifgs into KDE-plasma user spot. That worked, but I wasn't able to do it running as user spot. So I'm simply a multi-user noob, and don't know how it's really supposed to work.

[geo_c]

Runs like a bandit; namely FAST!

Well it's fast, and I'm finding all these KLVs boot and run extremely fast. Now that I have more up to date machines, these OS's are booting about as fast as waking up a sleeping display. They are mostly 4-10 seconds to get to a desktop, though KDE is notably slower than Spectr.

And they all run particularly fast. My perception of course, with no real benchmark testing.

Speed and capability are certainly all there in Plasma, what I need do to further test and explore is it's usefulness for pro audio applications, in particular pipewire-jack.

It seems even though it's Void under the hood, KDE-wayland may involve more tinkering than other xorg versions. I had no trouble getting pipewire-jack to run on Spectr, Airedale, and Bookworm. Just install it and some jack apps, and they worked.

So like I say, more exploration needed for me in that area.

[williwaw]

Xfe is working great, my question with that wasn't about Xfe, but about accessing the /mnt/home drive from user spot, and what is the best way to be able to read and write to that drive. I booted another OS and changed permissions of a folder so I could copy the Xfe conifgs into KDE-plasma user spot. That worked, but I wasn't able to do it running as user spot. So I'm simply a multi-user noob, and don't know how it's really supposed to work.

in a terminal...
# su
or
# su -

When you use su, the system switches to the specified user's account but keeps the current environment, including the current working directory, shell variables, and other settings. It doesn't fully simulate a login session as the specified user.

On the other hand, su- or su -l or su --login simulates a full login session for the specified user. It resets the environment to that of the target user, including the home directory, shell, and environment variables.

then your mount command or a script that has your mount command
or just call xfe

[wiak]

Xfe is working great, my question with that wasn't about Xfe, but about accessing the /mnt/home drive from user spot, and what is the best way to be able to read and write to that drive. I booted another OS and changed permissions of a folder so I could copy the Xfe conifgs into KDE-plasma user spot. That worked, but I wasn't able to do it running as user spot. So I'm simply a multi-user noob, and don't know how it's really supposed to work.

in a terminal...
# su
or
# su -

When you use su, the system switches to the specified user's account but keeps the current environment, including the current working directory, shell variables, and other settings. It doesn't fully simulate a login session as the specified user.

On the other hand, su- or su -l or su --login simulates a full login session for the specified user. It resets the environment to that of the target user, including the home directory, shell, and environment variables.

then your mount command or a script that has your mount command
or just call xfe

I tend to also want a root user filemanager, so I open a spot terminal and enter:

Code: Select all

sudo thunar

From that root-user owned filemanager window, simply right clicking on directory window allows you to open a root user terminal and at that directory. That's the way I do such work mostly.

The only other thing I often do is make a certainly directory that was otherwise owned by root user, owned by user spot (or whoever). To do that, using for example above thunar as root and then root terminal methodology, I issue the command that makes a directory 'belong' (and thus permission-wise) to user spot as follows:

Code: Select all

chown -R spot:spot NameOfDirectory

The -R means recursive so includes all subdirectories. The spot:spot means user spot and also group spot. This is the sort of thing you need to become used to doing to allow spot to write to the likes of a usb stick directory or directories (otherwise only root can do that) or to a mounted partition that was otherwise all owned as user root. In fact you can make the whole contents of such a partition recursively owned by spot:spot- that makes saving files from a browser started as user spot a straightforward matter too - rather than having to clog up spot's home directory, which spot already 'owns', with downloads... The other advantage of making other areas owned by spot is that if you used /home/spot to save too much, that has to be saved back to upper_changes savefolder whereas if you save to an alternative media (usb stick say) or to a separate mounted partition that does not get stored in save folder (so helps keep upper_changes small).

[williwaw]

In fact you can make the whole contents of such a partition recursively owned by spot:spot- that makes saving files from a browser started as user spot a straightforward matter too............

for the sake of illustration, suppose one had an external drive that was used with multiple machines, most all being operated as the single-user root.

without recursively changing permissions when acessed by spot (on a multi-user install), is there a way to mount the drive "as" spot?
ie.
configuring spot to have mount privileges
and
giving read-write-execute privileges to spot for files owned by root but only on that particular mounted filesystem or partition, and still be a the constrained user spot in the booted instance?

[geo_c]

Thanks @wiak and @williwaw, that gets me off on the right start.

So I have the right idea changing directory permissions, but might be better using sudo in other or most cases. I have to either open file managers, mount drives with sudo, or changing directory permissions recursively.

I tried a few weeks back changing permissions on a large directory recursively, and that approach leaves me with a few questions.

Based on what I did yesterday, that is change permissions of small directory to user:root, group:spot, and copy files into spot user that way, it seems that would be an appoach to having certain directories available on a drive to pups running as root and frugals running as spot. In other words changes those directory permissions and be able to access from root or spot.

I noticed yesterday that the directory I changed to user:root group:spot shows the group as 1001 when accessed from pups running as root.

So that approach would not necessarily be good if all the frugals running as spot didn't use the same 1001 for user:spot?

Also a little fuzzy on what the result is with using a file manager opened with sudo, or mounting with sudo. If using the proper sudo option allows me to read/write/execute from a mounted drive while running as spot or root.

Before I do something drastic like change recursively permissions on a 20GB directory full of files, I want to make sure I have it straight.

And I notice @williwaw jumped in ahead of me with a similar question.

So for example, if I changed the permissions on a large directory of portable apps to user:root group:spot, I should be able to run them from a root user pup, or a spot user frugal like KDE-Plasma, right?

[wiak]

So that approach would not necessarily be good if all the frugals running as spot didn't use the same 1001 for user:spot?[/b]

Yes, it is the numeric value that is important (how Linux really knows its users), not really the name.

You can find what numeric spot has by checking that in the file /etc/passwd (e.g. less /etc/passwd).
The groups (and the users that are in them, which actually shows user names...sigh...) can be checked by examining the file /etc/group (e.g. less /etc/group). Alternatively, if logged in as a particular user, you can check what groups you are a member of by entering the command: groups

Don't try and modify the likes of /etc/passwd or /etc/group directly (though it can be done). Use the likes of usermod command (google for how to use that if ever you need to; I forget all the time...)

It may well be that a different distro will have assigned a different numeric to a particular name such as spot. It may therefore well be the case that 'spot' in Puppy is not the same 'spot' as in KL. It is the number that matters!

I have a user wiak on my Linux Mint system that was the first normal user added, and by default wiak is given value 1000. That means that when I am using Linux Mint, I can access the same drive partitions/directories as when I am in a KL distro with user spot (i.e. wiak is same as spot because when booting the systems they have userid 1000). In KL, I often also have a user called 'firstrib' and if that was added second, that will have userid 1001, which would therefore match Puppy spot value (if 1001 is actually spot in Puppy; i.e. KL firstrib is actually Puppy spot in that case, if you see what I mean).

As far as user and group permissions are concerned; yes, if you give the group the relevant read/write/execute permissions and user you are logged in as is in the relevant group then they should be able to copy according to not only user permissions but the assigned group permissions too so you could have set up permissions on some directories to allow ease of copying certainly

[geo_c]

@wiak and @williwaw

I'm starting to figure out the lay of the land here.

I ran Xfe from the Konsole terminal and changed one of the shared directories on /mnt/home that I use all the time for Xfe themes. It contains sets of custom Xfe icons, and what I do is link that folder full of icon sets to the /root/.config/xfe folder when using pups and run-as-root KLs, that way any time I edit the icon sets, the changes automatically show up in every distro.

So I changed the permissions of the folder recursively to user:root group:spot, and linked the folder to both the spot instance of /.config/xfe and the root instance of /.config/xfe.

I also set the root instance of Xfe to again give me the annoying start up message "Warning! Running as root" which I always disable. But it's not so much a problem getting confused about what user Xfe is started as, because in KDE-Plasma the window title bars indicate if the window is running as root.

So I have a LOT of these types of links in my system, not just for themes and icons, but for things like terminal app configs and so forth. So it may take me awhile to sort out my multi-distro shared file scenario.

Edit: and I set my portable-app folder permissions the same and I can run portables! I'm all set.

Now that I have the basic multi-user permission thing headed in the right direction, I can begin to figure out why the pipewire-jack applications aren't working in my KDE-Plasma, and get back on topic.

Sorry to hi-jack the topic @Sofiya

KDE-plasma is starting to grow on me. It's very nice and smooth.

[geo_c]

Just like in the recent KLV-Boxer, in order to get Thunderbird-portable64 to run I had to install libdbus-glib-1.so.2.3.5 and a link is created in /usr/lib called libdbus-glib-1.so.2 which Thunderbird finds.

The package that pulls in the library is called: dbus-glib

I'm not sure why that hasn't been necessary in the other KLV's, maybe dbus-glib is in the earlier build scripts.

[geo_c]

@Sofiya,

I'm now running smoothly in KLV-Plasma and exploring the pipewire-jack system.

I don't necessarily think this why I'm not able to get the jack applications to connect, but what I found is that in addition to the pipewire-jack package installed, there is also what we call native jack: libjack installed. I don't think pipewire-jack pulls that in, and could possibly be a factor.

So I tried to uninstall libjack, but OctoXbps is telling me: "Transaction aborted due to unresolved dependencies."

It won't uninstall.

I'm looking at the FR_minimal_KDE_plasma_desktop.sh right now to see if might be able to do a rebuild and alter the plug. I can look at all my other Voids running pipewire-jack and write a plug including all the necessary components.

Audio is working well with other apps, except for MuseScore which is not a jack app. And reading the terminal output, the error is the snd seq module not being found. I've tired using the modprobe snd seq which has been necessary in other KL's. I also tired sudo modprobe snd seq which doesn't get the sound working in Musescore either, so it might be just a midi issue related to snd seq, but as with the jack apps, I'm not seeing any stream for Musescore in the qpwgraph.

Maybe @rockedge has some ideas about it.

[Sofiya]

Yoshimi

@geo_c We will become musicians with you

[fredx181]

So I tried to uninstall libjack, but OctoXbps is telling me: "Transaction aborted due to unresolved dependencies."

It won't uninstall.

Perhaps it will tell you more about the reason why if you do from terminal : xbps-remove libjack (probably related to pipewire-jack)

[geo_c]

So I tried to uninstall libjack, but OctoXbps is telling me: "Transaction aborted due to unresolved dependencies."

It won't uninstall.

Perhaps it will tell you more about the reason why if you do from terminal : xbps-remove libjack (probably related to pipewire-jack)

Yes, I believe that's right. Looking at my Spectr pipewire-jack libraries I see that libjack is installed, and I'm pretty sure I didn't specifically install it.

EDIT: and I should add that the libjack is placed in the /usr/lib/pipewire directory, so it's a pipewire jack dependency.

I'll have to play around with KLV-plasma and the audio apps more as I have time this week.

[Sofiya]

@Sofiya,

I'm now running smoothly in KLV-Plasma and exploring the pipewire-jack system.
I also tired sudo modprobe snd seq which doesn't get the sound working in Musescore either, so it might be just a midi issue related to snd seq, but as with the jack apps, I'm not seeing any stream for Musescore in the qpwgraph.

Maybe @rockedge has some ideas about it.

I wrote about this (modprobe snd seq)
save and reload

place in /etc/modules-load.d/

[geo_c]

place in /etc/modules-load.d/

Thanks!

That's simple, so that's how it's done.

In my Spectr build I have modprobe snd-seq in a script in Startup. Maybe I should try and copy this in and disable the startup script.

[Sofiya]

MuseScore Studio

[Sofiya]

I have it installed

Code: Select all

# Pipewire volume
xbps-install -y paprefs alsa-plugins-pulseaudio pipewire wireplumber alsa-utils alsa-pipewire libjack-pipewire gstreamer1-pipewire pavucontrol pamixer ffmpeg ffmpegthumbs qpwgraph

[geo_c]

Okay I got Yoshimi running using pw-jack Yoshimi and all the midi shows up with the module loaded! Working good!

That's a good start:

But when I start Calf plugins with or without pw-jack I'm getting a jack connection error. So I'll keep plowing through and figure it out.

Since Yoshimi terminal output says it's using jack audio, that's a successful test of pipewire jack running, So now I need to start installing all the apps and see what's required to start them properly.

Code: Select all

✘ spot@void-live  ~  pw-jack yoshimi      
Yoshimi 2.3.2 is starting
Using jack_audio for audio and alsa_midi for midi
Set jack session callback failed
Alsa midi priority is 1
Build Number 2318
Clientname: yoshimi
Audio: jack -> 'default'
Midi: alsa -> 'LPK25:0'
Oscilsize: 512
Samplerate: 48000
Period size: 1024

Yay! We're up and running :-)

Found 1770 instruments in 48 banks
Root 5. Bank set to 5 "Arpeggios"
yoshimi>