<Sedrikov>
hcarty: all these packages define environnement variables useful for other packages
<hcarty>
Sedrikov: Good! I'm glad it works.
<hcarty>
Sedrikov: I'm just going by what is done for PCRE, Lapack, Gtk+ and others.
<Sedrikov>
hcarty: ok gsl is installed
<Sedrikov>
hcarty: cairo has none since it has no environnement variables defined, although it is a binding. I don't see what I could put in a cairo conf-*
<hcarty>
The same basic logic could be used for the GSL and Cairo bindings.
<hcarty>
In the mean time, a "make check" target which is required by "make all" would probably provide a reasonable short-term solution.
<hcarty>
Sedrikov: I'll have to ask Gerd what the appropriate approach is. Most of the established C and Fortran library bindings in GODI seem to have matching conf- packages.
<Sedrikov>
hcarty: but I am not sure a conf package is the good idea, conf packages are mostly here to set environnement variables for godi; so that all depending libraries can use it
<hcarty>
s/though//
<hcarty>
I don't think it has a way to pick up any configured values though without manual post-processing of the godi-* package output from godiva.
<hcarty>
I haven't tried it though.
<hcarty>
godiva has options for conf packages
<Sedrikov>
hcarty: in fact conf-* are like godi-* packages, but cannot be made via GODIVA (if you used it)
<hcarty>
Sedrikov: A basic conf package should be pretty simple to do. I'm not sure how to do proper version checking though.
<Sedrikov>
hcarty: you must be right I forgot to do it, maybe a configure script telling that the lib is not found would be better (but that is not your fault)
<hcarty>
This is why I need to learn to make conf- packages for GODI :-)
<hcarty>
gsl-config should be in $PATH
<hcarty>
Do you have the GSL development package installed?
<hcarty>
Sedrikov: There shouldn't be
<Sedrikov>
hcarty: is there a script that must be run before?
<Sedrikov>
hcarty: did you add a file (in ocaml-sgl/file) you forgot to move or something like that?
<Sedrikov>
hcarty:
<Sedrikov>
hcarty: taking a look at ocamlgsl, I got an error: "gsl-config : commande introuvable" [that is "command not found"]
<hcarty>
I look forward to hearing more about it as it progresses
<hcarty>
How is the new language coming along? Out of curiosity, will it have OCaml-like type inference?
<hcarty>
Yoric[DT]: Just curious. Given that your language focus is elsewhere now, it's quite understandable if you're unable to do so.
<Yoric[DT]>
hcarty: I'll try and check today.
<hcarty>
Yoric[DT]: How did your efforts with coThreads turn out?
<hcarty>
Yoric[DT]: Hello
<Sedrikov>
hcarty: it is a problem in the packaging, but it may be fixed now
<Sedrikov>
hcarty:
<Sedrikov>
hcarty:
<hcarty>
If it's a problem in the library then I can commit a fix if we find one.
<hcarty>
Sedrikov: Is this a problem in Cairo-OCaml or in the packaging?
<Sedrikov>
hcarty: in fact cairo is a little bugged, I assume lablgtk was installed in your system, I have reinstalled GODI today and tried to install cairo without having installed lablgtk and lablgtk2; it did not work. Then I modified the dependencies in the Makefile and it worked, but some flaws may have stayed...
<hcarty>
Sedrikov: svn worked for me (co and ci) but the web site did not.
<Sedrikov>
hcarty: what link was it? I have tried "svn ci" and to connect to the administration part of the svn.
<hcarty>
Also, mlpost works here now. So excellent work on all three packages :-)
<hcarty>
The text was correct, but the actual link was not.
<hcarty>
There was a problem in the GODI email I received - one of the links was incorrect
<hcarty>
Sedrikov: Where are you having password troubles?
<Sedrikov>
hcarty: my packages are ready, but I had some problems with my password, then I'll commit them. Next week I hope to make them available for GODI users, having time to test by submitters
<Sedrikov>
hcarty: ok
<hcarty>
Sedrikov: Thanks for the update on mlpost. I'm getting the extra texlive package now and will test again once it's installed.
<hcarty>
Oops ... sorry about that
<hcarty>
Sedrikov: /away
<hcarty>
Is anyone here still working on ocamlfind/GODI updates for packages?
2009-09-09
<hcarty>
I am off as well, take care all
<hcarty>
Thanks again for your time on this!
<hcarty>
bluestorm: Sleep well then, and we can talk more about this tomorrow.
<cedric_>
hcarty: trying to type each statements one after the other of the last command from the good directory and the good rights (but I don't know them)?
<hcarty>
cedric_: Yes, I don't know how to get a better error from that.
<hcarty>
bluestorm: If you feel the urge to work on it yourself, the godi-ocamlgsl directory has the gsl.godiva file which may provide some insight. And the online documentation is good as well.
<cedric_>
hcarty: tomorrow only, from where I am it is not very convenient
<hcarty>
bluestorm: I may be able to godiva-fy your work on Deriving, but it won't be until several hours from now at the earliest. I'll send you the results once I have some.
<hcarty>
cedric_: Will you be uploading and maintaining your three packages?
<hcarty>
I need to go for an hour or maybe more. I'll post a message to the OCaml list some time later this evening with a summary of the day's progress.
<hcarty>
Yes, # starts a comment
<hcarty>
bluestorm: # I think
<hcarty>
There is a _build directory, for example
<hcarty>
It looks like it is in the failed build state
<cedric_>
hcarty: and empty, are some of the files of the command presents?
<hcarty>
The work/ directory is there
<hcarty>
OCaml 3.11.1
<hcarty>
cedric_: Ubuntu 9.04 64bit
<hcarty>
cedric_: I wonder the same thing :-)
<cedric_>
hcarty: that seems ok... the error of the compilation is not very verbose... "mkdir -p img/ && cd img/ && ../customdoc/img_doc.byte >> /dev/null && cd .. + mkdir -p img/ && cd img/ && ../customdoc/img_doc.byte >> /dev/null && cd .." which one of the four commands has failed?
<hcarty>
cedric_: Nothing immediately obvious
<hcarty>
This is MetaPost, Version 0.993 (Web2C 7.5.6)\n**
<cedric_>
hcarty: is metapost well installed (try to run mpost and see if you have a teX-like interactive command line)
<hcarty>
cedric_: I tried deleting the build directory and restarting the process, but had the same error.
<cedric_>
hcarty: I tried to install mlpost here and had no problem, during the configure, the program didn't recognized your platform; and maybe old files polluted the repository. Some usefull command is godi_make [install/clean/delete], see the documentation of GODI; another thing is to delete the work directory in godi/build/godi/godi-*/ to erase all old generated files
<hcarty>
bluestorm: Thanks, I'll see if I can get that working here. If I do and you are still around I will let you know.
<hcarty>
At least two of those four (cairo and mlpost) are just small steps from completion.
<hcarty>
Ok, from my count we now have three packages _DONE_ and four more in progress.
<hcarty>
It's not pushable (or clonable) from outside, sadly. I need to figure out how to do that at some point. You can send the patch + META though.
<hcarty>
bluestorm: Is it fair to say that work on deriving is "In progress"?
<hcarty>
bluestorm: godiva is pretty straightforward. I may be able to take a stab at it today.
<hcarty>
Very nice
<hcarty>
:-) That tends to happen as it gets late.
<hcarty>
I don't remember if that's ocamlopt only or both opt and c.
<hcarty>
bluestorm: Is -linkpkg needed?
<hcarty>
bluestorm: What's the error?
<hcarty>
I can send the build log if you want it.
<hcarty>
It may have left some cruft behind from the failed build.
<hcarty>
cedric_: I'll try to clean things out. When I first tried to build mlpost, it failed because of a missing mpost.
<hcarty>
The other packages (cairo, bitstring, gsl, uuidm) all build correctly though.
<hcarty>
Yes, it seems to have come from the doc generation.
<hcarty>
It's a mkdir command... something with docs maybe.
<hcarty>
cedric_: I'm getting errors when trying to install mlpost. I'm not sure what they are coming from though.
<hcarty>
I will hopefully, at some point, learn my way around GODI well enough to package PLplot. I think that will be a pretty significant undertaking though.
<hcarty>
It looks pretty nifty. Not something I need at this point, but interesting none the less.
<hcarty>
mlpost is first I have heard of this program.
<hcarty>
Thanks. I'm testing the packages on my system.
<hcarty>
cedric_: (if you know) - Is texlive-metapost the package I need to build mlpost?
<hcarty>
Yoric[DT]: Cool, thanks again for taking part
<hcarty>
cedric_: Thanks
<hcarty>
cedric_: There will hopefully be a proper 1.2.0 release at some point, and without that I think the version comparisons may have trouble going from a date to a "normal" version.
<hcarty>
cedric_: If you are going to upload and maintain the Cairo OCaml GODI package, could you change the version number to 1.2.0?
<hcarty>
Camarade_Tux to the rescue :-)
<hcarty>
cedric_: I don't remember :-) I'll look it up.
<cedric_>
hcarty: thanks, for having a native version of godi, what did you do? add the target opt to the godi-tools Makefile?
<hcarty>
cedric_: I found that out as well when digging in to the Makefile
<hcarty>
cedric_: Yes, I set it up to use yes/no if you want to grab the files from 0ok.org
<cedric_>
hcarty: oups, I have done mistakes, my default values are in range {yes/no} and not {true/false}
<hcarty>
Yoric[DT]: Any idea how it happened?
<hcarty>
Yoric[DT]: Oh my - that's not good at all
<cedric_>
hcarty: ok, so I will try to do it too
<hcarty>
Almost unbelievably large.
<hcarty>
cedric_: We both tried it, and it does indeed provide a large speedup.
<cedric_>
hcarty: did Camarade_Tux (IIRC) compiled it in native code to compare or did he only emit the idea?
<hcarty>
gerdstolpmann: Camarade_Tux (IIRC) brought up the idea of using a native code godi_console. It greatly increases the speed of the program. Is there a configuration option to have it built by default?
<hcarty>
gerdstolpmann: Thank you very much
<hcarty>
cedric_: Sounds good. I'll update my end as well
<cedric_>
hcarty: Ok, that is cool; I knew it without the default option, but I will change it tomorrow on my repository
<hcarty>
cedric_: Your Cairo package works here
<hcarty>
Yes, works here for the Cairo package.
<hcarty>
gerdstolpmann: Thanks
<cedric_>
hcarty: yes I didn't thought of it, but it is natural
<cedric_>
gerdstolpmann, hcarty: I also have a question about giving default value to an option in CONFOPTS, how do we do it?
<hcarty>
cedric_: It looks like default settings for CONFOPTS are set in the Makefile
<hcarty>
gerdstolpmann: Thank you for stopping by!
<cedric_>
hcarty: Cool Gerd is here, we can ask him!
<hcarty>
I'll look around some more.
<cedric_>
hcarty: I don't know either, I never tried to do it
<hcarty>
If I make the line "GODI_MLPOST_CAIRO_SUPPORT=yes" then it thinks that is the option name.
<hcarty>
I'm not sure how to define default options
<hcarty>
Should I do the same for the Cairo lablgtk2 option? Only in that case, I suppose "false" may be a better default.
<hcarty>
cedric_: Do I just change the line to "GODI_MLPOST_CAIRO_SUPPORT=true"?
<hcarty>
And/or away on vacation :-)
<hcarty>
I emailed him about a separate GODI question and have not heard back. My guess is that he has been busy.
<hcarty>
I'll start making some noise on the GODI list once today is complete.
<hcarty>
cedric_: Hopefully we can all get GODI accounts :-)
<cedric_>
hcarty: Ok
<hcarty>
hans_: I'll add your package there as well
<hcarty>
hans_: There was a post about this recently on the mailing list...
<hans_>
hcarty: maybe just submitting to the mailing list might be just as good, if no one here has write access to the SVN repository and can take the responsibility of submitting packets created by this effort
<hcarty>
Yoric[DT]: Changing the topic is not a bad idea... how do you do it? :-)
<hcarty>
Packages can also be submitted to the GODI mailing list.
<hcarty>
orbitz: Anyone can request the ability to do so.
<hcarty>
bluestorm: Should we collect packages by email?
<hcarty>
cedric_: It's beyond mine as well, at least as much as time allows. I think godiva could be used to make the configuration package, but I'm not certain of that.
<cedric_>
hcarty: for the moment such a conf-* is beyond my abilities, but it should be a piece of cake for persons familiar to those things; but for that GODIVA won't help...
<hcarty>
cedric_: Not a problem :-)
<hcarty>
cedric_: Check for the dev files and a recent enough version, similar to how conf-pcre behaves.
<cedric_>
hcarty: I understood it 0.5 s after posting, sorry
<hcarty>
cedric_: No, I mean the system Cairo, not the OCaml bindings.
<cedric_>
hcarty: I don't think there will be often updates on the version of cairo and if there is, somebody must make it, in the sense that there is no tar.gz for cairo-ocaml; I had to checkout cairo-ocaml, then make the tar.gz file and upload it, so an update of the version should consist in remaking the tar.gz then commit the package to godi repository; no conf-* is required (nor usefull) for that
<bluestorm>
hcarty: for the record, I did the trick by declaring LIB_PACK_NAME with the name of the produced .cmo : i'm still building it myself instead of using OCamlMakeFile rule, but the predefined "make clean" knows about LIB_PACK_NAME.cm*
<hcarty>
cedric_: I don't follow.
<cedric_>
hcarty: the update function of godi_console is here for that
<hcarty>
Just getting a few more of these packages in to GODI will be a big help.
<hcarty>
cedric_: And I'm not sure, as you suggest, that it is needed in general.
<hcarty>
cedric_: The purpose would just be to check for a recent enough version of Cairo. But I don't think it's needed yet.
<cedric_>
hcarty: my godi package has no conf-* for cairo, but I am not sure such a package should be usefull...
<hcarty>
That, unfortunately, is beyond my knowledge.
<hcarty>
bluestorm: I used to use OCamlMakefile a lot, but it has been a while.
<hcarty>
bluestorm++ for the idea
<hcarty>
They still need to be submitted and put in to GODI. But it's a very nice start.
<hcarty>
6 packages would be a reasonable success for today, I think.
<hcarty>
Yoric[DT]: Thanks for coming by.
<hcarty>
Hooray!
<hcarty>
GSL and Cairo could use some love, as they should both depend on conf-(gsl|cairo) packages.
<hcarty>
Yoric[DT]: It's going reasonably well. One package by me, the 3 submitted by cedric_ before today, and bluestorm is working on at least one other.
<hcarty>
cedric_: That makes sense - I thought the godi_* tools did some sort of directory scanning.
<hcarty>
bluestorm, cedric_: Do you just copy those files to a new build/foo/ directory to get GODI to recognize the local package?
<hcarty>
cedric_: Also, why are the "opt" portions commented out?
<hcarty>
cedric_: Did you make any modifications to the upstream cairo-ocaml code in the .tar.gz you provide?
<hcarty>
Alpounet: We will look forward to it :-)
<Alpounet>
hcarty, ok, thanks. I'll try to read that when I'll have enough time, and then get back here asking for libraries to package :)
<hcarty>
cedric_: It's next on my list to try
<hcarty>
Alpounet: godiva requires a .godiva file (simple syntax, see the docs linked from the wiki) and any extra files/patches required to make the library's build system match what GODI expects.
<hcarty>
bluestorm: That sounds reasonable (META + talking with upstream)
<hcarty>
Alpounet: For simple (and not so simple) packages, godiva does a lot of the heavy lifting.
<Alpounet>
time's hugely missing in here bluestorm, hcarty, but try to keep some work for me, later !
<hcarty>
Alpounet: Seconded!
<hcarty>
s/from/on/
<hcarty>
So if anyone here has GODI and the GSL development pacakage(s) installed from their system, that's ready to test.
<hcarty>
I'm completed a GSL package, and there are the packages from Cedric
<hcarty>
bluestorm: I started looking at deriving earlier and decided it might be better suited for your talents :-)
<hcarty>
bluestorm: cgit will make .tar.gz/.zip/etc files for download.
<hcarty>
Sounds good to me. Or I can make it available by cgit
<hcarty>
bluestorm: I haven't heard much of anything from others who may be taking part
<bluestorm>
hcarty: i think "direct" hosting would be interesting
<hcarty>
bluestorm: I can host the files in the short-term, either directly or make a git repo
<hcarty>
bluestorm: Just got back from lunch
<bluestorm>
hcarty: I'm back, where can I help ?
<flux>
hcarty, well, plain CGI is even simpler
<hcarty>
flux: Even being able to toy with that under normal CGI would be interesting. Thanks for the tip.
<hcarty>
flux: That's pretty nifty - was it difficult to put together?
<hcarty>
I have a .godiva file and relevant patches for installing the OCaml GSL bindings under GODI.
<hcarty>
One package down! At least on my system...
<blue_prawn>
hcarty: you're wellcome :)
<hcarty>
blue_prawn: Thank you for doing that.
<hcarty>
blue_prawn: But the majority of existing users and packages use the name "zip"
<hcarty>
?
<hcarty>
blue_prawn: What ocamlfind options would you currently use in Mandriva to use the library? "-package zip" or "-package camlzip"
<hcarty>
blue_prawn: I think it should be changed in Mandriva and GODI to match Debian and Fedora
<hcarty>
misinformation
<hcarty>
blue_prawn: My apologies for the misinformatin!
<hcarty>
blue_prawn: It is used in other ways. For example, package listings.
<hcarty>
blue_prawn: For example, in my GODI install, "ocamlfind install zip META" will install the META file to lib/ocaml/site-lib/zip/
<hcarty>
blue_prawn: Yes, I suppose so, where the name is determined by the "ocamlfind install" command.
<hcarty>
blue_prawn: If the META file is included upstream then there is no need
<blue_prawn>
hcarty: so the name of the dir ?
<hcarty>
blue_prawn: The findlib package name is set by the "ocamlfind install" command.
<hcarty>
blue_prawn: And I apologize - I was wrong about the META file naming and package naming.
<hcarty>
Or at least the same package name in the META file, if not exactly the same META file.
<hcarty>
If the META file is added upstream OR all of the packagers use the same META file, then the problem is resolved.
<hcarty>
There is no consistent name to use to indicate that this library is a prerequisite.
<hcarty>
This breaks packages which rely on the zip/camlzip library.
<hcarty>
Debian had the first package. Then GODI, then Fedora. Debian and Fedora use "zip" for the name, GODI, and apparently Mandriva as well, use "camlzip".
<blue_prawn>
hcarty: consistently with what ?
<hcarty>
As long as the same name is used consistently then I see no problem.
<hcarty>
blue_prawn: The bug, as I see it, is the inconsistency.
<blue_prawn>
hcarty: I don't understand if you consider it as a bug it should be changed, no ?
<hcarty>
But, from the conversation around that report, I learned the bits and pieces I mentioned earlier.
<hcarty>
blue_prawn: I assumed "camlzip" was the better name as well, which is why I submitted a bug report to Debian.
<blue_prawn>
hcarty: OK
<hcarty>
blue_prawn: If you wouldn't mind, I think changing it to "zip" would be best.
<hcarty>
Sorry - the "of course" was "of course there is further inconsistency"
<hcarty>
Of course...
<hcarty>
blue_prawn: HA
<hcarty>
Then using "zip" will be generally safe.
<hcarty>
If xleroy does not want to include an official META file then I'll submit the work-around META file to GODI.
<hcarty>
blue_prawn: "zip" seems to be the general consensus. camlzip installs to a "zip" directory by default, and the Debian package was around first.
<hcarty>
Rather, the name defined in the META file is the name used for the package
<hcarty>
blue_prawn: No, the name is defined in the META file
<hcarty>
The simple work-around is to install a dummy "zip" package in GODI, which has nothing itself but requires "camlzip"
<hcarty>
Yes
<hcarty>
blue_prawn: One has the name as zip (Debian), the other camlzip (GODI).
<hcarty>
blue_prawn: Again, the patch does not have to be accepted. It's not really worth getting angry over a well-intentioned submission.
<hcarty>
flux: Yes, I'm not sure how that works out for non-OCaml projects. The reasoning, from what I understand, behind not accepting outside patches for OCaml is because it hinders their ability to relicense.
<hcarty>
And if he does, then it is beneficial to submit one.
<hcarty>
Still - the reasoning stands that if he does not want to accept the patch then he does not have to.
<hcarty>
blue_prawn: I don't know of a patch, but that doesn't mean it hasn't been sent.
<hcarty>
blue_prawn: There is a bug report open about this now in Debian, due to the naming diferrence for camlzip between Debian and GODI.
<blue_prawn>
hcarty: I think debian did, because it is written in thier policy to do so
<hcarty>
AFAIK, no one has sent him a patch yet.
<hcarty>
blue_prawn: If no one has submitted one, and he doesn't use findlib, why should he?
<blue_prawn>
hcarty: (for example in camlzip)
<blue_prawn>
hcarty: he doesn't include the META in his tarballs
<hcarty>
blue_prawn: What does Xavier Leroy have to do with this, and why should it be explained to him?
<hcarty>
If software has a bug that a user finds and fixes, and the author is available - should they not submit a fix?
<hcarty>
blue_prawn: Software is very different from a physical thing.
<hcarty>
blue_prawn: But if users of software want to contribute, why shouldn't they?
<hcarty>
flux: Indeed :-)
<blue_prawn>
hcarty: there are still a lot of tarballs without META file
<hcarty>
blue_prawn: But why do it that way, when it is such a common part of the OCaml community?
<hcarty>
blue_prawn: If one does not want submissions from others, then just state that clearly and people will stop submitting them.
<hcarty>
blue_prawn: But upstream submission should - then it's up to them if the change is included or not.
<blue_prawn>
hcarty: probably but not all
<hcarty>
The submitter could always be asked to maintain the META file.
<hcarty>
blue_prawn: From my limited experience, most authors are happy to receive such contributions.
<blue_prawn>
hcarty: yes this is what I say
<hcarty>
blue_prawn: Then don't accept the patch? If you don't like it, you don't have to keep it.