[00:22] doublechecked to be sure (23.3 fine, git main shows the mentioned output). [00:22] can't see anything obvious in a diff between 23.3 and main code [11:26] meena: looks like my issue may be #4487 [11:28] minimal: it's still bizarre. [11:31] why is it trying to render all these other files? [11:31] minimal: is there a difference between python versions? [11:43] meena: yeah I mentioned in a note I added to the issue that as I'm specifying openrc init then I don't know why it treies to template the others [11:44] I tested building 23.3 on the *same* build environment (i.e. versions of python etc) and it doesn't behave the same [11:47] The systemd stuff has been around a lot longer than that tho. So are my changes throwing it off then? [11:48] the packaging still completes fine, I just find those YAML messages strange [11:49] I'm wondering if their the recent logging changes have made this visible but it always silently happened [11:53] Ah, i didn't consider that [13:57] meena: why do you have `{{ prefix }}` in the ds-identify rc.d template? [13:58] does that get populated by jinja at some point pre packaging? [13:58] dch: it gets rendered when you package it. [13:58] good good [13:58] dch: i test like this: python3 ./setup.py install --distro=freebsd --prefix=/usr/local --init-system=sysvinit_freebsd --root=/tmp/tmp.p03232blah [13:59] shellcheck refuses to check a jinja templated shellscripts! [14:00] dch: anyway, i updated the PR if you wanna test it [14:00] i see theres a = now thanks! [14:00] 23.3-65-g89f0f8978 would be the version [14:00] you'd have to replace canonical with igalic in the makefile [14:00] thanks you linked me a patch already very kindly [14:02] i'll link you a usable patch with make makesum, too [14:04] I finally decided I needed to write up the whole phoenix endpoint -> page render path for somebody [14:04] like 5 years overdue [14:13] dch: https://codeberg.org/meena/freebsd-ports/commit/dd907ac19af4472bc49178fa8e7a7e443b7e4fe7 [14:13] -ubottu:#cloud-init- Commit dd907ac in meena/freebsd-ports "net/cloud-init-devel: bump" [14:13] adding .patch on Codeberg works just like on github: https://codeberg.org/meena/freebsd-ports/commit/dd907ac19af4472bc49178fa8e7a7e443b7e4fe7.patch [14:14] i need a nap before i go pickup my daughter [14:17] dch: notice the += in PYDISTUTILS_INSTALLARGS+= "--init-system=sysvinit_freebsd" [14:17] the preexisting INSTALLARGS are the ones passing things like --prefix=${PREFIX} [20:52] meena not much luck here atm on the dsidentify hack [20:52] a shite [20:52] https://git.sr.ht/~dch/ports/tree/main/item/net/cloud-init/files/patch-sysvinit_freebsd_dsidentify.tmpl [20:53] on top of net/cloudinit though [20:53] if that matters [20:55] dch: what's ds-identify's log look like? [20:56] https://www.irccloud.com/pastebin/QyLJfp5c/dsidentify.log [20:56] started via `service dsidentify start` [20:58] aah it doesnt pick up the env vars [20:58] https://www.irccloud.com/pastebin/E4qVgPBO/env [20:58] because cloudinit_env should be dsidentify_env I think [20:59] do you wanna try? [20:59] https://www.irccloud.com/pastebin/DfaQgtQY/boom [20:59] that works [20:59] I skipped the rest of the log [21:00] dch: I'm mildly surprised, i think [21:01] I would for sanity's sake make all of cloudinit_dsidentify_ ... just dsidentify_ [21:01] I'm only running the dsidentify service, not the whole suits [21:01] *suite [21:01] hrmm [21:02] https://git.sr.ht/~dch/ports/tree/main/item/net/cloud-init/files/patch-sysvinit_freebsd_dsidentify.tmpl [21:03] but yes I share your general sense of surprise [21:03] I'll add you as co-author [21:03] share the blame, share the pain [21:03] heh [21:04] I reiterate, again, that sysvinit scripts should die in a fire, and like a phoenix from the ashes, freedesktop.org unit files should replace them [21:04] just for ports [21:04] leave my pid1 alone thanks [21:04] so (1) I like this approach better than my *cough* dirty hack [21:05] but (2) these vars, I'm not sure whether they all work like we expect [21:05] what email do I use for you? [21:05] dch@skunkwerks.at is fine [21:05] they're all fine [21:07] meena: let me give this 1 more whirl in a more-or-less fresh boot [21:07] before we commit ourselves to immortalised infamy [21:08] thank you for the help [21:10] a proper fix would still be to template ds-identify during the installation process [21:12] https://www.irccloud.com/pastebin/o9e5GO85/blargh [21:12] https://www.irccloud.com/pastebin/5sX1DgyG/happy_dsidentify.log [21:12] so, with that hack/patch, dsidentify runs correctly [21:13] but the blargh paste above looks like network takes too long to come up before datasource bombs out [21:13] that is more of a "me problem" than a cloudinit one [21:18] can you give it a 👍 [21:24] RFE https://github.com/canonical/cloud-init/issues/4497 [21:24] -ubottu:#cloud-init- Issue 4497 in canonical/cloud-init "[enhancement]: render ds-identify through template renderer" [Open] [21:29] ok, just finished a half-way decent test, this looks great [21:32] dch: please give it an approving review: https://github.com/canonical/cloud-init/pull/4485 [21:32] -ubottu:#cloud-init- Pull 4485 in canonical/cloud-init "ds-identify: FreeBSD fixes" [Open] [21:37] already done [21:37] its a lukewarm comment but definitely a +1 as WORKS ON MY MACHINE [21:41] * dch kicks a build and goes to sleep