Re: [buildd] Action plan to get buildds getting online again
Ingo,
> On 2012-11-24 09:29, Michael Schmitz wrote:
> >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.
>
> That's bad news with that NIC. Maybe someone here on the list has a
> spare part to donate?
These parts are quite rare - and it may not be totally dead yet. The USB
chip on the same board is still alive. The ethernet chip is recognized and
can be read from as well - it just behaves weird when writing registers.
This I might be able to work around - haven't yet tried to reflash the CPLD
either.
> >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.
>
> So your ISP is blocking port 25?
It has always done that, but I had postfix set up to use submisson in place
of smtp. That stopped working. Might have been a postfix update that did
that.
> As I said I could provide a public IP for a IPIP tunnel or such (or
> even some sort of VPN setup).
Remember I'm at GMT+12. Not exactly close. I don't think that would work
well.
> >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.
>
> There are some new states within buildd anyway. I discovered them
> when I tried to fix Buildd.net. Maybe one of these already handles
> this kind of task?
Maybe someone else got fed up with that problem.
> >>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.
>
> To clarify things: with "re-building toolchain" I meant to really
> re-build the toolchain on real iron, although we already have those
> packages built. At least libc6, binutils & gcc. I feel a little bit
> more safe when I know that we run safe on real hardware. :-)
It'll be slow - you can pretty much dedicate a buildd for that purpose alone
I think. But knowing that a build on actual hardware works the same as on
emulated machines would be good for comfort.
Thorstens packages will supersede the test-built ones anyway so it's mostly
for regression testing.
We'll get to that once we have got the basics set up.
Cheers,
Michael
Reply to: