| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759
|
| |
|
|
|
|
| |
perl_build is tried first. Avoids the makemaker warning message introduced by the fix to #527990.
|
|
|
|
| |
#578805
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
debhelper 7.4.11. Closes: #570503
Previously the test used make -s -n | head -n 1 and then chomped the
output. In the case of this bug, root-system's Makefile *always* outputs
something to stdout, even for targets that don't exist, before configure is
run. It accidentially worked before, since the first line it outputs
happens to be empty.
So bring back the chomp to retain compatability with this package that used
to work before, but the test only does the right thing for this package due
to sheer luck, really.
|
|
|
|
| |
misbehave when stderr is closed. Reopen it to /dev/null when testing for the existance of a makefile target. Closes: #570443
|
|
|
|
| |
"-Bpython-support". Closes: #570039
|
| |
|
| |
|
|
|
|
|
|
| |
Here is yet another revision which sets the PREFIX variable to '/usr' which
seems commonly used by Qt projects. Also removed the -e test discussed
previously.
|
|
|
|
| |
(at the end naturally)
|
| |
|
|
|
|
| |
Missed that dh still uses it.
|
|
|
|
|
|
| |
Actually, since ignore_unknown_options is only used with
DH_INTERNAL_OPTIONS, which always uses -O for such options, I was able to
remove that complication too.
|
|
|
|
| |
That messes with the return value of the outer call.
|
|
|
|
|
|
|
|
|
| |
* Add -O option, which can be used to pass options to commands, ignoring
options that they do not support.
* dh: Use -O to pass user-specified options to the commands it runs.
This solves the problem with passing "-Bbuild" to dh, where commands
that do not support -B would see a bogus -u option. Closes: #541773
(It also ensures that the commands dh prints out can really be run.)
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
something with a space in it. Closes: #563557
|
|
|
|
|
|
|
|
|
| |
This patch adds --parallel option that enables parallel builds and does not
impose limits on maximum concurrent processes. --max-parallel (that implies
--parallel) can be used to specify that maximum limit.
Also make necessary adjustments to debhelper.pod and buildsystem_tests for
this option.
|
|
|
|
|
| |
$max is about upper limit. Make algorithm reflect that.
(cherry picked from commit 62d7dc07b97a12912cfe08483c6fb244161224f5)
|
|
|
|
| |
(cherry picked from commit 11b0b2483302f8694d8c6a76c73df1eefca7ad1f)
|
|
|
|
| |
enabled by using the --max-parallel option. This was necessary because some buildds build with -j2 by default.
|
|
|
|
|
|
|
| |
a certian horribly broken makefile
by making the test stop after it sees one line of output from make. (This
may be better replaced with dh's makefile parser in the future.)
|
| |
|
| |
|
|
|
|
|
|
| |
The condition is not what dh_auto_* 7.0.x would have done. The
patch makes auto-selection to pass through cmake.pm if Makefile
was not created. This problem is not very dangerous though.
|
|
|
|
|
|
| |
In order to avoid code duplication, auto-selection code has been refactored
into separate subroutine autoselect_buildsystem(). Both load_buildsystem() and
buildsystem_list() use it.
|
|
|
|
|
|
|
|
| |
Probably due to an overlook in 758ce0bb1f, the '-e' test on build.xml
disappeared, leading check_auto_buildable() to always return '1' for
the ant build system.
Signed-off-by: Cyril Brulebois <kibi@debian.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch alters semantics of check_auto_buildable() a bit. Now it can
also indicate if the source has already been partitially built with the
build system and if so, such build system may be auto-selected over a less
specific its parent (in the inheritance tree) even if the latter is earlier
in the @BUILDSYSTEMS array.
However, this still leaves a requirement that a derivative build system
must not do anything that may break packages of the parent build system.
Otherwise, introduction of a new derivative build system might break
packages which already had that build system implemented via overrides...
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|