This is based on the loongarch64 64-bit little-endian CPU.

Signed-off-by: xinpeng.wang <wangxinpeng@uniontech.com>

Américo Monteiro authored May 25, 2022 and Guillem Jover committed May 25, 2022

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

Frans Spiesschaert authored May 25, 2022 and Guillem Jover committed May 25, 2022

Closes: #1010031, #1010032, #1010033
Signed-off-by: Guillem Jover <guillem@debian.org>

The dist-cpan target includes OpenPGP signing the CPAN distribution,
which is problematic on a chroot. It is also not generally helpful,
as we mostly care about generating the CPAN distribution for the latest
releases.

We are de-configuring this package to allow the unpacking and
configuration of a not-yet installed package. So we need to print the
version from the available package not the installed one.

Add sub-sections to make the structure more obvious. Clarify that ${}
is not an actual substitution variable instead of an illegal one. Add
«variables» to the SYNOPSIS to clarify this describes more than the
file formats. Move the file format syntax after the variable syntax
definition. Move warning description in the new «Substitution»
sub-section.

Prompted-by: Niels Thykier <niels@thykier.net>

These commands make use of substvars and its file format.

Some packaging helpers (namely debhelper) set various substvars that
might usually be used by the packaging, but not necessarily always.

In the same way we mark some of the built-in variables as used, we add
a new operator «?=» to make it possible for other tools to mark those
other variables as optional too. Track those internally too so that they
can be printed back properly.

Proposed-by: Niels Thykier <niels@thykier.net>

For untrusted v2 and v3 source package formats that include a debian.tar
archive, when we are extracting it, we do that as an in-place extraction,
which can lead to directory traversal situations on specially crafted
orig.tar and debian.tar tarballs.

GNU tar replaces entries on the filesystem by the entries present on
the tarball, but it will follow symlinks when the symlink pathname
itself is not present as an actual directory on the tarball.

This means we can create an orig.tar where there's a symlink pointing
out of the source tree root directory, and then a debian.tar that
contains an entry within that symlink as if it was a directory, without
a directory entry for the symlink pathname itself, which will be
extracted following the symlink outside the source tree root.

This is currently noted as expected in GNU tar documentation. But even
if there was a new extraction mode avoiding this problem we'd need such
new version. Using perl's Archive::Tar would solve the problem, but
switching to such different pure perl implementation, could cause
compatibility or performance issues.

What we do is when we are requested to perform an in-place extract, we
instead still use a temporary directory, then walk that directory and
remove any matching entry in the destination directory, replicating what
GNU tar would do, but in addition avoiding the directory traversal issue
for symlinks. Which should work with any tar implementation and be safe.

Reported-by: Max Justicz <max@justi.cz>
Stable-Candidates: 1.18.x 1.19.x 1.20.x
Fixes: commit 0c0057a2 (1.14.17)
Fixes: CVE-2022-1664

These are not harmful, as they get remapped as is, but are useless in
this context.

Warned-by: shellcheck

On Ubuntu they are not installing the dpkg-fsys-usrunmess script, so
it seems clear they are not interested in this warning, silence it.

When installing a stat override, we are changing the user/group and mode
for the pathname, which in most cases might require root privileges. Add
support for the not-root force option, so that it can be used standalone
or so that it does not break when called within a maintscript on a
not-root dpkg invocation.

Based-on-patch-by: John Spencer <maillist-dpkg@barfooze.de>
Closes: #1009069

Warned-by: codespell

For setups with completely untracked kernel and modules, we need to add
also /lib/modules to the list of pathnames that need to be copied over,
otherwise its contents will not find a directory to copy to.

Closes: #1008764

On Debian some people seem so offended by a (factual) warning, that the
obvious recourse has been for them to bully and abuse. Life's too short
for that.

If you might have wanted to be able to know about the status of dpkg
on *your* system, and decide for *yourself* what to do with it, sorry,
you will need to get aware some other way.

Peter Krefting authored Mar 30, 2022 and Guillem Jover committed Mar 30, 2022

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

Peter Krefting authored Mar 30, 2022 and Guillem Jover committed Mar 30, 2022

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

The strings were using «%1s» instead of «%1$s», so the positional
arguments in the strings were not being reordered.

Closes: #1008671

Fixes: commit 48e33c40
Changelog: silent

Kernel module files are required as part of the system boot, so we need
to make sure any such files gets moved or the system might end up not
being able to boot, once the initramfs images get regenerated.

In particular, kernel module files are easily found on systems as
untracked pathnames in the filesystem, either from custom built kernels,
or as part of modules built via machinery such as DKMS.

One complication is that there appears to be some documentation
referencing /usr/lib/modules/ pathnames for at least apache, python and
ruby module locations. Which we do not want to be moving.

To limit these unknowns, and as we are dealing with untracked pathnames,
we will restrict moving subdirectories that start with a digit, which
matches Linux and kFreeBSD module locations, in addition to the
modprobe.conf filename.

Closes: #1008316

We should check that these both emit warnings and their values get
properly remapped to their modern counterparts.

The comment was still referencing the old nicknames structure.

Fixes: commit 3a017177

When converting from the old nicknames remapping handling to the normal
fieldsinfo structures, the dependency fields did not get assigned their
respective «enum deptype» value. These were defaulting to the 0 value
which happens to be dep_suggests, so only the «Recommended» field was
being mapped incorrectly.

Fixes: commit 3a017177