January 2004 Archives

Unless showstopper bugs are found, the tarballs released to packagers will be KDE 3.2.0 final (feature plan). I'm taking a break from working on KDE/Mac stuff long enough to get final Fink packages put together. I've got up to kdebase built and I'll be continuing getting things cleaned up in preparation for release.

If I'm lucky, I'll be able to do a simultaneous release of the info files with the tarballs. If not, well, it won't be too much later. =)

So there's this big thread on the Apple SciTech list about Fink which seems to be complaining about a number of things that are either design features that people don't understand, or outright FUD about things that Fink supposedly breaks that has nothing to do with Fink.

For example, in this post, he says:

There's nothing wrong with linking against Fink libraries. If you want to include them in your own project, you can use install_name_tool to relocate the library for use in your own projects so that you don't need to work with the /sw directory yourself. The problem happens when you don't do this (e.g. Virex installing libs in /sw!). This is not Fink's problem, this is a problem with not understanding the Mac OS X development environment, and how library paths work on Darwin.

If you can't just move the libraries because the software you're using from Fink relies on other support files (config files and such), you can still take advantage of the porting work we've done by using our patches and building from source yourself. Our goal is to make it easier for people to run traditional UNIX software on the Mac. We understand that not everyone wants the full Fink infrastructure, which is why everything we do is available in "source" form, as a patch, and an info file that you can examine to see how the porting was done. No one is locking you into using Fink, Fink is a convenience.

There were also a number of posts about /usr/local. There are a couple of very good reason Fink (or any other 3rd-party project) should not use /usr/local:

1. /usr/local is in the default library and include search path. If you put something in /usr/local, you are damning anyone doing their own development on the system to linking against your stuff. GCC looks for things in /usr/local by default. If your project sticks something in /usr/local that it depends on, but never updates, people will find that down the road, something else has broken.
2. /usr/local is for the local system administrator. The only person who should be putting things in /usr/local is the person who runs the system. That way they know it's there, and if there are problems with it being in the default GCC path, they will know to fix them. 3rd-party projects traditionally belong in /opt. If I was part of the Fink project I'd have suggested putting it in /opt/fink instead of /sw as that is the proper place for 3rd-party packagers to put things. But I wasn't, and changing from /sw to /opt/fink now would break many systems, so I have no objections to leaving it as-is, the net result is the same.

The same general rules apply to working with frameworks. You should never put your framework in /System/Library/Frameworks, that's equivalent to writing stuff to /usr/lib -- it's reserved for Apple. If you make your own projects, put it in ~/Library/Frameworks, or, the equivalent to /usr/local for frameworks: /Library/Frameworks.

In this post, he refers to "GCC bugs" and problems with Virex that just don't make sense:

There are a number of things I think he could be referring to:

• The "GCC bug" he's referring to could be the fault of OpenOffice's (IMHO) horrible behavior of installing an old dlcompat into /usr/local that's incompatible with Panther. Panther now includes Pogma's dlcompat code in libSystem, and if you have old headers lying around it will cause problems. This is exactly why you should not ever install stuff in /usr/local as a 3rd-party packager.
• Another possible problem is if he's got a Fink that was built on 10.2 before we were Panther-aware; if he followed the upgrade instructions he would no longer have any stray dlcompat headers (if, in fact, that was the issue).
• Another possibility is he's referring to Fink's prebinding system. At one point, Fink's prebinding setup would add environment variables to force prebinding to everyone's shell if they use Fink. That was a bug (my bug, in fact), and has been fixed for months.
• The Virex problem is not Fink's problem, but Virex's. As mentioned earlier, instead of properly relocating the libraries they used from Fink into their bundle (using install_name_tool), they just unpacked software into /sw directly. There is no way I can even imagine of thinking this would be OK. /sw is a known directory for Fink stuff; if they knew enough to link against it, they should have known better than to overwrite it. This has since been fixed, and is, I believe, a non-issue.
• He could have even been referring to something else. We take compilation bugs (especially anything that breaks GCC, or working with software outside of Fink) very seriously. If I'd gotten an e-mail about broken GCC issues, I would have looked into it immediately. I don't recall any such message to our lists or bug reporter (granted, we get thousands of messages a month, perhaps I just missed it).

And this is the most obvious FUD, right here:

My earliest post about running Fink on Panther was early October. By late October things were generally working and shortly after that we had our first officially supported test release for 10.3. Support (and available packages) rapidly increased and we now have a binary distribution for 10.3-specific packages that fixes most of the issues encountered in the 0.6.x series on Mac OS X. Making the move to Panther was hard. Many things broke, and it meant splitting our time between 2 different systems, since this is the first time we've supported 2 different Mac OS X releases simultaneously. (When Jaguar came out, we immediately dropped 10.1 support.)

I've got no problems with legitimate concerns with Fink. We don't do everything perfectly. I do have problems with comments that can't be called anything other than FUD.

I'm at the TriLUG installfest and things are crazy! There's gotta be at least 50 or 60 people here; they had to go steal more tables and chairs from the room next door... I wish I'd remembered to bring my camera, I'd have taken some pictures.

Kudos to Wake Technical Community College for donating the space (and likely an immence draw of electricity =); it appears to be a rousing success...

So it turns out a lot of the launch problems we were having were not, in fact, caused by fork (although the fork can still cause issues). To set up KDEDIRS and PATH and such, we had been making the app bundle contain a shell script that calls the binaries, but behind the scenes, the shell script was still calling, say, /opt/kde/bin/kcmshell. Qt, however, can only figure out where it's at if it's called from inside an app bundle.

The fix was to make a hidden directory containing app bundles of everything, even things that aren't necessarily GUI apps, and putting that first in the path. This lets Qt find itself, and it has the happy side-effect that I can put a property file inside the bundle that makes those apps not show up in the dock (yay!).

So I'm in the process of uploading new binaries right now. I'll probably end up not having everything ready for download until tomorrow, since I'm getting about 40k/s and it's nearly a gig and a half of data. =) From here on out, I suspect the only thing we'll have to work on for a while is kdelibs, most everything is pretty stable except for problems that can be fixed in everything by fixing up kdelibs (key accelerators, etc.).

[Update:] All of the binaries have been uploaded and the WebDAV installer may work again on panther, since all of the pre/postflight scripts are gone. Give it a shot, and let me know if things are any better. (Hmm, like the eye doctor. Better? Or worse? Better? Or worse?)

There's also a torrent available containing all of the dmg files, although I can't say how long it will stay up (since the files change so often, it'll be pointless pretty soon... =)

So it may seem like things are pretty quiet, but actually a lot has been happening behind the scenes. Unfortunately, for now there's a lot of research that has to be done before noticable progress will happen.

1. I've been looking into how authentication and the keychain work. It seems that kdesu can be replaced with OSX's authorization framework. KWallet has a pretty nice-looking API that is abstract enough that it appears it should be relatively easy to reimplement the backend portion with calls to OSX's keychain.
2. Tanner has been looking into the mess that is KKey. It's currently a twisty maze of x11-specific stuff; it looks like it could be refactored into a very lightweight set of calls to Qt's key handling. *crosses fingers*
3. I've been doing more research into how KDE starts other programs, and their interaction, as well as talking with an Apple engineer on how to get around the issue where fork loses mach ports (and thus the GUI).
4. Benjamin Meyer (aka IceFox) has started a revolution in bringing up getting high-quality versions of the KDE icons for 3.2. He's also working on building as much as he can so he can show off our current status at LinuxWorld Expo.

All of this will eventually bear fruit but it makes it seem like nothing's really going on. I assure you, we're getting places. I'll let you know when something happens. =)

There's a whole bunch of new binaries on kde.opendarwin.org. A number of things wanting plugins don't work, I think it's because I caught kdelibs in the midst of an important update; I'm doing a new build to see if that helps.

[Update:] forgot to mention, the new binaries put stuff in /Applications/KDE instead. If you have one of the earlier packages that had it as a symlink, you may want to delete /Applications/KDE before installing all this stuff.

Also, the wiki has moved. The old one was pretty un-featureful. The new one's pretty spiffy.

If you didn't notice, there was the start of a new binary release up on the binary site.

Unfortunately, it looks like kdelibs has broken enough things that it's pretty much unusuable right now for anything reasonable complex (ie, kwrite works, that's about it...)

Guess I'll have to give kdelibs another shot tomorrow; I think I'm going to have to revert to the Jan. 6th patch and then make only a few changes from what I've done now. I'll keep you posted, there's a *lot* of great changes that you could be playing with if only I hadn't screwed up kdelibs. =)

There is now a stable release of JACK for Mac OS X. JACK is an audio system and low-latency audio server that was initially developed on Linux, and aims to be portable, well, everywhere.

Previously, there was an OSX port of JACK using PortAudio, but it was incomplete and you lose a lot of the low-latency advantages of JACK by going through an intermediary.

This is excellent news! A lot of very nice Linux audio apps used only JACK because it's basically the only pro-quality audio implementation there.

Since the initial slashdotting on the 30th, I've gotten over...

One... MILLION Hits.

Considering I got 2-3,000 a day before then, that's pretty insane.

But cool. =)

I just saw this on Slashdot, it's an incredible introduction to the history and many of the technical aspects of Mac OS X. It's an interesting read, and I suspect just about everyone will find something in it they didn't know before.

I got interviewed by EWeek yesterday. Seems like having KOffice somewhat working is making a lot of waves. =)

It's pretty good, although he got Fink confused (calling it "Think"). Not too big a deal, although our Fink PR dude will probably kill me.

Spiffy!

If you haven't noticed, I put some binaries up for KOffice. This should give people an idea of the kinds of things that are still broken, but it's suprising how much works. =)

IceFox also figured out a good way to manage the app bundles so that applications can come bundled with all of their resources (the things that would normally have gone into $KDEDIR/share/apps/<appname>).

That's not part of these binaries yet, but hopefully we'll figure out how to incorporate them into the build soon.

I figured out why things always froze the first time on starting any KDE/Mac apps.

We had originally disabled forking in KUniqueApplications because otherwise quartz wouldn't know how to find them. The problem is, some apps *need* to fork. So now, instead of #ifdef'ing it out, I've reenabled the --nofork option, and then changed our app-bundle-generating script to add the --nofork option to the little shell script we put in the bundle so that it runs properly from the finder.

Unfortunately, fix-osxbits.sh is sloooow, but hopefully we'll eventually have the build set up to generate application bundles during the install, and it won't be so bad.

IceFox is making good progress on the new .desktop -> .app conversion script, hopefully soon we can just start looking into integrating that into the KDE build system. I've gotta port my new fix-osxbits.sh changes to it first though.

We're definitely getting closer to something that's worth releasing to the general populace, though. It's not nearly as ugly as it was. Still plenty ugly though. =)

If you're interested in helping out and/or trying to compile it, I've started putting together binary packages of the base stuff you need to get going.

I've got nice installers for Qt, "kdesupport" (a mishmash of dependent libraries) and "kde mac tools" (configure-kde and fix-osxbits.sh). If you want to give them a shot, you can get them from this page. Hopefully I'll have something more official as far as getting binaries out eventually, I've asked about getting space on ftp.kde.org for distributing stuff as it stabilizes.

There's also a package of arts up there, it doesn't work (seems that mcop's a bit confused) but you can at least use it as a dependency for kdelibs to get things compiled. I'm not going to put up any binary packages for anything newer because they're still moving targets at this point. Once there's something reasonably useful (kdeinit respawn is fixed, etc.) I'll start looking at packaging up higher-level KDE bits and applications.

[Update:] OK, there's a new link now. Thanks to Dave Schroeder at the University of Wisconsin and Rob Braun from OpenDarwin for hosting the files, I think my bandwidth would go insanely out of control if I tried to put them here. I'm sure my server could handle it, but my wallet couldn't. =)

Bits of KOffice work now!

KPresenter has a couple of draw issues but looks great in the full-screen mode.

IceFox figured out the Qt/Mac theming issue (whooo!), and KOffice compiled insanely easy. The only real modification that needed to be done was replacing some x11-specific DPI references.

Happy New Year! <grin>

[Update:] I've been getting slashdotted and macslashed and osnews'd like crazy, and I see a lot of references to "Benjamin Reed has done such-and-such". While I appreciate the attention (and I certainly have done a lot of work on this), and my blog has generally been a focus for tracking what's happening, I'd like to point out that I'm not the only one that has made this happen...

Benjamin Meyer (IceFox) has been doing a lot of work on getthing things working too, and a number of other people have been helping out building stuff, not to mention I would never have gotten this far without tons of help on the Qt/X11 port that laid the groundwork. This is a group effort, so feel free to join in. =)