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

Re: Bits (Nybbles?) from the Vancouver release team meeting

Martin Schulze wrote:
> > not to mention the time spent by the DSA/buildd admins and the security
> Thanks for asking the security team how much work it is to support 11
> architectures.  Err... Huh?  I wasn't asked?  Uh?
> However, to clarify this for the readers who aren't involved in
> security: Thanks to the awesome buildd network and a stable Debian
> release supporting 2 architecturs is as easy or difficult as
> supporting 20.  The difference is just waiting for one buildd reply or
> waiting for 19.
> In most of the times the package will compile fine on all
> architectures since it's a stable Debian release and hence its
> packages are supposed to be rebuildable on a stable Debian machine.
> There are exceptions to the rule, but they're not that common.  A new
> S/390 kernel and a new MIPSel kernel caused some configure scripts to
> fail, but this can be solved quite easily (once debugged and
> documented) by patching the configure script, so it's just a rebuild
> that is required.
> More problematic are cases when software doesn't compile anymore on a
> certain architecture due to compiler problems or kernel limitations.
> However, these are very rare and I only remember two such cases: chbg
> doesn't compile on HPPA anymore and xemacs21 cannot be compiled by a
> buildd anymore.
> It causes the security team a lot more work to support more than one
> distribution and/or to support older software for which current
> patches don't work and where the code is too different to easily find
> out whether it is vulnerable as well or not.
> Supporting stable and oldstable for a year until we drop support for
> oldstable always causes a lot of extra work for us.  Supporting more
> than one architecture for a given distribution is not.
> This, however, refers to a working buildd network.  However, every
> once in a while one architecture fails because only one buildd is
> configured for stable-security and this buildd is defunct.  For
> example, there was no working i386 buildd for a long time.  Currently,
> there is no arm buildd (for whatever reason, I dunno).
> The hate architecture for many developers however, m68k, has worked
> quite well normally.  There are about a dozen buildd machines and
> several of them are configured to compile stable-security.  If one
> machine is busy or down, another one picks up the package.
> Additionally, this architecture has quite responsive buildd admins so
> problems can be discussed and resolved via irc or mail quite easily.
> These are features I would wish for all architectures: more than one
> buildd configured for stable-security and responsive buildd admins.

I'm not sure if my wording was bad but apparently I offended some
people not on intention.  So let's clarify some pieces:

The security team is very thankful for the buildd network as it
simplifies the roll-out of security updates a lot.  We couldn't
support our distributions without this buildd network.  It is an
essential projects asset and an essential resource of the security

For potato we had to compile all packages manually on the six
architectures that potato was released for.  When build dependencies
were missing we had to ask for their installation.  This bound a lot
of time and energy.  As the number of packages and the number of
architectures grew this didn't scale well.

That's why we mentioned that we cannot support woody if we need to
continue building packages manually for all architectures.
Unfortunately this caused a delay of the release of woody but in the
end it gave us a great opportunity to support woody and concentrate
not on building but on fixing problems.

James and Ryan have set up and configured the buildd network and have
done a great job installing it.  Without their work I don't know what
the security team would do now.

The above explanation came from the security team only.  It didn't
come from the buildd admins or the system administration.  These are
totally different matters.



Those who don't understand Unix are condemned to reinvent it, poorly.

Please always Cc to me when replying to me on the lists.

Reply to: