| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
| |
dirs. Closes: #641279
This is extra work, but querying dpkg-architecture for the multiarch lib
dir could easily take just as long.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
has explicit binary-indep and binary-arch targets.
Closes: #639341 Thanks, Yann Dirson for test case.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* dh: Now you can use override_dh_command-arch and override_dh_command-indep
to run different overrides when building arch and indep packages. This
allows for a much simplified form of rules file in this situation, where
build-arch/indep and binary-arch/indep targets do not need to be manually
specified. See man page for examples.
* dh: Note that if a rules file has say, override_dh_fixperms-arch,
but no corresponding override_dh_fixperms-indep, then the unoverridden
dh_fixperms will be run on the indep packages.
* dh: Note that the old override_dh_command takes precidence over the new
overrides, because mixing the two types of overrides would have been
too complicated. In particular, it's difficult to ensure an
old override target will work if it's sometimes constrained to only
acting on half the packages it would normally run on. This would be
a source of subtle bugs, so is avoided.
|
| | |
|
| |
|
|
|
| |
Should be no behavior changes, although I did drop the comment when
skipping an empty override target.
|
| |
|
|
|
| |
A future nostripexceptonfullmoon option seems unlikely, but sure,
let's be strict. More importantly, let's reuse good code.
|
| | |
|
| |
|
|
| |
3.0 (quilt) is presumably better
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
5.10 is in stable, which is good enough for me.
(And this dependency was added for very unclear reasons in the first place.)
|
| |
|
|
|
| |
It was only needed so dh_shlibdeps and dh_strip, which are no longer run
during build.
|
| |
|
|
|
|
|
| |
binary target when all packages being acted on are indep.
This is a not particularly interesting optimisation, but it will allow my
next commit..
|
| |
|
|
| |
The man page recode is not necessary as the man pages are utf-8 already.
|
| | |
|
| |
|
|
|
|
|
|
| |
This patch makes dh_installlogcheck be similar to other helpers, like
dh_installlogrotate that already support a --name option: to install
the files as if they were installed by a different package.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
|
| | |
|
| | |
|
| |
|
|
| |
python-sphinx. Closes: #637492 Thanks, Jakub Wilk
|
| | |
|
| |
|
|
| |
Can this test be written w/o using --after?
|
| |
|
|
|
|
| |
To avoid re-breaking packages that were already broken a first time by
dpkg-buildpackage unconditionally setting the environment, and unbroke it
by unsetting variables in the rules file. (Example: numpy)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Pass appropriate -jN option to ctest (via ARGS variable in the Makefile) to
enable support for running tests in parallel. Similarly to makefile build
system, ctest -j1 mode is enforced even when parallel mode in debhelper is not
explicitly enabled.
Unlike make, CTest does not have "unlimited parallel" setting (-j implies -j1).
So in order to simulate unlimited parallel, allow to fork a huge number of
threads instead.
|
| | |
|
| |
|
|
|
|
| |
Assume that the package can be cleaned (i.e. the build directory can be
removed) as long as it is built out-of-source tree and can be configured. This
is useful for derivative buildsystems which generate Makefiles.
|
| |
|
|
| |
override targets instead.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If a rules file has a custom install or binary target, those targets
still need to explicitly depend on the build target. Unless dh is used
in such a target (which it probably is of course).
It's not possible to avoid the need for those dependencies. A rules file
with a hand-written binary target simply does not run dh, so dh can
do nothing to help it run the build target.
Reword the docs to not give the wrong impression that dh somehow
magically makes that work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a rules file with an explict build target. Closes: #634784
This hack was necessary back when dh ran each target, and so recursively
invoked itself. If debian/rules binary ran debian/rules binary-arch ran
debian/rules install-arch ran debian/rules build-arch, then debhelper
commands would be running with -a throughout, and so for debian/rules
binary-indep it would have to re-run all the commands with -i. The hack
avoided this extra work (and expecially dh_auto_configure running twice) by
first running the common commands without -i or -a and only then following
through with running the explicit per-arch targets, which didn't run many
(if any) additional commands.
But now dh does not run implicit targets, so (unless targets
are explicit), it will instead just construct a sequence of debhelper
commands to run directly, and so the -a flag is avoided.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Also simplified a lot by not special-casing the base case, at the cost of
always forking once.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Implement support for parallel deb builds, when DEB_BUILD_OPTIONS has
parallels=N - limiting the number of forked processes to N.
Requested-By: Kari Pahula <kaol@debian.org>
Signed-Off-By: Gergely Nagy <algernon@madhouse-project.org>
|
| | |
|
| | |
|
| | |
|
