Slackware 14.2 is coming , but will the slackbuilds will also be updated accordingly?
 

With Slackware 14.2 rc1 , does alien bob and the team , will they be able to update the slackbuilds.org with all new builds for 14.2 on time? i see a lot of old packages in it , but still everything works fine , i was just curious to ask . Dont get me wrong ;-)

Yes, you might want to read through this thread.

@Speck , thank you

I guess you haven't check master branch?
http://slackbuilds.org/cgit/slackbuilds

To be clear, SBo is not affiliated with or officially endorsed by Slackware. It's a different team and the admins and maintainers are all volunteers. See #1 in the FAQ: https://slackbuilds.org/faq/#affiliation

If it doesn't happen right when 14.2 gets released, it will happen soon afterwards.

Sbopkg (although I've switched to sbotools) takes a bit longer still. But just a bit.

Hi, I'd like to take this opportunity to officially endorse SBo. Nobody ever asked me, as far as I can recall.

Class. The mold was definitely broken after Pat!

+1
I do believe SBo is now officially endorsed; doesn't get more official than this. :)

Well this is certainly welcome! :)

Well. F-udge. Now I have to step up my game to make sure my SBo submissions are worthy of this endorsement. I better get crackin' now that we are RC1!

The situation has just been changed.

Can... open. Worms... EVERYWHERE!

`sbopkg` is always up-to-date if you point it to the master branch. ;^)

https://github.com/ryanpcmcquen/conf...T.sh#L495-L505

Oh Wow ! Thanks Patrick Volkerding !!

I have nothing good to say about slackbuilds. you maintainers that never answer emails. You have Ponce and Willy just dumping any push from a maintainer that does not even use Slackware. but they want to maintain it.
I mean just to build qjacktl for 14.1 now you have to compile qt5. What is worse it is not an alternate location install.
so it dumps right into /usr/lib64 or /usr/lib. just nuts the crap I have been watching in there. Right now you have programs in there that are so unsecured they are still using the old heart bleed ssl.

Do not take your time to work on the problems or contact the maintainers they are fictional. I have been trying to contact them for over 6 years now and never one reply. So this tells me they are dumping crap that they have no clue what they are building against.
If I was you I would go to the slackbuilds github and go to the second revision after 14.1 came out and clone it.
Then from there start doing your own. because. this year slackbuilds took 2 years of my work in slackware 14.1 and threw it away.

And if you do get a sarcastic reply from Ponce. It only shows he is over his head. And Care less about slackware 14.2.
.
This is why Alien bob and many of use just do are own thing. main stream Slackbuild.org does not care ok. Why should they they are doing it for free. They care less if it cause 2 years of work to be ruined.
My rant.

Pat I disagree your not seeing the whole picture. But your work is fine. now go build qjackctl against slackware 14.2 and try to do any development with transitional programs that are working with dual builds of qt5.
I have tried to get a hold of these maintainers. unlike you you actually answered me in emails.
I am sorry my dealing with slackbuilds has been a nightmare.

hi Drakeo,

sorry, I'll paste links your pull requests on my personal repository (not submissions to SBo) so people could have an idea of what you are talking about

https://github.com/Ponce/slackbuilds/pull/5
https://github.com/Ponce/slackbuilds/pull/6
https://github.com/Ponce/slackbuilds/pull/16
https://github.com/Ponce/slackbuilds/pull/19

I will not add anything to what anybody can read.

Is it tomorrow already?

It depends on your timezone.

I will say that my experience with SBo is quite a bit different. I am understanding that willy, ponce, etc are just maintaining the repo and don't want to step on the toes of the people actually maintaining the packages. If a package isn't broken or isn't breaking their rules, then any changes they impose on that package could be seen as strong-arming and could hurt the admins relationship with their maintainers and violate trust. They have to walk a fine line when making adjustments to packages to ensure they don't scare off package maintainers. But any suggested changes will obviously depend on the receptiveness of the maintainer. I will give two examples of a positive interaction with SBo and/or its maintainers.

1. I was trying to build lirc for kodi on -current back in November. It wouldn't build, and after a lot of work, I eventually figured out what was wrong. I tried contacting the maintainer to get things updated, but I got a bounceback for his email. I then proposed taking over maintainership on the SBo mailing list, and Willy gave me the ok, so I submitted that package (along with a new required dependency). When the maintainer won't respond to messages, SBo will allow you to take it over yourself.

2. While building kodi, I had some suggestions on what should be enabled by default on the SlackBuild (so those optional dependencies would become required). I emailed the maintainer about it and after some discussion, he chose to incorporate a few of my suggested changes. This will be highly dependent on how willing the maintainer is to receive suggestions, but if you present things logically and politely, they'll probably be open to suggestion. You can always email the maintainer and CC the SBo mailing list to get a proper discussion going on any suggested changes. That way, if the maintainer doesn't like the changes, but the group thinks they're worthwhile, it may push the maintainer to make the changes.

