On Mon, 16 May 2011 17:18:20 -0500 Jonathan Nieder wrote: > tags 626937 + unreproducible > quit > > Hi Francesco, > > Thanks for your reply.
You're welcome!
>
> Francesco Poli wrote:
>
> > Please note that Cupt is not really fully tested with apt-listbugs (at
> > least as far as I know)
>
> I've been using apt-listbugs with cupt on amd64 for a while, for what
> it's worth.
Good to know... :-)
>
> > Please try to reproduce the bug outside of the package manager.
> > For instance, does apt-listbugs work for you if you just issue the
> > following command?
>
> apt-listbugs list <package> worked okay for me when I tried it in the
> course of investigation.
OK, so apt-listbugs is not completely broken on your qemu-emulated
system...
>
> The bad news: before receiving your reply, I uninstalled apt-listbugs,
> ran "cupt dist-upgrade", and reinstalled apt-listbugs, and now the
> problem doesn't happen anymore. I think it must have had something to
> do with the particular wheezy -> experimental upgrade that was being
> proposed[1].
Can you downgrade the packages to their original versions and perform
that upgrade again?
That could be a not too slow way to reproduce the bug, I think.
>
> > I can try to reproduce the bug on a sid chroot (on amd64) with Cupt,
> > but unfortunately I don't have any armel system where I can investigate
> > a possible architecture-specific bug.
>
> I doubt it is architecture-specific, unless there is some assumption
> of signed char somewhere or something like that. This is an
> interpreted language and it wasn't a segfault. :) To reproduce the
> slow way (I don't encourage this --- it's just for illustration):
[...]
> I wonder if apt-listbugs/logic.rb, line 770 should not be
>
> pkgnames[index] = pkgnames[index].chomp
>
> and similarly for "if line != nil" on line 1169? Though that wouldn't
> affect this bug.
/usr/share/apt-listbugs/apt-listbugs/logic.rb:770 is
pkgnames[index].chomp!
Maybe it should be replaced with
if pkgnames[index] != nil
pkgnames[index].chomp!
end
or perhaps the "end" should be put after line 782:
pkgs[f["package"]] = f
It would be very nice of you if you could try to reproduce again the
bug in your qeme-emulated armel system, then modify
/usr/share/apt-listbugs/apt-listbugs/logic.rb
as suggested above (both possible strategies) and check whether the
issue goes away.
I don't know if this is enough to fix the bug, but it should do no
harm: at the end of the day, we cannot invoke the `chomp!' method for a
nil object, and there's no point in attempting to chomp a nil object
anyway...
>
> pkgnames gets populated by adding entries of the form
>
> filename = line.split(" ")[4]
>
> after apt-listbugs sees a blank line. If there are 4 or fewer fields
> on such a line then filename will be nil. Perhaps cupt mentioned a
> package it was going to remove or trigger in a nonstandard way.
It would useful to see what Cupt sent to apt-listbugs.
If you manage to reproduce the bug, could you please attempt to run the
same upgrade with something like
DPkg::Pre-Install-Pkgs {"/bin/cat - > /tmp/log";};
DPkg::Tools::Options::/bin/cat "";
DPkg::Tools::Options::/bin/cat::Version "2";
DPkg::Pre-Install-Pkgs {"/usr/sbin/apt-listbugs apt || exit 10";};
DPkg::Tools::Options::/usr/sbin/apt-listbugs "";
DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version "2";
in your /etc/apt/apt.conf.d/10apt-listbugs ?
*Big warning*: I haven't tested if the above does what I think it
does... ;-)
>
> Is the apt VERSION 2 hook interface documented anywhere? I tried
> "man apt" and "man apt.conf" but no luck so far.
I don't know: it's something I am not (yet) familiar with, even though
it would be useful to an apt-listbugs maintainer like me... :-(
>
> Thanks for your thoughtfulness,
Thanks to you for your help in investigating the issue.
--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpO0bFaCrg6J.pgp
Description: PGP signature
