MacPorts bustage and trouble with 26

Floodgap was again down today because of a nasty winter storm that knocked the power out for almost twelve hours (the UPSes are, best case, good for maybe three). There was some hideous arcing early this morning but it doesn't look like there was any hardware damage. Unfortunately, the wind is still really howling outside and I hope we don't have a repeat episode tonight.

For 24.2.0 final, scheduled for 10 December, there will be a total of three tweaks on tap: increasing the garbage collection timeslice (as mentioned before), which should also help reduce memory usage by cleaning up more fully; again locking cores to one; and removing the blurred boxshadow from the video stand-alone document so that playback doesn't chug when the blur gets invalidated and must be redrawn. No other critical bugs have cropped up.

That's the good news. After this, it's all bad news. The port for 26 is running aground; JavaScript does not compile with either gcc 4.6.3, 4.6.4 or 4.8.2 due to a security patch of arguable utility. This patch does not compile when applied to 24 either, but we can back it out safely on 24 because no functionality actually relies on it, and there is some question over whether the problem it fixes is even exploitable. This isn't true for 26 because it may be an issue for generational garbage collection, which is imminent in Firefox, and code likely does depend on it. I am waiting for Mozilla's opinion since I'm not sure how to safely rewrite the code so that it compiles and is forward-proofed.

Oh, but before I could do that, trying to install gcc 4.8.2 caused MacPorts to try to rebuild Perl 5.12, which failed (even though I already had it on the system) due to a linker problem with Xcode 2.5. Forcing the install caused it to fail building cloog due to bad isl headers. Upgrading isl manually enabled it to complete and then I could build the other prerequisites and told it to ignore the Perl one, and finally I successfully built gcc 4.8.2 ... which then broke gcc 4.6.3 because of the new compiler libraries. One rebuild, a lot of cold sweat and about 24 hours later, the toolchain is working again and I'm crosschecking the libraries to make sure. As a result, we're on gcc 4.6.4 but 4.6.3 will still be supported, since it was known to work. All this to say that you should be very careful about MacPorts updates right now -- it is doubtful anyone is routinely testing port changes, let alone new ports, against 10.4 or 10.5 and several ports are already demonstrably busted. I need to backup /opt and then I'll try to submit fixes to the portfiles for 10.4 as I have copious spare time. It may be worth our while to generate a binary set of the toolchain components that can be installed separately to guard against this, since it will almost certainly happen again in the future.

I have a low threshold for not advancing to 26 even if it works, mostly because I don't want to be dropping source parity on a non-ESR release so close to an existing ESR branch, and because some of the stuff for Australis that is landing now is alarming and may not even be workable for 10.5, let alone 10.4, which may force our hand anyway. (But hey, I predicted our demise for Firefox 5, 10 and 19, and we made it through all of those releases; still, we've existed much longer than we've had a right to.) I'll make that decision based on what changes I have to make to get 26 to work. If these changes are unacceptable or impossible (or I can't figure out what to do in time), or the resulting product is iffy, then we stay on 24 and we go to feature parity. I'll decide this after 24.2.0 comes out.