[Bug 2063003] Re: package manager could not make changes to the installed system
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 `pkgProblemResolver::FixByInstall` which is enabled by default. Once in a while I wonder if that should have been disabled for remove commands. Or if it was a mistake to resolve an upgrade problem 14y ago with this. Hard to tell if it does more good than bad as that highly depends on the situation. The other "obvious" possibility is that a maintainer script is trying to access the network. Perhaps its intended only on install, but not correctly guarded for the removal case. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2063003 Title: package manager could not make changes to the installed system To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2063003/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2061834] Re: apt build-dep . fails to parse build dependencies
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 because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2061834 Title: apt build-dep . fails to parse build dependencies To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2061834/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1988819] Re: When apt keeps back packages due to phased updates, it should list them separately
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 might make sense to extended apt-patterns so that current (and future) lists can be expressed in them and then add some more options to format those lists/tables/… at which point we could have different templates and so options/choices galore. I think aptitude has formatting to some extend of its lists. One of my first apt patches that was never merged was actually about reordering/coloring the lists… that failed, so I am very positive that a much bigger yak will be shaved more easily and faster many years later. ;) Precedence of the initial ask is 'can be autoremoved' btw, which is not displayed, displays a full list, an even fuller list in version mode or displays a single line with how many packages could be autoremoved depending on config. P.S.: On a multi-arch system nearly every Depends is a choice even without or-groups: given that you e.g. pick banana:amd64 or banana:i386 for an M-A:foreign banana. And the t64 transition added a quadrillion of real vs. virtual bananas at least until everyone depends on bananat64. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1988819 Title: When apt keeps back packages due to phased updates, it should list them separately To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1988819/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1974456] Re: regression: apt.postint fails if never previously configured
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1974456 Title: regression: apt.postint fails if never previously configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1974456/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1970110] Re: downloaded packages are removed just after installation
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 configuration option "Binary::apt::APT::Keep-Downloaded-Packages" to "true". E.g: # echo 'Binary::apt::APT::Keep-Downloaded-Packages "true";' \ > /etc/apt/apt.conf.d/01keep-debs Please note that the behavior of apt-get is unchanged. The downloaded debs will be kept in the cache directory after they are installed. To enable the behavior for other tools, you can set "APT::Keep-Downloaded-Packages" to false. If you have disabled this feature you can do manual maintenance with the `autoclean` and `clean` commands. More automatic maintenance can be achieved with our cronjob, see `/usr/lib/apt/apt.systemd.daily`for details, which can e.g. be configured to remove files after a few days as you seem to prefer here. As this default behavior is a deliberate choice and there are various options to change this I am closing this report as not a bug. ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1970110 Title: downloaded packages are removed just after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1970110/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1965960] Re: apt installs snap packages
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 to foo (or snap) so it can be worked on and perhaps fixed. Currently, you are angrily complaining to your old parcel deliverer that they brought you a letter informing you that the next letter will come with a different parcel deliverer. (Disclaimer: Not an Ubuntu dev, not even a user, but one of the devs of apt itself reading "downstream" bug reports) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1965960 Title: apt installs snap packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1965960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1960727] Re: When apt holds back updates, it fails to inform the user of the reason
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 distribution. That is because a package is seldomly held back because it is itself "misconstructed" (and never because its "corrupt, or otherwise junk"), it is usually the state of the universe at large (so to speak) who is at 'fault'. Happy to be proven wrong through. Ideally with a tool who can deduce these things which could be used in apt & elsewhere. Also, but that comes down to user attitude I guess, is that as a user I am trusting the tools I am using. So it justifying all its decisions in detail for me to review feels way too micro-managing to me. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1960727 Title: When apt holds back updates, it fails to inform the user of the reason To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1960727/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1957781] Re: when i upgrade my package ask me yes or no ?
+
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 in between the square brackets counts as a yes. In any
application honoring this setting, apt isn't alone in this! And it is
sort of important to respect such settings as in some locals 'N' means
something different (I think e.g. in Norway it means yes).
1/0 make sense for technical persons to use btw as they will be familiar
to the concept of on/off, yes/no, … being encoded as 1/0. For less
technical people that can be a bit alien and showing all options would
probably confuse the heck out of people not familiar with regex syntax,
hence apts choice to display only two common options ("Y/n").
So, this is not a bug, but intended behavior and as such I am closing
this bugreport.
** Changed in: apt (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1957781
Title:
when i upgrade my package ask me yes or no ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1957781/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1952720] Re: apt uses proxy in order to access local resources
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 (or both) does not match with your reality (anymore) and hence denies the request. You actually confirmed this already by disabling the checks in the config which resulted in it working (again). As apt works as it should be here, reassign to the suqid-proxy package. ** Package changed: apt (Ubuntu) => squid-deb-proxy (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1952720 Title: apt uses proxy in order to access local resources To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/1952720/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950095] Re: [github] 20.04: Apt fails to download URLs with non-encoded querystrings
"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 complicated code in the world, but it's quite a bit of it as I was not trying for minimal, but instead maximized for forward and backward compat. (Disclaimer: I am the upstream author of the patch set in question. Not involved enough with Ubuntu to know and/or predict if this qualifies or not for backport, so not commenting on that part. Pretty sure Debian would refuse if we tried including that in a stable update through). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950095 Title: [github] 20.04: Apt fails to download URLs with non-encoded querystrings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1950095/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1945093] Re: apt update command output gives gapes in row numbering
> 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 message. If we like really wanted to fix that we probably could special case this situation and trick the progress reporting into showing a hit for Release.gpg, too, but you are the first person to notice in … a lot of years and the proper fix is for this repository to have an InRelease file. I would have set it to "wont-fix", but I am apparently not allowed to do that on launchpad, so "opinion" it is, which feels wrong as I agree its unfortunate, I just don't think it is worth it to invest precious resources to fix it at this point. In an ideal world we would instead drop the fallback which would also fix that issue… (but also break that repository). ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1945093 Title: apt update command output gives gapes in row numbering To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1945093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1936273] Re: apt not respecting Ignore-Files-Silently directive
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 configuration files. ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1936273 Title: apt not respecting Ignore-Files-Silently directive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1936273/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1682320] Re: apt-transport-tor causes errors saying "Failed to download repository information"
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 years ago. Probably not that helpful now years later, but so is keeping this unactionable bugreport open. ** Changed in: apt-transport-tor (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1682320 Title: apt-transport-tor causes errors saying "Failed to download repository information" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt-transport-tor/+bug/1682320/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1793495] Re: apt-transport-tor doesn't handle tor+mirror:// lines in sources.list
(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 connected to, so potentially different exit nodes are used for getting the mirror file vs. getting the actual files from the selected mirror(s). ** Changed in: apt-transport-tor (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1793495 Title: apt-transport-tor doesn't handle tor+mirror:// lines in sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt-transport-tor/+bug/1793495/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921626] Re: apt install - File has unexpected size - http pipeline
> 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 matches the size the error shows the last tried size (aka of the last file in the queue). I wonder a bit why Filesize isn't included in the message as internally it is implemented as a (very weak) hash, but that might be due to the apt version… I am not remembering ATM how it worked back then. I am also a bit worried about the screenshot in the referred bugreport as that shows two different servers replying (Apache vs some python via a proxy). And last not least: The sizes given in the HTTP request logs for python3-zmq (which failed in that example) shown in /var/log/httpd/foreman_access.log and /var/log/messages do not match (254232 vs 254454). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921626 Title: apt install - File has unexpected size - http pipeline To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1921626/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1713219] Re: 'apt-mark showauto' and 'apt show' is slow
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 clients might. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1713219 Title: 'apt-mark showauto' and 'apt show' is slow To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1713219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1713219] Re: 'apt-mark showauto' and 'apt show' is slow
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" state potentially causing huge problems. I like to think that it is the same here. If the data gets lost, corrupted or whatever we fall back to a safe state: protected from autoremove as manual installed rather than causing havoc. In reality the original implementer might not have thought that far, but he isn't around anymore to ask him… and it isn't really important, is it? Your precived "slowness" might be an out of dated cache. Have you recently run an apt command with root rights? If it is not run as root apt will build the cache in memory only. That cache can also easily be many megabytes big, which can take a while to shuffle into disk cache on a slow spinning disk. Your script might be very fast, but it is also wrong (Auto-Installed is not the only field which can be set there even if for apt its the only one used. Other clients could use other fields and in that case apt would of course also keep the manual entries…) and doesn't even begin to support what apt-mark does. If you want to constructively work on speeding apt in these cases is to look at where the time is lost and optimize those codepaths. Showing off your script-foo is not helping and borderline trolling… after all, I can easily point at a lot of traveling salesperson (well, perhaps not in corona times), but that seems like a very hard problem for computers somehow. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1713219 Title: 'apt-mark showauto' and 'apt show' is slow To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1713219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919314] Re: debconf: delaying package configuration, since apt-utils is not installed
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 than the "normal" output. In any case, this is something you will have to bring up with debconf… reassigning there (and resetting status). ** Package changed: apt (Ubuntu) => debconf (Ubuntu) ** Changed in: debconf (Ubuntu) Status: Opinion => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1919314 Title: debconf: delaying package configuration, since apt-utils is not installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1919314/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919314] Re: debconf: delaying package configuration, since apt-utils is not installed
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 interrupting the process multiple times waiting for user input who might have decided to take a walk while this lengthy installation process runs to return to a machine having stopped half-way through with a configuration question (not installed) vs. a machine who asked the questions upfront and is now done (installed). The end result doesn't change regardless of apt-utils being installed or not – its just a matter of which way is taken to get there. (In an ideal world, in reality there are still packages who have to ask questions in the middle of it as those only come up in certain configurations and/or situations and can't be asked upfront). ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1919314 Title: debconf: delaying package configuration, since apt-utils is not installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1919314/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1918930] Re: Unexpected file size of one package interrupts update process for all packages and leaves system vulnerable
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 error message points to? It will make it so that apt still shows the errors, but it will continue on and install all packages it could successfully acquire. That is still a failure for the whole process though (if that would be silent it would be too easy for an attacker to fail these downloads and make you believe you are up-to-date while nothing was installed – especially in unattended processes). Perhaps we should make that an interactive question in "apt" to have it more easily discoverable for an interactive user? (not commenting on the LP things, you may want to talk to them directly about this rather than venting in an unrelated bugreport) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918930 Title: Unexpected file size of one package interrupts update process for all packages and leaves system vulnerable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918930/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869107] Re: Error when installing scanner deb on 20.04
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 /apt-team/apt/-/commit/bf46e09f0e4b52b3c71ac20bb11e7511fc16179f That the scanner doesn't seem to work for you is orthogonal to this issue. You might want to contact a support channel of Ubuntu about this with more details – bugreports tend not be a good place for getting hardware to behave with drivers in third-party packages. Thanks for reporting your issue none the less! ** Changed in: apt (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869107 Title: Error when installing scanner deb on 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1869107/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1668944] Re: The _apt user ignores group membership.
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 features in practice for easier testing: Any takers? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1668944 Title: The _apt user ignores group membership. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1668944/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864623] Re: apt-get attempts to download Packages.xz which is not InRelease and does not exist
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 exist and be advertised in the (In)Release file. The option is from a time the answer was a lot easier to answer (a long time ago), but nowadays apt supports too many optional features which are handled at runtime to make accurate predictions (especially) about the future. So, your problem is elsewhere. Please check what "update" says. What a following install command says and verify that the deb file it wants to download actually exists. "~Ubuntu" in the version seems kinda strange… usually its lowercase. Either is fine, but consistency is key: apt as most tools in Linux is case-sensitive. Anyway, with the current set of information we can only make very wild guesses. ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864623 Title: apt-get attempts to download Packages.xz which is not InRelease and does not exist To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1864623/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1857018] Re: apt-get: Can not downgrade dependencies or anything with -t
"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 satisfied by the already installed [newer] versions from the PPA). Note that downgrades are still unsupported and can break your system, so that is really not a painless action. Nobody said activating PPAs left and right is something you can or should do – or that it is easy to change your might. You probably want something like "pick all packages from PPA foo and install from bar". I think you can express something like that with the newish patterns, but note that apt doesn't really know if a package was installed from PPA foo. It guesses that if the current version is the same as the version in the PPA it was installed from there, but that isn't the same thing… -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1857018 Title: apt-get: Can not downgrade dependencies or anything with -t To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1857018/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1825021] Re: apt's dpkgpm.cc WriteApportReport function should gather more data
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 to Ubuntu. https://bugs.launchpad.net/bugs/1825021 Title: apt's dpkgpm.cc WriteApportReport function should gather more data To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1825021/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1809174] Re: apt doesn't detect file corruption in /var/lib/apt/lists
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 of a compressor could produce different files). So such a check is not exactly free as we need to potentially uncompress the content we want to check – we can't even do a size check in the general case "for free". It might be worth it paying the price in "update", but there are a bunch of people who believe we shouldn't, reporting bugs to the effect that a no-change update should finish instantly. That said, files of size 0 could be made always invalid: We don't download such files nowadays (as an empty file compressed has a [small] size), so files in lists/ should have at least some content and if they don't something is absolutely fishy. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1809174 Title: apt doesn't detect file corruption in /var/lib/apt/lists To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1809174/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1787460] Re: Unattended upgrades removed linux-image-generic
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 secure). Perhaps some should be "Important:yes"… For the record: apts behavior is different depending on if you explicitly remove a metapackage vs. its removed as part of problem resolution like in a dist-upgrade or if you remove some dependee. Only in the later cases the manual bit is applied to the (other) dependencies of the metapackage. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1787460 Title: Unattended upgrades removed linux-image-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1787460/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1718453] Re: apt does not download dep11 files for foreign architectures and appstream cannot find applications for these archs.
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 download the files for all configured architectures – if that is really desired is what appstream developers have to figure out. I will add that it might be also a good idea to add support for Components-all first to avoid at least a bit of duplication (yes, apt supports downloading those files, too, it just wont by default – but that default can be switched via Release file metadata). ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1718453 Title: apt does not download dep11 files for foreign architectures and appstream cannot find applications for these archs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1718453/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1682320] Re: apt-transport-tor causes errors saying "Failed to download repository information"
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 connection. Possible would e.g. be a repository forbidding access via tor which in older apt versions could end up in such errors – nowadays the errors are different. Also, with 0.3 the implementation of apt-transport-tor changed entirely so even if that was a bug in it, it wouldn't really apply anymore. ** Changed in: apt-transport-tor (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1682320 Title: apt-transport-tor causes errors saying "Failed to download repository information" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt-transport-tor/+bug/1682320/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1740114] Re: apt-get update hangs forever trying to fetch data via a non-working IPv6 connection
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, but as an APT developer who is paid splendidly by the many thanks of people like you for investing his freetime it feels like my obligation to pay back some times: Its not our fault that you misconfigured your system and throw money out the window. APT wouldn't be using IPv6 if your system wouldn't say that it is available. Talk to your ISP: You pay them a lot for your router and network usage presumably. Enough to make non-broken IPv6 available to you – you will need it sooner than later. APT also performs fallbacks – not quickly, we are working on that, but it eventually does: Too quick and naive a fallback and we break for systems which have high latency, but otherwise working configuration. So, as this "bugreport" adds exactly nothing to improve the situation expect perhaps "helping" that I and other volunteers are never going to look at bugs written by "fucking insane morons" I am closing as "opinion" for fucks sake. P.S.: apt isn't launchpad either. These guys likely wouldn't appreciate the nice ton of your message either, through. ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1740114 Title: apt-get update hangs forever trying to fetch data via a non-working IPv6 connection To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1740114/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1725861] Re: APT::AutoRemove::SuggestsImportant "false" should be the default
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 many users who only very casually check the output of apt and generally trust it to do the right thing™. And that is kinda reasonable if we don't want to teach every user packaging practices. Most users will just not make the connection between having run autoremove a couple of days ago and suddenly not being able to push audio files from their favorite player directly to their phones causing users (and supporters alike) to be frustrated. Having "too many" packages installed rarely causes that level of frustration in comparison. autoremove is just not an "undo". It is supposed to remove things which are clearly no longer needed by anything. Like old kernels, old libraries and co. In fact, ideally we should end up in a situation in which autoremove can be called automatically so that old kernels are really gone, the system is cleaner after an upgrades and such… (but for various reasons that isn't really possible/advisable at the moment). Perhaps we should implement an "undo" – just named differently as that is too confusing as we can't really perform an undo, but we have the history.log from which we can extract which packages were newly installed in an "apt install A" and offer to remove them as well (maybe with a question ala: those other packages make use of B initially installed with A, should we keep it?). (And, while we are at it also a way for a repository to say: I don't support package A anymore with options among a) you can safely remove it as something else takes care of it now, b) here are potential alternatives [we tend to have a list in RM requests, but nothing a user can look at easily] c) it is dead and nothing compares d) look elsewhere for it e) … – which should deal with a lot of packages which autoremove should be removing, but is too scared ATM as it has not enough information to make a safe call) [No, I haven't implemented either. I haven't even really thought about them. It just sounds for me like those could be potential ways to resolve the situation] -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1725861 Title: APT::AutoRemove::SuggestsImportant "false" should be the default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1725861/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1701852] Re: (xenial+) apt-cache fails to run if a single sources.list.d entry is not readable
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 well a bug… long story short I guess we can make that a warning. Why an error/warning? Having a different view on what packages are available depending on if you are root or not is a cause for confusion by users and tools alike as you confirm the non-root view, but the root view is applied, which might include additional packages, different versions or even (additional) unauthenticated packages you haven't approved… (but the tools think you have). Similar things happen for non- root preferences/configs and are hence discouraged. For netrc/auth.conf documentation we have e.g. Debian bug #811181 tracking it. It is just that nobody has written documentation yet. I assume it is waiting for someone who actually wants that feature to write a few sentences about it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1701852 Title: (xenial+) apt-cache fails to run if a single sources.list.d entry is not readable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1701852/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1694989] Re: apt-mark overwrites existing held package info
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 dpkg/status file is modified again (e.g. with another hold), the record for the uninstalled package is cleaned up removing the hold. That is intended behavior by dpkg upstream according to earlier talks (and in there since ever, but I think the situations in which cleanup happens increased over time). We were thinking of having some way of having dpkg store such info even for not installed packages, but then life (& freeze) happened I guess, so there is nothing to show off apart from "yeah, we should be doing something, maybe". Perhaps we should just change apt to not accept holds for non-installed packages until that is resolved in some way. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694989 Title: apt-mark overwrites existing held package info To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1694989/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1687666] Re: apt-cache doesn't read keys from trusted.gpg.d when rootdir is used
"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 to stay as an apt bug perhaps try to reproduce it with "apt-get update -o Rootdir=/path/". The mentioning of "trusty" in the tarball indicates a rather old version. We had a bunch of these strange characters/spaces in path issues in recent times; perhaps some/all weren't backported to trusty – I don't follow Julians effort on that front all too closely. btw: Rootdir is usually not the option you want. Dir tends to have the same effect for "less" surprises – depends a bit on what you actually do through. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1687666 Title: apt-cache doesn't read keys from trusted.gpg.d when rootdir is used To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1687666/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1680261] Re: apt-secure ignoring allow-unauthenticated during apt-update
> 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 error resulting from the […] It is actually the point of --allow-unauthenticated to skip the explicit confirmation for unauthenticated packages and nothing else since all of its existence… (because the 'complains' from "update" are new) I was misreading "--allow-unauthenticated" for "--allow-insecure- repositories" – but for the record the documentation for the earlier one explicitly mentions the trusted option (at least in 1.4, not check earlier). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1680261 Title: apt-secure ignoring allow-unauthenticated during apt-update To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1680261/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1680261] Re: apt-secure ignoring allow-unauthenticated during apt-update
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 sources.list – also hinting at "trusted". ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1680261 Title: apt-secure ignoring allow-unauthenticated during apt-update To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1680261/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1668944] Re: The _apt user ignores group membership.
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. Disabling the feature or making the file world readable does work as well, but totally defeats the point of course… I don't see what the point of trying to us groups here is. Are you trying to share the same certificate for multiple things? If so that's a bad idea. You should have a certificate for each and every usecase (= client), not a single one shared between multiple clients on the same machine. ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1668944 Title: The _apt user ignores group membership. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1668944/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1632209] Re: apt-file search says "Don't know how to handle tor+http"
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 (aka months before this report). I guess it missed the LTS deadline – perhaps there is a backport available if you need it to work. In any case, this isn't a bug in apt-transport-tor hence closing as invalid. ** Changed in: apt-transport-tor (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1632209 Title: apt-file search says "Don't know how to handle tor+http" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt-transport-tor/+bug/1632209/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1649086] Re: W: Invalid 'Date' entry in Release file /var/lib/apt/lists/developer.download.nvidia.com_compute_cuda_repos_ubuntu1604_x86%5f64_Release
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 /warning/ is generated – a user can work with the repository as before. As the content of that field is only of use for applications and apt isn't a fullblown calendar-application we decided to not implement all the craziness which is time. All hints for creating repositories which apt (and other clients and servers) can work with: https://wiki.debian.org/RepositoryFormat So, as this isn't a bug: Closing as invalid. ** Changed in: apt (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1649086 Title: W: Invalid 'Date' entry in Release file /var/lib/apt/lists/developer.download.nvidia.com_compute_cuda_repos_ubuntu1604_x86%5f64_Release To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1649086/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1657440] Re: apt won't redownload Release.gpg
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: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1657440 Title: apt won't redownload Release.gpg To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1657440/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1551464] Re: apt-get sources should support TLS SNI (server name)
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 which does, but details). apt doesn't need the option as it is using libcurl-gnutls which is using SNI (see the apt- helper command above as proof). That this isn't working in your case on your system is a bug "somewhere", possibly libcurl-gnutls or the things it uses like libgnutls, but not a reason to request a servername option in apt which given that you want to set it with servername == hostname would be a NOP anyhow… P.S.: Fire up wireshark and realize that HTTPS itself fails your blank "everything should be encrypted" statement. The irony is that SNI is actually one of those unencrypted but highly informational pieces. The rest is a bit of traffic analyze away as you have perfect knowledge of the entirely static data sent over the encrypted wire, so from the transfer size alone you can already make reasonable guesses about what you do and with a bit more work you can be sure. Better than nothing of course and one of the reasons I subsumed under "you might want" but its still mostly a feeling of security/privacy you get here as apt just isn't your typical dynamically created website with cookies and passwords and stuff resulting in unique data streams where HTTPS makes a lot more sense. IF you and repository owners were really into privacy, you would be using TOR and repositories on onion services (for the record, apt supports it via apt-transport-tor and some repositories are available as onion service). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1551464 Title: apt-get sources should support TLS SNI (server name) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1551464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1551464] Re: apt-get sources should support TLS SNI (server name)
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 can respond with the right cert). I somehow doubt a highlevel interface like libcurl even exposes such a detail. The bugreport you reference is speculating about all sorts of things, so one of them might be it. I would personally consider a bug in libcurl-gnutls most likely (note that this is not always the library behind curl. It seems to be in newer releases, older releases use libcurl (the openssl variant)). As an additional datapoint: On Debian stretch the command "/usr/lib/apt /apt-helper download-file 'https://deb.nodesource.com/gpgkey/nodesource.gpg.key' 'nodesource.gpg'" works just fine, so in newer versions that seems resolved. Anyway, this report is a mixture between a feature request we will not be implement and a bug we don't have – as such marked as invalid in apt as you are better of finding the real culprit and report a new bug against that. P.S.: apt doesn't need https for integrity. Given the sorry state of CAs (compare e.g. StartSSL/WoSign) that wouldn't really be secure… There are other reasons you might want https even in case of apt, but blank statements aren't making anyone more secure – they just make them feel secure. ** Changed in: apt (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1551464 Title: apt-get sources should support TLS SNI (server name) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1551464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1522988] Re: stdout and stderr are not synced on lines
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 is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1522988 Title: stdout and stderr are not synced on lines To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1522988/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1522988] Re: stdout and stderr are not synced on lines
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: Multiple processes are running here which would need to be synced by an additional output layer all so that debug output looks nicer…). Or you mean sometimes else which might or might not be a bug (still). Without additional details it is at least not an actionable bugreport hence set to 'incomplete'. ** 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. https://bugs.launchpad.net/bugs/1522988 Title: stdout and stderr are not synced on lines To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1522988/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1634234] Re: apt-key leaves files in /dev open after exit
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 gpg-agent, but "a few seconds" is obviously too slow if you are in a hurry, so apt-key tries to kill it via gpgconf --kill gpg-agent (which isn't supported in all gpg version, but at least in the one in ubuntu I hope). The manpage tells me that this isn't supported for dirmngr through, which is the daemon left in your case, so solving that from the apt-key side isn't exactly easy (short of implementing a sub- subprocess supervisor in shell script…) so I would feel tempted to declare that the problem of gpg and invalid for apt-key. That said, your apt-key command is bad and should be replaced. Getting keys from a keyserver is hopelessly insecure (it is better with recent gpg versions) but still: Your use of a short-keyid screams security problem due to easy collisions and hkp is a cleartext protocol so just asking for MITM (and at least older gpg versions do no checks at all on the received key(s)). I guess the simplest & best solution is to ship the key in your preseed script and drop it with an appropriate name (ending in .gpg) in /etc/apt/trusted.gpg.d/ – as a bonus, your system will not need gnupg installed (at least in terms of apt), gpgv will be enough. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1634234 Title: apt-key leaves files in /dev open after exit To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1634234/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577926] Re: apt-key works fine, yet apt fails with "Could not execute 'apt-key'"
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 code… there are ways to have a similar effect, but as that would be an enormous security hole I am not going to describe it here for fear of someone blindly copying it. Obviously NOT a good idea at all. Now that we have that out of the way two "common" problems: 1. Check that /tmp has reasonable permissions. It should have 1777 and be owned by root:root. 2. ls -ld /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d /etc/apt/trusted.gpg.d/* Everything shown should be owned by root:root and everything world-readable (= the last of the three r's). (the first is hard to detect, the second has a proper warning in newer apt versions) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577926 Title: apt-key works fine, yet apt fails with "Could not execute 'apt-key'" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1577926/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1616909] Re: Installing multiple dbgsym packages fails
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 *.deb files. Debian had decided to stick with .deb for their automatic debug packages to avoid changing all tools dealing with deb files to also deal with ddeb (or whatever). Anyway, as that used to work with apt and is a valid althrough uncommon thing to have packages without .deb as extension I have just commited a patch upstream: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=4f242a2 As a workaround you can set the option "dpkg::install::recursive" to false and "dpkg::install::recursive::force" to true OR set "dpkg::install::recursive::minimum" to e.g. 100 (assuming you can accept not installing a 100 ddebs at once for the time being). Both workarounds effect all dpkg calls through, so please only use if needed until the patch reaches Ubuntu – don't set it "forever" or you will eventually run into the problems this is designed to void in the first place… ** Changed in: apt (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1616909 Title: Installing multiple dbgsym packages fails To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1616909/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1611010] Re: yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: ''
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. https://bugs.launchpad.net/bugs/1611010 Title: yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: '' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1611010/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1613193] Re: apt-get does't work with http_proxy
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 specific to your setup than a general "everything broken" case… Please run apt with some debug options enabled: -o Debug::Acquire::http=1 -o Debug::pkgAcquire::Worker=1 Beware: That generates a lot of output, so you might want to add also somthing like: 2>&1 | tee apt-update.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1613193 Title: apt-get does't work with http_proxy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1613193/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1607845] Re: List of versioned kernels is not right for Ubuntu
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 unlikely with the kernel versions attached… in the case of goldfish it seems to be unneeded through as they have "normally" named images/headers packages, too, which depend on the strange ones, so the autoremover wouldn't kick in anyhow for those. kfreebsd, gnumach (= hurd) do not share the same version, they do share the kernel postinst scripts which apt is using here through, so even through they use entirely different version schemes, its still a version we can work with. Excluding specific items depending on the architecture we built apt for would be possible, but not really worth the implementation effort I presume. And yes, -modules/-kernel is for out-of-tree modules as created by module-assistant (from -source packages), but I think dkms can built packages, too, and its the naming scheme which tends to be used for packages for modules which happen to be distributable as binary builds… (not that there would be many). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1607845 Title: List of versioned kernels is not right for Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1607845/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1589204] Re: apt-get dist-upgrade and apt full-upgrade not reporting held back package
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 same: We change the candidate (which we also do in another case: M-A:same version screws) which means later parts do not realize that there ever was a chance to upgrade the package. In other words: Not that easy to fix… -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1589204 Title: apt-get dist-upgrade and apt full-upgrade not reporting held back package To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1589204/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1605160] Re: kernel autoremove not working
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 not sure this really list all modules). In that case it works as "intended". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1605160 Title: kernel autoremove not working To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1605160/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1605160] Re: kernel autoremove not working
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 nothing else would block them: apt-mark showauto ^linux-image-.* apt-mark showmanual ^linux-image-.* cat /etc/apt/apt.conf.d/01autoremove-kernels -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1605160 Title: kernel autoremove not working To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1605160/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1216426] Re: package libisofs6 1.2.4-0ubuntu1 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 2
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 general bug in apt, wouldn't apt be chest deep in such bugreports? We are chest deep in all sorts of bugreports for sure, but that can at least be partially attributed to being considered a good dumping ground for bugs package maintainers don't want to work on themselves. A strong hint for that is apologizing in advanced btw… :( Failing postinst are usually bugs in the package itself as it is using things which aren't (fully) installed it isn't allowed to use by policy, but does anyway. A huge pointer in that direction tends to be that just re-running apt/dpkg solves the issue. That doesn't need to generate a huge load of bugreports as there is a good chance that the maintainer is lucky enough to get the mistake hidden in 99% of all cases anyhow. Classic example is using python. In your case, back in that version the package didn't seem to have a manual postinst script (something which you could have checked…), just an autogenerated by debhelper calling ldconfig (essential in libc-bin). That failing indicates more hardware issues. No opportunity for an apt bug here in any case. Anyhow, I see nothing actionable in this report for us, so closing as incomplete… ** 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. https://bugs.launchpad.net/bugs/1216426 Title: package libisofs6 1.2.4-0ubuntu1 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1216426/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1598810] Re: `apt-get install python3.4` on xenial exits 0 despite python3.4 not being available
(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 to not like that at all even if its for their own good [compare recent security enforcement]. Implementing options for changing it varying by release and even distribution is actually even more frighting than the present interface through as that one is at least reasonably consistently bad… That is why I mentioned patterns [see aptitude for examples] as a future way out - together with 'apt' on the user side, but that bug is about automation, so that will always be 'apt-get') @Dan: Indeed, I got kinda confused by you mentioning that they got python3.5 and /not/ mentioning regex while comparing it to a non-regex in behavior. Sorry. With no xenial box in close reach ATM I tried it (with apt 1.2 as well as 1.3 series) on my Debian machine but that has both packages available [only] in stable. Causing libpython3.4-minimal to be installed via a regex is producing the usual install behavior (it does want to remove findutils through as that breaks these. Removing essentials is fun, wouldn't be surprised if it turns out to be related to that). Lets try the usual solver-debug-combo first: -o Debug::pkgDepCache::Marker=1 -o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1598810 Title: `apt-get install python3.4` on xenial exits 0 despite python3.4 not being available To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1598810/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1598810] Re: `apt-get install python3.4` on xenial exits 0 despite python3.4 not being available
(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 which is impossible to change without breaking existing users. Note that the package python3.4 doesn't exist at all in the view of apt, which triggers this. If ANY package would give it as much as a passing hint that it ever existed (by having any sort of dependency on it) apt would actually error out in a way you would like it to (saying that python3.4 isn't available for install, but is referenced by other packages – pointing to the potential of being replaced by something else or distributed in another repository). That is also perfectly fine and established behavior which is impossible to change by now. Anyway, a workaround for your setup might be using '^python3\.4$'. So, as there is no bug to be found, closing as opinion. We could treat it as a wish for controlling how the string is interpreted, but that will actually be a tiny by-product of patterns – and is in no way helping apt versions without patterns as a feature, which is the subtext of this bugreport. P.S.: The automation to make stuff available for an application is called packaging, not running apt commands automatically as this has failure modes like this, makes changes so much harder for the python side as well as the application side, destroys automatic removal and and and which is why package management was invented decades ago in the first place. ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1598810 Title: `apt-get install python3.4` on xenial exits 0 despite python3.4 not being available To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1598810/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1571370] Re: Missing option in the manpage
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 option which a user might happen to use. Its even more obvious with the --no-download option. Documenting --download would just be more text to write, read & translate for no obvious benefit – hence marking as wontfix/opinion. ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1571370 Title: Missing option in the manpage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1571370/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1593583] Re: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_yakkety-proposed_InRelease
@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 single-digit hours… Anyway, I wrote a patch upstream avoiding the use of std::get_time by doing the parsing of the timestamps more manually for the "time" being which accepts days/hours even if they are single-digit… -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1593583 Title: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_yakkety- proposed_InRelease To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1593583/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1593583] Re: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_yakkety-proposed_InRelease
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. Reverting commit 9febc2b238e1e322dce1f94ecbed46d595893b52, which introduced the usage of std::get_time has the disadvantage of opening the 'problem' it is supposed to fix again and the 'bonus' the commit mentions is removed, too, which seems small, but is a surprising gotcha in unsuspecting applications (which are either not fiddling with locale at all or are multithreaded). ** Bug watch added: GCC Bugzilla #71556 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1593583 Title: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_yakkety- proposed_InRelease To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1593583/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1583591] Re: Removing a meta package shouldn't mark any of it's deps/recommends for autoremove
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 like the browser). If you request the removal of the metapackage explicitly through, the dependencies will not be marked. You can do that manually as you see fit. This is done so that people who install a suite of packages via a metapackage can get right of this suite in (roughly) the same way they installed it. ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1583591 Title: Removing a meta package shouldn't mark any of it's deps/recommends for autoremove To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1583591/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1538438] Re: apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()
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 of the requester. At least that break fits in the timeframe, is in mentioned method (RunMessages) and happens [only] with apt-helper (see added test), but I use none of those downloader packages and don't feel like starting to, so that is just an educated guess. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1538438 Title: apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1538438/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1576960] Re: apt-mark prints ambiguous package name
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 have this special architecture. It is a specific version of a package "foo:native" which was built such that it works independently of the underlying native architecture – so the display of fully arch-qualified package names would still be "wrong" as apt-mark talks about packages, not about versions. This distinction comes into play e.g. if the source package changes from any to all (or vice versa) as this resembles a 'normal' upgrade (which carries over data like the autobit), while there is no upgrade path in the crossgrading foo:i386 to foo:amd64 case. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576960 Title: apt-mark prints ambiguous package name To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1576960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1576960] Re: apt-mark prints ambiguous package name
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 single-architecture systems do not need to be touched/fixed. It just happens to be a different convention than dpkg is using – which prints the architecture only if it could be ambiguous, like for all packages marked as M-A:same (Since recently it also shows the architecture for M-A:foreign packages of a non-native architecture, too) and in exchange requires an architecture to be given (for M-A:same) even if it isn't ambiguous [which broke pre-multiarch tools, but most tools interacting with dpkg do this via apt which shielded them]. APT can't operate with this convention as basically every package is available in all architectures, so a package name is always ambiguous and hence all package names would need to be fully arch-qualified all the time. That would be a lot of noise… ** Changed in: apt (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576960 Title: apt-mark prints ambiguous package name To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1576960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1560797] Re: package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured during 15.10 to 16.04 upgrade
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 backportable into 2011 (= the time this regression was introduced) even if the surrounding code changed a bit over time. Could potentially also be worked around with strategic duplication of Pre-Depends in Depends. So, what going on? apt doesn't check if Pre- Depends are satisfied before configuring but that is actually hard to trigger as apt does check them for unpack and the window between unpack and configure is usually very small as apt is actively trying to have it very small (compare immediate configuration) so all my attempts at constructing a testcase for it failed so far… ** Patch added: "0001-recheck-Pre-Depends-satisfaction-in-SmartConfigure.patch" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1560797/+attachment/4636054/+files/0001-recheck-Pre-Depends-satisfaction-in-SmartConfigure.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560797 Title: package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured during 15.10 to 16.04 upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1560797/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1560797] Re: package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured
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 thing™). I might have some free time later this week to look at this closer if nobody else beats me to it… (no promise through). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560797 Title: package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1560797/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1560797] Re: package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured
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 and log-staring usually doesn't work that well, so being able to reproduce this would be very nice… What we can try is testing with the /var/lib/dpkg/status file from BEFORE the upgrade. Backups of this file can be found in /var/backups: The file "dpkg.status.X.gz" (where X is a number and .gz optional if X is 0) modified last before the upgrade would be good to have. Note before uploading: This file includes information about ALL packages you have (or in that case had) installed and in which version (which you might or might not consider private/personal information, but that applies already to most log files, too). Assuming we would have such a file we could try on a THROWAWAY system: -o dir::state::status=/path/to/file -o Debug::pkgAcqArchive::NoQueue=1 -o Debug::pkgDpkgPM=1 (theoretically its possible to run this on a system you wanna keep, but theoretically there is also no problem with juggling a bunch of running chainsaws… until something goes wrong in practice) The output will likely be a mile long including the exact commands apt would have used to call dpkg. If that exposes the wrong order we are "good". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560797 Title: package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1560797/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566657] Re: [apt] implement --yes
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 same options would not only be a big duplication, but also a freaking long manpage nobody will ever read AND it will also be confusing because the hundreds of options in such a manpage would apply each only to a selected few of the subcommands. So, yeah, the user will have to read the manpages of the underlying applications he or she is pointed to be the apt manpages – but given the potential alternative of lumping all manpages into a single big one, that feels like a feature. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566657 Title: [apt] implement --yes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1566657/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566657] Re: [apt] implement --yes
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 used in our testcases, but I have just tried with my local build) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566657 Title: [apt] implement --yes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1566657/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1565782] Re: APT doesn't respect pin-priority when using APT::Default-Release option
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 default-release be so special, why not for all of them… (which can't be done because behavior changes are a no-no in general). Or in other words: You are arguing that default-release should not override pinnings of packages but that doesn't happen. It overrides the pinning of releases. If it wouldn't be doing that, what would be the point… The usecase for this is your very own usecase – or how do you overrule your preferences setting in case you occasionally don't want the PPA to take the lead? You can use globs and regexes in preferences btw. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1565782 Title: APT doesn't respect pin-priority when using APT::Default-Release option To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1565782/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566657] Re: [apt] implement --yes
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. https://bugs.launchpad.net/bugs/1566657 Title: [apt] implement --yes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1566657/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1565782] Re: APT doesn't respect pin-priority when using APT::Default-Release option
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 priority you set in the /etc/apt/preferences file described later, but not over specifically pinned packages. Closing as not-a-bug hence. ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1565782 Title: APT doesn't respect pin-priority when using APT::Default-Release option To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1565782/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1558331] Re: message "The repository is insufficiently signed by key (weak digest)" is poorly worded
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1558331 Title: message "The repository is insufficiently signed by key (weak digest)" is poorly worded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1558331/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1558484] Re: Ubuntu 12.04: apt-get can't parse repository url if username contains @ ('at' sign)
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
436d7eab92bb8f9cc6498acfbf2055e717be6fd0 (from 2010, but that stayed in
experimental for a long time – still, not sure, probably something
better hidden). In either case, fixed by now, so changing status to fix
released. I doubt this is valuable enough to be backported (the bug, not
the commit).
** Changed in: apt (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1558484
Title:
Ubuntu 12.04: apt-get can't parse repository url if username contains
@ ('at' sign)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1558484/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1279776] Re: Encountered a section with no Package: header
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 reproducible in any recent version feel free to reopen. ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1279776 Title: Encountered a section with no Package: header To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1279776/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1559860] Re: [feature-request] Add clean option for apt command
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 are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1559860 Title: [feature-request] Add clean option for apt command To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1559860/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1558484] Re: Ubuntu 12.04: apt-get can't parse repository url if username contains @ ('at' sign)
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 (it has to be
world-readable to have apt-based tools in a functional state).
Instead, create the file /etc/apt/auth.conf and and use the netrc(5)
format to specify the authentication tokens. You can change the access
permissions to this file to your liking (600 for example) as a bonus.
Example: echo 'machine example.org\nlogin star\npassword hunter2' >
/etc/apt/auth.conf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1558484
Title:
Ubuntu 12.04: apt-get can't parse repository url if username contains
@ ('at' sign)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1558484/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 589941] Re: Incorrect status of downloaded bytes while upgrading
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" these changes to jessie (which at that time early last year was frozen) in and around 1.0.9.8. Later versions have that natively of course. ** Changed in: apt (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/589941 Title: Incorrect status of downloaded bytes while upgrading To manage notifications about this bug go to: https://bugs.launchpad.net/aptdaemon/+bug/589941/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1550741] Re: Upgrade failed - unauthenticated package (module-init-tools)
(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 .get_changes() returns packages in "non-interesting" states as those are clearly not changes. Basic sanity checking might be in order here to catch such issues in the future as e.g. a package from archive "now" (which is the designation for a package in the dpkg/status file) can realistically only be removed. APT has the test-bug-735967-lib32-to-i386-unavailable testcase which produces such a situation, the heisenstate doesn't seem to interest apt through and can't be easily observed. Maybe the tests should be extended to be able to call python – the ability could be handy as a CI test in general. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1550741 Title: Upgrade failed - unauthenticated package (module-init-tools) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1550741/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1481871] Re: apt-key del silently fails to delete keys due to limited understanding of GPG key ID formats
> 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 already) had apt-key rewritten fixing this among other things. The unblock request back then mentions explicitly the inability of apt/jessie to work with fingerprints at the benefit of not introducing untested changes late in the release process. As already mentioned 1.1 in Debian (and Ubuntu) supports fingerprints just fine, so there isn't anything left to be done for Debian. In the end, "apt-key del" is supposed to be used only to get away from using apt-key as what you are supposed to be doing is ship your own -keyring package which contains a /etc/apt/trusted.gpg.d/ fragment file instead of using "apt-key add /path/to/file" to add your key to a central file (from which you have to delete it again on remove with "apt-key del"). I doubt the chances to have collision even with shortids among archive keyrings in the wild is high. With longids its even less likely. And what exactly is to be gained by such a collision given that all you get is to take another key (you collision with) with you at the time your maintainerscript (run with root rights I have to add) removes it… [That "apt-key del" isn't failing and can't be changed to do it if it hasn't removed a key is btw based on the problem that its mostly called by maintainerscript, which don't ignore failures] If on the other hand you happen to think you could revert a "apt-key adv" command like "--recv-key" with a "apt-key del" you are wrong as it isn't safe to fetch a key directly into an always trusted keyring to begin with (mainly as you can't be sure that gpg is actually inserting the key you wanted it to and no amount of fingerprint is helping here). See this subthread (and followups) for the written affirmation of Debians gnupg maintainer(s) that you can't: https://lists.alioth.debian.org/pipermail/pkg-gnupg- maint/2015-August/002802.html [just so you don't have to "just trust me" on this]. So, in summary, I believe that the chance that you have a security bug on your(!) side based on the idea that you need a fingerprint in this scenario to interact with apt-key is a lot higher than the chance to encounter a collision even on short keyids in this scenario. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1481871 Title: apt-key del silently fails to delete keys due to limited understanding of GPG key ID formats To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1481871/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1528765] Re: packages deb filename is not consistant
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 encoded to support filesystems which can't deal with ":" in filenames. We are not breaking apt to make you not have to look at epochs, sorry pal. Oh, and reinstalls can be done with "apt install --reinstall $pkg". ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1528765 Title: packages deb filename is not consistant To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1528765/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1497534] Re: apt-get crashed with SIGSEGV in strlen()
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 behavior to store for which language the Translation is aka the result of a X.c_str() call in a char* where X runs out of scope shortly after – but X was just a copy of a globally stored std::string (in that case in the deeps of _config). strlen on such a wild pointer has at least a chance of segfaulting… See also #1486061. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497534 Title: apt-get crashed with SIGSEGV in strlen() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1497534/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1486061] Re: Long descriptions missing from apt cache - affects software-center etc
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 passing our testcases (as the only partly working Translation-* trashes our testcases). That is also the cause for other recent bugreport like #1497534 here I would guess. It is probably not the worst idea to think about applying 8965b2f8 (the one mentioned above) – even if it is technically an abibreak, in practice only libapt itself is using (and is actually able to use) the symbol which is why in newer libapt versions the symbol isn't even exported anymore. 130f34b7 should be applied as well for entirely different reasons (even through it isn't a security fix in any way, it should be dealt with as one). No idea where Ubuntu is in the release cycle frankly as I have other things to worry about at the moment, but instead of cherry-picking these it might be better to use the entire release. They are well tested by now and bugfix only… Feel free to ask me for more details if need be, but expect delays as I read mail between two grape presses at the Most (pun intended, even through mostly a my-region-only pun). And a, btw mc3man: I wouldn't advice to install the Debian version directly on Ubuntu – it depends on the wrong archive-keyring for example. At the very least, you should recompile it, then the buildsystem will take care of setting the right things. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1486061 Title: Long descriptions missing from apt cache - affects software-center etc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1486061/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1479207] Re: Never-MarkAuto-Sections not working correctly
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 on the dependencies of packages with the given sections, but on the packages with the given section itself. Much more details there. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1479207 Title: Never-MarkAuto-Sections not working correctly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1479207/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1477299] Re: please fix building apt using gcc-snapshot
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 helper – as before without a crazy non-sense std::ostream to bool conversion. The auto_ptr think keeps being a warning for now, right? I am happily using c++11 features in (currently unreleased) patches, but I have my doubts if I should really force c++11 upon the reverse dependencies just now (as the auto_ptr gcc is warning about here is in a public header). Even through std=c++11 is the new default, right? Well, we will see after the gcc5 transition is done. There are some more issues with apt build with gcc5 and running with the new libstdc++6, namely that some code pieces assume std::string to have copy-on-write behavior, which it doesn't have in c++11 mode anymore which can be observed by the integration tests – not run at buildtime, but by autopkgtest. Patches for that are in the experimental branch, too, for a while as they break the abi, but the step to gcc5 does break abi anyhow so who cares. ;) mvo said he isn't around for a while, so I will try to polish up the sid-gcc5 branch he created and follow up at debbug#790979 then I am done hopefully later this weekend. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1477299 Title: please fix building apt using gcc-snapshot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1477299/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1464950] Re: output flushing error causing ugly output for autoremove
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: http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2a884c612b10b27f4be2cc6dd689bfe448d9361a It is written as an abi break, but could be rewritten to not require one with some care (at least binary compatible, technically source compatibility breaks and theoretically its still a behavior change). I just decided against it at the time it was clear we would have to keep the diversion a little longer than originally planed and backported just the absolutely needed stuff. We could do it now, but I guess the time is better spent in stopping to semi-maintain two branches. Hence setting fix commited in anticipation of fix released soon [all while realizing that I might very well be the biggest blocker in this process with my perfectionism] ** Changed in: apt (Ubuntu) Status: New = Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1464950 Title: output flushing error causing ugly output for autoremove To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1464950/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1456479] Re: PPA info with trailing quote in /etc/apt/sources.list
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 (copypaste maybe?) OR it was a tool (potentially in the apt-* namespace, but not maintained by the apt team) which has this bug. Its a bit unlikely perhaps, but as far as apt is concerned main could be a valid component (also, because it is hardly defined which characters could be) and the error messages it prints tell you that it tried to get data for the main component as it was configured to do, but wasn't able to. ** Changed in: apt (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1456479 Title: PPA info with trailing quote in /etc/apt/sources.list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1456479/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1456275] Re: Feature request for APT
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 downloads is actually what is provided by the repository and not tampered with by an attacker. That means through that the key needs to be acquired in a way which is secure from tampering. Importing a key from a keyserver is NOT SECURE. Not even if you use a TLS enabled protocol (which gpg doesn't by default). You can make it secure if you can verify that the key you got from the keyserver is what you expected to get. Signatures are a good thing for this, but now you need to know that the signatures are good… aka: You need a trust path from the key to you. APT can't create nor validate such a trustpath. As much as we all love automation, adding a key to apts trusted keyring is a very serious action which needs careful attention and in the end manual work to establish a trust path. If you don't do it, your system is not secure anymore as an attacker who can trick you into trusting the wrong key can subsequently trick apt into installing whatever he wants including keyloggers, bots and trojans as root, with full disk, (local) network and internet access (aka: The holy grail). This isn't too common yet in the internet at large as the linux marketshare is low, but e.g. daily practice in the Tor network and various leaked documents hint in which direction we are heading as everything a governments can do, can also be done by (non-government) criminals sooner or later. ** Changed in: apt (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1456275 Title: Feature request for APT To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1456275/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1448917] Re: apt-get -o quiet=1 dist-upgrade isn't quiet anymore
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 hardly think of everything and/or an important fact to know for upstream isn't obvious to someone who isn't deeply involved with the package in question. So, no critic meant either.) So, with my apt upstream hat, I am reassigning to dpkg even through I know that this is caused by a change in apt, but the problem is that dpkg has a non-overrideable check for terminal output or not (and because as mentioned apt quiet option never influenced dpkg. Otherwise quiet=2 wouldn't have output at all, but what it does is in fact reduce the output to mostly just dpkg output). The apt change in question is that dpkg is properly called in (most) cases in a pseudo-terminal, so it's looking always like dpkg is running in a terminal. We need this in apt to be able to log the output (term.log) as well as show the output of dpkg (and subsequently programs called by it like debconf) correctly. See e.g. debbug #765687. The 1.0.9.x versions contain various fixes (and fixes of fixes) in this regard. You can tell apt to not use a pseudo-terminal for dpkg with -o Dpkg::Use-Pty=0 , but that carries all the disadvantages I mentioned earlier and more and is therefore not advised. ** Package changed: apt (Ubuntu) = dpkg (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1448917 Title: apt-get -o quiet=1 dist-upgrade isn't quiet anymore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1448917/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1448917] Re: apt-get -o quiet=1 dist-upgrade isn't quiet anymore
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 dpkg [and apt never controlled the (non-)quietness of dpkg], so in that case you want to talk to them instead. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1448917 Title: apt-get -o quiet=1 dist-upgrade isn't quiet anymore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1448917/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1436626] Re: aptd crashed with SIGSEGV in _IO_vfprintf_internal()
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 don't have the clearance to look at anything else). Maybe the new crashreport is partly written before it crashes as multiple fprintf's are involved in its creation… (I don't see an obvious badboy. Maybe something about the sourcename lookup. I had to do some bad stuff to preserve ABI in there lately (to fix md5-only source), maybe something of that is incorrect. [even through I would presume these calls would fail, rather than fprintf…]). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1436626 Title: aptd crashed with SIGSEGV in _IO_vfprintf_internal() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1436626/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1429285] Re: feature request: apt-get update --if-necessary
ä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 requests so (if a server supports it… not all do, but at least most) a server can respond with just a 304 Not Modified, so at least there isn't much traffic wasted even if you happen to request updates every few minutes (less effective for load itself of course, apt is trying to be nice here as well by e.g. being a proper keep-alive HTTP1.1 client, pipelining and not opening multiple connections to the same server). A hypothetical average website loaded by a average browser seems to be much worse from a load and traffic point of view… Regarding the snippets: The puppet one just runs update if the sources.list changed. That isn't your usecase as I haven't changed my sources.list for months… The ansible one, well, its a hack. A hack which in the worst case opts you out of security updates for 12 hours. That can be a long time, so I really don't want to define an arbitrary value for not necessary which is (a lot) larger than zero. And I am not very keen on suggesting by providing an option for it that there is a good value for it which I just don't want to figure out myself. The problem is basically that you don't know at which point an update makes sense. Your last update can be 10 seconds ago, but even if that is close, it could still be outdated data as the repository was updated in the meantime. What we would need is a 'soft' valid-until which specifies the time after which the next update is/was deployed. Just that this is pretty hard to predict (its easy to specify when the the update will start on the master [expect for times you want to do an emergency rollout], not so much the point it is finished and don't even try to speculate about when this will reach your mirror…). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1429285 Title: feature request: apt-get update --if-necessary To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1429285/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1425662] Re: apt-get download fails if /var/cache/apt/archives/partial is not accessible
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 give it a spin later… can't be hard,right? ;) ) ** Changed in: apt (Ubuntu) Status: New = Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1425662 Title: apt-get download fails if /var/cache/apt/archives/partial is not accessible To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1425662/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1399037] Re: apt-get can not simulate
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 dangerous as that made user believe they would actually have an effect… Now, what happen back then is that I typoed dselect as deselect, which made it not accept any option… Well, I was never using it, many others neither, so that went unnoticed for months, until someone reported that and (still in 2013) we fixed that. Over the years other similar things appeared (usually forgotten options or options which really had no effect) like the one mentioned here with apt-offline. Anyway, all nice and good right? Well, expect that while the commit message back then indicates that Michael replaced ALL instances of 'deselect', he just fixed one instance. Another one was still in there, guarding some options: (drumroll) -s and friends. Quite telling how unused dselect is nowadays that this could hide itself for another (nearly) two years… Will be fixed soon (= fixed in my branch, but that is unlikely to hit any release soon). Until then you can use -o APT::Get::Simulate=1 instead of -s (or the others like --dry-run). Or, well, don't simulate. ;) Oh, and feel free to give me a compelling example of how to use it for good. Its totally underrepresented in our testcases, so if you want to prevent breakage of your usecase in the future… -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1399037 Title: apt-get can not simulate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1399037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1369259] Re: /var/lib/apt/extended_states registers packages with the architecture all as the system architecture
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, where is the bug? The extended file is an internal state file, so as long as we parse it correctly, everything is fine. If you need the info included in that file, ask e.g. apt-mark for it. Nobody knows if the next version of apt would be renaming the file, be binary or use a mysql database to store that info instead (okay, the later is unlikely… as in: Over my dead body!) ** Changed in: apt (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1369259 Title: /var/lib/apt/extended_states registers packages with the architecture all as the system architecture To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1369259/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 940825] Re: apt-get update reporting not acceptable
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 I would be interested in how to reproduce it still in apt versions = 0.9.12 (disclaimer: I wrote both, the patch and the test). [well, expect that as mentioned in #20 we would try to range a bz2 with an incomplete xz, but that could change with other reorganisations soon and more importantly, is pretty unlikely to have practical effect as compression formats do not appear and disappear at random from mirrors…]. A proper server shouldn't sent us a 416 here anyway, as we sent an If-Range btw as detailed in the HTTP RFC, but if we get it anyhow, we drop the partial file we have and do the request again without a range. Regarding 406: We send an Accept header only if we request an uncompressed file (to prevent servers from content negotiating us a compressed file we do not support…), which is the last one we would try and usually doesn't exist (expect on your own localnet mirrors), so a failure is expected and the problem is more that your mirror doesn't have the compressed files we asked for before… -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/940825 Title: apt-get update reporting not acceptable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/940825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1329760] Re: Database too huge to be real
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 that doesn't really matter): Lese Datenbank ... 686018 Dateien und Verzeichnisse sind derzeit installiert. Completely unrelated to your initial (?) problem of synaptics being slow at times. I bet you run synaptics as user and with an invalid/non- existent cache. Might be 'temporary' gone with apt-cache gencaches. You are better of continuing in the old bug though and with someone who has at least started synaptics once (which I haven't). ** Changed in: apt (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1329760 Title: Database too huge to be real To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1329760/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1324915] Re: apt-cache rdepends has incorrect output
* 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 of them tends to be quiet painful. You have two options: * -o APT::Cache::ShowDependencyType=1 which results in a similar output as with depends (it is the same code). * --important --no-conflicts --no-replaces --no-breaks --no-pre-depends (^ the last one might actually not be what you want, but hints at why we tend to have a relaxed interpretation of things) I would like to have the first one as default, but given that scripts exist which depend on this (insane) behavior, no dice… ** Changed in: apt (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1324915 Title: apt-cache rdepends has incorrect output To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1324915/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1310592] Re: apt-get doesn't update lists timestamp
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 reported. This is needed as otherwise mirror updates might be hidden due to timing: achieve is updated, you apt-get update against a mirror, mirror is updated, you update again: If we updated timestamps to your last apt-get run you wouldn't get any updates in this situation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1310592 Title: apt-get doesn't update lists timestamp To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1310592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1309658] Re: Invalid comments in debian/apt.conf.autoremove
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 that the default assumption is in fact '#'. (all apt config files I have on my systems include #-comments btw, and I doubt I am the only one) We should just document this fact properly instead of reverting support for it… I wonder more why augeas is parsing our config file (but then again, I have no idea what augeas is). We have the apt-config tool to extract settings as well as python-apt, libapt-perl and libapt proper. Doing it on your own leads to a disaster sooner or later… (just compare it with sources.list parsers… a simple codesearch reveals that most of them are fundamentally broken even in perfectly documented cases; but in most cases I have no idea why they they try to parse it in the first place…) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1309658 Title: Invalid comments in debian/apt.conf.autoremove To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1309658/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1308670] Re: apt-get -s --print-uris update does not work on Tahr
(History-digging response) After sending my reply I actually wondered about the lock as well: A simple test revivaled that the current version has no problem with it, but now I had a closer look: I vaguely remember problems with locking as well, but I am not sure if that was related to 'update'. A casual look for changes in that area leads me to git commit 1cd1c398 from 4 years ago, which looks a bit like it could be the fix for this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1308670 Title: apt-get -s --print-uris update does not work on Tahr To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1308670/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
