Recently in Darwin Category

So there was a little bitrot since my last packaging run in November, but I've finally managed to get a new KDE build done. If you're downloading in pieces, Qt and kdesupport have been updated too, so make sure you grab them as well as whatever else you're looking to install.

It looks like starting from the Finder works again, so my patches haven't totally rotted, and one big new thing is working -- input methods!

Unfortunately, SSL is still not happy, I've not had a chance to investigate yet. Otherwise, though, things are looking up. Please give them a shot and let me know if you run into any issues, and if you're willing to help out, join us on irc, in #kde-darwin on freenode.

For the first time since early 2005, a new major version of "fink" the command-line program is out. Plenty of good development work has gone on in the 0.24 series, with lots of nice incremental updates, but a lot of really great stuff has gone into 0.25. While there are plenty of other neat engine things and additions, I'm going to focus here on the changes that users will be able to see.

Internals

Speed

Most noticeable right away is speed. The incremental indexer was pretty much rewritten. You will not spend nearly as much time nowadays waiting for fink to scan your info files for changes.

A lot of other smaller operations related to the index have been sped up as well. All in all, fink is much faster. (Although I still would never call it "snappy"... <grin>)

Building

The buildlocks system has been rewritten, and should rarely get in your way anymore. It is much smarter about adding and removing build locks, and can clean up after itself much better.

Options

There are a number of new options for various things.

--log-output

Automatically log the output of package builds to a file. You can specify --logfile=/path/to/some/file to specify the location.

--maintainer

Enables "maintainer" mode, which does handy things for package maintainers, including automatic validation of both the info files and resultant deb files for any packages you're building, and enables some other miscellaneous things like turning build-time warnings into errors, and enabling tests if the package supports it.

--trees and --exclude-trees

When performing an action with fink, only use packages in the specified tree(s). For example, if you have unstable enabled, but wish to install the stable version, you can run "fink install --trees=stable mypackage". In addition, you can use the special-case trees "status" and "virtual" to refer to the dpkg database or fink virtual packages, respectively. The --exclude-trees flag does the same thing, only excludes specific trees.

Additionally, some existing fink command-line options have been upgraded or split off into separate programs.

dpkg-scanpackages

A convenience script to generate the apt Packages indexes so that local (or remote) clients can access locally-built binaries. This is invoked by the new automatic scanpackages feature.

fink cleanup

The fink cleanup command has gotten a much-needed overhaul. It's now capable of cleaning out old .deb files, source files, and the dpkg database.

Configuration

A few additions have been made to the fink.conf configuration file to make things easier on you.

AutoScanPackages

If this option is set to "true" (the default), then whenever fink has completed building new binaries, it will automatically update apt-get's indexes. Previously you had to run "fink scanpackages" to make your fink-built binaries available to apt.

Bzip2Path

You can specify the path to an alternate bzip2 command using this option. Normally you would use this if you want fink to use pbzip2 on a multiprocessor/multicore system to unpack archives. This will probably be expanded into a more generic configuration option for specifying system commands in the future.

NoAutoIndex

If you don't edit info files locally on your system, you can set NoAutoIndex to "true" and avoid the index scan when you run the fink command. You can still force fink to update the cache by running fink index (and you can force it to ignore the cache and create an entirely new index by running fink index --full).

ScanRestrictivePackages

If AutoScanPackages is "true" and you are planning on making your apt repository public, you must enable this option to avoid making legally-restricted packages available.

SkipPrompts

You can specify a number of classifications of prompts for fink to automatically accept the default. The currently available classifications are fetch (don't ask when a mirror fails, accept the default to try another/give up) and virtualdep (don't ask when fink has multiple packages that can satisfy a dependency, pick the default).

Conclusion

This has been a long time coming, and it's good to see it finally out the door. Please try it out, and let us know if you hit any snags. A ton of things have changed under the covers, and while plenty of us have been using it daily for quite some time, you always find new bugs when the general public tries things you haven't.

Happy finking!

So we've been working frantically to get Fink things up and running in a basic way on Leopard. I'm told that Fink HEAD now bootstraps cleanly, and we've been slowly working our way through smoke-testing building various things.

For the most part, it's been really smooth, compared to this time in the previous cycle. The Tiger WWDC preview was nearly unusable; it was enough to get a taste of things to come, but so much was broken at the system level that it was hard to get things working reliably. It took a number of seeds before we could really do much work on 10.4.

That's definitely not the case on Leopard. Other than a few minor buglets, stuff has been working remarkably well. I've probably only had to tweak maybe one in ten packages to get where I am, and those have been minor changes (mostly standard fixes related to POSIX compliance -- "#include <sys/types.h>" and such).

I've managed to get a decent amount of KDE/X11 built, and it seems to run just fine:

Woot!

It's funny how what should have been one of the greatest open-source PR moves since Netscape opened up the mozilla codebase instead feels like "too little, too late."

Apple has announced Mac OS Forge, a project to do what OpenDarwin was already essentially created to do. It comes on the heels of months of bad PR about Apple failing to put out the X86 kernel source, and OpenDarwin shutting down due to a lack of communication between Apple and the open-source community and a lack of community involvement in general (other than a few specific exceptions like dports and WebKit).

For a company that's done a great job of getting developers excited about their platform, this really shows they don't understand the community they're trying to get help from.

The most important thing you can give an open-source developer is the feeling that he's doing something with impact; that he's donating his time to something that others will appreciate and find useful. He wants to know that the work he's doing goes, maybe not into the public domain, but into a world where everyone can stand on each other's shoulders to make something good. And he wants to know that the work he does will be there in the future, for other people to stand on and take to the next level.

If, at any time during the last 6 months, Apple had said "we understand your concerns, we have some issues that we need to work out but we are committed to keeping things open" people would be jumping for joy to hear this announcement. Instead, so far as I've seen, the overwhelming response has been... WTF? There is nothing to be gained by hiding your open-source strategy. "Release early, release often" isn't a mantra just for the sake of having one.

Those of us doing open-source development on the mac are already aware that Apple has never been entirely open, and that they are especially secretive of upcoming announcements of any kind (and I salute those of you at Apple who I'm sure had to fight to make this happen at all) but it's a shame that Apple had to let things sink to such a low before doing their triumphant return. I'm sure there are many folks who will think twice before donating code to these projects, because in the back of their mind, they're thinking, "What happens if Apple drops support again? Will my code just bitrot?"

Remember, for a project to truly stand the test of time, it has to grow beyond the few people that created it and think of it as their "baby." You have to get the community involved and excited about your software. You have to get people who are not only users, but want to help out and make your project shine. Plenty of good software goes to waste because no one ever helps out, and the core developers stop needing to work on it, or move on to other things, and they have no one to pass the mantle to. Good software dies not because it was inferior, but because it didn't try hard enough to get people's desire to contribute.

I wish Mac OS Forge well -- more open-source software on the Mac can never be a bad thing; I hope they can prove me wrong and get a huge following and rival SourceForge in the variety and vitality of projects, but it was certainly given a poor place to start from. I hope, at the least, Apple has learned their lesson and will learn to work with the people that get excited about Mac OS X, and want to see it succeed, rather than punish them for their boosterism. Those boosters were the ones who put iBooks and PowerBooks into every alpha geek's hands 3 or 4 years ago to the present. Without them, you're relegated to the sidelines.

For now, I guess all we can do is wait and see...

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 updated my linux-based darwin cross-compiler/distcc suite; the packages should be a little more maintainable and are now separated into 10.3 and 10.4 packages. One thing to note, these packages will only work on 10.3 if you use the odcctools ld, 10.3's ld from Xcode does not understand the relocation entries created by the odcctools assembler and such.

I've built packages on CentOS 4 and Fedora Core 5, and I have access to a whitebox 3 system that I can build RHEL3-compatible packages on as well. If any of you have other systems that you've been able to get things to build on, please e-mail me.

So I've been working on getting a reasonable cross-compile of GCC from XCode 2.2.1 working on Linux so that I can distcc to my Linux boxes from my mac when doing long compiles (*cough*KDE*cough*). I've finally got something useful enough for myself that it's worth seeing if it works for anyone else.

So, uhh... check out my spiffy linux/darwin cross-compiler here!

I ended up making a little tool that automatically translates various gcc references into the canonical target name of that compiler, so it's safe to distcc to other oses (ie, instead of calling "gcc-4.0", it turns it into "powerpc-apple-darwin8-gcc-4.0"). This script is now part of my distcc package in unstable as of tonight.

Please, give it a shot, and let me know if you run into any issues. Happy compiling!

Yes, it's been quiet, but I assure you, I've been busy. Figured it's time to post an update as to what's going on.

• Mono

  I've got Mono 1.0.1 all put together, just need to do some final testing and put it out. Sorry, there still is no modern mono on 10.2-gcc3.3, it refuses to build and I haven't found a solution yet.

• KDE

  I got various builds of KDE 3.3 beta working, and it seems to have shaped up pretty well. KDE 3.3 is being uploaded right now and will go live very soon, I'm working on getting everything updated to KDE 3.3 final and I'll see if things will be ready for release... well... sometime. ;)

• PostgreSQL

  It looks like the major problems in the PostgreSQL packages have been ironed out now. I'm working on putting together a PostgreSQL 8.0 package, too, with the 8.0 beta.

• X.org X Server

  The new release of the X.org X Server is coming, and I'm going to work on packaging that up as well. I've got a package in my exp tree but haven't actually tried building it yet. ;)

I'll keep you updated, I'll be updating a bunch of stuff over the next few weeks.

It's a nice lazy Sunday afternoon. My roommate and I got a grill, we're cookin' up burgers, and it's a nice 66 degrees outside.

I've got an XFree86 4.4 package working, it seems to run really nice. It's pending inclusion in unstable after we decide how we want to handle the licensing issue. The main question now is, do we stand with the other distros in not releasing 4.4 packages so that XFree86 is more likely to unkink their licensing, or do we release anyways (since it seems like, at least, there isn't a conflict anymore)?

Also, I've basically got KDE 3.2.1 done now. I'm finishing up the test builds on 10.3, but I see no reason it won't be releasable to coincide with the tarball release from the KDE folks.

I've got my KDE/Mac toolset put back together and I'm through kdelibs in building everything again (including an update to Qt 3.3.1, I've gotta get packages put together and up on the KDE binary page).

Things are moving along in a generally forward direction, as mom would say. I'll keep you posted when I get new KDE/Mac binaries together and ready for perusal.

So it turns out this is why the Fink KDE 3.1.x packages haven't been building right on panther and 10.2 with gcc 3.3. It's a freakin' weird problem, I'm just glad I know what it is now. Removing the -isystem stuff from the build fixes it.

I'm working on 3.1.4 packages right now, it's due any day. I should be ready, now that I've gotten past kdebase.