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

build cluster for all architectures.



Ben,

what you propose here, sounds very reasonable to me. 

One criticism: 

For most dialup developers, it will be very inconvinient to work on
this cluster.  So writing the fail logs in the home directory will be
of little use.

Jens

[copied with permission from debian-private --- no cc to private
because it will be easy to accidentially leak confidential mail. ]

Ben Collins <bcollins@debian.org> writes:

[lot's of packages fail when a build daemon for other architecture
tries to build them]
> 
> I agree, right now sparc lists over 100 failed builds that aren't sparc related.
> Some are trivial, some out right stupidity (no rule for binary-arch in
> debian/rules) and some will probably never get fixed without rewrites.
> 
> A lot of maintainers are very good about patching for other archs, and even
> supply the patch upstream. Other maintainers completely ignore (or are MIA) the
> patches supplied in the BTS.
> 
> Which leads me to a suggestion I've been mulling over for awhile (yes this
> get's off topic and is probably best suited for -devel, so Cc there if that's
> your feeling). Will we ever be able to setup a build cluster? I mean let the
> packagers test build their software on whatever primary arch they want to,
> then upload the source (once they feel it is able to compile correctly) to
> a build cluster that then tries to compile it on every arch that it claims
> to support (in the Arch field). If it does not compile on any of them the
> fail logs and source are left in the users homedir (shared between all the
> build systems) so that they can test and fix the problems. After it compiles
> on all of them, the multi-arch .changes is sent to the maintainer for signing
> and then sent to Incoming for dinstall.
> 
> This fixes several problems, 1) packages that are uploaded that _do not_
> compile from the source (believe me, there are more of these than you think,
> even ones that make use of scripts not in the source or in any packages), 2)
> it keeps the archs in sync. Since right now all of the stable archs are pretty
> much in sync with the compiler/kernel/libc (excepting m68k), this approach
> is starting to be more feasible and needed. Also we end up with a more secure
> archive since all packages will be built by one system and only the source
> needs to be verified (signed on upload to the build system).
> 
> I'm willing to setup a few systems and even get the bandwidth donated if need
> be. This could be setup as a voluntary system for initial testing, and I'm sure
> the wanna-build people would be very interested in helping with something like
> this.
> 
> 

P.S.: Please vote against Spam! At
             http://www.politik-digital.de/spam/
(Sorry Europeans only)
---
Jens.Ritter@weh.rwth-aachen.de   grimaldi@debian.org
Key ID: 2048/E451C639 Jens Ritter
Key fingerprint: 5F 3D 43 1E 24 1E CC 48  1E 05 93 3A A7 10 73 37 


Reply to: