Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time
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
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
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
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
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
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
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