It does not make much sense to ship the upstream «git log» changelog
which contains lots of fluff and metadata. At the same time the recent
debhelper trimming is not ideal as there's no easy way to fetch old
entries anymore. So stop shipping the upstream changelog in favor of
not trimming the debian/changelog one, which acts as a proper user
readable changelog.

Closes: #1027716

When bootstrapping a cross-compiler, it might not have some of the
required parts available, such as a libc. Catch the error, emit it as a
warning and return undef, like with the other conditions where we skip
the test. Because in the end this is just a tainting flag, and it is not
worth it failing the entire build due to that.

Closes: #1027966

Changelog: internal

The $file argument should be part of the error() arguments not the g_()
arguments.

The new version fixes the remaining issue that allows the code to use it
as a backend. Add it as a preferred implementation if available.

The handling for deb 0.x formats that relocates files around once
extracted was using a buffer with a hardcoded size, not taking into
account the length of the directory which would overflow it.

Switch to use a dynamically allocated buffer to handle any destination
directory length.

Reported-by: Georgy Yakovlev <gyakovlev@gentoo.org>

When xz does not have enough memory given the requested threads, it
might end up adjusting the memory usage and number of threads, while
emitting a warning, and then exiting with non-zero. Both of which we
do not want from the library.

If xz cannot meet the memory usage limit on multi-threaded mode, then
it can end up falling back to single-threaded mode, which would then
generate different output, making it non-reproducible. This has the
drawback that it can then error out.

When xz does not have enough memory given the requested threads, it
might end up adjusting the memory usage and number of threads, while
emitting a warning, and then exiting with non-zero. Both of which we
do not want from the library.

These are causing test suite breakage on other projects, which will
block migration for dpkg. Silence them for now.

We are distinguishing the feature being undef to cover the builtin case,
and use_feature() coerces it to a bool values which makes it lose the
undef and causes the flags to include PIE flags.

Reported-by: Helmut Grohne <helmut@subdivi.de>

This is relevant with builtin features where use_feature() will coerce
the returned value into true or false, and where undef is a valid ternary
state we use to track the default the compiler might have.

Update to 1178t.

The unit tests did not make it clear that we are testing how the system
patch(1) works, and not local code. This has caused bugs reported in the
past on systems with unsafe patch(1) implementations.

The new module gets rid of the deprecated functions and follows the same
naming convention as used by the other Dpkg::BuildSomething modules.

Keep the old module for backwards compatibility until users have
switched over.

This makes this module use the current prevalent convention for the
other Dpkg::BuildSomething modules.

This makes this module use the current prevalent convention for the
other Dpkg::BuildSomething modules.

We have already normalize the arch name, so we can compare against the
well known constant string we want, and there is no need to use the
comparison function which is intended to compare arch names with
different tuple formats.

Split setting the build features to use, from acting on them to set the
build flags based on these.

This makes it possible to override these feature defaults by vendors
inheriting from a parent, so that they do not have to mangle the
generated build flags, or need to modify the parent vendor module to be
able to change those defaults.

This will make it possible track the state of these option values
across initialization and usage, and to preset for example the
optimization level to specific values, and be overridden by other
vendors.

These denote build flags that might be handled as builtin defaults by
the compiler (even if only on a subset of architectures). The current
example of such case would be PIE on gcc in Debian.

This will be used to track the values for some options, so that they can
be overridden (such as the optimization level). They are private for now
as it's not clear whether this interface is general enough for other
uses.

This abstracts the feature state with this getter so that we can query
it from code that needs to act on the features to set actual build
flags.

In some cases we might want to set features, then apply the vendor
defaults.

Closes: #1027312, #1027313
Signed-off-by: Guillem Jover <guillem@debian.org>