Age | Commit message (Collapse) | Author | Files | Lines |
|
Only load the Dpkg::Compression::FileHandle module if the compression
option is enabled.
Some control files are not supposed to ever be compressed, and making it
possible to disable the compression support reduces substantially the
amount of modules being loaded by default.
|
|
Addresses: Subroutines::ProhibitManyArgs
Warned-by: perlcritic
|
|
This way we remove code executed at import time.
|
|
Call setup_color() only if we are going to print something, so that
we remove code executed at import time.
|
|
If we are not using colors we should not be imposing the additional load
times over most modules using the error handling functionality.
|
|
The Dpkg::Vendor-specific modules are loaded as part of many other
modules load-chains. But not all parts of these modules are used, as
they are hook-specific. Switch these two modules to be required only
when we are going over the specific code paths needing them.
|
|
If we are not using signal handling code we should not be imposing the
additional load times over most modules using the transparent compression
support, which currently includes all Dpkg::Control users.
|
|
Missed in commit d62520090a7dafb123b6f1f4d4e9b61b75218057.
|
|
|
|
|
|
|
|
Closes: #870221
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
|
|
When the option is true it will set a get_func_key to a function that
generates a unique tuple for that item. For CTRL_INDEX_SRC and CTRL_PKG_SRC
use the Package and Version fields, for CTRL_INDEX_PKG and CTRL_PKG_DEB use
the Package, Version and Architecture fields, all joined by "_" to index
the entries.
This behavior will become the default in dpkg 1.20.x. A deprecation
warning will be emitted now requesting to set the option to true or
to set a get_key_func options.
Prompted-by: Johannes Schauer <josch@debian.org>
|
|
|
|
The current implementation supports several comment lines, VCS and
editor variable settings which get ignored. In addition, to be able
to handle ancient changelog entries, the parser will detect those and
ignore while preserving them for output.
Closes: #858579
Reviewed-by: G. Branden Robinson <g.branden.robinson@gmail.com>
|
|
|
|
Our current minimal Perl version contains a new enough List::Util module
implementing none and any, and several other functions.
|
|
These are generated files, and these pathnames are part of the external
interface. With the introduction of the buildinfo support, these get
generated even on source builds, which means that it can disrupt
previous workflows based on not cleaning the source tree, because they
assumed that source-only builds did not have filesystem side-effects.
|
|
The documentation on the CHANGES section did not match the current
$VERSION, bump it so that it does, and document when it was actually
bumped, so that users do not get confused.
Fixes: commit 608f93858f2fc44e86538fbf585d4e0fa9cf7743
|
|
This makes sure the perl module is using a directory traversal resistant
patch implementation, currently that's only GNU patch.
Fixes: CVE-2017-8283
Stable-Candidate: 1.17.x
|
|
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Delegate the setting to gcc builtin or an explicit request by a user.
This is needed to cope with the general PIE brokenness situation in
Debian, and the current specific brokenness of a Debian gcc patch
mangling the dpkg build flags.
This is wrong in so many levels, as we'll have discrepancies between
architectures, the interface towards maintainers is inconsistent, and
updating the PIE support needs touching and coordinating two places. But
it's certainly the current lesser evil.
Closes: #848129, #845550
|
|
Specifically kfreebsd-amd64, kfreebsd-i386, sparc and sparc64.
|
|
Closes: #855450
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
If the ELF class or endianness are unknown or bogus, ignore the file.
Reported-by: Niels Thykier <niels@thykier.net>
|
|
Emit an explicit warning whenever we cannot detect the format for
an executable object, instead of delegating this to the subsequent
objdump, and letting it die, which ca be canfusing and is not
future-proof.
Closes: #854536
|
|
The rest of the code handles non-binary files (ELF in this case)
gracefully and ignores them, even though not very explicitly, as
objdump will emit a warning that might be difficult to decrypt.
We will still fail for other read failures that are not just
short-reads, as those imply some actual problem with the passed files.
Closes: #854536
|
|
The affected code in NetBSD was bogus, and has been removed now. So
there is no point in trying to special case the EM_SPARC32PLUS ELF
machine ID depending on the ELF class, for something that should never
happen.
Ref: https//gnats.netbsd.org/51925
|
|
These are too unreliable for exact matches. There are objects with
EABIv4 in the wild, even when the current is EABIv5. The soft and
hard float flags are not always set on armel and armhf respectively,
although the Tag_ABI_VFP_args attribute in the the ARM attribute
section should always be present on armhf. And there are cases were
both soft and hard float flags are set at the same time(!).
Mask all flags on ARM, so that we get back to the previous behavior
with objdump. We can try to revisit this for a better matching during
the dpkg 1.19.x cycle.
Closes: #853793
|
|
restrictions"
This reverts commit 9899bdcf9bde76d969b124abf0a898fcbb202c70.
This change is contentious and should have been discussed more widely.
Given that this has been live only for a couple of days, the impact
should be minimal, but still something to take into account once and
if this gets reintroduced, in the same or different form and shape.
Closes: #852820
|
|
Some ELF binaries contain alternative or old ELF machine types, which
should match with their canonical forms. Map those before encoding the
ABI.
We ignore some mappings for things that should certainly never appear
in current systems. Of note are EM_PPC_OLD (17) that conflicts with
EM_VPP550 (17), and EM_PJ_OLD (99) that conflicts with EM_SNP1K (99).
Warned-by: rebootstrap
|
|
On Linux systems the flock() locks get converted to file-range locks on
NFS mounts, which makes it safe.
The correct solution here will be to completely get rid of the need to
do any locking, which should also make parallel builds faster.
Addresses: #677865 (on Linux)
|
|
This way when unpacking for output, the result gives meaningful results.
|
|
These do not define the ABI, and seem to be set depending on the ISA
used. Mask them for now, and postpone possibly making more fine-grained
matching in the future.
|
|
This has been refactored from Dpkg::Vendor::Debian, to have a generic
option parser.
|
|
The previous ELF ABI mismatch detector was very naïve, as the string
returned by «objdump -a» is a very simplistic representation of the
ELF ABI used.
Switch to our own ELF header parser, so that we can distinguish based
on the fields that define the object ABI.
This is still not enough, and we will have collisions with things such
as linux-i386 and hurd-i386, but most of the previously colliding
objects are now filtered.
This also makes us independent of objdump not supporting any unknown
ELF object ABI.
Closes: #849913
|
|
Switch scripts to use the new function instead of using ad-hoc
implementations.
|
|
This information is currently only available in the Restrictions field in
the debian/tests/control file.
When dispatching tests, it might be inconvenient to have to download and
unpack the source package beforehand. Let's expose this via the .dsc in
a similar way we do for the Testsuite-Triggers field.
Closes: #847926
Based-on-patch-by: Iain Lane <laney@debian.org>
|
|
If we do not have a date from the changelog set it to the current time.
Closes: #849081
|
|
When there's at least one colon or one dash, we should expect epoch
and revision numbers.
|
|
This field is used to distinguish packages that have been automatically
injected by some build tool, and are not present in the debian/control
file.
|
|
And fix the documentation while at it, which was incorrect code.
|
|
Warned-by: codespell, spellintian
|
|
Instead of entering into an infinite loop.
Closes: #851441
|
|
|
|
This makes using the module a bit easier.
|
|
The function was splitting tuples at most into three elements, which
made it unable to handle quadruplets.
Extend the unit tests to cover wildcard quadruplets.
Missed in commit 9d7ba99cc3ff84fc553ed39da9d2e4f4008d35b6.
Reported-by: Julian Andres Klode <jak@debian.org>
|