Bug#633777: [buildd-tools-devel] Bug#633777: sbuild: virtual dependency resolver broken?
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 You shouldn't have two providers of a package where people build-depend on. So it's a bug in the packages, exactly because there's no guaranteed predictable solution to it. (It's causing FTBFSes in unstable too.) I won't comment on the sbuild failure mode, though. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#633777: [buildd-tools-devel] Bug#633777: sbuild: virtual dependency resolver broken?
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
Bug#633777: [buildd-tools-devel] Bug#633777: sbuild: virtual dependency resolver broken?
On Wed, Jul 13, 2011 at 6:05 PM, Roger Leigh rle...@codelibre.net wrote: On Wed, Jul 13, 2011 at 05:38:16PM +0200, Thibaut VARENE wrote: 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. So, I tried the 'aptitude' resolver, since I couldn't find any mention of a 'apt' resolver in the source code (note by the way that as far as I can tell, none of this is documented anywhere ;P) using the following in .sbuildrc: $build_dep_resolver=aptitude; And it did fix the issue, while installing more stuff (aptitude) into the chroot. 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. Well, given the lack of documentation, especially on upgrade process, and my previous experience with generally painful upgrades from version to version (0.60 entirely broke backward compatibility with 0.58 configs), I'm not exactly thrilled by the idea... ;P Cheers, T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633777: [buildd-tools-devel] Bug#633777: sbuild: virtual dependency resolver broken?
On Wed, Jul 13, 2011 at 06:28:53PM +0200, Thibaut VARENE wrote: On Wed, Jul 13, 2011 at 6:05 PM, Roger Leigh rle...@codelibre.net wrote: On Wed, Jul 13, 2011 at 05:38:16PM +0200, Thibaut VARENE wrote: 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. So, I tried the 'aptitude' resolver, since I couldn't find any mention of a 'apt' resolver in the source code (note by the way that as far as I can tell, none of this is documented anywhere ;P) using the following in .sbuildrc: $build_dep_resolver=aptitude; And it did fix the issue, while installing more stuff (aptitude) into the chroot. The apt resolver may not yet be available in stable. It's certainly in testing. And this should all be documented in the testing/unstable version in the sample sbuildrc and sbuild.conf. Just checked the changelog and the stable version does lack it. 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. Well, given the lack of documentation, especially on upgrade process, and my previous experience with generally painful upgrades from version to version (0.60 entirely broke backward compatibility with 0.58 configs), I'm not exactly thrilled by the idea... ;P In theory, we should be completely backward compatible--we continue to allow the use of older configuration variables in order to not break compatibility with older formats. If you are seeing breakage, I would appreciate knowing what's broken, so we can fix it. We have definitely made the config parser stricter though--it will now error out where it would previously continue e.g. if you misnamed a variable. And where we have removed configuration options, you might well be required to comment out/remove them from your configuration. But anything that's present in old and new versions should continue to work. If it doesn't, I'll fix it. 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
Bug#633777: [buildd-tools-devel] Bug#633777: sbuild: virtual dependency resolver broken?
On Wed, Jul 13, 2011 at 6:38 PM, Roger Leigh rle...@codelibre.net wrote: On Wed, Jul 13, 2011 at 06:28:53PM +0200, Thibaut VARENE wrote: Well, given the lack of documentation, especially on upgrade process, and my previous experience with generally painful upgrades from version to version (0.60 entirely broke backward compatibility with 0.58 configs), I'm not exactly thrilled by the idea... ;P In theory, we should be completely backward compatible--we continue to allow the use of older configuration variables in order to not break compatibility with older formats. If you are seeing breakage, I would appreciate knowing what's broken, so we can fix it. We have definitely made the config parser stricter though--it will now error out where it would previously continue e.g. if you misnamed a variable. And where we have removed configuration options, you might well be required to comment out/remove them from your configuration. But anything that's present in old and new versions should continue to work. If it doesn't, I'll fix it. Well, from the top of my head problems were: - local config name changes (buildd.conf - .builddrc) - removed/renamed config variables, which simply prevented sbuild/buildd to run until commented out / renamed. - config variable refactoring (the whole @distributions array was brand new in 0.60 and didn't work well (read: at all) with the good ol @take_from_dists(), and basically meant redoing entirely the buildd local configuration) - this is what I call breaking backward compat, fwiw ;-) - upgrading schroot wasn't exactly a pleasant trip either HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
