Requests for -current (14.2-->15.0)

Roman Dyaba · 03-04-2021, 07:47 AM

Sorry friends, i now was skipping KDE upgrades, be cause it have unpredictable changes in last month.

I was remove this pkg's and put him in /etc/slackpkg/blacklist

Code:

hplip
y/
kde/
plasma/

I use XDM, XFCE and LibreOffice now.

USUARIONUEVO · 03-04-2021, 04:03 PM

hi , xdg-utils have some knowed problems with plasma after 5.19 , some fixes are availables but not as release, only if grab a git snapshop.

Please make xdg-utils upgrade from a fresh snapshot , as an example see this commit.

https://gitlab.freedesktop.org/xdg/x...11d440013bdc72

Roman Dyaba · 03-04-2021, 09:33 PM

Announcements
Thursday, 04 March 2021
20.12.3 Releases
Over 120 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE’s release service.

https://kde.org/

What did you mean friends ?

USUARIONUEVO · 03-05-2021, 10:50 PM

Can add this patch to qt5 for webengine text rendering with glibc-2.33 ???

http://www.linuxfromscratch.org/patc...ibc233-1.patch

PLEASE READ THIS
https://bugzilla.redhat.com/show_bug.cgi?id=1904652

andygoth · 03-06-2021, 12:06 AM

Pardon me for asking again, but it's been a few weeks and I still need vmd.ko.xz added to the installer initrd. This is necessary for being able to install to an Asus VivoBook 15.6. For now I am making a custom installer to get around this:

Code:

kv=$(echo slackware64/slackware64/a/kernel-modules-*.txz |
    sed 's/.*modules-\([0-9.]*\).*/\1/')
mkdir -p initrd-tree/lib/modules/$kv/kernel/drivers/pci/controller
tar -xOf slackware64/slackware64/a/kernel-modules-*.txz \
    lib/modules/$kv/kernel/drivers/pci/controller/vmd.ko | xz -9f -C crc32 > \
    initrd-tree/lib/modules/$kv/kernel/drivers/pci/controller/vmd.ko.xz
zcat slackware64/kernels/huge.s/System.map.gz |
    /sbin/depmod -b initrd-tree -F /dev/stdin $kv
(cd initrd-tree; find -print0 | cpio -o0 -H newc) | lzma > initrd.img

atelszewski · 03-06-2021, 02:04 AM

Hi,

This is what Ubuntu 20.10 has in /etc/hosts for IPv6:

Code:

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Though I don't know how important it is.

--
Best regards,
Andrzej Telszewski

atelszewski · 03-06-2021, 02:19 AM

Hi,

How about changing example.net to home.arpa?

Excerpt from RFC 8375:

Code:

   Users and devices within a home network (hereafter referred to as
   "homenet") require devices and services to be identified by names
   that are unique within the boundaries of the homenet [RFC7368].  The
   naming mechanism needs to function without configuration from the
   user.  While it may be possible for a name to be delegated by an ISP,
   homenets must also function in the absence of such a delegation.
   This document reserves the name 'home.arpa.' to serve as the default
   name for this purpose, with a scope limited to each individual
   homenet.

This will allow unknowing users to always have a correct and meaningful domain.
It's opinionated, but it sounds much better than example.net. :-P

I was also considering local, but when reading more about it, it turned out it might be treated differently by different OS-es.
For those interested, read more on Special-Use Domain Names.

--
Best regdards,
Andrzej Telszewski

Didier Spaier · 03-06-2021, 03:59 AM

[Deleted, no value added]

Alien Bob · 03-06-2021, 05:24 AM

Quote:

Originally Posted by atelszewski

Hi,

How about changing example.net to home.arpa?

Excerpt from RFC 8375:

Code:

   Users and devices within a home network (hereafter referred to as
   "homenet") require devices and services to be identified by names
   that are unique within the boundaries of the homenet [RFC7368].  The
   naming mechanism needs to function without configuration from the
   user.  While it may be possible for a name to be delegated by an ISP,
   homenets must also function in the absence of such a delegation.
   This document reserves the name 'home.arpa.' to serve as the default
   name for this purpose, with a scope limited to each individual
   homenet.

This will allow unknowing users to always have a correct and meaningful domain.
It's opinionated, but it sounds much better than example.net. :-P

I was also considering local, but when reading more about it, it turned out it might be treated differently by different OS-es.
For those interested, read more on Special-Use Domain Names.

--
Best regdards,
Andrzej Telszewski

Interesting! I will use this in liveslak.

teoberi · 03-06-2021, 05:33 AM

Quote:

Originally Posted by atelszewski

Hi,

This is what Ubuntu 20.10 has in /etc/hosts for IPv6:

Code:

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Though I don't know how important it is.

--
Best regards,
Andrzej Telszewski

ip6-localhost -> localhost6

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

0XBF · 03-06-2021, 10:23 AM

Hi Pat and Crew,

Currently in slackware there are a number of methods used for starting the session dbus in the xinitrc and display manager scripts (also wayland scripts). It would be nice to see them updated for consistency, particularly around their use of the variable DBUS_SESSION_BUS_ADDRESS.

What should happen is that if this variable is set (e.g. the user started their own session dbus), then don't launch a dbus instance and use the existing one, else launch a new one. Currently most scripts already do this in one way or another, but there are a few that could use fixing.

I have gone through all the scripts and I will summarize my findings here. Hopefully you see what I mean:

Plasma:
Plasma is packaged with the script "/usr/lib64/plasma-dbus-run-session-if-needed", which checks the DBUS_SESSION_BUS_ADDRESS variable and launchs a dbus if needed. However this script is only used in the starting of wayland from the display manager in /usr/share/wayland-sessions/plasmawayland.desktop:

Code:

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

In the x11 version at /usr/share/xsessions/plasma.desktop we have:

Code:

Exec=dbus-run-session /usr/bin/startplasma-x11

Which launches a dbus unconditionally. This could be changed to use plasma-dbus-run-session-if-needed to allow for checking DBUS_SESSION_BUS_ADDRESS.

In /etc/X11/xinit/xinitrc.kde we currently have this at the end:

Code:

else
  dbus-launch --sh-syntax --exit-with-session startplasma-x11
fi

Which also starts its own dbus unconditionally. Why not reuse plasma-dbus-run-session-if-needed again and allow for that flexibility?

Also in /usr/bin/startkwayland the line is:

Code:

dbus-launch --sh-syntax --exit-with-session /usr/bin/startplasma-wayland

Once again that could be changed to use plasma-dbus-run-session-if-needed. If its already used for the plasmawayland.desktop launch, why not all of plasmas launching scripts?

Xfce:
Both the xfce.desktop and xinitrc.xfce files run /usr/bin/startxfce4 directly, which checks for DBUS_SESSION_BUS_ADDRESS already and starts one only if needed. No changes required.

Fluxbox & Blackbox:
These are launched with /usr/bin/startfluxbox and /usr/bin/startblackbox respectively. Both these scripts check for DBUS_SESSION_BUS_ADDRESS and start a dbus if needed, no change required.

Fvwm2:
The xinitrc.fvwm2 script launches a dbus unconditionally with this:

Code:

dbus-launch --exit-with-session /usr/bin/startfvwm2

However, the /usr/bin/startfvwm2 script checks for DBUS_SESSION_BUS_ADDRESS and starts its own if needed. The "dbus-launch --exit-with-session" can be removed and startfvwm2 will take care of that instead (which seems like that scripts only purpose anyway).

WindowMaker:
This one also launches dbus unconditionally in xinitrc.wmaker with:

Code:

exec dbus-launch --exit-with-session /usr/bin/wmaker $NOCPP

This one needs a dbus and will not launch its own. However, it would be nice if it was consistent with the rest and ran if needed. E.g. modified to this: (or just use plasmas start-if-needed script :-)

Code:

if [ -z "$DESKTOP_SESSION" -a -x /usr/bin/ck-launch-session ]; then
  exec ck-launch-session dbus-launch --exit-with-session /usr/bin/wmaker $NOCPP
