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: slack 7.1 till latest and -current, LFS
Posts: 368
Rep:
rworkman, a rationale would be to include the wayland package, rebuild mesa with EGL_PLATFORMS="wayland,x11,drm"
having the xorg-Xwayland.so module that comes from xorg-server would be a good addition to it.
If anyone wants to play with wayland, you need to rebuild mesa with wayland, rebuild your xorg video driver, rebuild xorg-server with wayland support.
Weston is not a must, it is a client, and I expect every DE team will make their own (Gnome has their own and weston is not required).
I have to add another +1 for Ruby. I'd like to see a move to 2.2.x; not only is 1.9.3 out of support but more and more gems are requiring the newer versions. There isn't much in Slackware that uses Ruby as dependency. I have upgraded the system Ruby with no problems and I know others have as well. Given there should be little concern about breakage, I don't see any good reasons the system Ruby should not be a release that will contemporary projects.
With it no longer being developed, I don't think it's a good candidate for inclusion in Slackware, especially since I'm not aware of anything in the core actually requiring it. For things like conky it should be enough to have it on SBo, eventually.
Yeah, it is more likely that the change for now should be on conky to have a toggle for audacious support. Anyway, just noted it here in case someone else finds their conky setup no longer working post upgrade.
ruby's been pawned off on vbatts, as that was his baby originally.
I'm going to pawn off the sip and related to alienBOB, as he handles the KDE-related stuff.
I have no idea re baloo/nepomuk, so again, I'll defer that to alienBOB.
Re the wayland stuff, I don't see it as enough of a real problem at all right now. If some external thing is enough of a must-have and it requires the wayland bits, then it shouldn't be too big of a problem to do standalone mesa-wayland and xorg-wayland (or similar-named) packages by rebuilding the entire packages with the needed changes and then only packaging the necessary bits.
Re python3, I too would like to have it, but only to simplify some issues with stuff at SBo that can use either 2 or 3 or even both - however, Dugan's argument is completely sensible, and if I look at it without my SBo bias, I think I'm in favor of his position, at least for now.
orc and mcelog-115 are queued up now.
I'm about to look at gnuplot and then hopefully Tcl/Tk.
Last edited by rworkman; 04-22-2015 at 10:30 PM.
Reason: orc
PAM - Unless we're going to use Weston for testing Wayland, then no. Otherwise, it can be optional. I have no qualm against it being pulled officially into /extra along with any rebuilt packages specifically for it, but internally in the core, no. Not yet. Unless we abso-freakin-lutely can't run the core without it. It would be nice to test Weston, but there is still a conflict with nvidia-driver and the lack of KMS with it and nvidia-kernel. Weston ends up deadlocking the system with nvidia-driver and nvidia-kernel.
ConsoleKit2 - Personally Robby, my test package in Slackworks has gone well, so if you guys want it, grab it. We should look into it since ConsoleKit2 does support newer protocols for session management such as some of the logind routines, but to use logind we would need a toolkit like LoginKit to use ConsoleKit2 as a backend for logind emulation. The current used ConsoleKit package is fine, but if we want to look into newer things, we should look into updating.
Otherwise, we still need to look into procps-ng possibly as well as adding support for using pkill in rc.6 if someone is using JFS for /(root) to forcekill anything not shutdown by killall5 from the write back phase of JFS. It's not a major issue, but we should research it.
Another thing is maybe looking into the ZFS issues regarding if Slackware could gain permission to distribute a ZFS enabled kernel and install disk since Debian allegedly gain permission to distribute a binary package. It would be nice to have an option eventually for a zfs-root, but it's non-essential. In my opinion, research first and fully, but no full commit. If we can, try, but if not, no problem.
Also, I would like to add that we probably could help out with the research on Jude C. Nelson's vdev alternative to udev/eudev. I have a half-built package ready to push onto Slackworks for testing, but otherwise eudev might be the right path, if it is needed.
PAM - Unless we're going to use Weston for testing Wayland, then no. Otherwise, it can be optional. I have no qualm against it being pulled officially into /extra along with any rebuilt packages specifically for it, but internally in the core, no. Not yet. Unless we abso-freakin-lutely can't run the core without it. It would be nice to test Weston, but there is still a conflict with nvidia-driver and the lack of KMS with it and nvidia-kernel. Weston ends up deadlocking the system with nvidia-driver and nvidia-kernel.
What part of "we're not discussing PAM" is difficult? EVERYBODY knows the pros and cons, and Wayland/Weston isn't really under consideration right now because nobody has any fy(|<$ to give about anything needing them right now. If/when that changes, then we'll reassess, but for now, let's not waste time on them.
Quote:
ConsoleKit2 - Personally Robby, my test package in Slackworks has gone well, so if you guys want it, grab it. We should look into it since ConsoleKit2 does support newer protocols for session management such as some of the logind routines, but to use logind we would need a toolkit like LoginKit to use ConsoleKit2 as a backend for logind emulation. The current used ConsoleKit package is fine, but if we want to look into newer things, we should look into updating.
I've got some commits in upstream CK2 repo, so it's a short leap to conclude that I have actually tried it out (in fact, I'm using it now). I'd like to wait and see what happens wrt its naming and maintenance before we move - no sense in moving from one dead project to another, especially since we don't actually *need* anything provided by CK2 right now. If/when that changes, we'll reassess.
Quote:
Otherwise, we still need to look into procps-ng possibly as well as adding support for using pkill in rc.6 if someone is using JFS for /(root) to forcekill anything not shutdown by killall5 from the write back phase of JFS. It's not a major issue, but we should research it.
If I understand what you're saying correctly, shutdown presently could result in incomplete writes, which sounds like a very major issue to me. I've got procps-ng on my list of things to look at, and Larry Hajali (iirc) sent a script for it, so it's definitely under consideration from me (though not filtered through Pat at all yet).
Quote:
Another thing is maybe looking into the ZFS issues regarding if Slackware could gain permission to distribute a ZFS enabled kernel and install disk since Debian allegedly gain permission to distribute a binary package. It would be nice to have an option eventually for a zfs-root, but it's non-essential. In my opinion, research first and fully, but no full commit. If we can, try, but if not, no problem.
Why? I'm sure ZFS is a nice filesystem, but it's not something that I see Slackware users begging to have.
Quote:
Also, I would like to add that we probably could help out with the research on Jude C. Nelson's vdev alternative to udev/eudev. I have a half-built package ready to push onto Slackworks for testing, but otherwise eudev might be the right path, if it is needed.
systemd's udev seems fine here, and it's what everything expects to be there, and for now at least, it's relatively trivial to build and package it, so I don't see a compelling reason to even consider switching.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.