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.
It looks to me like the Terminus font incorrectly uses the italic variant of some Cyrillic characters. See the table at the bottom of this paragraph of the Wikipedia article.
I spoke to an Ukrainian colleague about this today. His comment was that the variants used by Terminus are "handwritten" variants. This is also mentioned in your Wikipedia link.
So Terminus enables these alternative glyphs by default for "de", "i" and "j" letters. It also provides such glyph for letter "ge", but it's not enabled by default. I don't know the reason. But it seems to me that it would be a good idea to apply the patches I mentioned in my previous post, so that the normal glyphs are used consistently.
I don't know what the state of play with the installer is, but it would be nice to have encryption support out of the box for Slack 15. I haven't tried it, but I believe the Slint installer has a bunch of new features that could be worth importing?
An extensive documentation about the new Slint installer is provided here. The stuff used to build the installation ISO is there. Some caveats:
As set up in Slint, full encryption with no LVM uses GRUB for unlocking the drive and puts a LUKS key in the initrd (the initial one and the one built for each new kernel).
More generally some modifications in the installed system (mostly in scripts) are necessary to bring the new features provided in Auto mode, running 'auto'.
I do intend to port some of these features in the Manual mode, running 'setup', but this is not in top of my TODO list.
I won't go into the gory details here, but if there is an interest to bring some of the listed features to Slackware I am available, by email, text chat via IRC (server irc.freenode.net, channel #slint) and voice chat via mumble (server slint.fr, default port number).
PS I suggest to first install Slint in Auto mode in a Qemu VM to assess the new features of the installer. It takes less than 15 minutes with a decent hardware, needs 2G of RAM and a 30G virtual hard disk.
Last edited by Didier Spaier; 04-13-2021 at 11:37 AM.
And there is also the stand-alone XWayland 21.1.1 server, with the same CVE fix and tons of other features for Wayland - compared with the monolithic Xorg:
Do you mean in the font chooser widgets? At least half of the entries in there already are for non-Latin characters, and I just scroll past them. After enabling 09-texlive.conf, I get a bunch of new entries for Latin Modern and TeX Gyre variants, and just a few others. Let me know if you meant something else.
Do you mean in the font chooser widgets? At least half of the entries in there already are for non-Latin characters, and I just scroll past them. After enabling 09-texlive.conf, I get a bunch of new entries for Latin Modern and TeX Gyre variants, and just a few others. Let me know if you meant something else.
If i remember right, some default fonts changed here and there, so this might not be what the usual user wants to have. conf.avail is there, so anybody may enable it easily. It's not necessary to build lilypond.
So Terminus enables these alternative glyphs by default for "de", "i" and "j" letters. It also provides such glyph for letter "ge", but it's not enabled by default. I don't know the reason. But it seems to me that it would be a good idea to apply the patches I mentioned in my previous post, so that the normal glyphs are used consistently.
They are already normal. But suggested by these patches glyphs are harder to read on small resolutions (8x8, 8x14, 8x16).
As for me that it would be a bad idea to apply the patches mentioned in your previous post for all users of Terminus. My native language is Russian.
They are already normal. But suggested by these patches glyphs are harder to read on small resolutions (8x8, 8x14, 8x16).
That's a very good argument, and would probably explain why these glyphs were chosen in the first place.
But could you confirm whether or not these glyphs generally belong in italic and cursive scripts? And if so, do they not look slightly out of place when they appear among upright characters?
When you do, be interesting to know what model UPS too and if its the bcmxcp_usb driver.
Finally got around to installing and testing, no problems here on -current with an Eaton 5E650iUSB and usbhid-ups driver (apart from the annoying need to boot with "usbhid.quirks=0x0463:0xffff:0x08").
The latest version 0.8 added an unique support for interacting with elogind and auto-quitting on user logout, at our feature request accepted by this friendly developer.
I can say that this elogind integration was added specially for Slackware and developed under Debian and its systemd(-logind) then this is a supplementary guarantee that the logind API is fully respected, until it works similarly under systemd, but of course there is no need for this feature.
This feature of auto-quitting on user logout is particularly useful for running programs which are developed as "user target" daemons for systemd, like are the three PipeWire daemons. But the daemon itself is a program developed since 12 years, for multiple operating systems, and it could be generally useful to run system services which has no ways to daemonize themselves.
For example, it can help to create a complete rc.d script/service (with start/restart/stop/status) for xBrowserSync, which is a NodeJS based server.
Also, please note that this daemon supervisor has a really small footprint, and it could be packaged in a 100KB package, which installs a 200KB program (the daemon itself), a man file and a configuration file.
I should also note that I use this daemon supervisor with great success since its elogind integration development started, as I described also in a dedicated thread, where I described also a packaging approach:
In other hand, please consider to add on the PipeWire package the following three sample files for the global XDG autostart.
/etc/xdg/autostart/pipewire.desktop-sample
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
The first two files, IF renamed with a proper .desktop extension, will start the main daemons of PipeWire, and this will enable the standard support from PipeWire, as expected by Wayland/Plasma5 and various features of it will start working, for example the taskbar thumbnails.
The third file, IF renamed with a proper .desktop extension, will start the Pulse Audio replacement daemon (just like Fedora intends to do), and this will need also the disabling of PA server by the user, by renaming the file /etc/xdg/autostart/pulseaudio.desktop and changing on /etc/pulse/client.conf
Code:
autospawn = no
So, probably somewhere should be added those instructions of how to disable the PulseAudio server while using the PipeWire Pulse-compat server.
However, please note that I do NOT ask for enabling the PipeWire daemons by default, BUT about adding a consistent infrastructure at user decision whether s/he would enable those PipeWire daemons, considering our past experiences with them.
So, I would say that my proposal is about transforming the Slackware-current on being "PipeWire ready", to facilitate for its users to experiment with the PipeWire features, and definitely is NOT about requesting a fully switching to PipeWire, like Fedora intends to do.
Please consider this proposal!
It's only about adding a really small program which could be useful in many ways and about adding just three sample files!
And this little program adds an unique feature to Slackware, which no other non-systemd distribution has yet: ability to handle properly the "user target" daemons made for systemd.
It's a feature added on this daemon supervisor by @raforg specially for Slackware and we can be the first ones having this feature. It could be something unique compared with other distributions.
Last edited by ZhaoLin1457; 04-14-2021 at 03:53 PM.
I have finally find out how openSUSE do the setup of Wayland/Plasma5 and I think that I have a proposal of big importance for our own Wayland/Plasma5.
As a preamble, I noticed since long time that on opeSUSE the "standard" sessions of Wayland/Plasma5 are much more stable and some applications uses XCB (so, XWayland) backend and others the native Wayland backend.
For example, on openSUSE, will use the XCB backend applications like: Konsole, KWrite, Kate, KMail, Dolphin, Krusader or even SMPlayer, while another ones somehow prefers the native Wayland.
The openSUSE has also another Wayland session: "fullwayland" which is visible less stable and where everything uses only the Wayland backend, and it behaves roughly similar with what Slackware do today.
I lurked on the sources of openSUSE since really long time - since the Plasma5 was still in KTown, trying to understand how they do that "graphical backend auto-switching" and why the "standard" Wayland/Plasma5 sessions are much stable.
So, finally I managed to emulate this behavior on Slackware.
Well, looks like the Plasma5 applications are capable to choose alone between the XCB and native Wayland backend, IF the Qt5 is built in a particular way:
This is a patch for the current qt5.SlackBuild which generates this particular setup. Essentially they literally specify "-egl" and "-eglfs" BUT I think the real trick is that they have "xcb;wayland" instead of "xcb" for "-qpa"
Aditionally, they patches the plasma-workspace
Code:
From 3deadbfcdf776eb0c994bb4d719e601160943bfa Mon Sep 17 00:00:00 2001
From: Fabian Vogt <fabian@ritter-vogt.de>
Date: Wed, 28 Aug 2019 15:09:49 +0200
Subject: [PATCH] Set GTK_BACKEND=x11 in a wayland session
Works around missing window decorations and broken config file reading
---
startkde/startplasma-waylandsession.cpp | 5 +++++
1 file changed, 5 insertions(+)
Index: plasma-workspace-5.15.80git.20210121T134153~83e5f9011/startkde/startplasma-waylandsession.cpp
===================================================================
--- plasma-workspace-5.15.80git.20210121T134153~83e5f9011.orig/startkde/startplasma-waylandsession.cpp 2021-01-21 14:41:53.000000000 +0100
+++ plasma-workspace-5.15.80git.20210121T134153~83e5f9011/startkde/startplasma-waylandsession.cpp 2021-01-22 08:39:19.900539408 +0100
@@ -47,6 +47,11 @@
out << "startplasma-waylandsession: Starting up...";
if (qEnvironmentVariableIsSet("DISPLAY")) {
+ // GTK3 uses the wayland backend by default, but its implementation is not correct
+ // enough to work well here. Window decorations are missing, for instance.
+ if (!qEnvironmentVariableIsSet("GDK_BACKEND")) {
+ qputenv("GDK_BACKEND", "x11");
+ }
setupX11();
} else {
qWarning() << "running kwin without Xwayland support";
This small patch is for fixing some eventual issues of GTK applications on Wayland.
And, finally, IF we want to have also the "full Wayland" sessions like openSUSE - it's specially useful to have a comparation term to what we have without this particular setup.
This is my proposal for -current. Specially the Qt5 rebuilding part is essential, because it's a really laborious endeavor to leave it on the hands of users.
So, they are small changes - they are also insignificant for the X11/Plasma5 sessions, BUT the result is a visible better and more stable Wayland/Plasma5 sessions.
Okay, the visible better and more stable are the "standard" Wayland/Plasma5 sessions, because the Full Wayland ones are just like Slackware has today.
Oh, and really, really please upgrade to the stand-alone XWayland server!
The one included today in Slackware-current acts just like someone runs x11/Plasma5 with a VESA Xorg driver. It's fantastic slow.
I can confirm that the Qt5 rebuilding as proposed by you, associated with the the plasma-workspace patch, indeed results in a quite stable working of the Wayland/Plasma5 sessions and that indeed the Qt5 and KDE applications looks like choosing the graphical backend. Some uses XCB and some uses the native Wayland.
I do not believe that's an accidental behavior, but rather a design made to permit a seamless transition from X11 to Wayland of Plasma5 and its applications.
Unfortunately, looks like right now we force all programs to use a Wayland backend on the Wayland/Plasma5 sessions, with negative effects on functionality and stability. I hope this will be fixed.
There I presented my experiences with this rebuilt Qt5 and patched plasma-workspace:
I am sorry for bringing this up again, but honestly, this would make life much much easier, and the modification is tiny:
Add
Code:
find ./ -type f -exec setfattr --name=trusted.slackware_v1.makepkg.package_name "--value=${TAR_NAME}" {} +
to line 414 of /sbin/makepkg (just before archiving).
The "trusted" namespace means that only root is going to see (and use) this.
This would make it much easier to find out what is going on in the threads like this: https://www.linuxquestions.org/quest...ps-4175693511/ (/etc/mtab tagged by the package it is coming from). It would be much easier to find when some files are missed by updates, or whether there are stray files at the file system.
"-exec {} +" performance penalty is tiny, essentially comes at the same price as two additional "find ." On my machine (2014), it tags 5000 files per second.
Backwards compatibility is ultimate: if xattrs are unsupported, they are ignored. And you can just never use them at all.
I have finally find out how openSUSE do the setup of Wayland/Plasma5 and I think that I have a proposal of big importance for our own Wayland/Plasma5.
As a preamble, I noticed since long time that on opeSUSE the "standard" sessions of Wayland/Plasma5 are much more stable and some applications uses XCB (so, XWayland) backend and others the native Wayland backend.
For example, on openSUSE, will use the XCB backend applications like: Konsole, KWrite, Kate, KMail, Dolphin, Krusader or even SMPlayer, while another ones somehow prefers the native Wayland.
The openSUSE has also another Wayland session: "fullwayland" which is visible less stable and where everything uses only the Wayland backend, and it behaves roughly similar with what Slackware do today.
...
So, they are small changes - they are also insignificant for the X11/Plasma5 sessions, BUT the result is a visible better and more stable Wayland/Plasma5 sessions.
Okay, the visible better and more stable are the "standard" Wayland/Plasma5 sessions, because the Full Wayland ones are just like Slackware has today.
Look, before to post this proposal, I do not just read articles on Internet, hopping Slackware to test the things instead for mine...
Contrary, I struggled since Plasma5 was in KTown with the Wayland/Plasma5 and I did myself those experiments, and I seen on bare metal how those things behaves.
And from my experience, the way we setup Wayland/Plasma5 today causes problems for many programs. AND, at least on Slackware, this graphical backend auto-selection does NOT happens, contrary of what that article quoted by you says.
On the Wayland/Plasma5 of ours, from Slackware-current, any Qt5 and KDE software uses the native Wayland backend - I seen non one to chose the XCB unless it is forced to do this. And I seen with my own eyes, that this causes crashes and misbehavior, up to not working, as SMPlayer cannot play something.
However, the setup which I proposed is way more stable. That was physically tested on bare metal by me and also the applications CHOOSE their graphical backend.
For example, Konsole or Dolphin uses XCB and KInfoCenter uses Wayland - on same Wayland/Plasma5 session.
Last edited by LuckyCyborg; 04-15-2021 at 08:16 AM.
Look, before to post this proposal, I do not just read articles on Internet, hopping Slackware to test the things instead for mine...
However, the setup which I proposed is way more stable. That was physically tested on bare metal by mine.
That is why i mentioned that you have probably already read it. I didn't imply you didn't do your research and that you posted your suggestion out of the blue. I am sorry if my post appeared to do so but i didn't mean any offense.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
