Slack Community call

If it comes back to systemd again, I'll have to pass on Wayland. But I'll at least take a look at the instructions and try to build it myself. I just used Pat's slackware-current SlackBuilds to rebuild Mesa, libdrm, and X11. My PC shouldn't be in terrible shape for such an experiment--other than for the 3.10.58 kernel, maybe--and hardware GL is known to work well on this PC.

well only the logind part
shouldn't be worse then console-kit
and big DE's will accept patches to make it work without it

then there are smaller ones like weston that shouldn't require it at all (last time i tried it didn't)

We can get logind from the shim project when it stabilizes, but because systemd is in such a state of development and ongoing add-ons that's going to be a big if.

You can build wayland and weston on a non-systemd system though so...

OK, I took the instructions and git clones; took them to an i686 Pentium 4 (Intel i865 video) running last night's slackware-current and kernel 3.18.0-rc1...

That working around things for Slackware has some dealbreakers. Weston indeed can be run without systemd, but weston-launch wants PAM. Perhaps it can be de-PAM-ified by somebody, or maybe the Weston folks might consider a non-PAM version. Otherwise, the easy way to let non-root users use Wayland programs is to set each program setuid root. Not good. I chose to configure Weston with --disable-weston-launch, and I had a regular "weston" program that could be run easily as root.

I've never used SBo, but if those guys haven't gotten into Wayland/Weston, maybe they could brew something up. Each of the supporting programs listed at http://wayland.freedesktop.org/building.html have git repositories, are configured with autoconf, and have Makefiles that respect the DESTDIR directive. Only Weston might need the extra program configuration and extra user configuration, making an XDG_RUNTIME_DIR and setting an environment variable. The instructions were correct, and "make DESTDIR=$PKG_DIR install; cd $PKG_DIR; makepkg ../$PKG-$VERSION-$ARCH-$BUILD.txz" was all very easy.

As for Wayland, Pat might consider adding the single wayland package, then build Mesa with "wayland" as an extra EGL driver. It involves changing exactly one line in slackware-current's mesa.Slackbuild. Mesa takes a long time to build and can be evil during upgrades. If somebody wants to add the other packages, that's fine. My video hardware may be too old to test this; I was hoping that the minimum "i915" meant "all cards supported by i915 drives, including i830 to i865." I did not get the EGL drivers to work and probably didn't get them going for X11 or Cairo in the past. Someone might prove that Wayland support in Mesa would make a difference. It did build OK, though.

But that's me trying to answer the call. Personally, I really liked what I saw, getting it to run in X11 with the pixman drivers, then getting it to run in the console with the fbdev backend. It was a treat to run one weston instance per virtual console and bounce between them like ordinary virtual consoles. The startup speed was gorgeous, as was the speed of switching consoles. Memory usage was good, though I don't know why weston-keyboard needs 7 MB of memory to run. The speed of scrolling text was way faster than KMS, thanks to my KMS consoles not wanting to go lower than 32bpp in kernel 3.18.0-rc1.

There some kernel messages from DRM like "error: unable to reset chip: -19", but I've had my share of glitches with KMS and X11, too. Not scoring it against either Wayland or Weston.

If enough people were smart enough to port their games here, even if they were old svgalib games that run only with luck, it would break me into PAM-ifying at least one of my Slackware boxen.

Thanks for making me look at it!

You only need libdrm, libmesa, and GTK+3.x rebuilt for Wayland support. The rest could be built normally. Cairo and Pango might need rebuilding as might QT4 and QT5 as well.

Originally Posted by mlslk31 3.18.0-rc1...

Why would you use a rc kernel? You are an adrenaline junky?

Ontopic: I completely trust Pat's decision. Even in an unlikely event of him accepting systemd, I would support it.

I would personaly prefer if there was a native BSD init port. The modern one with paralelism and stuff. Not as a default (Slack's BSD-ized sysv init is simpler), but at least as an alternative.

If you want more services launched in parallel you can always move more startups into inittab. The getties are launched this way, or you could use cronjobs. Sysvinit is extremely flexible, all you have to do is abuse it properly. Slackware also has a SlackBuild of Runit to use with sysvinit as a inittab launch service supervisor, so right there's another option.

I think I was clear enough. If you used FreeBSD or NetBSD recently then you should know what kind of init they use. If it was ported to Linux, it would be a nice alternative to the other options mentioned in the thread. Nothing else.

Originally Posted by ReaperX7 You only need libdrm, libmesa, and GTK+3.x rebuilt for Wayland support. The rest could be built normally. Cairo and Pango might need rebuilding as might QT4 and QT5 as well.

Thanks. Maybe I'll play with the slackware-current libdrm tonight. I might get better results by upgrading, but I end up upgrading in a circle and have git versions of everything. Speaking of...

Originally Posted by bobzilla Why would you use a rc kernel? You are an adrenaline junky?

I use one testing PC to run development XFS through its paces in debug mode (CONFIG_XFS_DEBUG=y kernel config option), strictly using and testing, no programming. There are new features coming to XFS, but I don't think they're enabled by default yet in xfsprogs. These features might be stable by now, but my mode is still "get the latest xfsprogs, then use it with the latest kernel." Keeping a git kernel has the side effect of letting me know what got broken badly elsewhere in the kernel and then re-fixed before becoming a "stable" kernel and looking a lot like the kernel that came before it.

Relevant to this discussion, I have to add a debug stack to Slackware: elfutils, pahole, crash, kexec-tools, trace-cmd, and some other stuff. perf gets compiled as well. The Wayland build instructions have libunwind as an optional dependency, and I've been seeing that quite a bit. weston can use it, perf can use it. libcxxrt can use it, too, but I don't know if that libunwind has to be compiled with clang. I wouldn't ask Pat for libunwind just yet, but maybe somebody could keep it on the radar.

Oh ok. It sounded like you were using it on desktop or production machine. My bad.

The only bad thing about Wayland usage is that KDE currently is the only Slackware deployed DE that uses it, while Xfce and the rest still use X. I don't know how well it uses it on KDE though as I never progressed with it in my own usages. I built it on B/LFS, but as far as usages, I never tried it outside the demos.

What I do know is this much:

Wayland itself requires libffi directly, with options for Publican, libxlst, and Doxygen for documentation building.

Weston requires:

cairo
libjpeg-turbo (not in Slackware yet)
libxkbcommon
glu
mtdev
Wayland

directly. It's recommended you also build with:

libinput
Linux-PAM (for weston-launch though it builds anyway or you could build Linux-PAM solely for weston only)
pango (for demos)
systemd or systemd-shim (for logind though it builds without it regardless)
xorg-libs (to build the X11 backend and compat layer)
Xorg-server (built with Xwayland)

Optional extras are provided by

Colord
little cms 2
libva (for h.264 video encoding support)
libwebp
freerdp
libunwind

From my own builds, weston-launch is built anyway without Linux-PAM, though you could assign it to work through effective permissions or use a Linux-PAM built only towards weston usage (this was done with Google Chrome I think as well at one point), and logind doesn't seem to be a hard requirement (not sure why it's even used if you use a DE that has it's own management agent through another session manager like ConsoleKit).

The only big issue to starting work is getting libjpeg-turbo included in Slackware to replace libjpeg. The rest are there, or in SBo.

Originally Posted by bobzilla Oh ok. It sounded like you were using it on desktop or production machine. My bad.

I was seconds from trying Wayland/Weston on the production machine right here next to me at work. I'd even run the full xfsdump to get / backed up. I didn't have the heart to do it, though, so I drove home and built everything.

Just a reminder when you run weston to test it here's something you need to know:

XDG_RUNTIME_DIR must be set in either the environment or the ~/.weston.ini file in your $HOME directory.

I used the following shell script for testing:

#!/bin/sh
if [ -d ~/.weston/XDG_RUNTIME ]; then
    mkdir -pv .weston/XDG_RUNTIME
fi
export XDG_RUNTIME_DIR=~/.weston/XDG_RUNTIME
weston-launch -- --modules=xwayland.so
EOF

The make it executable.

Be advised, that Weston's sampler kit is VERY basic, even more so than TWM, and to exit you'll need to run Ctrl+Alt+Backspace to exit Weston. Don't attempt to reboot or shutdown while in Weston or you'll loose the framebuffer and console and have to manually hard reboot/powerdown the system.

I don't know how it'll work under KDE though. You'll have to rebuild KDE-Workspace to support Wayland. So far I haven't rebuilt it yet.

I did find this article on how to start a full KDE session under Wayland though, so user beware.

http://blog.martin-graesslin.com/blo...on-in-wayland/

Arch has some info on setting up the Weston user interface further to gain more functionality:

https://wiki.archlinux.org/index.php/wayland

I ended up putting LinuxPAM on the test system so I could build weston-launch. Yeah, that's much better. It does go with the instructions: It's one setuid binary that can launch programs with normal permissions. Just add users to a new weston-launch group, and they'll be able to use Weston. Excellent.

After that, I zeroed out the system and restored a backup. Good times, just wished I had found some more native Wayland apps to use with it. I didn't have the prerequisites installed to get mpv up and running...

Thanks again!

I was pondering system testing and the pros and cons of late adoption vs security patches, and remembered this thread. Since you are testing new packages under Slackware, it seems relevant.

To help ensure the reliability of my systems, I wait for some months after a new Slackware has been released, to give early adopters more time to find and report bugs, so that they are fixed by the time I download it.

After downloading the stable Slackware release, I test the system myself on a noncritical "beater" system for a couple of months. If all goes well, I roll it out onto other systems.

This is well and good, but from time to time security fixes are released, and that poses a puzzle. Touching code creates bugs, and security fixes are no exception. The security fix potentially introduces bugs, and neither the Slackware development team nor the Slackware user community has much time to try it out and find those bugs.

What do I do? Do roll the dice and apply the fix? Usually there is no problem, but when the dice come up snake-eyes, it can be very bad.

I can wait a while for any bugs with the fix to be found, reported, and fixed, but then that's weeks or a month that my systems are known-vulnerable.

The problem can be mitigated somewhat by putting off fixes to vulnerabilities which do not seem likely to be exploited on my systems, but I'm still rolling the dice by applying fixes for likely-exploited vulnerabilities (like the recent bash vuln; I disabled users' cgi scripts while mulling my options, and the httpd logs filled with exploit attempts).

