LinuxQuestions.org - Requests for -current (14.2-->15.0)

Hello,

Recently I was looking at some Russian text in the console with Terminus font, and I was surprised to see some characters looking different than I expected. See attached file for a comparison between the letters of Cyryllic script in Terminus and in Monospace fonts (differences are underlined). I'm not using Cyryllic on a daily basis (and only know basic Russian), but this seems strange to me, I've never seen glyphs like the Terminus defaults before. See Wikipedia entry on Russian alphabet for comparison: https://en.wikipedia.org/wiki/Cyrill...habets#Russian.

Terminus font provides additional variants for several characters (see http://terminus-font.sourceforge.net for details). I was wondering if we could change the defaults for Slackware-current so that the three outstanding Terminus characters look like their Monospace counterparts? This would require applying two patches (shipped with Terminus sources) in the SlackBuild:

Code:

cat alt/dv1.diff | patch -p0 --verbose || exit 1

cat alt/ij1.diff | patch -p0 --verbose || exit 1

Are there any users here on the forum who read Cyryllic script on a daily basis? If so, please comment: is my proposition reasonable?

Another thing is the tilde character, which is by default is aligned so that it's at the top of the line. Terminus font provides another variant, with the character in the middle of the line (i.e. centered vertically). This is changed with another patch:

Code:

cat alt/td1.diff | patch -p0 --verbose || exit 1

Arguably, the tilde patch is purely aesthetic, but the Cyryllic patches are more important IMHO.

Nobby6

04-12-2021 08:12 PM

Quote:

Originally Posted by MDKDIO (Post 6240228)

I agree with you, odd that the link is not working.

But link to announcement is working on the mirror sites (for download)
http://cdn.postfix.johnriley.me/mirr....RELEASE_NOTES

Even more strange its 12 hours later and still 404'd, given the time passed, I've emailed Wietse

(the email has come through tho)

perrin4869

04-12-2021 09:44 PM

Since the beta is out, before the 15.0 release, I wanted to bring up again https://www.linuxquestions.org/quest...es-4175688858/.
I noticed there were a few changes applied to mkinitrd_command_generator applied these last 2 weeks, but this issue appears to remain unsolved

elyk	04-12-2021 11:11 PM

Please add this symlink to the texlive package:

Code:

/etc/fonts/conf.d/09-texlive.conf -> ../conf.avail/09-texlive.conf

This will make a few more fonts available to the system, in particular TeX Gyre (needed by Lilypond).

davjohn

04-13-2021 01:34 AM

There are some errors in ffmpeg.SlackBuild.
It should probably be like this:

Code:

--- ffmpeg.SlackBuild.orig      2021-04-13 08:14:17.608298161 +0200

+++ ffmpeg.SlackBuild  2021-04-13 08:17:40.119981787 +0200

@@ -119,7 +119,7 @@

 libcodec2=""  ; [ "${CODEC2:-no}" != "no" ]      && libcodec2="--enable-libcodec2"

 libsoxr=""    ; [ "${SOXR:-no}" != "no" ]        && libsoxr="--enable-libsoxr"

 libsrt=""    ; [ "${SRT:-no}" != "no" ]          && libsrt="--enable-libsrt"

-libzimg=""    ; [ "${ZIMG:-no}" != "no" ]          && libsrt="--enable-libzimg"

+libzimg=""    ; [ "${ZIMG:-no}" != "no" ]          && libzimg="--enable-libzimg"

 chromaprint=""  ; [ "${CHROMAPRINT:-no}" != "no" ] && chromaprint="--enable-chromaprint"

 vapoursynth=""  ; [ "${VAPOURSYNTH:-no}" != "no" ] && vapoursynth="--enable-vapoursynth"

 opencore_amr="" ; [ "${OPENCORE:-no}" != "no" ] && \

@@ -131,7 +131,7 @@

 decklink=""  ; [ "${DECKLINK:-no}" != "no" ]  && \

  { decklink="--enable-decklink" ; \

    SLKCFLAGS="$SLKCFLAGS -I/usr/include/decklink" ; }

-vulkan=""    ; [ "${VULKAN:-no}" != "no" ]      && librsvg="--enable-vulkan"

+vulkan=""    ; [ "${VULKAN:-no}" != "no" ]      && vulkan="--enable-vulkan"

 libglslang="" ; [ "${GLSLANG:-no}" != "no" ]    && libglslang="--enable-libglslang"

 liblensfun="" ; [ "${LENSFUN:-no}" != "no" ]    && liblensfun="--enable-liblensfun"

franzen

04-13-2021 01:50 AM

Quote:

Originally Posted by elyk (Post 6240430)

Please add this symlink to the texlive package:

Code:

/etc/fonts/conf.d/09-texlive.conf -> ../conf.avail/09-texlive.conf

This will make a few more fonts available to the system, in particular TeX Gyre (needed by Lilypond).

This will add way to much fonts with strange font effects in various apps.
See https://www.linuxquestions.org/quest...ts-4175693179/ for building lilypond with the Tex Gyre fonts.

saxa	04-13-2021 05:19 AM

librsvg-2.50.4
https://download.gnome.org/sources/l...-2.50.4.tar.xz

niksoggia

04-13-2021 05:28 AM

/usr/bin/lrz has a split personality

4 Attachment(s)

Hello Pat,

/usr/bin/lrz provided by minicom is the zmodem transfer protocol,
/usr/bin/lrz provided by lrzip is a compression utility.

Since one of the two must go, my suggestion is to remove all the "l" prefixes in lrszsz binaries (please see my patch).

I just made a full slackware64 install and then wrote a simple script to find similar problems:

usr/bin/gpgsplit gnupg-1.4.23-x86_64-4 gnupg2-2.2.27-x86_64-3
usr/bin/gtk-update-icon-cache gtk+2-2.24.33-x86_64-2 gtk+3-3.24.28-x86_64-1
usr/info/libffi.info.gz gcc-10.3.0-x86_64-1 libffi-3.3-x86_64-3
usr/man/man1/chfn.1.gz shadow-4.8.1-x86_64-12 util-linux-2.36.2-x86_64-2
usr/man/man1/chsh.1.gz shadow-4.8.1-x86_64-12 util-linux-2.36.2-x86_64-2
usr/man/man1/login.1.gz shadow-4.8.1-x86_64-12 util-linux-2.36.2-x86_64-2
usr/man/man1/lrz.1.gz lrzip-0.641-x86_64-1 minicom-2.8-x86_64-3
usr/man/man1/mmencode.1.gz elm-2.5.8-x86_64-7 metamail-2.7-x86_64-9
usr/man/man3/Thread.3.gz perl-5.32.1-x86_64-2 tcl-8.6.11-x86_64-3
usr/man/man5/mbox.5.gz mutt-2.0.6-x86_64-1 tin-2.4.5-x86_64-2
usr/man/man5/mmdf.5.gz mutt-2.0.6-x86_64-1 tin-2.4.5-x86_64-2
usr/man/man6/maze.6.gz xgames-0.3-x86_64-8 xscreensaver-6.00-x86_64-1

The two usr/bin/gpgsplit do the same thing but depend on different libraries, maybe it is a good idea to rename the binaries and make a sacrificial symlink.

The two usr/bin/gtk-update-icon-cache look the same and I suspect that we can interchange them. But, hey, I already patched gpg and I can patch gtk in the exact same way.

Info and man pages are not that critical.
Some are easy to fix because one of the two packages is missing the command so the man page can be safely removed, some are harder (Threads, maze) and need a bit of thought.

Ser Olmy

04-13-2021 06:57 AM

Quote:

Originally Posted by arcctgx (Post 6240355)

See attached file for a comparison between the letters of Cyryllic script in Terminus and in Monospace fonts (differences are underlined). I'm not using Cyryllic on a daily basis (and only know basic Russian), but this seems strange to me, I've never seen glyphs like the Terminus defaults before. See Wikipedia entry on Russian alphabet for comparison: https://en.wikipedia.org/wiki/Cyrill...habets#Russian.

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.

niksoggia

04-13-2021 08:17 AM

duplicate info/man pages

3 Attachment(s)

(This is a continuation of my post )

Quote:

usr/info/libffi.info.gz gcc-10.3.0-x86_64-1 libffi-3.3-x86_64-3

It should be more appropriate to keep the .info from libffi, but the one from libffi is older (6.6) than the one from gcc (6.7).
Being a niche manpage I doubt it will be read so often, and we can afford to leave the things as they are now.

Quote:

usr/man/man1/chfn.1.gz shadow-4.8.1-x86_64-12 util-linux-2.36.2-x86_64-2
usr/man/man1/chsh.1.gz shadow-4.8.1-x86_64-12 util-linux-2.36.2-x86_64-2
usr/man/man1/login.1.gz shadow-4.8.1-x86_64-12 util-linux-2.36.2-x86_64-2

I fixed a bug in shadow.SlackBuild that prevented the manpages to be deleted.

Quote:

usr/man/man1/mmencode.1.gz elm-2.5.8-x86_64-7 metamail-2.7-x86_64-9

This is easy, metamail does not have the binary.

Quote:

usr/man/man3/Thread.3.gz perl-5.32.1-x86_64-2 tcl-8.6.11-x86_64-3

I prefer to sacrifice Perl because the manpage refers to an old (5.0-) API.

Quote:

usr/man/man5/mbox.5.gz mutt-2.0.6-x86_64-1 tin-2.4.5-x86_64-2
usr/man/man5/mmdfq.5.gz mutt-2.0.6-x86_64-1 tin-2.4.5-x86_64-2

These manpages describe mailbox formats, I think nobody (apart me) will ever read them.
Nobody will die if we leave the things as they are now.

Quote:

usr/man/man6/maze.6.gz xgames-0.3-x86_64-8 xscreensaver-6.00-x86_64-1

These programs do the same thing: one in a window, the other as a screensaver. Oh boy, this is hard, we should make a disambiguation manpage.
Naaah!

LuckyCyborg

04-13-2021 08:46 AM

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:

Code:

--- qt5.SlackBuild.orig        2021-03-27 21:20:06.135958397 +0200

+++ qt5.SlackBuild        2021-04-13 01:09:17.279033081 +0300

@@ -196,10 +196,12 @@

  -opengl \

  -openssl-linked \

  -optimized-qmake \

-  -qpa xcb \

+  -qpa "xcb;wayland" \

  -qt-harfbuzz \

  -verbose \

  -xcb \

+  -egl \

+  -eglfs \

  -nomake examples \

  -nomake tests \

  -no-mimetype-database \

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.

Code:

--- plasma-workspace.post-install.orig        2020-10-30 03:30:21.927833013 +0200

+++ plasma-workspace.post-install        2021-04-13 14:17:55.664952637 +0300

@@ -49,3 +49,9 @@

  sed -i $PKG/usr/share/xsessions/plasma.desktop \

      -e "s,^Exec=/,Exec=dbus-run-session /,"

 fi

+

+# Install custom "full wayland" session

+pushd $PKG/usr/share/wayland-sessions/

+sed '/^Name/d;s/^Exec=/Exec=env GDK_BACKEND=wayland QT_QPA_PLATFORM=wayland /' plasmawayland.desktop > plasmafullwayland.desktop

+echo 'Name=Plasma (Full Wayland)' >> plasmafullwayland.desktop

+popd

Well, so called "Full Wayland" session is just a session where is forced the Wayland backend, resulting the following execution line.

Code:

Exec=env GDK_BACKEND=wayland QT_QPA_PLATFORM=wayland /usr/lib64/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

compared with the "standard" session which is run with

Code:

Exec=/usr/lib64/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

From my experiences, what we do today on Slackware with the Wayland/Plasma5 sessions is equivalent with:

Code:

Exec=env QT_QPA_PLATFORM=wayland /usr/lib64/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

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.

drgibbon

04-13-2021 08:46 AM

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?

cwizardone

04-13-2021 11:14 AM

xorg-server-1.20.11
Security release.

Quote:

X.Org server security advisory: April 13, 2021

Input validation failures in X server XInput extension
======================================================

Insufficient checks on the lengths of the XInput extension
ChangeFeedbackControl request can lead to out of bounds memory
accesses in the X server.

These issues can lead to privilege escalation for authorized clients
on systems where the X server is running privileged.

* CVE-2021-3472 / ZDI CAN 12549 XChangeFeedbackControl Integer Underflow.....

The full post and patch can be found here, https://lists.freedesktop.org/archiv...il/060677.html

nobodino

04-13-2021 11:19 AM

upgrade the kernel without rebooting.

LuckyCyborg

04-13-2021 11:24 AM

Quote:

Originally Posted by cwizardone (Post 6240614)

xorg-server-1.20.11
Security release.

The full post and patch can be found here, https://lists.freedesktop.org/archiv...il/060677.html

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:

https://lists.freedesktop.org/archiv...il/060679.html

https://xorg.freedesktop.org/archive...-21.1.1.tar.xz
https://xorg.freedesktop.org/archive...1.1.tar.xz.sig

Already built it, and it runs exceptionally fine with Wayland/Plasma5 of -current.

arcctgx

04-13-2021 11:26 AM

Quote:

Originally Posted by Ser Olmy (Post 6240552)

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.

Didier Spaier

04-13-2021 11:34 AM

Quote:

Originally Posted by drgibbon (Post 6240582)

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.

gmgf	04-13-2021 12:35 PM

Quote:

Originally Posted by LuckyCyborg (Post 6240619)

Same here ;)

elyk	04-13-2021 11:18 PM

Quote:

Originally Posted by franzen (Post 6240468)

This will add way to much fonts with strange font effects in various apps.
See https://www.linuxquestions.org/quest...ts-4175693179/ for building lilypond with the Tex Gyre fonts.

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.

franzen

04-14-2021 01:49 AM

Quote:

Originally Posted by elyk (Post 6240826)

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.

bormant

04-14-2021 03:26 AM

Quote:

Originally Posted by arcctgx (Post 6240620)

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.

Ser Olmy

04-14-2021 04:45 AM

Quote:

Originally Posted by bormant (Post 6240863)

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?

drgibbon

04-14-2021 05:12 AM

Quote:

Originally Posted by Ressy (Post 6212124)

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").

bormant

04-14-2021 06:48 AM

Quote:

Originally Posted by Ser Olmy (Post 6240881)

But could you confirm whether or not these glyphs generally belong in italic and cursive scripts?

Yes for "i" and "j"; "de" usually uses glyph with up-to-left curve for italic and with lower loop for handwritten.

Quote:

Originally Posted by Ser Olmy (Post 6240881)

And if so, do they not look slightly out of place when they appear among upright characters?

Don't think so. In any case rebuilding this font package with or without cosmetic patches is not rocket science.

ZhaoLin1457

04-14-2021 03:10 PM

Quote:

Originally Posted by ZhaoLin1457 (Post 6232769)

Please consider adding this small daemon supervisor developed by @raforg for a proper handing of the PipeWire daemons.

https://github.com/raforg/daemon

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.

https://github.com/raforg/daemon/releases/tag/v0.8

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:

https://www.linuxquestions.org/quest...ed-4175691414/

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

/etc/xdg/autostart/pipewire-media-session.desktop-sample

Code:

[Desktop Entry]

Version=1.0

Name=PipeWire Media Session

Comment=Start the PipeWire Media Session

Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session

Terminal=false

Type=Application

X-GNOME-Autostart-Phase=Initialization

X-KDE-autostart-phase=1

/etc/xdg/autostart/pipewire-pulse.desktop-sample

Code:

Desktop Entry]

Version=1.0

Name=PipeWire Pulse

Comment=Start the PipeWire Pulse

Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse

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.

ZhaoLin1457

04-14-2021 03:27 PM

Quote:

Originally Posted by LuckyCyborg (Post 6240581)

Code:

--- qt5.SlackBuild.orig        2021-03-27 21:20:06.135958397 +0200

+++ qt5.SlackBuild        2021-04-13 01:09:17.279033081 +0300

@@ -196,10 +196,12 @@

  -opengl \

  -openssl-linked \

  -optimized-qmake \

