=== shardy is now known as shardy_lunch === shardy_lunch is now known as shardy [15:25] smoser, so git is ready?? [15:25] and larsks is fixing up brpm [15:25] even better :-P [15:26] whats git btw [15:26] i only know bzr [15:26] lol [15:26] harlowja_at_home: well, trying to. [15:26] and then redhat will use brpm [15:26] even better [15:26] hja [15:27] *ha [15:28] damn think i lost my other open bzr pulls [15:28] Yeah, note likely. My official recommendation is "delete brpm and bddep and leave that to the packaging people", but smoser says these things are actually being used... [15:28] smoser, did those go away? [15:28] larsks, yes, i use them [15:28] Yeah :) [15:29] leave that to the packaging people == i'm always stuck with some ancient version of cloudinit == not happy me [15:29] i use bddeb all the time. [15:29] larsks, honest question, if you're developing an open source project, how would *you* install that thing on a system? [15:29] i suspect you'd use build a package [15:30] (and if you wouldn't, how would you deal with the already-installed package or dependencies...) [15:30] Yeah. But I would probably start with, say, the existing Fedora rpm, and then insert the new sources. [15:30] And I would maintain the spec file directly, rather than generating it. [15:30] ah, the hand-curated spec file stuff [15:30] One of the problems with the existing brpm script is that it is super fragile... [15:30] its worked :-P [15:31] It will never work for me because it doesn't deal well if your rpm configuration redefines things like _rpmdir, _specdir, etc. [15:31] larsks, but if you're workign on trunk, you commit to trunk, you wan tot type some command have have somtehing to install [15:31] thats my need. [15:31] larsks, well we can adjust that, just code ;) [15:31] if that can be done in some other way, then i'm not opposed to some other way. [15:32] For most packages I work with, packaging is handled "downstream" (by the distribution) rather than by the application developer (which is nice, because it means an application developer doesn't have to keep up with packaging standards, shifting names, etc). [15:32] But no worries, I will make brpm work :) [15:33] I will probably need a hand with bddeb, because it's been a long time since I worked on debian style packages. [15:35] larsks, yeah, that is the common way "upstream doesnt care" [15:35] but that just seems odd to me [15:35] i want to install something on a n operating system. and then remove it cleanly. [15:35] there are tools for that :) [15:36] larsks, i'll help with bddeb. [15:36] Yay! [15:36] smoser, sooo all the other open branches i had on the bzr codebase, i guess i gotta find those and reopen? recreate? [15:37] did they diseapper in the ether? [15:37] ah, nm, i found them @ https://code.launchpad.net/cloud-init/+branches [15:37] i guess we have to resubmit? [15:52] harlowja_at_home, yeah, i think thats best. [15:53] k [15:53] https://yahoo.tumblr.com/post/147941303269/verizon-to-acquire-yahoos-operating-business [15:53] and that's over with ^^ [15:55] smoser, https://review.openstack.org/#/c/317739/ also relevant to us [15:56] don't think it changes much, but haven't reviewed in depth :-P [15:58] harlowja_at_home: I am getting a keyerror from the templater when trying to generate the spec file. Does this make any sense to you? https://gist.github.com/larsks/2728dcf1cd0036e19472e0e1d802ed69 [15:59] larsks, will get back to u on that, does seem sorta odd there [17:58] so smoser what should we do with https://github.com/openstack/cloud-init ?? [17:58] that ones an odd duckling now, lol [17:58] but the master has (?) something useful? [17:59] lots of windows stuff that i don't understand in that, lol [18:00] harlowja, its a 2.0 branch that is currently shelved [18:01] harlowja: the templating failure was because it was a cheetah template...but brpm explicitly ignores a venv python, so ended up using the basic rendered, which failed on those expansions. [18:02] ah [18:02] ya, wonder why it explicitly ignroes that [18:02] who wrote that crap [18:02] lol [18:29] so smoser i'm gonna get openstack-infra to drop/delete https://github.com/openstack/cloud-init [18:29] ok with u? [18:29] *or try to get them to [18:29] lol [18:29] lets put a copy into launchpad first. but yeah. [18:29] k [18:30] smoser do u have that ability, or do i also (to push branches?) [18:30] you do, but i'll do it [18:30] k [18:34] harlowja, ok. it is there at https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init-v2 [18:35] cool [20:11] I'm trying to make an EC2 AMI with a centralized authorized keys file (ie. in sshd_config: AuthorizedKeysFile /etc/ssh/authorized_keys/%u). I see in the cloud-init source-code, cloudinit/ssh_util.py, the function setup_user_keys asserts the parent folder to be mode 700. Those permissions don't work with this AuthorizedKeysFile value. Having /etc/ssh/authorized_keys be mode 755 is what works. Is there a way around this? [20:43] wraithm: you can run arbitrary shell commands via cloud-init, e.g., using the 'runcmd' directive. Maybe try that? [20:43] harlowja: when you have a moment, I've updated https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/300953 with a working brpm and I would appreciate your eyes on it. [20:43] like runcmd: [ 'chmod 755 '] ? [20:43] cool [20:44] wraithm: something like that, yes. [20:44] harlowja: ...but I'm just about to take off for the day, so no rush :) [20:44] cools [20:44] The ssh module should probably be split up into one module for generating host box keys and one for inserting user keys [20:44] It's really annoying that it does both at the same time [20:47] I also had the idea of not running the ssh module, generating the ssh keys with a bootcmd or something (so that the keys still get printed to the console for my known_hosts). Do you think that would work? [21:57] The runcmd chmod worked :) Thanks!