There should be a better solution, but the only one I can think of is comprehensive test automation.

If I had a battery of regression- and integration-tests for every Slackware package, I could apply a fix to a test system, let it run the relevant tests, and if everything came up green I'd at least know there was no obvious problem, and could roll it into production with minimal risk.

With such a testing system, it would also be easy to validate new Slackware releases, too. It could even run automatically against -current nightly, and possibly help detect bugs before the next release candidate.

I don't have anything even remotely approaching such a system today. What I do instead is build and run the unit- and end-to-end-tests for the software that runs on my systems. That exercises several system components (perl, python, bash, gcc, apache-httpd, mysql, etc) but isn't anywhere near complete, nor automated, nor consistent, nor something I could share with the wider community.

I've also spent some time with The Linux Testing Project, which seeks to provide a way to test linux distributions in general (but seemingly assumes a .deb or .rpm platform), but haven't been able to get it to build on Slackware 14.1 yet. It's not complete either, but would still exercise several services (like the kernel and ssh).

I just need to take the plunge, and set up a buildbot or jenkins instance and start writing tests, but haven't managed to make it a priority yet :-/

So, questions for y'all: What do you do to test the packages you're getting to work on Slackware? Would anyone be interested in helping with a Slackware testing framework? Is there one already?

Also, does anyone have thoughts on the pros and cons of applying security fixes and their impact on system stability? Most of my employers have taken one extreme position or another -- either update/upgrade/patch everything with everything early and often (of the "move fast and break things" ilk) or avoid changing anything on production systems until there is a demonstrated need (even avoiding security fixes until it's been demonstrated that someone has exploited their systems).

I try to steer a moderately conservative course between these two extremes, but why do I seem to be the only one? Does anyone have thoughts/advice?