New 'Import Clip Art…' dialog in trunk fails on Mac OS X

[su_v]

Original description:
=====================
New (refactored) import feature from OpenClipart.org fails on Mac OS X with this error:

(inkscape:29713): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-io-error-quark
code : 15
what : Operation not supported

Steps to reproduce:
1) launch Inkscape trunk
2) open 'File > Import Clip Art…'
3) enter search phrase and click on "Search"

-> search returns no results in the dialog, and above messages are printed to the console instead. Inkscape itself does not crash, and the dialog can be closed normally (using the 'Close' button).

Reproduced with Inkscape 0.48+devel r11030 on
- Mac OS X 10.5.8, Apple GCC 4.2.1, glib 2.28.8, glibmm 2.28.0
- OS X 10.7.2, FSF GCC 4.6.2, glib 2.30.2, glibmm 2.28.2

Regression was introduced in revision 11027 with the merge of lp:~and471/inkscape/ocal-dialog-improvements.
For further details, see the discussion in the merge proposal:
<https://code.launchpad.net/~and471/inkscape/ocal-dialog-improvements/+merge/56234>

Update (from comment 10):
=========================
Works as expected if gvfs is installed, and GIO configured to use (i.e. autolaunch) gvfsd (requires running dbus session).
The search for images on Openclipart then autolaunches gvfsd-http.

Remaining issue: packaging for OS X

[jazzynico (jazzynico)]

The same steps lead to a crash on Windows XP, with a laconic message:

-----
terminate called without an active exception
Emergency save activated!
....
-----

No bt available. Worked well last time I tested it from the branch (old devlibs).

The new OCAL dialog works as expected on Ubuntu 11.04 and Debian Wheezy.

[su_v (suv-lp)]

@JazzyNico - since the new dialog had worked on Windows earlier (in branch builds), maybe it would be better to track the crash in a separate report. Chances are that it can be fixed easily - whereas the new dialog _never_ worked on OS X (due to GIO features apparently not ported to or compatible with) Mac OS X /Darwin).

Proposing to set bug importance of this report (bug #943148) to 'Wishlist' and tracking the crash on Windows in a separate report (bug importance 'High').

[jazzynico (jazzynico)]

I hesitated to create a separate report because the steps are identical, and the Windows case may have been triggered by the recent devlibs changes. But since it doesn't crash on OS X, it may also be something different...

[jazzynico (jazzynico)]

Windows issue reported in Bug #943275 "New 'Import Clip Art…' dialog crashes on Windows".

[su_v (suv-lp)]

> - Mac OS X 10.5.8, Apple GCC 4.2.1, glib 2.28.8, glibmm 2.28.0
> - OS X 10.7.2, FSF GCC 4.6.2, glib 2.30.2, glibmm 2.28.2
also tried newest stable (?) glibmm:
- OS X 10.7.2, FSF GCC 4.6.2, glib 2.30.2, glibmm 2.30.1
with same result (Operation not supported).

[jazzynico (jazzynico)]

I'd tend to consider this one a blocker...

~suv - Anything new on GIO on OSX?

[su_v (suv-lp)]

> ~suv - Anything new on GIO on OSX?

No - I still get the same error with updated dependencies:
- glib 2.33.10, glibmm 2.32.1
and haven't figured out which operation is for what reason not supported.

Next time I update dependencies for the GTK+/Quartz-based build environment (upgrade to unstable glib 2.33.12 is pending), I'll consider upgrading to unstable glibmm too (latest is 2.33.3) - though the error might as well be a missing configuration which on linux desktop is handled with gconf (or similar), I just don't know.

[su_v (suv-lp)]

> I'd tend to consider this one a blocker...

Not sure about this: it only affects one of the supported platforms, and not having it supported on Windows didn't block earlier releases either.

(TBH the feature isn't "stable" on Mac OS X with Inkscape 0.48.x either: import from OpenClipart can only be used once in the current session - if called a second time within the same session, it results in a crash as well (bug #365567, comment #4 and below))

[jazzynico (jazzynico)]

> TBH the feature isn't "stable" on Mac OS X

Ok. I thought you lost a stable feature.
Not having it on Windows is different because it has never been implemented on that operating system. It's not yet vs no more...

[su_v (suv-lp)]

Update:
Works as expected if gvfs is installed, and GIO configured to use (i.e. autolaunch) gvfsd (requires running dbus session).
The search for images on Openclipart then autolaunches gvfsd-http.

GIO settings (control via env):
GIO_USE_VFS=gvfs | local

openclipart import fails with known error if $GIO_USE_VFS is set to 'local', but works if $GIO_USE_VFS is unset or set to 'gvfs'.

Remaining issue: packaging
Enabling gvfs support will require including dbus and gvfs daemons in the relocatable app bundle. Inkscape.app will then autolaunch three daemon processes which are left running unless the launcher script finds ways to stop them on exit. AFAIU DBus has this feature built-in (dbus-launch --exit-with-session …), but I haven't yet found information about a similar option for the daemons autolaunched by GIO and gvfsd.

[su_v (suv-lp)]

Trying to solve this for osx packaging is getting frustrating rather quickly.

While bundled dbus launches as well as stops a session bus just fine, there are two blockers which I have no clue so far how to solve:
1) DBus service files and gvfs mount files require an absolute path for the 'Exec' part. This prevents usage with relocatable self-contained OS X application bundles. AFAICT relative paths are not resolved, nor is $PATH searched if only the name is specified.
2) Gvfs so far seemed to ignore any attempts to respect environment variables which would help with relocation support (e.g. $XDG_DATA_DIRS for the location of the mount files). The dbus service launches the bundled gvfsd binary just fine, but that daemon subsequently seems to fail to launch gvfsd-http on request (even if the 'Exec' path in the mount file has been modified to point with an absolute path to the gvfsd-http binary inside the app bundle).

