[Since bug 782871 and 782777 are merged, so I replied to both 782871@ and 782777@.]
Thank you so much for your kind and detailed explanation, David. I agree that this bug is really weird. Actually I _roughly_ checked the diff between 1.0.9.7 and 1.0.9.8 before submitting the bug. However it was my first time to check the diff in the Debian git repository, so I thought I missed some changes. As you told, it seems that the changes should not cause this kind of problem. Anyway let me explain more. In my case, I have only sid repository in my sources.list, while the other reporters said that they had experimental as well. However the package I have the problem on includes libgcc-4.9-dev which is mentioned in bug 782777. IMHO, if there're really small change lists between 1.0.9.7 and 1.0.9.8, then we can test with patching changes one-by-one. Thanks. 2015-04-19 19:00 GMT+09:00 David Kalnischkies <da...@kalnischkies.de>: > Control: reassign -1 aptitude > Control: forcemerge 782777 -1 > Control: affects -1 apt > > On Sun, Apr 19, 2015 at 01:00:59PM +0900, Hae-woo Park wrote: >> Recently I upgraded the following packages from 1.0.9.7 to 1.0.9.8: >> apt, apt-utils, libapt-inst1.5, libapt-pkg4.12. (I am using sid.) >> >> After then aptitude could not handle 'forget-new' (and 'markauto'?) properly. >> When type 'f' (or 'M') for those instruction in aptitude, it seems working; >> but after restarting aptitude the status went back. >> Note that the 'markauto' issue was tested only with 'new' packages. >> >> So now I've rolled back those 4 packages, >> and aptitude properly forgets the new packages by 'forget-new'. > > This wierdness is discussed over at aptitude with #782777, so I am > merging with it and let you guys figure it out because I can't reproduce > it here with "pure" apt(-mark) and this aptitude thingy is pure black > magic for my eyes and ears (on of these days I might start it). > > > From what I read there it isn't clear to me that a downgrade actually > fixes things. It seems more to "fumble around" stuff so that it pops up > someplace else. > > > My biggest problem with it is through that nothing in the vincity of the > autobit handling changed in 1.0.9.8. Not even close to it. > > > The closest is maybe "parse specific-arch dependencies correctly on > single-arch systems", but that just because it is the binary cache > creation changed, which is state potentially shared between different > versions of libapt, but is reshuffled on 'update' and at least partly > with every change to the dpkg/status. > > I didn't invalidate the cache with a version bump, which from a (very) > theoretical standpoint is incorrect, but that just means you are > effected by the bug this commit is fixing until after the cache is > invalidated next (given that just one package satisfying the criteria > exists at all in all of Debian, that isn't as bad as it might sound > – especially as the fix is for jessie and this one package is sid only). > That is working the other way around, too, through as a downgrade isn't > breaking it again instantly either. What I can see is that the two > reporters who provided the information are single-arch systems, so they > would be effected by this bug, for multi-arch systems nothing changed. > > > Now, all that being said, this bears no relation to 'new' nor 'auto' as > this is about dependencies being created incorrectly. At the most its > "removing" packages as this bug created package structures with a bad > name so they couldn't be found later, but that also means these bad > packages never had a version belonging to it and I doubt aptitude > considers those as new (and they are gone now, not added, so if > anything, 1.0.9.8 would fix it…). > > But yes, its the best I got, even through I have no idea what could be > it as the other fixes I would consider even less likely to influence the > outcome of aptitude than the current moon phase: > - apt-key changes do not effect aptitude at all > - VectorizeString is called by aptitude only in mkdir_parents, > which is itself never called by aptitude… > - WriteApportReport is disabled in Debian by default, called only by > libapt itself and only as a reaction to a dpkg error while stuff is > installed. Also, its a crash fix… > - pkgAcquire::Item::Mode is another crash fix, a crash theoretically not > happening and indeed never happening for 5 years in C++ code. Only > python3 seems to manage to trigger it. Also only acts while stuff is > being fetched from the interwebs. > - https is, well, a seperate binary never called directly by aptitude, > nor does it see the communication with it. Used also only while > fetching stuff from the (encrypted) interweb. > - a typo in the commandline parsing of apt-get. > > And that was it, all 7 changes in 1.0.9.8. > > Fun fact: This mail has more lines than 2 times the amount of changed > code lines (which itself counts changes twice as one line added and one > line removed) in the diff between 1.0.9.7 and 1.0.9.8. > > > Best regards > > David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