-  -qpa xcb \

+  -qpa "xcb;wayland" \

  -qt-harfbuzz \

  -verbose \

  -xcb \

+  -egl \

+  -eglfs \

  -nomake examples \

  -nomake tests \

  -no-mimetype-database \

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.

Code:

--- plasma-workspace.post-install.orig        2020-10-30 03:30:21.927833013 +0200

+++ plasma-workspace.post-install        2021-04-13 14:17:55.664952637 +0300

@@ -49,3 +49,9 @@

  sed -i $PKG/usr/share/xsessions/plasma.desktop \

      -e "s,^Exec=/,Exec=dbus-run-session /,"

 fi

+

+# Install custom "full wayland" session

+pushd $PKG/usr/share/wayland-sessions/

+sed '/^Name/d;s/^Exec=/Exec=env GDK_BACKEND=wayland QT_QPA_PLATFORM=wayland /' plasmawayland.desktop > plasmafullwayland.desktop

+echo 'Name=Plasma (Full Wayland)' >> plasmafullwayland.desktop

+popd

Well, so called "Full Wayland" session is just a session where is forced the Wayland backend, resulting the following execution line.

Code:

Exec=env GDK_BACKEND=wayland QT_QPA_PLATFORM=wayland /usr/lib64/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

compared with the "standard" session which is run with

Code:

Exec=/usr/lib64/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

From my experiences, what we do today on Slackware with the Wayland/Plasma5 sessions is equivalent with:

Code:

Exec=env QT_QPA_PLATFORM=wayland /usr/lib64/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

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:

https://www.linuxquestions.org/quest...ml#post6241079

Lockywolf

04-14-2021 10:24 PM

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.

Please, consider doing this.

imitheos

04-15-2021 06:39 AM

Quote:

Originally Posted by LuckyCyborg (Post 6240581)

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.

You've probably already read this but there was a discussion
Please remove the xwayland ("Wayland") and wayland ("Full Wayland") sessions as we know them
about this openSUSE approach. I didn't follow it since i don't use wayland but i think it caused problems for many programs.

LuckyCyborg

04-15-2021 07:17 AM

Quote:

Originally Posted by imitheos (Post 6241330)

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.

imitheos

04-15-2021 07:21 AM

Quote:

Originally Posted by LuckyCyborg (Post 6241340)

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.

ZhaoLin1457

04-15-2021 10:32 AM

Quote:

Originally Posted by imitheos (Post 6241342)

Well, there a valid critic of the "mixed" mode (this is how they call it) as used by openSUSE even today and proposed by @LuckyCyborg to be added to Slackware...

Undoubtedly, the Qt5 applications which choose the XCB backend for running, will run significantly slower than the ones running on the native Wayland backend, and same applies for the GTK applications.

This could be tested empirically even on the current Wayland/Plasma5 setup, by adding on ~/.profile the following lines:

Code:

export GDK_BACKEND="x11"

export QT_QPA_PLATFORM="xcb"

Adding this, anyone could observe that the Wayland/Plasma5 sessions would become considerably more stable but also considerably more slower.

That happens because the XWayland server has no real acceleration support until the stand-alone versions released not long ago. From what I read, previously to the stand-alone versions (and there is included even the latest emergency release) the XWayland used for its GLAMOUR support nothing less than the SOFTPIPE. A driver which emulates OpenGL on software.

However, the standalone XWayland server have a real 3D acceleration for its GLAMOUR, resulting on a much better behavior of both Qt5 applications which uses XCB (automatically or not) or X11 as GDK backend.

That's WHY I believe that is not enough to recompile the Qt5 and to patch the plasma-workspace, but also we should move to the stand-alone XWayland server, just like also @LuckyCyborg said.

There I want to make a note: from what I understand, the stand-alone XWayland server is not an independent software like was XFree86 vs. Xorg. In fact, the XWayland is the server which gets today most of development and the stand-alone releases was needed because of release pace of Xorg.

Someday, maybe they will release a new 1.21 Xorg, and all the changes introduced on the stand-alone XWayland server would be also present on the included one. But, even now there are no plans for this future release.

PS. I use on bare metal a self-built stand-alone XWayland server since it was first released, and it works considerably better than the stock version from Slackware.

BenCollver

04-15-2021 01:47 PM

1 Attachment(s)

Attached is a patch for xorg-cf-files to fix an incompatibility introduced by binutils 2.36 [1].

[1]
https://www.mail-archive.com/debian-...sg1789948.html

TommyC7

04-15-2021 04:53 PM

I sent an e-mail about this to Mr. Volkerding already but I don't want to spam and since I didn't see it changed in the last update I'm just posting here hoping it gets noticed.

/etc/rc.d/rc.M and /etc/rc.d/rc.K both load rc.keymap (if it's executable).

I think once (in one of them) should suffice unless there's something I'm missing/don't know about.

drumz

04-15-2021 05:46 PM

Quote:

Originally Posted by TommyC7 (Post 6241558)

Only one of rc.K and rc.M gets executed: rc.K for single user (runlevel 1) or rc.M for multi user. See /etc/inittab.

So there is no bug.

USUARIONUEVO

04-15-2021 05:54 PM

llvm-12.0 is out

https://github.com/llvm/llvm-project/releases

Please sync the libclc package.

Didier Spaier

04-15-2021 06:16 PM

About linuxdoc-tools

Caveat: boring rant ahead.

Trying (unsuccessfully so far, but that's not the point) to build daps on Slint made me realize that the linuxdoc-package in Slackware-current (that I have rebuilt in Slint) needs an update. I also suggest to un-bundle it and ship the software it gathers as standalone packages. Updates suggested:

Asciidoc's development (now based on Python3) continues here. Other distributions have migrated or are migrating to this "branch". It is important to install asciidocapi.py under /usr/lib$LIBDIRSUFFIX/python<pythonversion>/, as the main remaining usage of asciidoc is to build software using its Python API, of course not provided by Asciidoctor which is written in Ruby. As an example presumably most dependencies listed under "required by" in this page rely on it.
docbook-xml-5.0 and docbook-xml-5.1 would be welcomed additions as more and more software rely on at least 5.0. Building using LFS receipts work as they do for 4.5.
It would be better to install separately docbook-xsl and docbook-xsl-nons as does Arch to help build dependent software.

Why Un-bundle linuxdoc-tools? I assume that using slacktrack makes easier to do post-install tasks as there is no need for doinst then. However, these tasks can also be done by a doinst script. Then, ship the components separately would allow users to more easily update them. Still the build order would not be too hard to maintain. Last, as awesome as be slacktrack, it of course modifies the installed system (even if a great care is taken to undo the modifications after usage). For testing I used a snapshot of clean installation in a Qemu VM, but I assume that not all end users are ready to do that.

Thanks for reading :)

Lockywolf

04-15-2021 11:50 PM

libgpod and sdparm seem to need a rebuild after the sg_utils update

Nobby6

04-16-2021 05:31 AM

Just a FYI,

Since this may get lost in the diatribe with all the clowns and chest beaters in "another thread", I'll post it here too.

I can confirm 32bit mariadb is working again as of the next release, which will likely be within a couple weeks tops.

5.10.29-smp #1 SMP Sat Apr 10 13:55:37 CDT 2021 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux

MariaDB [mysql]> SELECT VERSION();
+-----------------+
| VERSION() |
+-----------------+
| 10.5.10-MariaDB |
+-----------------+
1 row in set (0.000 sec)

MariaDB [mysql]>

saxa	04-16-2021 05:41 AM

Quote:

Originally Posted by Didier Spaier (Post 6241598)

Asciidoc's development (now based on Python3) continues here. Other distributions have migrated or are migrating to this "branch". It is important to install asciidocapi.py in /usr/lib$LIBDIRSUFFIX/python<pythonversion>, as the main remaining usage of asciidoc is to build software using its Python API, of course not provided by Asciidoctor which is written in Ruby. As an example presumably most dependencies listed under "required by" in this page rely on it.
docbook-xml-5.0 and docbook-xml-5.1 would be welcomed additions as more and more software rely on at least 5.0. Building using LFS receipts work as they do for 4.5.
It would be better to install separately docbook-xsl and docbook-xsl-nons as does Arch to help build dependent software.

I second that.

mralk3

04-16-2021 10:30 AM

Quote:

Originally Posted by mralk3 (Post 6235027)

I see the following error message in my /var/log/messages when trying to force enable a vpn connection on eth0 through nm-applet:

Code:

Mar 28 10:07:28 mothership kernel: nm-connection-e[1776]: segfault at f048cc20 ip 00007f58659c2327 sp 00007ffe2f732e58 error 4 in libc-2.33.so[7f5865875000+15e000]

Mar 28 10:07:28 mothership kernel: Code: f9 20 77 1f c5 fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1 1f 48 83 e7 e0 eb 36 66 90 83 e1 1f 48 83 e7 e0 <c5> fd 74 0f c5 fd d7 c1 d3 f8 85 c0 74 1b f3 0f bc c0 48 01 f8 48

Reproduce it in nm-applet by: Edit connections -> edit "Wired connection 1" -> General Tab -> Mark "Automatically connect to VPN"

See attached screen shot. This is on a fresh installation of current x86_64 from today. It could be due to the fact that I have straggling configuration files, but I did do a rm -rf ~/.config and ~/.cache in my home directory in a chroot, during the installation.

The window just disappears, then the log reports the segfault.

EDIT: A .ovpn was used to install/configure the connection. I prefer to not attach that file as it includes my tls key and ca key.

I am still seeing this same behavior. I am able to import the .ovpn file using nmcli and nm-applet. I know the file works because I can connect to my vpn successfully. Within the file I have included the all certificates, as most .ovpn files do. I am using all standard openvpn client settings, and inheriting most settings from the vpn server, which should be unrelated at that point. I have added the following:

Code:

cipher AES-256-GCM

auth SHA512

Code:

<ca>

-----BEGIN CERTIFICATE-----

..removed for obvious reasons..

-----END CERTIFICATE-----

</ca>

I've done the same with the <cert> block <key> block, and <tls-crypt> block. I am using tls-crypt. I am using ECC to generate symetric keys, for the extra speed, and including all required files within the .ovpn. Is there some inconsistency by including everything within the files or in my client configuration?

tldr; I do not know if my configuration file is simply too long or something else. I am unable to activate my vpn connection automatically from within the nm-applet configuration dialogs. I can do so with nmcli by editing my configuration at the command line. I am running a few day old installation of Slackware beta 1 with updates in the ChangeLog. I see the exact same segfault in dmesg.

SCerovec

04-16-2021 03:53 PM

Quote:

Originally Posted by arcctgx (Post 6240355)

Code:

cat alt/dv1.diff | patch -p0 --verbose || exit 1

cat alt/ij1.diff | patch -p0 --verbose || exit 1

Code:

cat alt/td1.diff | patch -p0 --verbose || exit 1

Arguably, the tilde patch is purely aesthetic, but the Cyryllic patches are more important IMHO.

Quote:

Originally Posted by arcctgx (Post 6240620)

Quote:

Originally Posted by bormant (Post 6240928)

Yes for "i" and "j"; "de" usually uses glyph with up-to-left curve for italic and with lower loop for handwritten.

Don't think so. In any case rebuilding this font package with or without cosmetic patches is not rocket science.

I am not a Russian native speaker (or writer for that matter) but i am native Cyrillic user and can say only this:

IMHO leave it as is.

The glyphs in question are mere variants of one and the same letter(s) if one, for instance, is writing the "stamped" letters by hand the "и" becomes "и" pretty fast - so most likely all Cyrillic users will not notice the oddity in reading, but only in thorough inspection of the font (as OP, i presume, did).

OTOH, if You are learning Cyrillic alphabet and find that confusing, I'd advise You put your effort in getting used to it - as it is just the way things stand (having non identical normal and cursive glyph for the same phoneme)

Just my 2c (take with a grain of salt).

majekw

04-16-2021 04:40 PM

It could be good to bump LXC to some recent version from 2.0.11 as according to LXC site:

Quote:

LXC 2.0 will be supported until June 1st 2021

and latest stable version is 4.0.6.

TommyC7

04-16-2021 04:50 PM

Quote:

Originally Posted by drumz (Post 6241586)

Only one of rc.K and rc.M gets executed: rc.K for single user (runlevel 1) or rc.M for multi user. See /etc/inittab.

So there is no bug.

Ah ok, good to know.

majekw

04-16-2021 05:01 PM

Quote:

Originally Posted by wowbaggerHU (Post 6209448)

Could you please add thin-provisioning-tools to -current?
It is necessary for activating cache LVs on reboot, and without it, the LV can't be mounted.

+1 for this.
thin-provisioning tools are already in Slackbuilds https://slackbuilds.org/repository/1...sioning-tools/, so integrrating should be easier.
Keep in mind that there is also patch for mkinitrd for boot support from thin or cached volume.

drumz

04-16-2021 05:26 PM

Quote:

Originally Posted by wowbaggerHU (Post 6209448)

Could you please add thin-provisioning-tools to -current?
It is necessary for activating cache LVs on reboot, and without it, the LV can't be mounted.

Quote:

Originally Posted by majekw (Post 6241915)

Is this still true? I created a logical volume with a cache (though not my boot drive) and rebooted and it works just fine. Maybe I'm using a different type of cache?

Here is how I created it:

Code:

#!/bin/sh



set -e



dd if=/dev/urandom of=/root/luks_keys/lv_slow.luks bs=1K count=4



mdadm --create --verbose /dev/md0 --level=stripe --raid-devices=8 \

        --name=slow_data --chunk=512K \

        /dev/sd[abcdefgh]1



pvcreate -M2 --dataalignment 512K /dev/md0



vgcreate -s 512K vg_storage /dev/md0



lvcreate -l 97%FREE -n lv_slow vg_storage /dev/md0



pvcreate -M2 --dataalignment 512K /dev/nvme1n1p2

vgextend vg_storage /dev/nvme1n1p2

lvcreate -n lv_fast -L 31G vg_storage /dev/nvme1n1p2

lvcreate -n lv_fastmeta -L 31M vg_storage /dev/nvme1n1p2

lvconvert --type cache-pool --cachemode writeback --poolmetadata vg_storage/lv_fastmeta vg_storage/lv_fast

lvconvert --type cache --cachepool vg_storage/lv_fast vg_storage/lv_slow



cryptsetup -y luksFormat /dev/vg_storage/lv_slow /root/luks_keys/lv_slow.luks

cryptsetup --key-file /root/luks_keys/lv_slow.luks luksOpen /dev/vg_storage/lv_slow lv_slow_luks



mkfs.ext4 -b 4096 -m1 -E stride=128,stripe_width=1024 /dev/mapper/lv_slow_luks

After rebooting it looks like everything is working fine:

Code:

# lvdisplay 

  --- Logical volume ---

  LV Path                /dev/vg_storage/lv_slow

  LV Name                lv_slow

  VG Name                vg_storage

  LV UUID                xOInJ0-R3Zi-x2Mf-Vf1y-zJ4M-WKq7-9XvVYo

  LV Write Access        read/write

  LV Creation host, time Thelio-PC, 2021-04-16 11:32:27 -0700

  LV Cache pool name    lv_fast_cpool

  LV Cache origin name  lv_slow_corig

  LV Status              available

  # open                1

  LV Size                35.29 TiB

  Cache used blocks      100.00%

  Cache metadata blocks  19.30%

  Cache dirty blocks    99.99%

  Cache read hits/misses 9981 / 748

  Cache wrt hits/misses  680100 / 7231293

  Cache demotions        6807

  Cache promotions      495919

  Current LE            74017625

  Segments              1

  Allocation            inherit

  Read ahead sectors    auto

  - currently set to    16384

  Block device          253:3

I'm stress testing it right now, by the way (I think that's why cache usage is so high).

Edit to add: I do NOT have thin-provisioning-tools installed.

majekw

04-16-2021 06:31 PM

Quote:

Originally Posted by drumz (Post 6241924)

Is this still true?

You could be right :-)
I checked changelog of LVM2 and found:

Quote:

Allow activation of pools when thin/cache_check tool is missing.

So, for activation I think it shouldn't be necessary.
Thank you for testing.

upnort

04-16-2021 06:39 PM

Pat,

If something important gets overlooked here, just keep after me.

Perhaps not "important" but perhaps low level annoying -- dangling symlinks:

cldr-emoji-annotation
bind9
util-linux
gftp
articulate

mumahendras3

04-16-2021 07:44 PM

Quote:

Originally Posted by mumahendras3 (Post 6232865)

I'm sorry for bumping this, below changes are needed for /usr/bin/sddm to let the init process properly supervise SDDM. Also "$*" is changed to "$@" since I think that is more appropriate for propagating the positional parameters in this script.

Thanks for the consideration!

Code:

--- a/usr/bin/sddm      2021-03-22 13:30:32.209653646 +0700

+++ b/usr/bin/sddm      2021-03-22 13:32:55.810714919 +0700

@@ -3,4 +3,4 @@

 if [ -f /etc/default/sddm ]; then

  . /etc/default/sddm

 fi

-/usr/bin/sddm.bin "$*"

+exec /usr/bin/sddm.bin "$@"

Sorry for bumping this up again. Hope it's still worth mentioning.

Thanks!