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