Requests for -current (14.2-->15.0)

ZhaoLin1457 · 04-15-2021, 10:32 AM

Quote:

Originally Posted by imitheos

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.

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

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

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.

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

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

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

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

I second that.

mralk3 · 04-16-2021, 10:30 AM

Quote:

Originally Posted by mralk3

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

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.

Quote:

Originally Posted by arcctgx

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.

Quote:

Originally Posted by bormant

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

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

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

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

+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.

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.