Re: What is autobuilder? Please help me understand this bug.
Paul Elliott <pelliott@blackpatchpanel.com> writes:
>> http://wiki.debian.org/Alioth/PackagingProject
>> Source: libswe
>> Version: 1.77.00.0004-1
>> Severity: serious
>> Justification: fails to build from source
>>
>> Automated builds of libswe are failing because unoconv (used to
>> produce PDF and HTML documentation) assumes a writable home directory,
>> which the autobuilders' build environments lack. (Many also lack
>> loopback network interfaces, which may be an issue as well.) Given
>> that the documentation winds up in a separate architecture-independent
>> binary package anyway, I'd suggest arranging to build it only in full
>> builds, which presumably run in less restrictive environments.
>> (Relatedly, I'd suggest moving unoconv from Build-Depends to
>> Build-Depends-Indep.)
>>
>> Could you please look into it?
>
> My program does indead use unoconv to build documentation. I need to
> understand this bug so that I can fix it.
It's spelled out very understandably in the report, I believe: an
autobuilder (a program that builds debian packages, so that we can have
packages for all architectures Debian supports, without having to
manually compile each) tried to build it, and it failed.
It failed, because a program the package uses assumes that $HOME is
writable, which, on the autobuilders, it is not.
> For instance, libswe just appeared in debian unstable, that means someone must
> have built it. How does the build environment of the autobuilder's differ from
> the one that built libswe on its path to unstable?
As explained in the bug report, the autobuilder has a read-only $HOME,
among other things. They often have no network, not even loopback.
> Why is the autobuilder's environment correct? In other words, why is
> this not a bug against the autobuilder's software?
Because a package, while building, MUST NOT touch files outside of its
build directory. $HOME is way outside of it, so it shouldn't be doing
anything there to begin with. Since you shouldn't be doing that anyway,
it's not a bug in the software (it's a feature, that guards against this
kind of thing).
> How can I duplicate the autobuilder's builds on my local machine to test this
> problem?
There are two ways to do this: one is to make your $HOME non-writable,
the other is to set your $HOME to a non-writable place for the time of
the build.
> What is a "full" build and can I be sure that a full build will never occur in
> the autobuilder?
A full build is a build that builds... everything, architecture
dependent and independent packages alike. (Ie, binary-arch and
binary-indep targets, both)
Autobuilders only build architecture dependent binary packages (they
call debian/rules clean, build and binary-arch). So they will never,
ever do a full build.
What the bug report suggests, is to arrange your debian/rules so that
documentation is only built if the architecture independent package is
built aswell, not every time, even when it will end up being unused.
> If I make a fix to this problem, how can I test that it will work in the
> autobuilder's evnironment?
If you fix unoconv, to not touch $HOME, then you can test the fix by
setting $HOME to a non-writable place for the duration of the build.
If you change the build process to build documentation only when doing a
full build, you can test it by calling debian/rules binary-arch, and
verifying that no documentation was built (not just that the -doc
package wasn't, but that not even the docs were built).
Hope this helped!
--
|8]
Reply to: