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.
I'm not sure how anyone who has been watching the changelogs for a few months could have missed the constant references to the upcoming stable 14.2 release:
Code:
Wed Jan 13 00:01:23 UTC 2016
Hey folks, happy new year!
After upgrading to BlueZ 5 recently, everything seemed to be working great,
but then it was pointed out that Bluetooth audio was no longer working.
The reason was that the newer BlueZ branch had dropped ALSA support and now
required PulseAudio. So with some trepidation, we began investigating adding
PulseAudio to Slackware. Going back to BlueZ 4 wasn't an option with various
dependent projects either having dropped support for it, or considering doing
so. After several iterations here refining the foundation packages and
recompiling and tweaking other packages to use PulseAudio, it's working well
and you'll likely not notice much of a change. But if you're using Bluetooth
audio, or needing to direct audio through HDMI, you'll probably find it a lot
easier to accomplish that.
Best of all, we're finally a modern, relevant Linux distro! ;-)
Thanks to Mario Preksavec, Heinz Wiesinger, and Robby Workman for a lot of
help and testing. Bug reports, complaints, and threats can go to me.
Also, enjoy a shiny new LTS 4.4.0 kernel and consider this 14.2 beta 1.
Code:
Wed Feb 3 22:39:25 UTC 2016
Welcome to Slackware 14.2 beta 2. Getting closer. :-)
Code:
Thu Mar 17 22:09:16 UTC 2016
Good hello, let's call this Slackware 14.2 release candidate 1. We still
have a bit of work to do before this is fully ready to go, but we're done
doing every little upgrade that comes along. Well, mostly.
Have a great day, and beannachtai na Feile Padraig oraibh!
Code:
Fri Apr 15 20:37:37 UTC 2016
Finally got some fixes we were waiting for in this new kernel.
It's been almost a month since 14.2rc1 so we'll call this Slackware
14.2 release candidate 2. Almost there. Get in any last-minute
bug reports quickly. :-)
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,167
Rep:
Well, let's see..... January, February, March, April and it is now the 21st of May, and the 2-1/2 year anniversary of the release of 14.1 was two weeks ago today, but, heck, a rolling release is OK with me.
Last edited by cwizardone; 05-21-2016 at 09:45 PM.
The only thing about running current or whatever we need to call it is the kernel updates
They break a few things
Other than that it seems to be in pretty stable shape although there was something about GRUB and EXT4 I believe, but lilo works for me right now except on a 32bit machine where it refuses to boot that other OS
Me not... as long as the ChangeLog includes comments like "We are nearly there", "call this RC1" or similar this proves this is not a rolling release. I think many guys which think about a rolling release try to compare Slackware with for e.g. Firefox which creates new releases every few weeks. This is what a rolling release is doing, bring many updates to the user when they are ready. This would make it necessary to have a testing and a stable branch.
There have been a few issues in -current which really caused my some headaches which is OK for a development release. If that would have happened on a stable branch of a rolling release i really would think about changing the distro.
Pat could simply develop -current behind the scenes and push a final release some years later, but sharing latest updates to -current with the community make it much easier to find and fix bugs before a release is done. Closed development is something we know from MS where you never know what you get.
I mostly like the "rolling release" feel of Slackware over the last couple of years. Particularly since slackware.no puts together an installation iso from -current every Tuesday, removing the need to do new installs by installing 14.1 and slackpkg-ing 2 1/2 years of updates.
The only thing I don't like is the somewhat chaotic state the "rolling release" leaves slackbuilds.org in. Some slackbuild pages have been updated frequently since 14.1, some not, some have patched slackbuilds available on 3rd-party sites configured against a variety of -current dates. Some just don't compile any more, and likely won't get fixed until 14.2.
I think that if the slackbuilds repository were completely updated on a more consistent schedule when there are multiple years between Slackware releases, say against -current on 1 Jan. and 1 July, then the "rolling release" style of using slackware-current in lieu of rare point-releases would be a lot easier.
I mostly like the "rolling release" feel of Slackware over the last couple of years. Particularly since slackware.no puts together an installation iso from -current every Tuesday, removing the need to do new installs by installing 14.1 and slackpkg-ing 2 1/2 years of updates.
Heh... it is very easy to create a dvd.iso from -current. OK, i do it not on every Tuesday... but on every Friday ;-)
Quote:
Originally Posted by croxen
The only thing I don't like is the somewhat chaotic state the "rolling release" leaves slackbuilds.org in.
I don't see any chaos there... Updates for 14.1 are there... for -current it is not that easy because -current may change at any time. I never used Slackbuild.org nor i will ever use it. Can't tell much more about SBo
Quote:
Originally Posted by croxen
I think that if the slackbuilds repository were completely updated on a more consistent schedule when there are multiple years between Slackware releases, say against -current on 1 Jan. and 1 July, then the "rolling release" style of using slackware-current in lieu of rare point-releases would be a lot easier.
Well...that's not the definition of a rolling release, it's like Ubuntu rolling out a release every six months. According to such comments best thing would be if SBo stops updating SlackBuilds for -current but that would not be very helpful to fix issues with the core base of Slackware.
No... People that find -current or SBo for -current chaotic should simply not use -current. It is a development tree. If you don't want to help the developers... don't use it. It is really that simple
P.S. Just for the record... here are my scripts for the ISOs (i keep them inside a slackware64-current directory):
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,167
Rep:
Quote:
Originally Posted by croxen
I mostly like the "rolling release" feel of Slackware over the last couple of years. Particularly since slackware.no puts together an installation iso from -current every Tuesday, removing the need to do new installs by installing 14.1 and slackpkg-ing 2 1/2 years of updates....
Alien Bob makes an .iso from -current available within a few hours of any modifications to the change log.
I've found it best to wait a few days before installing the "latest" -current so any problems that may have arisen from the most recent changes have been fixed.
Quote:
Originally Posted by croxen
....The only thing I don't like is the somewhat chaotic state the "rolling release" leaves slackbuilds.org in. Some slackbuild pages have been updated frequently since 14.1, some not, some have patched slackbuilds available on 3rd-party sites configured against a variety of -current dates. Some just don't compile any more, and likely won't get fixed until 14.2....
With the announcement of Release Candidate 1, slackbuilds.org went into a state of suspended animation and has been since January. Once 14.2 has been released things wil get back to normal.
Last edited by cwizardone; 05-22-2016 at 10:15 AM.
The only thing I don't like is the somewhat chaotic state the "rolling release" leaves slackbuilds.org in. Some slackbuild pages have been updated frequently since 14.1, some not, some have patched slackbuilds available on 3rd-party sites configured against a variety of -current dates. Some just don't compile any more, and likely won't get fixed until 14.2.
One of the SBo admins, ponce, has a personal, unofficial fork of the SBo repo that he and others update for -current. This allows users of -current to use that repo, then when issues are found, fixes can be researched and submitted allowing other users to benefit from it. Many of the automated SBo build tools are able to work with it.
Once Slackware 14.2 was getting close to being released, the SBo admins froze updates for 14.2 and then they took ponce's repo and pushed it to SBo's master repo. This allows more to have an eye on what's being done and continue pushing updates to ensure packages build properly on -current. Once 14.2 is released, then they'll have 14.2 SlackBuilds prepped and can push it out to the website quickly. As with ponce's repo, many of the automated build tools are able to work with this as well.
Long story short, if you want to always follow -current, use ponce's repo. If you find issues, try and research fixes, and send them off to ponce to update his repo
With the announcement of Release Candidate 1, slackbuilds.org went into a state of suspended animation and has been since January. Once 14.2 has been released things wil get back to normal.
Well, that will certainly be good! But I think my question only revolves around wondering whether slackbuilds.org's normal is really the best maintenance procedure if very long development cycles between Slackware releases become more of the norm in the future. As for Slackware itself, I think the development procedure as it stands is terrific --I only wonder about the apps and such that are to be installed on top of the OS. (To defuse whatever on earth it was that DarkVision was taking me to task over.)
I think we've all done various edits and workarounds and hacks to get this or that application or utility or its various dependencies to build from a slackbuild into a workable package if one was using a slackware-current version increasingly far removed from the most recent release. I just wonder if such surgery would be easier if the slackbuilds.org maintainers would add an updated page at a regular interval for their app or utility done against a -current image on specific dates every six months or so. So application "X" would have had its slackbuilds page for Slackware 14.1, one for -current as it was on 1 July 2014, a third done against -current as it was on 1 Jan. 2015, and so forth. After Slackware 14.2 is released, application "X"'s slackbuilds pages for the intervening versions of -current cease to be relevant and are taken down.
This way, if one is using a -current version of Slackware on a machine some number of years after the most recent point-release of the OS, and has to do application/utility installations, the relevant slackbuilds would always pertain to a -current no more than 6 months earlier and would accordingly be much more likely either to be usable "as is" or with only minimal tweaking.
I think projects like Ponce's collection of patched slackbuilds of various dates for -current at https://github.com/Ponce/slackbuilds are tending in this direction already. I just wonder if this sort of thing were better if systematized and incorporated into slackbuilds.org as a constituent feature.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
