+1 for ruby

We asked her. Unfortunately she's booked for the foreseeable future.

2 members found this post helpful.

I edited the original post in the thread to address this. :-)

2 members found this post helpful.

Alan Coopersmith has bumped twm to 1.0.9

http://cgit.freedesktop.org/xorg/app/twm/

(not sure if that counts as xorg stuff, sorry if it does)

It does, but I'll let you slide this time :-)

1 members found this post helpful.

You're a gentleman!

I just love twm, it's been my sole desktop for two years now, so when there's big updates I always worry it's going to get forgotten or dropped :-)

orc is still at 0.4.22. Even in SBo it has reached 0.4.23

1 members found this post helpful.

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

The one thats 28 pages? I don't wanna search for it, so I'll just assume the answer is no then.

No, the original post in *this* thread (the post that I made to start this thread).

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.

1 members found this post helpful.

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.

4 members found this post helpful.

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.

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.

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.

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

Why? I'm sure ZFS is a nice filesystem, but it's not something that I see Slackware users begging to have.

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.