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

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

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

This kind of file includes translated entries, which causes spelling
check false positives, and makes the author tests and CI systems
checking those fail.

The non-breaking space before the colon seems to be confusing po4a which
ends up using it for all subsequent spaces within the I<> markup. Move
the non-breaking space outside the I<> markup to avoid the issue.

Warned-by: lintian

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

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

[guillem@debian.org:
 - Remove trailing newline from translation.
 - Fix end-of-line withing string syntax errors.
 - Add missing closing angle for POD markup. ]

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

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

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

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

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

[guillem@debian.org:
 - Remove trailing newline from translation.
 - Fix translations with mismatched format specifiers. ]

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

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

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

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

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

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

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

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

There was a missing 1 in the version.

Fixes: commit b21501dd
Closes: #1030288

Some of these are valid, but we'll fix them in the soon to open 1.22.x
series. This should make the CI systems based on Debian unstable
checking author mode, get back to normal.

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

The source ChangeLog.old file might have different permissions depending
on the umask during the source package unpack. Copy the file without
any flags, and then explicitly set known permissions on the result file.

This should fix the build on reproducible variants.

Fixes: commit 2c2f7066

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.

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

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

Update to 1184t.