| Commit message (Collapse) | Author | Age |
|
|
|
| |
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A .dsc containing patches which patch files multiple times would be
rejected by dpkg-source due to #848611.
Work around this by arranging for the patch of interest to never be
the first patch, by introducing (and then evaporating) a dummy patch.
Yuk.
Closes:#848391.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
during .dsc import. Apropos of #848391.
gbp swallows the error from the first run (without --whitespace=fix).
Previously only that first run would do anything useful; the second
would complain about --whitespace=fix. So failures of dpkg-source
would always produce a useless error message.
Instead, tolerate (and ignore) the --whitespace=fix option which gbp
passes during the second run. This means that the second run tries to
do the actual work.
This only does extra work if the first run failed, and since the first
and second runs are now equivalent, that happens when the second run
fails too. But in return for that extra work, we get a report which
actually mentions something that unexpectedly went wrong.
(The alternative would be to have absurd/git try to stash and then
reproduce its previous error, or to make more fragile assumptions
about gbp's behaviour.)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
|
|
|
|
|
| |
Honour DGIT_ABSURD_DEBUG, which is set by dgit from $debuglevel.
Also, in dgit, open the output file for append.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
|
|
|
|
|
| |
Right now this simply replaces all the echo >&2, producing no
significant functional change.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
|
|
|
|
| |
unusual object, in case dpkg-source doesn't.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
gbp import can fail due to git apply not understanding patches.
This is #841867 (against dgit).
The underlying problem is #841866 (in gbp pq) which exposes things
like #841865 and #829067 (in git). I imagine there are other lurking
incompatibilities between git-apply and dpkg-source.
We could in principle reimplement the gbp patch metadata extraction.
But that would be quite tiresome and have its own compatibility
problems.
The real problem is just `git apply'. (Indeed gbp already tries git
apply without, and then with, a whitespace fix option.) We work
around the trouble by providing our own implementation of `git apply'.
Specifically:
We try to do things the sane way (just running gbp pq import) first.
If that works, great. If it doesn't, we put /usr/share/dgit/absurd on
the PATH. That contains only a sh script called `git'. This sh
script figures out whether the caller is trying to invoke `git apply'.
If not, it runs the real git.
If the caller wanted git-apply, the absurd git script emulates it
using dpkg-source --before-build. Conveniently, we know that the
series file will not be touched by patches. So we can write just the
patch we care about into the series file, and run --before-build,
which applies just that one patch.
The results are committed (minus the .pc), and for the next patch,
dpkg-source sees again a tree with simply a single patch to apply.
We try ordinary gbp pq first because our absurd approach is very slow
on a big tree. Also we would like to maximise our chances of the
import working. If git and/or gbp ever work better by themselves, all
of this craziness will simply not happen.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|