=== sterfield_ is now known as sterfield === shardy is now known as shardy_lunch [11:59] smoser, thoughts on -> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1600766 [12:02] hmm.. maybe we've fixed already but we just haven't done a release with it? https://bugs.launchpad.net/cloud-init/+bug/1246485 [12:03] jgrimm, this is fixable by lxc templates. i've discussed it with stgraber. [12:03] it is now fixable in cloud-init with some thought ... the most recent changes would allow for it when previously there wasn't really a point in boot where you could do that. [12:04] but a rose by any other name would still smell as sweet [12:04] ie, why does it matter? [12:04] ubuntu-core folks have use case [12:04] probably not good ones. [12:05] the host platform (lxd in this case) declares that the hostname of the system is XXXX [12:05] why do you care what the system calls itself ? [12:05] the system says "I want to be named bob" [12:05] lxd says "his name is robert" [12:05] who cares what the system says. if you ask the platform (dns) his name is robert. [12:06] but, as i said, 2 ways to fix it. [12:06] does that make sense ? [12:06] why do you care what the container calls itself. [12:06] This is a problem when using the dnsmasq for local dns resolving for *.lxd, which is the standard way of doing host dns for containers, as new containers are not dns addressable with a restart or renew. [12:07] lxd should fix that. [12:07] if lxd wants to insist that you can ask dnsmasq for dns resolution [12:07] then it can't rely on the system behaving correctly [12:15] jgrimm, stgraber i commented in bug [12:15] smoser, sorry.. laptop locked up. looking now === shardy_lunch is now known as shardy [16:09] rharper, harlowja larsks [16:09] here [16:09] i'm going to delete lp:cloud-init [16:09] which means http://paste.ubuntu.com/21155351/ [16:09] howdy [16:10] I've only got one in that list and I can resubmit... [16:10] ditto [16:10] your repos wont be deleted, but yeah. they have to be re-done [16:10] k [16:12] larsks, and harlowja since i know you're such high bzr and launchpad users, you might sometime need the solution i came up with at [16:12] https://bugs.launchpad.net/bzr-fastimport/+bug/1606973 [16:12] powersj, rharper might actually use that at some point (curtin and other things) [16:13] smoser: nice [16:13] that'll be needed for curtin move to git as well [16:13] i wasted a lot of time trying to use another solution that just didnt work with cloud-init's bzr export [16:14] this is cool [16:14] this way was much easier. [16:15] y [17:57] larsks, rharper https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init harlowja [17:57] that is up now. [17:57] ready for merge proposals [17:57] thx [17:57] * larsks looks... [18:06] re-propsed: https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/301310 [18:08] larsks, what does git push -u do for me ? [18:08] smoser: sets the upstream tracking branch so that in the future you can just "git push" instead of "git push myremote mybranch" [18:09] Otherwise you get: http://chunk.io/f/6378b82ea0c647cd888de1af0d912bb8 [18:10] (-u is short for --set-upstream) [18:11] larsks, do you want to stick with with cheetah in that tempatle ? [18:12] You mean the spec file? Not really! I just didn't want to make too many changes at once that weren't directly related to the task at hand... [18:12] ok [18:12] thats fine, want to ditch cheetah [18:12] but that is good to not do that here. [18:12] I will make that a subsequent merge proposal. [18:12] (converting the redhat and suse spec files to jinja templates) [18:12] although you did do arbitrary white space (line 534) [18:12] :) [18:13] That hurt my brain. [18:14] i think keep the 'find_root' around line 635 [18:14] same reason as before... would like to set those [18:14] rather than relying on git [18:14] alghouth i guess less improtant there [18:14] as that is explicitly a git operation [18:14] Even make-tarball? That seems like we really want that to come from version control. [18:14] Yeah. [18:15] line 681 in that diff [18:15] isthat set -o pipefailed ? [18:15] i dont think so. [18:15] so the gzip is unlikely to fail and thus unlikely to error [18:16] (if the left sizde of that | (git archive) fails, then the command will succeed) [18:16] read-depednecies... there is some reason we cant' use egrep [18:16] let me log [18:17] commit e26ac6b63072f3217de2fc9214584e61682cd211 [18:17] I'll update the script to set pipefail. [18:17] * larsks looks at that commit. [18:17] pipefail is bash [18:18] silly non-linux unixes [18:18] Ah, right, and we can't assume bash. [18:18] and their silly 1986 shells [18:18] That basically means "freebsd" at this point? [18:18] yeah. [18:18] those changes came in with freebsd [18:18] it makes sense to use python though [18:18] as we're pretty dependent on python working [18:18] :) [18:19] I guess. It seemed like a ridiculous amount of logic, but that's okay, I'll revert. [18:26] larsks, my mom reminds me that i didnt' say thank you. this is good, thank you. [18:27] smoser: thanks! just pushed a restored (mostly) read-dependencies; fixing up make-tarball now... [18:34] ...and there's a fixed up make-tarball