[01:08] meena: well if you look at that busybox link it also says "was re-ported from NetBSD and debianized" [01:12] so it seems to be UCB -> NetBSD -> Debian -> Busybox [03:18] Did all of them benefit from smoser's grep optimization last cycle? Or did any of the non-debian almquists acquire the ability to read more than a character at a time? [07:52] https://github.com/NetBSD/src/blob/trunk/bin/sh/miscbltin.c#L73 character by character [07:55] same here, https://github.com/freebsd/freebsd-src/blob/main/bin/sh/miscbltin.c#L150 [08:01] same here https://github.com/openbsd/src/blob/master/bin/ksh/c_sh.c#L250 (also, didn't realise OpenBSD sh was ksh under the hood) [08:02] holmanb: so, yes, they all benefited [15:50] meena: huh, thanks for checking that [19:06] holmanb: my earlier reference to ds-identify changes needed for Alpine wasn't ash vs dash related, rather the need to make use of udevadm conditional (as Alpine doesn't use udev by default) and also need to verify that for any external programs called (such as blkid) that both the options and expected output is compatible with Busybox's versions or whether the "full fat" versions are a dependency [19:55] I'm adding docker and k8s.io sources using the apt config, and those files are created in sources.list.d on the VM, but package update (package_update: true) in cloud-init-output.log doesn't list them, and installation of containerd.io/kube* fails.  When logging into the VM from vagrant and running apt update manually, the sources are listed and I [19:55] can then install those packages.  It seems that package_update is run before the sources are created. What am I missing? [20:54] loser123: only if you changed something about the ordering [20:55] meena: didn't do anything about the ordering.  How would I handle that or inspect out it's ordered on the VM? [20:56] inspect how* [20:56] loser123: cloud.cfg should tell you about the ordering, the log files should tell you about what happened [21:13] meena: (for some reason I can't upload a file here, so I'll keep it short):  Here is some info from the log: [21:13] 2023-12-10 20:29:41,050 - helpers.py[DEBUG]: Running update-sources using lock () [21:13] 2023-12-10 20:29:47,970 - util.py[DEBUG]: apt-update [eatmydata apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet update] took 6.919 seconds [21:13] 2023-12-10 20:29:48,221 - cc_apt_configure.py[DEBUG]: adding source/key '{'keyid': '9DC858229FC7DD38854AE2D88D81803C0EBFCD88', 'keyserver': 'https://download.docker.com/linux/ubuntu/gpg', 'source': 'deb [signed-by=$KEY_FILE] https://download.docker. [21:13] com/linux/ubuntu mantic stable'}' [21:13] 2023-12-10 20:29:48,514 - cc_apt_configure.py[DEBUG]: adding source/key '{'keyid': 'DE15B14486CD377B9E876E1A234654DA9A296436', 'keyserver': 'https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.28/deb/Release.key', 'source [21:13] ': 'deb [signed-by=$KEY_FILE] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /'}' [21:13] 2023-12-10 20:29:48,907 - helpers.py[DEBUG]: update-sources already ran (freq=once-per-instance) [21:14] looking into cloud.cfg now.  This is ubuntu/mantic64 vagrant image. [21:15] loser123: this is IRC, we don't upload stuff here, we use a pastebin [21:15] (preferably one without ads) [21:15] we don't seem to have one in the /topic [21:16] meena: I'm on here through kiwiirc which does some sort of file upload (from the cloud init docs). [21:18] ah, yeah. I'm on The lounge, which uses Kiwi as library, and it has filled upload, too. but it doesn't catch a paste to transform that into an upload [21:20] anyway, the log already says that upload happens first, which is rather nonsensical [21:20] meena: ok, here is the cloud.cfg from the VM, which looks like it have the correct order: [21:20] cloud_config_modules: [21:20]   - apt_pipelining [21:20]   - apt_configure [21:20] cloud_final_modules: [21:21]   - package_update_upgrade_install [21:21] yeah, I don't get it.  it's as if the order isn't respected. [21:22] I wonder if vagrant if going something. [21:25] that hopefully is found in its own logs