06:43 <Matthieu[m]1> hi,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0cadf20bad6ac06082f8e0a55aff51b939ac2ffe)

06:43 <Matthieu[m]1> * hi,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4905580aac797a23978c32f62756a82f5f563077)

06:44 <Matthieu[m]1> * hi,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/bf438044b3e36eab332bac50d97a0c8faf8fe8d3)

06:47 <Matthieu[m]1> In fact, is it even relevant?...

07:11 <Matthieu[m]1> https://coreos.github.io/ignition/configuration-v3_3/ so 3.3.0 is the latest

09:47 <lucab> Matthieu Saulnier: the latest version of what exactly?

09:48 <lucab> Matthieu Saulnier: ah, I think you may be asking about Butane config. The available versions are here: https://coreos.github.io/butane/specs/

10:17 <Matthieu[m]1> lucab, yes butane config

10:17 <Matthieu[m]1> I tried with 3.3.0 but I had an error, so I made a new try with 1.4.0

10:17 <Matthieu[m]1> thank you

15:04 <walters> any opinions on trying to more consistently move some of stuff that we depend on that lives in personal repositories (mostly rust crates) into the coreos/ GH org? I am concretely thinking of https://github.com/cgwalters/cargo-vendor-filterer and https://github.com/lucab/memfd-rs for example

15:05 <walters> I think I asked this before about the former but I think it's also scoped a bit more widely

15:09 <bgilbert> walters: I was just discussing this with jlebon yesterday

15:11 <lucab> memfd is a shared-ownership one, it wasn't originally coreos-related

15:11 <bgilbert> he argued that it makes sense to keep "group maintenance" things in coreos/

15:11 <bgilbert> maybe we should have explicit guidelines about this

15:11 <lucab> https://crates.io/crates/memfd

15:12 <bgilbert> though I wouldn't want to force someone to move their personal project into coreos just because they use it in coreos code

15:12 <walters> i know memfd specifically has outside-coreos maintainers, but, if it's in the coreos/ gh org then we can more easily apply the same automation (MSRV bumps) there unless there's a reason not to

15:12 <walters> right we should definitely not force this

15:14 <walters> ok sorry perhaps memfd is too special case, if there are no objections I'll ask to transfer https://github.com/cgwalters/cargo-vendor-filterer to coreos/ since it is definitely somewhat load bearing for us and soon others and I want to reduce the bus factor there

15:16 <lucab> Nowadays it's mostly nagisa taking care of memfd, it just happens to keep living under my namespace. And the other contributors there have a wider range of cases (bsd, android) so I don't think it would follow our coreos/fedora/rhel decisions much.

15:27 <walters> filed https://github.com/coreos/fedora-coreos-tracker/issues/1256

15:27 <walters> wait the BSDs support memfd?

15:29 <lucab> At least freebsd does. But I think there were some other problems in libc-rs around that.

16:02 <lucab> bgilbert: I got back to a point where I'm fighting users/groups ownership and sysusers in initramfs and I'm tempted to revive https://github.com/coreos/ignition/pull/1153 (instead of https://github.com/coreos/fedora-coreos-config/pull/774) and possibly add a top-level `sysusers` field in Ignition to override the OS defaults. Just a random idea for now, but is this maybe something that we already debated before?

16:48 <bgilbert> lucab: if there's been previous discussion, I wasn't involved

16:49 <bgilbert> lucab: I think I'd need more context. I'd assume that however the OS wants to provision its system users/groups, that isn't Ignition's concern?

16:50 <bgilbert> i.e. the f-c-c PR is what I was thinking we'd do

17:26 <jlebon> i'd pay at least $10 if someone fixed GRUB pegging 100% of one of my cores when I'm just idling in the menu

17:29 <jlebon> (or more often editing kargs)

17:50 <Matthieu[m]1> jlebon, just set the timer to 1 or 2sec :)

17:51 <jlebon> Matthieu[m]1: i mean when i have to interrupt the menu :)

17:52 <lucab> bgilbert: kinda, it gets tangled into Ignition in cases like this https://github.com/coreos/fedora-coreos-config/pull/1839#issuecomment-1184215907

17:54 <bgilbert> lucab: doesn't https://github.com/coreos/fedora-coreos-config/pull/774 fix that though?

17:59 <bwnnfd[m]> I have what if probably a very stupid question. I'm trying to provision an AWS EC2 instance running CoreOS. I have an ignition file but it's too large to directly input in the userdata field, so I've hosted it on a webserver. How do I properly reference my ignition file URL in the userdata?

18:04 <walters> bwnnfd: Hi; use the ignition/config/merge stanza, see https://coreos.github.io/butane/config-fcos-v1_4/

18:10 <dustymabe> we could probably use an example in our docs that gave a full example - copy/paste is definitely easier than parsing the config spec

18:10 <dustymabe> bwnnfd[m]: as you are working through it keep in mind this fact: https://discussion.fedoraproject.org/t/fcct-and-ignition-file-merge/19989/2

18:17 <bgilbert> bwnnfd[m] walters dustymabe: see the last example on https://docs.fedoraproject.org/en-US/fedora-coreos/remote-ign/

18:18 <bgilbert> sorry, the first example is a better bet

18:26 <dustymabe> bgilbert: perfect. I should have used the new search functionality in our docs

18:27 <bwnnfd[m]> Here is where I really demonstrate my ignorance. Is it as simple as passing that config (with my ignition URL and the correct hash) in the EC2 instance data?

18:28 <dustymabe> bwnnfd[m]: yes it should be. also you don't need to do the hash if you are accessing an `https` resource

18:28 <dustymabe> that's mostly useful if you are accessing insecure `http` resources

18:28 <dustymabe> bwnnfd[m]: maybe https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-aws/ would fill in some gaps

18:29 <bwnnfd[m]> Great, thank you. Very helpful.

18:29 <dustymabe> bwnnfd[m]: look at the bottom example there.. The text that starts "In order to launch a customized FCOS instance"

19:16 <jlebon> bgilbert: maybe we should document s3 and gs URLs there too

19:19 <bgilbert> https://github.com/coreos/fedora-coreos-docs/issues/430

19:50 <jlebon> +1