Hi, Quoting Joachim Breitner (2015-08-26 09:17:13) > Am Mittwoch, den 26.08.2015, 07:18 +0200 schrieb Johannes Schauer: > > Maybe a conservative solution would be to make sbuild run one of the quick > > resolvers like apt and aptitude first, and only try running apt with an > > external resolver if they cannot find a solution? After all, the job is > > only sent to the buildds if dose3 found that there exists a solution, so > > this step should really never fail on the buildds, no? > > Using aspcud on the experimental buildds sounds like an elegant way > out. It would however require patching sbuild to support it in its > --build-dep-resolver=resolver > flag. Johannes, you don’t happen to have such a patch already for your > personal sbuild/aspcud needs? :-) I indeed have a local patch to sbuild that allows the apt resolver to try aspcud in case it fails to satisfy dependencies (as it for example happens when one tries to use the apt resolver with experimental). TLDR: please find a hackish proof of concept patch here: https://mister-muffin.de/p/LcTV.diff Long version: I did not communicate this feature idea with the sbuild maintainers yet because I'm still waiting for a reply from them [1] on a more public sbuild git branch of mine which fixes 13 sbuild bugs [2]. Since I got no reply from them in the mailing list thread [1] I prepared a delayed NMU to experimental with my fixes but also got no replies about that [3] so that is now in experimental [4]. Because of this lack of communication I gave up on sending sbuild patches but since you asked about this I just pushed the branch aspcud [5] with a hackish proof of concept commit on top that implements the aspcud fallback [6]. This is only a proof of concept as it contains no documentation or command line switches yet to enable or disable this feature. But as far as I can see it seems to work fine at least for me so far. Though maybe I should file a sbuild bug about this anyways so that this idea doesn't get lost. On a related note to your original message: When running dose-builddebcheck locally, I cannot confirm that there is a solution to install the build dependencies for pandoc in experimental. Specifically the problem is this [7]. cheers, josch [1] http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2015-July/009655.html [2] https://gitlab.mister-muffin.de/josch/sbuild/commits/staging [3] http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2015-July/009662.html [4] https://packages.debian.org/experimental/sbuild [5] https://gitlab.mister-muffin.de/josch/sbuild/commits/aspcud [6] https://gitlab.mister-muffin.de/josch/sbuild/commit/f8a66fc3ea9c587908efae12b7b54500da1a4bb8 [7] https://mister-muffin.de/p/sQbt.txt
Attachment:
signature.asc
Description: signature