Re: building packages for sparc
* Blars Blarson <blarson@blars.org> [2004-12-10 17:36]:
> I volunteered a machine of mine (twice as fast as vore) to act as a
> buildd with myself doing the buildd machine maintenance and uploading.
> No reply was received, I later found out one was sent but the sparc
> buildd maintainer directly refused a request of the dpl to resend the
> reply.
I think it would be fair to elaborate on this. The sparc buildd
maintainer responded to you but you never got the reply because of
your tight spam checks. While you're not using a C-R system, let's
take this as an example because it's pretty good. There is quite a
number of people who will never respond to a C-R system on moral
grounds because they think it's a bad system. While I personally
think C-R is annoying, I usually respond anyway, but I understand
people who don't. Now, while you don't use C-R, you use a very tight
spam control, and there have been complaints about people not being
able to mail you before... I don't know which one of you is "right",
but I think both sides have good arguments, and I feel you only
presented one view in your paragraph above.
> I was building packages in a pbuilder environment and uploading when I
> felt appropriate. The sparc buildd maintainer insisted that I stop
> doing so, claiming that I was causing problems for the security team.
> He refused to elaborate or discuss this claim.
It's pretty simple and has been discussed on various lists before.
The problem with people building and uploading packages outside
Debian's build infrastructure when the official Debian buildd failed
is that this does not solve the underlying issue why the buildd failed
in the first place. In many cases, a rebuild would do, but sometimes
there are real issues related to the environment. You have a
different environment than the Debian buildd and while it may compile
in your environment, it might not compile on the Debian buildd. The
problem with security updates is that they are strictly built on
Debian buildds. So just "doctoring" around a failure on a buildd by
building it in a different environment is not healthy in the long run
because we need to make sure that the buildd is capable of building
every package.
In addition to this, there are often subtle problems that a package
may build, but not actually work. mips is an example where outdated
auto* scripts will lead to broken packages even though they build just
fine. In fact, we had such broken packages uploaded to the archive
because the people randomly compiling and uploading packages did not
know what they were doing!
--
Martin Michlmayr
http://www.cyrius.com/
Reply to: