Mimicking Ubuntu's build robots
jw+debian at jameswestby.net
Fri Jan 9 16:39:23 UTC 2009
On Fri, 2009-01-09 at 17:17 +0100, Markus Hitter wrote:
> Am 09.01.2009 um 02:22 schrieb James Westby:
> > On Fri, 2009-01-09 at 01:26 +0100, Markus Hitter wrote:
> >> Hello all,
> >> in an attempt to get some insight about
> >> <https://bugs.launchpad.net/ubuntu/+source/gnustep-base/+bug/245981>
> >> [...]
> >> So my question is: how would I best mimick Ubuntu's build machinery?
> >> Probably a virtual machine, to allow building i386 on an AMD64 host,
> >> but which type of installation, what else?
> > [...]
> > There are local copies of the DTDs in the source package, the one it
> > probably wants is ./Tools/gsdoc-1_0_3.dtd, but it is apparently
> > searching for a file ending in ".xml", and from what I can see only
> > adds user, system and network locations to the search path, though
> > the intent of "-HeaderDirectory ../Tools" may be to do this.
> So you mean I have three (Matt's, your's, Mine) patch recommendations
> now, but there is no way to actually test such a patch without
> commiting it to Ubuntu's public repo's? I'm used to provide tested
> patches only, so I hope this isn't true.
You can apply the patch and test build the documentation directly,
temporarily disabling your network.
You can try building the whole package with your network disabled,
which should build Arch: all packages on amd64 I believe.
You can push it to a PPA which has a very similar environment to the
You can build a source package with the proposed change and jump on
#ubuntu-motu and ask for someone to test build without network access
for you, or indeed ask here.
You can provide the patch and explain that it's not tested, and give
instructions on how a sponsor can check that it will work correctly.
If the worst comes to the worst we can just upload it to the archive,
another build failure isn't a big problem, but as you can see there
are plenty of options until we reach that point.
More information about the Ubuntu-devel-discuss