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.