Zero Install metadata for Inkscape 0.44
I've added the RPM for 0.44 to the Zero Install interface file. I've put up a copy here:
http://0install.net/tests/Inkscape.xml
Run this way, the RPM works on Debian/unstable, Debian/testing and Ubuntu/5.10 (if you have libglitz, libstdc++6, libgtkspell0, libgnomevfs2-0 and libxslt1.1 installed). It does not work on Debian/sarge (due to a (bogus?) dependency on pangocairo).
If you'd like to host this on the inkscape.org site, the steps are:
1. Download the XML above:
$ wget http://0install.net/tests/Inkscape.xml
2. Get 0publish (if you don't have it already):
$ 0alias 0publish http://0install.net/2006/interfaces/0publish
3. Set the URI to the address on the inkscape site where it will be made available, and resign with your GPG key:
$ 0publish Inkscape.xml \ --set-interface-uri=http://inkscape.org/2006/Inkscape.xml \ --key=Jean
4. This will also create a .gpg file with your public key. Upload both to the same directory on the web-server.
People will then be able to install it using:
$ 0alias inkscape http://inkscape.org/2006/Inkscape.xml
or by dragging to their GUI installer.
Thanks,
On Saturday 24 June 2006 13:47, Thomas Leonard wrote:
I've added the RPM for 0.44 to the Zero Install interface file. I've put up a copy here:
http://0install.net/tests/Inkscape.xml
Run this way, the RPM works on Debian/unstable, Debian/testing and Ubuntu/5.10 (if you have libglitz, libstdc++6, libgtkspell0, libgnomevfs2-0 and libxslt1.1 installed). It does not work on Debian/sarge (due to a (bogus?) dependency on pangocairo).
Yep, still haven't figured out how to work around this. Neither static compiling, nor appbuild nor building against GTK+ 2.4 (which doesn't require pangocairo) work for me. As soon as I fix this, I'll upload 0.44-1 on SF.
On Sat, 24 Jun 2006 15:31:07 +0200, Jean-François Lemaire wrote:
On Saturday 24 June 2006 13:47, Thomas Leonard wrote:
http://0install.net/tests/Inkscape.xml
Run this way, the RPM works on Debian/unstable, Debian/testing and Ubuntu/5.10 (if you have libglitz, libstdc++6, libgtkspell0, libgnomevfs2-0 and libxslt1.1 installed). It does not work on Debian/sarge (due to a (bogus?) dependency on pangocairo).
Yep, still haven't figured out how to work around this. Neither static compiling, nor appbuild nor building against GTK+ 2.4 (which doesn't require pangocairo) work for me. As soon as I fix this, I'll upload 0.44-1 on SF.
How are you checking that the dependency isn't there? ('objdump -p' will show actual depenencies, whereas 'ldd' will show dependencies due to libraries on your system and so isn't very useful for this)
I've just tried the autopackage build, and it also fails on Debian/sarge. It no longer depends on pangocairo but, unlike the RPM, it has gained a dependency on libxfixes!
Mike: any idea where this came from?
Extra deps in RPM (those not in the autopackage):
aspell bonobo bonobo-activation dl expat gconf-2 glitz gnomevfs-2 gtkspell ORbit pangocairo pangox popt Xft Xrender xslt
Extra deps in Autopackage (those not in the RPM):
png12 Xfixes xml2
I also tried compiling from source on sarge. This works and runs, but it hangs when the resulting binary is run on Debian/unstable, in Inkscape::ObjectHierarchy::_addTop. This might have something to do with me ignoring the dependency on sigc++-2.0 >= 2.0.11 and using 2.0.10 instead.
On Mon, 26 Jun 2006 21:38:43 +0100, Thomas Leonard wrote:
I've just tried the autopackage build, and it also fails on Debian/sarge. It no longer depends on pangocairo but, unlike the RPM, it has gained a dependency on libxfixes!
Yeah *rolls eyes*, myself and Aaron were working through this last night. It seems that GDKmm 2.4 uses an XFixes cursor API, so when it's statically linked in we get a dep on XFixes. I do not know if GDKmm compiles this out if it's not present or what .... the fix I suggested was to just stub out the function and eliminate the -lXfixes option :)
thanks -mike
Mike Hearn wrote:
On Mon, 26 Jun 2006 21:38:43 +0100, Thomas Leonard wrote:
I've just tried the autopackage build, and it also fails on Debian/sarge. It no longer depends on pangocairo but, unlike the RPM, it has gained a dependency on libxfixes!
Yeah *rolls eyes*, myself and Aaron were working through this last night. It seems that GDKmm 2.4 uses an XFixes cursor API, so when it's statically linked in we get a dep on XFixes. I do not know if GDKmm compiles this out if it's not present or what .... the fix I suggested was to just stub out the function and eliminate the -lXfixes option :)
And I was going to try this but -lXfixes keeps ending up in the Makefile no matter what I change. I'm still exploring this. If anyone wants to drop me a clue, feel free. As a last ditch effort I will edit all the makefiles and see if makeinstaller still has an option not to run configure.
Aaron Spike
On Sat, 24 Jun 2006 15:31:07 +0200, Jean-François Lemaire wrote:
On Saturday 24 June 2006 13:47, Thomas Leonard wrote:
I've added the RPM for 0.44 to the Zero Install interface file. I've put up a copy here:
http://0install.net/tests/Inkscape.xml
Run this way, the RPM works on Debian/unstable, Debian/testing and Ubuntu/5.10 (if you have libglitz, libstdc++6, libgtkspell0, libgnomevfs2-0 and libxslt1.1 installed). It does not work on Debian/sarge (due to a (bogus?) dependency on pangocairo).
Yep, still haven't figured out how to work around this. Neither static compiling, nor appbuild nor building against GTK+ 2.4 (which doesn't require pangocairo) work for me. As soon as I fix this, I'll upload 0.44-1 on SF.
I've been trying to compile against 2.4 as well. It doesn't work, because Inkscape uses some functions that only appeared in 2.6. I've submitted a bug report and patch here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1513541&gro...
Once that was done, I was able to compile it in a GTK 2.4 environment. I guess no-one else tried compiling with 2.4 before the release.
Note to devs: It's quite easy to do now, as I've added the gtkmm and glibmm 2.4 headers to the 0install GTK-2.4 environment. Run it like this:
$ 0launch http://0install.net/2006/interfaces/GTK-2.4.xml Giving you a new shell... compile your program in this environment. pkg-config reports GTK version is now 2.4.14 gtk2.4 $
Then build the RPM (or ./configure; make) in that environment, which has PKG_CONFIG_PATH pointing to an old -dev environment, which it downloads for you and places in the cache (it won't affect your normal build environment).
(0launch is available from http://0install.net/injector.html)
I've been trying to compile against 2.4 as well. It doesn't work, because Inkscape uses some functions that only appeared in 2.6. I've submitted a bug report and patch here:
Thanks. Something like this was already in svn to fix the CentOS 4.2 build failure (1505373). But yours reminded me that it could be done more correctly by including config.h.
And I have to apologize, partly.
The reason why inkscape lost glib-2.4 support was, largely, due to my stripping some lines including config.h in the Great Include Purge.
OTOH, Bryce did not catch this with his supposedly 2.4 test system, so has some homework now, too.
ralf
participants (5)
-
Aaron Spike -
Jean-François Lemaire -
Mike Hearn -
Ralf Stephan -
Thomas Leonard