=== thnee1 is now known as thnee [10:00] rharper: thanks for the reply. I'll start working on NM renderer for Fedora, then. Thanks for the support guys :) [14:42] rharper: still about network-manager support: If I can hack the netplan.py available() function to detect 'netplan' OR 'network-manager', I could just use the netplan renderer to have as input a v2 config file and render network-manager configuration, is that correct? [14:43] rharper: not as beautiful as having a proper nm renderer but perhaps a quicker and cleaner way. [15:09] otubo: yes, we'd need to think about the policy about which netplan backend to specify when rendering; for example, some images may have netplan which have both systemd-networkd *and* networkmanaeger [15:10] rharper: but I think this is not exactly a problem, right? It should be specified on the configuration file which one to use. [15:11] otubo: possibly, but one has to consider these things for existing images when changing behavior [15:14] rharper: I understand. I'll write a patch and create a pull request. Then we can continue the discussion from there. But apart from 'how to detect and enable', you think this would be a reasonable approach? [15:16] otubo: for sure; it does require netplan in the image; but it's a good extension of the netplan rendering (to also render when networkmanager is present) [15:18] rharper: oh so, I'll still need to have netplan present? Even if I hack the detection method? [15:18] rharper: if there's no wait out of having netplan present I'll really have to write the network-maneger standalone renderer [15:24] otubo: yes, cloud-init netplan.py writes netplan yaml to /etc/netplan/50-cloud-init.yaml (which is then read by netplan's generate tool which converts yaml to either systemd or networkmanager configs) [15:39] blackboxsw: do a cloud-init uplaod today to cosmic [15:40] or just "right now" [15:40] just lets get something up [15:40] agreed smoser [16:32] upload proposal for cosmic https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/352825 [17:28] blackboxsw: reading [17:30] blackboxsw: approved... should i put 'Approved' to the Status ? [17:30] that kind of scares me :) [17:30] smoser: I'm not sure here now that we have autolander.... let's not until we sort it. [17:30] yeah [17:31] I don't want to add the wrong commit message to the merge [17:31] my build-and-push is [17:31] http://paste.ubuntu.com/p/7fJy6hPVBD/ [17:31] just make sure you do the things it does [17:31] (basically, build it locally... and then push the branch (ubuntu/devel) and the tag [17:31] thanks. I found I have stale incorrect pgp keys on my dev box, so I'm going through the backup of those keys now [17:32] :) [17:32] then I can sign where I built it [21:13] man now that I can finally import my keys, I'm seeing timestamps on the build outfile which don't exist. [21:13] smoser: do you have any sbuild env vars defined in your environment [21:13] like BIN_NMU_TIMESTAMP ? [21:13] when trying to run the sbuild cmd I get "E: Failed to open build log /home/csmith/ubuntu/logs/../out/cloud-init_18.3-24-gf6249277-0ubuntu1_amd64-2018-08-09T21:13:35Z.build: No such file or directory [21:13] E: Error creating chroot" [21:14] whereas ../out/cloud-init_18.3-24-gf6249277-0ubuntu1_source.build exsts [22:12] got it. fixed my sbuild env, I didn't have a cosmic schroot setup [22:13] though seeing lintian errors when I try to build [22:13] E: cloud-init source: untranslatable-debconf-templates cloud-init.templates: 6 [22:13] E: cloud-init source: not-using-po-debconf [22:13] not sure if that should block upload or not [22:51] hrm well, it seems my upload was successful yet my signature failed to verify. https://pastebin.ubuntu.com/p/M7DCpqC4MP/ [22:51] I don't see any launchpad emails yet about this failed upload