libgda3-3 is currently FTBFS on the autobuilders but local tests check out fine - I want to be able to close the RC bug in an NMU but I can't reproduce the buildd error. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466431 http://buildd.debian.org/fetch.cgi?pkg=libgda3;ver=3.0.2-1;arch=amd64;stamp=1203274481 gtk-doc-tools is not being picked up as a build depends during port builds, despite it being located during normal debuild, pdebuild and pbuilder checks on my machines. (pbuilder ... --binary-arch works too). gtk-doc-tools is in Build-Depends-Indep: in debian/control so porting builds will (presumably) drop that depends and this setup then conflicts with the explicit --enable-gtk-doc option in debian/rules, causing the upstream GTK_DOC_CHECK m4 macro to fail. There isn't much point forcing buildds to build the docs but the quick fix would be to put gtk-doc-tools into Build-Depends instead of Build-Depends-Indep. Do buildds set DEB_BUILD_OPTIONS ? (i.e. wrapping --enable-gtk-docs in "nodocs" support would help in other areas but would it allow the buildd runs to complete?) Is there a sane solution *and* a way to replicate this on a normal Debian box without implementing sbuild? (This is also holding up my own upstream work which needs a fix in this version of libgda3-3.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part