Re: [buildd] needs-build @ 914
Stephen R Marenka wrote:
> On Mon, Jan 28, 2008 at 02:52:25PM +0100, Ingo Juergensmann wrote:
>> On Mon, Jan 28, 2008 at 07:27:07AM -0600, Stephen R Marenka wrote:
>>> Meanwhile, maybe we need to think about what a debian-m68k distribution
>>> should really have in it. We could probably release a lenny-m68k without
>>> kde, gnome, mathematical packages, and some of the other large packages
>>> that afaik, nobody uses on m68k.
>> Definitely, such packages like blast2, axiom or scilab doesn't make much
>> sense on m68k except for academically proving that it can be run on m68k,
>> Similar packages are flight simulators and other high cpu and graphic load
>> based apps. I really doubt that anyone will ever use fs on linux m68k.
>> Maybe we should concentrate on basic functionality including X11 support
>> with xfce4 or icewm, some sort of browser (dillo and iceweasel) and email
>>> Would ya'll (such users and developers that hang around this list) support
>> I do!
>> I think we can take care for about 4000 source packages, but ~7000 packages
>> is was too much, especially when some of the porters are always trying to
>> bring coldfire support in...
> Actually, we generally stay caught up until a major bug or toolset
> change causes us grief. Getting caught back up again takes us a very
> long time. It might be that we just need a very much smarter buildd
> queue with the things we don't care about sitting on the back burner
> until everything else is built.
You can change the permanent priority of a package to make sure it's
always at the back of the queue (or you can put it in weak_no_autobuilt
on all buildds, which is probably too much work)...
>> Maybe we should start a new thread and announce it prominently on planet.d.o
>> and email@example.com and collect opinions for about 2 weeks and then take
>> action accordingly.
> I'd rather figure out *how* before I'm overly concerned with what and
> announcing it to the world. :)
This could easily be done with not-for-us after discussing the list of
packages to block (temporary)...
For both things you'll need a list of packages. For the former you can
construct categories with the same priority which will be sorted
internally like it's done now or just one category of packages that
should be built when all others have been built already...
I would be happy to implement it if there is some kind of consensus on
the list and/or categories.