* Blars Blarson <[EMAIL PROTECTED]> [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/
