On Sun, Jun 16, 2013 at 10:16:30AM +0200, David Kalnischkies wrote: >On Sun, Jun 16, 2013 at 12:50 AM, Steve McIntyre <st...@einval.com> wrote: >> * eventually, after a lot of debugging by a group of people, we >> worked out that this was caused by the Packages file missing >> Description: fields for all the package entries. Not everybody >> could consistently reproduce the problem (and it certainly wasn't >> there in squeeze); we worked out that the issue was related to the >> Acquire::Languages setting. > >That's a known bug. Various code particles assume that there is always >a Description available for a package, so you might happen to follow >dangling pointers and other dangerous stuff. In your tests with squeeze >you might just be lucky – squeeze already had Acquire::Languages >implemented, just that the archive didn't used/supported it, but squeeze >didn't had split-out long-descriptions so thats probably your problem.
Ah, right! >> For now, I'm working around this in debian-cd by explicitly adding "-o >> Acquire::Languages=none" to the code where I call apt, but I'd love to >> know: is this change a deliberate design decision, or a bug? If it's >> deliberate, could you please explain the reasoning? I can't see >> anything in the Changelog that mentions this behaviour change, >> offhand. > >It was always the case that "apt-cache show foo" would show the >Description-$LANG and if that wasn't available Description. >The thing that changed now with the split out long-description for >en is that even LANG=C has a 'translated' long-description in the >form of "Description-en" as "Description" is just a short description. > >So using =none might be the best you can do if you don't need the >description for anything - otherwise I would just >sed -i '#^Description-en:#Description:#' >and be done. OK, I'll stick with the =none then. >For the APT parsing side we should probably accept "translations" in the >Packages file as well instead of just from Translation-* files as there >isn't a real reason not to. ACK, sounds reasonable to me. But, as I'm seeing more and more often - it's amazing how often a minor change like that can have unexpected consequences. Thanks for the very quick response to the bug report, it's appreciated. I know I was very frustrated when I submitted it, and that may have shown through in my tone. If so, apologies... :-/ It's always the way when we do releases - the first point release is the one where all the weird off-base bugs happen, as it's the first one where all the infrastructure is running r0 instead of the previous stable code that we'd already debugged! I don't know whether or not to close this bug - it's up to you really... Cheers, -- Steve McIntyre, Cambridge, UK. st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
