Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #12962 > unrolled thread

Apt feature request / suggestion

Back to article view | Back to linux.debian.project

Contents

  Apt feature request / suggestion xaq xaq <xxasdqwe@gmail.com> - 2022-10-06 20:00 +0200
    Re: Apt feature request / suggestion Paul Wise <pabs@debian.org> - 2022-10-07 03:50 +0200
      Re: Apt feature request / suggestion David Kalnischkies <david@kalnischkies.de> - 2022-10-09 14:50 +0200
        Re: Apt feature request / suggestion xaq xaq <xxasdqwe@gmail.com> - 2022-10-09 22:30 +0200
          Re: Apt feature request / suggestion David Kalnischkies <david@kalnischkies.de> - 2022-10-10 16:00 +0200
            Re: Apt feature request / suggestion Austin Moon <austinm237@gmail.com> - 2022-10-10 17:20 +0200

#12962 — Apt feature request / suggestion

[Multipart message — attachments visible in raw view] — view raw

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).

I have two suggestions/discussions to post.
- Have an option to ignore failures in any source.list file. This will
allow updates of security repos to proceed.
- 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.

Thank you

[toc] | [next] | [standalone]

#12963

[Multipart message — attachments visible in raw view] — view raw

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

> - 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

> - 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.

It might be hard to write such a script. The apt-listbugs package is
probably the best example of how to process the hook script input.

https://sources.debian.org/src/apt-listbugs/0.1.36/10apt-listbugs/
https://sources.debian.org/src/apt-listbugs/0.1.36/bin/apt-listbugs/#L455

Documentation on DPkg::Pre-Install-Pkgs is in the apt.conf manual page:

https://manpages.debian.org/bullseye/apt/apt.conf.5.en.html#HOW_APT_CALLS_DPKG(1)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#12981

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#12982

[Multipart message — attachments visible in raw view] — view raw

Thanks Paul and David.

To simplify a frequently seen halt of `apt upgrade` I have this example.. I
had to remove keepsolidinc.list
from /etc/apt/sources.list.d. Then apt update proceeds. Here is the error I
get with that source list in place:

*Hit:1 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> - InRelease
Hit:2 http://security.ubuntu.com/ubuntu
<http://security.ubuntu.com/ubuntu> --security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> --updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> --backports InRelease
Ign:5 http://apt.keepsolid.com/ubuntu
<http://apt.keepsolid.com/ubuntu> - InRelease
Err:6 http://apt.keepsolid.com/ubuntu
<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
<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.*



For the size estimation, I understand it is an estimation, and there could
be guesswork, but I would posit that if the estimate is even roughly
correct, a user most likely will not want to proceed, because the
consequences greatly outweigh the benefits of proceeding.

This is because once a disk is filled, `apt remove` will not undo the
changes until the install is complete. This creates an impossible
situation, ie. apt cant remove without space, but install cant proceed
because there is no space.

This problem is most relevant today with users heavily relying on VMs where
shrinking a disk is often problematic, so creating an image with the least
amount of freespace is highly useful, because images are often cloned
many times for backup and progression. This means repeatedly bumping into
this "impossible situation".

It seems a simple solution to just not proceed when the estimated install
space exceeds the free space. It is already calculated. And the edge cases
will more likely than not benefit from not proceeding by default. This is
because the cost of a false positive is much, much less than getting into a
catch-22 of disk space, getting stuck, and not being able to undo what apt
just did, even following the recommended --fix-broken which wont work if
the disk is full, which is many times presented because of the disk being
full. I'm not sure I see many situations where having to use a flag to
proceed would harm the vast majority of users.

Thank you


On Sun, Oct 9, 2022 at 5:37 AM David Kalnischkies <david@kalnischkies.de>
wrote:

> 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
>

[toc] | [prev] | [next] | [standalone]

#12984

[Multipart message — attachments visible in raw view] — view raw

On Sun, Oct 09, 2022 at 01:21:45PM -0700, xaq xaq wrote:
> To simplify a frequently seen halt of `apt upgrade` I have this example.. I
> had to remove keepsolidinc.list
> from /etc/apt/sources.list.d. Then apt update proceeds. Here is the error I
> get with that source list in place:
> 
> *Hit:1 http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu> - InRelease
> Hit:2 http://security.ubuntu.com/ubuntu
> <http://security.ubuntu.com/ubuntu> --security InRelease
> Hit:3 http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu> --updates InRelease
> Hit:4 http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu> --backports InRelease
> Ign:5 http://apt.keepsolid.com/ubuntu
> <http://apt.keepsolid.com/ubuntu> - InRelease
> Err:6 http://apt.keepsolid.com/ubuntu
> <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
> <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.*

What do you mean with "halt of `apt upgrade`"? You have shown us output
of 'apt update'? And that output suggests that the other archives were
updated (just that they were already current: cache "Hit").

