[08:03] <alan_g> RAOF: hanging out today?
[08:03] <RAOF> alan_g: Just noticed the time!
[08:03] <alan_g> You must be having fun! ;)
[09:28] <alan_g> Hmm. An unexpected downside to epoch...
[09:28] <alan_g> 09:22:07 mir_1.0.0+fetch5145bzr4250.orig.tar.gz
[09:28] <alan_g> 09:22:07 + cd mir-1:1.0.0+fetch5145bzr4250
[09:28] <alan_g> 09:22:07 /tmp/hudson3553452967355580048.sh: line 24: cd: mir-1:1.0.0+fetch5145bzr4250: No such file or directory
[09:28] <alan_g> https://mir-jenkins.ubuntu.com/job/build-1-sourcepkg/release=xenial/5134/console
[09:30] <xnox> please don't use epochs =) they are weird in many ways.
[09:31] <xnox> plus 1.0.0 >> 0.27.0 and no epoch is required.
[09:31] <xnox> (at least from ubuntu perspective)
[09:31] <xnox> (no epochs, if you can that is)
[09:49] <alan_g> xnox: I want to merge miral into mir and that's at 1.4
[09:56] <alan_g> for now, the above problem just looks like a regex for extracting "UPSTREAM_VERSION" that doesn't know about epochs.
[09:57] <alan_g> Hm. No that's not it.
[09:58] <xnox> alan_g, dpkg-source, when unpacking things skips epoch (as that is "debian" prefix)
[10:00] <alan_g> xnox: and so it should.
[10:01] <xnox>  line 24: cd: mir-1:1.0.0+fetch5145bzr4250 -> looks like something is trying to change into a directory with an epoch; yet i don't think any standard tools would create such a dir.
[10:01] <xnox> anyway, not my code, i should go fix broken things instead =)
[10:02] <alan_g> xnox: that's why the directory doesn't exist. I just need to correct the cd command
[10:02] <alan_g> This is wrong: UPSTREAM_VERSION=`perl -n -e '/^Version:\s(.*)-[0-9]ubuntu.*$/ && print $1' ${DSC}`
[10:03] <alan_g> I just need to get the right number of escapes to work in jenkins
[10:03] <xnox> ooh, ok.
[10:04] <xnox> in general, in debian/rules, i use "include /usr/share/dpkg/default.mk" and use the DEB_UPSTREAM_EPOCH variable or some such, I guess having a makefile is too much here.
[10:04] <xnox> but that is equavalent to something liek: $ dpkg-parsechangelog -SVersion | sed -e 's/-[^-]*$$//'
[10:05] <xnox> hm, nope
[10:15] <alan_g> xnox: I can make this work. But if you have a better idea than an epoch, then please tell.
[10:15] <xnox> from what i can tell the canonical variables as created by /usr/share/dpkg/pkg-info.mk appear to be broken
[10:16] <xnox> and those parse debian/changelog, which is not extracted yet... (given that above tries to parse .dsc file)
[10:20] <alan_g> xnox: I can insert "([0-9]:)?" into the the above perl but (unsurprisingly) things just break a little later
[10:25] <xnox> $ cat openssh_7.5p1-8.dsc | sed -n 's|Version: [0-9]\?:\?\(.*\)-.*|\1|p'
[10:25] <xnox> is my best attempt, which will not work when upstream version has dashes in it (legal) or with double-digit epoch (also legal)
[10:26] <xnox> and it fails with non-epoch .dsc
[10:26] <xnox> sigh
[10:26] <xnox> $ echo openssh_7.5p1-8.dsc | cut -d_ -f2 | cut -d- -f1
[10:26] <xnox> =)))))
[10:27] <xnox> $ echo ${DSC} | cut -d_ -f2 | cut -d- -f1
[10:59] <alan_g> xnox: FWIW it seemed to be just one script that was epoch-unaware. in the end I fixed the uses that broke, and left the variables alone: e.g. cd "${SOURCE}-${UPSTREAM_VERSION#[0-9]:}" (etc)
[11:00] <xnox> =)
[11:00] <xnox> simples
[11:01]  * alan_g once again wishes the CI configuration were backed by version control.
[11:42] <xnox> =/
[11:43] <xnox> yeah, in our team we do use git repositories, that have jobs in yaml, and then jenkins jobs builder creates it, but i still think there are manual bootstrap jobs and/or things that are manually twiddled.
[11:48] <alan_g> xnox: you didn't suggest a less bad idea than epoch. Does that mean I'm doing something sane?
[11:50] <xnox> alan_g, less bad idea was to simply use 1.5 version number which is higher than miral&mir
[11:50] <xnox> without epochs.
[11:50] <xnox> epochs are evil =)
[11:50] <xnox> as you will never ever be able to drop an epoch, and it looks weird, and people get confused.
[11:51] <xnox> or e.g. 1.4.1
[11:51] <ogra_> if you want friendly epochs ... use snaps ;)
[11:52] <xnox> alan_g, and just because version number i 1.4.1 it is still perfectly fine to claim that mir api/abi is 1.0.Y
[11:52] <xnox> or not, as you wish.
[11:52] <alan_g> I suspect that going from 0.27 to 1.5 is no more popular.
[11:52] <xnox> alan_g, go from 0.27 to 28?
[11:52] <xnox> =)
[11:52] <alan_g> But I'll test that out.
[11:52] <xnox> yeah, it's all very physcologically driven.
[11:53] <alan_g> greyback: concerns addressed? https://code.launchpad.net/~alan-griffiths/mir/move-miral-to-mir/+merge/329455
[11:53] <xnox>  but do expect people to refer to the new thing a 1.1.0.0, because people do not notice the colon epoch 1:1.0.0
[11:53] <xnox>  but do expect people to refer to the new thing as 1.1.0.0, because people do not notice the colon epoch 1:1.0.0