path: root/absurd
Commit message (Collapse)AuthorAge
* absurd/git: Do not fail to import a .dsc containing patches to .git/ (!)Ian Jackson2016-12-19
| | | | Signed-off-by: Ian Jackson <>
* absurd/git Do not fail to import certain weird .dscsIan Jackson2016-12-19
| | | | | | | | | | | | | | 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 <>
* Produce better error reporting when absurd git wrapper fails on a patchIan Jackson2016-12-19
| | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* absurd/git: Better debuggingIan Jackson2016-12-19
| | | | | | | 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 <>
* absurd/git: Introduce log()Ian Jackson2016-12-19
| | | | | | | Right now this simply replaces all the echo >&2, producing no significant functional change. Signed-off-by: Ian Jackson <>
* absurd git-apply fallback: defend against debian/patches/series being an ↵Ian Jackson2016-10-25
| | | | | | unusual object, in case dpkg-source doesn't. Signed-off-by: Ian Jackson <>
* Import: Use absurd `git apply' emulation if gbp pq import failsIan Jackson2016-10-24
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 <>