I'm not sure exactly where I can help, but I'd be willing to supply a static endpoint for some tunnel(s), and a mail relay if nothing else. I'm no package troubleshooting wizard but I'd be willing to look at anything buildd pukes on.
Jason On Sat, Nov 24, 2012 at 7:29 PM, Michael Schmitz < [email protected]> wrote: > Ingo, > > On Fri, Nov 23, 2012 at 10:23:36PM +0100, Ingo Jürgensmann wrote: > > 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. ;) > > I could offer a 060 Falcon but that will be of limited use only. The > network > card I got for it in the hope to speed up network operation seems to have > died, so it will be quite slow. The whole buildd system will have to be set > up from scratch. > > Mail outgoing from my home network has broken down again - not sure this is > due to changes by my ISP but this I have to resolve before the machine can > be used as buildd. > > I won't be able to handle more than my own buildd and maybe one more. > > > >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. > > That was a stretch already last time while we were in the running, so I > don't think it is worth to try. > > As Thorsten has said - build dependencies are the main problem there. We > need to work our way backwards from what can currently be built. Stuff that > is not a build dependency and not likely to be useful can be flagged > not-for-us. Unbuildable packages (build dependencies missing or > uninstallable) should be flagged as well. Maybe we need a new state similar > to dependency-wait for cases where a build depencency exists but cannot be > installed. > > > 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. > > I'd listen to Thorsten's advice as well. > > > >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 > > That's the best I'd hope for. And it will take quite a few people to step > up > and take care of a buildd system to pull off. > > Cheers, > > Michael > > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: > http://lists.debian.org/[email protected] > >
