Adopt an orphaned port project

lme@

lme@

Administrator
Staff member
Administrator
Moderator
Developer
Since the ports tree is now open again, let's start the "Adopt an orphaned port" project.

What is it?

According to http://freshports.org/ we currently have 23,940 ports in our tree, that's really great! But: There are 4,751 unmaintained ports (approx. 20%), that need your love.

What can I do?

Adopt one or more ports!

You think it's a lot of work? That's not necessarily the case, the ports are already there and just need someone to track the latest upstream versions and someone who keeps the port in a good shape.

How do I know which ports are unmaintained?

That's pretty easy: If you want a list of all unmaintained ports, run
# nawk -F"|" '$6 == "ports@FreeBSD.org" {print $2}' /usr/ports/INDEX-`uname -r | cut -d'.' -f1`

If you want to see which of your installed ports are unmaintained run
  • for PKGNG:
    # pkg query -e "%m == 'ports@FreeBSD.org'" %o
  • for pkg_*:
    Code: 
    #!/bin/sh

INDEX="/usr/ports/INDEX-$(uname -r | cut -d'.' -f1)"
MAINTAINER="ports@FreeBSD.org"

grep -h ORIGIN /var/db/pkg/*/+CONTENTS | cut -d: -f2 |
  nawk -v INDEX="$INDEX"  -v MAINTAINER="$MAINTAINER" \
    '{ installed_ports[$0] = 1 }
    END {
    	FS="|"
    	while (getline < INDEX) {
    		if ($6 == MAINTAINER) {
    	   		sub(/\/usr\/ports\//, "", $2)
    			unmaintained_ports[$2] = 1 
    		};
    	}
    		for (port in installed_ports) {
    			if (unmaintained_ports[port]) {
    				print port
    			}
    	}
    }' | sort

What can I do then?

  • Pick a port.
  • Take a look at the port's Makefile and pkg-descr.
    • See if a new version is available upstream.
    • Check if the WWW line in pkg-descr still points to a valid site.
    • Check for broken distfile mirrors, take a look at http://people.freebsd.org/~ehaupt/distilator/ports@FreeBSD.org-bad.html.
    • Find other mirrors, or mirror the distfiles yourself.
    • Remove the dead mirrors from the port's Makefile.
    • Try to update the port to the new version.
    • Add yourself as MAINTAINER in the Makefile.
  • If the updated port works, create a patchfile and send a problem report (PR) with send-pr(1) or via the web interface http://www.freebsd.org/send-pr.html.
All you need then is some patience until some committer grabs the PR and eventually commits it or asks you to re-work the patch, if there are some issues left.

I'd really like to do that, but how do I actually do it?

There's very good documentation for porters, the Porter's Handbook: http://www.freebsd.org/doc/en/books/porters-handbook/. Don't worry. It's called a book, but it's not a very thick book. Even so it explains porting very good. While it's recommended to read the whole book you can also pick the chapters first that you need to update the port. If you still have problems or questions then, there are many helpful people at the ports@FreeBSD.org mailing list.

What benefits do I have?

Actually there a several benefits:
  • You give something back to the community. That's the idea of open source.
  • You earn experience with Makefiles, diff(1), patch(1) and other useful tools.
  • You and everyone benefits from updated ports.
  • Your name gets added to the list of FreeBSD Contributors: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/index.html.
  • If you create enough PRs and maintain a bunch of ports, it's quite possible that you get punished with a ports commit bit! \o/
 
I've had my eye on a couple of neglected ports -- when things at work wind down for the holidays, I'll have a go at updating them.
 
Thanks for sharing this info, I have seen some of them which I used daily using git, but I see those are poiting to old link or dead link. I will probably take those.

But I have a question, since most of the projects were moved to git, how to versioning them, I mean what will be on PORTVERSION?

--
gnumonk
 
What if the port has a MAINTAINER, but they seem to have vanished?

There's a port, which requires frequent updates. But hadn't been updated in years. The last PR where the maintainer responded was in August 2010, where he submitted a patch that updated it from 0.57 to 0.59.

None of the ports of this nature worked when I tried them, but I found that this port's upstream had an active community maintaining it. Though there appears to be a gap in activity from November 2010 to August 2012. So, I found the latest revision and got it working. I submitted a PR to update it to version 2.7, where I with with provide the distfiles since the current versions involve reading a discussion thread and checkout the specified CVS revision on Sourceforge. After about six weeks it was committed with maintainer-timeout.

Later the port stopped working, a 3.0 .tgz had been released during the time, but I needed to actually get revision 2.29 from CVS (v3.0.3) for things to work again. So, I submitted another PR, this one has been waiting for maintainer feedback for over two months now.

Meanwhile, I've had to update again. But, how should I submit or why? Feel I might also be the only person on FreeBSD using this port.

The Dreamer.
 
Which port is it? Ask on the freebsd-ports mailing list and request that the maintainer of the port is reset to ports@freebsd.org which means that the port does not have a maintainer. Or if you feel that you could do the maintainer's work yourself volunteer as the maintainer ;)
 
Maybe it's just me, but I would like to know that a reasonable number of people are using (or at least have installed) a port before committing to maintain it. Priority should be given to maintain those ports most frequently installed/used, but are orphaned WRT being maintained, no?

Is this information available somewhere?
 
The being mentioned as a contributor thing never happened, but otherwise:
Code: 
# find /usr/ports -name Makefile -exec grep MAINTAINER {} \; | grep -i ports@FreeBSD.org | wc -l
  4279
There are still over 4,000 unmaintained ports so if you feel like "adopting" one (or a few) of them, then you are by all means welcome.
 
I'll happily add everyone to the contributor list who maintains a port. :)
 
A while back, I had intended to adopt the orphaned ports that I was using that were facing deletion due to not STAGING, but I got busy and didn't get down to working on them (part of it was working through some issues in getting poudriere working.)

But, the port is now gone, and I'll probably just go find an alternative when the occasion to want to use something like it comes along.

Though back when I last posted, I had kind-of adopted one. It wasn't a true orphan, since it just had an absent maintainer. First time I updated it, it was eventually accepted on timeout. Second time I updated it, it timed out but never got acted on. While I was waiting for that to time out, there was a third update. And, after both had timed out, it was in need of another update, except it felt like I was the only person trying to develop the update upstream (given how Mircosoft does rolling updates, not everybody is impacted by a change they make). There were other contributors to the bug report, and I wasn't the original submitter, but evidently the only one willing to dig into the source and try things. All along, the author reported that the issue didn't affect him yet, but later he declared it dead and that he's off to work on its successor, but nothing released yet.

I forget if the request to have it marked BROKEN or removed has timed out yet, and if it has happened. I guess it did. It doesn't say how long with 'maintainer timeout' before the first update got in, but the second update says '9 months', while for the final update as BROKEN the timeout was 'four weeks'. A little while later, portmgr@ changed it to use USES, and then a couple of days later it expired and was deleted.

To be a powerful being like portmgr@ must be fun, since ports will suddenly change behavior with no need to say anything. I'm currently dealing with a port that did what it's described to do. But, portmgr@ has updated it with just a comment of 'cleanup plist', except that he also updated the port to the latest version and changed it so it no longer does what it's supposed to do nor provide a knob to control this unexplained change to the port.

Though ideally, there should be a different way entirely for the port to exist in its intended form without the kind of hops I'm going through to use it that way now. (I'm thinking it should be like how all the sendmail-* slave ports got pulled into the master, so that other ports that depend on it don't keep trying to install the master on top of one of the slave ports, except that it's not a master/slave port problem.)

Meanwhile, I had intended this four-day weekend (due to taking Monday off before tomorrow's holiday) to clean up and submit a bunch of patches I needed to get various ports to build in poudriere, and perhaps see if some of the patches for a port I was updating are still applicable (because 'poudriere testport' catches the errors, where other methods don't) since the maintainer has reappeared and jumped it over the update I was working on. (Most of the errors are associated with enabling an option that isn't set by default, and some as simple as missing a @dir or two.) Except that somewhere overnight my system died and one zpool didn't make it (the one that includes /home and /poudriere), I'm watching to see if zdb -e -bcsvL will recover it (current ETR is 2974+ hours.)

I never did get around to building a second FreeBSD server so that they could back each other up; the latest delay is that some of the drives for that build got used to replace drives that failed last summer in my main system. If I get things back up and running, think I should see about moving more essential services from this machine over to my two headless (SFF) servers. Some of them might make a good candidate to go on my tiny HAST volume, now that I got CARP stablized. ipfilter was getting in the way, someday I'll get around to pf conversion.

ipfilter because that's what we use at work on Solaris and the same files worked on FreeBSD when we had a few pop up in production and in our CFEngine system. (Or I use, since Solaris and FreeBSD are dying breeds at work, and I'm the only one that hasn't quit or been reassigned.) Plus, the federal agency SLA customer that finally allowed FreeBSD into production use here is leaving us this month. We're going with mainly Ubuntu, with some RHEL for Oracle. We never got all our CFE policies to support Ubuntu, since FreeBSD took priority and most of that work was turned into that. At the time, there was no official reason to support Ubuntu; there was almost a ban on it, because one group kept asking for it. As for my home CFE, I'm not sure why I'm dragging on having it manage my Ubuntu systems.

ETR is 2996+ now, 3019+ now, I probably should go find something else to do with the rest of my staycation instead.

The Dreamer
 
Last edited by a moderator:
Maintainers should all be on the contributor list. I don't know if the ports group would want missing contributors entered as PRs, but it's worth contacting them, maybe on the freebsd-ports mailing list.
 
I just discovered that devel/cc65 is unmaintained. I'm using its assembler and linker for cross-development to the C64. The version in ports is so old, it doesn't parse my linker configuration in a little C64 demo project correctly and my build fails. So I'd be quite interested in adopting this one.

The problem is: the upstream maintainer changed meanwhile and the project structure changed a lot. I'd probably have to rewrite the port from scratch. Okay, I'd give it a try, but there is another catch: the new maintainer doesn't do releases. There is just a GitHub repository. How would I ensure production quality taking the code from there? How would I create a meaningful version number? Would this even be accepted for the ports tree?
 
Thanks for your reply. I already knew the technical aspects, because I created a port for my own GitHub project (mkd64), just to get used to it (and for a clean install).

That said, I could create a port for the new cc65 just for my personal use, but I'd prefer to share this effort. So, previously there were a versioning scheme and releases -- I guess the correct way now would be to set
Code: 
PORTEPOCH=1
and derive the version number from the date of the Git commit I'm using as upstream?
 
You must log in or register to reply here.
Back
Top