Re: New buildd and some obversations
I don't have a problem giving root access to diablos (the m68k), but I'm
rather hesitant to give out root to siren (the x86 emulator host). I've
been doing some more tweaking of the buildd environment, and I've added
ccache which helps with configure tests since it simply caches each
result. I've also been experiementing to see if its possible to offload
the creation of documentation to the x86 (which I've had some good
successes in actually), although I can easily remove this when it comes
time to make this machine an offical buildd. I can be found in
#debian-68k under the username NCommander if you wish to talk w/ me.
On Sun, 2008-02-10 at 11:00 +0100, Christian T. Steigies wrote:
> On Sat, Feb 09, 2008 at 10:12:35AM -0500, Michael Casadevall wrote:
> > The machine has a dynamic IP address, I have a
> > dyndns pointed at the machine so its always
> > accessable. However, for mail, and other services
> > requiring a static IP, I have the domain name
> > nemesisnetworks.com, and that has a mailserver on
> > it; mail is delivered to both siren and diablos
> > via fetchmail in multidrop mode; both can send
> > using nemesisnetworks.com as a smarthost.
> > Obviously enough, it isn't possible to directly
> > access diablos (unless I did some massive hacked
> > of my iptable scripts ;-)); you need to SSH into
> > siren, and then you can rlogin (or SSH if you
> > like waiting) into diablos.
> That is not too different from my setup at home, only that I have "real"
> m68k hardware. I only have a dynamic IP, but my router supports dyndns. On
> my router I set up IP forwarding, so if you know the correct port number,
> you can ssh directly to my m68k boxes behing the router/firewall. You can
> either run ssh on that special portnumber, or have the forwarding point to
> the ssh port on the machine behind the firewall, or even both at the same time.
> Depends a little bit on your router/firewall.
> On the dyndns address, I also receive mail for all buildds, the server
> behind the firewall forwards mail on the internal network, and acts as a
> smarthost for outgoing mail. Fetchmail might be more reliable, but I did not
> see big problems yet. IPv6 would be another solution, but I only got the
> initial tunnel working so far, not the subnet.
> > If this setup is acceptable, I can also setup two
> > more machines in a few more weeks into the same
> > configuration.
> That sounds great, I actually prefer virtual hardware, as real hardware
> tends to break in the long run... but to use this as a debian-m68k buildd,
> you'd first have to be a developer or maintainer, or give root access to the
> m68k machine to a developer/maintainer. I hope that is sufficient to get
> this accepted as a new m68k buildd, Stephen might know more? Then you also
> need a developer/maintainer to sign the build logs, it does not have to be
> the same person who has root access, but it helps if the person handling the
> logs can work on the machine. I am not volunteering for either job...
> > Anway, a couple of notes and obvervations I made
> > during my setup of the buildd and such
> > 1. With distcc, the compile part of building
> > packages is very quick (compared to just plain
> > complination), which does help cut down build
> > times. The problem though comes with
> > documetnation (I don't think there is much that
> > can be done about this unless someone wants to
> > write a distcc-like script for texinfo and
> > friends). It took about two hours to build the
> > documentation of zsh (about half an hour for each
> > format it took). There has got to be a
> > way we can reduce the time it takes.
> The best would be to build the docs as separate arch-any package, so that it
> has to be built only once. But it is up to the package maintainer to decide
> that. We did have problems with docs for a long time, some tools to build
> the docs did not work on m68k, it is such a waste of resources to build the
> docs on a dozen arches. Works only if the docs are identical on all arches,
> the debian-installer docs are arch dependant for example.
> But as long as the package builds fine, it does not matter too much how long
> it takes. Packages that fail to build are much more problematic, everything
> else will get built eventually. We just need a few more buildds and a little
> more time...