What is autobuilder? Please help me understand this bug.
Recently libswe made it into debian(unstable). Almost immeadiately, I got this bug: 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. 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? Why is the autobuilder's environment correct? In other words, why is this not a bug against the autobuilder's software? How can I duplicate the autobuilder's builds on my local machine to test this problem? What is a full build and can I be sure that a full build will never occur in the autobuilder? If I make a fix to this problem, how can I test that it will work in the autobuilder's evnironment? Thank you for helping a beginning packager fix a bug. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: What is autobuilder? Please help me understand this bug.
Paul Elliott pelli...@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] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obts8dk5@luthien.mhp
Re: What is autobuilder? Please help me understand this bug.
On Wed, Jan 25, 2012 at 12:20:12AM -0600, Paul Elliott wrote: Source: libswe Automated builds of libswe are failing because unoconv (used to produce PDF and HTML documentation) assumes a writable home directory, Seems like a matter of setting HOME=`pwd` 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. This won't fix the bug, merely let official buildds proceed. Every single package is supposed to be autobuildable, not merely arch-dependent ones. For instance, libswe just appeared in debian unstable, that means someone must have built it. Your sponsor did, by hand, on i386. How does the build environment of the autobuilder's differ from the one that built libswe on its path to unstable? It hasn't been built in a controlled environment anywhere yet. You can approximate one using pbuilder. Why is the autobuilder's environment correct? In other words, why is this not a bug against the autobuilder's software? You shouldn't assume any directory outside of your build path and /tmp/ is writeable. Here, the bug appears to be in unoconv (if the report is correct, which I did not check), yet it can be trivially worked around by setting $HOME. What is a full build and can I be sure that a full build will never occur in the autobuilder? Every package must be fully buildable from source -- as in, every binary package must be reproduceable depending on nothing you did not explicitely declare in Build-Depends (-Indep, -Arch) and build-essential. If I make a fix to this problem, how can I test that it will work in the autobuilder's evnironment? pbuilder is not 100% identical but should be good enough. And a FTBFS in pbuilder is bad enough. Hope this helps. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
