SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The taskbar thumbnails are lost under X11/Plasma5 after the update of Mon Jun 13 21:02:58 UTC 2022 where is also KDE Frameworks 5.95.0
Instead of the small imagine of the window, is presented the application icon.
I've found NO solution yet for this issue, other than rolling back to KDE Frameworks 5.94.0, even I've rebuilt locally the KDE Plasma 5.24.5.
However, the Wayland/Plasma5 taskbar thumbnails are alive and sound - I've noticed no issues in the Wayland side of Plasma5 with KDE Frameworks 5.95.0.
Still, I wonder how the heck slipped this obvious (and obnoxious) issue in the -current's updates...
I should understand that no one from the Slackware Team uses Plasma5 excluding Mr. Hameleers?
Last edited by LuckyCyborg; 06-14-2022 at 03:24 AM.
The taskbar thumbnails are lost under X11/Plasma5 after the update of Mon Jun 13 21:02:58 UTC 2022 where is also KDE Frameworks 5.95.0
...
I should understand that no one from the Slackware Team uses Plasma5 excluding Mr. Hameleers?
The taskbar thumbnails are lost under X11/Plasma5 after the update of Mon Jun 13 21:02:58 UTC 2022 where is also KDE Frameworks 5.95.0
Instead of the small imagine of the window, is presented the application icon.
I've found NO solution yet for this issue, other than rolling back to KDE Frameworks 5.94.0, even I've rebuilt locally the KDE Plasma 5.24.5.
However, the Wayland/Plasma5 taskbar thumbnails are alive and sound - I've noticed no issues in the Wayland side of Plasma5 with KDE Frameworks 5.95.0.
Still, I wonder how the heck slipped this obvious (and obnoxious) issue in the -current's updates...
I should understand that no one from the Slackware Team uses Plasma5 excluding Mr. Hameleers?
I've rebuilt the plasma-framework package with this patch and I can confirm that it restores the functionality of taskbar thumbnails under X11/Plasma5.
I am a bit puzzled. I didn't build the python/PyQt5 bindings when building qtermwidget-1.1.0, (released after this commit) however qterminal works here. Which features do I miss by lacking these bindings?
PS You may just request inclusion of LXQt in Slackware, but don't hold you breath
Last edited by Didier Spaier; 06-15-2022 at 05:41 AM.
Reason: PS added.
I am a bit puzzled. I didn't build the python/PyQt5 bindings when building qtermwidget-1.1.0, (released after this commit) however qterminal works here. Which features do I miss by lacking these bindings?
So am I, is just optional.....but would be nice to have it.
Quote:
PS You may just request inclusion of LXQt in Slackware, but don't hold you breath
How is the recommended way to make a request? Just an email to Pat or we have for things like that a specific form?
Hi , i see a new parameter introduced in the kernel modules build to reduce modules size removing debug things.
But not need that , we have new option to do this
Quote:
INSTALL_MOD_STRIP=1
Your trick is find files with ko extension , but it fails if we use module kernel compress XZ/ZSTD cause files entensions change when use this parameters.
If enable ZSTD module compress the driver.ko its end naming driver.ko.COMPRESSION , like driver.ko.zst , then your trcik fails and its not correct cause we have a offcial and more safe way to strip the modules.
Last edited by USUARIONUEVO; 06-15-2022 at 08:55 PM.
Hi , i see a new parameter introduced in the kernel modules build to reduce modules size removing debug things.
But not need that , we have new option to do this:
Code:
INSTALL_MOD_STRIP=1
Your trick is find files with ko extension , but it fails if we use module kernel compress XZ/ZSTD cause files entensions change when use this parameters.
If enable ZSTD module compress the driver.ko its end naming driver.ko.COMPRESSION , like driver.ko.zst , then your trick fails and its not correct cause we have a official and more safe way to strip the modules.
Not sure what post you are answering exactly. Assuming it is this one, and the trick is in the code snipped a way to find which kernel modules include in the initrd, I knew it was fragile as I wrote it in the post But now I can get rid of all this complication with just this command to build the initrd:
Code:
dracut -q
This make an all-included initrd not tied to a specific host. Yes it is huge (55M) but this command:
Code:
lsinitrd|grep ko.zst|wc -l
tells that it contains no less that 1039 kernel modules (and also 64 firmware files, themselves xz compressed). Fortunately zstd compression (for the modules) and xz compression (for the firmware) help to limit the size of this initrd (which also includes a rescue shell with many utilities to investigate and solve issues, including for instance cryptsetup). dracut also allows with just a few appropriate options in its command and specific parameters in the boot command line to unlock a LUKS device using a LUKS key, stored either on an USB stick or even embedded in the initrd itself, so that you are asked the passphrase only once by GRUB, as illustrated by the attached pics. It took me several hours to find the right parameters to write in /etc/default/grub, fortunately I ended up coming across this thread.
So I will use dracut instead of mkinitrd and friends from now on. Not that mkinird be bad in any way, but this move will make the settings and maintenance a lot easier in Slint, freeing some time for other tasks in the future.
Also, yesterday I have built a kernel-modules-5.18.4 packages with this line:
Code:
make INSTALL_MOD_PATH=$PKG INSTALL_MOD_STRIP=1 modules_install || exit 1
It indeed stripped each module one at a time before compressing it, but the end result (unpacked package size) is the same as with the 5.18.3 package (85M) just because there was nothing to strip, as in the kernel config I did set: CONFIG_DEBUG_INFO_NONE=y.
Last edited by Didier Spaier; 06-16-2022 at 05:03 PM.
Reason: pics added.
I post the new mod install strip option , cause building a custom 5.18.4 , without the slackbuild , i noticed the modules size are 900mb when in branch 5.17 are arround 170 mb.
Then i discover this new option to install modules striped.
Thats all , reading the slackbuild from patrick y see he see this same issue and make a variable to strip the modules , but thats probably cause he not found that new "strip" option for install.
If inspectioning the kernel-modules.slackbuild you can see something like this
Quote:
if [ "$STRIP_DEBUG" = "YES" ]; then
echo "Stripping debug info from kernel modules..."
find $PKG -name "*.ko" -exec strip --strip-debug "{}" \;
fi
This works if no enable module kernel compression , cause the compression make change in the name extension adding name of compression type , as i explain back.
But this is unnecessary , cause can use the official way STRIP=1 when install the modules...and works independently if you use a base *.ko or *.ko.xz or *.ko.zst , cause official way strip and compress later.
Thats all , simply.
EDIT: Thats for branch 5.18 or newer , branches 5.17 builds and install modules stripped by default , im not sure if 5.18 have a bug or cause we have that new install option.
If you want to see excatly what im talking here , download a 5.18.4 and build , see after modules install , size is arround 1gb if not use the option strip=1 when install modules.
But as i say im not sure if this is the new way to do , or is a bug in 5.18.x in the past by default , the modules install stripped , but now need to explicitly enable.
Last edited by USUARIONUEVO; 06-16-2022 at 10:10 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.