[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ara bug suggestions & buildd states

George Danchev <danchev@spnet.net> writes:

> Hello, 
> I have some questions I would like to clarify for myself regarding some 
> suggestions given within ara's [1] 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 [2] 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 [3] 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?

> [1] http://svn.debian.org/wsvn/ara
> [2] http://www.debian.org/devel/buildd/wanna-build-states
> [3] 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 


Reply to: