| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
|
|
|
| |
The shell-quoted sed code passed as parameter 4 is fragile (see Bug#665296).
Make it possible to pass a sub that operates on each line via $_ instead.
Also add a basic unit test for Dh_Lib, for now just with tests for autoscript.
|
| |
|
|
|
|
| |
breaks dh_usrlocal and must be considered part of its interface. Added to interface documentation. Closes: #665263
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
* 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?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. ]
|
| |
|
|
|
|
|
| |
A future nostripexceptonfullmoon option seems unlikely, but sure,
let's be strict. More importantly, let's reuse good code.
|
| |
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
This reverts commit fcfcd1298f6ea1fcfb2b2b5a529303270aa800d9.
Per Raphael's mail.
|
|
|
|
|
|
| |
Do that even when dpkg-buildpackage modifies environment variables. Also
document DEB_${flag}_{APPEND,SET} as recommended way to override standard build
flags.
|
| |
|
|
|
|
|
|
|
| |
Dpkg::BuildFlags API is declared stable. It should be safe to use it directly
rather than dpkg-buildflags wrapper. In addition, do not do any
DEB_BUILD_OPTIONS=noopt handling in debhelper. Dpkg::BuildFlags already does it
for us.
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Open compat level 9, which incompatibly changes dh_auto_configure behavior
to set --libdir and --libexecdir to the multiarch directory path. This
requires dpkg-dev 1.16.0 (not yet released) for the multiarch directory
variable, so bump the dependency to this version.
Also set a new substvar, misc:Pre-Depends, to multiarch-support, a virtual
package provided by versions of eglibc that support the multiarch library
paths at runtime; this needs to be a pre-dependency to ensure unpacked but
not-yet-configured libraries can still be found during upgrades, so library
packages converting to multiarch (i.e., switching to compat 9) will need to
add this substitution by hand to debian/control.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes in 76ef1cbd64829ee4a5156a5fc4b887bcba6b974f broke
--remaining-packages in override target.
Now all debhelper commands run in the override target are marked as running
as part of the override, and when the whole target is run, the log is
updated to indicate that commands run during the override have finished.
So, inside the override target, --remaining-packages will see the commands
run as part of the target as having been run. Outside, if the target
fails, dh won't see the commands run it it as having been run.
Closes: #612828
|
| |
|
|
|
|
|
|
|
| |
Note that only the overridden command is inhibited. I wanted to avoid a
behavior change if a rules file runs other debhelper commands inside the
target, and relies on the logging preventing them being run later on in
the sequence.
|
| |
|
|
|
|
| |
commands. (Unknown options in DH_OPTIONS still only result in warnings.)
|
|
|
|
| |
typical package with no explicit architecture mentions in control file or debhelper config files.
|
| |
|
| |
|
| |
|
|
|
|
| |
dpkg-architecture at all for simple comparisons not involving architecture wildcards. Closes:# 579317
|
| |
|
| |
|
|
|
|
| |
acting on all packages in the control file, which was a guaranteed failure if the control file listed packages that did not build for the target architecture. After recent optimisations, this default behavior can efficiently be changed to the more sane default of acting on only packages that can be built for the current architecture. This change is mostly useful when using minimal rules files with dh. Closes: #572077
|
|
|
|
|
|
|
|
|
| |
dh used DH_OVERRIDE_UNKNOWN_OPTIONS, which was too broad as it affected
commands run via override targets and caused there to be no warning about
unknown options.
Now unknown options are only ignored when parsing DH_INTERNAL_OPTIONS and
dh's own options.
|
| |
|
|
|
|
|
| |
exit cannot be caught with eval.. I used exit before because I thought it
was cute for erorr() to call warning(). Silly.
|
|
|
|
| |
already said it was deprecated.) Closes: #555899
|
|
|
|
|
|
|
|
|
|
|
| |
Now clean_jobserver_makeflags will only remove --jobserver settings
from MAKEFLAGS. This is simpler and easier to understand than
the old behavior, which, if there was no --jobserver, removed
all -j and --jobs, while leaving those when removing --jobserver.
This relies on -j options passed to make overriding
-j settings in MAKEFLAGS. So we don't need to clean those out,
we can just override them.
|
|
|
|
|
|
|
|
|
|
|
| |
I disliked the complexity of the return values, and the boilerplate
code that followed the two calls to the function, to clean/unset
MAKEFLAGS. To solve both, I refactored it into two functions, one simply
tests to see if a jobserver is specified but unavailable, while the other
cleans/unsets MAKEFLAGS.
This loses the ability to pull the jobs-N count out of MAKEFLAGS,
but that was not currently used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Add routine to Dh_Lib (used by dh and makefile.pm) which is capable of
detecting make jobserver and job control options from the MAKEFLAGS environment
variable. It also generates and returns a clean up MAKEFLAGS from these
options.
2) Add --parallel option to build system framework which allows source packages
to specify that they support parallel building. Optional value for this option is
the number of maximum parallel process to allow. However, the actual number of
parallel process (if any) for the specific build is determined from
DEB_BUILD_OPTIONS env variable as specified by Debian Policy.
By default (no --parallel option) parallel is neither enabled nor disabled
(depends on the external environment). However, dh may pass --parallel to
dh_auto_* implicitly in case 4) described below.
3) Add parallel support for makefile buildsystem. This implementation
forcefully starts a new make job server (or disables parallel) for the number
of process requested. If --parallel was not passed to the build system at all,
the build system will only clean up MAKEFLAGS from stale jobserver options to
avoid pointless make warnings.
4) If dh detects that it is being run by dpkg-buildpackage -jX and it is NOT
run with "+" prefix from debian/rules (i.e. jobserver is not reachable), it
enables --parallel implicitly. This closes: #532805.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|
| |
|
|
|
|
|
|
|
| |
The -a flag now does the same thing as the -s flag, so debhelper users do
not need to worry about using the -s flag when building a package that only
builds for some architectures, and dh will also work in that situation.
Closes: #540794
|
|
|
|
| |
arch all.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly reverts commit f897611a77726655aea258af0c4d52a8ce759ebc.
Remaining cosmetic changes (all functional changes have been reverted):
* Refactoring of option string into split_options_string() sub (no semantic
changes though).
* Cosmetic change in Dh_Buildsystems.pm.
Breaks testsuite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* DH_AUTO_OPTIONS is like existing DH_OPTIONS, just only for dh_auto
stuff. This also avoids "explosion" of separate DH_AUTO_* environment
variables (i.e. exports in debian/rules) and encourages usage of dh_auto
command line option names. DH_AUTO_OPTIONS is passed via "extra_args" to
Dh_Lib::init() (API addition).
* When splitting options from DH_OPTIONS and its flavours, allow arguments
to include whitespaces if they are escaped with backslash (\) (see
split_options_string()). Document this in debhelper.pod.
* Short option for --buildsystem is -c (aka class).
* Provide API to cancel option specs from default debhelper options.
It will be used in the feature.
|