Hi Diane, On Sunday, 17 September 2017 22:14:18 AEST Diane Trout wrote: > I just did it that way because it was the least disruptive change I > could make that would let me build and test the package.
Sure, that's entirely sensible. > In my experience I'm much more likely to to notice a build time test > failure than one from the CI system. Absolutely agreed. I'm thinking that this is a rather exceptional situation because of the circular dependency and the fall-out that we regularly see from that. > What do other people think? If there are autopkgtests, should you still > let dh_auto_test run tests? (I know I'm not the 'other people' from whom you solicit replies, I was just perhaps unclear in what I was musing on before so I want to be more clear now) Like you, I would *normally* run all tests in both places: buildd tests catch severe problems right now; ci.d.n reruns the tests each time new versions of dependencies are uploaded too and later breakage is caught. Perhaps this is not a normal situation, however. Either one of "circular dependencies" or "packages that often FTBFS on one or more architectures" would be unusual enough to justify doing something different. All I am wondering (from my position of ignorance!) if in this case, perhaps the tests that cause the circular dependency can be disabled or xfailed, with the remaining tests run as normal. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7