Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> Control: reopen -1
> Control: fixed -1 aptitude/0.7.7-1

Doing this is not really a good thing IMHO. That bug is fixed in
unstable and has a severity level (normal) which usually doesn't get
fixed in stable after the release anymore.

> >What bugs me is closing a bug that is neither fixed (in stable) nor
> >(going to get) documented anywhere. It's just going to get archived

That's expected. Bugs fixed in unstable and having a severity below
"important" are archived automatically. Only bugs of the severity
"important" or higher are not automatically closed, if they also apply
to a supported release of Debian as far as I remember.

> >and then it won't even show up in reportbug anymore.

reportbug is not authorative. The BTS is. And the BTS allows you to
also search for archived bug reports.

If you dislike that reportbug doesn't show archived bug reports which
still apply to the release you're using, then please file a bug report
against report bug, not against packages of maintainers which use the
BTS as intented.

> >This is not the first bug I've come across in the last few weeks that
> >turned out to be a possible dupe of a months-old archived report, with
> >or without any indication that it still affected the current stable

Yes, as explained above, that's expected. Use the BTS and search also
for archived bug reports if you look for low-severity bug reports
which are fixed in unstable, but still may affect stable or oldstable.

> Anyway... leaving the above aside...  If we close the bug with fixed
> version 0.7.7-1 for example, I think that it will appear in reportbug
> (when reporting from a system with < 0.7.7-1 installed),

Does reportbug check which bug is fixed with which version? I doubt
it. But then again, I use the BTS, not reportbug to query bug reports.

> and it will also appear in some views of the BTS (when selecting
> "dist=stable", for example)

I think you will still have to explicitly query archived bugs if you
want to see low-severity bugs already fixed in unstable.

> -- but I think that the view in BTS is to show unstable by
> default.

Yes, it does if you use the shortcuts, e.g.
http://bugs.debian.org/aptitude it redirects to
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=aptitude;dist=unstable

