SlackwareThis Forum is for the discussion of Slackware Linux.
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.
I'm not really sure you should ask on here what you should maintain. Probably the best option, find something that you use/need that isn't on SBo (yeah, right), submit the slackbuild and maintain it. You could maybe see if there is a slackbuild that someone has stopped paying attention to and takeover as well.
I want to start giving back to Slackware, and figured the easiest way to do so is by maintaining a package on SlackBuild.org.
I've been fortunate in that I've been able to find all the packages I've needed on SBo, so I was wondering if anyone here was looking for anything in particular.
Scripts on SlackBuilds.org are maintained. We do not accept submissions without maintenance. You can subscribe to the SlackBuilds.org mailing list where maintainers regularly announce that they stop maintaining a script - you can then take over if you want.
Originally Posted by moisespedro
I think pipelight would be a good package to maintain.
Pipelight depends on a modified version of wine, and therefore not supported for 64-bit Slackware (at least on slackbuilds.org which does not want to support multilib because it is not part of Slackware). Also, I have build scripts and packages myself, so there is a proper alternative.
Oh ok, I didn't know they don't accept multilib. And by the way, sometimes I see a package on slackbuilds that is outdated and I change the slackbuild and info files myself (just changing the version). Is that the right way to do it? And can I submit the files even not being the maintainer of the package?
And by the way, sometimes I see a package on slackbuilds that is outdated and I change the slackbuild and info files myself (just changing the version). Is that the right way to do it?
Certainly, it's how I do it too. The only thing to keep in mind that the SlackBuild has been tested and approved for the VERSION which is meantioned in the .info file, and that other versions may or may not have compilation or functional issues.
And can I submit the files even not being the maintainer of the package?
Only the maintainer who is listed in the .info file can submit updates, we reject all others. If you have an update, you should contact the maintainer through his email address (we require a valid email address if you submit anything at slackbulds.org). If a maintainer does not respond to several questions, you can write a post to the mailing list and ask if you can take over maintainership. One of the admins will respond to your question.
Thanks for all the replies guys - it sounds like the best method is to find a package that is outdated, try and give the mantainer an updated version, and then if that doesn't work, try and take over maintenance.
Not just network/sphinx but there are several packages no longer officially used by Slackware that could use some maintenance to keep the patches current to allow them to build still and be useful for those interested outside the official realm without being pushed into pasture completely.
Hal and Hal-info are still mildly useful for a small multimedia crowd and a SlackBuild and updated patch set to build with modern 3.10 or later kernels would be beneficial.