I've released Fink packages for the recent PostgreSQL security update -- they are available in unstable in the 10.3, 10.4-transitional, and 10.4 trees.
Share on Facebook
|
|||||
|
There's been quite a bit going on since my last Fink status update. Here's what I've released since April 27th.
Looks like I'm lucky enough to have work send me to OSCON this year, in Portland, OR! (Yay!) If you want to hang out, please drop me a line, it'd be cool to put some faces to names. And if you're a SourceForge person and want to kill me now, well, I'll be there for you too. 🙂 Share on FacebookSo I used to think the folks at SourceForge were just overworked and under-appreciated. They've worked really hard recently to show me this is not the case. Sure, it's a "free" service, but it's there to sell their premium services, and they get a lot of exposure being the place to go for open-source development. They've been having growing pains for a while; a few months ago, they had a major CVS outage. Open-source development the world around ground to a standstill for days while they worked to get hardware up. Since then, they've been planning on transitioning folks to subversion, and to a new CVS infrastructure. Did I mention that in the meantime, the anonymous CVS has been frozen and out-of-date since March? This outage was only "repaired" for developers; user access has been broken all this time. Since then, we've been planning on moving to our own server (donated by xs4all). As you've seen in previous posts, I've made progress towards that end. In the meantime, our expectation was to get in on the "new CVS" beta. We've been preparing versions of Fink that can "phone home" to figure out what the CVS repository should be, so we'd be prepared for when the switch came. 2 days ago, another CVS outage occurred. After a day of waiting without the site status page being updated, I opened 1 of (I think) hundreds of open unanswered bugs about CVS being down, making note that they should at least update the site status, so people would stop opening bugs. I went to the #sourceforge channel on IRC and asked about it, and they said there were network driver problems. They got it fixed, and CVS was back up, for, literally, 30 seconds. It turns out that machine also had a hard drive out. After being told it would be up once the hard drive was replaced, I wandered off to nap some more. I'd been out sick for 2 days and was really hoping to commit the culmination of 2 weeks of work on KDE fixes for outstanding issues that were (and are) affecting nearly all Fink KDE users. I had made the last few changes while I was at home, sick, and could finally commit and get back to sleep. Hours pass, and I finally ask, "I hate to keep bugging you guys, but it seems the site status never gets updated during outages like this. Were there problems putting in new drives? Is there something else keeping our cvs from coming back up?" The response: "I'll update site status tomorrow with details, I don't have full details at the moment, but I do know it will be down over night, at minimum." Understandable, things happen. But the fact that the site status page wasn't the first thing updated as soon as a problem was found shows me how much they care about their users. You can save a lot of ill will by just telling people what's going on. Today, the site status gets updated:
( 2006-05-10 04:43:14 - Project CVS Service ) So one thing to note. Anonymous CVS for the new servers is at a new CVSROOT. Everyone that wants to access the new CVS repository will need to check out fresh, or manually munge their CVS/Root files. This is the eventuality we were going to handle gracefully, which is now impossible. Additionally, shell access to the project servers (ie, the way we log in to modify pages on http://fink.sourceforge.net/) is down, so basically:
This is intensely frustrating. It would be one thing if it were just hardware and server issues. These things happen. But the total lack of disaster planning and managing of user resources (and user expectations) is just abysmal. The timing makes it all that much worse, since we were literally prepared to finally move away from SourceForge's spotty service in the next few weeks (or, at the very least, months). But don't worry, SourceForge, we'll be reducing your server load just as soon as we're able. You can count on a little less load in the future. Share on FacebookAlexander K. Hansen, Fink documentation guru extraordinaire, is having to move on from his current job at MIT and has to give all his mac hardware back. He's one of the most helpful people on the lists and on IRC, and it would be a shame to lose him, even for a little while. If you can give anything at all to help him get up and running on some new hardware, please donate here! Whether this works or not, thanks AKH, for all of your hard work! Share on FacebookFor the most part, the x86 transition has been really smooth. Only minor changes needed here or there to make things work. But there are a couple of places where it's clear they didn't spend much time looking at their infrastructure. Assembly is one of them. I can't imagine they didn't think "Well, there's all this linux x86 code out there that's gonna suddenly be enabled when people start building things. Perhaps we should make sure stuff works." but apparently they didn't. 🙂 There are some obvious things, like Apple's gas being very old and heavily modified, that should have set off warning signals. For example, Apple's gas has no ".balign" keyword. Instead, it has ".align". So if you used to use ".balign 16" you now use ".align 4". Similarly, ".balign 8" becomes ".align 3". Also, apparently the AT&T-style ".rept" and ".endr" are not supported, even though they work everywhere else. So now this: __asm__ __volatile__ ( ".rept 8 \n\t" "(something) \n\t" ".endr \n\t" ); ...becomes... __asm__ __volatile__ ( "(something) \n\t" "(something) \n\t" "(something) \n\t" "(something) \n\t" "(something) \n\t" "(something) \n\t" "(something) \n\t" "(something) \n\t" ); How convenient! I can only hope the tools will get better, this is their first XCode release to a wide audience on the x86 platform, so some surprises were bound to happen, but it's a bit silly that they didn't try to build large, well-known, asm-using projects like mplayer to see what happens. Share on FacebookI've put up a new release of the universal Qt installer, based on the 4.1.3 20060503 snapshot. Qt-copy has moved to a 4.1.3 snapshot as well, so I figured I'd do that, at least, to keep up. I've also been working on getting the KDE CMake stuff capable of doing universal binaries, but I've run into some strange issues with linking stuff mixed inside and outside of the /Developer/SDKs directories (even though everything I'm linking to should be universal). If anyone knows more about how that stuff works, please let me know. 🙂 On a related note, recently, Jos Boumans at xs4all got together a donated system for Fink, and I've been working on getting everything set up. We're going to be working on moving services there as much as possible over the next weeks, to get away from SourceForge's spotty performance. I've got LDAP and mail set up, and am working on bring other things up as time permits. Thanks for the hosting, Jos! Share on FacebookSo I've put universal Qt4 and "kdesupport" (for lack of a better term) packages up on kde.opendarwin.org now, in preparation for an attempt to start building (universal) KDE4 binary snapshots from the nightly and continuous builds of kdelibs. They install to /opt/qt4 and /opt/kde4-deps respectively. This makes it even easier to start building the base of KDE/Mac and helping out in the porting effort. Feel free to hop in and starting trying to get it to build for yourself. The more the merrier! Update: I've also made a package for CMake as well now, you can get it at the KDE/Mac site too. Share on FacebookI've released KDE 3.5.2 to the Fink 10.4 and 10.4-transitional trees. 10.3 is forthcoming, when I get my 10.3 test box back up. 🙂 The biggest changes are:
There are too many changes to list everything, see the KDE 3.5.2 and KOffice 1.5 pages for more info. Share on FacebookWhile it's not officially supported, and can cause breakage when building certain packages, it's possible to use distcc with Fink if you're careful. I finally got around to documenting setting MAKEFLAGS in Fink on the wiki. Heed the warnings, but for the most part it works pretty smoothly. Also, I'm in the process of starting down the road of updating kde.opendarwin.org now that there's some decent progress on KDE/Mac. I'm making Installer.app packages of universal Qt and "kdesupport" (the tarball documented on the Building KDE/Mac from Source wiki page.) There won't be universal kdelibs and stuff until I figure out how to get such integrated into the cmake build, but in the meantime, it will save some folks some building, and set the groundwork for getting some real snapshot stuff packaged up nicely. Share on Facebook |
|||||
|
Copyright © 2024 Tales of the Raccoon Fink - All Rights Reserved |
|||||
Comments are closed 