Re: ara bug suggestions & buildd states
George Danchev <firstname.lastname@example.org> writes:
> I have some questions I would like to clarify for myself regarding some
> suggestions given within ara's  bug #290338 (ara: [m68k] FTBFS dh_testdir:
> I have no package to build).
> Thiemo Seufer suggests forcing the package to cause dep-wait onto build by
> wanting a build-dependency which could not be satistied for that arch [m68k
> for example]. Looking at w-b states explanation  this will require a human
> intervention and the dependency wont be satisfied anyway. So why bother
> humans, when this can be done automatically ? What is the whole idea behind
> this suggestion, am I missing something ?
The package depends on a compiler for native code to build the binary
package. It should have the depends anyway. The only way to write that
depends though is to Build-Depend on the native compiled compiler.
Imho a shortcoming in ocaml packaging.
> Since ara 1.0.8 has been in testing for long time, seems it has already been
> done what Goswin von Brederlow has suggested. Now, what is FTBFS and what are
> the best practices to contact the ftp-masters (obviously someone else had
> done the job for me ;-).
To avoid the FTBFS ara must be added to packages-arch-specific.
Otherwise the package will try to build and either fail with
Build-Depends missing or no packages to build. Thiemo and I find the
missing Build-Depends a clearer indication that this is not ment to be
> Anyway we have ara 1.0.9  at the alioth svn which solves these things
> accordingly (e.g. one can successfully build the source package on m68k) and
> will be rebuild soon after the last ocaml transition.
Huh, what changed? Do you build seperate bytecode for each arch
without native code again?
>  http://svn.debian.org/wsvn/ara
>  http://www.debian.org/devel/buildd/wanna-build-states
>  http://svn.debian.org/wsvn/ara/trunk/debian/?rev=0&sc=0
> pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu>
> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB