Hit:1 http://archive.ubuntu.com/ubuntu - InRelease
Hit:2 http://security.ubuntu.com/ubuntu --security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu --updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu --backports InRelease
Ign:5 http://apt.keepsolid.com/ubuntu - InRelease
Err:6 http://apt.keepsolid.com/ubuntu - Release
404 Not Found [IP: 144.217.71.199 80]
Reading package lists... Done
E: The repository 'http://apt.keepsolid.com/ubuntu - Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
On Fri, Oct 07, 2022 at 09:33:28AM +0800, Paul Wise wrote:
> On Thu, 2022-10-06 at 10:54 -0700, xaq xaq wrote:
> > Hi, how do I submit a suggestion to the Apt team? I've tried to
> > register on their website (https://salsa.debian.org/apt-team/apt).
>
> You can report a bug via the Debian BTS:
>
> https://www.debian.org/Bugs/Reporting
Our¹ "website" mentions at the end of our general information blob:
| Discussion happens mostly on
| [the mailing list](mailto:deity@lists.debian.org)
| ([archive](https://lists.debian.org/deity/))
| and on [IRC](irc://irc.oftc.net/debian-apt).
| Our bug tracker as well as a general overview can be found at
| the [Debian Tracker page](https://tracker.debian.org/pkg/apt).
(in markdown so you can see the direct pointers). It is actually our¹
README file in the version control system, we don't have a website and
hence none is given in the Homepage field.
¹ "our" as in: I am one of two active apt developers.
> > - Have an option to ignore failures in any source.list file.
> > This will allow updates of security repos to proceed.
>
> This makes it sound like you need to update your apt sources for the
> changes to the security archive that happened in Debian bullseye:
>
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
Apart from what Paul said (and is btw an other indication that "we will
write it in the release notes and everything is smooth sailing from
there on out" still means a lot of support questions. I stopped counting
how often I pointed to that release note section…):
Please tell us the EXACT and COMPLETE update output you are seeing.
In the security-archive example an 'apt update' will fail with error
messages and such about the bad archive, but all the other "working"
archives will be updated as usual and subsequent apt calls will use
that information. The failure is hence already "ignored" in a sense.
So if you don't see that behaviour it might simply be a bug that should
be fixed.
> > - Have Apt not proceed with install if available space is less than
> > estimated install space. Especially since --fix-broken-install
> > usually requires more space to resolve this.
>
> Until the apt developers implement this, it might be possible to add a
> hook script added to the DPkg::Pre-Install-Pkgs option in apt.conf.
(--fix-broken-install is not a thing, I suppose the last - is a space)
APT already makes a rough check on the available space for the download,
so in that step, you aren't going to run out of space. The installation
is another matter… apt displays a remark on what it thinks will be used/
freed after the upgrade will be complete, but that can be a pretty rough
estimate (= is completely wrong most of the time).
Take apt itself as an example: Download is ~1.5 MB, Install size
supposedly ~4.5 MB. In practice /var/lib/apt and /var/cache/apt will
grow into the hundreds of MBs on first use. apt is usually not used
inside maintainer scripts, but many other things generate lots of data
which isn't accounted for. The other thing is that e.g. we don't know
where that space will be needed: If you have a separate /boot for
example it becomes interesting if your next kernel install will fit into
it as well or not (and if it does in the middle of the upgrade, not at
the end after others were perhaps removed) – and it is usually
accompanied by a generated initrd which isn't accounted for anyhow.
So, that script would probably contain lots and lots of guesswork and
would indeed be better of being not part of apt itself (like the
mentioned listbugs or e.g. listchanges) as src:apt is usually not
granted as much leeway in terms of updates as "leaf" packages.
(Beside that this script probably has the same problem as apt itself:
Ideally an upgrade from X to Y would use the version from Y already)
Best regards
David Kalnischkies