hrm, there seem to be two separate problems here.

Firstly it looks like there was an old version of autopackage lying around. We don't deal with this situation very well currently.

The second problem is this:

(autosu-gtk:26246): Gdk-WARNING **: shmat failed: error 2 (Invalid argument) Xlib: connection to ":0.0" refused by server Xlib: No protocol specified

In other words, perhaps the reason we didn't set things up correctly is that autosu failed to start. Why? I don't know. The shmat error indicates some kind of problem with the X SHM Pixmaps extension, but I have no clue what might cause it to fail. Perhaps a permissions issue - is the user you ran the installer as able to connect to the X server normally?

thanks -mike

On Wed, 12 May 2004, Mike Hearn wrote:

The second problem is this:

(autosu-gtk:26246): Gdk-WARNING **: shmat failed: error 2 (Invalid argument) Xlib: connection to ":0.0" refused by server Xlib: No protocol specified

In other words, perhaps the reason we didn't set things up correctly is that autosu failed to start. Why? I don't know. The shmat error indicates some kind of problem with the X SHM Pixmaps extension, but I have no clue what might cause it to fail. Perhaps a permissions issue - is the user you ran the installer as able to connect to the X server normally?

thanks -mike

Hi Mike,

I played with autopackage again this afternoon, and got it to work! I ran into some problems (like the ones I mentioned earlier) but got them resolved. Here's a list of those problems and the things I did to work around them:

1. Run `xhost +` ================= By default my system was set up with xhost -, so that's why the Xlib errors were showing up. You can detect the current setting by running `xhost`. I'd recommend you add to your install script something that turns this on when the program is run, and restores to the original state when the script exits.

2. Permissions Problem ======================= After this, I ran the installer as root and it installed and ran fine - but only as user 'root'. As a regular user I couldn't execute Inkscape because autopackage had set it's permissions to 700. I have:

mercury:/home/bryce # umask 0077 mercury:/home/bryce # echo $umask 22

3. Download Loop ================= After the first time I successfully installed Inkscape with autopackage, I uninstalled it and tried installing again as a regular user to see if the permissions problem got resolved. But then I started getting a problem where it would download and install autopackage, then remove it and try installing again a second time, but the second time through it encountered this error:

