| Age | Commit message (Collapse) | Author |
|---|
|
We start your quest by using the version of a package applying to a
specific pin, but that version could very well be below the current
version, which causes APT to suggest a downgrade even if it is
advertised that it never does this below 1000.
Its of course questionable what use a specific pin on a package has
which has a newer version already installed, but reacting with the
suggestion of a downgrade is really not appropriated (even if its kinda
likely that this is actually the intend the user has – it could just as
well be an outdated pin) and as pinning is complicated enough we should
atleast do what is described in the manpage.
So we look out for the specific pin and if we haven't seen it at the
moment we see the installed version, we ignore the specific pin.
Closes: 543966
|
|
|
|
|
|
|
|
The rational from the buglog:
> The problem here is that the Priority field in one of the Packages files
> is incorrect due to a mishap with reprepro configuration, […] the
> amd64 version is Priority: standard but the arm64 version is Priority:
> optional (and has a stray "optional: interpreters" field).
> […]
> However, Priority is a rather weak property of a package because it's
> typically applied via overrides, and it's easy for maintainers of
> third-party repositories to misconfigure them so that overrides aren't
> applied correctly. It shouldn't be ranked ahead of choosing packages
> from the native architecture. In this case, I have no user-mode
> emulation for arm64 set up, so choosing m4:arm64 simply won't work.
This effectly makes the priority the least interesting data point in
chosing a provider, which is in line with the other checks we have
already order above priority in the past and also has a certain appeal by
the soft irony it provides.
Closes: #718482
|
|
nl_langinfo is used to acquire the YESEXPR of the language used,
but it will return the one from LC_MESSAGES, which might be different
from the language chosen for display of the question (based on LANGUAGE)
so this commit removes the [Y/n] help text from the questions itself and
moves it to the prompt creation in which the usage of LC_MESSAGES is
forced for it, so that the helptext shown actually represents the
characters accepted as input for the question.
There is still room for problems of course starting with an untranslated
"[Y/n]" but a translated YESEXPR or the problem that the question is
asked in a completely different language which might have a conflicting
definition of [Y/n] input or the user simple ignores the helptext and
assumes that an answer matching the question language is accepted, but
the mayority of users will never have this problem to begin with, so we
should be fine (or at least a bit finer than before).
Closes nothing really, but should at least help a bit with bugs like
deb:194614, deb:471102, lp:1205578, and countless others.
|
|
|
|
Git-Dch: Ignore
|
|
|
|
Lintian complains about these links in the source package as they leave
the source directory and as they are autogenerated there isn't that much
sense in shipping them, we can just recreate them before calling
configure.
|
|
|
|
|
|
|
|
It works for a while now in manual tests, now lets see how it will
perform if enabled for all by default automatically.
|
|
|
|
|
|
And while at it ensure that this can't happen again by letting the build
fail in case a po file is available but the language isn't mentioned in
the LINGUAS file (not even as a disabled language).
|
|
|
|
The list shows that it is ignored as some translations which are shipped
are not included here, so remove this source of possible confusion.
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
|
|
Git-Dch: Ignore
|
|
Using the static FileFd::Write method gives us error messages for free
so we use it here to avoid failing silently (with a fail silent error).
Git-Dch: Ignore
|
|
|
|
|
|
Commit 2b9c9b7f28b18f6ae3e422020e8934872b06c9f3 not only removes
keep-alive, but also changes the request URI send to proxies which are
required to be absolute URIs rather than the usual absolute paths.
Closes: 717891
|
|
|
|
|
|
On CD-ROMs Translation-* files are only in compressed form included in
the Release file. This used to work while we had no record of
Translation-* files in the Release file at all as APT would have just
guessed the (compressed) filename and accepted it (unchecked), but now
that it checks for the presents of entries and if it finds records it
expects the uncompressed to be verifiable.
This commit relaxes this requirement again to fix the regression.
We are still secure "enough" as we can validate the compressed file we have
downloaded, so we don't loose anything by not requiring a hashsum for
the uncompressed files to double-check them.
Closes: 717665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
StackPost
|
|
|
|
* skip all Description fields in apt-cache, not just first (Closes: 717254)
* fix 'apt-cache search' crash with missing description (Closes: 647590)
|
|
|
|
|
|
* debian/apt.postinst:
- run /etc/kernel/postinst.d/apt-auto-removal once on upgrade
to ensure that the correct auto-removal list is generated
(closes: #717615)
|
|
* debian/apt.auto-removal.sh:
- do not include debug symbol packages for the kernel in the
blacklist (closes: #717616)
|
|
|
|
Beside the earlier fixed 'apt-cache show', 'showpkg' and 'search' deal
with descriptions. 'showpkg' was fixed by fixing the cache generation
for 'show', but 'search' still segfaulted.
On the upside, it doesn't segfault any longer, on the downside, if a
package has no description at all (aka: not in the Packages file and not
in a Translation-* file) the package can't be found with 'search', even
if we search only by name. That is a shortcoming in the code, but fixing
it means rewriting it completely for dubious gain at best.
So this commit just skips packages without a description and is done.
Closes: 647590
|
|
Given a Packages file like:
[…]
Description: foo bar baz
moo moo moo
Multi-Arch: foreign
Description-md5: 97e204a9f4ad8c681dbd54ec7c505251
[…]
We have to display the Multi-Arch flag field as well as the fields
after the Description-md5, but not this field itself, as we already
have one printed alongside the Description we display.
Closes: 717254
|
