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.