OpenNMS 1.3.9 has been released. It's mostly a few small bug fixes and features, but it does fix a rather important deadlock in the database code that could cause notifications to not go out correctly (among other things).
Other than that, we've been pow-wowing on what to do for the next release -- there's a bunch of niggly little bugs that need to be cleaned up, but overall, the trunk codebase is still looking solid.
We've finally gotten the OpenNMS image for VMware put together and uploaded to SourceForge, with OpenNMS 1.3.8 on it. It hasn't been updated since the 1.3.3 VMware image was put together.
Since I'd been having such good luck with Mandriva, and as Tarus mentioned, they've been very supportive of us in general, I went ahead and made the image using Mandriva 2008.0. It has the advantage of being quite a bit smaller than our previous CentOS-based image (about 400MB compressed) and is a very minimal install with just the minimum needed to get OpenNMS up and running.
So if you were wanting to try OpenNMS out but didn't really have anywhere to run it, why not download the image from SourceForge and give it a shot? All you need is the free VMware player; just follow the README file inside the package and you should be off and running.
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 Mandrake Mandriva, and it's definitely grown from just a KDE-themed RedHat into a pretty sweet and polished Linux distribution.
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.
OpenNMS 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.
I'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).
Just wanted to give a quick update on a mix of Fink and Leopard issues.
First of all, if you get the error, "Failed: Can't fix GCC after Repair Permissions" it's because the XCode installer decided not to bother erasing your /usr/sbin/gcc_select even though it shouldn't be there anymore. It should be safe to erase it, but if that scares you, you can upgrade to 0.27.8 and your problem should go away as well... (Fink does not use gcc_select anymore on 10.5 as of 0.27.8.)
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 __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
...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.
