Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
Closes: #921942, #921943
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Closes: #920972
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
[guillem@debian.org:
- Fix markup errors.
- Mark broken translation as fuzzy. ]
Closes: #920905
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
There were several error messages involving the dpkg database, that were
ambiguous by referring to it as "dpkg status area", instead of printing
the affected pathname. The historical reason for not being more explicit
has been to keep the user a bit under the dark, because this has been an
internal database storage, and only those in the known would go there to
edit it by hand and similar.
This is a bit pointless though, because the Internet is full of
references to those directories, and other error messages just print
them anyway.
In addition, for users that want to diagnose what is the problem this is
not helpful, and the directory might have been changed at build or run
time with one of the options.
Closes: #883700
|
|
Versions before 1.13.10 did not properly clear the Origin and Bugs
fields, so there might still be entries with these fields that are
not getting garbage collected properly.
Make sure to blank these package entries so that they get forgotten
on the next database dump.
Closes: #922410
|
|
|
|
Closes: #922212
Reported-by: Y <sevener@cock.li>
|
|
We need to do that, as we might try to use args again when constructing
the error message into the emergency buffer, which would get garbage
instead.
|
|
We should compare only the memory being used, and file_slurp() does not
guarantee NUL-terminating the varbuf.
Closes: #920974
Diagnosed-by: Frank Schaefer <kelledin@gmail.com>
|
|
We use a number that is close to the amount of packages currently present
in a Debian suite, so that installed and available packages do not add
tons of collisions.
The memory usage is «BINS * sizeof(void *)», so it will be 256 KiB on
32-bit systems and 512 KiB on 64-bit systems.
Update the code comment to reflect the above.
|
|
Now that we do not use a nickname mapping anymore, the field struct
contains the actual field name matched, so we can report it correctly
instead of listing all possible altrnatives, and then missing some.
|
|
The current code first does a lookup to see if the fieldname is in the
nicknames table, if found fixes up the fieldname to the new alias, and
then always does a lookup for the normalized name in fieldinfos table.
This penalizes the common case (i.e. non-obsolete fieldnames)
substantially. Also moving the nicknames into the fieldinfos table will
allow to print correct fieldnames on error as those are not mangled any
more, and to provide new wrapper parse functions that print warnings for
the obsolete fieldnames.
|
|
Move the error reporting outside the involved functions so that we do
not need to call gettext if there is no error, which has a significant
performance cost.
|
|
Move all field names to be format arguments so that these do not get
accidentally translated. Use fip->name instead of hardcoding the field
name. Always refer to the field names as "'%s' field". Use the proper
field names instead of descriptions. And capitalize their names.
|
|
Although package states are very unlikely to change their names, it's
just better to use a single canonical place to store their values.
This also makes sure no translator will accidentally translate these
names.
|
|
|
|
|
|
These are intended to be used to check performance improvements in the
libdpkg implementation.
|
|
|
|
Closes: #921031
Fixes: commit d1d35a56e401181b6d15baf474a7db21d3372a65
Diagnosed-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
These will detect problematic files under /usr/local which can taint
the current build.
|
|
This will detect whether the system we are building on contains the
problematic /usr merged via symlinks deployment method.
Suggested-by: Alexander E. Patrakov <patrakov@gmail.com>
|
|
This field will contain a list of tainting reason tags, which can denote
that the current build has potentially been broken.
Suggested-by: Alexander E. Patrakov <patrakov@gmail.com>
|
|
We do not want to move the entries beneath the first depth of the
pathname, as when we try to move those, we will have already moved
their parent.
Closes: #922799
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Print where these are to be used.
Closes: #922039
|
|
Closes: #922407
|
|
Closes: #920880
|
|
This new option works in both dpkg and dpkg-statoverride. And dpkg will
pass it to its children, which means dpkg-statoverride called from a
maintainer script will automatically pick it up.
Ref: #811037
|
|
Deprecate --force option which will be considered an alias for
--force-all for now.
|
|
|
|
This will make it possible for third-party tools, and also for other
dpkg tools to have access to the force options specified for dpkg.
Closes: #666147
|
|
|
|
|
|
This makes it easier to generalize to be used by other modules with
different force options, and to operate on the force options.
|
|
This will make it possible to reason more easily about what is
getting enabled.
|
|
We will be using the same logic for other commands.
|
|
This unifies all force related code in a single file, and will make it
possible to use it in other programs.
|
|
We do not really need to normalize the return code, which was confusing
the cppcheck for which we required a supression.
|
|
The wrapper function should be generic, so leaking this SELinux specific
detail there is just wrong.
|
|
Describe what to expect from these new checks.
Closes: #921557
|
|
This is generally insecure, not just when using the --pidfile match
option alone. The «/dev/null» excemption is still in place.
|
|
We should not try to use errno, when the error has not been produced due
to a system error, as then errno might contain bogus or unrelated
information. Be explicit in the error handling by calling fatale() for
errno related errors, and fatal() for the ones that are disconnected
from it.
|
|
Initialize errno to 0 before returning on any error condition, not just
before strtol(3), so that when we call fatal() we get a meaningful value
in errno.
|
|
Systems deployed with that method bypass the package manager and its
understanding of the filesystem, create aliasing problems, and break
all kinds of expectations for any program that uses pathnames as key
into their database, such as u-a.
|
|
These fields have been there mostly to showcase their usage, which
should instead be dynamically added at build-time, and as a reminder
that this should be done.
But there is already a bug filed as a reminder (see #511160), they
are also now documented in the deb-src-control(5) man page, they are
actually wrong in many cases when present on a downstream, and they
generate nagging lintian warnings to boot.
|
|
|
|
All such bugs have been closed, there is no reason to document it
anymore.
|