extra-{depends/conflicts} and disabling of should_build_msgs; building of non-free
Hi,
additional dependencies / conflicts
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I just pushed a new buildd package which allows to specify additional
build dependencies / conflicts. Please note that it is *NOT*
acceptable to specify packages as dependencies which aren't to be
installed anyways; this is rather for increasing the version number,
like for binNMUs with an new eglibc. The right way to fix a missing
build-dependency is to upload an fixed package. If I notice this is
used for other purposes, I might get annoyed enough to waste time to
make buildd ignore dependencies on packages which are not installed by
the package anyways.
Usage: specify --extra-depends "string" or --extra-conflicts "string"
with any writing command, like --binNMU. There is also a new command
"--update" which does nothing except to write to the database.
buildd adjustments / WANNA_BUILD_API / no should_build_msgs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On the buildd side, the query syntax to wanna-build has changed. Due
to my lazyness there are no longer mails "should I build this failed
package" - if there is some strict need, please tell me so that I can
change that. As a temporary shortcut to that, you could specify an
WANNA_BUILD_API of 0 in the $defaults-section of .builddrc; this will
however hide packages with extra dependencies / conflicts. Please also
note that WANNA_BUILD_API is unchangeable 0 on all old-style-buildd
configurations. This means at least one buildd should use the modern
style file, i.e. with @distributions. Again, if you think it's
sensible to roll out the new API format to old-style configured
buildds as well, please say so (this is a probably trivial, but well).
For non-debian wanna-builds and the buildd.debian.org buildd packages
it's now necessary to set WANNA_BUILD_API to 0 (unless you get our
most recent changes re that).
For your own account on grief, you could specify api: 1 in
~/.wanna-build.yaml to always see all packages.
buildds: $defaults
~~~~~~~~~~~~~~~~~~
If there are settings which should apply to all distributions within
@distributions, there is $defaults. This allows me to write:
@distributions = (
{ dist_name => ["testing", "unstable"], },
{ dist_name => ["experimental"], build_dep_resolver => 'aptitude', },
);
schroot & run-setup-scripts / run-exec-scripts
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As the squeeze schroot spites out warnings if run-*-scripts are
enabled in schroot configuration, these settings are auto-disabled on
upgrade. (This doesn't make any difference, as we just set the default
in lenny, and set to the only possible option in squeeze.)
squeeze-ability of lvm-style chroots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also a few more adjustments are done to make schroot fully squeeze
ready.
building of non-free packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wanna-build now has non-free packages, but by default hides them from
the buildds. For lvm-style buildds, all that needs to happen is to
show these packages to buildd; please just ping me and tell me for
which buildd that should happen. For non-lvm-style buildds, this needs
a bit more consideration to avoid non-free sources to be present for
uploads to main (or perhaps not, but I haven't yet made up my mind).
Also, currently for all packages (in main, contrib and non-free),
build-dependencies could be satisfied from main+contrib (unchanged).
However, it should be that packages in main can only use main, and
packages in contrib+non-free could use main, contrib and non-free (at
least that's what the policy says). For that, we need to adjust
wanna-build a bit (for edos checks), get an list of acceptable
non-free packages for inclusion (by ftp-master, as buildds need to
include them as well), and then update the buildds to specify
appropriate chroot options (or perhaps in different order). So, more
work ahead. Until that, some packages in contrib and non-free wrongly
can't be built.
Andi
Reply to: