Note the remark ", including virtual package names." in the manpage.
bindgen-0.65 has a "Provides: bindgen" (with a version), so it has
(also) the virtual package name "bindgen" and that perfectly matches
your regex. So, working as intended & documented and hence I am changing
the status to
As the requirement for reproducing is "being offline" it could be that
this remove command wants to download packages, which fails.
Yes, remove can install packages – specifically the problem resolver can
try to fix a broken dependency by installing another provider/or-group
member. Controlled by
https://salsa.debian.org/apt-
team/apt/-/commit/633f6d67a28b375cf1f225f14d3c926e618d46af
** Changed in: apt (Ubuntu)
Status: New => Fix Committed
** Changed in: apt (Ubuntu)
Assignee: (unassigned) => David Kalnischkies (donkult)
--
You received this bug notification becau
Not sure who all the upstream(s) involved might be, but from my personal
PoV at least you can add all the options you like… the topic gets harder
if we talk defaults & changing (e.g.) the lists completely (like that
tabular verbose-explosion thingy from apk or whatever it was). At some
point it
jftr: I removed this if in git commit
938889b20268ec92be1bff67750f7adf03f52c1b, which was shipped with 2.1.12
– that might explain why it isn't effecting releases with later versions
and why it was missed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
apt 1.2~exp1 came with the follow NEWS entry:
[ Automatic removal of debs after install ]
After packages are successfully installed by apt(8),
the corresponding .deb package files will be
removed from the /var/cache/apt/archives cache directory.
This can be changed by setting the apt
fwiw it is "invalid" here as apt has nothing to do with it, as it did
what it is supposed to do, upgrade a package: It has no business in the
contents, similar to a parcel deliverer. It is probably more productive
you figure out what exactly is not working in foo.deb vs. foo.snap and
report this
Can you provide a complete (preferably real) example of what output you
would expect?
Honestly, I don't see this working as in the general case the reason is
not simple – its at least my experience from staring at debug output for
hours to figure such things out in the development branches of a
+
Yes, "1" is a valid expression to say "yes", as is "+" – at least in my
(german) locale, and perhaps in yours, too. You can check with `locale
yesexpr` – the output is a regex expression. For me it prints
"^[+1jJyY]" (without the quotes), so anything starting (^) with either
of the characters
apt contacts the squid proxy (which is on your local machine) hence the ipv6
from your machine. The "Forbidden" is the reply from the proxy for the request.
squid-deb-proxy hardcodes an allowlist for mirrors and sources to contact and
ips that can contact the proxy. I would presume that either
"minimal potential for causing regressions" is a big claim given I had
to fix regressions in later commits like
149b23c2b9697bc262c0af1934c7a3f6114d903f and
2b0369a5d1673d9e40f2af4db7677b040a26ee58. There might be more, that is
just what I remember directly. It is certainly not the most
> Ign:3 https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4
InRelease
triggers the fallback to download the files Release & Release.gpg, but
as the Release file (5) is a Hit apt skips the attempt to acquire
Release.gpg (8) and continues on with the reverify step which doesn't
emit a
This is documented behavior due to in which order the various
configuration places are evaluated: man apt.conf has the details at the
top.
In other words, you have to set Dir::Ignore-Files-Silently in a config
file specified with the APT_CONFIG environment variable for it to take
effect for
A package which isn't even installed can not be the cause of a problem…
and you are not using a "tor+" source (which is enabled by that
package).
Looks for me like you would need to "apt update" as the data you have
locally on your system is too old and references no longer existing
files … a few
(Probably "a bit" late, but here we go)
You will have to use the slightly unwieldy "tor+mirror+http", so your example
line would be:
deb tor+mirror+http://mirrors.ubuntu.com/mirrors.txt bionic main restricted
universe multiverse
btw: apt-transport-tor is by default using a new circuit per host
> I've attached an example log, where the error pops up for multiple
packages, and they all appear to be compared to one size (86464 bytes).
just for the record: This is a misunderstanding. If apt does pipelining
it searches in the requests it made for the file this response is for.
If no request
No such version exists as it would be a bug. An Auto-Installed field !=
1 is still possible if the section includes another field the current
apt version doesn't know about and hence can't reason about. apt itself
does not currently generate such stanzas, but a future version might. Or
other
Mechanical train signals used to signal if the next section is clear vs.
blocked by another train used to have the arm raised if it was clear and
down if not. That was so that if the mechanic would fail in some way the
arm would fall down and rest in the "blocked" state rather than in a
"clear"
The message can not be shown only if the package is going to ask
questions as debconf would need to extract the questions beforehand (and
find none) for that to work – but it can't do that without apt-utils. :)
Not sure about the stderr vs. stdout, I guess the rational is that its
more important
apt-utils is not required & this is not a warning (in the sense of an
unimportant error), but an information why debconf isn't asking
questions to configure all packages upfront at the start of the run, but
will ask questions (if any) while the packages are actually installed as
needed potentially
APT can't know how "critical" the other packages are compared to the
packages which failed to download (which really shouldn't happen to
begin with). I mean, if you don't (normally) use an SSH server, but
hard-depend on a sublime text-editor experience…
Have you tried the --fix-missing option the
Without looking at the deb file, this is likely a regression of 2.0
which was fixed in the recently released 2.0.1 in Debian. Pretty sure
that will eventually flow into Ubuntu as well. See the commit in
question for details if you are interested: https://salsa.debian.org
Nowadays our HTTPS implementation works a few layers deeper than what I
talked about three years ago, so we could similar to our auth.conf work
now open all certificate (others also?) files as root before dropping
rights. As that would be best implemented by someone who actually uses
these
The cake is a lie.
--print-uris does *NOT* print the URIs an "apt update" is bound to use.
It can't because it doesn't download any file and it would need to
download at least the (current) InRelease file to answer that. So what
it does is print the URIs it would download IF everything would
"apt install foo/bar" will try to satisfy dependencies of foo from
release bar if the current candidates do not satisfy the requirements.
That is more a feature for going to a PPA (or backports) than leaving it
and has some issues, but it exists (e.g. your downgrade has probably all
dependencies
No idea about Ubuntu specifically, but it should be in upstream since apt
1.8.0~alpha3 release on Tue, 18 Dec 2018 15:02:11 +0100.
See also: https://salsa.debian.org/apt-team/apt/merge_requests/38
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Note that the file we have in lists/ is not what we downloaded as we
have downloaded a highly compressed version of the content (e.g. xz),
but store it either uncompressed (for which we have a checksum) or
lightly compressed (e.g. lz4 for which we have no checksum and can not
as different versions
They both sound awfully "generic" (pun intended), but I can't really
come up with an example for a bad match, so lets just try it I guess.
That said, isn't the "deeper" problem that these metapackages can be
removed easily even through they are important to keep the kernel up-to-
date (and hence
apt does what it is told – appstream configures apt to download only the
files for the native architecture, so there is no sensible action to be
taken by apt and hence this task invalid.
If "$(NATIVE_ARCHITECTURE)" in the apt.conf file shipped by appstream is
changed to "$(ARCHITECTURE)" apt will
I am sorry, but with the provided details this report isn't actionable.
You have run apt on the terminal so including the ENTIRE output would
have been a good idea, can't do much with the hashsum mismatches –
expect predicting that this is indeed some sort of problem on your end
of the internet
Thanks for your well written bugreport and a very happy Christmas to
you, too, sir. Please proceed to the checkout counter and accept a full
refund and our sincere apologizes.
Unfortunately, I am neither a ubuntu developer, nor do I drink kool-aid
apart from the seasonal appropriate hot cocoa,
While that sounds reasonable at first in simple situations, if I follow
that argument, I can find no reason why we are doing complex metapackage
handling, keeping many providers and a lot of other things, so we should
get right of all those, too, should we?
In reality we have to deal with many
Regarding the bug itself: I wouldn't exactly call it a regression, but
it wasn't a super-intended change either. If I see it right I "broke" it
in 2015 by fixing a compiler warning, which indicated that a check which
should have been since ever never applied. So, that it worked before was
just as
Is it really /any/ which I can't confirm at the moment as holding e.g.
apt & dpkg works just fine…
The underlying question is: Are the packages you are trying to hold
installed? If not, dpkg will accept the hold at first and record it (so
apt will report it on showhold again), but as soon as the
"apt-cache" (the commandline binary packaged in apt) never reads keys
because it has no business with keys… from the "reproducer" I guess you
are trying to report a problem with the python bindings? You have also
omitted any other useful information like which version you are using…
If you want it
> The allow-unauthenticated did not downgrade all errors relating to signing to
> warnings.
> If it had, the apt-get update would have included the new packages and it
> would find
> the packages during an install command, but may not allow installation
> without explicit
> confirmation. The
Have you read apt-secure(8) manpage as the explanatory notice (N:)
attached to the *warning* message says?
It explains why you see the *warnings*, that it is the propose of the
switch to downgrade the *errors* to a *warning* (so that worked as
intended) and it mentions how to configure that in
The recommended way is "chown _apt:root FILE && chmod 400 FILE" at the moment.
Ideally we wouldn't need the chown (or have it root:root), but that isn't very
realistic to be implementable without rolling our own TLS stack in the process
at the moment, so we have to make due with that for now.
That used to be a shortcoming in apt-file, not a problem of apt-
transport-tor (or any other transport as apt-file was using its own
implementation). An apt-file release changing to utilizing apt for
downloads (which in turn would us a-t-t then) was released as version
3.0, released on 28 Feb 2016
The solution is to tell the owners of the respective repositories to fix
their Release file(s). The Date (and Valid-Until) field MUST be in UTC
(aka GMT, Z, +). Earlier apt versions accepted other timezones
silently, but parsed it as UTC anyhow which could cause all kinds of
fun. Now a
That sounds like what this commit describes:
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=84eec207be35b8c117c430296d4c212b079c00c1
Hence tagged as such as its available in the 1.4 series. Not sure if this
should be backported to 1.2 or not.
** Changed in: apt (Ubuntu)
Status:
So, how is this option named in firefox and how do you set it? ………
exactly. You don't have it as an option as servername != hostname is
something you only need for experiments which is the main purpose of
s_client. Firefox doesn't need that option as it is using SNI (in
reality it uses a library
That would be horrible… If you contact a server foo.example.org it
should respond with the cert for it, not with a cert for
bar.example.com. That is what SNI is all about after all (as your client
connects to an IP and SNI is telling the server which hostname it wanted
to connect to, so the server
And which are the "broken error messages" then, I don't see any… ?
(the messages are on the longer side, which makes it look "funny" if
wrapped like it is in launchpad, but I don't see what is broken about
it…)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Without an example nobody will ever know what you might mean.
You might be meaning accidentally debug output – I that happened
sometime ago, could be 1.1 and should be fixed in newer versions. Or
perhaps you mean that you enabled debug output and expect it to be all
orderly – not going to happen:
That isn't directly the fault of apt-key. It uses gpg which in its >=
2.0 versions has split its operations into a multitude of daemons for
security reasons. The daemons should be terminating themselves a few
seconds after the directory they operate in disappears. That is at least
the case for
1. Removing the _apt user is really not needed nor a good idea. Its enough to
have this in a config file:
APT::Sandbox::User "root"; // remove file again after testing!
2. Symlinking /usr/bin/gpgv to /bin/true will never work as verifying
signatures is more involved then just checking the exit
APT is using dpkg's --recursive option with a temporary directory since
recently if it has to touch >5 packages to avoid producing too long
commandlines for the kernel (yes, that is a thing… although unlikely it
does happen in big upgrades). Seems like this interface in dpkg does
support only
https://anonscm.debian.org/git/apt/apt.git/commit/?id=0919f1df552ddf022ce4508cbf40e04eae5ef896
** Changed in: apt (Ubuntu)
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
What type of proxy is that? Given you were using it before I presume its
an HTTP proxy. Does the URI you specify has "http://; in front? Is that
perhaps a public proxy? We have a test covering HTTP proxies and I have
just run an upgrade myself with a SOCKS proxy so that more likely
something
btw: "apt-cache pkgnames" should have better/quicker result than
searching.
Don't know what that goldfish is nor am I particular interested in
cloud, but I guess they could be added if there is need/interest. Its
not like there is any real cost attached to it and false positives are
pretty
That is a regression of sorts caused by a sleight of hand used to avoid
another bug. The commit in question would be
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=446551c8ffd2c9cb9dcd707c94590e73009f7dd9
although the involved code changed in the mean time the general idea
remains the
So apt would autoremove them if it could, like it already did with the
linux-image-extra packages – so I guess as before: kernel module package
depending on the images perhaps via indirection (provides), probably on
of the "NonfreeKernelModules: zfs zunicode zcommon znvpair zavl" (or
another, I am
Are you sure you haven't marked these kernels as manually installed
somehow? Perhaps there is also something depending on them still like
some installed out-of-tree kernel modules.
The output of the following three commands can be helpful to figure out
if apt would consider autoremoving them if
well, reassigning 3 years old bugs isn't really helping anyone…
especially if there are no details. Even worse if you pull a "I had a
complete unrelated issue I haven't reported a couple days ago, so that
years old issue here must be a bug in apt". After all, in your
reasoning, if it would be a
(for the record: I am not defending the name->glob->regex fallback/guess
as a wonderful interface… it isn't… I am defending it on the grounds
that it is an interface for nearly two decades now, so changing it for
apt-get would be a horrible mess breaking usercases left and right and
apt-users tend
(srly, bugreports referring to pastebin?)
Well, apts output says what is going on: As a package with that name
doesn't exist and the string looks like a regex (thanks to the '.') it
will search for packages matching the regex and it does find one. That
is perfectly fine and established behavior
This is intended. The intro text of the OPTIONS section mentions that
for boolean options every option has a --no- option negating the effect
(which happens to be right above --no-install-recommends). As --install-
recommends is the default, it feels more useful to document the negation
as its the
@dino99: Are you sure you haven't (partially) upgraded just the 'apt'
package? In that case this would be expected as the "fix" is in libapt-
pkg5.0 build by the apt source package – the ubuntu repository was most-
recently updated in a 2-digit hour, while both PPAs were last updated in
This is caused by the usage of relatively new c++11 features, namely
std::get_time, as described in this libstdc++6 upstream bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
The Release for yakkety-proposed currently reads: "Date: Fri, 17 Jun
2016 6:30:29 UTC". Note the "6" as hour.
This is an explicit feature – apt will mark the packages as manual if
the metapackage is removed as a consequence of another package (e.g. you
remove the browser the metapackage depends on, the office-suite will be
marked as manual to prevent it to be removed automatically just because
you don't
Could be:
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=84ac6edfabe1c92d67e8d441e04216ad33c89165
Which is a problem with the redirection handling, which would also explain why
its not happening for everyone as these download servers might be doing (no)
redirections based on the region
I presume that works (I would be using nativearch="$(dpkg --print-
architecture)" through – and poking directly into info/ is discouraged.
Checking exitcode of commands like 'dpkg-query -s "$1"' might be
better), but note that with a "foo:all" you aren't talking about a
package as packages can't
The names aren't ambiguous – if apt prints no architecture it is ALWAYS
the native architecture. This is this way for compatibility reasons as
apt hadn't previously printed any architecture – because they were all
native – so old tools, scripts, processes, … sticking to the common case
of
Attached is a trivial patch [in retrospective] I just committed upstream
which should fix this issue – I have only verified it by logchecking
with the two status files from the buglog (again: thanks!) through, I
haven't actually run it on a real system so testers welcome!
That should be easily
Thank you both for the files! A quick test suggests that both expose the
problem by unpacking but not configuring libgcrypt before touching
systemd. The actual produced order is quiet different through (and both
systems are obviously far away from a minbase chroot – which happily
does the right
As pitti can't reproduce it with a clean system there is a good chance
an "unrelated" package from a PPA or cruft from an earlier upgrade
confuses apt (as far as I remember PPAs are disabled on upgrade in
Ubuntu, so it can't be new "unrelated" packages at least). These bugs
are everyone’s favorite
The apt(8) manpage doesn't list any options (okay, it mentions a selected few,
but it has no long list like the other manpages).
It lists only subcommands like 'install' or 'show' and refers the reader to the
manpage of apt-get or apt-cache or whatever for details because repeating the
very
well, apt 1.2.10 is in xenial and in that version my example works, so I
fear you will need to provide a few more details like the entire output
and commandline of the command you try.
(it works also in earlier versions and I am relatively sure it works
since the dawn of the apt-binary as its
All settings involving pinning are of the first-come-first-serve level.
Adding an exception for the default-release setting to have an effect on
all packages from this release "maybe" is just complicating a feature in
usage, documentation and code which is already very complicated – and
what makes
Please mention the exact command you are trying as --yes is implemented
in apt… e.g. "apt install sauerbraten --yes".
** Changed in: apt (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This is a feature, so you can pin a release (like backports) to a low
value, but raise it easily if you need to. It is also explicitly
documented in the apt_preferences manpage, which also mentions a
"workaround": Note that this [= the target release setting] has
precedence over any general
We had the intention (#818639) but forgot it then so only zh_CN was
fixed in 1.2.8 … I commited the comma-drop now [I would like to claim
that this comma makes perfect sense in German but even there it is a bit
strange].
--
You received this bug notification because you are a member of Ubuntu
I realized that even the reporter say that in newer versions it works –
so no wonder I couldn't reproduce it. I modified our basic-auth test to
check for this issue specifically, so we aren't going to regress on
this.
The history suggests this could be fixed by
Raring is out-of-support for 2 years now (and was already unsupported at
the time of the bugreport) and the report misses all sorts of details to
be actionable.
I guess this was a "web-portal confusing apt" issue back then, which is
long fixed by now, hence opportunistically closing – if that is
That is the case since at least version 1.1~exp15, so closing as done.
Note that 'apt' isn't supposed to replace 'apt-get'. They can happily
co-exist and should be used as needed.
** Changed in: apt (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you
With a quick test I can't reproduce this with %40 as encoding, but I
will try some more later.
I would highly recommend to NOT write your authentication information in
sources.list through. Beside the parsing problem you seem to encounter,
you can't reasonably change the permission of the file
See
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9127d7aecf01f2999a2589e4b0503288518b2927
and
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=27925d82dd0cbae74d48040363fe6f6c2bae5215
among others.
Backporting of these changes itself might not be sensible, but we
"backported"
(as I was asked to have a look – only reviewing based on comments and
code in this bug through)
I guess setting the state explicit here is okay, I wonder why the
package hasn't any state through – isn't that kinda normal for a package
not touched at all? I also think it is wrong that
> Does this issue have a CVE assigned yet? Does it have a Debian
bugreport yet?
It has neither and it needs neither in my humble opinion.
The longid issue had its own bugreport in Debian (#754436) which used the
included patch (more or less) for Jessie while the 1.1 series (at that time
And I don't want epochs to exist. And I want all filesystems to support
":" in filenames. And I want a million dollars and world peace – but the
world doesn't work that way.
apt needs to save the file with an epoch to know the difference between
version 1 and version 1:1. And it has to store it
I haven't seen a crash myself, just "garbage" results (mostly apt trying
to use Translation-rowf%&$ files), but in all likelihood this is the
result of gcc5 changing to a c++11-compatible std::string implementation
– which the previous copy-on-write implementation isn't. apt was
depending on this
The patchset applied in ubuntu for the gcc5 transition wasn't complete;
I thought that it would have been synced back by now, but it seems not…
– I had added a few more changes on top of Michaels changes (including
the one Kiwinote referred to) to make it not only build, but also build
something
Without verifying if these Ubuntu versions actually have my bad patch
(deprecate the Section member from package struct - fixing the problem
of a package changing sections basically being randomly in one of these
sections) I would presume this is debbug #793360 aka: Never-Mark-Auto
doesn't apply
or the fix which is in the experimental branch for this issue for 2+ months
now… ;)
353c135e45d3b76dbecc1ba1b2bd9266601181ee
I don't think the virtual package handling CacheSetHelperAPTGet provides
is really needed (nor even wanted) for download or changelog, so we can
just use the default
Yeah, relatively recent in its very visible form, but a relatively old problem
in its cause.
Fixed in upstream git for a while, but thanks to diverting branches
(abi-breakfree unstable and abi-breaking experimental) it hasn't reached a
(non-experimental) release yet:
Thanks for the report! Unfortunately reporting it against apt is
incorrect as apt itself contains no program which automatically adds
PPAs or similar such. It just takes the sources.list content and
interprets it. So it was either you adding this PPA by hand in which
case its a user error
While this sounds like a good idea at first and many users actually do
it this way (= unchecked import of keys), apt can't do it for security
reasons and adding it (anyway) as an option would just mean we encourage
this behavior further.
The signing keys of a repository ensure that the data apt
Sorry if my previous comment came across as rude, it wasn't intended as
such. It was just meant as a quick reply (I was in a hurry) to clear up
what is the topic of this bug as incomplete reports aren't actionable.
(An incomplete bug isn't necessarily the fault of the bugreporter as
someone can
About what progress reporting are we talking here? (apt has a gazillion
steps which have independent progress reporting, so progress report is
a tat too unspecific).
If we are talking about the (Reading database in the output you
attached, this isn't even coming from apt – this is coming from
The funpart to observe here is that apt is crashing while writing an
apport report for an observed failure… so figure out what error it is
that apt wants to report here is probably bringing you guys a lot closer
to figure out what goes on… (looking at the stacktrace in the bugreport
alone as I
ähm, did you realize that Expires is the exact time of your request
(compare Date) in your example? (See also the HTTP1.1 spec which will
tell you that 'Expires' doesn't really mean what you think it does, so
that the value it has is actually 'okay').
APT is using If-Modified-Since in its
apt 1.1~exp4 fixes this issue (see also debbug #762898) in git commit
43acd01979039b248cb7f033b82e36d778d0ebec, so try that version then it
appears in Ubuntu. Using of the root cache (if available) is at least
supposed to happen in that version as well (but also in the version you
have… I will
That's a fun one… You see, back in 2013 I remodeled the commandline
parsing. The point was that an option (like -s) is only accepted if the
command (e.g. dselect-upgrade) supports this option. Previously e.g.
apt-get would accept any option even if it only has an effect for
certain commands. Very
Not a bug. Being architecture all or architecture any is a property of
the version as a package can change from any to all (and back) between
versions. The stanzas in the extended file refer to all versions
instead, which means that arch:all is the same as arch:native, so this
is correct.
Also,
Well, expect that 406 and Range have nothing to do with each other. 416
is an out-of-range request, while 406 tells us that we requested a file
in a specific encoding which the server did not have.
The 416 Range thing should be handled for a while now, we at least have a
testcase covering it so
Sounds to good to be true, right?
Well, the message is from dpkg and it is the right number as it is talking
about ALL files installed on your system via a package, so this number only
changes if you install/remove a package. Your system is pretty lightweight
though. Mine says (in german, but
* presence of '| network-manager-dbg'
network-manager-dbg depends on network-manager and this dependency is
or'ed, so what is wrong about that?
* presence of connman (connman is a conflicts of network-manager)
If we/apt talks about dependencies, we usually mean all of them as
enumerating all
Well, you should tell us your sources then, otherwise we wouldn't know
how to reproduce. Also, the output of ls -l /var/lib/apt/lists to see
the timestamps might be helpful.
Note that apt isn't setting the timestamp to your last execution of apt,
but to the last modification time the server
As I implemented this years ago I am obviously biased, but I think not
supporting # as a comment is a mistake as sources.list and preferences
support it and most other config files you come across do comments with '#'.
The autokernelremove code was an external contribution and it just shows
1 - 100 of 227 matches
Mail list logo
