[buildd-tools-devel] Bug#700317: sbuild -s fails if package has Build-Depends-Indep

Ian Campbell ijc at hellion.org.uk
Wed Dec 30 14:16:13 UTC 2015


On Thu, 2015-12-24 at 01:07 +0100, Johannes Schauer wrote:
> Control: tag -1 + moreinfo
> 
> On Mon, 11 Feb 2013 14:58:28 +0000 Ian Campbell <ijc at hellion.org.uk>
> wrote:
> > When building a package (Xen, from Stable as it happens) which has:
> >   Build-Depends-Indep: graphviz, gs-common, texlive-fonts
> -recommended, texlive-latex-recommended
> > with the command:
> >   $ sbuild -d squeeze -s -j4
> > 
> > The build fails with:
> >   dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin:
> vendor): -g -O2
> >   dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin:
> vendor): 
> >   dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin:
> vendor): -g -O2
> >   dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin:
> vendor): -g -O2
> >   dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: 
> vendor):  APT policy: (990, 'testing' 
> >   dpkg-buildpackage: source package xen
> >   dpkg-buildpackage: source version 4.0.1-5.7
> >   dpkg-buildpackage: source changed by Ian Campbell <
> ijc at hellion.org.uk>
> >    dpkg-source --before-build xen-4.0.1
> >   dpkg-buildpackage: host architecture amd64
> >   dpkg-checkbuilddeps: Unmet build dependencies: graphviz gs-common
> texlive-fonts-recommended texlive-latex-recommended
> >   dpkg-buildpackage: warning: Build dependencies/conflicts
> unsatisfied; aborting.
> >   dpkg-buildpackage: warning: (Use -d flag to override.)
> > 
> > I can work around this by adding -A to the sbuild invocation but I
> think this
> > probably ought to Just Work.
> > 
> > I also confirmed that this occurs when building the trunk SVN
> version of Xen in
> > a sid chroot. I'm using sbuild on Wheezy/Sid regardless of the
> chroot.
> > 
> > I suppose this might actually be a dpkg-buildpackage bug, I'm not
> really sure
> > what the semantics of building the source vs. Build-Depends
> actually are.
> 
> maybe this is actually a bug in the documentation.
> 
> Sbuild is for building binary packages. If you want to build a source
> package,
> then don't use sbuild but either use:
> 
> $ dpkg-buildpackage -S
> 
> or
> 
> $ dpkg-source -b .
> 
> A source package is the *input* to sbuild not its output.

This is a good point, not a way I'd thought about it until now. I guess
I was simply confused because I typically run sbuild from a source
package directory and it automagically makes a .dsc for me.

> If you really, really want sbuild to also generate a source package, then you
> can add the -s or --source option. As the man page points out, this will run
> dpkg-buildpackage without the -B option (which would do a binary-only build,
> limited to architecture dependent packages, which is the default mode of
> operation of sbuild). Thus dpkg-buildpackage will *also* create a source
> package *in addition* to the binary packages it creates. This is why all the
> build dependencies are needed.
[...
> If you have an idea how the documentation can be improved to prevent this kind
> of misunderstanding in the future, I'd be happy to hear it!

I think adding some of the wording you use above to the --source
documentation would do the trick. In particular "in addition to the
binary packages" or something along those lines.

Maybe you would also want to add "this is the default" to the --no
-source option?

One thing I'm still not sure of, is if you run in the mode where a
source package directory is passed as an argument, and sbuild therefore
runs dpkg-source -b for you, but you also pass -s, am I correct in
thinking that a second .dsc will then be generated by dpkg-buildpackage
and included in the .changes file and that this will be a different
.dsc (timestamps etc) to the one which sbuild made (which is thrown
away)?

Actually, a second thing I'm not sure of, given that -s says it will
run dpkg-buildpackage without -B, asking therefore for a .dsc as well
as arch and indep binaries to be built, shouldn't sbuild therefore be
installing all the build-deps, both -dep and -indep?

Ian.



More information about the Buildd-tools-devel mailing list