elif [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
  exec dbus-launch --exit-with-session /usr/bin/wmaker $NOCPP
else
  exec /usr/bin/wmaker $NOCPP
fi

MWM:
The xinitrc.mwm script already checks for DBUS_SESSION_BUS_ADDRESS and starts one only if needed, no change required.

TWM:
Doesn't do anything with dbus sessions.

So really just plasma, windowmaker, and fvwm2 could be changed, then they all would have consistent behavior in checking DBUS_SESSION_BUS_ADDRESS and starting dbus if needed. That would provide flexability for a user to be able to start their own dbus and have it used into the graphical session, rather than launching more unnecessary ones.

There is one quirk to all this. In the top of /usr/bin/startx there is the line:

Code:

unset DBUS_SESSION_BUS_ADDRESS

I don't understand why thats done upstream. The git commit said it was to allow for running startx in an already running session and not much else. (https://gitlab.freedesktop.org/xorg/...689a2c3da49af9) Im not sure what the benefit of that is though...

Unsetting the dbus variable breaks the intended behavior of checking and only starting a dbus if needed in the following xinitrc scripts after running startx. If the majority of DEs and WMs already check for this properly then why does startx have to break the detection logic?

It would be nice if that was "patched" with a comment in front. I noted that arch linux does this in their own patch here: https://github.com/archlinux/svntogi.../fs46369.patch

Sorry for the long read but this usage of DBUS_SESSION_BUS_ADDRESS is a across a few places. These changes shouldn't affect anything except opening up the ability to use DBUS_SESSION_BUS_ADDRESS for its intended purpose.

USUARIONUEVO · 03-06-2021, 01:57 PM

Hi

Quote:

Sat Mar 6 19:39:46 UTC 2021
l/python-idna-2.10-x86_64-2.txz: Rebuilt.
Since it doesn't seem that there's any progress yet on making requests
compatible with idna-3, let's drop back to this version for now.

Now can fix python2-collection-modules ?

pip2 check

Quote:

requests 2.23.0 has requirement urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1, but you have urllib3 1.26.3.

GazL · 03-06-2021, 04:52 PM

RE: dbus launch

cleaning up the inconsistencies would be good.

One approach I've been playing with is having the xinitrc reinvoke itself through dbus-run-session as follows.

Code:

#!/bin/bash

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] &&  [ -x /usr/bin/dbus-run-session ]; then
  exec /usr/bin/dbus-run-session \
    --dbus-daemon /usr/bin/dbus-daemon \
    -- "$0" "$@"
fi

: ${XDG_CONFIG_DIR:=$HOME/.config}

xsetroot -solid '#00003f'
xrdb -load "$HOME/.Xresources"

/usr/bin/fvwm

Another approach, which I've based on what I've seen in crux, is to implement a xinitrc.d/ directory and have a dbus-launch.sh in there, that uses the old-school tried and tested 'eval' method.
e.g.

xinitrc:

Code:

#!/bin/sh

# merge in defaults and keymaps

sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

userresources="$HOME/.Xresources"
usermodmap="$HOME/.Xmodmap"

[ -f "$sysresources" ]   &&  xrdb -merge "$sysresources"
[ -f "$userresources" ]  &&  xrdb -merge "$userresources"

[ -f "$sysmodmap" ]      &&  xmodmap "$sysmodmap"
[ -f "$usermodmap" ]     &&  xmodmap "$usermodmap"


# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
  for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

# start window-manager

if [ -x /usr/bin/fvwm ]; then
  /usr/bin/fvwm
else
  xterm -geometry +0+0 -name login
fi

xinitrc.d/dbus-launch.sh:

Code:

#!/bin/sh

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] && [ -x /usr/bin/dbus-launch ]
then
	eval $( /usr/bin/dbus-launch --sh-syntax --exit-with-x11 )
	export DBUS_SESSION_BUS_ADDRESS
	export DBUS_SESSION_BUS_PID
fi

Both approaches appear to work, and will essentially no-op themselves if dbus has already been started by a display manager. The latter has the advantage of having one common script-file for the dbus launch code rather than having it duplicated in each individual xinitrc file, which I kind of like.

Just throwing it into the mix to add to what 0XBF has already said above, in case any of it appeals.

camerabambai · 03-06-2021, 05:19 PM

Why the /etc/slackpkg/mirrors on current has a 14.2 mirror as default?

Code:

# USE MIRRORS.SLACKWARE.COM (DO NOT USE FTP - ONLY HTTP FINDS A NEARBY MIRROR)
https://mirrors.slackware.com/slackw...ckware64-14.2/
#

Ressy · 03-06-2021, 07:24 PM

Quote:

Originally Posted by bassmadrigal

If you're so sure it's tied to an X library, have you tried recompiling it and the plugins? If you don't have X installed, it will either error out if something requires one of those dependencies or it will build it without support for that.

This way you could at least know whether or not that is what the problem is and can give Pat a place to start if he wants to figure it out.

So, I found time to throw a spare hard drive in a pc at home, installed -current with no DB's fresh start, mariadb fails still.

removed it and all traces of it, grabbed the source and built it eliminating other missing libraries and wipped out /var/lib/mysql - still fails with same problem, so it is GLibc2.33 at fault, or causing the fault, so I'm finding it rather hard to believe those that claim "it works for them" obviously they have not actually run it and tried to use it, perhaps mistaking the start scripts wrongful reporting of it "starting".