I'm not exactly sure why bzr debuild fails, but I noticed his in http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/86 and tried to fix it. Unfortunately, while that was valid and buildable package, it exposed a bug in 'bzr dailydeb' (which is how the dailiy builds run). I reverted my change (and thus knowingly re-broke bzr bd again) at revno 87.
Here is a summary of whats wrong:
* The tests/ files that were added should not be in the packaging branch.
Its bad packaging to have files outside debian/ in your packaging. And most of the time people enforce that by using 'debuild' with '--source-option=--abort-on-upstream-changes'.
* When I removed these files, and instead put them into a patch to be applied, that broke bzr dailydeb because we were creating new files with a patch (which seems like a major bug, but this was verified by jelmer).
I think the right solution is probably to move those tests/ files into debian/tests and then work with them from there.
I'm not exactly sure why bzr debuild fails, but I noticed his in http:// bazaar. launchpad. net/~maas- maintainers/ maas/packaging/ revision/ 86 and tried to fix it. Unfortunately, while that was valid and buildable package, it exposed a bug in 'bzr dailydeb' (which is how the dailiy builds run). I reverted my change (and thus knowingly re-broke bzr bd again) at revno 87.
Here is a summary of whats wrong: option= --abort- on-upstream- changes' .
* The tests/ files that were added should not be in the packaging branch.
Its bad packaging to have files outside debian/ in your packaging. And most of the time people enforce that by using 'debuild' with '--source-
* When I removed these files, and instead put them into a patch to be applied, that broke bzr dailydeb because we were creating new files with a patch (which seems like a major bug, but this was verified by jelmer).
I think the right solution is probably to move those tests/ files into debian/tests and then work with them from there.