[05:36] <smoser> harlowja, larsks i just uploaded a 0.7.7 and pushed a signed tag.
[05:36] <smoser> https://launchpad.net/cloud-init/trunk/0.7.7
[14:53] <cpaelzer> smoser: has that check_version any good use-case other than to block one from just running make check to get all while developing :-)
[14:53] <cpaelzer> well the check was alwas there, but if now you take cloud-init and make any change it seems it creates a new evrsion (based on git hash) which then blocks the check_version
[14:53] <smoser> cpaelzer, check_version shoudl work
[14:54] <smoser> its there to stop me from releasing something without the change to the cloudinit/version
[14:56] <cpaelzer> smoser: http://paste.ubuntu.com/22917489/
[14:56] <cpaelzer> it fails as soon as any commit is made
[14:56] <cpaelzer> which is probably ok to block you from releasing
[14:57] <cpaelzer> but stopping "make check" from checking anything else as it does an early exit on that
[14:57] <smoser> cpaelzer, you need to pull tags
[14:57] <smoser> git pull --tags
[14:57] <smoser> i'm open to sugestions as that bit harlowja also
[14:59] <cpaelzer> smoser: tags don't unblock me (tells me already up to date and still fails the version check)
[14:59] <cpaelzer> I need to read what the check is actually doing
[15:02] <cpaelzer> smoser: for the start I'd suggest putting it at the end of the line in the check: target
[15:02] <cpaelzer> smoser: and then probably only calling it for release-checks or so
[15:02] <cpaelzer> smoser: where do you refer to the check when building a release - in the d/rules?
[15:03] <cpaelzer> ah yeah found the packages/debian/rules.in
[15:03] <cpaelzer> smoser: how about this
[15:03] <cpaelzer> create a release-check target
[15:03] <cpaelzer> which holds: check check_version
[15:04] <cpaelzer> and remove check_version from the "check" target
[15:04] <cpaelzer> call check_release from the packages/debian/rules.in
[15:04] <cpaelzer> smoser: if that would be ok for you I can quickly send an MP
[15:04] <cpaelzer> what do you think?
[15:44] <smoser> cpaelzer, you're right. its busted.
[15:56] <cpaelzer> if LP wouldn't have had network issues you'd already have an MÜ
[15:56] <cpaelzer> MP
[15:57] <cpaelzer> I'll retry later
[15:58] <smoser> cpaelzer, http://paste.ubuntu.com/22922872/
[15:59] <smoser> when i changed the format, i missed fixing that.
[16:00] <cpaelzer> ok, if you are on it I consider it done
[16:00] <cpaelzer> thanks
[17:31] <harlowja> smoser cools
[17:31] <harlowja> i'm wondering if people would be interested in knowing what godaddy is doing with jenkins (via myself, ha) for this
[17:32] <harlowja> https://gist.github.com/harlowja/748ddc47dd327ba25de6f60d77c5c5e0 is the http://docs.openstack.org/infra/jenkins-job-builder/ stuff for my little jenkins (currently)
[17:42] <smoser> cpaelzer, i pushed fix for make check
[18:04] <smoser> harlowja, thanks.
[18:10] <harlowja> i'm thinking though that i might try to get out the pkg_resources entrypoints stuff soon though
[18:11] <harlowja> cause i really don't like our injecting a module crap i am doing, lol
[18:13] <harlowja> it it makes version numbering all weird also :-P
[18:24] <smoser> what makes version numbering wierd?
[18:24] <smoser> do you not like my git-describe versions ?
[18:38] <harlowja> nah, just when i have to copy in a 'patch' it sort of distorts the real version of cloud-init
[18:39] <harlowja> vs just having the module loading look outside for modules, and then i can have a cloud-init-godaddy-addons package or something
[18:39] <harlowja> and can manage that myself and ...
[22:43] <smoser> rangerpbzzzz, around ?
[22:43] <smoser> rangerpbzzzz, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/302604