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.

1 members found this post helpful.

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.

1 members found this post helpful.

Firestorm is sad it is no good. using qjackctl 0.41 instead of 0.40 .40 is much better for slackware 14.0 14.1 14.2 it does not require qt5.
Mixxx still has the script so it does not build with shout set a patch and request to the maintainer years ago. because SB finally updated to the newer libshout. After 4 years of trying to get anything correct in sbo it just easier to keep your own stuff.

https://github.com/Drakeo?tab=repositories
and
https://bitbucket.org/Drakeo/

and some of the work does with this work.
is SBO Broke youtube
next week it will be on Micro Linux and a quick tutorial on pulse-jack-sync

Users can simply remove the package from their system if they think it's insecure or if they don't trust other's work.

Remember that SBo only provides SCRIPTS to build sources into a slackware-compatible packages, not the binary itself. Upstream is the one handling the original sources.

1 members found this post helpful.

qjackctl maintainer have his own reason why he upgrade to qjackctl 0.41, and you can always discuss it with him.

there's no rule saying that you MUST use SBo repository, ie: you have a choice, either you use the scripts provided by SBo or you can make your own repository based on scripts available in SBo. That's what i did with MSB (originally written by Chess) and CSB projects.

1 members found this post helpful.

Well, as I said before I know a simpler solution, ie: getting stuff from trusted sources.

a nice summary why not everything, like for example PAM, can not be outsourced to SBo or other 3rd party repo that easy, even if it is official endorsed.

and that's why most distros have a core, and some EPEL/Universe/Packman/Factory/BuildService/whatever where at the end you are on your own and can hope only that the 'community' you trust in, which is very often 1 person, is not on holiday.

I want to mark this comment as helpful, but I respect Pat too much to be the one to destroy a perfect 42 approval rating.

2 members found this post helpful.

Thank you for your reply.

I think that we all want the best systems that we can have, given the constraints of other people's time as well as our own.

travis82,

what exactly do you want? Can you suggest a list of criteria for adding a package to SBo? Post it here, I am sure others will add their opinion. Then you can post it to the SBo mailing list, and who knows? May be you will help improve the quality of SBo.

PS: I am glad you stayed in the forum, I generally like your attitude.

If we are going to design more rules, maybe we should consider this highly relevant blog post from Matthew Garrett which he published late last night.

Also maybe we should ask ourselves which packages in SBo could realistically ever cause security breaches -- remember the guy who was frightened of manpages? -- and whether we have a right to impose more rules on other peoples' copious spare time, and whether more rules would just make us more like Debian.

2 members found this post helpful.

SBo is awesome and is not Slackware.
SBo is awesome because it is a slackbuilds repository. Please let it be only that : a slackbuilds repository. Simplicity is a feature.
How many slackers went back to Slackware because of over-engineered package managers in other distributions ?