Control: clone -1 -2
Control: retitle -2 build-source and push-source disregard -wc
Control: tags -2 - patch
Control: severity -2 normal
Mattia Rizzolo writes ("Bug#910687: dgit: crash with perl backtrace"):
> I'm now already falling asleep, I'll try to apply your patch tomorrow and
> report back :)
FYI, I discovered some other weirdness with what you were trying to
do.
Firstly, from your transcript, you didn't commit debian/source/format.
It's an un-ignored un-tracked file. dgit nowadays always builds
source packages in a private area and bases them on your git tree.
The result is that if you do what you did it will (i) notice the
debian/source/format in the working tree and decide to do quilt
linearisation (ii) call dpkg-source --commit in the private area in a
clean tree with no debian/source/format. The result is a 1.0 package.
This is arguably a bug. But the only thing dgit could sensibly do
would be to spot that yuu did this and stop with a complaint.
I experimented with committing debian/source/options. If I do that
dgit makes a hamfisted attempt at quilt linearisation: again, it
attempts to call dpkg-source --commit starting at a commit which does
not have debian/source/format. I will fix dgit to stop quilt
linearisation when it encounters a change to debian/source/format, and
you would then get this error message:
dgit: error: quilt fixup cannot be linear. Stopped at:
dgit: 45a228db..d5c44c79: changed debian/source/format
along with some essentially useless suggestions.
What you are asking dgit to do is rather outside of its scope. The
quilt linearisation feature is intended to support an NMUer or user
adding a few commits on top. It is not intended as a general puprose
git workflow and delta queue management tool. It certainly isn't
intended for converting from 1.0-with-diff to `3.0 (quilt)'.
I infer that you want to do `3.0 (quilt)' with this package, and
you're using git, so you will need a git workflow tool. Which one are
you intending to use ? Perhaps the real problem is that you intend to
use git-debrebase but forgot to convert the branch (with git-debrebase
convert-from-dgit-view) ? Or that you intend to use gbp pq but didn't
make a pq branch and export it ?
Having said all that, I experimented with rebasing the little stub
branch so that the dgit-generated diff import commit was *after* my
change to add debian/source/format. That resulted in a branch that
dgit was able to do quilt linearisation on. The single patch that
comes out is of course the patch form of the dgit diff import commit.
But having done that IDK how you would rebase onto a new upstream
version. You'll definitely need a workflow tool for that (or I guess
you could do it by hand with raw git runes if you had iron
concentration and an iron constitution).
Also, arguably something should have stopped you proceeding with an
untracked unignored files (perhaps, especially as you specified -wc).
But the clean mode is basically ignored with build-source (and
push-source) since the tree does not need to be cleaned. But spotting
uncommitted files is important. I'm not sure exactly what to do about
this but I have cloned this bug to track this issue. It seems odd to
say that --clean=check ought to make build-source and push-source
check for loose files, even though they usually don't actually clean
the tree at all. Perhaps there should be a separate check which
doesn't depend on the clean mode ?
Regards,
Ian.
