Bug 460894 - Review Request: ocsigen - Web programming framework
Review Request: ocsigen - Web programming framework
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
NotReady
:
: 460841 (view as bug list)
Depends On: 460893
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2008-09-02 09:26 EDT by Richard W.M. Jones
Modified: 2012-12-11 18:13 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-11 18:13:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2008-09-02 09:26:52 EDT
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.
Comment 1 Jason Tibbitts 2008-09-05 17:31:38 EDT
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
Comment 2 dex 2008-09-05 21:55:17 EDT
Looks like a build dependency on ocaml-camlp4.
Comment 3 Ellen Shull 2009-01-13 00:17:40 EST
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?
Comment 4 Richard W.M. Jones 2009-01-13 09:27:56 EST
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@redhat.com> - 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.
Comment 5 Ellen Shull 2009-01-14 03:45:35 EST
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?
Comment 6 Richard W.M. Jones 2009-01-14 05:33:36 EST
(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!
Comment 7 Richard W.M. Jones 2009-01-14 05:34:46 EST
(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
Comment 8 Richard W.M. Jones 2009-01-14 06:00:55 EST
About ocamlduce, see bug 479970.
Comment 9 Ellen Shull 2009-01-14 06:38:56 EST
(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.
Comment 10 Richard W.M. Jones 2009-01-14 07:19:58 EST
(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.
Comment 11 Stéphane Glondu 2009-01-21 12:09:09 EST
There might be problems building with OCaml 3.11.0, see:

  http://caml.inria.fr/mantis/view.php?id=4699
Comment 12 Richard W.M. Jones 2009-03-10 11:16:03 EDT
*** Bug 460841 has been marked as a duplicate of this bug. ***
Comment 13 Jason Tibbitts 2009-07-31 22:41:04 EDT
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 14 Stéphane Glondu 2009-08-01 07:57:30 EDT
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).
Comment 15 Jason Tibbitts 2009-08-03 21:42:38 EDT
Richard, did you want to update the package and post fresh links here?
Comment 16 Richard W.M. Jones 2009-08-05 03:35:53 EDT
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.
Comment 17 Jason Tibbitts 2010-01-25 19:17:03 EST
So this has been not ready and needinfo for nearly half a year.  Can we go ahead and close this out?
Comment 18 Richard W.M. Jones 2010-01-26 04:51:59 EST
It's got NotReady in the whiteboard, so is there a problem leaving it open?
Comment 19 Jason Tibbitts 2010-01-26 16:28:58 EST
I still clean these up periodically.  If you want to leave it open, fine, but be prepared to be pinged about it.
Comment 20 Caius Chance 2010-04-30 02:29:28 EDT
Ping.
Comment 21 Stéphane Glondu 2010-04-30 02:59:17 EDT
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
Comment 22 Richard W.M. Jones 2010-04-30 03:35:22 EDT
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.
Comment 23 Miroslav Suchý 2012-12-11 18:13:12 EST
Closing per #19 and #20

Note You need to log in before you can comment on or make changes to this bug.