|
|||||
|
I've finished getting everything set up so that you can run OpenNMS on Mandriva Linux. It is now possible to install using URPMI with a minimum of fuss.
I've gotta say, it's been a number of years since I've tried out So I've finally gotten a full KDE/Mac build done, and new snapshots are available. The kdeaddons package went away, and QCA is now part of kdesupport (since they've gone on and done new development that isn't compatible with current KDE trunk). I've done some spot-checking, and as always, things that are simple tend to work better -- most of the kdegames stuff looks great as always. Everything in KOffice is unfortunately failing with the error: 11/17/07 12:36:56 AM [0x0-0xb50b5].kspread[11258] ASSERT: "not isInitialized" in file /Users/ranger/cvs/kde-mac/source.build/koffice/libs/pigment/KoColorConversionSystem_p.h, line 70 I haven't yet figured out why it's happening yet, but expect an update once I do. Amarok actually runs and plays music, although it inexplicably loses it's menu bar completely, so there isn't much else you can do with it. I suspect it might be the splash screen stuff confusing Qt, but I'm not positive. BUT, the big news is that it actually works on Leopard too. 🙂 I've made an ugly patch that fixes the CoreFoundation fork/exec issue and I was able to open pretty much everything (well, everything that didn't crash for other reasons... <grin>). A few of the packages are still seeding from my 384kbit upstream system, so it might still be a little bit before they're all available, but please, as always, try them out, and post if you see any interesting issues. Share on FacebookOpenNMS 1.3.8 is out. The biggest change is that it runs on Windows, with a spiffy GUI installer, even. Well, technically the installer should work for any platform, but it was written to make installation easier on Windows, where there is no real package management. 😉 RPM and Debian packages are prepared as well, so everything should be good to go. There's plenty of other nice small changes in this release across the board; it's definitely clear that we're approaching ready to put out a stable release. Other than a few small features that we still want to implement, things are definitely looking really solid from a bug standpoint. (A sizeable percentage of our support customers are already running on the 1.3.x series, it's so much better than 1.2.) So if you haven't tried OpenNMS out yet, check it out, it's the best release yet! And feel free to drop by the discussion lists or irc if you have any issues. Share on FacebookI've got a new kdelibs release for Fink (kdelibs3-unified 3.5.8-1023) which fixes the issue with the ~/.DCOPserver file having sub-directories in it, and also with starting up KUniqueApplications which wanted to fork. Please test it out and let me know how it works, and I'll try to get it pushed to stable as soon as possible. If you're interested, the fix is to use _NSGetArgc() and _NSGetArgv() to pull out the arguments passed to the program, so that you can do a fork-and-exec afterwards (passing a flag to not fork the next time around). Share on FacebookJust wanted to give a quick update on a mix of Fink and Leopard issues.
First of all, if you get the error, " Also, people have been coming out of the woodwork hitting the OpenGL bug ("ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib") so I want to mention it here specifically for search engines to make it easier for people to find the fix. The fix is to add the following line to your linker command: -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib It should be a perfectly safe no-op on older Mac OS X releases, but makes sure that the XCode 3.0 linker doesn't get confused and try to be too smart about finding the correct libGL.dylib. I've also been trying to solve a new-on-leopard issue where they no longer allow CoreFoundation code to be called across a fork (presumably mach port messiness). The error is:
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on ...it seems to hit KUniqueApplications specifically. The fix is most likely to re-exec after kdeinit does it's thing, using execve() but I'm not entirely sure. I need to play around with it some more first. If anyone has any ideas, please let me know. 😉 Also, I updated fontconfig2-dev -- it's at 2.4.1 in 10.4 now, and no longer has conflicting configuration stuff that expects Apple's to be there. On 10.5, it's a dummy package that symlinks into the fontconfig 2.4.1 in /usr/X11, so there's no issues of conflicts on leopard. On an unrelated note, yes I am working on a new KDE/Mac snapshot, and have been making good progress on it. I'd say I'm probably 95% of the way through a full clean build working. Of course, KDE/Mac on Leopard has the same problem that KDE/X11 does, so whatever I solve in one will need to be ported to the other. Whee. I think that's it... If you have any questions, as always, let me know. I'm trying to work my way through everything, but there's lots of stuff to fix still. Share on FacebookSo I've spent the last week or so working on a Windows installer for OpenNMS, using IzPack, an awesome Java-based installer. After some trial-and-error getting it to handle paths nicely (some of our code is not spaces-in-paths clean, so I had to hack something up to get the DOS 8.3 filename), it seems to be working! We're going to spend some time testing it and making sure everything works well enough to be considered an "alpha", but this certainly appears to put us on track to have a nice installer working shortly after 1.3.8 is out -- which should be any day, there are only a couple of bugs left on the blocker list. ...and since IzPack is a Java-based installer, it actually works on Mac OS X and Linux as well, and in theory, anywhere else that supports Java 1.5... (Although it is still recommended you use native package management, since you'll get config-file management and other nice stuff...) Share on FacebookIf you've missed it, David posted to the Fink news that we have initial Leopard support. Thanks to apple keeping C++ binary compatibility this release (phew) it is most definitely the easiest upgrade yet! For most people, you can just do a "fink selfupdate-rsync" (or "fink selfupdate-cvs") to get the fink 0.27.7 tool, and it will automatically convert your fink installation to be Leopard-compatible. If you're doing a fresh fink install, you'll have to install XCode 3 off the Leopard DVD, and then bootstrap from the 0.27.7 tarball, but it's a very painless procedure. A binary installer is on the way. The best part is, increased POSIX compliance and better overall system headers in 10.4 has paid off in most Fink packages working out of the box on 10.5 (minus the stupid linker bug which apple did not fix in time for 10.5.0) and what's left will get updated as problems arise. The transition (as compared to the 10.3 -> 10.4 gcc-3.3 to gcc-4.0 move) has been considerably less painful. Since Leopard is still very new, and not many maintainers have had the chance to upgrade, if you find issues with packages (or missing packages) and wish to report a bug, please CC the fink-devel list for the next few weeks so we can find someone to help fix it, even if the maintainer can't test bugfixes yet. Share on FacebookLet me start with a story. It's a story of answering a simple question in the #fink irc channel. What was my answer? It doesn't really matter. What matters is that I used "..\lib" in my response. Why does it matter? OH GOD I JUST ACCIDENTALLY USED A BACKSLASH TO REPRESENT A PATH IN IRC! That's right, this week I've been in the Land Of Evil, working on porting OpenNMS to Windows. I've been so heads-down into it, I actually started thinking in backslashes even in a Mac OS X channel. Oh, the shame. <grin> Anyways, it actually (surprisingly!) mostly works. The hardest part was porting jicmp, which required setting up a mingw environment and fixing our configure stuff in a lot of ways. And I've gotta say, libtool and I have had our differences in the past, but it performed beautifully at hiding the details of making a .dll file out of our code. There's still plenty left to do. The docbook stuff doesn't run right. Our GWT maven plugin inexplicably fails, even though the command-line it generates actually works manually. It will be a lot of work putting together an installer. But overall, it was much less trouble than I had expected. Say what you will about Java, but out of our 250,000 lines of code, it took less than a week to go from 0 to proof-of-concept with code written entirely on UNIX-like systems. Woot! Share on FacebookI just released KDE 3.5.8 to Fink unstable. There are a ton of little bugfixes in this release, as well as a few Fink-specific changes, mostly related to Leopard-compatibility... (A newer CUPS and a workaround for a stupid linker bug that won't be fixed in time for 10.5.0.) As always, please let me know if you have any issues, or if it works for you. We're going to try to fast-track the update to stable so we're ready for Leopard. (Only 10 days to go!) Share on FacebookSure, it may seem quiet, but oh man, there's been a lot going on. First of all, a little off topic... Hockey season has started again. Go 'Canes! <grin> Second, as you might or might not be aware, a new kitty is coming to town soon. While David Morrison has done the majority of the work, I've been trying to help clean up some loose ends in getting things ready in Fink -- validator fixes, working around compiler issues, and other misc stuff. Third, I and a few other folks have been working on finally getting GNOME up to 2.20 (including GTK+ 2.12) in Fink, which is a metric TON of work. GTK+ 2.8 introduced a dependency on Pango's Cairo backend, which has to bubble up into build-time dependencies for literally hundreds of Fink packages. Through a combination of brute force and some automation, this is now to the point where it's time for brave users to help us find the kinks, test upgrades, and other fun stuff. Expect an announcement sometime this weekend with details. Fourth, I've been working on getting KDE4 moving again, including KDE4/X11, and starting to package KDE4 beta3 for Fink. This means Qt4/X11 and Qt4/Mac in Fink as well, which I've just gotten working. A little more testing and I'll put those out in unstable. As for KDE4 itself, I'm stymied at the moment by a bug in Strigi that is causing meinproc to fail, so I can't get through kdelibs, but vandenoever is aware of the issue and hopefully we'll get something worked out soon. Oh, and, I've started using Twitter. I'm still not entirely sure why, but it is fun. 🙂 Anyways, as always, busy busy! I'll try to keep things up-to-date here. Share on Facebook |
|||||
|
Copyright © 2024 Tales of the Raccoon Fink - All Rights Reserved |
|||||
Comments are closed 
