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

Re: linux-image-*-dbg for squeeze?



>> > I wonder what we (as Debian) could do about it. Would it make sense to
>> > sponsor a very fast machine that the kernel team could use to build the
>> > kernels and upload from, replacing kernel-archive.buildserver.net ?
>> The easiest fix is the official blessing by the ftp team to upload only
>> the architecture independant packages and build all architectures on the
>> buildds.
> Ftpmasters, would it be acceptable for the kernel team to upload only
> the architecture independant packages ?
> It would allow to provide debug packages on fast architectures without
> forcing the developers to upload them using their slow internet
> connections, solving #365349.

There is a "hole" in dak that allows uploading a source that has
arch:all and arch:any with only source+all.  This is not intentional,
but until now there hasn't been a real need to "fix" this.

There are some developers already "using" this hole to upload in a
source+all way, having the rest of the packages build on buildds.

This is not entirely the most favored thing to do, for various reasons
(including bypassing things like lintian checks and not actually showing
the stuff builds), but is very very low on our todo to fix. For the
simple reason that the packages uploaded this way simply do not appear
on any radar. Ie. they are maintained well. No (bad) lintian problem and
even more important: No build failures, the buildd do not get useless
work from them.

Provided this will be true for the kernel packages too (ie. they are
build elsewhere first and its known to work and they don't bypass lintian
checks that would otherwise do a reject on a sourceful upload) then it
is acceptable for the kernel team to upload only the architecture
independent packages, having the rest build on the autobuilders.

-- 
bye, Joerg
<40293f1b.8130421@news.individual.de>
Windows ME? Mit 13? Kann der nicht lieber Drogen nehmen wie andere Kinder
in dem Alter?


Reply to: