I've got the first release of my prebinding bits working now, it's a combination of a patch to fink's perl modules and a couple of packages that implement the post-processing.
I've got a few people trying them out, when I'm confident they're at least not breaking anything, I'll make a bigger announcement to the list.
The nice thing about doing things this way is that it's pretty much all transparent for any package that makes twolevel libraries.
Yay!
I got Darwin/x86 set up on my PC a couple of days ago, and I've been a building fool since then. KDE works from dports, and I'm in the process of getting the fink packages happy as well.
Some details here, in my post to the KDE-Darwin list.
There's a discussion going on over at OSNews about how the OSS community needs to start focusing on the users. I think that's true, but he's got it backwards. He talks about the developer's responsibility, but the open-source developer has no responsibility except to himself. It's the user who has a responsibility to join the community.
I do this because I like doing it. I do it because, like any good hobby, I can do something, and then sit back and look at what I've done, and be content, knowing I've made things better in some small way. Users do not beget open-source software, open-source software begets users. The fact that OSS is useful to "regular" users is great, and it's certainly no small part in that happiness I mentioned. It's wonderful to get an e-mail from a happy user who likes the results of your hard work. However, that is not the goal -- it is a side-effect.
It's important to note, developers doing something for their own needs does not preclude things that have traditionally been ignored in the developer community. The Fink project that I work on has some of the best documentation I've seen in an open-source project. Since our target audience is MacOS X users who traditionally have no UNIX (or even command-line) experience, we have a lot of documentation for things that are traditionally glossed-over in open-source projects. Despite document-writing being a typically thankless job, it's heartening to be able to say that; and that feeling makes it a little bit easier the next time it's time to sit down and document something.
Anyways, I digress. I think this anonymous post sums it up pretty nicely:
I didn't write it because I have an overriding urge to 'implement all the current standards relating to customer feedback processes' I wrote it because I wanted a tool and didn't have a suitable one to hand.
If you're a user, don't, by any stretch, think your views are unimportant, or that users don't mean anything to open-source developers; there are few things nicer than a "great job!" from a user on a discussion list. But don't assume you run the show, either. :)
So I've been spending the last week trying to make prebinding happen in Fink. I've gone through a couple of stages in investigating things, and I've found a number of ways to do it that are inefficient, but none of them seem to be very elegant. I've got a couple of ADC support requests left, so I sent this to Apple:
The Problem:
Currently Fink is entirely un-prebound. I've been spending a couple of weeks trying to determine how to make prebinding Fink possible (given the large number of binaries to manage, and how often they are changed). I'm trying to figure out the minimum amount of work that packagers have to do to make prebinding possible, and what will be needed to be changed in the Fink tools to handle the backend. Unfortunately, prebinding on the scale that we're trying to accomplish is largely undocumented.
My first attempt at prebinding involved taking a list of dylibs from Fink and putting them in a file, and running seg_addr_table from cctools on it. Then I would have Fink set:
LD_SEG_ADDR_TABLE=/sw/fink/dists/seg_addr_table
LD_PREBIND=1
LD_PREBIND_ALLOW_OVERLAP=1
This way, anything that's already properly built twolevel will get built prebound.
Unfortunately, managing this seg_addr_table globally for all Fink users would be incredibly difficult.
My 2nd thought was locally generating the seg_addr_table, based on the installed packages. The biggest issue then is managing when segments change.
Then, in reading the documentation, it seems as if update_prebinding should handle everything for me, but in my testing it appears that is not the case. What I was hoping is:
sudo update_prebinding -root /
...would make new segments, and update everything for me. However, I tried the following, and didn't get what I expected:
sudo update_prebinding -root /
fink rebuild dlcompat (this makes a libdl.dylib that's prebound
to 0x00000000 again)
sudo update_prebinding -root /
I would have expected that this would find an empty address, and fix anything prebound against libdl to point to that new address. Instead I end up with the segment still set to 0x00000000.
So my question is, what do I need to do to fill in the missing piece of getting the right segments for update_prebinding? Are we still going to have to generate our own seg_addr_table? If so, it seems that we'd end up having to re-implement update_prebinding's mach-o prebound object-scanning, which seems a bit silly. What is the best way to go about doing this?
Apparently Clutter can now add artwork to songs in iTunes... yay!
I should have been in bed, instead of reading this.
00:33 <keetz> why doesnt darwins df have the human readable flag
00:34 <landonf> keetz: we don't believe in humans
00:34 <kevinvv> keetz, humans don't use darwin
It appears my writer's block is definitely over, I wrote another song. You can get it from my music page, it's called "Stowe". The Impulse Tracker module is available as well, but it's interesting only for technical reasons, the MP3 has post-processing and effects that aren't available in the IT file.
Comments are always welcome, let me know what you think.
I've got the cleanup of all of the KDE packages complete, including all of the packages in my experimental tree (not counting the "notready" directory). Deps are, as far as I'm aware, correct; docs are properly generated; everything seems peachy. KOffice 1.3beta and KDevelop 3.0a4a are both working properly. All is well on the KDE front. ;)
There were a couple of critical bugs fixed recently in the 3.1 branch, so 3.1.2 is delayed a short period again. I'm importing them (kdebase and kdesdk) into the KDE-Darwin tree and I'll be doing another build, but I don't anticipate issues, they're small differences. Bring it on!
Looks like I've got a handle on the build problems I was having. I'll have new packages updated and in experimental soon, and then I'll put them out along with the KDE 3.1.2 release which is due (hopefully) early this week.
Pictures are online! Be the first on your block to marvel at the iMac of Doom!
I've got 3.1.2 built now. Only took minor tweaks, and I did a little cleaning up of the packages as well.
I'm going to be doing an audit of all of the dependencies, and then I'll be set for when 3.1.2 is released officially.
I'm home sick today... woke up and it felt like someone had given my throat a once-over with sandpaper. Thankfully, NyQuil came to the rescue. =)
I'm feeling a little better now, but still under the weather. I'm kicking off CVS imports of the tentative KDE 3.1.2 packages between naps, hopefully I'll have them ready pretty soon. 3.1.2 is due for release next week.
Well, after a weekend of no TV and lots of setting up of software, I finally managed to write a new song. Please let me know what you think, it feels good to be writing something again.
With drm's help, I've cleaned up some of the package dependencies for KDE, and it looks like everything is set now. The bindist has been updated with 3.1.1 for those who do an apt-get update, so you no longer need to build KDE 3.1.1.
KOffice and KDevelop still aren't working right yet, I'm not sure when I'll have a chance to look at it, but pogma thinks he may have some libtool fixes that will affect it.
On a personal note, I finally bit the bullet and spent all of yesterday and half of today putting Windows 98se (ugh) back on my PC so I can run Impulse Tracker. Here's to hoping it won't be necessary for much longer.
