[16:02] Odd_Bloke, I'm a bit stuck here and looking for smart ideas: https://github.com/canonical/cloud-init/pull/387 [16:04] I'd like to modify .travis.yml, but I can't just commit to it as the change interferes with the quilt patch also touching it [16:04] and the change can't be handled with a quilt patch as the patching does not happen at the right time and location [16:16] one way out I see is to remove .travis.yml from the quilt patch, making the cherry-pick a partial lie, and carefully avoiding including it again in cherry-picked patches [16:25] paride: So we landed a change to avoid running the integration tests on ubuntu/* branches: https://github.com/canonical/cloud-init/commit/e9ab1235eb3944ede588188592a1aa1aaae02591#diff-354f30a63fb0907d4ad57269548329e3 [16:26] paride: So we don't need bddeb to work on the packaging branches (I think build-package is the correct tool to use there as a developer?). [16:27] (Am I missing the point?) [16:37] Odd_Bloke, just partially. Even if we want integrate the "skip ubuntu/*" change in ubuntu/focal we need to modify .travis.yml as above. However modifying it will break the package building process as one patch in debian/patches touches .travis.yml too, and dpkg-source will refuse to apply it, breaking the package building process [16:41] I think we've got one thing wrong: touching .travis.yml in cpick-986f37b0-cloudinit-move-to-pytest-for-running-tests-211 [16:59] paride: Right, I see. IIUC, that pytest patch should be integrated from master to the packaging branches during the next SRU process (which we're starting this week), and then I think this problem goes away? [17:08] Odd_Bloke, yes, it will go away with the next sru. I guess the right thing to do is just to ignore the bddeb failures in ubuntu/focal up to that point [17:09] and maybe we should try to modify .travis.yml in separate commits, so the changes won't end up in cherry picked patches [17:09] I'll close the PR