[03:24] <blackboxsw> noahm: thank you for raising that to our attention, I'm fixing the doc builds now and regenerating tagged releases
[03:24] <blackboxsw> I did that early last week I believe, thinking I checked all the boxes on a docs migration to a readthedocs site that didn't have ads embedded.
[04:04] <noahm> blackboxsw: thank you! :) 
[04:22] <blackboxsw> noahm: reverted the migration temporarily so it won't redirect for the moment. most of the old builds fail on new RTD-hosted.com tooling. So, we'll sort how to export or migrate those static old builds before flipping the switch. noahm out of curiousity, how old a version were you interested in
[04:25]  * blackboxsw was looking at making sure we sync back to 0.7.9 but not sure if we need to stretch farther
[05:36] <noahm> blackboxsw: I certainly don't anticipate needing anything further back than that. 19.3 is far enough for most of what I'm likely to care about.
[11:47] <holmanb> SuperLag: welcome :D
[11:51] <holmanb> SuperLag: ln 19 I was invoking cloud-init from a clone of the source code, on a system that has cloud-init installed that could be called as `cloud-init schema -c test.yml`, or using the --system flag instead of -c to check the schema on the system from the datasource rather than from a file.
[11:51] <holmanb> SuperLag: https://cloudinit.readthedocs.io/en/latest/reference/cli.html#schema
[11:51] <holmanb> SuperLag: https://cloudinit.readthedocs.io/en/latest/reference/faq.html#how-can-i-debug-my-user-data
[11:55] <holmanb> SuperLag: and if you want to run ln 19 the way I did (on a system without cloud-init installed) you could `git clone git@github.com:canonical/cloud-init.git && cd cloud-init` before running that command.
[16:46] <SuperLag> holmanb: you still around?
[16:50] <holmanb> SuperLag: yes
[16:52] <SuperLag> I went to the second link. And there's a python script there. Ran it, it says "userdata.yaml - ok".
[16:53] <holmanb> SuperLag: ahh the validate-yaml.py one?
[16:53] <SuperLag> but when I installed cloud-init on my jump box, and was testing... I did "cloud-init schema -c userdata.yaml" and got --> Error: Cloud config schema errors: users.0: {'default': None} is not valid under any of the given schemas
[16:53] <SuperLag> so I'm not sure which one to believe :D
[16:53] <SuperLag> holmanb: yep
[16:53] <holmanb> don't trust that one
[16:53] <holmanb> thanks for pointing that out, the docs need to be updated
[16:53] <SuperLag> don't trust that script? or the latter?
[16:54] <holmanb> all that validate-yaml.py does is check if your config file is valid yaml
[16:54] <SuperLag> which isn't sufficient for it to work with cloud-init, I take it?
[16:55] <holmanb> correct, valid yaml doesn't mean it is valid user-data
[16:56] <holmanb> do you have a colon after "default" in your users list>?
[16:57] <SuperLag> I do.
[16:57] <holmanb> SuperLag: if you see the paste from before, you'll note that I deleted the colon in the version of your userdata that passed the validation
[16:57] <SuperLag> sure enough :D
[16:58] <SuperLag> and after removing that it passes muster :D
[16:58] <holmanb> SuperLag: \o/
[16:59] <SuperLag> Is cloud-init supposed to work the same for all distros? or are there differences depending on distro?
[17:00] <holmanb> SuperLag: there are many things that cloud-init can't guarantee across distros - package name, for example, varies from distro to distro
[17:00] <holmanb> SuperLag: and there are some distros which cloud-init doesn't support
[17:02] <holmanb> SuperLag: however, it operates similarly for most distros
[17:03] <holmanb> SuperLag: on the modules page you'll note that each module has a "Supported distros" list
[17:03] <SuperLag> One of the things I haven't tried yet, is to mark one of the generated VMs as a template, and see if subsequent VMs have the cloud-init stuff baked in. Having the VMware datasource makes life VERY nice.
[17:07] <holmanb> SuperLag: Should work, depending on what you mean by that.
[17:08] <holmanb> SuperLag: You'll note that Module Frequency for many modules is "once-per-instance", so cloud-init will execute those modules only once per instance (this is customizable in cloud.cfg).
[17:52] <andrew76> Recently I've noticed problematic behavior using cloud-init's "packages" functionality to install some apt packages on Ubuntu 20.04. It seems to install the packages fine, but then if I look after the fact, the packages contain no files at all
[17:53] <andrew76> if I run "dpkg -L <package>", I get "Package '<package>' does not contain any files (!)"; so the apt package is installed, but there are no files associated with it; any suggestions on how to fix this? Thanks!