> >In my ideal world this bug would be marked "wontfix" for all versions
> >of aptitude known to be affected (but otherwise kept from being
> >archived as long as an affected version is supported) and "fixed in"
> >for the earliest version known not to be. I'd thought the BTS could do
> >this, but perhaps not. What do I know, I'm just a user. Also a
> >/usr/share/doc/*/ERRATA.Debian containing short summaries of all known
> >issues that won't be fixed in the current branch would be nice. The
> >bug numbers and subjects would do, as long as the latter are
> >descriptive.
> 
> One of the problems with this is that, most of the time, I don't even
> have the means to test if the bug was present in stable, simply because
> I don't have other machines around.  Only when I have access to the
> computer of other friends/family with stable installed and root access I
> can test some of these things.  And some of them require specific
> changes (configuration, a specific repository, a "state bundle" or the
> right architecture, etc) that are not trivial to reproduce.

Manuel: I usually can also test things on stable and oldstable. (No
more live running squeeze anymore since recently, though.)
Additionally I can test no more supported releases via Xen virtual
machines, if necessary. Bootstrapping such a VM usually 5-10 minutes.

I though don't think it's worth to dig that deep in nearly all cases.

>From now on, I'd only test wheezy and jessie and if I can't reproduce
something on Wheezy, I'd mark it as fixed with the version initially
in Wheezy (i.e. not the current version which might be from a
stable-update). Otherwise with the version in Jessie/Testing/Unstable,
depending on where I can't reproduce it anymore.

> Also, for some of the bugs that I tried to reproduce in the 0.7.x
> series, I cannot go further back than 0.7.5-1, because that's the moment
> when apt-1.1 was released, and installing older versions of apt for
> every bug that I want to reproduce is not practical and can break my
> system.

Indeed. That's even difficult with a dedicated VM for the test and
IMHO usually not worth it. (Installing the previous stable release and
then dist-upgrading to the date the bug was reported via
snapshot.debian.org sources.list entries is possible, but very
tedious.) Compiling an older aptitude version on a current unstable
may be quicker, but less accurate.

> Finally, as more personal note...  Above all, the whole thing of bug
> triaging for a project of aptitude (and other parts of Debian) is very
> time consuming, boring and energy-draining, even in the best of the
> scenarios.  Going for a much more accurate triaging will surely impact
> other 

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[Manuel A. Fernandez Montecelo]

Control: reopen -1
Control: fixed -1 aptitude/0.7.7-1


2016-03-01 19:01 Christian Pernegger:

2016-03-01 18:53 GMT+01:00 Manuel A. Fernandez Montecelo
:

Perhaps.  But in any case, even if the underlying problem was actually a
different one, if several people cannot reproduce it in 0.7.x and there
are reasonably indications that it was fixed, it means that it's
probably fixed.


Agreed.


And more in general, if we cannot reproduce it there's not much that we
can do about it.


Also agreed, but people can (in the jessie version).


Sorry, but we don't have the resources to backport versions to Jessie,


That's perfectly understandable.

What bugs me is closing a bug that is neither fixed (in stable) nor
(going to get) documented anywhere. It's just going to get archived
and then it won't even show up in reportbug anymore.
This is not the first bug I've come across in the last few weeks that
turned out to be a possible dupe of a months-old archived report, with
or without any indication that it still affected the current stable
...


Fair enough.




In general I dislike closing bugs with "fixed" versions when I don't
know which version actually fixed it, or if it's not a bug fixed with
specific changes of aptitude that I can point to.  Among other things,
this can be misleading when triaging other bugs and trying to find
conditions that triggered it in the past, etc.  Seeing in the header
that it was "fixed" in some version and trying to find in the changelog
what changed triggered that, only to find that it didn't actually happen
at that point, is a bit frustrating, and it happened to me with aptitude
a few times already.  So as a developer, marking with "fixed" versions
when it's not accurate is actually harmful.

Another problem is that, as most software projects, it relies on other
libs (specially libapt in this case), so many of the bugs are fixed or
occasionally arise suddenly without anything changing in aptitude, but
in the supporting libraries.  When a few months or years pass, it's
difficult to know if it was fixed in the version that went to the last
stable or not.  And most of the bugs still currently open were
unatteneded for several years.

In this bug in question that we're discussing, I pointed to a possible
change that fixed it, you think that it was working fine by the time
that the other bug fixed was reported... so what then?  There are still
users of (jessie-1)-LTS...

Sometimes it's even quite difficult to know if they are present or not
/today/, but a 10 year old bug that happened once when the user was
running aptitude through PuTTy and ssh, in which the terminal was
scrambled after some keystroke, but there are no people "me-too'ing" and
the reporter doesn't reply or the address is not valid, it's not so
clear cut whether we should close it with a "fixed" version or not.  You
might think that this is an extreme example, but among the thousands of
bugs reported a good few hundred are like these; and keeping hundreds of
bugs open it's not very useful for the development of aptitude and
getting things fixed -- the trees and the forest and all that.


So, to recap, you are right about the good practice in general and for
the benefit of the users.  But consider this... aptitude had ~650 bugs
by last summer and 1000+ 3 or 4 years ago, even now has 340.  Maybe you
pay attention to duplicates, but at least among reporters of aptitude I
can assure you that many people don't -- and with so many open bug
reports I don't blame them.  The page takes 15 seconds to load (much
more a few months ago) and reportbug is impractical to search through
them in most cases.  Even if one wanted to pay attention, is very hit or
miss, because sometimes there are bugs older than 10 years which are
still valid, while there are others which are valid only for a specific
point in time, thus tagged as confirmed, when a change was made to
apt/infrastructure/archives that caused a spike... but that 2 months
later is not present anymore, and 5 years later is still opened and
"confirmed".




Anyway... leaving the above aside...  If we close the bug with fixed
version 0.7.7-1 for example, I think that it will appear in reportbug
(when reporting from a system with < 0.7.7-1 installed), and it will
also appear in some views of the BTS (when selecting "dist=stable", for
example) -- but I think that the view in BTS is to show unstable by
default.

Copying Axel, which has more experience with all these things.



In my ideal world this bug would be marked "wontfix" for all versions
of aptitude known to be affected (but otherwise kept from being
archived as long as an affected version is supported) and "fixed in"
for the earliest version known not to be. I'd thought the BTS could do
this, but perhaps not. What do I know, I'm just a user. Also a
/usr/share/doc/*/ERRATA.Debian containing short summaries of all known
issues that won't be fixed in the current branch would be nice. The
bug numbers 

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[Christian Pernegger]

