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

Groups > linux.debian.user > #197430 > unrolled thread

Buster and apt wanting to remove tons of packages...

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

Contents

  Buster and apt wanting to remove tons of packages... sgarrulo <sgarrulo@gmail.com> - 2018-07-10 13:00 +0200
    Re: Buster and apt wanting to remove tons of packages... Joe <joe@jretrading.com> - 2018-07-10 15:10 +0200
      Re: Buster and apt wanting to remove tons of packages... sgarrulo <sgarrulo@gmail.com> - 2018-07-11 18:20 +0200
        Re: Buster and apt wanting to remove tons of packages... Greg Wooledge <wooledg@eeg.ccf.org> - 2018-07-11 18:50 +0200
    Re: Buster and apt wanting to remove tons of packages... Roberto C. Sánchez <roberto@debian.org> - 2018-07-10 15:50 +0200
    Re: Buster and apt wanting to remove tons of packages... Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-07-10 15:50 +0200
    Re: Buster and apt wanting to remove tons of packages... The Wanderer <wanderer@fastmail.fm> - 2018-07-10 16:20 +0200
      Re: Buster and apt wanting to remove tons of packages... Hans <hans.ullrich@loop.de> - 2018-07-10 16:40 +0200
        Re: Buster and apt wanting to remove tons of packages... sgarrulo <sgarrulo@gmail.com> - 2018-07-11 18:30 +0200
      Re: Buster and apt wanting to remove tons of packages... sgarrulo <sgarrulo@gmail.com> - 2018-07-11 18:20 +0200
    Re: Buster and apt wanting to remove tons of packages... Jochen Spieker <ml@well-adjusted.de> - 2018-07-10 22:10 +0200
      Re: Buster and apt wanting to remove tons of packages... Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-07-11 18:20 +0200
        Re: Buster and apt wanting to remove tons of packages... Joe <joe@jretrading.com> - 2018-07-11 22:50 +0200
          Re: Buster and apt wanting to remove tons of packages... Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-07-12 17:40 +0200
        Re: Buster and apt wanting to remove tons of packages... Jochen Spieker <ml@well-adjusted.de> - 2018-07-12 09:50 +0200
      Re: Buster and apt wanting to remove tons of packages... sgarrulo <sgarrulo@gmail.com> - 2018-07-11 18:30 +0200

#197430 — Buster and apt wanting to remove tons of packages...

Hello everyone!
I had an installation of debian stable (stretch) which was fully upgraded something
like a couple of months ago. Then I passed it to testing (buster).

Now I'm facing this situation:
* 5031 installed packages
* 1292 upgradable packages

If I do a normal upgrade, 676 packages are to be upgraded, but only the gtk/qt unrelated ones
(for example, apache2-doc but none of the apache2 *real* packages, or vim-addon-manager and vim-doc
but none of the vim *real* packages, and so on)

And if I try to upgrade, let's say, vim-* packages, it wants to remove a ton of seemingly unrelated
packages, like calibre, evolution, gir1.2-*, gstreamer things, kid3, libqt5-*, pidgin, vlc-*, etc etc...

This happens when I try to upgrade or install apparently *anything* related to GUI programs (GTK/Qt related).

I am worried to make an upgrade like that.

What can I do to debug this situation and try to understand which package(s) is/are breaking everything?

I have no pinned packages.

Thank you in advance!

[toc] | [next] | [standalone]

#197437

On Tue, 10 Jul 2018 12:55:26 +0200
sgarrulo <sgarrulo@gmail.com> wrote:

> Hello everyone!
> I had an installation of debian stable (stretch) which was fully
> upgraded something like a couple of months ago. Then I passed it to
> testing (buster).
> 
> Now I'm facing this situation:
> * 5031 installed packages
> * 1292 upgradable packages
> 
> If I do a normal upgrade, 676 packages are to be upgraded, but only
> the gtk/qt unrelated ones (for example, apache2-doc but none of the
> apache2 *real* packages, or vim-addon-manager and vim-doc but none of
> the vim *real* packages, and so on)
> 
> And if I try to upgrade, let's say, vim-* packages, it wants to
> remove a ton of seemingly unrelated packages, like calibre,
> evolution, gir1.2-*, gstreamer things, kid3, libqt5-*, pidgin, vlc-*,
> etc etc...
> 
> This happens when I try to upgrade or install apparently *anything*
> related to GUI programs (GTK/Qt related).
> 
> I am worried to make an upgrade like that.
> 
> What can I do to debug this situation and try to understand which
> package(s) is/are breaking everything?
> 
> I have no pinned packages.
> 

It's probably not a single package. I run an unstable workstation, this
sort of thing is not that unusual. Whole subsystems get upgraded, such
as GTK or the kf5 stuff, but not everything is ready at once. Also, many
applications dependent on this subsystem have precise dependencies
specified, and are not happy with the new libraries. Those applications
have to be upgraded, not necessarily to change them, but to mark them as
compatible with the new libraries after testing. So a major change can
require hundreds of dependent packages to be revised. This kind of
thing never happens in stable, but is fairly common in testing and
unstable.

What I do is to temporarily switch from upgrade-system to Synaptic. It
is relatively quick to select a few innocent-looking packages from the
big list, and check that they go through without a problem. After a few
tries, you can see where the trouble is, and leave those packages at
the current state. People comfortable with the aptitude interactive
interface can do the same there, but for some reason, I prefer
Synaptic. Generally the state of difficulty lasts only a few days,
though it can go on for a week or two sometimes. 

It's the price you pay for having more up-to-date software than stable
has. At the point of release of a new Debian stable, testing is
identical to it. At the time of the next release, about two years
later, testing is very different, many changes of architecture of major
systems having been made. If you use testing or unstable over this
period, you have to ride out these upheavals, hoping that nothing
important breaks. About eighteen months after release, testing is
frozen for bug fixing before the next release, and the ride is much
smoother after that. It's quieter in unstable as well, since unstable
has to be kept in a condition where it can be copied into testing after
the release occurs, so changes to unstable have to be kept within
limits. All hell breaks loose at release time...

-- 
Joe

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

#197504

On Tue, 2018-07-10 at 14:08 +0100, Joe wrote:
> 
> What I do is to temporarily switch from upgrade-system to Synaptic. It
> is relatively quick to select a few innocent-looking packages from the
> big list, and check that they go through without a problem. After a few
> tries, you can see where the trouble is, and leave those packages at
> the current state. People comfortable with the aptitude interactive
> interface can do the same there, but for some reason, I prefer
> Synaptic. Generally the state of difficulty lasts only a few days,
> though it can go on for a week or two sometimes.

I also tend to do something like that, but I'm worried that upgrading like
this can broke things badly, especially when upgrading shared libraries, or
some (but not all) packages related to a program. For example, I don't know..
Situation like "yeah, I'll upgrade my terminal because it's harmless", and then
it stops working because I did not upgrade also lib-foo-bar-baz which is used
by my terminal. So let's upgrade lib-foo-bar-baz! but I cannot upgrade it now
because trying to upgrade it wants to remove a ton of other software that I use.
And maybe I cannot install another terminal either because it's GUI software,
which installation triggers all the cascade of removal of other things, etc etc
etc...

You can say "no, something like that cannot happen" but Murphy's law is
always right behind the corner.

> It's the price you pay for having more up-to-date software than stable
> has. At the point of release of a new Debian stable, testing is
> identical to it. At the time of the next release, about two years
> later, testing is very different, many changes of architecture of major
> systems having been made. If you use testing or unstable over this
> period, you have to ride out these upheavals, hoping that nothing
> important breaks. About eighteen months after release, testing is
> frozen for bug fixing before the next release, and the ride is much
> smoother after that. It's quieter in unstable as well, since unstable
> has to be kept in a condition where it can be copied into testing after
> the release occurs, so changes to unstable have to be kept within
> limits. All hell breaks loose at release time...

Yes, I know the basics of Debian release cycle. I had sid and testing on
this computer before. When the freeze approaches I keep $codename (of the
to-be-released stable distribution) in my sources.list and keep my machine
on stable for some time after the release. But I thought that 2018's spring/summer
was enough time after the release of stretch to try and be on testing again...

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

#197510

On Wed, Jul 11, 2018 at 06:12:45PM +0200, sgarrulo wrote:
> Situation like "yeah, I'll upgrade my terminal because it's harmless", and then
> it stops working because I did not upgrade also lib-foo-bar-baz which is used
> by my terminal.

That exact situation would be a bug, and should be reported.  That's
the sort of thing Debian wants to hear from testing/unstable users,
so they can fix the dependency bugs.

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

#197440

On Tue, Jul 10, 2018 at 09:39:44AM -0400, Cindy-Sue Causey wrote:
> 
> Hi.. Been there, done that, filed a bug, got fussed at, vented here at
> Debian-User. Moral of the Story: I don't file ANY BUGS anymore. I
> spend that time advocating important subjects related to #Life
> instead. lol!
> 
Sadly, that does happen from time to time.  I am sorry if you had a bad
experience.  Still, I would like to encourage you and everyone else to
continue filing bugs.  Most Debian package maintainers are very
responsive and try to maintain high quality for their packages.  The bug
reports from users help improve that process.

Regards,

-Roberto
-- 
Roberto C. Sánchez

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

#197441

On 7/10/18, sgarrulo <sgarrulo@gmail.com> wrote:
> Hello everyone!
> I had an installation of debian stable (stretch) which was fully upgraded
> something
> like a couple of months ago. Then I passed it to testing (buster).
>
> Now I'm facing this situation:
> * 5031 installed packages
> * 1292 upgradable packages
>
> If I do a normal upgrade, 676 packages are to be upgraded, but only the
> gtk/qt unrelated ones
> (for example, apache2-doc but none of the apache2 *real* packages, or
> vim-addon-manager and vim-doc
> but none of the vim *real* packages, and so on)
>
> And if I try to upgrade, let's say, vim-* packages, it wants to remove a ton
> of seemingly unrelated
> packages, like calibre, evolution, gir1.2-*, gstreamer things, kid3,
> libqt5-*, pidgin, vlc-*, etc etc...
>
> This happens when I try to upgrade or install apparently *anything* related
> to GUI programs (GTK/Qt related).
>
> I am worried to make an upgrade like that.
>
> What can I do to debug this situation and try to understand which package(s)
> is/are breaking everything?
>
> I have no pinned packages.
>
> Thank you in advance!


Hi.. Been there, done that, filed a bug, got fussed at, vented here at
Debian-User. Moral of the Story: I don't file ANY BUGS anymore. I
spend that time advocating important subjects related to #Life
instead. lol!

What you experienced is one aspect of the design of how package
upgrades work. As you saw in your case, overriding by manually
installing ("cherry picking") Developer-held packages can be dangerous
for the health of your current install.

Those packages have been held back for a reason. I still don't fully
grasp why those packages even show in our face. I a-sume it's just
somehow part of the system of erasing certain to-do's on a development
checklist to help keep the perpetual upgrade process moving onward and
upward.

I just deleted a bunch of other junk I wrote to instead ask an
important question that might help others help you:

What path did you take to upgrade to where you are this second?

Me? I zap mine and start over via debootstrap because it's just more
"cognitively friendly" *for me*. Others go some version of the
"apt-get dist-upgrade" route which is trustworthy and viable.

Simply changing things, e.g. /etc/apt/sources.list, to point to a
higher or lower distribution, not so much. That sometimes starts a
ticking time bomb toward almost inevitable self-destruction. ALSO been
there, done THAT a very long time ago. *NEVER... EVER... AGAIN!* :D

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

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

#197445

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

On 2018-07-10 at 06:55, sgarrulo wrote:

> Hello everyone!
> I had an installation of debian stable (stretch) which was fully 
> upgraded something like a couple of months ago. Then I passed it to
> testing (buster).
> 
> Now I'm facing this situation:
> * 5031 installed packages
> * 1292 upgradable packages
> 
> If I do a normal upgrade, 676 packages are to be upgraded, but only
> the gtk/qt unrelated ones (for example, apache2-doc but none of the
> apache2 *real* packages, or vim-addon-manager and vim-doc but none of
> the vim *real* packages, and so on)
> 
> And if I try to upgrade, let's say, vim-* packages, it wants to
> remove a ton of seemingly unrelated packages, like calibre,
> evolution, gir1.2-*, gstreamer things, kid3, libqt5-*, pidgin, vlc-*,
> etc etc...
> 
> This happens when I try to upgrade or install apparently *anything*
> related to GUI programs (GTK/Qt related).
> 
> I am worried to make an upgrade like that.
> 
> What can I do to debug this situation and try to understand which
> package(s) is/are breaking everything?

If I were experiencing a similar situation, what I'd do is try to
simultaneously install both one of the packages that triggers the
cascade and one or more of the packages which the cascade wants to
remove, and keep adding packages to the install command until I get a
dependency-resolution failure.

E.g., assuming that trying to upgrade 'vim' triggers the cascade and the
cascade wants to remove calibre, evolution, and pidgin:

$ apt-get install vim calibre evolution pidgin

(In case it wasn't obvious: an 'install' operation on an
already-installed package which has a newer available version triggers
an install of that newer version, i.e., an upgrade.)

If you get a successful upgrade attempt which doesn't trigger the
cascade, you can let it proceed, then try the mass upgrade again. If the
mass upgrade still produces the cascade, you can repeat the
some-small-subset-of-packages manual install process.

If on the other hand the manual install command *does* trigger the
cascade, you should cancel it and add more package names to the install
command.

Keep repeating those two until either the cascade disappears from the
mass-upgrade attempt, or you get a "request cannot be fulfilled"
dependency-resolution failure.

If the cascade disappears along the way, you're in good shape; just
complete the mass upgrade. (Unfortunately, this doesn't really help
figure out what caused the bug in the first place.)

If you get a dependency-resolution failure, the packages involved should
give you a hint about which packages have dependency relationships which
are leading to the cascade.

The next step involves looking at those packages and their dependency
relationships, and I can't describe the process very well without a
real-world example to hand.

Once you've identified the dependency relationship which resulted in the
cascade, it's probably fairly straightforward to determine what bug
report to file and what package to file it against.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#197447

Please also note, tzhat there is a difference, between using apt (apt-get) and 
aptitude.

The way, I prefewr, is using apt-get upgrade (which installs only newer 
packages, and let the problematic ones uninstalled), then using apt-get full-
upgrade.

When there are packages deinstalled, reinstall them afterwards.

I know, this is not the best way. 

As itr was mentioned before: Using aptitude (tzhe ncurses gui) can show you, 
which packages are causing trouble. You can set them to hold (aptitude hold 
packagename) and then analyse, what dependencies are causing the trouble.

One package after the other. Yes, it  is annoying, I agree.

Hope this helps still....

Best regards

Hans

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

#197505

On Tue, 2018-07-10 at 16:29 +0200, Hans wrote:
> Please also note, tzhat there is a difference, between using apt (apt-get) and 
> aptitude.
> 
> The way, I prefewr, is using apt-get upgrade (which installs only newer 
> packages, and let the problematic ones uninstalled), then using apt-get full-
> upgrade.
> 
> When there are packages deinstalled, reinstall them afterwards.
> 
> I know, this is not the best way. 
> 
> As itr was mentioned before: Using aptitude (tzhe ncurses gui) can show you, 
> which packages are causing trouble. You can set them to hold (aptitude hold 
> packagename) and then analyse, what dependencies are causing the trouble.
> 
> One package after the other. Yes, it  is annoying, I agree.
> 
> Hope this helps still....
> 
> Best regards
> 
> Hans

Thank you for your hint, I never used aptitude, so I think I have to RTFM about
it and see if it helps me in my situation :)

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

#197503

On Tue, 2018-07-10 at 10:13 -0400, The Wanderer wrote:
> If I were experiencing a similar situation, what I'd do is try to
> simultaneously install both one of the packages that triggers the
> cascade and one or more of the packages which the cascade wants to
> remove, and keep adding packages to the install command until I get a
> dependency-resolution failure.
> 
> E.g., assuming that trying to upgrade 'vim' triggers the cascade and the
> cascade wants to remove calibre, evolution, and pidgin:
> 
> $ apt-get install vim calibre evolution pidgin
> 
> (In case it wasn't obvious: an 'install' operation on an
> already-installed package which has a newer available version triggers
> an install of that newer version, i.e., an upgrade.)
> 
> If you get a successful upgrade attempt which doesn't trigger the
> cascade, you can let it proceed, then try the mass upgrade again. If the
> mass upgrade still produces the cascade, you can repeat the
> some-small-subset-of-packages manual install process.
> 
> If on the other hand the manual install command *does* trigger the
> cascade, you should cancel it and add more package names to the install
> command.
> 
> Keep repeating those two until either the cascade disappears from the
> mass-upgrade attempt, or you get a "request cannot be fulfilled"
> dependency-resolution failure.
> 
> If the cascade disappears along the way, you're in good shape; just
> complete the mass upgrade. (Unfortunately, this doesn't really help
> figure out what caused the bug in the first place.)
> 
> If you get a dependency-resolution failure, the packages involved should
> give you a hint about which packages have dependency relationships which
> are leading to the cascade.

This seems like a long work, but it's a path I did not think about, maybe
I'll try this steps, thank you for the hint!

> The next step involves looking at those packages and their dependency
> relationships, and I can't describe the process very well without a
> real-world example to hand.

Yes, I know, but listing the hundreds and hundreds of packages involved
can be annoying for the mailing list... :)

> Once you've identified the dependency relationship which resulted in the
> cascade, it's probably fairly straightforward to determine what bug
> report to file and what package to file it against.

If I'll manage to point the finger to the package that triggers all this mess,
I'll do a bug report.

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

#197461

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

sgarrulo:
>
> I had an installation of debian stable (stretch) which was fully upgraded something
> like a couple of months ago. Then I passed it to testing (buster).

There should not be that many changes, but I generally would only
upgrade to a newer release when the current system is up-to-date with
regards to its current version.

> If I do a normal upgrade, 676 packages are to be upgraded, but only the gtk/qt unrelated ones
> (for example, apache2-doc but none of the apache2 *real* packages, or vim-addon-manager and vim-doc
> but none of the vim *real* packages, and so on)

I would start with that, if only to get these packages out of the way.

> And if I try to upgrade, let's say, vim-* packages, it wants to remove a ton of seemingly unrelated
> packages, like calibre, evolution, gir1.2-*, gstreamer things, kid3, libqt5-*, pidgin, vlc-*, etc etc...
> 
> This happens when I try to upgrade or install apparently *anything* related to GUI programs (GTK/Qt related).

You can use aptitude's TUI to investigate these things. It should at
least help explain why this happens. It is very possible (or likely),
that testing is just in bad shape for this upgrade right now.

(And no, reporting this as a bug is of no help here because the Debian
release process is not designed to support what you are trying to do at
a random point in time.)

> I am worried to make an upgrade like that.

Rightly so.

> What can I do to debug this situation and try to understand which package(s) is/are breaking everything?

Aptitude. I do not like how it behaves and how you control it, but for
this kind of investigation it is without alternative. Instead of the TUI
you can also use 'aptitude why' and 'aptitude why-not'.

J.
-- 
People talking a foreign language are romantic and mysterious.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

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

#197502

On Tue, Jul 10, 2018 at 3:01 PM Jochen Spieker <ml@well-adjusted.de> wrote:
>
> There should not be that many changes, but I generally would only
> upgrade to a newer release when the current system is up-to-date with
> regards to its current version.

I'm trying to understand your recommendation. It seems you advise to
bring the system to the most
recent update in the current release, FOLLOWED BY the upgrade to the
new release. Richtig? Correct?

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

#197519

On Wed, 11 Jul 2018 11:18:48 -0500
Nicholas Geovanis <nickgeovanis@gmail.com> wrote:

> On Tue, Jul 10, 2018 at 3:01 PM Jochen Spieker <ml@well-adjusted.de>
> wrote:
> >
> > There should not be that many changes, but I generally would only
> > upgrade to a newer release when the current system is up-to-date
> > with regards to its current version.  
> 
> I'm trying to understand your recommendation. It seems you advise to
> bring the system to the most
> recent update in the current release, FOLLOWED BY the upgrade to the
> new release. Richtig? Correct?
> 

For a version upgrade, yes, this is Standard Operational Practice. The
main reasoning is that the upgrade has been tested in that way i.e.
from the final version of everything in the old distribution, and has
not been tested from earlier software versions.

Also, most of the upgrade instructions involve tidying up the old
system, unholding anything held, ideally removing anything which isn't
part of the old distribution, etc. Upgrading everything to the latest
version fits into this tidying theme.

Finally, if upgrading the old system revealed a bug and broke
something, it will be easier to fix within a familiar system, and a
good idea to do so before the version upgrade.

So, no, you don't have to, but yes, it is recommended.

-- 
Joe

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

#197556

On Wed, Jul 11, 2018 at 3:42 PM Joe <joe@jretrading.com> wrote:
> For a version upgrade, yes, this is Standard Operational Practice. The
> main reasoning is that the upgrade has been tested in that way i.e.
> from the final version of everything in the old distribution, and has
> not been tested from earlier software versions.

OK thanks. I didn't actually know that, but for a long time my
practice (at work)
is complete re-installation rather than upgrade.

> Finally, if upgrading the old system revealed a bug and broke
> something, it will be easier to fix within a familiar system, and a
> good idea to do so before the version upgrade.

Yes, thanks for the "fine print". And don't forget to point out that one might
actually want to try things out on the upgraded system before the
version upgrade.
Not just reboot and resume upgrading. Instead really try-out things
before the upgrade ;-)
As I have experienced first-hand ;-)

> So, no, you don't have to, but yes, it is recommended.
>
> Joe

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

#197532

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

Nicholas Geovanis:
> On Tue, Jul 10, 2018 at 3:01 PM Jochen Spieker <ml@well-adjusted.de> wrote:
>> 
>> There should not be that many changes, but I generally would only
>> upgrade to a newer release when the current system is up-to-date with
>> regards to its current version.
> 
> I'm trying to understand your recommendation. It seems you advise to
> bring the system to the most
> recent update in the current release, FOLLOWED BY the upgrade to the
> new release. Richtig? Correct?

Correct.

J.
-- 
Scientists know what they are talking about.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

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

#197506

On Tue, 2018-07-10 at 22:00 +0200, Jochen Spieker wrote:
> sgarrulo:
> > 
> > I had an installation of debian stable (stretch) which was fully upgraded something
> > like a couple of months ago. Then I passed it to testing (buster).
> 
> There should not be that many changes, but I generally would only
> upgrade to a newer release when the current system is up-to-date with
> regards to its current version.

Ops, I think I made myself not as clear as I thought, sorry... (english is not my mothertongue)
I meant that a couple of months ago, my machine was on stable, and fully up to date. Then one day,
two months ago, when my machine was fully up to date to stable, I made the switch to testing, because
Being passed many months since the release of stretch, I thought that the hurricane (that happens right
after the release of a new stable) in testing was passed. Oh boy how I was wrong... :P

> You can use aptitude's TUI to investigate these things. It should at
> least help explain why this happens. It is very possible (or likely),
> that testing is just in bad shape for this upgrade right now.

I never used aptitude, but I think I'll RTFM and try to understand the situation better

> Aptitude. I do not like how it behaves and how you control it, but for
> this kind of investigation it is without alternative. Instead of the TUI
> you can also use 'aptitude why' and 'aptitude why-not'.
> 

Thank you, I'll do it!

[toc] | [prev] | [standalone]

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

csiph-web