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.
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,645
Rep:
The ffmpeg SlackBuild could be extended by adding a configure option for libaom (a AV1 decoder/encoder, according to Wikipedia a royalty and open and royalty-free video codec designed to be a successor of VP9) similar to the existing configure options. Today I got the first Youtube video with AV1, so I guess others could have the desire to compile it in, too.
Currently when starting in console mode and typing startx from ttyi to launch a graphical session the session start on tty(i+6) and I find this in the output of pstree:
If the desktop session becomes irresponsive, among the things I can do to kill it is press Ctrl-Alt-i then Ctrl-c, which kills startx, xinit and the whole desktop session.
Reading this in the ChangeLog for Slackware64-current:
Code:
Fri Jun 19 19:59:04 UTC 2020
<snip>
x/xinit-1.4.1-x86_64-2.txz: Rebuilt.
When using elogind, start the session on the current console.
Thanks to alienBOB.
leads me to this question: how to kill the session then?
Currently when starting in console mode and typing startx from ttyi to launch a graphical session the session start on tty(i+6) and I find this in the output of pstree:
If the desktop session becomes irresponsive, among the things I can do to kill it is press Ctrl-Alt-i then Ctrl-c, which kills startx, xinit and the whole desktop session.
Reading this in the ChangeLog for Slackware64-current:
Code:
Fri Jun 19 19:59:04 UTC 2020
<snip>
x/xinit-1.4.1-x86_64-2.txz: Rebuilt.
When using elogind, start the session on the current console.
Thanks to alienBOB.
leads me to this question: how to kill the session then?
Switching to second tty with CTRL+ALT+F2 then logging in as root or the same user?
Anyway, the elogind changes are guarded with an IF, then you should not be influenced when you run the "classic" way of ConsoleKit2.
Code:
if [ -x /lib/elogind/elogind -o -x /lib64/elogind/elogind ]; then
# When starting the defaultserver start X on the current tty to avoid
# the startx session being seen as inactive:
# "https://bugzilla.redhat.com/show_bug.cgi?id=806491"
tty=$(tty)
if expr "$tty" : '/dev/tty[0-9][0-9]*$' > /dev/null; then
tty_num=$(echo "$tty" | grep -oE '[0-9]+$')
vtarg="vt$tty_num -keeptty"
fi
fi
This is from /usr/bin/startx
It will not keep the same console when you run the "classic" way of ConsoleKit2 and the X server will jump in tty7 as usual.
BTW, your MATE was patched and built for elogind? IF not, better to not switch from ConsokeKit2.
Last edited by LuckyCyborg; 06-21-2020 at 01:30 PM.
Switching to second tty with CTRL+ALT+F2 then logging in as root or the same user?
Yes that would be one way to do it, thanks. A least this command works if only one graphical session has been started:
Code:
kill $(ps -C xinit -o pid --no-headers)
It just needs some adaptation is several graphical sessions have been started.
Quote:
Anyway, the elogind changes are guarded with an IF, then you should not be influenced when you run the "classic" way of ConsoleKit2.
Indeed, but my question was if using elogind.
Quote:
BTW, your MATE was patched and built for elogind? IF not, better to not switch from ConsokeKit2.
I am currently running Mate-1.24 on Slint64-14.2.1 using ConsoleKit2, but want to determine which changes will be needed in Slint 15, including in the documentation..
Last edited by Didier Spaier; 06-21-2020 at 11:38 PM.
Reason: Typo fix.
I am currently runnig Mate-1.24 on Slint64-14.2.1 using ConsoleKit2, but want to determine which changes will be needed in Slint 15, including in the documentation..
I have absolutely no experience with MATE, but looking to what happened with Plasma5 build made by Mr. Hameleers or XFCE-next build made by Mr. Workman, I guess that for a MATE running on top of a replacement of ConsoleKit2 with elogind, you will need a special Mate build, adapted for elogind - supposing that MATE is somehow compatible with elogind, as it could well support only either ConsoleKit2 or systemd...
However, looks like some desktop builds can survive well to this replacement. Like is KDE4 and XFCE builds from -current, which from my experiments still works fine after replacing the ConsoleKit2 with elegind, using the Mr. Hameleers' elogind and custom dbus and polkit packages - for experiments, I have one box where the ConsoleKit2 is replaced with elogind, but it still has the stock KDE4 and XFCE as shipped by -current.
In fact, over time I managed to own a lot of old cheap boxes, but no one qualify as gaming computer.
Anyway, in my humble opinion, the elogind is NOT a direct replacement of ConsoleKit2, both as API and behavior.
Basically, this elogind is a stand-alone systemd-logind grabbed from the systemd source code, just like is also our eudev.
Then, the software should be adapted for working with elogind, but fortunately, it being much closer to the widely used systemd(-logind), is much easy to make this adaptation.
Last edited by LuckyCyborg; 06-21-2020 at 02:45 PM.
I have absolutely no experience with MATE, but looking to what happened with Plasma5 build made by Mr. Hameleers or XFCE-next build made by Mr. Workman, I guess that for a MATE running on top of a replacement of ConsoleKit2 with elogind, you will need a special Mate build, adapted for elogind - supposing that MATE is somehow compatible with elogind, as it could well support only either ConsoleKit2 or systemd...
I just checked, Mate 1.24 already supports elogind, especially the mate-session component. Indeed it needs to be rebuilt but that's easy: include "--with-elogind" among the configure options, no patch needed.
As an aside I am wondering if just using elogind will allow to use dbus-broker. Else, we would need a launcher for dbus-broker not depending on systemd. Any clue about that?
PS a quick web search comes with "no way. You need to write a new launcher for dbus-broker." Anyone wants to do that?
Last edited by Didier Spaier; 06-21-2020 at 03:24 PM.
I just checked, Mate 1.24 already supports elogind, especially the mate-session component. Indeed it needs to be rebuilt but that's easy: include "--with-elogind" among the configure options, no patch needed.
As an aside I am wondering if just using elogind will allow to replace dbus by dbus-broker. Else, we would need a launcher for dbus-broker not depending on systemd. Any clue about that?
Then, the question is: which parts of systemd uses this BUS1? IF it exclusively uses the login1 and/or udev services, probably it could be adapted and/or patched to work with our eudev and elogind. How I am a simple user, and not a developer, also I am unable to analyze the BUS1 source code, then to respond to this question.
Still, there are the biggest questions: why we should replace the DBUS service with BUS1? What are the arguments for this replacement? And what's wrong with the DBUS?
However, I believe this is basically on itself an another story, and only the Slackware developers could respond if they even intends to replace the DBUS with BUS1 service in the foreseeable future.
Last edited by LuckyCyborg; 06-21-2020 at 03:26 PM.
Setting up encrypted LVM via NCURSES - It can be done.
I still hope that perhaps the installer will be updated to allow encrypted LVM setup. Hell just take a page from Devuan and use their code if thats the case:
I just checked, Mate 1.24 already supports elogind, especially the mate-session component. Indeed it needs to be rebuilt but that's easy: include "--with-elogind" among the configure options, no patch needed.
Thanks Didier
i have placed a separate branch for elogind preparation
So, the replacement of ConsokeKit2 with elogind is a given?
I seen that both Plasma5 and XFCE 4.14 had been switched fully to elogind, with no ConsoleKit2 based alternative (or legacy?) builds, event thought it is still in the slackware-current.
Then, in the near future we will have elogind in slackware-current?
So, the replacement of ConsokeKit2 with elogind is a given?
I seen that both Plasma5 and XFCE 4.14 had been switched fully to elogind, with no ConsoleKit2 based alternative (or legacy?) builds, event thought it is still in the slackware-current.
Then, in the near future we will have elogind in slackware-current?
Robby and I are testing outside of Slackware whether it is feasible to replace ConsoleKit2 with elogind, yes.
Could we please update soma to the latest version? (3.3.5 at the moment)
The bug I fixed in 3.3.1 was a show stopper, since the latest dialog now ignores --timeout in --tailbox, and that stops means soma will get stuck at the dialog, stopping most of its functions.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
