severity 431104 serious thanks On Fri, Jun 29, 2007 at 11:53:04AM +0200, [EMAIL PROTECTED] wrote: > Package: libgsf-1-114 > Version: 1.14.4-1 > Severity: important > Justification: renders package unusable > I am using libextractor-plugins that are linked to libgsf. > The libextractor ole2 plugins crashes with the last libgsf version (1.14.4), > but not with the previous one (1.14.3).
Hi, this happens because the plugin is not calling gsf_init(). The same issue made libimage-librsvg-perl fail to build from source, see #430805. Version 1.14.4-1 of libgsf introduced changes that broke applications not calling gsf_init() and using 'dynamic' stream types like gzipped input (and apparently others). Symptoms are messages like ** (process:12689): CRITICAL **: gsf_output_get_type: assertion `gsf_output_type != 0' failed ** (process:12689): CRITICAL **: gsf_output_memory_get_type: assertion `gsf_output_memory_type != 0' failed ** (process:12689): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed In a sense this is an API change: although gsf_init() has been present earlier, I see nothing in the documentation stating that calling it is mandatory. Of course, it is sane to expect this from the applications, and anyone not calling gsf_init() should be considered buggy. I'm raising this to serious for now to keep 1.14.4-1 out of lenny until the implications of the change are clear. Hope this is OK with the libgsf maintainer and the release team. There are currently 13 source packages build-depending on libgsf-1-dev, including librsvg that's build-depended on by 44 more packages. I don't know how widespread the problem actually is. One more affected package that I have found is gimageview, which can't view compressed svg files anymore. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
