| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
|
|
|
| |
Schepler.
|
|
|
|
| |
named debian/package to be installed as the init script. Only fixed in v10 since packages might depend on this behavior. Closes: #719359
|
| |
|
|
|
|
| |
command that is now skipped creating the package build directory, the directory is created when a command is skipped. This workaround is disabled in compat level 10. Closes: #707336
|
| |
|
| |
|
|
|
|
| |
Closes: #665891
|
| |
|
|
|
|
|
| |
debhelper used to have its own noopt handling, but this was replaced by
dpkg-buildflags doing it
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
* Finalized v9 mode, which is the new recommended default.
(But continuing to use v8 is also fine.)
* It is now deprecated for a package to not specify a compatability
level in debian/compat. Debhelper now warns if this is not done,
and packages without a debian/compat will eventually FTBFS.
|
| |
|
|
|
|
| |
in debian/ directories turns out to be atrocious; who knew?
|
|
|
|
|
| |
Reason:
http://git.42mm.org/?p=python-greenlet;a=blob;f=debian/rules;h=bd009f86895d496999cd412eac44dbae7b9f1caa;hb=HEAD#l10
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. ]
|
|
|
|
| |
enough binutils and gdb; debhelper backport may need to disable this. Thanks, Aurelien Jarno and Bastien ROUCARIES. Closes: #631985
|
| |
|
| |
|
| |
|
|
|
|
| |
Closes: #643069
|
| |
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
dh
|
| |
| |
| |
| |
| |
| |
| |
| | |
* dh_auto_build, dh_auto_configure, dh: Set environment variables
listed by dpkg-buildflags --export. Any environment variables that
are already set to other values will not be changed.
Closes: #544844
* Also, support DEB_BUILD_OPTIONS=noopt, by changing -O2 to -O0.
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
debhelper.pod
debian/changelog
|
| |
| |
| |
| |
| |
| |
| | |
--libexecdir when using autoconf. Closes: #541458
Fixed rleigh's patch to be more correct in the edge case where there is
a non-multiarch dpkg (ie, backports).
|
|/ |
|
| |
|
|
|
|
|
|
| |
Note to backporters: If you remove that dependency, debhelper will fall
back to not doing multiarch stuff in v9 mode, which is probably what you
want.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
As advised in man(1), always use: B<bold text> type exactly as shown.
I<italic text> replace with appropriate argument.
s/debian/Debian/ if needed. s/ / / also.
s/perl/Perl/ s/python/Python/ and s/emacs/Emacs/ too.
|
| |
|
|
|
|
| |
#578805
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids ambiguities when parsing options to be passed on to debhelper
commands. (See #570039)
In the end, the idea of putting the debhelper command options after --
seemed to need too much knowledge about whether an option like
--buildsystem is a dh option or a command option.
I did consider making no change.. The ambiguities this eliminates are
small. But it seemed worth simplifying dh's option parser, and only about
1/6th of calls to dh in the archive don't put the sequence first already.
(Docs have shown that as the right thing to do for some time.)
|
|
|
|
| |
it generates shlibs files for. This means that -X can be used to exclude libraries from processing by dpkg-gensymbols. It also means that libraries in unusual locations, where dpkg-gensymbols does not itself normally look will be passed to it, a behavior change which may break some packages. Closes: #557603
|
|
|
|
| |
commands. (Unknown options in DH_OPTIONS still only result in warnings.)
|
|
|
|
| |
dpkg supports the field now, so no XC- needed
|