| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
I see no reason to make this v9 only.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Debhelper config files may be made executable programs that output the
desired configuration. No further changes are planned to the config file
format; those needing powerful syntaxes may now use a programming language
of their choice.
In many bugs I see a tendency of users wanting debhelper configuration
files to have their pet feature from some programming language. So I choose
to short-circuit this process by taking it to its logical conclusion, and
without the bother of developing a new language myself.
[ Is this consistent with my boycott/disinterest in integrating features
features first developed in Ubuntu? Yes. Instead of blocking the
issue of multiarch needing variable expansions, I have stepped
back and let anyone make whatever mess they desire while not forcing
that mess on the rest of us. ]
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
override_dh_command-indep targets. This is needed when the binary target is run, rather than binary-arch/binary-indep. Closes: #648901
|
| |
|
|
| |
enough binutils and gdb; debhelper backport may need to disable this. Thanks, Aurelien Jarno and Bastien ROUCARIES. Closes: #631985
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
#643702 Thanks, Steve Langasek.
|
| | |
|
| |
|
|
| |
Closes: #643069
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
A future nostripexceptonfullmoon option seems unlikely, but sure,
let's be strict. More importantly, let's reuse good code.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
python-sphinx. Closes: #637492 Thanks, Jakub Wilk
|
| |
|
|
|
|
| |
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)
|
| | |
|
| | |
|
| |
|
|
| |
override targets instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
--buildsystem=qmake_qt4. Closes: #566840
There is that build system option patch that I suckily never applied,
and could be used here.. but this is at its core a different build system,
and so handling it as such makes the most sense.
It may make sense to have a qmake_qt3 build system, but perhaps QT 3
will instead just go away. I considered just waiting, but this is an easy
fix. ;)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
dh_pysupport has started emitting a deprecation warning, which is
very annoying since it clutters every build that uses dh -- even builds
where it doesn't do anything. Since there is not just a dh_python2, but
also a dh_python3 waiting in the wings, this is clearly too volatile
a situation for dh to try to support further.
I considered making dh_python detect and run the right dh_python[23] helper
-- a python helper helper as it were -- but 70-odd packages still use that
command.
|
| | |
|
