Hi folks, sbuild 0.60.4 has just been uploaded to unstable, and we would very much like to get some feedback about a new feature it includes. If you're a user of sbuild, this means you! When sbuild builds a source package, either locally or on a buildd, it uses a "dependency resolver" to determine which binary packages to install and/or remove from the build chroot to satisfy the Build-Depends, Build-Conflicts (and -Indep variants) specified by the package. Historically, sbuild has used an "internal" resolver, included with sbuild to do this task. However, it has a number of bugs and deficiencies and we would like to move to a more modern resolver which can properly support things Debian Policy says we should support, such as: • Handling correct removal of all Build-Conflicts • Correct selection of alternative dependencies • Correct installation of virtual packages • Proper support of versioned dependencies, including the above The internal resolver fails under certain circumstances for all of the above, or simply doesn't support them at all. A new "aptitude" resolver has been written by Marc 'HE' Brockschmidt. This creates a dummy "dependency package" which is installed and contains Depends and Conflicts for all the appropriate Build-Depends and Build-Conflicts, and uses aptitude to install and remove the appropriate packages to satisfy them. This has been in use on our experimental buildds for about a year, and we now want to look towards making it the default. However, we need some more widespread testing to make sure the dependency resolving doesn't result in inconsistent installation of packages and hence inconsistent library dependencies or break building of any packages etc. The aptitude resolver may be enabled by setting $build_dep_resolver='aptitude'; in your /etc/sbuild.conf or ~/.sbuildrc You can then build your packages with sbuild like normal. What we are interested in are things like: • Outright build failures (e.g. due to unsatisfiable/uninstallable dependencies) • Different packages being installed compared with the internal resolver • Inconsistent packages being installed (depending on if other packages are installed or not) • Anything odd or unexpected • Success (if it works without problems, this is also nice to know!) Making sure the build chroot is fully updated and upgraded prior to testing can avoid false positives! Note: when building packages for upload, set $build_dep_resolver='internal'; (or comment out the line) to use the internal resolver to make sure the same resolver is used as on the buildds. Feedback can be sent to buildd-tools-devel@lists.alioth.debian.org Many thanks, 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.
Attachment:
signature.asc
Description: Digital signature