Re: buildd administration
Jeroen van Wolffelaar <jeroen@wolffelaar.nl> wrote:
> On Fri, Dec 09, 2005 at 09:43:36AM +0100, Frank Küster wrote:
>> Ingo Juergensmann <ij@2005.bluespice.org> wrote:
>> >
>> > A buildd admin doesn't see much more than what you can see in the build
>> > logs. Basically the build logs is all a buildd admin see.
>>
>> But the buildd admin for sure has read access to /tmp in the build
>> chroot? Assuming that /tmp isn't cleared after each build, but just
>> every couple of hours/days/whatever.
>
> Due to disk shoreage on a significant amount of buildd's, to the best of
> my knowledge, the build tree is removed quite immediately after the
> build finishes, and only a rebuild would be able to give you more info.
What do you mean with "build tree"? I assume it's the tree where the
sources of the package are unpacked and dpkg-buildpackage is called?
This is not what I want. In the case I am talking about, tetex-bin was
installed as a build-dependency, but failed in its postinst. The other
package FTBFS, and a bug was filed against tetex-bin. When tetex-bin's
postinst fails as it did there, it leaves a temporary file in /tmp, and
this file I wanted to investigate. Even if /tmp had been cleaned
between the failed build and me sending the mail, the buildd admin could
have remembered this when he found the next package FTBFS the same way
(which happened in fact a couple of days later).
Since I didn't know a contact address, I wrote to debian-admin, and for
sure they would have been able to at least look into /var/debbuild/tmp/
and check whether our file was still there, but I didn't get a reply
from them, either. And I still don't know whether there's a strange
corner case where tetex-bin fails to configure, or it was just a fcked
up /var/debbuild, or hardware problems on sarti.
> But surely, a porter owns the hardware in question too, and can simply
> test-built it himself? *That* is work that any interested porter can do,
> in the process, debugging the problem, and ultimately filing a useful
> bugreport, hopefully with patch -- and maybe do a porter NMU later, even
> -- prefereable still with i386 or so so that it is verified that this
> time around, the buildd indeed is capable of building the package.
Since the package had been configured on hppa without problems
previously, it wasn't a simple architecture problem, and simply
installing it on hppa would not have revealed the bug. Either there is
a bug, then it was a consequence of the specific order of installs,
removals, purges, and upgrades in the sarti debbuild environment; in
this case only looking at this environment could help to debug. Or
sarti suffers from hardware problems.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: