Re: ia64/unstable: FTBFS: needs ocamlopt
On Wednesday 28 May 2008, Stefano Zacchiroli wrote:
> On Wed, May 28, 2008 at 10:28:04PM +0300, George Danchev wrote:
> > What we are supposed to do with FTBFS like #483280, #483307, and similar
> > where ocamlopt binary is just not available on these particular
> > architectures, in that case IA-64 ? Should we just set the severity to
> > important as Luk Claes did for #483280 and wait for upstream to provide
> > support for IA-64 or should we remove ia64 from Architecture: list ?
>
> The former (just raising the severity and wait) is not an option, we
> need to either make the package build on that arch or drop---your second
> option---ia64 from Architecture list. The alternative is of course to
> make the package build without ocamlopt (i.e. relying only on ocamlc) if
> possible in your fase. If you want to actively maintain ara this is your
> call on that, but please choose and act quickly :) as we are in the
> middle of a transition here.
As latest developments shown ara is packaged just after its canonical example
of spamoracle, whose source packages are not supposed to be built (I would
say useless to even try to;-) on arches where ocamlopt is not available. For
these arches -byte binary packages are meant and produced, i.e. already built
once as arch-indep (arch:all) parts on arches where arch-dependant parts was
built (i.e on arches where ocamlopt was available). I mailed Lamont who
happen to be a P-a-s maintainer and these bug filer to update P-a-s
accordingly.
> > By the way, I'd like to thank Stefano and Sylvain for improving the
> > (my;-) ara package and *documenting* that in README.Debian-source! I'm
> > already a DD, so I can upload myself, but I'd love to co-maint/co-develop
> > it together.
>
> You are more then welcome, but in fact I did the last two uploads of
> ara, respectively for 3.10.1 and 3.10.2 transitions just because nobody
> else was doing. I'm not particularly willing to take care of ara in the
> long run. So if you want to do that please step in, but also please stay
> at pace with the rest of ocaml packages during transitions, as they need
> coordination.
Sure. Can transition-check(1) (recently added to devscripts) be of any help
here ?
> The only particular desire I have for the ara maintenance is to have it
> on the pkg-ocaml-maint repo, so that access control is the same as for
> other OCaml related packages. This would make it easier to help when/if
> needed. I understand that ara has its own alioth project for
> _development_, but this should not hinder having its packaging
> elsewhere. To be read: yes, I think ara should no longer be a native
> package: use the ara project on alioth for development, and
> pkg-ocaml-maint for packaging of "upstream" releases.
I like that plan. Could you please add ara's debian/ to ocaml-maint repo, then
I will remove debian/ from its "upstream" repo ?
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: