Spec URL: http://annexia.org/tmp/ocsigen/ocsigen.spec SRPM URL: http://annexia.org/tmp/ocsigen/ocsigen-1.1.0-5.fc10.src.rpm Description: Web programming framework rpmlint says: ocsigen.i386: W: non-standard-uid /var/log/ocsigen apache ocsigen.i386: W: non-standard-gid /var/log/ocsigen apache Not entirely sure what this means. We reuse the same 'apache' user as Apache itself (created, if it doesn't exist, %pre, just like Apache). ocsigen.i386: W: unstripped-binary-or-object /usr/bin/ocsigen ocsigen.i386: W: unstripped-binary-or-object /usr/lib/ocsigen/extensions/ocsidbm These are OK, per the packaging policy: http://fedoraproject.org/wiki/Packaging/OCaml#Stripping_binaries ocsigen.i386: W: percent-in-%pre Strange one. My %pre is exactly the same as the Fedora Apache package. ocsigen.i386: W: ocaml-naming-policy-not-applied /usr/lib/ocaml/ocsigen/ocsigen_headers.cmi That's OK - programs don't need to be called ocaml-* ocsigen.src:85: W: configure-without-libdir-spec Yes, because this isn't autoconf.
This fails to build for me in rawhide. The failure is long so I thought I'd do a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=809571 but that proceeded to fail because cduce-devel is not available on ppc64. So here's a scratch build on x86_64 only: http://koji.fedoraproject.org/koji/taskinfo?taskID=809581
Looks like a build dependency on ocaml-camlp4.
Seeing how the Ocsigen home page says "02/09/08 Ocsigen and Lwt in Fedora", maybe we ought to work on making it true? I just tried to build the srpm on a local f10-x86_64 box (w/all current updates) with no success. I did ferret out a few missing BuildRequires: ocaml-camlp4-devel for /usr/bin/camlp4 ocaml-ocamlnet-devel for -lnetaccel_c ocaml-pcre-devel for -lpcre_stubs Now it gets all the way past %doc and dies with: File not found: /home/wes/rpmbuild/BUILDROOT/ocsigen-1.1.0-5.fc10.x86_64/usr/lib64/ocsigen Looking at the build output, I see a "Checking for ocamlduce... not found", but I see no ocamlduce in the repo (I do have cduce installed of course). also diff: xHTML.mli: No such file or directory and later ocamlyacc http_parser.mly 4 shift/reduce conflicts. But I have no immediate idea what to do with that. Does someone who actually knows the ocaml buildsystem (Richard?) want to take another stab at this?
Here's an updated package which fixes everything in comment 3 and builds in Koji: Spec URL: http://www.annexia.org/tmp/ocaml/ocsigen.spec SRPM URL: http://www.annexia.org/tmp/ocaml/ocsigen-1.1.0-8.fc11.src.rpm * Tue Jan 13 2009 Richard W.M. Jones <rjones> - 1.1.0-8 - Add some missing BRs (thanks Wes Shull). - Make sure examples, extensions get installed in _libdir. - ExcludeArch ppc64. Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1049581 Note that we cannot yet build ocamlduce for OCaml 3.11.0 as we are waiting for upstream to release a new version: http://www.cduce.org/ocaml_install.html Since I don't really use ocsigen at the moment, I can't say whether this gravely affects the functionality of this package. However it does compile OK without ocamlduce.
I can verify it now builds, installs, and runs (only did basic testing) without error for me on f10-x86_64; thanks Richard. A few minor points: * /usr/bin/ocsigen is system_u:object_r:bin_t; do we maybe want to make it system_u:object_r:httpd_exec_t like apache httpd since it's "just" another webserver? * I got no -debuginfo package out of the build, and /usr/bin/ocsigen is not stripped. * The ocsigen quickstart page indicates most distros include an initscript, which we seem to be lacking. I'd volunteer but shell scripts make me want to gouge my eyes out. Apart from these potential considerations, looks good to me. Should I start rabble-rousing on the -devel list to get some real certified reviewers on this?
(In reply to comment #5) > I can verify it now builds, installs, and runs (only did basic testing) without > error for me on f10-x86_64; thanks Richard. > > A few minor points: > > * /usr/bin/ocsigen is system_u:object_r:bin_t; do we maybe want to make it > system_u:object_r:httpd_exec_t like apache httpd since it's "just" another > webserver? I have absolutely no idea how to do this, but sure it sounds like a good idea. > * I got no -debuginfo package out of the build, and /usr/bin/ocsigen is not > stripped. Debuginfo isn't really that useful for OCaml programs, since gdb doesn't know about OCaml. So you end up having to debug assembler. > * The ocsigen quickstart page indicates most distros include an initscript, > which we seem to be lacking. I'd volunteer but shell scripts make me want to > gouge my eyes out. Probably best to copy the one from Debian, if they have one: http://git.debian.org/?p=pkg-ocaml-maint/packages/ocsigen.git;a=summary > Apart from these potential considerations, looks good to me. Should I start > rabble-rousing on the -devel list to get some real certified reviewers on this? Sure thing!
(In reply to comment #6) > > * The ocsigen quickstart page indicates most distros include an initscript, > > which we seem to be lacking. I'd volunteer but shell scripts make me want to > > gouge my eyes out. > > Probably best to copy the one from Debian, if they have one: > > http://git.debian.org/?p=pkg-ocaml-maint/packages/ocsigen.git;a=summary Here we go, smimram wrote one: http://git.debian.org/?p=pkg-ocaml-maint/packages/ocsigen.git;a=blob_plain;f=debian/ocsigen.init;hb=HEAD
About ocamlduce, see bug 479970.
(In reply to comment #6) > (In reply to comment #5) > > * /usr/bin/ocsigen is system_u:object_r:bin_t; do we maybe want to make it > > system_u:object_r:httpd_exec_t like apache httpd since it's "just" another > > webserver? > > I have absolutely no idea how to do this, but sure it sounds > like a good idea. bug 243302 details another package dealing with the same thing (yay for bz being indexed by google now) I do have a reasonable level of familiarity with creating selinux modules, so unless you've nothing else to do, leave it for me and I'll take a poke at it tomorrow. Once we've got something tested/working we can run it by dwalsh to make sure it's not insane. > Debuginfo isn't really that useful for OCaml programs, since > gdb doesn't know about OCaml. So you end up having to debug > assembler. I take it the symbols are of use to ocamldebug then? Or could we just strip useless baggage and discard? > > * The ocsigen quickstart page indicates most distros include an initscript, > > which we seem to be lacking. I'd volunteer but shell scripts make me want to > > gouge my eyes out. > > Probably best to copy the one from Debian, if they have one: > > http://git.debian.org/?p=pkg-ocaml-maint/packages/ocsigen.git;a=summary I can handle that level of copy-and-tweak, again unless you've just nothing better to do.
(In reply to comment #9) > > Debuginfo isn't really that useful for OCaml programs, since > > gdb doesn't know about OCaml. So you end up having to debug > > assembler. > > I take it the symbols are of use to ocamldebug then? Or could we just strip > useless baggage and discard? In ordinary Fedora C packages, foo-debuginfo contains the unstripped object files (ie. containing DWARF debugging info). The base package ('foo') is stripped of course. However the programs in the base package contain a special buildid section, which, with a suitably modified version of gdb, causes gdb to get the right symbols out of the corresponding foo-debuginfo file. All well and good for ordinary C/C++ programs. However OCaml has its own native code generator (ie. it generates machine code directly). This code generator doesn't embed any DWARF debugging info, and as a result if you try to generate a ocaml-foo-debuginfo subpackage it will usually be empty. (Except in some special cases, ie. where C code is linked in to the program). Thus we disable generation of ocaml-foo-debuginfo subpackages as a matter of policy. There's a separate issue which is that gdb is still able to find ordinary symbols in unstripped OCaml executables, but because gdb doesn't have DWARF info and in any case doesn't know anything about the OCaml language, all it can do is show symbol locations in assembler. Believe it or not, I have debugged OCaml programs on many occasions using gdb like this ... ocamldebug is quite separate. Firstly it only works on bytecode- compiled OCaml programs. Secondly, OCaml bytecode contains its own debugging information, not related to and totally incompatible with DWARF, which is only understood by ocamldebug and a few other programs like ocamlprof. Some enterprising person with LOTS of time on their hands needs to add DWARF output to the OCaml native code generator(s), and add support for the OCaml language in gdb.
There might be problems building with OCaml 3.11.0, see: http://caml.inria.fr/mantis/view.php?id=4699
*** Bug 460841 has been marked as a duplicate of this bug. ***
What's the status of this ticket? Given comment #11, I'm not sure if this is ready for review, but I built the package from comment #4 on rawhide and it seems to at least build and install OK. (I've zero idea how to test it.) One thing I noticed is that the %pre scriptlet references %contentdir, which isn't defined so it gets inserted literally into the scriptlet which almost certainly doesn't do what's expected, and also causes: ocsigen.x86_64: W: percent-in-%pre There's also ocsigen.x86_64: W: ocaml-mixed-executable /usr/lib64/ocsigen/extensions/ocsidbm ocsigen.x86_64: W: ocaml-mixed-executable /usr/bin/ocsigen which I've not seen before. rpmlint says that nothing should build with ocamlc -custom. I don't see '-custom' anywhere in the build log so I'm not sure what's up there.
Comment #11 is obsolete with OCaml 3.11.1. The "ocaml-mixed-executable" shouldn't be there whith latest ocsigen (1.2) and ocaml-ssl with the following patch: http://patch-tracking.debian.net/patch/series/view/ocaml-ssl/0.4.3-2/makefile (committed in rev. 6455 of upstream SVN).
Richard, did you want to update the package and post fresh links here?
I'll set it to NEEDINFO of me, but I don't have much time at the moment to spend on this. I'm quite happy leaving these bugs open for as long as they take, or if someone else is motivated to pick up the package and finish the review.
So this has been not ready and needinfo for nearly half a year. Can we go ahead and close this out?
It's got NotReady in the whiteboard, so is there a problem leaving it open?
I still clean these up periodically. If you want to leave it open, fine, but be prepared to be pinged about it.
Ping.
A few remarks: - the last upstream release of ocsigen is 1.3.2, and require lwt 2.1.0 (the patch to make it work with lwt 2.0.0 (if needed) is trivial) - the message about shift/reduce conflicts from ocamlyacc is harmless (but should probably be fixed upstream...) - there is no executables linked with -custom (so-called "mixed" executables that cannot be stripped) any more since version 1.2.0 - the bug I mentioned in comment #11 is fixed in upstream ocaml, now
While I'm in no position to update this package at the moment, I think this is an important package and we should leave this bug open, if only because someone can take over the bug if they need it in the meantime.
Closing per #19 and #20