On 2017-06-29 20:36 +0200, Thomas Nyberg wrote:
> I am trying to build the thunderbird package with some modifications. I
> made the modifications and commited the changes to a local patch, but
> then during the build (using `debuild -uc -us`) I ran out of space. I
> ran `debuild clean` and then deleted different things on my computer and
> then tried to run the build again, but this time it no longer even
> starts. It immediately complains about files that were changed.
>
> It prints out the files that are changed and provides a patch file
> `/tmp/icedove_45.8.0-3~deb8u1.diff.fG4ELW` and asks if I want to commit
> the changes with `dpkg-source --commit`. I don't, however, see any way
> to throw away these changes. How do I do this? If I used git, I would do
> something like `git stash; git stash drop`. Another approach would be to
> apply this patch file in reverse, but I'm not sure how to do that.
In my experience, if you are serious about changing packages it's always
better to create a git repository, if only temporarily. Ideally clone
the existing one mentioned in the Vcs-Git header, but this might be too
big or too outdated, not even containing the changes from the latest
upload. Or create your own from scratch, e.g. with
"git init; git add .; git commit -a -m 'Initial Import'" .
> How do I revert these changes? Is there no option for this in
> `dpkg-source`? I'm posting the entirety of the error printout below.
> Thanks for any help.
If you have already built the source package, the easiest way is to
throw away the mess in the current directory and unpack afresh.
> Also on another note, would this be considered a bug in the debian
> packaging? It seems to me really odd that I wouldn't be able to run
> `debuild clean; debuild` and have it work again.
Yes, that is considered a bug. Debian Policy ยง4.9[1] states the
following about the clean target:
,----
| clean (required)
|
| This must undo any effects that the build and binary targets may
| have had, except that it should leave alone any output files
| created in the parent directory by a run of a binary target.
|
| If a build file is touched at the end of the build target, as
| suggested above, it should be removed as the first action that
| clean performs, so that running build again after an interrupted
| clean doesn't think that everything is already done.
`----
However, with the rise of packaging helpers like git-buildpackage,
people seemed to have stopped caring about this problem since they
always build the package in a scratch space. And this approach (which,
incidentally, has been used in the RPM world for ages) certainly has its
merits, since it completely sidesteps the problem of backing out any
changes the build process makes to the source tree.
Cheers,
Sven
1. https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
