Russ Allbery writes ("Bug#884646: No commands in dgit-maint-gbp appear to work
with 3.0 (quilt) packages"):
> $ dgit gbp-build
> gbp:error: You have uncommitted changes in your source tree:
> gbp:error: On branch debian/master
> Your branch is ahead of 'origin/debian/master' by 6 commits.
> (use "git push" to publish your local commits)
>
> Changes not staged for commit:
> (use "git add/rm <file>..." to update what will be committed)
> (use "git checkout -- <file>..." to discard changes in working directory)
>
> modified: Makefile.am
> deleted: conf_convert.sh
> modified: configure.ac
> modified: main.c.in
> modified: mkchroot.sh
> modified: pathnames.h.in
> modified: rssh.1
> modified: rssh.conf.5
> modified: rssh.conf.5.in
> modified: rssh.conf.default
> modified: rssh.h
> modified: rssh_chroot_helper.c
> modified: rsshconf.c
> modified: util.c
> modified: util.h
>
> Untracked files:
> (use "git add <file>..." to include in what will be committed)
>
> .pc/
> conf_convert
Well. I tried this and: with the build-dependencies not installed it
bombs out, and then leaves the tree in the state you show above.
This is not ideal. Ideally it ought to clean up, but the only
way it can do that reliably is with git and that's dangerous. -wgf
avoids this, as the message suggests.
Then I tried it again (without cleaning the tree or anything) with the
b-deps installed and of course then dgit complains that the tree is
dirty; that complaint is right.
Then I tried again after git-reset --hard && git-clean -xdff and now
dgit gbp-build --git-ignore-branch
works just fine. (In sid.)
Unfortunately it left the tree dirty, but that seems to be a property
of the package. I don't really think it can be dgit's job to clean
that up.
I tried on stretch, and the package FTBFS on stretch:
rssh_chroot_helper.c:103:20: warning: ignoring return value of
?setuid?, declared with attribute warn_unused_result
[-Wunused-result]
etc. - but it got further than your transcript, I think.
So, overall, I cannot reproduce the problem you exhibit above. Do you
still have the full shell history or any other information about how
you got into this state ?
> I then tried with --git-ignore-new, but get:
Trying this was a mistake, since you shouldn't really have been in
this situation, and you shouldn't need to supply that flag unless you
deliberately have uncommitted files in your tree.
In any case I wouldn't expect that to help.
Right, on to the next message in this bug...
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
