Re: heads up
I am not even trying to comprehend where these rules come from, or
what their sanity is. I am just going to accept whatever comes out of
the Debian cabal as long as I can morally accept it.
At 16 Mar 2005 11:04:39 -0800,
Thomas Bushnell BSG wrote:
> 1. the architecture must be freely usable (i.e., without NDAs)
> 2. the architecture must be able to run a buildd 24/7 sustained
> (without crashing)
Does this mean eternally, or only for one week? Who is going to
If we use a slow machine with lots of memory, running for one week
will be fine, if certain precautions are taken (enough disk space and
ogi's ext2, or excluding certain packages that can't be built within 2
If you use a fast machine, it won't work, because a fast machine hits
the bugs and races faster. Mach just crashes at some point with
zalloc failures. I have no information about this bug, and have no
inclincation to collect it.
> 3. the architecture must have an actual, running, working buildd
We had this before, it's possible. People are working on setting it
> 4. the port must include basic unix functionality, e.g resolving
> DNS names and firewalling
The firewalling requirement was specifically put in there for us, I
suppose. AJ was quite upset when I told him we don't have it (years
ago). The people asking for this seem to think that having a working
firewall is some kind of proof of something, I don't know what. They
may or may not realize that the Hurd does not make any kinds of
security claims at this point (the code base is not audited, and we
actually know about some glaring security problems, so a firewall is
pretty down the list for me). In any case, I guess it would be
possible to enable ipchains or iptables or whatever we have in our
pfinet and export the Linux ioctl interface to configure it in pfinet.
Some coding work, for sure, but nothing substantial, unless
ipchains/iptables needs some kind of magic we don't have in our glued
pfinet. Nobdoy is working on it, though (and don't look at me ;).
> 5. binary packages must be built from the unmodified Debian source
> (required, among other reasons, for license compliance)
That was always a requirement.
> 6. binaries for the proposed architecture must have been built and signed
> by official Debian developers
Ditto. This says nothing about the hardware and where it is located.
I am reasonably sure that many Debian machines are located at
environments which are not exclusively controlled by Debian
maintainers, but by trusted third parties.
> 7. the architecture must have successfully compiled 50% of the archive's
> source (excluding architecture-specific packages)
This assumes a definition of "architecture-specific". I suspect it's
going to be based on the Architecture: field of the packages, which
would be wrong, as some packages may not be buildable yet but will be
when we implemented a certain feature, or when it is ported. It
doesn't help that Debian source packages suck in all the dependencies
for every silly feature a package got.
I suggest that this definition allows for the port maintainers to
build their own "architecture-specific" exclusion list, and then base
the numbers on that.
But even then I suggest to just reject this rule. The software in
Debian is heavily biased towards GNU/Linux.
That said, last time I was doing the buildd stuff, I think we had
something in the 30% range or so...
> 8. 5 developers who will use or work on the port must send in
> signed requests for its addition
Trivial. We have many more than that (not all active all the time,
> 9. the port must demonstrate that they have at least 50 users
Well, we surely can find 50 people who say they are using Debian GNU/Hurd.
> These are not cast into stone, but we should expect something like
> this to become reality I think.
I am expecting everything from the Debian cabal. Nothing will
surprise me. ;)
- heads up
- From: Thomas Bushnell BSG <email@example.com>