On Wed, Jul 13, 2011 at 05:38:16PM +0200, Thibaut VARENE wrote:
> I've recently discovered that some of my packages stopped building because of
> the following error:
>
> Checking for source dependency conflicts...
> E: Package 'libjpeg-dev' has no installation candidate
> libjpeg-dev is a virtual package provided by:
> Using (no default, using first one)
> Use of uninitialized value in join or string at
> /usr/share/perl5/Sbuild/Chroot.pm line 339.
> Use of uninitialized value in join or string at
> /usr/share/perl5/Sbuild/Chroot.pm line 340.
> Use of uninitialized value in join or string at
> /usr/share/perl5/Sbuild/Chroot.pm line 341.
> Use of uninitialized value $command in join or string at
> /usr/share/perl5/Sbuild/Chroot.pm line 353.
> Use of uninitialized value in exec at /usr/share/perl5/Sbuild/Chroot.pm line
> 354.
> terminate called after throwing an instance of 'std::out_of_range'
> what(): basic_string::compare
>
> Turns out -q apparently inhibits apt-get from displaying the providers of the
> virtual package:
>
> So, I tried editing /usr/share/perl5/Sbuild/Build.pm:1136 to remove the '-q'
> bit, but unfortunately it didn't fix the issue.
>
> I've checked that the apt-get command did NOT include '-q', and that was
> right. Still, for some reason, either sbuild doesn't get the output from
> apt-get, or apt-get isn't showing its
> expected behaviour when run through sbuild, because I still got the same
> error messages. Adding a 'print("pipe: $_");' at line 1147, in the
> "while(<pipe>)" block, shows:
>
> terminate called after throwing an instance of 'std::out_of_range'
> what(): basic_string::compare
> Installing positive dependencies: [snip]
>
> sbuild never gets the list of providers, and thus cannot pick any.
>
> I *think* this might be a recent apt-get bug since I had the same issue with
> sbuild 0.58.2 a couple days before upgrading, but maybe it's also a new
> "expected" behaviour from apt-get and
> thus sbuild should get fixed...That's interesting, I had seen the missing provides list before, but hadn't pinned it on "-q" being the cause. I assume that this is a change in the historical behaviour of apt-get which we haven't adapted to. However, the fact that it also dies due to an exception (std::out_of_range) does not bode well. That's an outright bug in apt-get, and we can't work around that. > In any case, the fact is it breaks the virtual resolver for packages with > multiple providers (i've tested that when there's only one provider, there is > no problem. I suppose apt-get does > the right thing then). There are two areas of brokeness here: apt-get and sbuild itself. While apt-get is definitely misbehaving here, sbuild's "internal" resolver is also absolutely awful at working with virtual packages. While we did do some refactoring when introducing the "apt" resolver, it could well be that the root cause was apt-get being broken. You could try using the "apt" resolver which delegates all dependency resolution to apt-get. It's the default in current unstable, and can handle virtual dependencies without issues, including alternatives. I would also suggest trying the latest sbuild/libsbuild-perl in testing/unstable. They should run without problems on squeeze by design. If the bugs are still causing problems with this version, we can at least address them whereas updating the squeeze version is rather more difficult. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
