[02:20] <cjwatson> jelmer: Would you mind having a quick look at https://bugs.launchpad.net/launchpad-buildd/+bug/1350430 ?  bzr-builder doesn't call substitute_changelog_vars for format 0.4; it looks deliberate, but I can't figure out why, nor what's supposed to be done instead
[02:20] <_mup_> Bug #1350430: {debupstream} {debversion} not recognised  by format 0.4 <launchpad-buildd:New> <https://launchpad.net/bugs/1350430>
[02:20] <cjwatson> jelmer: (we've finally deployed a non-archaic bzr-builder, so just starting to notice the effects of things you did years ago ...)
[02:21] <StevenK> OMG, so it ain't so
[02:28] <cjwatson> StevenK: scalingstack, it is a thing at last
[02:28] <StevenK> I don't believe it
[02:48] <cjwatson> jelmer: http://paste.ubuntu.com/7910544/ seems to fix it, and the unit tests still pass; but that line of code seems to have been added after the 0.4 format was added if I'm reading the history right, so it would be nice to get confirmation before pushing that to utopic/trusty-updates and potentially breaking something else ...
[02:50] <cjwatson> __init__.py says "{debupstream} now only looks for changelog in the root branch, not the resulting tree" - struggling to work out why that's a useful thing
[02:51] <cjwatson> the bug suggests {debversion} is affected too, which makes sense given the structure of substitute_changelog_vars, so presumably also {debupstream-base}
[10:19] <jelmer> cjwatson: looking
[10:20] <jelmer> it's a long time I've worked on all of this :)
[10:21] <cjwatson> yeah :)
[11:04] <jelmer> cjwatson: I vaguely remember that the point was that we could find out the version string without actually building the tree
[11:05] <jelmer> there was also a syntax to get the debversion from a nested tree
[11:05] <jelmer> {debversion:NAME}