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

[guillem@debian.org:
 - Fix missing format specifier conversion characters. ]

Signed-off-by: Guillem Jover <guillem@debian.org>

Signed-off-by: Guillem Jover <guillem@debian.org>

This reverts commit 321e479b.

This arch which was supposedly already defined, with an agreed ABI,
GNU triplet and dpkg multiarch paths, seems to want to redefine all
these. There is no clear rationale for why this is happening at this
point in time, while patches for at least gcc have been submitted
with no coordination (which ended up being applied).

The handling of this is less than ideal. Until the whole situation
gets clarified, the safest way is to revert the support. It can be
reintroduced once things clear out.

Ref: #1028654

[guillem@debian.org: Fix typos in comments. ]

Ref: https://bugs.launchpad.net/bugs/2002582


Signed-off-by: Guillem Jover <guillem@debian.org>

The recently added lto handling for Ubuntu, did not take into account
that the DEB_BUILD_OPTIONS and DEB_BUILD_MAINT_OPTIONS environment
variables are parsed and their options applied just after setting the
defaults, and before applying any arch-specific mask.

We add a new init_build_features() internal method, which sits between
these two actions, so that the Ubuntu vendor module can modify the
defaults before any user or maintainer override are applied.

Fixes: commit df7627ac
Fixes: https://bugs.launchpad.net/bugs/2002582

When verifying a signature, we were using the internal dearmor() method,
as that makes it possible to not have gpg around when we are using gpgv.

The problem is that the internal dearmor() method does not handle
concatenated ASCII Armor blocks, and might then fail to find the
certificates. When using gpgv this is only a partial regression as
we were previously not verifying at all on minimal systems where gpg
was not available. But when it is available, now that has regressed.

In the future we might require no concatenated ASCII Armor blocks,
but for now let's mitigate this regression.

Fixes: commit a11d7340
Reported-by: Sven Joachim <svenjoac@gmx.de> (on IRC)

The gpgv command expects a trustedkeys.gpg keyring, and if there is none
it will try the trustedkeys.kbx one, but then will emit an error such as:

  gpgv: unknown type of key resource 'trustedkeys.kbx'
  gpgv: keyblock resource '<GPGHOME>/trustedkeys.kbx': General error

This error will only show if the gpgv invocation failed for other
reasons, but it is still an unnecessary distraction. Avoid that error,
by touching the trustedkeys.gpg keyring.

The current GnuPG defaults with --openpgp cater for heavy backwards
compatibility at the cost of being insecure but potentially being
compatible with very old programs.

We care more about secure defaults than backwards compatibility with
ancient programs, so we pass our preferences to gpg when signing. This
should also cover the case for users that have created old keys with
insecure key preferences which might end up producing insecure
signatures.

Fixes: commit b83114da
Closes: #1028961

The regex was not correctly matching at the beginning of the line with
leading spaces, which could be left by a previous replacement from
the same s/// operator. Instead switch to split the flag value and
filter based on a hash, which means we do not need to care about such
space issues anymore.

This change should not change the semantics for space separated options
in the flags, as the code was already splitting the passed values on
spaces, and then remapping on the entire flag value.

Improve strip unit tests to cover all these cases.

Closes: #1028044

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.

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.

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.

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.