Looks like kdepim builds on kdelibs4 now!
I'm in the process of getting Qt/Mac 4.1.3 final (plus the KDE qt-copy patches) finished up for my binary packages, and then I'm going to start tooling up for trying out some more KDE/Mac stuff. It will take a little time to get all the DBus stuff sussed out on OSX.
At least there's something interesting to try out; perhaps I can get KMail running.
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.
There's been quite a bit going on since my last Fink status update. Here's what I've released since April 27th.
amaroK: I've rearranged the amaroK package (again), and updated it to 1.4. It's still got a wrapper package ("amarok") but now the core and the output engines are separate packages. Since the gstreamer engine was not deemed stable for the initial 1.4 release, the only engine that's packaged is the xine engine, but eventually, you will have the choice of 1 or more engines to install on top of the amaroK core without needing variants.
GNUPG: I updated gnupg to 1.4.3, as well as gnupg-idea, which was long overdue for an update.
GStreamer: I finally did a big overhaul of the GStreamer packages. There's now a wrapper package for all GStreamer 0.10 plugins (called "gst-plugins-0.10"), I've also finally finished up packaging gst-plugins-bad and gst-python. Also of note, gst-plugins-good-0.10 reintroduces the osxaudiosink, missing since 0.8, so you can get native audio again (instead of routing through the esound or SDL output plugins). The osxvideo sink is not quite as ready for primetime, so I've left it out still. Hopefully it's coming soon.
KDE: As I mentioned before, I finally got the KDE 3.5.2 release out, and have been going through bug reports. Things are looking pretty good now, only a few outstanding issues that only affect a small number of users. Expect a few more updates (and KOffice 1.5.1) soon, but for the most part it's looking good.
libgpod: New package for accessing an iPod, version 0.3.2.
liboil: updated to 0.3.8.
libtunepimp3: fix for building on 10.3
PerlQt (and libsmoke): No version change, but updated to be more friendly with possible porting of kdebindings.
various perl modules: Catalyst::Plugin::Authentication (0.07), Catalyst::Plugin::Authorization::Roles (0.04), Catalyst::Plugin::DefaultEnd (0.06), Catalyst (5.6902), Class::DBI::Loader (0.32), Class::DBI::Pg (0.08), Class::Inspector (1.16), Data::Visitor (0.05), DateTime::Format::Pg (0.11), DateTime::TimeZone (0.46), DBD::Pg (1.49), Digest (1.15), File::Copy::Recursive (0.22), Module::Install (0.62), Object::Signature (1.04), Rose::DateTime (0.522), Rose::DB::Object (0.726), Rose::DB (0.673), Test::MockObject (1.06), Test::use::ok (0.01), Text::Balanced (1.98), UNIVERSAL::can (1.12), UNIVERSAL::isa (0.06), XML::Dumper (0.81), XML::RSS (1.10)
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. :)
So 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 ) As of 2006-05-09 the developer CVS server had a disk-failure. As the new CVS infrastructure is in its final phases of rollout, we'll be deploying it, in place of the current infrastructure, by end of week. We'll be sending out an email to project administrators with further details later in the day, regarding how to access the new CVS servers and the changes that occurred with the new infrastructure.
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:
selfupdate-rsync 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.
Alexander 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!
For 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.
I'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!
So 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.
