[17:51] SuperLag: can you show us the logs? [20:29] sorry meena, just now seeing this… [20:29] https://dpaste.com/AJQ4FGXD8 and https://dpaste.com/3WM76A6MG [22:45] minimal: does `cloud-init analyze` work on alpine? [22:46] I'm curious if the author of this page[1] meant to say: [22:46] "The analyze subcommand only works on systemd-based distros." [22:46] [1] https://cloudinit.readthedocs.io/en/latest/explanation/analyze.html#availability [22:52] nevermind, I see the calls to systemctl this is very tightly coupled [22:52] and in theory this would work on gentoo/systemd too [22:52] ... if cloud-init had better gentoo support [22:54] holmanb: blame, show, and dump work on Alpine, it's just "boot" that doesn't due to its reliance on systemd [22:55] I briefly looked at it a month or 2 ago thinking of getting it working but didn't dig deep enough to work out what changes were needed [22:55] minimal: gotcha, nice [22:55] thanks for the information [22:56] it's on my long list of things to work on lol [22:57] the neverending list :P [22:57] BTW am trying to figure out python gpep517 support [22:58] holmanb: yeah I recently added both the lxd DS and cc_lxd to that list ;-) [23:02] ah nice [23:02] how good is lxd support on alpine? [23:03] I'm new to lxd myself, only recently spun it up on a VM (to initially test containers) [23:03] gotcha [23:03] I like it [23:03] it's nice [23:04] and from a quick look at the LXD DS it seems some Alpine-specific changes needed, e.g. the sock file is not in the usual place [23:04] the other day I was trying to use it on an old gentoo server of mine and got stuck on subuid/subgic configuration - didn't work out of the box [23:04] but also I didn't try debugging for very long [23:05] Alpine actually has 2 versions packaged - package lxd is 5.0.2, package lxd-feature is 5.19 [23:05] gotcha, sock file should be easy enough to work around I assume [23:05] and they're not identically setup (2 different maintainers) [23:05] lxd on ubuntu has been snap-only for a while - no deb is maintained [23:06] hrm, 2 maintainers for different versions of the same package sounds problematic [23:06] it's the "usual" situation of someone supporting/maintaining a "stable" version and someone else wanting the latest/greatest [23:07] gotcha [23:07] if you feel like a quick docs review https://github.com/canonical/cloud-init/pull/4563/files [23:07] -ubottu:#cloud-init- Pull 4563 in canonical/cloud-init "Docs Correction" [Open] [23:08] do you know anything about python gpep517 at all? [23:08] uhhhh, a tiny bit [23:08] wait is gpep a thing? [23:08] I thought it was a typo before [23:08] its a "setup.py replacement" [23:08] but you did it again and now I'm second guessing myself [23:09] yeah I pushed a package to pypi a while ago that used pep517 [23:10] so using "gpep515 build-wheel --wheel-dir .dist --output-fd 3 3 3>&1 >&2" to build cloud-init [23:10] and then apparently "python3 -m installer -d "$pkgdir" .dist/*.wml" to package it up [23:11] which is how rthe numerous Alpine python packages do this, except this result in *ALL* the cloud-init stuff (including etc directory) being placed inside the site-packages directory [23:12] had a scan of the gpep517 and the python installer modules docs and am none the wiser lol [23:13] yeah it's... confusing [23:13] and our setup.py does some random stuff like call external scripts for templating [23:14] gpep517 is a frontend we made to try paper over the mess [23:14] https://github.com/projg2/gpep517 [23:14] alpine started using it too because it's good [23:14] howdy sam_ o/ [23:14] hi! [23:15] I started looking at gpep517 as a side action of trying to figure out the recent "YAML parsing errors of systemd template files" that I've been seeing with c-i master (but NOT with previous releases), still haven't haven't figured that one out yet [23:16] > It is the tool of choice for a world that does not revolve around pip and venvs. [23:16] XD [23:16] I like it [23:17] sam_: Hi. Looking at examples of other Alpine packages I couldn't figure out how to pass extra options to "python3 -m installer" packaging stage that I currently pass to "python3 setup.py install" (like "--init-system=sysvinit_openrc") [23:19] https://github.com/projg2/gpep517/issues/10 [23:19] -ubottu:#cloud-init- Issue 10 in projg2/gpep517 "how to pass setup.py arguments" [Closed] [23:19] (https://github.com/projg2/gpep517/issues/10) [23:20] holmanb: yeah, it's our best effort for coping with it [23:20] the ecosystem is kind of a mess rn though [23:20] it's a nice idea (pep517), but it's messy rn [23:20] the defacto stuff for what gpep517 does is 'installer' and 'build' [23:20] and they have a tonne of deps [23:23] sam_: before you joined the convo I mentioned I'm seeing the installer currently put *everything* inside site-packages, even the etc dir that should be /etc :-( [23:23] ... that was the next bit I was going to mention [23:23] there's no standard way for pep517 things to install outside of site-packages [23:23] this is probably the worst part [23:23] doh! ok, so I'll forget about gpep517 for the near future then [23:24] what we've done for portage (because it's both a python module but we also want to install files to /etc, etc) is use meson-python in two modes [23:24] one for pure wheel [23:25] one for system installs [23:27] ah, interesting [23:29] ok, now I'll go back to trying to work on what the heck is going with YAML parsing of tmpl files as mentioned in #4487 [23:29] https://tpaste.us/papW [23:30] thanks for the context sam_, appreciate it [23:39] hmm, even just running "python3 setup.py install --help" produces those YAML errors...