While import from openclipart works reasonably well with a regular install (fixed $PREFIX) on OS X (if one has gvfs installed and accepts to have multiple additional non-native daemons running, apart from dbus), I fail to make it work within a relocatable OS X application bundle (contributing: my utter lack of knowledge about GIO, Gvfs and whatever GNOME implements via these libraries, and lots of other GNOME internals which seem to play an increasing role for OS X packaging even if one tries to avoid installing GNOME-specific dependencies or components as much as possible).

[su_v (suv-lp)]

Tentative solution (hackish) in
<http://bazaar.launchpad.net/~suv-lp/inkscape/osxmenu/revision/12735>

Gvfs dbus service file and mount file(s) are loaded from $XDG_DATA_HOME, and get recreated on each launch with the current absolute path for 'Exec' to the gvfsd* binaries inside the app bundle.

Tested with spaces in the path to Inkscape.app, but not any other characters users might use as folder names, and which might need to get quoted or escaped differently in the 'Exec' attribute of the local service and mount files.

Not an ideal solution IMHO (preferably upstream would provide relocation support for other platforms); and support for the dbus-based scripting API with Inkscape.app might require further workarounds (not attempted yet).

[su_v (suv-lp)]

Update wrt osx packaging (in branch 'osxmenu') - new failure:

(inkscape-bin:38854): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-tls-error-quark
code : 0
what : TLS support is not available

AFAICT it seems that openclipart's feeds moved from http to https, which is not supported by the current solution (or hack) in the osxmenu branch to provide self-contained relocatable GIO/gvfs http support in Inkscape.app. Including the gnutls GIO module (libgiognutls.so) and its linked libraries seems to fix it (search and import from ocal works again), but at the same time breaks a core feature of inkscape (inkscape-bin crashes when attempting to spawn a process for any script-based extension).

I'm giving up for now …

[su_v (suv-lp)]

On 2014-10-28 05:45 (+0100), ~suv wrote:
> I'm giving up for now …

Not really ;-)

Small progress: the failure to spawn processes seems related to the current p11-kit version in MacPorts (0.22.1), which apparently also causes GIMP to fail to load any file plugins (but only if gegl is compiled with ffmpeg support (?)) [1].

After downgrading p11-kit locally to 0.20.7, both 'Import Clip Art' and extensions work again in initial tests with recreated Inkscape.app. More tests needed though …

[1] GIMP's issue with plugins is tracked for MacPorts in
- Ticket 45309: p11-kit child atfork handler causes gimp forks to
  crash due to gegl dlclose(), no gimp plugins available
  https://trac.macports.org/ticket/45309

[su_v (suv-lp)]

On 2014-11-03 13:41 (+0100), ~suv wrote:
> After downgrading p11-kit locally to 0.20.7 (…)

JFTR: p11-kit is a dependency of gnutls. Gnutls is needed AFAICT (based on empirical testing) to provide https support via GIO; glib-networking configured with gnutls support installs the required gio module.

Dependency chain:
gvfs <- libsoup <- glib-networking <- gnutls <- p11-kit

[su_v (suv-lp)]

Patch to disable the menu entry 'File > Import Clip Art...' in osxapp-enabled builds.

To be applied to <lp:inkscape/0.91.x> to avoid the defunct menu entry in release packages of Inkscape 0.91 for OS X (see also new duplicate report bug #1399484).

[Bryce Harrington (bryce)]

Patch in comment #16 is approved for landing on the 0.91.x branch.

This doesn't preclude a proper patch to fix the feature later, if a suitable one becomes available.

[su_v (suv-lp)]

Patch to disable menu item "File > Import Clip Art..." committed to <lp:inkscape/0.91.x> in r13679.

[Shlomi Fish (shlomif-gmail)]

I'm running into this bug with the inkscape packages and a self-compiled Inkscape on Mageia Linux x86-64 v5 and Mageia Linux x86-64 v6. I am getting these errors on the command line:

(inkscape:5633): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-tls-error-quark
code : 0
what : TLS support is not available

(inkscape:5633): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-tls-error-quark
code : 0
what : TLS support is not available

========================

shlomif@telaviv1:~$ inkscape

(inkscape:9685): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-io-error-quark
code : 15
what : Operation not supported

shlomif@telaviv1:~$ /home/shlomif/apps/graphics/inkscape-trunk/bin/inkscape

(inkscape:9692): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-io-error-quark
code : 15
what : Operation not supported

[Jonathan Hofinger (jhofinger)]

OpenClipart integration has been removed from Inkscape (https://gitlab.com/inkscape/inkscape/issues/440), since OpenClipart is down permanently.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Closed by: https://gitlab.com/jhofinger