[00:15] <falcojr> IIRC most warnings come from the dependencies rather than the code itself, but if there's some easy ones to remove, sure! It'd be best to do as a separate commit in a separate PR though
=== david__ is now known as davido
[14:51] <Odd_Bloke> falcojr: Would you be able to take a look at https://github.com/canonical/cloud-init/pull/837 ?  It sounds like we may have regressed vendor-data?
[15:01] <falcojr> yep, I'll take a look
[16:04] <falcojr> I commented on the PR, but I don't think this is a regression. Same behavior happens if I jump to (much) older releases of cloud-init
[16:13] <Odd_Bloke> falcojr: Would any code set vendordata_raw to a list in those older versions?
[16:15] <falcojr> I inserted a `self.vendordata_raw = ['#cloud-config\n']` on line 185 of DataSourceNoCloud.py
[16:16] <falcojr> s/185/186
[16:24] <stevenm> has 'cloud-init' (not as a bit of software, but as a specification) ever been immortalised as an RFC or some equivalent?
[16:25] <stevenm> because whenever someone says 'cloud-init' I've no idea if they mean the feature (of communication between host and guest) or the package
[16:48] <Odd_Bloke> stevenm: I'm not really aware of people using it as a generic descriptor: cloud-init (the package) is present in almost every distribution, so it's usually the case that "cloud-init" is cloud-init.  There have been others, cloudbase-init works on Windows too, and CoreOS' Ignition performs similar actions but in quite different ways (it runs in the initramfs, not in the booted system).
[16:49] <Odd_Bloke> (I feel like I'm missing another one, but I may just be getting mixed up because CoreOS got acquired.)
=== Savicq is now known as Saviq
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
=== Tahvok_ is now known as Tahvok