When did that port break?

Sometimes you want to find out when a particular port stopped building. Ports break either on port upgrades, upgrades of ports they depend on, or changes to the FreeBSD src tree.

The quick answer is that there no quick answer: you will need to do some detective work.

Let's assume, to make the discussion easiest, that your port broke because of an upgrade, and it's broken on all architectures and OSVERSIONs.

You need to start with the pointyhat front page. There you will find a bewildering array of links. You will want to start with the group New build failures. The most likely link for you to start with is New build failures on 8.x-stable for amd64 and/or New build failures on 8.x-stable for i386. (I'm picking -8 because that's where a port is most likely to build as of the creation of this wiki entry.)

Now you're taken to a page entitled New package building errors. This is a table of category/portname vs. first-broken-date vs. latest-build-date vs. number of times it failed to build. The link under port will take you to the CVSWeb page for the port; the link under Build log will take you directly to the latest build log. (Note, if a run is in progress, as it usually is, this logfile may be temporarily unavailable).

If this is not enough information for you, you may want to go the portsmon overview page for that port to learn more about which archs and OSVERSIONs where it is currently showing up as non-buildable. FreshPorts is also a useful resource.

But all that is the easy part. If you've read this far, you may be looking for the answer to the harder question ...

When did that port last build?

It's time to put on your deerstalker cap. The game is afoot!

pointyhat is continually doing incremental builds of ports for various combinations of archs and OSVERSIONs. The ones most often built are i386 and amd64 on "the earliest supported version of 7-STABLE, 8-STABLE, and 9-STABLE". (We are trying to make things easier for portmgr to keep up with updating the latest 10-CURRENT builds, but they often lag; OTOH the OSVERSION that the port Makefile will see will be the latest value from SVN -- it's just that the kernel/world that that Makefile is being evaluated on may lag. See why I put off that discussion at first?)

In any case, let's assume the page under Error logs / Previous run on 8.x-stable (e.g. for amd64) doesn't contain the build error you are looking for. (This can be either because that page has been rotated out, or the port got marked BROKEN and was not even tried).

Look once again at a New build failures page. Note the value of "first broken". You're going to use that to index into another page.

That page will be under Archive / All portbuild logs (e.g. amd64, i386). Don't click on it yet! You need to know that patience is required. You're going to get the complete pointyhat build history for that arch. The page can take a long time to load!

Let's use the i386 one, since the amd64 one seems to be broken as of 20110918. siiiiiigh

Ooh, loading that page took forever, didn't it?

OK, now you're going to see a huge number of links. You are looking for the a.*.* (all logs) links, not the e.*.* (errorlogs) links. Example: a.8.20110223062852/. This is the directory for the logs that were built on a run for i386 on 8 that started on 20110223. Remember that "first broken" value? You're going to use that and start searching backwards from that for a run.

Now click on that link and go get a cup of coffee.

Well, here you are, a list of all the port build logs for that run. Make sure it was a run that ran to completion! If it's a really short list, it didn't. Go back and try the previous one in the list.

Once you load the right page, clicking on any link will show you the build log for that port.

Now: is there a build log for your port, and was the port still building at that point? Great. If not, you're going to have to iterate over the above process to find out exactly when it broke.

And that's how it's done.

But what about '''-CURRENT'''?

There's a reason I put off this explanation for last.

As hand-waved above, we don't update the -CURRENT worlds every time there's an SVN checkin, or even every time there's an OSVERSION bump. It's simply impossible due to the rapid pace of change -- and hardware constraints. (Never mind the fact that we would also be constantly chasing glitches in -CURRENT itself.)

You're going to have to use the links for 10, e.g. a.10.20111207031942/. Unfortunately it does not appear that those logs contain anything more specific than "building for: 10.0-CURRENT i386". This is definitely a bug, and there's no workaround.

So consider this a "work needed" statement.

In any case, let's assume that you somehow figure out what checkin broke the port. To fix it, you'll need to determine the correct OSVERSION to patch the port Makefile.

Example from sysutils/syslog-ng's Makefile:

.if ${OSVERSION} >= 900007

.endif

Now, how do you determine which OSVERSION to use? If there was an OSVERSION bump for it in param.h, you're lucky, just use that. However, if there wasn't one, then just use the previous version in the sequence. If anyone has an SVN checkout between that previous version and the date broken, well, they're just out of luck -- OSVERSION is the most granular control available to port Makefiles. (This is why portmgr is so insistent on seeing OSVERSION incremented even for things that "can't possibly change anything" -- e.g. additions to libc, which then break auto* scripts that "know" that libc doesn't have that function, and so try to install a local copy, and the compile fails because of conflicts. Easy!)

Conclusion

Software is hard.

If you have any questions about this information, you can ask its author, MarkLinimon.

WhenDidThatPortBreak (last edited 2012-02-26 16:38:13 by EitanAdler)