SlackBuilds.org Orphaned Build FAQ

What is an orphaned build?

How does a build become orphaned?

What happens to orphaned builds?

My build got orphaned! What happened, and what can I do about it?

I have a build I don't want to (or can't) maintain any more. How do I orphan it?

Can I take over an orphaned build?

One of my builds depends on a build that got orphaned. What should I do?

How do I find orphaned builds that I might want to take over?

Why do orphaned builds have to get removed from the repo? Why can't they just be left in the repo indefinitely?

If you're removing orphaned builds, is there a way to find builds that were removed from the repo?

How do I find out how long it's been since a build became orphaned?

• A SlackBuild that has no active maintainer.

  This doesn't just mean "hasn't been updated lately".

  We don't mark a build orphaned just because it hasn't been updated in a while. Upstream may not have updated it, or the maintainer has a good reason to stay at an older version.

  We orphan builds that are unmaintained. It's only unmaintained if nobody is paying attention to it (which isn't always easy to verify). Orphaning a build whose maintainer has disappeared is just making the .info file reflect reality. It's already unmaintained, we're just documenting it as such.

• Usually, one of these:
  1. Maintainer can't be reached by email, after multiple attempts over a period of at least a week.
  2. Maintainer can be reached by email, but responds with "I'm no longer maintaining SlackBuids" or "I'm no longer running Slackware".
  3. Maintainer posted "I'm abandoning my builds, whoever wants them can have them" on the mailing list, but some (or all) of the builds never got taken. In this case, the polite thing for the maintainer to do would be to orphan the remaining builds... but that very rarely actually happens.
  4. Maintainer has multiple builds, some of which have upstream updates, but hasn't updated any of them at all in at least 5 years. Actually, sometimes this number is more like 10 or 12 years.

• Eventually, they get removed from SBo. In the past, orphaned builds have been allowed to stay in the repo for months or even years. Starting soon, there will be an automatic process that removes orphaned builds after they've been orphaned for some number of days (90, 120, or maybe 180; we still haven't decided).

• Possibly you missed some emails from a SBo user or admin. After a few weeks of non-response, we have to assume you're no longer paying attention.

  If we orphaned your build in error, you can either:

  • Ask the SBo admins to restore your build. You can ask on the mailing list, or private email (or even IRC, if you're an IRC user).
  • Submit an update/PR/MR with your name and email address in the .info file (in other words, put it back like it was). You don't actually have to ask for permission or tell us you're doing this.

• Before you consider doing that, you should ask on the mailing list whether anyone would like to take over maintenance.

  If nobody responds to the request after a week or so, you can go ahead and orphan your build. To do this, change the MAINTAINER and EMAIL in the build's .info file to *exactly* this:

       MAINTAINER="orphaned - no maintainer"
  
       EMAIL="NOEMAIL"
  

  It's important to be exact: we have scripts that depend on these values for maintainer and name, which might get confused if you change them.

  For your commit message (or submission comment if you use the site's submission form), you can keep it as simple as:

       category/build: Orphaned by maintainer.
  

  Optionally, if you want to add an explanation of why you're orphaning the build, that's best done by adding comments near the top of the .SlackBuild itself. E.g.

       # Orphaned by your name on date because reason
  

  ...where reason might be something like "This is a hardware driver, and I no longer own the hardware it's for", or "No longer have free time to spend on SlackBuilds".

• Yes! Please do. We'd rather see the build stay in the repo and be actively maintained. If you want to take over an orphaned build, just do it: Send a submission, GitHub PR, or GitLab MR, with your name/email in the .info file and any other changes you want to make. You don't have to ask for permission or notify anyone.

  In the unlikely event that someone else has also decided to take over the build at the same time, we (the admins) will post that fact on the mailing list, and you and the other maintainer can decide which of you get the build.

  Note: If you take over a build that has any dependencies listed in REQUIRES (in the .info file), make sure those aren't also orphaned. If they are, you should take them over, too.

• You should take over maintenance of the orphaned build. If you don't, eventually the orphaned build may be deleted, which would leave your build broken. Alternatively, if you really can't take it over, you should ask on the mailing list; someone else might be able to take it instead.

• One way is to use the website's Advanced Search, choose Maintainer as the search type, and NOEMAIL as the search term.
• Another way is to just click this link:

  https://slackbuilds.org/advsearch.php?stype=maint&q=NOEMAIL

• If you've cloned our git repository, you can use a command like:

        git grep '^EMAIL="NOEMAIL"' '*/*/*.info' | cut -d/ -f1,2 | less

• There are a few reasons for this...

  • Over time, builds break. Even patches to Slackware stable releases can cause problems (e.g. curl updated to 8.x in 15.0's patches/). If they're unmaintained, that means the SBo admins have to patch them. When a new Slackware stable release happens, this is a lot of extra work (we already have to patch a lot of the maintained builds). Even after all this work...
  • Unmaintained software may have security issues. It's a maintainer's job to keep up to date with security issues, applying patches and/or updating to non-vulnerable versions as needed. If there's no maintainer, nobody's doing this job. Leaving builds with potential vulnerabilities in the repo can be a security hazard to us all.
  • We don't do run-time testing. It's not feasible for the SBo admins to actually install and run every piece of software. Some things, we *can't* test (e.g. hardware drivers for hardware none of us owns; software that requires domain-specific knowledge to use).

  There have been quite a few builds over the years that have been kept in the repo, unmodified, across Slackware releases, that don't actually work: Running the script produces a package, but installing the package results in software that fails to run (e.g. segfaults on startup).

  It's a maintainer's job to fix problems like this. If there's no maintainer, we just have brokenness we don't even know about. And if nobody's reported "Hey, segfaults on startup, and I can't reach the maintainer by email!", probably that means nobody's even trying to use the build.

  • The site is faster and costs us less in storage/bandwidth, if the repo is smaller.

• Yes. They end up here:

  https://slackware.uk/~urchlay/boneyard/

• Clone the git repo (if you haven't already):

      git clone git://git.slackbuilds.org/slackbuilds.git

  ...then "cd" to the directory for the build you're wondering about. If the build is called foobar:

      cd slackbuilds/*/foobar

  ...then run this:

      git -P blame -L/MAINTAINER/,+1 ./*.info

  ...which will show something like:

      a8f3447a2bb (B. Watson 2025-10-11 00:27:38 -0400 9) MAINTAINER="orphaned - no maintainer"

  ...which shows the date/time of orphaning, plus the user who orphaned it.