Your work is appreciated, and I hope you don't stop trying to make improvements to various packages and to continue maintaining yours :)

Like many open source projects, SBo is a volunteer effort by the package maintainers and the repository admins. It's a lot of work - I know this because I was both a maintainer and an admin in the past. However, in more recent years, I have not had as much time as before, therefore I had to turn in my admin privileges so to speak and get other people to take over my packages. I also use FreeBSD and OpenBSD and the same thing happens in their ports and packages. Volunteers come and go but the project lives on. That's part of the deal when participating in open source projects.

The SBo admins do a helluva job, IMHO. It is not easy herding cats (i.e. package maintainers) and if a maintainer drops out then what can the admins do? They rely on other volunteers (i.e. people who use a package in question) to step up and take over maintainership. If nobody steps up, then either the package can sit in the repo as-is as long as it builds or it can be dropped and I think both happen. And I also know that changes are tested against the repo before being pushed out to the public.

Last, I don't see anything in ponce's replies to your pull requests that seems sarcastic. In all my years of working with ponce and all the other folks in and around the Slackware community, everyone seems to me to be helpful and cordial. Of course, one still needs to learn to help themselves first, but in my mind, one of the best things about using Slackware (aside from the technical aspects that come from Pat and the team) is the community around it.

If you have a problem with a SlackBuild bring it up with the maintainer, if they do not respond then bring it up with SBo. Its really that simple...

Please have a look on master branch in https://slackbuilds.org/cgit/slackbuilds/
Those are real work on SBo repository against latest current. They are not backported to 14.1 since we are focusing on 14.2

Some maintainer are no longer active and that's why you don't get reply. This is NOT a PAID job. It's explicitly expressed in SBo's main website.

Feel free to judge but we need real actions that follows the rules, not just some random rants and no real work :)

Does it mean security is not among those rules?

It's your system and you have responsibility for its security. You are welcome to get advice about security from many places -- LQ, upstream websites and mailing lists, LWN, the SlackBuilds.org mailing list and maintainers, specialised security mailing lists, etc.

There are Submission Guidelines and there's an FAQ page. If anybody wants rules, I guess those pages might make them happy.

If anybody knows specific problems, please report them on the SlackBuilds.org mailing list. If there are "programs in there that are so unsecured they are still using the old heart bleed ssl", I want to know the package names please, preferably with fixes and before 14.2 is released. (But don't expect backports to 14.1.)

Basically, yes. Each package is maintained by whoever maintains it, and there's no guarantees that a package will be updated because a security patch was issued upstream. One sample is Firejail which is still 0.9.18 on SBo, although on the Firejail homepage 0.9.38 was released Feb 2016 with this note
I think the SBo maintainer of Firejail has dropped it though. I personally quite like SBo, but the whole thing is not completely tight from a security point of view (depending on what you install) simply because it's run by volunteers. That's part of the deal though.

Most of them are easy to fix simply by changing the VERSION line and build the new version which fixed the security problem.
Remember that we ship Slackbuild Scripts, not a binary packages.

Fixed in master branch since last month
https://slackbuilds.org/cgit/slackbu...246284735aca3a

That's what I usually do, but I was just pointing out that SBo doesn't come with any update guarantees, and that any given Slackbuild may or may not be active (i.e. the admin has to keep on eye on things).

Nice :) I had some trouble updating that one. I will have to join the SBo mailing list.

In normal cycle (when new stable is released), we normally do not update the whole repo by ourself and we need maintainer to pro actively submit updates via submission forms.

During development cycles like nowadays, some packages are broken due to updates in current so we need to fix things to make sure they are fixed when new stable is released. Some maintainer prefer to wait until next stable

Thanks for the reminder. PPA maintainers have same advice for Ubuntu fans.

Sorry sir. I don't have enough time to bug track and read various websites and mails for every single package which I install from SBO. Therefore, if SBO maintainers let everyone threats security of Slackware users by bad slackbuilds or buggy codes, I prefer to change my habit and use Eric and Roby repositories as main source of third party packages.

Then you may need a package not provided by Eric and Robby. Will you compile it by hand or write your own SlackBuild? In such case you will also have to bug track packages and read various websites and mails for every single package you install.

In general I find SBo to be pretty good with updates. But the point was that slackbuilds are maintained by volunteers, so it is true that they are sometimes abandoned, but in my experience that's for the rarer pieces of software. Just to name a few that I like--TeX Live, Libreoffice, R, Audacity, Clementine, Digikam, Duplicity, Lame, Nvidia drivers, Recoll, Transmission, Yakuake--all on SBo, all brilliant :) But, at least you have the freedom to choose :study:

