demexp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Demexp-dev] demexp 0.5.2


From: Thomas de Grenier de Latour
Subject: Re: [Demexp-dev] demexp 0.5.2
Date: Sun, 3 Jul 2005 13:36:07 +0200

On Sun, 03 Jul 2005 11:16:13 +0200
David MENTRE <address@hidden> 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.

Attachment: demexp.schemas
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]