KDE 3.4.1 in progress

Yes, yes, I know I keep saying I'm going to move KDE to stable. I'm in the process of getting KDE 3.4.1 built and released, and we'll see about it then.
Even if it doesn't make the bindist, I will build binaries so they will be available post-bindist, so hopefully things will be available soon.

Share on Facebook

13 comments to KDE 3.4.1 in progress

  • kangaroo

    argh i cant get fink or kde or anything to work AT ALL whenever i install fink (through the terminal) it gets an error compiling gettext
    im running 10.4.1 is fink even supposed to work on this? i have xcode 2 and bsd subsystem installed, and also xdarwin, but i think i pretty much screwed that up completely in my efforts to get kde to work. i installed kde with the kdedarwin thing and whenever i run startkde it says error opening ksmserver, which the damn installer didnt even install so its pretty much useless, so i tried going with the fink install method and here i am. i hope someone can help me

  • kangaroo

    hmm maybe its because im using fink commander… is fink commander a bad idea for tiger?

  • Well, gettext is not my package, just because KDE depends on it, doesn’t mean I have anything to do with it. Post to the fink lists, that’s the proper place for bug reports anyways.
    As for Fink Commander, I don’t use it, and it’s essentially unmaintained, so I would say in general, if you’re comfortable with the command-line, don’t use it. 🙂

  • kangaroo

    ok thanks ill try posting there

  • Not that this is deeply relevant, but I went ahead and upgraded to 10.4+KMail from KDE 3.4.1 w/o waiting for binary packages. It’s not anything I’d recommend to friends. Here’s my brief account:

  • Well, to answer some of your complaints:
    > Programs installed via Fink no longer work
    > (expected) and the upgrade instructions boil
    > down to “reinstall fink!”.
    The upgrade instructions *right now* boil down to reinstall fink. It takes time to get everything working with a new OS. If you want to be on the bleeding edge, you live with reinstalling (or doing some trickery to upgrade). If you want everything to be happy and supported, you wait a month or two for there to be a bindist.
    > Flip back to the desktop that Fink is on some
    > hours later only to find that it has, again,
    > crapped out with some message about getting
    > confused about building multiple packages
    > at once. What kind of 2-bit software is this,
    > anyway?
    Take some graph theory and come back and ask that question. Tracking dependencies is *hard*. There is some code in Fink CVS that alleviates this, but it has it’s own problems, hopefully to be fixed soon. In the meantime, the worst that happens is you restart a build. Whooptee-do. You didn’t lose all the stuff you built, it just paused.
    > Come back, laptop has suffered a kernel panic!
    > Brilliant! (this is a really, really bad thing)
    I’m sure you know this, but this is not Fink’s fault. Probably just ’cause tiger’s still not terribly stable compared to 10.3.
    > Aside: why in the fuck do I need OpenMotif and
    > TCL/TK for a KDE app anyway?
    You need it for things that KDE depends on. None of the KDE packages depend on it directly. You’d have to ask the people whose packages I depend on. Most likely it’s something like xscreensaver (kde can use xscreensaver xscreensavers) which in turn has an admin app written in motif. (I think). Sorry, I guess we should make our software use the least features.
    > After a bit googling it turns out that all of
    > the environment variables that were required
    > to run KDE apps on previous versions of Fink
    > should now NOT be provided, and in fact, I’m
    > apparently doing something “dumb” by setting
    > them. Right. Some .bashrc fiddling, X11
    > restarting, and various other config twiddling
    > and things actually run! (albeit slowly, since
    > apparently everything is built in debug mode).
    Well, if you have details on these changes, I would appreciate knowing what they are, so I can document them so it’s not necessary to google.
    Also, KDE’s not built in debug mode, but it’ll never be *fast* on OSX because KDE’s “everything is a loadable module” architecture does not jive well with OSX’s “holy crap loading modules is slow” architecture. Not much I can do about that, though it’s gotten a *lot* faster than it used to be.
    In my experience, startup is a bitch, but once started, KDE apps run just fine speed-wise.
    > It seems the only thing slower than building KDE
    > from source on OS X is convincing the Fink
    > developers to put new versions of it into
    > stable. Frankly, they must not actually use this
    > stuff. That’s the only rational explanation I
    > can come up with.
    It’s not “fink developers”, it’s entirely my decision as the maintainer. I’ve been holding off pushing it to stable because of a number of showstopper bugs. As of the kde 3.4.0 packages, I believe I’ve got a handle on everything, and I’m gonna be pushing stuff to stable after I can set up a fresh system to test stable with.
    > If they DID use it, there would be a system that
    > allowed the first person to build something in
    > unstable to be able to upload it to some kind
    > of “build cache” that you could optionally use
    > as an apt source. Binaries could be vetted
    > through checksum acclimation (non-matching
    > checksums would boot versions from the cache).
    > The current situation is an unmitigated
    > disaster. I’m using OS X precisely because I
    > never want to see another “emerge” or “make
    > world” on my desktop box. I’ve got better
    > things to do with my life. Why don’t the Fink
    > developers get that?
    Yes, I’m sorry, I didn’t realize how easy it was to make a distributed mass-build system where we can implicitly trust packages built by random people for upload to the fink binary dist. Thanks! I’ll set it up and have it ready for you this evening.
    Really, it’s not simple setting up such a thing. We *want* to do it, but we’re volunteers, and no one has had the time to devote to setting up such a system (and believe me, it would be a lot of time).
    I’m not happy to get constructive criticism mixed with attitude (but hey, it’s your blog), but I can tell you that we’re aware of, and fixing, many of these issues; the biggest issue is that you can’t have your cake and eat it too. You can get a binary dist, or you can get bleeding edge stuff. You can’t have both. You *will* be able to get things fast, but we’re still in the process of making the frigging bindist. We don’t get the final version of Tiger any faster than you do. We can test all we want on ADC prereleases, but that’s not trustworthy enough to build the bindist on, things change between the seeds and GM.

  • Hey,
    So yeah, a lot of this is completely out of the hands of Fink (i.e., the kernel panic). I wrote the post because I was frustrated. That said, I’m going to be handing the .debs over to a friend on CD today so that he doesn’t have to go through all of this.
    Previous, in my kmail/konsole/knoqueror invocations, I had something like:
    alias kmail=”DYLD_LIBRARY_PATH=/sw/lib kmail”
    My memory is a bit hazy here, but IIRC it was required in the past because of some sort of native (aqua) QT library interactions. It now appears that the DYLD path is un-necessaray.
    As for asynchronous dependency satisfaction, I’m very familiar with the problem (one of the tools I work on has to do just this). Yes, it’s a bitch, yes doing cycle breaking is non-trivial, but how hard would a “retry until you cycle X times” option be? I’d gladly set that to 3 if it meant that the box could keep working while I slept. Anyway, the point that I can just come back and restart it is a bit specious when you consider that I would like to kick off a time-intensive build before I get some sleep and won’t necessarily be there to babysit the thing the whole time.
    I also get why you need Motif et. al., but it does really start to grate on you about the 36th hour. I also know that a distributed build system isn’t trivial. But look at this from the point of view of a user: I’d be happy to run a “verify” build on some portion of the source tree in order to verify reputation if it means that I can get 90% of a package’s dependencies for “free”. Even as a security geek, I’m willing to take that bet. Esp if gpg integration for binary signing were an implicit part of it. It’s just a suggestion, and by no means fully fleshed out. But the current situation is pretty untenable.
    That said, I like Fink and Kmail enough to have built all this gunk. That, at least, is testament to how much better Fink/KMail are than Mail.app and Thunderbird.
    I’ve said thank you for your hard work on KDE before, and I’ll say it again. Thank you.

  • Itai Seggev

    I can’t install arts. Fink install arts
    terminates with
    “This package requires pkg-config”
    The weird thing is that PKG_CONFIG_PATH is correctly set (or at least written to stdout 🙂 at the start of the extraction process. Help!

  • eddie

    generic encouragement on moving 3.4.1 to stable.

  • addythegeek

    where can i just get an installer for koffice or just kpresent? all this junk with 15,000,000 different files is annoying.

  • Not sure I know what you mean. You can install koffice or kpresenter (and their dependencies) without installing all of bundle-kde.
    It will still need to install the dependencies. Hence the name, *depend*encies.

  • Andre

    Hej RangerRick!
    Thanks for your massive work on KDE! Any progress on KDE 3.4.1 on Mac OS X? Would like to have Kontact running on my MacMini 🙂

  • vniow

    Hi, I’m not sure where else to post this since I can’t see any other method of contact (I’m probably just blind) but…
    I was trying to install KDE natively per the instructions on this site (http://wiki.befunk.com/tiki-index.php?page=Building+KDE+Yourself) but I can’t seem to connect to the svn server, I can do it from the web client but not the Terminal. I’d rather try to install KDE natively but I’m not sure how else to do it.