[11:45] Is that a good assumption the CA Certs module can work on ubuntu and debian only? [13:50] andras-kovacs: I believe it depends on tooling that is only present in Debian derivatives, yes. [14:13] * andras-kovacs sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/AuwhMuZRuZyPzlqOuLWFhGUG > [14:13] * andras-kovacs sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/YqvjIFpIhuWgYdZbGgNSEieo > [14:14] hmm maybe it's time for me to try to contribute to this project [14:48] andras-kovacs: Contributions would certainly be welcome! [15:03] hi there, can anyone tell me what the diff between nocloud, genericcloud and generic in https://cloud.debian.org/images/cloud/buster/20200210-166/ is? [15:06] ah found it here: https://salsa.debian.org/noahm/debian-cloud-images/blob/master/README.md === tds0 is now known as tds [17:30] does the proxy directive in apt module support yum? [17:30] I guess I could try and see [17:30] actually, it appears it doesn't. dang [17:31] ananke: It would be surprising if anything in the apt module supported yum. :) [17:34] Odd_Bloke: well, I was going by the notion that apt_update and apt_upgrade are aliases [17:36] and there is no other module that deals with package manager options. hmm, not sure if i'll be able to use 'packages' module then, without being able to set a proxy first [17:36] runcmd runs afterwards [17:36] ananke, there is a yum module [17:36] Yep, they're aliases, but in cc_package_update_upgrade_install which is generic. [17:36] Looks like the yum module only adds extra repos, rather than allowing config like proxy to be applied. [17:37] powersj: there appears only yum_repos, is that what you're referring to? [17:37] ananke: Would a bootcmd work for you? [17:37] (It's runcmd but earlier.) [17:37] Odd_Bloke: potentially, that's a good idea [17:38] would you happen to know if write_files is before packages or afterwards? [17:38] * ananke should just look at a sample failed host [17:38] Check /etc/cloud/cloud.cfg to see the configured order. [17:39] (Alternatively, run https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl through your brain's Jinja2 parser. :) [17:40] our AMI build environment is behind a squid proxy, which makes a lot of things like that challenging [17:43] ahh, good, write-files is much earlier. it's at the beginning of cloud_init_modules, while package-update-upgrade-install is towards the end of cloud_config_modules === tds7 is now known as tds [18:05] yay, that worked. sadly yum doesn't appear to support dropping in a file, so I have to change existing /etc/yum.conf [18:50] on that subject, does write_files 'path' directive create missing dirs? [19:33] Odd_Bloke: the cla check says: [19:33] 3s [19:33] We are currently unable to download the log. Please try again later. -- what does that mean ? [19:34] ananke: yes, it effictively runs "mkdir -p $(basename file)" [19:34] ananke: it also has an append mode [19:37] rharper: thanks! appears to be working like a charm [19:38] had to create a systemd environment file for docker, so it can use proxy [19:40] rharper: No idea! [19:41] ananke: nice trick! [19:41] Odd_Bloke: did we already land something from garlof ? [19:42] I was looking at the mime-data type bug and updated that with a fix, but noticed the cla check had a weird result [19:42] I "reran" the checks bit it stayed the same [19:43] rharper: that appears to be the sanctioned method. here's how the net result looks like with cloud-init: http://dpaste.com/3D3B7XC [19:57] cool [19:58] rharper: I see a couple of commits from Kurt Garloff. [20:20] Odd_Bloke: ok, I thought I remembered that. So I wonder what to do with the check failing though; we have time, waiting for garlof to respond [20:29] rharper: So the process is (correctly) failing on one of the PRs because we don't have garloff in our in-repo lists of CLA signers. [20:29] (I don't know why it's failing to check out on the other.) [20:31] But regardless, I think you'll need to email them on their CLA-signing email address asking them to confirm that they control the GH account in question. [20:32] Odd_Bloke: ok [20:33] (And then update the in-repo metadata, of course.)