| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
the patch and for verifying no affected package is broken by this change.
|
| |
|
|
|
|
| |
breaks dh_usrlocal and must be considered part of its interface. Added to interface documentation. Closes: #665263
|
| |
|
| |
|
| |
|
|
|
|
| |
info dir file. Closes: #634741
|
| |
|
|
|
|
|
|
|
|
| |
* 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. ]
|
| |
|
|
|
|
| |
Closes: 497653
|
| |
|
| |
|
|
|
|
|
|
|
| |
The standard way to pass build flags to makemaker perl build systems is to
set the OPTIMIZE variable on the commandline; CFLAGS in the environment gets
ignored entirely. So pass the CFLAGS from the environment to Makefile.PL so
makemaker packages can also benefit from dpkg-buildflags.
|
| |
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
--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. ;)
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
--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).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't work reliably, see #607313.
Probably that is caused by the perl_build buildsystem not being detected
for a package that has a Makefile.PL, and so MODULEBUILDRC is not
overridden. So, I could add it there too, but then it's also possible for
it to be run from a Makefile.. so I could add it to dh_auto_*. But
then there are packages that don't use those. So I conclude that dealing
with this in debhelper is out of its scope, and this needs to be fixed
at a higher level, probably dpkg-dev.
|
|
|
|
| |
listed.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759
(cherry picked from commit 865e6266a5eaae81004bf530bc23da1c3fdc10b1)
Conflicts:
debian/changelog
|
|
|
|
|
|
|
|
|
|
|
|
| |
when python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759"
This reverts commit 865e6266a5eaae81004bf530bc23da1c3fdc10b1.
Conflicts:
debian/changelog
Too late for 8.0.0 since testing is frozen. Will put back in later.
|