.... Connecting to ftp.sunsite.dk[130.225.247.92]:80... connected. HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable

Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `autopackage-0.5.1.tar.bz2'.

Download failed. ....

So then I manually downloaded the package and put in the current dir, and ran it again. This time it just continually looped, reinstalling and reinstalling the Autopackage GTK+ Graphical User Interface.

The console output included this:

.... (autopackage-frontend-gtk:29185): Gdk-WARNING **: shmat failed: error 2 (Invalid ar gument) The selected package is already installed, removing ... done /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 341: /share/autopackage/apkg-funclib: No such file or directory /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 343: out: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 344: out: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 346: out: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 347: out: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 348: out: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 351: isInList: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 352: updateEnv: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 353: out: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 354: out: command not found /dev/shm/autopackage.139723121/meta/@inkscape.org/inkscape:0.39cvs/apkg-downloader: line 355: out: command not found

The installation of this software requires some additional support code to be installed. ....

To work around this problem, I logged in as root and ran the package tool. This time it ran through to completion correctly, but as before the permissions were screwy. So I manually fixed them like this:

mercury:/home/bryce # chmod a+rx /usr/bin/inkscape mercury:/home/bryce # chmod a+rx /usr/lib/libgtkmm* mercury:/home/bryce # chmod a+rx /usr/lib/libgdkmm* mercury:/home/bryce # chmod a+rx /usr/lib/libatkmm* mercury:/home/bryce # chmod a+rx /usr/lib/libpangomm* mercury:/home/bryce # chmod a+rx /usr/lib/libglibmm* mercury:/home/bryce # find /usr/share/inkscape/ -type 'd' | xargs chmod a+rx mercury:/home/bryce # find /usr/share/inkscape -type 'f' | xargs chmod a+r mercury:/home/bryce # chmod -R a+rx /usr/lib/inkscape/

I'm not sure I got everything, but that was enough to get it to run and seem to work correctly. Although I did see this at the console:

{mercury} ~ (13): inkscape Warning: program compiled against libxml 206 using older 205 Deleting Extension: AI Input Deleting Extension: Dia Input Deleting Extension: Text Input Deleting Extension: EPSI Output

(inkscape:13289): Gdk-WARNING **: shmat failed: error 22 (Invalid argument) {mercury} ~ (14):

Anyway, pretty cool! I think once these kinks get worked out, this will become the preferred way of installing Inkscape on rpm-based systems. I'd just gone through doing an rpm-based install for a co-worker today, and it is *such* a pain... I showed her the autopackage install and she was quite taken by it.

Bryce

On Fri, 28 May 2004, Mike Hearn wrote:

On Thu, 2004-05-27 at 17:40 -0700, Bryce Harrington wrote:

...

1. Run `xhost +`

================= By default my system was set up with xhost -, so that's why the Xlib errors were showing up. You can detect the current setting by running `xhost`. I'd recommend you add to your install script something that turns this on when the program is run, and restores to the original state when the script exits.

How is it possible to run any X programs at all as root if this is set? Is this the SuSE default, or is this something you have done?

I didn't set it, so it must be the SuSE default. And no, it isn't possible to run X programs as root, normally.

...

2. Permissions Problem

======================= After this, I ran the installer as root and it installed and ran fine - but only as user 'root'. As a regular user I couldn't execute Inkscape because autopackage had set it's permissions to 700. I have:

mercury:/home/bryce # umask 0077 mercury:/home/bryce # echo $umask 22

Is this the SuSE default?

I set it to that in my login scripts for my 'bryce' user. I think this gets carried over into root's environment when 'su' happens. Hmm, I could probably work around that by using 'su -', but for you probably the more robust solution is to temporarily force the umask to exactly what you need when running.

...

Connecting to ftp.sunsite.dk[130.225.247.92]:80... connected. HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable

It sounds like you had a failed download somewhere. I can't recall exactly where we download this too but I suppose we should wipe it before doing the download.

Yeah, I looked around for it, removed everything under /dev/shm/* but it still was having trouble.

...

So then I manually downloaded the package and put in the current dir, and ran it again. This time it just continually looped, reinstalling and reinstalling the Autopackage GTK+ Graphical User Interface.

The console output included this:

.... (autopackage-frontend-gtk:29185): Gdk-WARNING **: shmat failed: error 2 (Invalid ar gument)

This is still the problem. Either xhost got reset, or there is still something wrong with your system (something screwy in the kernel?). I don't really understand why your system is producing these errors, but that's why autopackage is screwing up. We expect this to always work, an apparently flawed assumption :)

Guess it's better to assume there's still bugs, we just haven't found 'em yet. ;-) In any case, I'd love to help make it always work a little more, so hopefully this is useful feedback even if they are strange corner cases.

...

I'm not sure I got everything, but that was enough to get it to run and seem to work correctly. Although I did see this at the console:

{mercury} ~ (13): inkscape Warning: program compiled against libxml 206 using older 205

This should be fairly harmless, I hope ...

...

(inkscape:13289): Gdk-WARNING **: shmat failed: error 22 (Invalid argument)

OK so it looks like this is a problem with all GTK apps on your system. I'm not sure what we can do about this, I don't know enough about the GDK/X internals to debug this remotely :(

I'll keep an eye out for it. I intend to use this mechanism for some of my co-workers for installing it, so since some of them are also running SuSE, it's possible I'll see it crop up again, in which case I'll try to narrow it down a bit better. It seems non-fatal on my system so I'll ignore it for now.

Bryce

I'm a muffin - I just discovered the inkscape install was broken for about a week due to version mismatches (when we released 0.5.1 I rebuilt inkscape but not its dependencies).

Could you do the xhost + thing and try again please? Make sure you've cleared up anything in /tmp and /dev/shm first ...

thanks -mike

On Sat, 2004-05-29 at 14:15 -0700, Bryce Harrington wrote:

For the graphics-based installation it would probably be wise to minimize the amount of stuff occuring on the console. There's a couple places where the user has to type 'Y' or hit enter in a console window, that would be better implemented as buttons in a GUI dialog.

Hmm, there should only be one: when you are first prompted to install autopackage itself. Once you have hit enter or pressed Y here the rest should be entirely automatic (assuming you ran as root, if not then you should get a GUI authentication window).

At a couple points it prompts 'Y/n' but just hitting 'enter' does not do the same as hitting 'Y', as one would expect. This needs to be fixed.

Yeah, that's a bug. Could you list the two points where you had to do console interaction? It should only be one, and after you have installed autopackage for the first time there shouldn't be any at all (ie it's all graphical).

While the upgrade process was very smooth and effective, it felt like something was missing. Perhaps this was because it occurred all on the console and I was expecting a GUI to pop up, or perhaps because it wasn't obvious that an upgrade had actually occurred (I had to launch Inkscape and try out a feature I new had just been changed in order to verify it).

When you say upgrade process, what exactly do you mean? Basically the only upgrade "support" currently present is that any existing package will be uninstalled before installing the new one when you run it. The installation of the new package should be entirely graphical, same as usual.

I suspect we still have X authentication issues here if you are seeing this much console interaction ....

So I guess what was missing was a bit more feedback. Maybe a dialog that pops up and says, "Inkscape has been successfully upgraded from version X to version Y."

Yes, it'd be nice to have this in the summary screen.

It'd be extremely cool if it could also list "What's changed", although I'm not sure how that info could be easily pulled in...

It could just be metadata in the specfile.

Probably during installation in general it'd be worth having a final screen that very clearly says, "The installation of Inkscape version X was a success." A summary of dependencies installed and maybe the release notes might be nice.

We already do? http://autopackage.org/screenshots/gtkfe/finished1.png

That screen lists all the packages that were installed along with menu entries that were put on the system. Are you sure you're seeing the sort of things on the http://autopackage.org/gallery.html page?

Do you have a hook for displaying the license? For some apps this will be considered pretty critical...

It's half complete. I doubt it'll be ready for 1.0, we're in feature slush right now. It's only necessary for proprietary software really, and currently autopackage does not provide good enough robustness guarantees for proprietary ISVs on Linux anyway.

I'm sure this is already on your todo list, but a GUI-based Uninstallation mechanism would be *very* nice.

Yep, it is definitely on the todo list. The main issue we need to work out here is simply how the user launches it. Currently neither Gnome (nor KDE i think) support the .desktop file Actions key. There is a patch for Gnome written by a friend of mine, but it's yet to be applied :(

Also, have you considered ways of providing hooks for tying Autopackage into the desktop stuff or the application itself? For instance, I'm thinking if a user could right-click on the program icon, or the application menu, and have options to "Upgrade"/"Uninstall"/"Reinstall"/"Package Info" etc. it could give a much better user-friendly package management solution than is available in *NIX or Windows currently.

Yes we want to do this, as I mentioned above some of the necessary patches have already been written.

The main problem is that:

(a) for Gnome at least, that ability is at minimum 6 months away, assuming the patch is applied by Mark McCoughlin soon.

(b) Usability is not great. Right clicking on a menu item in the applications menu? That isn't very intuitive and doesn't work for any other type of menu.

Long term we may want to move to a garbage collection model for this sort of thing, but more R&D is needed. For now we may simply install an "Remove/Upgrade 3rd party software" item or menu.

Extra slick would be if it could detect when the user deletes the application entry from their desktop menu and prompt if they want to just remove the icon link, or uninstall the program entirely (in which case the icon only is removed if the uninstall was successful).

I've considered this. My experience with Windows indicates that a lot of people don't really understand the distinction between a link to the app and the app itself though.

We have a long term UI vision for autopackage, that has been discussed on the mailing list at various points. I'm going to write it up into a "vision document" soon, so hopefully our UI goals become clearer :) The eventual goal is a totally transparent system with an UI somewhat resembling the one on MacOS X.

Finally a more general question - say you're an ISV and want to provide an Autopackage version of your software for use on any Linux distro. How "hard" will this be for a company that doesn't know Autopackage? What considerations will they need to take into account? Would they need to identify/provide packages for sub-dependencies themselves? What documentation would you point such an ISV at?

When I'm not being a student/living/working on autopackage I am an engineer with CodeWeavers, Inc (we make CrossOver, a semi-proprietary version of Wine). So in effect I am also a 3rd party ISV.

There are a few different issues here. I'll assume we're talking about proprietary software.

(1) 3rd party software tends not to have many "non core" dependencies. If any libraries are used which the user may not have, they are often statically linked. That's undesirable but understandable, we have enough problems with random distro brokenness to worry about user not having libfoobar.so.2.3.1

(2) If the user cannot install the software, you get no sale. So, the installation MUST be 100% robust and reliable. Loki Setup is popular because it works, and is a simple known quantity. It doesn't do dependency resolution but that's OK, if your software depends on packages not in the base set of most distros you are already going out of business ....

Autopackage currently does a few things we'd need to fix to make it really attractive for companies. In particular we would need to allow bundling of the core code and gtkfe inside the package: currently we invoke the "Please wait while autopackage is downloaded and installed" process you saw earlier. Replacing this with a graphical version is on the todo list, but it's not an ultra-high priority right now. Anyway, any installer which requires an internet connection is right out for proprietary ISVs.

Proprietary software tends to be large, so we don't worry too much about installer overhead there.

We'd also need to document exactly what autopackage itself depends on. Right now we haven't done this. Anything that may break in future or may not be present, needs to be included statically some how.

I have some plans for some distant point in the future to allow autopackage to make greater use of ELF binaries as generally the glibc/kernel interfaces are far more stable than interfaces to various shell script tools such as what we use. But that's a long way off.

As to would they have to package extra components themselves: this is the same as for open source software. In theory no - in the ideal world all library/component projects provide some binary package in some form that autopackage knows how to use, whether that be another .package or RPMs/DEBs/whatever.

Then they just have to publish a luau XML file on their web server, add the URL to the skeleton file and from that point on all packages compiled will be able to resolve them from the web.

For the foreseeable future however dependencies will not always be available in such a form. In this case, either statically linking them or packaging it themselves is the way forward. I would recommend static linking actually as if you package it yourself, this violates the principle that maintainers should build their own binary packages as well as possibily causing conflicts in future if/when they do.

thanks -mike

On Sat, 2004-05-29 at 16:41 -0700, Bryce Harrington wrote:

No, it always goes back to the console at least a couple of times for input from the user. It did this on my own system and Judith's (both SuSE desktops.) It also displayed GUI authentication windows at least once.

I guess we have a problem with the latest version of SuSE then. This definitely sounds incorrect.

Well, I mean it should also list that it installed/upgraded autopackage and any dependency libs (gtkmm, etc.), as well as listing the version numbers that were installed. Yes you're right that it displayed that installation completion screen in most cases.

Yep, OK. We'd like to do this.

Ah, makes total sense now. Small world. Tell Jeremy hi. ;-)

Done ;)

Fwiw, this particular question arises from a concern being voiced by some of the OSDL member companies about "difficulty porting to / installing on Linux". They haven't been very specific so I don't know for certain if Autopackage would suit the needs, but I am thinking it may be worth presenting it to them this summer.

Knowledge of Linux installation/binary portability techniques is somewhat lacking. As we've been writing autopackage we've been documenting the various issues in our packager guide.

Yup, and admittedly veering completely off-topic for this list. ;-) We can move this discussion over to the autopackage-dev list if you'd like to continue the discussion, but you've answered all the questions I had.

I think we're almost done for now ... it seems we have issues on SuSE which I will definitely look into (this would not be the first time we have odd problems with various distros).

The one major dependency that has been identified that ISV's run into is libc. That's a tough one to get sorted out (and not one you'd want to automatically install for people...) But I'm thinking if Autopackage could download the correct version of the software to match the system libc, that may provide a cleaner solution than currently available.

Actually libc isn't much of a problem if you use apbuild - all autopackages are built with this tool: the inkscape package should not suffer any libc problems on any system > deb stable/RH 6.2.

glibc actually does a pretty good job of not breaking backwards compatibility. The main issue is that people don't realise you can control which symbol versions are selected by the linker using GAS pseudo-ops. One of the things apbuild does is modify the build system and inject assembly control sequences into the code as it's compiled to ensure you end up with a binary that can run on older systems.

The other issue people run into is stuff like thread-local locales (the missing __ctype_b_loc symbol problem) and libgcc exception frame handling (__register_frame_info_bases). apbuild also fixes these automatically.

Using apbuild btw is straightforward and does not depend on autopackage. Just "CC=apgcc CXX=apg++ ./configure"

Right. There are a few different approaches to this goal in addition to making the packaging software ultra robust, or including all dependencies in the core, some of which are being tossed around at OSDL.

Are you involved with OSDL? I didn't realise they were looking at this issue, if these companies have any questions they should feel free to talk to us. Between Wine/CrossOver (which is binary portable to any distro) and autopackage I've become fairly adept at dealing with binary portability problems.

Although, also consider that we can expect that as Linux continues to penetrate into the enterprise desktop market, there's going to be more instances of internal app development/rollout, where they'd want installation to be user-pull rather than IT-dept-push. In this use case I can imagine the app being built on open source components and the installer needing to be at least modestly dependency-aware.

Yeah. We have a few bits of code in there which currently aren't used, but are there to support corporate deployment scenarios when we support that in future. For instance the current plan is to be able to generate a basic (low quality) RPM from a given autopackage. Such a thing would perhaps not deal with dependencies like a native RPM would but it could be mass deployed to desktops using things like Red Carpet, apt/yum etc.

...

We'd also need to document exactly what autopackage itself depends on. Right now we haven't done this. Anything that may break in future or may not be present, needs to be included statically some how.

Yup, does libtool indicate this? In any case, it might be worthwhile in general to list distro/versions that autopackage has been tested on and will run directly.

Being written mostly in bash autopackage doesn't use libtool - actually one of the things apbuild silently fixes is the fact that libtool gets DSO dependencies wrong (at least on Linux).

Mmm, that may work for them. A possible enhancement for this would be a script to cache the dep's at the vendor's site, so that if the mirrors were bogged down or something, the user could still obtain them from the vendor's site. Again, certainly something the ISV could easily do themselves.

That's a pretty good idea, thanks. We have some support for mirroring, but I don't think there's any way to order them currently. I'll stick it on the TODO list.

thanks -mike

On Tue, 2004-06-01 at 11:11 -0700, Bryce Harrington wrote:

Upgrading my current install from last week went much more smoothly this time. I had only the following warnings:

{bryce@...347...} ~ (37): ./inkscape-0.39cvs.package

(autosu-gtk:2226): Gdk-WARNING **: shmat failed: error 2 (Invalid argument)

(autopackage-frontend-gtk:2283): Gdk-WARNING **: shmat failed: error 2 (Invalid argument) The selected package is already installed, removing ... done

These errors are still very strange.

mercury:/home/bryce # {bryce@...347...} ~ (38): package uninstall inkscape gtkmm libsigc++ autopackage-gtk autopackage bash: syntax error near unexpected token `('

Not sure what is going on there ... try a DEBUGLEVEL=3 trace

Getting a list of what *is* installed:

{bryce@...347...} ~ (48): package list /usr/bin/package: line 1808: cd: /var/packages: Permission denied

<whimper> Is this related to your umask, do you think? /var/packages should be world readable.

Fixing permission problem about /var/packages:

mercury:/home/bryce # ls -ld /var/packages/ drwx------ 11 root root 520 2004-06-01 11:00 /var/packages/ mercury:/home/bryce # find /var/packages -type 'd' | xargs chmod a+rx mercury:/home/bryce # find /var/packages -type 'f' | xargs chmod a+r ^D {bryce@...347...} ~ (53): package list autopackage-gtk: Autopackage GTK+ Graphical User Interface gtkmm: C++ GTK bindings inkscape: Inkscape Vector Graphics Editor {bryce@...347...} ~ (54): package uninstall inkscape Uninstalling inkscape... package not found.

Hmm, not sure why uninstall isn't working. I also tried 'package remove inkscape' but same results. Ideas?

Well remove is just an alias for uninstall.

This all works OK here (with 0.5.1). All I can suggest is doing this:

export DEBUGLEVEL=3 package uninstall inkscape

then seeing if you can divine the entrails (it's possible a lot of text will be printed). Hopefully that'll help. I can't reproduce these sort of problems, and it's not been reported by anybody else either :(

thanks -mike

On Tue, 2004-06-01 at 11:33 -0700, Bryce Harrington wrote:

Yeah, I figured. Note that your website suggests 'package uninstall' but the help message from running 'package' shows a 'remove' command but not 'uninstall'. Maybe add 'uninstall' to the help message?

Fixed.

Uninstalling inkscape... * trace:uninstallPackage():called with inkscape

• trace:resolveName():resolving inkscape
• trace:resolveName():no reference or dead symlink trail in user db

package not found. {bryce@...347...} ~ (59):

It looks like my 'user db' is borked up? Is there a way to rebuild it, or to blow it away entirely and start over?

Rebuild it, no. Blow it away: rm -rf ~/.packages

Firstly though, what does "cd ~/.packages; find" produce? The databases are just directories with text files and symlinks in them.

The confusing thing of course is that you ran it as root, so I'm not sure why it is looking in the user db. Your root user IS uid 0 right?

thanks -mike

On Fri, 28 May 2004, Mike Hearn wrote:

On Thu, 2004-05-27 at 17:40 -0700, Bryce Harrington wrote:

...

1. Run `xhost +`

================= By default my system was set up with xhost -, so that's why the Xlib errors were showing up. You can detect the current setting by running `xhost`. I'd recommend you add to your install script something that turns this on when the program is run, and restores to the original state when the script exits.

How is it possible to run any X programs at all as root if this is set? Is this the SuSE default, or is this something you have done?

Normally X will use MIT magic cookies in preference to xhost "authentication", so "xhost -" should not be a problem (from a security perspective, it's a sane default).

Xlib looks for cookies matching $DISPLAY in the file pointed to by $XAUTHORITY (normally this is ~/.Xauthority). As long as $XAUTHORITY points to a file that is readable and contains a cookie for the current display things should work fine. Check to make sure that $DISPLAY and/or $XAUTHORITY are not getting reset somehow.

Please do not use "xhost +".

Let me reiterate: unless you're comfortable with arbitrary remote hosts being able to get screen dumps, snoop keyboard input, or pretty much anything else they want with your X session, do not EVER use "xhost +".

-mental

On Wed, 12 May 2004, Mike Hearn wrote:

On Tue, 2004-05-11 at 16:25 -0700, Bryce Harrington wrote:

...

I gave a shot at using autopackage to install Inkscape. Results are appended. Basically I ran into the following issues:

• Mozilla didn't automatically download the .package file so I had to wget it and run it from the commandline.

Hmm. Can you tell me what happened? I use Epiphany here and it worked fine. The files should be being serviced with a mime type of application/x-autopackage: is this not the case for you?

Yeah actually I noticed it worked after I sent in the report. It turned out mozilla *did* pop up the save dialog but for some strange reason it got buried under other windows so I didn't notice it. So whatever the issue was, it's completely orthogonal to autopackage.

...

• Cut-and-paste of the output from the command got messed up - perhaps because of ANSI sequences in the output?

What terminal emulator are you using? I use gnome-terminal and I haven't had problems with this. You can disable colour output by doing an

I was using Konsole, IIRC. The colors came through okay, it was the cut and paste that mussed things up.

export AUTOPACKAGE_NOCOLORS=1

before running anything.

FWIW we did testing on many different peoples computers before releasing 0.5 and it worked OK for nearly everyone, so there's something different in your environment we haven't anticipated here.

Yeah, I seem to be "lucky" at finding obscure ways of making things *not* work. ;-)

The system I was installing it on is a pretty much stock SuSE 9.0 system, except that I'm running it dual head. I thought it'd make a good test since I hadn't installed the current Inkscape dependencies on it (libsigc++, etc.)

Can you tell me what environment/system details would be useful to you to have to help characterize it?

Bryce