Nikolaus Rath writes ("Bug#958989: dgit-user(7): building instructions don't 
work"):
> I'm trying to follow dgit-user(7) to build a modified version of a package.
> I did:

Hi.  This is a thing you should be able to do.

> $ dgit clone valgrind
> $ cd valgrind
> $ git apply ../my_special_patch.diff
> $ git commit -m "Way better than vanilla!"
> $ gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit
> $ git clean -xdf
> $ sbuild -c buster-amd64 -A --no-clean-source --dpkg-source-opts='-Zgzip -z1 
> --format=1.0 -sn'
> 
> But this eventually fails with:
...
>  dpkg-source -b .
> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream 
> tarball found at ../valgrind_3.15.0.orig.tar.{bz2,gz,lzma,xz}
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 25

How sad.

There are two things wrong here.

One is that sbuild seems to be ignoring the --dpkg-source-opts, or
maybe the rune was always wrong.  I think I will have to investigate.
I *thought* we had a test for this rune but maybe not one involving
sbuild.

... yes, we do.  tests/tests/sbuild-gitish.  Obviously the test isn't
working right.

The other oddity, is that this complaint about
valgrind_3.15.0.orig.tar.* implies that there isn't a
valgrind_3.15.0.orig.tar.bz2 but when I tried dgit clone valgrind it
left me one in my "..".  I conjecture that you have a non-default
build-products dir for dgit but your sbuild doesn't have that
configured ?  This ought not to matter with the --format=1.0 -sn rune.
I don't think this is in your way but it would be nice to confirm that
there isn't another bug here.


Regards,
Ian.

Reply via email to