By RangerRick, on September 25th, 2006
I set off a new unattended build last night and had packages in the morning, so it looks like KDE trunk is still pretty mac-friendly at this point. 😉 The new torrents are on the new wikified KDE/Mac page and seeded. Please give them a shot and let me know.
I haven't had a chance to look into the D-Bus <--> launchd integration, and it's unlikely I will in the immediate future, but in the meantime, this should give you any of the updates that have gone on in trunk since the last snapshot.
After having looked at the CoreFoundation APIs for reading plists, I feel vastly unqualified for trying to read/write ~/.MacOSX/environment.plist in the D-Bus code, so if anyone with real C experience is interested in giving it a shot, take a look at Thiago's pending D-Bus autolaunch patch which adds support for autodiscovery of the D-Bus bus address if you're logged in to an X11 session. It should be pretty easy to adapt that to work with setting the values in ~/.MacOSX/environment.plist (and eventually launchd).
Share on Facebook
By RangerRick, on September 17th, 2006
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!
Share on Facebook
By RangerRick, on September 3rd, 2006
So I actually wrote some C++ code this weekend. Those of you who know me know that I have done a lot of hacking on other people's code, but have written very little C++ myself. (I do a lot of perl and java professionally.) I've gotta say, though, Qt is pretty darn easy to work with. I managed to replace the crazy dock icon stuff that Sam Magnuson had put into the original KDE3/Mac work with QSystemTrayIcon (new in Qt 4.2), and I also worked around the bug where apps don't exit properly.
I also made an ugly hack to set up the DBUS session environment and add /opt/kde4*/bin to the path. I still need to work out a nice/sane way to do this, but for now, it at least lets you start stuff from the Finder. (Yay!)
Next up is to find out why HTTPS is broken in konqueror (and presumably elsewhere).
In the meantime, check out the new packages for all of these updates, and let me know how things work for you.
Share on Facebook
By RangerRick, on August 31st, 2006
If you haven't noticed, I've updated the KDE/Mac binaries to a build I kicked off this morning.
The WebDAV was neat, but it seems those long-running DAV process booger up file locking on the web server, so I've had to disable it. However, I have added KOffice and kdegames to the mix. (Although a lot of things don't work very well, especially in KOffice.) I've also made a .dmg with "everything" if you want to just download the whole dang thing.
Oh, and I've also fixed the endianness issues so that PNGs aren't all purple anymore, so Konqueror looks normal again on PPC machines. 🙂
We've even gotten a few extra folks hanging out in IRC now, and folks with some interest in helping out porting, so stop by #kde-darwin on FreeNode and say "hi."
Share on Facebook
By RangerRick, on August 27th, 2006
So I've finally gotten things pretty much set up for autobuilding KDE4/Mac packages. Universal packages for 10.4 are available here and I'm working on getting 10.3 packages put together as well. I'm still setting off the build process manually for now so I can watch it, but assuming things work out, they should start updating nightly sometime in the next few days. (Well... Assuming everything builds, of course.)
I've noticed there are some endianness issues with the png code, I need to figure out if it's in libpng or somewhere higher up, but other than that, I was able to actually open Konqueror and browse around. Things are a little more stable than my last report a few months ago, so it looks like kde is moving in a generally forward direction. 🙂
If you have any questions, comments, whatever, please e-mail me or visit us on IRC.
Share on Facebook
By RangerRick, on August 15th, 2006
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!
Share on Facebook
By RangerRick, on August 9th, 2006
I finally got around to switching my blog over to point to RacoonFink.com, instead of ranger.befunk.com/blog. I've had the domain for some time (and have been using it for Fink e-mail) but had never gotten to updating the blog links.
Unfortunately, I noticed too late that it made RSS readers see everything as new. Please excuse the spamming, it won't happen again. 🙂
Share on Facebook
By RangerRick, on August 7th, 2006
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...
Share on Facebook
By RangerRick, on August 5th, 2006
There are quite a few updates since my last big post. Most notable are getting mono up-to-date (although monodevelop still doesn't work), Ruby on Rails, and kde 3.5.4 (as of this post, it's 10.4-only, my 10.3 build machine is still chugging through doing a final verification build, but it should be out in the next day or two).
Share on Facebook
By RangerRick, on July 31st, 2006
So this last week I was at OSCON. I met a lot of awesome people, some of whom I'd met online and finally got to see in person. I also learned a ton about a lot of things, but really, The Buzz® was Rails, Rails, Rails.
I've played with Ruby on Rails off and on for a few months, and I was very impressed, but I learned a new appreciation for it at OSCON. There were a ton of good training classes and experts able to explain the stuff that up until now I'd been using without really knowing what it means... (which is common if you've just picked up the 15-minute demo and thought "man, that's cool, I want to try it!")
Of course, I hate having anything installed on my system without it being package-managed, so I went ahead and packaged up everything up to Rails as well as a few extras -- Streamlined (a featureful replacement for the scaffold that was just announced at OSCON), and ferret (a port of the excellent Lucene search engine to Ruby).
It's dead easy to package up gems in Fink, so if there's anything that makes Rails easier for you that's missing, please let me know and I'll try packaging it.
Share on Facebook
|
|
|
