[00:15] 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] 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] yep, I'll take a look [16:04] 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] falcojr: Would any code set vendordata_raw to a list in those older versions? [16:15] I inserted a `self.vendordata_raw = ['#cloud-config\n']` on line 185 of DataSourceNoCloud.py [16:16] s/185/186 [16:24] has 'cloud-init' (not as a bit of software, but as a specification) ever been immortalised as an RFC or some equivalent? [16:25] 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] 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] (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