On Tue, Jun 19, 2012 at 10:51 AM, Alexander Foremny <[email protected]> wrote: > Hello, > > I am trying to create a Nix expression for solfege [1] and got it > building fine using the Nix expression available as Gist [2]. > However, running the application fails with the following error, > cryptographic hashes replaced by dots. > >> Traceback (most recent call last): >> File "/nix/store/...-solfege-3.20.4/share/solfege/solfege/startup.py", >> line 159, in start_gui >> solfege.win = w = MainWin(options, datadir) >> File "/nix/store/...-solfege-3.20.4/share/solfege/solfege/mainwin.py", >> line 119, in __init__ >> stock.SolfegeIconFactory(self, datadir) >> File "/nix/store/...-solfege-3.20.4/share/solfege/solfege/stock.py", line >> 71, in __init__ >> self.add_icons(d) >> File "/nix/store/...-solfege-3.20.4/share/solfege/solfege/stock.py", line >> 33, in add_icons >> iconset = >> gtk.IconSet(gtk.gdk.pixbuf_new_from_file(os.path.join(self.datadir, >> filename))) >> glib.GError: Couldn't recognize the image file format for file >> '/nix/store/..-solfege-3.20.4/share/solfege/graphics/solfege.svg' > > This issue has been addressed [3] and appears to be an issue not > caused by solfege but by a missing python dependency [4]. It is solved > by making solfege depend on python-rsvg. However, I cannot find this > package in Nixpkgs. Further research revealed that this binding is now > part of the Python bindings to Gnome [5]. As observable in the current > NIx expression I added the dependency gnome_python hoping this would > solve the problem. However, it does not. > > Is it correct that gnome_python are the Python bindings to Gnome > Desktop which should contain pyrsvg? If not, is pyrsvg already > packaged? If not, where can I find the sources of python-gnome-desktop > and where would be a good place to place a Nix expression for this? > > Or could it be the case that this functionality should be supplied by > pygtk, but this (optional?) feature is disabled due to missing > dependencies?
I ran into the same issue trying to package key-mon [1], your debugging helped a lot. I've packaged python-rsvg, and I had to change python-gnome so that python-rsvg could be built and I also needed to enable the librsvg pixbuf-loader (previously disabled): https://github.com/cillianderoiste/nixpkgs-goibhniu/tree/python-rsvg This should work with solfege too since I got exactly the same error, but you'll need to wrap it with something like: wrapProgram $out/bin/solfege --prefix GDK_PIXBUF_MODULE_FILE : ${librsvg}/lib/gdk-pixbuf/loaders.cache Since I use buildPythonPackage for key-mon, this results in a wrapper which wraps another wrapper. It all seems to work fine though. One concern is that if you wrap a program as described, then it will only be able to open svg files and not other formats. If this is a problem, the loaders.cache file could be concatenated with the gdk-pixbuf loaders.cache [2] and then that could then be used as the GDK_PIXBUF_MODULE_FILE. I bet there are smarter, nixian ways to do such a thing! On a typical distro these loaders are added to a global directory like /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/ then gdk-pixbuf-query-loaders is used to update /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache when a new loader is added. In the case of pygtk (and presumably for gtk in general [3]) gtk.gdk.pixbuf_new_from_file uses this file to find the loaders for the various formats. These changes would cause a massive rebuild (1110 packages, based on comparing the drv-paths), so I won't even add them as a pull request yet. It would be great to hear if there are more elegant ways to approach this. All the best, Cillian [1] http://code.google.com/p/key-mon/ [2] e.g. /nix/store/fimfm5ybk2m7iklsm78b84v7sy8flvgw-gdk-pixbuf-2.24.1/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache [3] http://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-query-loaders.html > [1] http://solfege.org > [2] https://gist.github.com/2953069 > [3] http://code.google.com/p/solfege/issues/detail?id=255 > [4] https://bugs.launchpad.net/ubuntu/+source/solfege/+bug/1004485 > [5] http://www.rittau.org/blog/20060418-00 _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
