NetworkManager-1.14.6

Tarball, http://ftp.gnome.org/pub/GNOME/sourc...-1.14.6.tar.xz

What does this portend, if anything?

Then you know for sure that Mr. Torvalds will never release a LTS kernel on 5.x series, even on 5.20.x or whatever? Interesting...

I know for sure... because it's Greg K-H who releases stable branches, not linus.

Anyway, it doesn't really matter one way or the other. From the years of watching kernel development I've come to the conclusion that LTS/non-LTS makes no difference. One is as likely to hit a regression as the other due to the development/release-engineering model being used.

4 members found this post helpful.

It depends on when Pat releases 15.0. If development continues and we get an LTS 5.x kernel before 15.0 is released, Pat may switch to it. Or he may stick with 4.19.x kernels. The LTS kernels have been released around 11 months apart with usually 4 releases in between, so it's possible that the next LTS kernel will be 5.3.x and released September 2019. I imagine that if Pat is close to a release, he probably won't switch to a new LTS without giving it enough time to mellow out, so if the kernel timeline is relatively accurate, I'd guess that we'd only see a newer 5.x LTS kernel in 15.0 if 15.0 isn't released until December 2019 or later. I hope it won't take that long for us to get 15.0...

October or November 2019 would be the best date for Slackware 15 with 5.x kernel.
I would have time to decide whether to stay with Slackware-current or return to Slackware-stable.
Now that I'm used to Slackware-current, it's hard to come back without solid arguments.

Yet 13.37 was released with non LTS despite being an undercover *.2 release

Pat clearly still has aces in the sleeve - all options are still on the table IMHO

The aces are actually crawling up and down my sleeve. But it is very likely that 15.0 will release with an LTS kernel - I'd say 99.9% likely.

6 members found this post helpful.

I recommend that N category be split into MX for email and everthing non email related stay in N.

Most people don't need email servers and clients on Slackware being used as a server, so it's kind of pointless having it in the N category. N should be for things like Iptables, TCP/IP and other things that are required for actual networking. That is just my opinion obviously, but I think it makes sense.

Would also be wonderful if Current or ver 15 could simplify or eradicate mouse and keyboard problems in Slackware. For example, EVIOCSKEYCODE: Invalid argument is a common problem on Linux installs (including my own) as it does not seem to recognise the keyboard/mouse attached even though obviously the mouse and keyboard works.

In addition, many people have problems with mouse scroll not working either in putty ssh connection or when logged onto actual computer or in a specific application. To use my setup as an example, mouse scroll does not work at all in vim or terminal when logged directly onto computer and despite many google searches etc, I still can't find the cause of this (as all answers talk about x11 which I don't have installed - I have only installed a, d, l and n and three apps from ap) and even more iritating is when connecting via putty ssh mouse scroll works perfectly in vim in slack 14.2, but upgrading to latest vim in slack current - mouse will scroll up in vim, but bizarrely will not scroll down in vim so I have reverted back to older vim for time being.

As virtually every USB mouse supports scroll, Slackware should be updated so that USB mouse defaults to supporting scroll in all environments and programs I think. I understand that Slackware is about only enabling the functionality you actually want, but having to work out how to enable mouse scroll is on a par with asking me if I want to enable the letters on my keyboard. Mouse scroll is a bare minimum feature.

Just my little 2 cents opinion. Thanks

network-manager-applet 1.8.20 doesn't build anymore libnm-gtk library by default, as explained here: https://gitlab.gnome.org/GNOME/netwo...aw/1.8.20/NEWS.
This library is still required by some plugins : for instance, NetworkManager-openvpn can't build anymore on -current

I suggest to rebuild network-manager-applet with the --with-libnm-gtk flag so third party plugins can still build till they adapt to this change.

3 members found this post helpful.

The libnm-glib support has been deprecated. Try rebuilding using the --without-libnm-glib switch.

How about changing to in glibc.SlackBuild .
Seen here http://www.linuxfromscratch.org/lfs/...r05/glibc.html.

if I remember correctly I think it was set to 2.6.32 for compatibility with openvz.

it's true that there's a new openvz around based on kernel 3.10 but I'm not sure how many providers are supporting the newer version already (also because in their wiki is still labeled as "testing").

1 members found this post helpful.

git-2.21

release notes --> http://lkml.iu.edu/hypermail/linux/k...2.3/00116.html
sources --> https://mirrors.edge.kernel.org/pub/...-2.21.0.tar.xz

Eh, I'm all for breaking some of the groups up (eg, I don't think there should be any KDE related libs in 'l') but I don't think this particular one is necessary. Email server packages are very discrete and you can just easily delete the 2 or 3 you don't need. slackpkg install-new will never try to re-add them to the system, unless a whole new email server package is introduced.

1 members found this post helpful.

Packages series are a remnant of the floppy disk era anyway. Not that useful in 2019 IMO.

But you can still make your customized tag files without changing the default ones for Everybody (on which presumably Everybody won't agree), this is authorized by The Laws of Slackware

1 members found this post helpful.