When viewing upgradable packages, one can use the `C' key (that is,
Shift + C) to download and view the changelog.  While the changelog is
downloading, both `q' and ^C (Control + C) terminate aptitude
altogether; it seems there is no way to cancel the download of a
changelog.

# Automatically generated email from bts, devscripts version 2.10.13
# A real bug, not just a feature request; cannot do other operations while changelog attempts to download
severity 438495 normal

Hi,

2007-08-17 13:28 Trent W. Buck:

2008-01-13 09:07 Josh Triplett:

Can you please confirm me if what you observed is still happening with
recent versions?  I's been quite a long time since the report and the
follow-up.

I am on a very slooooow connection, but even then the (and when
changelog is not on disk already) package changelog downloads so fast
that I cannot press 'q' before it downloads, except in a couple of
occasions.  Even with old packages (== assuming big changelog files) it
takes fractions of a second.

Sometimes when pressing 'q', it seems to want to quit aptitude rather
than cancel the changelog (but there is the confirmation dialog).
However, assuming that in your case it's just very slow downloading the
changelog, I think that one can press F6 and cycle to another view and
continuing working there for a few seconds, as a workaround.

To be honest, I am not sure if it's even a good idea to implement this
request, since I think the download happens in a background thread and
only creates the view (the one reacting to 'q') once the changelog is
ready.  So it's not a matter of simply connecting the 'q' event with
cancelling the download; perhaps it needs shuffling some code around and
creating new menus or keystrokes, that then need new messages and
translations and documentation, and I am not sure if the problem is so
inconvenient as to be worthwile?

But maybe I am missing your use-case and why it's so annoying, please
explain.


Cheers.

Usually it's more of a connectivity issue; it doesn't take long to
download once it starts, but occasionally I've had it take a long time
to *start* getting data over the connection.  Latency, perhaps.

What made it annoying is that while the changelog downloads, aptitude
blocks many other operations, just as it blocked operations while
downloading packages ("You may not modify the state of any package while
a download is underway.")

However, I can't seem to reproduce *that* part of the problem anymore.
Has aptitude changed to allow background downloads of changelogs without
blocking package state changes?  If so, then I think that brings this
bug back to wishlist at most.

- Josh Triplett

2015-09-21 21:25 GMT+01:00  <josh@freedesktop.org>:

I tried to disconnect, but in that case the name resolution fails
right away.  I guess that the worst case is if DNS is slow or the
connection is slow to start, as you say.

The message for downloads is still there, but one can stop the downloads.

The relevant changes in this area are:

[2009-11-18]
Version 0.6.1                               "Instant toll logging."
  + [all] aptitude now has a generic global download queue.  This is
          actually implemented with the apt download queue object, but
          it runs all downloads in the background, integrates with
          aptitude's download cache, and provides support for getting
          status information on individual downloads and canceling
          them.

[2010-01-17]
Version 0.6.1.4                             "You can't take the sky from me."
  + [all] Download changelogs using the new internal download queue,
          not the download_manager system.  Fixes random crashes at
          shutdown.


Cheers.

If you want to WONTFIX or close this bug, I don't object. :-)
Boring discussion follows.

Manuel A. Fernandez Montecelo wrote:

    Open aptitude TUI,
    select a package,
    hit C,
    then hit q (aptitude offers to quit) or hit ^C (aptitude quits).

When I pressed q, the bottom line of the TUI reported:
    Preparing to download the changelog of ganeti-haskell-2.15 ... 2%
so I assume the download was in progress.

IIRC it was noticable for me because changelogs were downloaded from debian.org, not a local mirror.
In Australia that meant they took a loooong time.

Right now on sid it takes about 1s for a package with a short changelog (haskell-zeromq4-haskell),
and about 4s for a package with a long changelog (vim).

I do not really care about this bug anymore -- especially since, as
you say, it is possible to continue working in the existing aptitude
tab (view?) while the changelog downloads.

IIRC what used to happen was I'd hit <right arrow> by mistake,
which sent ^[[C and aptitude would start downloading a changelog,
and it was in the foreground but I couldn't cancel it,
so effectively I was locked out of aptitude for a decasecond or two.

That doesn't seem to be the case anymore :-)

If you want to WONTFIX or close this bug, I don't object.

2015-09-22 1:55 GMT+01:00 Trent W. Buck <trentbuck@gmail.com>:

With vim also takes a while for me, also about 3-4 seconds.  I am
wondering if part of that time is not reading the chanlog and doing
some processing, like converting lists to be more visually appealing,
but in the end the problem is not different in this case.

Yes, the new tab/view is not created until the changelog is ready to
be shown (be that download, parsing or rendering).

With vim I managed to click '+' on a package and getting the resolver
to mark it as broken in before the window of the changelog was shown,
so now it is possible to use aptitude normally.

I can see how that was definitely annoying, yes :-)

With the window in the foreground I think that it would have been
easier to solve this by cancelling the action with 'q', that is, to
honour your request.

With the window not visible now, the solution would almost surely
involve menu actions (that might take longer to reach than the
download itself), or shortcuts (of which there are many already taken
and it's more and more difficult to find sensible keys for common
actions); and people are unlikely to even learn about this shortcut if
not in the menu.

These solutions are much more costly in terms of implementation
(specially in areas of documentation, screenshots and translations)
than creating the code for cancelling and connecting the signal of 'q'
with the cancelling action.

As I said in the a previous message and above in this message, with
the current less-annoying behaviour, the effort needed to implement
this (ost of the effort would not even immediate/by-me --e.g.
translations--, but still I think that it's worth considering), and
specially the long list of aptitude problems, I think that it's better
to spend time in other problems with higher impact or more common
complaints (this was not seconded since Josh in 2008).

I think that it is still a potential problem, or one that people might
want to report, e.g. because the new window interrupts you when
opening, so better to leave it as +wontfix, at least for now.  Maybe
there's the opportunity to implement it in the future as part of
"cancelling all network actions" or similar; or somebody wants to
implement this.

Thanks both for reporting and replying after such a long time!

Changing severity and tags, forgot in previous message.