I suppose if the old data still on disk for keepsolid is indicating
newer versions of packages than you have installed an upgrade would try
to download them potentially running also into 404 errors (assuming this
repo is entirely offline). That would indeed "block" upgrades of other
packages not from that repo, but what is apt supposed to do instead…
It is asked to upgrade all packages and can't: Partial upgrades are
technically supported, but hardly tested in practice as it is
a combinatorial explosion if you tried. So in theory you upgrade from
a perfectly supported system with updates available to a system with
unknown support status and still more updates available. That doesn't
look like a good default move.

You can tell apt to carry on with --fix-missing if that is what you
desire, but really, you should either remove that repository (and the
packages coming from it) for good or work with its provider on fixing
it/making it available again. After all, --fix-missing lets you carry
on in a pinch, but it remains that the repository fails to serve updates
to you, which in the worst case means public known security issues remain
exploitable on your system.

(This could be part of an attack. It usually isn't, but it is
 indistinguishable from a MITM blocking access to a repository so
 that you can not get the security updates the attacker wants to
 exploit. There are better ways, hence its unlikely, but it is just
 a less good way as it shows errors grabbing attention that something
 is wrong. If apt wouldn't, this would be really easy to use.)

> For the size estimation, I understand it is an estimation, and there could
> be guesswork, but I would posit that if the estimate is even roughly
> correct, a user most likely will not want to proceed, because the
> consequences greatly outweigh the benefits of proceeding.

As I tried to explain already apt downloads itself at the expense of 1.5
MB. It will take up installed 4.5 MB. It hardly changes size from
version to version, so more space freed/used after the upgrade amounts
to more or less 0 MB. Running and using apt requires additional data
which easily takes up 200 MB. Lets assume every package is similar to
apt (they aren't, you e.g. have things like texlive which comes in a
couple hundred MBs of download already). A typical upgrade can contain
more than 1000 packages, so which value between 0 and 200 GB are we
gonna use as a rough estimate for that upgrade? And again, which
partitions are we gonna talk about if you have multiple, like e.g.
a separate /boot ?

APT in this scenario picks 1.5 GB (the size it will need to download all
the packages) on the partition housing its download location:
apt's free space check for the download is done against free blocks
available for everyone. In a default configuration root has an additional
5% of a partition as free space available for their exclusive use.

If your idea is that lets say apt should not continue if you don't have
100 MB free on /boot and 5 GB on / (should be enough, right?) that is
fine for your system and pretty easy to implement with e.g. a
dpkg::pre-invoke hook (no need for the heavier dpkg::pre-install-pkgs
hook). That wont work in the general case though… there are systems
which don't even have 5 GBs of disk space to begin with.

(Did you think apts 1.5 GB is a reasonable low bound? For some people
 that is already way too high! Like if your filesystem supports
 compression)


That script you could package up and make available for everyone who
needs it. Probably with config knobs to specific sizes. Probably with
more iterations as people come up with pretty interesting partition
schemes if you give them the option to… perhaps indeed moving to a
pre-install-pkgs hook later on to make better guesses at what a given
upgrade might need (install of two packages, probably fine… upgrading
2000 package ~ now we are talking!) …

If a few months down the line we discover that there is indeed a setup
which works for – lets say – 95% of Debian users we can always set it
to prio:standard and install it by default or integrate it into apt
so (basically) everyone gets it everywhere, but until then it is more
beneficial for you and us if we are not burdening ourselves with
making it work for everyone from day 1.


Best regards

David Kalnischkies

[toc] | [prev] | [next] | [standalone]

#12986

[Multipart message — attachments visible in raw view] — view raw

Than you for the thoughtful reply.

Yes the apt upgrade submit ends there with no further error messages. When
moving that source list it proceeds and asks me if i want to install the
upgrades.

Please help me to understand the MITM scenario. So you're saying an
attacker could be able to redirect all sources except one? Is that even
technically likely? Has that ever happened?

I appreciate you explaining the risk, as I'm trying to understand why.
Please understand that this also prevents unattended upgrades from
proceeding, which aside from a real indication of MITM attack seems like
unnecessarily putting many systems at a security risk. (Also, shouldn't
https be used by default in the main sources list that includes security
repos? Doesn't https prevent MITM?)


Re space checking: I understand estimates are inaccurate. But it seems
better to fail on the side of caution in this instance. To be clear, I'm
not expecting to make waves for so many other users, this could be rolled
out with a flag option like (--check-space). I do think opt out should be
the default though.

I know there are separate partitions, but doesn't the estimation look at
say /boot when a kernel is queued for install? If it knows where to install
packages, it can check those exact locations for free space. (But still
imho better to fail by default)

I would take the conservative side of the estimate, as I've said the
uninstall process can be very complicated, especially when inside a VM with
no other space available. Usually means manually deleting files that upsets
dpkg and then having to reconfigure all that first before making apt happy
again.

I think 1.5GB is reasonable. Doesn't the filesystem not have to be
uncompressed to install? Wouldn't it already be uncompressed during apt
use?

I understand about rolling out in a way to see what possible problems arise
before implementing defaults.


Thank you


On Mon, Oct 10, 2022, 6:56 AM David Kalnischkies <david@kalnischkies.de>
wrote:

> On Sun, Oct 09, 2022 at 01:21:45PM -0700, xaq xaq wrote:
> > To simplify a frequently seen halt of `apt upgrade` I have this
> example.. I
> > had to remove keepsolidinc.list
> > from /etc/apt/sources.list.d. Then apt update proceeds. Here is the
> error I
> > get with that source list in place:
> >
> > *Hit:1 http://archive.ubuntu.com/ubuntu
> > <http://archive.ubuntu.com/ubuntu> - InRelease
> > Hit:2 http://security.ubuntu.com/ubuntu
> > <http://security.ubuntu.com/ubuntu> --security InRelease
> > Hit:3 http://archive.ubuntu.com/ubuntu
> > <http://archive.ubuntu.com/ubuntu> --updates InRelease
> > Hit:4 http://archive.ubuntu.com/ubuntu
> > <http://archive.ubuntu.com/ubuntu> --backports InRelease
> > Ign:5 http://apt.keepsolid.com/ubuntu
> > <http://apt.keepsolid.com/ubuntu> - InRelease
> > Err:6 http://apt.keepsolid.com/ubuntu
> > <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
> > <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.*
>
> What do you mean with "halt of `apt upgrade`"? You have shown us output
> of 'apt update'? And that output suggests that the other archives were
> updated (just that they were already current: cache "Hit").
>
> I suppose if the old data still on disk for keepsolid is indicating
> newer versions of packages than you have installed an upgrade would try
> to download them potentially running also into 404 errors (assuming this
> repo is entirely offline). That would indeed "block" upgrades of other
> packages not from that repo, but what is apt supposed to do instead…
> It is asked to upgrade all packages and can't: Partial upgrades are
> technically supported, but hardly tested in practice as it is
> a combinatorial explosion if you tried. So in theory you upgrade from
> a perfectly supported system with updates available to a system with
> unknown support status and still more updates available. That doesn't
> look like a good default move.
>
> You can tell apt to carry on with --fix-missing if that is what you
> desire, but really, you should either remove that repository (and the
> packages coming from it) for good or work with its provider on fixing
> it/making it available again. After all, --fix-missing lets you carry
> on in a pinch, but it remains that the repository fails to serve updates
> to you, which in the worst case means public known security issues remain
> exploitable on your system.
>
> (This could be part of an attack. It usually isn't, but it is
>  indistinguishable from a MITM blocking access to a repository so
>  that you can not get the security updates the attacker wants to
>  exploit. There are better ways, hence its unlikely, but it is just
>  a less good way as it shows errors grabbing attention that something
>  is wrong. If apt wouldn't, this would be really easy to use.)
>
> > For the size estimation, I understand it is an estimation, and there
> could
> > be guesswork, but I would posit that if the estimate is even roughly
> > correct, a user most likely will not want to proceed, because the
> > consequences greatly outweigh the benefits of proceeding.
>
> As I tried to explain already apt downloads itself at the expense of 1.5
> MB. It will take up installed 4.5 MB. It hardly changes size from
> version to version, so more space freed/used after the upgrade amounts
> to more or less 0 MB. Running and using apt requires additional data
> which easily takes up 200 MB. Lets assume every package is similar to
> apt (they aren't, you e.g. have things like texlive which comes in a
> couple hundred MBs of download already). A typical upgrade can contain
> more than 1000 packages, so which value between 0 and 200 GB are we
> gonna use as a rough estimate for that upgrade? And again, which
> partitions are we gonna talk about if you have multiple, like e.g.
> a separate /boot ?
>
> APT in this scenario picks 1.5 GB (the size it will need to download all
> the packages) on the partition housing its download location:
> apt's free space check for the download is done against free blocks
> available for everyone. In a default configuration root has an additional
> 5% of a partition as free space available for their exclusive use.
>
> If your idea is that lets say apt should not continue if you don't have
> 100 MB free on /boot and 5 GB on / (should be enough, right?) that is
> fine for your system and pretty easy to implement with e.g. a
> dpkg::pre-invoke hook (no need for the heavier dpkg::pre-install-pkgs
> hook). That wont work in the general case though… there are systems
> which don't even have 5 GBs of disk space to begin with.
>
> (Did you think apts 1.5 GB is a reasonable low bound? For some people
>  that is already way too high! Like if your filesystem supports
>  compression)
>
>
> That script you could package up and make available for everyone who
> needs it. Probably with config knobs to specific sizes. Probably with
> more iterations as people come up with pretty interesting partition
> schemes if you give them the option to… perhaps indeed moving to a
> pre-install-pkgs hook later on to make better guesses at what a given
> upgrade might need (install of two packages, probably fine… upgrading
> 2000 package ~ now we are talking!) …
>
> If a few months down the line we discover that there is indeed a setup
> which works for – lets say – 95% of Debian users we can always set it
> to prio:standard and install it by default or integrate it into apt
> so (basically) everyone gets it everywhere, but until then it is more
> beneficial for you and us if we are not burdening ourselves with
> making it work for everyone from day 1.
>
>
> Best regards
>
> David Kalnischkies
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web