<mark_weaver>when regexp-exec tries to convert this narrow string to a "locale string", it interprets the bare 0xA9 as UTF-8. but 0xA9 is in the range of bytes that's only allowed as a non-initial byte of a multi-byte sequence. so it will raise an error.
<mark_weaver>I guess that what was happening before is that all non-ASCII Latin-1 characters were getting turned into ?
<mark_weaver>toothbrush0: tput is part of the 'ncurses' package. you need to add 'ncurses' to either native-inputs or inputs (depending on whether it is used during the build or after installation, an important distinction when cross-compiling), and then you'll need to arrange for it to not look for it in /usr/bin
<mark_weaver>toothbrush0: is tput needed at run time or build time?
<mark_weaver>if "/usr/bin/tput" is hardcoded in the source, you'll probably need to patch it with 'substitute*'.
<mark_weaver>if it's only used at build-time, then you could just change it to "tput", since it will be found in PATH during the build if ncurses is in native-inputs.
<mark_weaver>if it's needed at run-time by the user, then "/usr/bin/tput" should be replaced with the absolute path "/gnu/store/.../bin/tput".
<toothbrush0>mark_weaver: ah, thanks for the info. It's only build-time, i believe.
<rekado>hmm, the guix-packaged solfege starts with the Fedora phython (with the Guix pygtk in the PYTHONPATH), but with the Guix python it won't work.
<rekado>the error with Guix python is "ImportError: could not import gio" (after explicitly adding site-packages/gtk-2.0 to the PYTHONPATH).
<mark_weaver>rekado: it might need to load an .so file as well. maybe run it under 'strace' to find out what it's looking for but failing to find?
<mark_weaver>if it's looking for a *.so, setting LTDL_LIBRARY_PATH to include the directory with the *.so might be the answer. it could be added with a wrapper.
<toothbrush0>Is there a "general" way of handling applications and plugins which are bundled/compiled separately? They're all rather interdependent: the application builds, but the plugin depends on the application and says it cannot be built as a dependency...
<mark_weaver>toothbrush0: what do you mean by "the plugin depends on the application and says it cannot be built as a dependency..." ?
<mark_weaver>typically there is an environment variable to tell the application where to look for plugins
<mark_weaver>and we declare search path specifications to handle setting those variables automatically during builds and to remind the user to set those variables.
<mark_weaver>typically such an environment variable would contain $HOME/.guix-profile/???/
<mark_weaver>all the plugin packages would install in <%output>/???/ and those will all be merged together into a single directory in the user's profile, which is then found via the environment variable.
<toothbrush0>So i have an application which only has two options for specifying plugin directory: command-line or hard-coded... It feels smelly to hard-code something like $HOME/.guix-profile/lib/.. as the plugin dir, but it's also rather uncool to force users to use a cmdline arg every time...
<toothbrush0>I've looked around in the code and it looks as if it doesn't support ENV variables.
<mark_weaver>because it can't accommodate any environment variable, not even $HOME as part of it.
<mark_weaver>you can look at gnu/packages/patches/xfce4-panel-plugins.patch for the modifications I made to xfce4-panel, but don't be scared off by it. xfce4-panel turned out to be quite a bit more complex than should be needed here, for various reasons.