On Tue, Apr 08, 2008 at 11:32:03AM +0400, Aleksey Midenkov <[EMAIL PROTECTED]> 
was heard to say:
> On Monday 07 April 2008 20:21:20 you wrote:
> > On Thu, Apr 03, 2008 at 05:06:50PM +0400, Aleksey Midenkov 
> <[EMAIL PROTECTED]> was heard to say:
> > > Package: aptitude
> > > Version: 0.4.11.1-1
> > > Severity: grave
> > >
> > > The program get terminated at very start.
> >
> >   I don't think it's grave for aptitude to break when its database is
> > corrupt, so I'm downgrading this.
> >
> >   Daniel
> 
> Neather database nor package cache rebuild does not help. The bug is not only 
> in reading empty Section: field, as I tried to describe. The bug is in losing 
> Section: field. Please, answer to the point. You seem to be the are author of 
> the program. Changing status of the bug back to grave: there is no way to use 
> a program.

  Please do not play bug ping-pong.  The program is not usable for you,
but it works for me and for most users (as evidenced by the fact that
the code in question has been out for a month and you are the first
person to trigger this bug).

  The fact that running "update" doesn't fix it is interesting.  Would
it be possible for you to run "aptitude-create-state-bundle" and post
the result somewhere that I can download it?


  JFTR, you stated that

On Thu, Apr 03, 2008 at 05:06:50PM +0400, Aleksey Midenkov <[EMAIL PROTECTED]> 
was heard to say:
> due to sections_remaining string emptiness. The string get empty from very 
> start at 272:
> 
>    270    else
>    271      {
>    272        section=pkg.VersionList().Section();

  Section should not be an empty string in a well-formed Debian
archive.  And in fact you said that it was not:

> I 
> looked into apt list and ascertained that the Section: field is not null for 
> gsfonts-other (non-free/text). I suspect, that /var/cache/pkgcache.bin get 
> build somehow wrongly.

  ...so the cache is messed up somehow because apt dropped the Section
field from the package.

  Obviously aptitude shouldn't barf when apt has done something wacky in
building its cache, and I have already committed a patch to the archive
that should guard against this case as I understand it (if you send me
the snapshot I mentioned above I can try to reproduce this and verify
that the attached patch works).  But it's not really possible to predict
all the ways that a broken cache will break aptitude; many badly formed
caches just produce unavoidable segfaults due to the way apt is designed.

  Daniel
diff -r 2fc5e36dc340 -r 9277b3f02cab src/pkg_grouppolicy.cc
--- a/src/pkg_grouppolicy.cc	Mon Apr 07 09:11:07 2008 -0700
+++ b/src/pkg_grouppolicy.cc	Mon Apr 07 18:28:19 2008 -0700
@@ -262,7 +262,8 @@ void pkg_grouppolicy_section::add_packag
       section=_("virtual");
       may_passthrough = true;
     }
-  else if(!pkg.VersionList().Section())
+  else if(!pkg.VersionList().Section() ||
+	  (*pkg.VersionList().Section()) == '\0')
     {
       section=_("Unknown");
       may_passthrough = true;

Reply via email to