I appreciate the people that maintain SBo, and the people that maintain the SlackBuilds themselves. It is a valuable resource that people can share their builds and the rest can benefit from. Sometimes maintainers fall behind, or lose interest in a project which is sad but hopefully there is someone that can pick up the "Slack". :) I have found a few packages on there that are updated past what Alien has in his repo, So it happens to them all. (Appreciate you too Eric, I don't know what I would do if I had to compile something like LibreOffice or Plasma 5).

PS: Pale Moon is broken on -current and has been since Feburary.

Travis, then perhaps Slackware is not the distro for you. With Slackware, there is PV, Eric, the team, SBO, and various tools to help, but ultimately you are the admin. If you think SBO has unmaintained packages then pick up the slack and help maintain some. Don't even get me started about the number of unmaintained or poorly maintained packages on other distros....Not naming names but 25K packages with 1k packagers is 25 per person...just saying, many of those are poorly maintained.

It builds ok here (most recently on 29th March). I've just installed it, and it works well enough to log into LQ, and I'm posting this reply with it right now.

Apparently it still has the same lousy textbox bug that Firefox cured years ago. meh

libwebp, slackbuild is for 0.4.3 but works with 0.5.0

webkitgtk, slackbuild is for 2.4.9 and seems to be working for 2.4.10 *

gnucash, slackbuild is for 2.6.6 but works with 2.6.11

If it's out of date you update it. What's the problem?

* I'll know for sure for sure in about 20hrs time... it really is a slow build.

official endorsement is official

Seriously? I can do a full fresh install and build Pale Moon 25.8.1 or 26.1.1 and each one gives me a seg fault. Maybe I need to refresh my mirror.

Thanks for the feedback.

Webkitgtk has been updated last month in master branch

Gnucash updated to 2.6.11 as well.

People should look in master branch in GIT repository instead in the Web since 14.2 is not out yet

Thank you :) I will have a look.

But my point was that Slackbuilds don't just work for the version stated but that they often work for updated versions as well.

So arguments that slackbuilds are for out of date software might be weaker than the proponent thinks.

As long as upstream doesn't make major changes, the script should work on newer version.

I wonder why you try to have a finger in every pipe. I didn't talk about unmaintained or poorly maintained packages. Next time read the post before quoting it.

What do you consider unmaintained or poorly maintained SlackBuilds? Do they differ in a significant way with SlackBuilds missing security updates?

It would appear to me that one of those is a subset of the other.

Travis, packages/scripts you know what I meant. You are complaining about something in Slackware that you have control over not someone else. You are your own admin...enough said. Others are gracious enough to help.

Ok, let me clarify. IMHO, if a package threats security of Slackware users it should be removed from SBO at least until it fixed either by it's developer or by slackbuild maintainer. I don't think SBO admins expect slackbuild maintainers to fix security issues of packages which they provide slackbuilds for (it would be good if they can). But, usually that's up to developers and providing a simple slackbuild using Eric template doesn't make me a developer. There must be a criteria for adding a package to SBO and that criteria shouldn't be just "successful build, install and work on Slackware". I don't know SBO admins have such control over SBO or not (I guess they have). They already have done a great job to manage thousands packages for various Slackware versions and me and other Slackware users always will be thankful for their work.
Of coarse even windows users must be admin of their system (not just Slackware ones) and the first step of such a administration is "getting software from trusted sources". Existence of security problems in repositories of other distros doesn't mean they should be exist elsewhere. You know all criticism about security of android because Google policy that let everyone to spread their crapware through Google play despite for instance Apple which has more control over App store.

That was my point. Forgive me if it hurts someone. God bless PV, Slackware team, SBO admins and all Slackbuild maintainers. Please don't bother to quote me for such answers: a) be a true slacker and fix security issues of SBO packages. b) be a true slacker and inform SBO maintainers about all unsecured packages (I will do that if I know any). c) go and use your windows. d) you'd better keep your promise and don't post in Slackware forum at all (well, I broke it already. Sorry Didier).

Regards

No problem. But yes, IMHO your time would be better spent on your PhD dissertation ;)

If this is brought up to the SBo admins/mailing list, I'd imagine they'd consider various actions. If there's an updated version with a fix, and it builds correctly on Slackware, I'd bet they'd update it themselves, even if the maintainer isn't involved. If there's no updated versions, but a patch available, I'd suspect they'd work the patch into the SlackBuild. If there is no fix, then there'd probably be discussion on the ramifications of removing the package or keeping it in an insecure state.

But they have to be notified when there's security concerns. I certainly don't check the sites of the SlackBuilds I maintain very frequently to see if there's updates or security issues. With my SlackBuilds, the software isn't updated very frequently, so I don't check it very often. I don't even really care about the development of those programs. They're just dependencies for another program that already had a SlackBuild that broke with -current. So I fixed one and had to add the other as a new dependency. If someone were to notify me of a security concern, I'd do my best to put out an updated SlackBuild that either patches the version I already had or change it to a newer version that doesn't have the vulnerability. And if they were to notify me of a version update, I'd do a little bit of digging to make sure it builds fine and doesn't break things, then I'd submit an update to SBo.