[14:46] smoser, jenkins URL is now externally available at: https://jenkins.ubuntu.com/server/ [14:46] I am working this morning to update the URLs generated by the CI bot and to get venonat online for the vmtests. [14:50] powersj, awesome! [14:50] venonat is offline [14:50] (just i saw that there, fyi) [14:51] powersj, is it possible to hide things from non-logged in users ? [14:51] i could see doing something stupid in a slave config [14:51] yeah sounds like IS doesn't have access to it, so I have to manually update it's URL for Jenkins to the new one. [14:51] such as exposing a credential or something in its log [14:51] smoser, agreed, let me look into that [14:52] in fact I am going to blow away the slave-config logs we have [15:16] powersj: nice! [18:26] harlowja, aorund ? [18:26] sup [18:27] we used bzr revno before [18:27] for a ever-increasing number [18:27] i think pbr has a way of doing a similar thing [18:27] that is failrly standard. [18:27] and i think you have at some point given sane way of getting that. [18:29] smoser: don't you love the random last 7 chars of git hash ? [18:29] well they dont always go up [18:29] thats what i dont like. [18:29] I know [18:29] =) [18:30] well, git describe --tags --long [18:30] maybe we can just go with that until we're unlucky [18:30] :) [18:30] does prepend a number of commits since tag [18:30] yea, ok. [18:30] so you get 0.7.6, then 0.7.6-N-hash, and then 0.7.5-N+M-hash [18:30] that sorta helps I think [18:31] I need to play with that to confirm [18:32] what is -N+M ? [18:32] whats the M [18:32] M may be more than one commit since the previous number [18:32] similar to revno I guess then [18:33] it's offset in numbver of commits since tag [18:33] http://paste.ubuntu.com/21428257/ [18:34] master reports as 1021 commits since 0.7.6 was tagged [18:34] =) [18:34] but why did you say '-M' [18:34] er.. +M [18:34] I just meant that it may be more than 1 since the last time you ran describe [18:34] ah. [18:34] I'm sure I confused you [18:34] ok. [18:34] its easy to do [18:34] :) [18:35] no, head to keyboard transfer isn't always perfect [18:35] usually PBCAC for me [18:39] heres hwat sucks. [18:39] ew can't use 0.7.6-XXX [18:40] as we've already released 0.7.7~bzrX [18:40] which is > 0.7.6- [18:49] rharper, so. .. [18:50] $ git describe --tags [18:50] 0.7.6-1022-g36e92d3 [18:50] what is g36e92d3 ? [18:51] ah. the g . ii forgot about that. [19:17] git describe --tags --long [19:17] the g is hardcoded [19:17] for whatever reason [19:17] g + 7 chars of the hash [19:18] smoser: need to tag 0.7.7 [19:20] yeah. [19:21] I rant into trouble with git since changlog has 0.7.7 but it's not bumped in the repo [19:21] but since larsks branch drops the changelog building, it was no longer an issue; that said, we should still tag it for a new deb build [19:42] so ya, pbr us one solution here [19:42] there is another one that can also help figure out the version to [19:44] https://pypi.python.org/pypi/setuptools_scm is one [19:44] there are a few more [19:45] i'm ok with any of them really [19:45] https://pypi.python.org/pypi/setuptools_scm#default-versioning-scheme [19:46] is that fine with folks? [19:46] that one seems to be the 'the blessed package to manage your versions by scm tags' [19:46] https://github.com/pypa/setuptools_scm/ [19:46] i guess from the pip folks? [20:02] harlowja, thanks. [20:02] rharper, or larsks is it ok for me to annotate tags and push them overwrite ? [20:03] smoser: it is okay to overwrite tags, sure. [20:03] rharper, i think the easiest answer to ~ or + is to just use + and to release an 0.7.7 [20:03] y [20:03] and then use + always fom here out. [20:04] people who have checked out the repository will probably need to do an explicit get pull --tags to get the updated tags. [20:04] y [20:04] 0.7.7+1-ghash [20:04] larsks, yeah. [20:04] how can i get the commit hash that a signed/annotated tag points to ? [20:06] $ git checkout && git log -n 1 [20:06] ? [20:06] prob a better way, ha [20:06] $ git show 0.7.6 | awk '$1 == "commit" { print $2 ; exit(0); }' [20:06] yeah [20:06] ok [20:06] so https://pypi.python.org/pypi/setuptools_scm#default-versioning-scheme what we gona go with? [20:07] i'd prefer that one over pbr (although its similar) [20:09] hmmmm, ok, let me know when thats done [20:09] i'll have to redo my fork and reviews i think [20:13] then i can get my jenkins stuff thats internally building cloud-init rpm back into shape [20:13] (using new jenkins way) [20:14] *git way [20:14] harlowja, it shoudlnt hur your checkout [20:14] it just changes the tags [20:14] kk [20:22] http://paste.ubuntu.com/21439291/ [20:22] that is 'sign-tag' and me running it. [20:23] i'm going to push now to master [20:25] proof its u? [20:25] how do i really know [20:25] u could be the fake-scott [20:34] harlowja, its the same key that signs important things. [20:34] like cirros builds [20:35] it better be [20:35] or i'm calling the police [20:35] lol [20:56] larsks, hey still arond ? [20:56] yessir. [20:56] smoser: ^^^ [20:56] i have some changes here to get bddeb to build [20:56] on top of your branch. [20:57] in bzr world, i'd just commit on yours, push and then request merge. of those [20:57] how would i do this in a sane way. [20:57] i dont care really about the annotation just want to get somethign to you i guess. [20:57] I think I would approximately the same thing: I would start a new branch based on mine, push it, and request merge. [20:58] And then hope that launchpad isn't crazy. [20:58] And then merge your changes after mine merge... [20:59] ok. [21:00] (honestly, I just wish everyone in the world used gerrit for handling code submissions, because it has great handling of changeset dependencies) [21:00] * larsks also wants a pony. [21:01] the one thing that bzr did better. [21:02] it basically does --first-parent by default [21:02] so peopple chan have all these little silly commits, you can merge them into yours, then i can merge them into master [21:02] and if you git log on master, then you only see the one commit [21:02] as if you had squashed them all before i merged or pulled [21:03] thats why you see allthat nonsense little commits in git log now [21:03] True. Although you can also adopt a policy of "one commit per change please", and reject patches that have all those little commits. [21:09] right, but thats just squashing [21:09] and yes, i would adopt such a thing. :) [21:09] i probaly use revision control more than i should [21:09] but i really like reading history [21:09] and put a lot of stuff in it [21:09] and often would bzr log --include-merged [21:10] whenever i would say WTH WAS I THINKING! [21:10] anywahy [21:10] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/301547 [21:10] ./packages/bddeb -S -v [21:10] that works in my branch [21:11] larsks, ^ thanks. [21:11] thats the last reference it hink to 'bzr' in the repo [21:12] that uses bzr at least [21:14] audios all [21:19] smoser: later [21:35] what's bzr [21:35] lol [21:35] * harlowja purges all knowledge of bzr [21:35] sorry canonical [21:35] lol