Josh Saddler

I was poking through the contents of my world file and USE flags the other day, trying to trim down the number of Gnome dependencies present on my Xfce laptop. Abiword is the application that requires all the Gnome stuff. If only it didn't need deprecated libraries like libgnomeprint, the rest of the Gnome desktop wouldn't get pulled in.

So, I started looking around at alternative word processors and office suites. There's always OpenOffice, but I don't really like using something as slow and bloated as OOo even at the best of times. There are some other office packages available, but they're for Qt/KDE. Or they're made of something really icky, like Java.

And then I found it: Siag Office. This office suite dates back a number of years. It used to be present in Gentoo, actually, but was removed five years ago.

I took a look at the upstream homepage; it still seems to be sporadically developed. Last release was in 2006. I poked around in the documentation, INSTALL, READMEs, and whatnot in the upstream CVS to get a better feel for what's required. Siag mostly relies on little-used X libraries, including old-school Athena widgets and their derivatives. It also has its own expanded widget kit, Mowitz. Siag ain't pretty, though at least it looks better than Motif-based apps. Most importantly, it's reputed to be very fast, needing very few dependencies.

The Portage CVS attic contained outdated ebuilds; the latest Siag release is 3.6.1, and the latest Mowitz release is .3.1. I used the outdated ebuilds as a foundation for creating my own ebuilds. And that's when the trouble, I mean fun, really began.

For starters, the old ebuilds had a lot of cruft leftover from the pre-modular X days. Stuff like virtual/x11, deprecated configure/make functions, unnecessary USE flags . . . even some bad configure switches from when the code did odd things, like --host=${CHOST}. These obvious mistakes required fixing. Then I checked the Getting Siag page to get more of an idea of the current dependencies.

Siag-3.6.1 has build dependencies on gmp, Mowitz, tcl, libXpm, and libXaw. It has optional runtime dependencies for Python, ccmath, and netpbm. The dependency on libXaw may be interchangeable with other Athena widget-compatible libraries. I sent an email upstream to verify this, as comments in the source code give the impression that while Xaw can be used, so can XawM (a variant created by the Siag folks), Xaw3d, and possibly even neXtaw. In my email, I asked specifically about neXtaw, as Mowitz relies on neXtaw. I figure it's best to just use one widget set if possible to give a more unified appearance. Perhaps neXtaw can be used as a drop-in replacement?

Anyway, once the dependencies were updated for the Siag ebuild, it was time to redo the configure/install section. This is actually still a work in progress; I haven't taken the time to really nail down the optional dependencies, add final USE flags, etc. I've been trying to get working ebuilds, not perfect ebuilds. Not yet.

Once the Siag ebuild was working, I moved on to the Mowitz ebuild. This required many of the same fixes that Siag did. The biggest headache, though, was trying to get the Xaw dependency hammered out.

The old version used to be able to use a number of Xaw varieties, same as Siag. However, the latest version seemed to have narrowed it down to either Xaw3d or neXtaw, default is neXtaw. The configure switch --with-xaw3d= should allow for either one, right? The source code comments in the INSTALL file say the same thing. Unfortunately, it doesn't hold up in reality. If neXtaw is not installed, the configure phase will fail, saying it can't find the Xaw implementation (aka neXtaw). I spent an hour throwing Xaw3d and Xaw name/path variants at it before giving in. How ironic that the --with-xaw3d= switch can't actually use Xaw3d. So I let it just run with the default neXtaw, updating the ebuild for this build dependency. Worked just fine. Good thing that neXtaw was never taken out of the Portage tree! The neXtaw ebuild, at least, is up to date.

In my email to the upstream maintainer, I mentioned that the configure and/or documentation is incorrect. Hopefully I'll get a response, but it has been a few years since the code was touched upstream.

Now that I'd hammered out the dependencies for Siag and its two required dependencies (Mowitz and neXtaw), it was time to merge the package. The sourcecode for Siag itself is only abou 1.5MB. That's right, a whole integrated office suite, with word processor, spreadsheet, animation app, file manager, text editor, and previewer . . . less than 2MB. That's quite an accomplishment! Only took a few minutes to compile.

I discovered that Siag is so old that it seems to predate the common .desktop files used to display an application in your program menu, or at least upstream hasn't bundled any. I'll have to write up my own .desktop entries and add in the accompanying installation function into the ebuilds. So I had to use the command line to launch 'em. That's when the biggest issue hit: Siag won't run.

None of the binaries installed can actually run; I have hit upon a rather famous error that dates back to 1998 or so, and has popped up here and there in the intervening decade:

$ siag
Warning: Cannot convert string "-*-helvetica-medium-r-*-*-12-*-*-*-*-*-iso8859-*" to type FontStruct
Warning: Missing charsets in String to FontSet conversion
Panic: can't load any fonts!

I'm not entirely positive what causes this; Google searching has widely disparate bug reports. It's probably something to do with the way pre-modular X did font handling. Siag seems to want to do stuff in certain ways that the old monolithic X did. It may be able to compile against more modern libraries, but whatever it wants to do is too old-school. There's probably some leftover cruft hardcoded somewhere. I just haven't found what, yet.

At least I can see the errors when running the main applications like siag and pw. The animation app, egon, won't even show that much. Just as in the linux.com review, egon simply would not run:

$ egon
Segmentation fault

I'm unable to perform any further diagnosis. I don't have any debug libraries or applications installed on the laptop, and at this point I'm not going to waste any more time on just this one application.

I'll still try to get the rest of Siag running -- there are a few solutions for the runtime font failure, but none of them have worked for me so far. I have not yet given up; I'm still trying to find ways to slim down my laptop, get rid of Gnome dependencies, and lighten up my Xfce environment.

I've put my work-in-progress ebuilds in my devspace. Once again, I should remind you that the Siag ebuild in particular is not yet finished. It'll do the most important things--compile and install Siag--but it's not finished. If you're looking to cut your teeth on some simple ebuild tasks, you're welcome to spend some time in our Gentoo Development Manual and send me a patch. Working with ebuilds really isn't intimidating the way it may appear at first. Mostly, the work just requires time to sort through issues as they turn up. Time, not arcane knowledge of the most secretive inner workings of code.

Also, if you've got any potential solutions to the font startup failure, I'd love to hear from you! This is the last remaining barrier that I know of to getting Siag working. Well, that and setting up Siag to print, as it doesn't have a graphical interface. Instead, Siag needs you to tell it the proper CUPS commandline stuff. Which, again, is just a bit more time and reading the manpage for lpr. Time and reading. That's most of the process. Time, effort, and persistence.

I'm hoping it'll pay off for Siag Office.