=== cpaelzer__ is now known as cpaelzer
[15:05] <Odd_Bloke> meena: What _is_ the Python 3 on your distro called?
[15:05] <meena> Odd_Bloke: python3.7 on FreeBSD 12.1-RELEASE
[15:06] <meena> and python3 on this Ubuntu 18.04 laptop
[15:08] <Odd_Bloke> meena: https://www.python.org/dev/peps/pep-0394/ <-- sounds like the FreeBSD Python maintainers need to read this ;)
[15:09] <meena> Odd_Bloke: i agree.
[15:10] <Odd_Bloke> And paride and I did discuss this briefly in a video meeting; if anyone has unusual requirements (like that), then they can do some symlink/PATH futzing.
[15:10] <meena> yah
[15:11] <meena> but i did forward that question to #bsdports let's see what they have to say
[15:12] <Odd_Bloke> paride: Do you want to split out to a separate PR the commit that smoser mentioned is unrelated?
[15:12] <paride> Odd_Bloke, yes (he is right)
[15:12] <smoser> drop the change. its unrelated and its the same, no?
[15:13] <smoser> [ -n "$var" ] == [ ! -z "$var" ]
[15:13] <smoser> no?
[15:14] <Odd_Bloke> The commit message mentioned it fixing a shellcheck warning.
[15:14] <Odd_Bloke> But paride has listened to us too quickly, so I can't see that commit any longer. :p
[15:14] <Odd_Bloke> Oh no, it's in the PR description too.
[15:14] <paride> Odd_Bloke, updated that too
[15:15] <Odd_Bloke> "This is a stylistic issue that does not affect correctness." <-- in the red corner, smoser; in the blue corner, paride
[15:15] <Odd_Bloke> ;)
[15:15] <smoser> honestly i think the change made it less readable.
[15:15] <paride> :P
[15:16] <smoser> oh. no. your change *does*  make it more readable.
[15:17] <paride> I was indeed asking why
[15:17] <paride> well we're keeping the change I think, just putting it in a separate PR
[15:18] <Odd_Bloke> smoser: I'm +1 on the PR as-is, but don't want to merge it under you if you're still reviewing, so let me know once you're done with it. :)
[15:21] <smoser> i am done reviewing. i dont really care.
[15:25] <paride> meena, anyway the 'python2' and 'python3' pyexe strings did get some special treatment in run-container: https://github.com/canonical/cloud-init/blob/master/tools/run-container#L278
[15:26] <paride> so I'm not sure it would have worked on systems where the python interpreter is not called in one of those ways (I didn't check)
[15:27] <meena> paride: yah, i'm just debating with FreeBSD maintainers why they don't provide a python3 binary by default, and we're running in circles of misunderstandings…
[15:28] <meena> paride: anyway, i'm fairly certain those tools won't run on FreeBSD, so there's no need to concern yourself with my comments, but i did just learn something, so, that's good? i guess??
[15:33] <meena> can anyone give me an estimate on when one of y'all will be able to comment on robjo's network refactoring proposal? i'd like to plan my "free" time
[16:46] <smoser> cloud-init needs support for fw_cfg .
[16:46] <smoser> probaly extend nocloud
[16:46] <smoser>  http://www.contrib.andrew.cmu.edu/~somlo/QEMU_fw_cfg/
[16:46] <rharper> Odd_Bloke: blackboxsw: using new-upstream-snapshot -v --update-patches-only on ubuntu/xenial  shows the failure; I think have to "hand apply" which ends up being comparing the current version of the file, to the version from before 19.1 where we added the new client;  this is a manual process unfortunately;
[16:46] <rharper> smoser: parsing fw_cfg values?
[16:47] <smoser> that link makes it seem like with qemu_fw_cfg module
[16:47] <smoser>   /sys/firmware/qemu-fw-cfg/by_name/opt/GuestInfo/raw
[16:47] <smoser> the  kernel does it
[16:47] <rharper> as a datasource then
[16:47] <rharper> DataSourceQemuFwCfg
[16:47] <rharper> or into NoCloud ? I guess as you suggested
[16:47] <smoser> i'd just extend NoCloud. if by_name/cloud-init/meta-data
[16:48] <rharper> worth thinking on;  I don't think we've dicussed much the idea of multiple datasources being present
[16:48] <rharper> and which one should win
[16:49] <smoser> well, nocloud already does merge from different sources
[16:49] <smoser> but ... probably beter for the provider to just give one.
[16:50] <rharper> is fw_cfg cross arch ?
[16:51] <rharper> looks like x86 and arm only, no ?
[17:02] <rharper> Odd_Bloke: blackboxsw: are you OK with me pushing a new-upstream-snapshot -v --update-patches-only update to ubuntu/xenial  and ubuntu/bionic to fix the daily ppa builds ?
[17:02] <rharper> do you want me to push the fix to branch for review  ?
[17:03] <Odd_Bloke> Might be worth pushing it somewhere for review, ISTR we ended up having to do some branch surgery last time.
[17:03] <rharper> ok
[17:03] <Odd_Bloke> I can't remember _why_, but maybe I will if I look at the branch before it's pushed. ;)
[17:03] <blackboxsw> +1 on the new-upstream-snapshot as review so that we have a record for future to remind us of the action taken
[17:04] <rharper> http://paste.ubuntu.com/p/Nn2qXkdsNC/
[17:04] <rharper> is what the xenial update will look like, but I'll put up the branch in a minute
[17:06] <Odd_Bloke> That looks good to me (though I haven't tested if it actually fixes builds, I'm trusting you to do that :p).
[17:11] <rharper> Odd_Bloke: yes, I
[17:12] <rharper> I'm going to write down the steps I'm doing (and likely will want to add a tag to the commit right before we modified the ubuntu_advantage config module since that's the source to which we want to revert
[17:21] <smoser> rharper: well, current kernels for ubuntu have qemu_fw_cfg module in arm64, i386 and x86_64. not for ppc64le or armhf.
[17:21] <smoser> current (5.3.0-26)
[17:21] <smoser> i'm not sure why ppc64el and armhf missing
[17:23] <rharper> smoser: IIUC, its a guest firmware issue
[17:24] <rharper> so SLOF and whatever is used on s390x would need to support it
[17:24] <smoser> maybe
[17:24] <smoser> https://cateee.net/lkddb/web-lkddb/FW_CFG_SYSFS.html
[17:24] <rharper> qemu will put it at a know ram location, and the firmware is supposed to update/read/modify with details from the machine that qemu constructs via commandline configuration
[17:24] <rharper> sysfs could read it I suppose without firmware help
[17:25] <rharper> https://github.com/coreos/ignition/pull/905
[17:40] <Odd_Bloke> We did have someone in here asking for it the other day.
[17:55] <Odd_Bloke> blackboxsw: https://github.com/cloud-init/ubuntu-sru/pull/96 is my last SRU verification.
[18:05] <blackboxsw> thanks Odd_Bloke and it looks like I need to review my results. thx for review
[18:05] <Odd_Bloke> Of course. :)
[18:24] <blackboxsw> Odd_Bloke: pushed https://github.com/cloud-init/ubuntu-sru/pull/92
[18:34] <blackboxsw> Odd_Bloke: minor nit on linking to the SRU README.md and please land https://github.com/cloud-init/ubuntu-sru/pull/96#pullrequestreview-349606965
[20:16] <blackboxsw> robjo: so sorry, I forgot to click submit on the pending review comments https://github.com/canonical/cloud-init/pull/162 that I put in last week. added them now for your thoughts
[20:16] <blackboxsw> I just realized they were still in "Pending"
[20:16] <robjo> OK, thanks will take a look
[20:39] <meena> rharper: i can't believe i was right about the use-case
[20:40] <rharper> meena: ?
[20:40] <meena> rharper: IBM / EBCDIC.
[20:41] <meena> https://github.com/canonical/cloud-init/pull/187#issuecomment-578116993
[20:42] <rharper> meena: hehe indeed
[20:46] <meena> rharper: i can't believe we're finally getting EBCDIC in the cloud
[20:46] <rharper> I think SoftLayer may have s390x available, and certainly openstack has been trying;
[20:47] <rharper> this use-case is more for the s390x ubuntu installer which is leveraging cloud-init for first-time environmental setups to make installing on  an s390x, a lot less like installing on s390x =)
[21:41] <rharper> Odd_Bloke: blackboxsw: ok, finally sorted out the PRs for fixing daily PPA (without a new upstream snapshot), https://github.com/canonical/cloud-init/pull/196 https://github.com/canonical/cloud-init/pull/197
[22:40] <robjo> blackboxsw: tag you're it
[22:45] <blackboxsw> robjo: thanks, I think you have minor conflicts against tip of master (that Odd_Bloke character landed some dropping py2.7 stuff :) )
[22:48] <robjo> blackboxsw: fixed
[22:48] <blackboxsw> thanks