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.