2016-03-01 18:53 GMT+01:00 Manuel A. Fernandez Montecelo
:
> Perhaps.  But in any case, even if the underlying problem was actually a
> different one, if several people cannot reproduce it in 0.7.x and there
> are reasonably indications that it was fixed, it means that it's
> probably fixed.

Agreed.

> And more in general, if we cannot reproduce it there's not much that we
> can do about it.

Also agreed, but people can (in the jessie version).

> Sorry, but we don't have the resources to backport versions to Jessie,

That's perfectly understandable.

What bugs me is closing a bug that is neither fixed (in stable) nor
(going to get) documented anywhere. It's just going to get archived
and then it won't even show up in reportbug anymore.
This is not the first bug I've come across in the last few weeks that
turned out to be a possible dupe of a months-old archived report, with
or without any indication that it still affected the current stable
...

In my ideal world this bug would be marked "wontfix" for all versions
of aptitude known to be affected (but otherwise kept from being
archived as long as an affected version is supported) and "fixed in"
for the earliest version known not to be. I'd thought the BTS could do
this, but perhaps not. What do I know, I'm just a user. Also a
/usr/share/doc/*/ERRATA.Debian containing short summaries of all known
issues that won't be fixed in the current branch would be nice. The
bug numbers and subjects would do, as long as the latter are
descriptive.

Cheers,
C.

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[Manuel A. Fernandez Montecelo]

Hi,

2016-03-01 13:31 Christian Pernegger:

Hi,

I'm not so sure. For one, #570492 is ancient and for me at least the bug is
new in jessie. 


Perhaps.  But in any case, even if the underlying problem was actually a
different one, if several people cannot reproduce it in 0.7.x and there
are reasonably indications that it was fixed, it means that it's
probably fixed.

And more in general, if we cannot reproduce it there's not much that we
can do about it.



Also it being fixed "in the 0.7 series" does not help jessie
users at all.


Sorry, but we don't have the resources to backport versions to Jessie,
if that's what you expect.

Due to various circumstances that it's not worth diving into right now,
it's probably also /technically/ difficult to backport it to Jessie, for
one boost1.58 would be needed.  But I will not stop anybody from trying.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[Christian Pernegger]

Hi,

I'm not so sure. For one, #570492 is ancient and for me at least the bug is
new in jessie. Also it being fixed "in the 0.7 series" does not help jessie
users at all.

Regards,
Christian

2016-03-01 13:52 GMT+01:00 Manuel A. Fernandez Montecelo <
manuel.montez...@gmail.com>:

> Control: tags -1 - moreinfo
> Control: close -1
>
>
> 2016-02-29 21:03 matthias.hinkfo...@uni-rostock.de:
>
>>
>> [...]
>> I cannot reproduce this behaviour, when I become root before doing
>> the removal.
>>
>> In the end, this looks to me to be
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570492
>> since it involves becoming root in between the package action.
>>
>
> Thanks for the confirmation/analysis.
>
> Yes, as I said in a previous message, I also think that it's the same
> problem fixed in the 0.7 series.
>
> So closing the bug now.
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo 
>

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo
Control: close -1


2016-02-29 21:03 matthias.hinkfo...@uni-rostock.de:


[...]
I cannot reproduce this behaviour, when I become root before doing
the removal.

In the end, this looks to me to be
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570492
since it involves becoming root in between the package action.


Thanks for the confirmation/analysis.

Yes, as I said in a previous message, I also think that it's the same
problem fixed in the 0.7 series.

So closing the bug now.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[matthias.hinkfoth2]

Hi,

I enjoyed playing around with this bug.
My test setup involves google-mock as package, but I think this is
somewhat arbitrary. I chose google-mock, because no package depends
on it.

Setup:
jessie and wheezy in sources.list, amd64, package google-mock installed

1. start aptitude as a user
2. search google-mock
3. [-] (mark for removal)
4. OK (package cache read-only)
5. [g]
now the preview opens.
google-mock is to be removed,
libgtest-dev is to be removed, because no longer used
6. [g]
7. become root :-)
8. [g]
actual removal.
9. now the package view says: will use 2,187 kB of disk spac ...
10. [g]
packages to be installed: google-mock and libgtest-dev
interestingly libgtest-dev will not be automatically
installed, but manually!


I cannot reproduce this behaviour, when I become root before doing
the removal.

In the end, this looks to me to be 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570492
since it involves becoming root in between the package action.


Regards,
Matthias

Bug#814996: aptitude: purge does not "stick" the first time

[Christian Pernegger]

> So a couple of more questions...
>
> Did you just dicover this recently

I did two fresh jessie-installs in the past two months, my first (my
other Debian boxes are still on wheezy or squeeze). Both new systems
exhibit this problem and have from the beginning, the older ones do
not.

Cheers,
C.

Bug#814996: aptitude: purge does not "stick" the first time

[Manuel A. Fernandez Montecelo]

2016-02-23 18:31 Christian Pernegger:

Hello,


I cannot reproduce this behaviour.


Lucky you! I've since found out that I don't even have to quit and
restart aptitude for this to trigger:

mark package for purging, [g],[g] --> package is purged (as expected)
[g] again --> package shows up marked for installation (instead of
nothing to do message)
set package to purge again, [g] -> skips right to the finished, press
any key message,*now* it stays purged


Do you launch aptitude as user and then become root, or launch it as
root?


I launch it as user and then become root as necessary. Standard
sudo-setup as done by the installer when the option to prohibit root
login is selected.


I can reproduce it, when doing it as user.


It looks like the same problem described here, which seems to have been
fixed in the 0.7 series:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570492



How much time passes between the sessions, [...]


Doesn't matter, see above. I'm positive that no other tools are involved.


So a couple of more questions...

Did you just dicover this recently so you don't know if it happened with
older versions of aptitude?  Or otherwise, do you know if this happens
only since recently (as in, you are sure that it wasn't happening
before)?  Or you have been experiencing it for a long time but only
reported it now?



Do you have the options to automatically install Recommends or Suggests
enabled, in the system, root .aptitude/config or user .aptitude/config?


Ah, yes ... there's this conf file in /etc/apt/apt.conf.d/, meant to
disable the automatic installation of Recommends and make the UI a
little more dselect-like. I've been using it since dselect was
deprecated, but it looks innocuous enough?

Aptitude::Get-Root-Command "sudo:/usr/bin/sudo";
//Aptitude::Auto-Install "false";
Aptitude::Auto-Fix-Broken "false";
Aptitude::Recommends-Important "false";
APT::Install-Recommends "false";
Aptitude::Keep-Recommends "true";
Aptitude::Keep-Suggests "true";
Aptitude::Purge-Unused "false";

Aptitude::UI::Default-Grouping "filter(missing),status,priority,section";
Aptitude::UI::Advance-On-Action "true";
//Aptitude::Theme "Dselect";


Probably not related, but if we need to dig into the code, maybe some of
this becomes relevant.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814996: aptitude: purge does not "stick" the first time

[Christian Pernegger]

Hello,

> I cannot reproduce this behaviour.

Lucky you! I've since found out that I don't even have to quit and
restart aptitude for this to trigger:

mark package for purging, [g],[g] --> package is purged (as expected)
[g] again --> package shows up marked for installation (instead of
nothing to do message)
set package to purge again, [g] -> skips right to the finished, press
any key message,*now* it stays purged

> Do you launch aptitude as user and then become root, or launch it as
> root?

I launch it as user and then become root as necessary. Standard
sudo-setup as done by the installer when the option to prohibit root
login is selected.

> How much time passes between the sessions, [...]

Doesn't matter, see above. I'm positive that no other tools are involved.

> Do you have the options to automatically install Recommends or Suggests
> enabled, in the system, root .aptitude/config or user .aptitude/config?

Ah, yes ... there's this conf file in /etc/apt/apt.conf.d/, meant to
disable the automatic installation of Recommends and make the UI a
little more dselect-like. I've been using it since dselect was
deprecated, but it looks innocuous enough?

Aptitude::Get-Root-Command "sudo:/usr/bin/sudo";
//Aptitude::Auto-Install "false";
Aptitude::Auto-Fix-Broken "false";
Aptitude::Recommends-Important "false";
APT::Install-Recommends "false";
Aptitude::Keep-Recommends "true";
Aptitude::Keep-Suggests "true";
Aptitude::Purge-Unused "false";

Aptitude::UI::Default-Grouping "filter(missing),status,priority,section";
Aptitude::UI::Advance-On-Action "true";
//Aptitude::Theme "Dselect";

Thank you for looking at this,

Christian

Bug#814996: aptitude: purge does not "stick" the first time

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Christian,

2016-02-17 12:58 Christian Pernegger:

Package: aptitude
Version: 0.6.11-1+b1
Severity: normal

Dear Maintainer,

let's say I purge some packages and exit aptitude, then relaunch it
later and press [g]. The expected behaviour would be for aptitude to
report there's nothing to do. Instead, all the packages purged in the
previous session show up again, marked for install. If I press [_]
(purge) again at this point, they'll stay down.

Unfortunately this also happens if I actually do something in the
second session -- the purges will just show up as additional installs,
which might easily be missed if the list of changes is excessive.

This occurs on both fresh jessie installs I have.


I cannot reproduce this behaviour.

Do you launch aptitude as user and then become root, or launch it as
root?

How much time passes between the sessions, do they run immediately or
some time passes in between (so e.g. maybe some tool runs automatically
updating the system)?

Do you have the options to automatically install Recommends or Suggests
enabled, in the system, root .aptitude/config or user .aptitude/config?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814996: aptitude: purge does not "stick" the first time

[Christian Pernegger]

Package: aptitude
Version: 0.6.11-1+b1
Severity: normal

Dear Maintainer,

let's say I purge some packages and exit aptitude, then relaunch it
later and press [g]. The expected behaviour would be for aptitude to
report there's nothing to do. Instead, all the packages purged in the
previous session show up again, marked for install. If I press [_]
(purge) again at this point, they'll stay down.

Unfortunately this also happens if I actually do something in the
second session -- the purges will just show up as additional installs,
which might easily be missed if the list of changes is excessive.

This occurs on both fresh jessie installs I have.

Regards
Christian Pernegger



-- Package-specific info:
Terminal: xterm
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Nov  8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.4.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140913
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd23d7b000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7f70b42ce000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f70b4098000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f70b3e6e000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f70b3c68000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f70b3952000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f70b3689000)
libboost_iostreams.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f70b3471000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f70b306)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f70b2e43000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f70b2b38000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f70b2837000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f70b2621000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f70b2276000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f70b2073000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f70b1e6f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f70b1c54000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f70b1a44000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f70b1821000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f70b1619000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f70b1414000)
/lib64/ld-linux-x86-64.so.2 (0x7f70b4c9)

-- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.9.8.2
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u3
ii  libcwidget3   0.5.17-2
ii  libgcc1   1:4.9.2-10
ii  libncursesw5  5.9+20140913-1+b1
ii  libsigc++-2.0-0c2a2.4.0-1
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstdc++64.9.2-10
ii  libtinfo5 5.9+20140913-1+b1
ii  libxapian22   1.2.19-1

Versions of packages aptitude recommends:
pn  aptitude-doc-en | aptitude-doc  
pn  libparse-debianchangelog-perl   
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  
pn  debtags   
pn  tasksel   

-- no debconf information