On Sun, 03 Jul 2005 11:16:13 +0200 David MENTRE <[EMAIL PROTECTED]> wrote:
> As usual, if you find something the burden you as a package > maintainer, don't hesitate to warn upstream. ;) Really, there was not much things to change in this release for it to compile and work fine on Gentoo. If you look at the ebuild, you will see that: - I had to change "equeue" into "equeue-core" for the EQUEUEDIR declaration in the Makefile, since that's where the module contents actually is here (with equeue-2.0.1). In /usr/lib/ocaml/equeue, all I have is a META file, with "equeue-core" in the requires. I'm not sure exactly, but there is probably something here that ocamlfind could solve automagically. Something like this should follow the requires and output in "-I /path/to/equeue -I /path/to/equeue-core" format: EQUEUEFLAGS:=$(shell ocamlfind query -i-format -recursive equeue) I think that in general, it would be a good idea to switch to such recursive queries in the Makefile or future configure script, cause it would also solve issue where some modules deps are missing (like in a previous version where i had to add expat or curl to the Makefile depending how cduce was compiled). - I've had to add "-I /usr/lib/ocaml/site-packages/stublibs" to the CLNT_OCAMLINC, otherwise compilation was failing with: ---------------------------------------------------------------- ocamlc.opt -I net -I lib -I /usr/lib/ocaml/site-packages/gz -I /usr/lib/ocaml/site-packages/equeue-core -I /usr/lib/ocaml/site-packages/rpc -I gtk2-clnt -I +lablgtk2 -g -warn-error A -o gtk2-clnt/demexp-gtk2-client.bc unix.cma equeue.cma rpc.cma str.cma bigarray.cma gz.cma lablgtk.cma lablglade.cma net/messages_aux.cmo net/messages_clnt.cmo net/messages_srv.cmo config.cmo gtk2-clnt/demexp_gladeui.cmo lib/perf.cmo lib/norm.cmo lib/time.cmo lib/timestamp.cmo gtk2-clnt/clntflags.cmo gtk2-clnt/misc.cmo gtk2-clnt/pref.cmo gtk2-clnt/cache.cmo gtk2-clnt/clerk.cmo gtk2-clnt/users.cmo gtk2-clnt/tags.cmo gtk2-clnt/newquestion.cmo gtk2-clnt/clsf.cmo gtk2-clnt/addrep.cmo gtk2-clnt/vote.cmo gtk2-clnt/browser.cmo gtk2-clnt/url.cmo gtk2-clnt/demexp-gtk2-client.cmo Error on dynamically loaded library: dllmlgz.so: cannot open shared object file: No such file or directory make: *** [gtk2-clnt/demexp-gtk2-client.bc] Error 2 ---------------------------------------------------------------- It sounds strange to explicitly include this dir, i would have thought it was in some kind of default path or something. I don't know what would be the clean fix here, maybe that's also something where ocamlfind could help, or maybe it's a Gentoo/Ocaml issue. On Debian, is this directory in the /etc/ld.so.conf or something like that? Other than this two compilation issues, my ebuilds are just about installing stuffs at the right place, and adding things like an init script for the server, etc., so there is not much that you could improve to ease that task (which is already quite easy actually). If you really want improvement requests, one item i would add to your TODO is a logging system for the server: it would be nice if it could have at least a "--logfile /path/to/logfile" option (because right no, to get a logfile while launching it via start-stop-daemon, i must use a wrapper shell script to make the stdout/stderr redirection, and that's not really beautiful). And sure, all the other features of a unix daemon (taking care of its pid file, dropping privileges, detaching to background, etc.) would be nice too, but this ones can be emulated by start-stop-daemon, so i don't miss them as much as the logfile option. Oh, and one last very simple request: there is much valuable info in your 0.6 announcement text, so don't forget to include it somewhere in the source tarball so that packages can install a copy in /usr/share/doc :) > Once again, if you want to add Gentoo specific information on > this page, let me know (or send me a patch against web CVS ;). Bah, there's a README in my repository, so there's no real need to clutter your web page with more Gentoo-specific details i think. > As fred, I'm also interested about that. How does it work? Can > it trigger the opening of the client if we have demexp:// URI > (URL?) inside a Gnome application? Yup, exactly. Actually, it's pretty simple: - copy the attached "demexp.schemas" in /etc/gconf/schemas - run the following commands as root (that's basically what the "gnome2_install_gconf_schemas" function do in my client ebuild): # export GCONF_CONFIG_SOURCE=$(gconftool-2 --get-default-source) # gconftool-2 --makefile-install-rule \ /etc/gconf/schemas/demexp.schemas - you should now have some "/desktop/gnome/url-handlers/demexp/*" keys in your gconf base. And that's it. From now, clicking a "demexp://something" link in a Gnome-aware application (like Epiphany or Galeon, or even Firefox if it's compiled with the right options) will launch "demexp-gtk2-client <your_url>". Maybe you could put the .schemas file and this short explanation in the misc/ directory, it may be useful for other packagers. As for the URI vs. URL distinction, eh, i don't really know what the difference is, so i randomly use one or the other. `wtf` doesn't help much here: % wtf url url [uri] (7) - uniform resource identifier (URI), including a URL or URN Go figure... -- TGL.
demexp.schemas
Description: Binary data
_______________________________________________ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev