Christian Weisgerber (naddy@) t2k13 report

As usual at hackathons, I set out to touch some ports with lots of dependencies. After updating audio/flac to the first new release in almost six years turned out uneventful, I moved on to graphics/png.

I had updated png a number of times in the past, but this time I paused. Just why did we bother to install the png headers in a nonstandard location, forcing us to add workarounds all over the ports tree to cope with this choice? I switched the png port to an autotools-based build and default file layout, did a full bulk build, fixed the fallout, and eventually removed a number of patches as well as workarounds from over a hundred port Makefiles. So much simpler. Once this was out of way, I actually got around to trying to update png to the new 1.6 branch (API changes!), which proved pretty straightforward and was committed shortly after the hackathon.

In the category of taking credit for other people's work, I enabled slowcgi(8). If you weren't aware yet, OpenBSD is in the process of switching the included HTTP server from the ancient Apache 1.3 to nginx. Since nginx is geared towards performance for high traffic sites, it doesn't support CGI programs. However, not everybody runs a huge commercial site and some of our developers still have a need for, say, a simple bgplg(8). Enter Florian Obser (florian@), who stepped up and wrote this FastCGI to CGI wrapper server. All credit to him. Since florian@ is a bit shy, and as an early tester of his work I had all the bits and pieces ready, I went ahead and committed the glue to hook up slowcgi and the nginx sample configuration I had successfully used to run the CVSweb CGI.

The hackathon also provided an opportunity to fix a number of other niggling but not very noteworthy issues in base and ports. I added support for XMODEM-CRC uploads to cu(1), which is currently awaiting nicm@'s review. Earlier this year, we had fixed a race condition in mkdir(1) that might affect ports builds with multiple MAKE_JOBS. I applied the same fix to install(1), which promptly turned up two ports that had bizarrely misused "install -d", showing again that in the ports tree, no good deed goes unpunished.