On 23/08/10 at 10:50 +0200, Matthias Klose wrote: > no, it's not the network, a threading test does hang. I cannot reproduce this > one. > > the packaging is prepared to exclude the network test, when run on a buildd: > > on_buildd := $(shell [ -f /CurrentlyBuilding -o "$$LOGNAME" = buildd ] && > echo yes) > > could you adjust this check, or configure your builds in such a way > that the test succeeds?
I think that the consensus is that tests using the network should be disabled by default: 21:16 < lucas> is there a reliable way for a package to determine that it is being built on a buildd ? 21:16 < lucas> doko uses [ -f /CurrentlyBuilding -o "$$LOGNAME" = buildd ] 21:17 < jcristau> is there a non-crazy reason for a package to care? 21:18 < lucas> disable tests that use the network, for example 21:19 < jcristau> those should always be disabled, not just on buildds 21:19 < aba> lucas: /CurrentlyBuilding is ubuntu. 21:20 < aba> we could standardize something like an additional target extended-tests, but being on the buildd shouldn't change anything. Wouldn't it be possible to do it the other way around, i.e enable those tests when detecting that you are the one building the package, for example? - Lucas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
