Re: [buildd] Action plan to get buildds getting online again
On 2012-11-23 21:27, Ingo Jürgensmann wrote:
I'm answering to myself to make a start... ;-)
1) Who will run a buildd? 24/7 operation and a good internet
connection are required (DSL or similar is quite common nowadays). Do
we split tasks between host and buildd maintainers?
I would offer 2 '060 Amigas and maybe an '040 to be able to test that
code as well.
Where I can offer to work as host admin I would refrain from acting as
buildd admin. ;)
2) Where will the buildds be run? Running them in the basement of
your home gives quick access, but most likely we need one or the
other
public accessible machine. There's still an offer from NMMN in
Hamburg
to host some machines in their office (kullervo, crest, elgar?)
I think when Christian successfully upgraded kullervo & crest we can
take them again to NMMN to let them run there. For Elgar I'm unsure. It
is (as crest) an A4000 in a big tower case, IIRC. I would like to get
rid of big tower cases. Maybe we should ask Smurf to send Akire, which
should be an A2000/060 in a desktop case. Or if anyone has an A4000
desktop case... ;)
Anyway there are still Arrakis and Vivaldi running at my parents home
and can be used as a buildd. Both are running 24/7 and behind a cable
modem. Maybe I can use an IPIP tunnel with a public IP if that is
needed.
3) What needs to be built (first)? Of course the toolchain should be
self-hosted and we need base and related stuff.
Although it would be nice to have a full archive, I fear that we won't
be capable to keep up when we try to build the whole archive of nearly
10000 packages now.
I think it would be best to omit KDE & Gnome packages. Maybe just build
X11 base and some lightweigth Desktop like XFCE or whar's appropriate
nowadays. And we won't need number crunching packages (don't know the
names, but there were some in the past, maybe called atlas or such?) as
well as graphic intense games. That way we can exclude many packages
that makes no sense at all on m68k. Maybe we can ask popcon maintainers
what packages were popular in the past on m68k to get an idea what the
users would need?
But that's the long term goal. First we need the toolchain back in
shape. Thorsten made an excellent job in the past and give some advices
on building the tool chain, I'm sure. And I think he has currently the
best overview of what needs to get built next.
4) More things needed? What kind of SSH keys are nowadays en-vogue?
RSA? DSA? How will the length impact SSH performance on m68k? What is
our aim? Do we target on re-inclusion in Debian with full archive or
do it in a different way like reduced set of packages (base,
required,
...) and everything else on a best-effort basis?
Well, already wrote some stuff in 3) regarding what packages need to be
built.
From the current point of view, I think it's too early to think of
re-inclusion in Debian. Maybe we can manage to follow unstable and keep
up with it and manage it somehow to get the stable version as well built
so that we can offer a stable distri to our users instead of a moving
target like unstable. Additionally our own buildds would benefit from a
stable base, I think. Maybe we can use one or two buildds for that,
depending on the overall count of available buildds and how much work
that would mean.
5) Anything else?
If needed I can donate some mirror space as well as some other
infrastructure like mailserver or such.
Before my vacation, I'm currently on, I tried to get buildd.net working
again.
So, after all, my POV for an action plan is:
- collecting info about what buildds to start with and who will operate
them (maybe start with a small number of buildds)
- setting them up (upgrading host system, setting up chroot for buildd)
- generating SSH keys & send them to debian-ports.org
- start re-building toolchain on real hardware
- next with our needed packages
- continue to build base and required packages
- getting more buildd online, getting more packages built
--
Ciao... // Fon: 0381-2744150
. Ingo \X/ http://blog.windfluechter.net
gpg pubkey: http://www.juergensmann.de/ij_public_key.
Reply to: