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

Re: [buildd] Action plan to get buildds getting online again



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 <schmitz@mail.biophys.uni-duesseldorf.de> 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 debian-68k-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 20121124082952.GA794@mail.biophys.uni-duesseldorf.de" target="_blank">http://lists.debian.org/[🔎] 20121124082952.GA794@mail.biophys.uni-duesseldorf.de



Reply to: