13:17 <dustymabe> \o

13:32 <dustymabe> saqali: let me ask over in #fedora-releng about the zlib package downgrade

13:48 <dustymabe> saqali: i opened https://pagure.io/releng/issue/10875

13:48 <saqali> thanks!

13:50 <dustymabe> saqali: how are things - anything I should look at?

13:51 <saqali> This run was a little suspicious https://coreos.slack.com/archives/C02AEJGDT1N/p1656951058526069?thread_ts=1656939796.171729&cid=C02AEJGDT1N

13:53 <travier[m]> I need someone to cover Fedora CoreOS news and topics for the OKD WG Meeting today

14:02 <lucab> dustymabe, jlebon: in case you missed it https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/DCBRZP5URNEYY5RS5Y45Q3RBWTVW332P/

14:05 <dustymabe> travier[m]: i'm going to the FESCO meeting at the same time, but can try to join the OKD one too

14:19 <dustymabe> lucab: ha - I can't even get to that link - I think infra team is having some troubes this morning

14:21 <lucab> dustymabe: eheh. They were just asking about some rabbitmq users, including the `coreos` one, to restrict the topics they can publish to.

14:22 <dustymabe> interesting.. i might be able to find that email in my inbox

14:22 <lucab> "Topic authorization on RabbitMQ" on infrastructure@

14:25 <dustymabe> thanks

15:06 <dustymabe> cverna: I'd say for today just don't worry about the releases - robosignatory has a large queue - we'll see if it chews through it all today and try again tomorrow

15:06 <dustymabe> i'll kick of the builds later if I see it clearing up

15:08 <cverna> sounds good

16:42 <dustymabe> gursewak: looks like it will take care of the problem: https://github.com/openshift/os/issues/873#issuecomment-1175266137

16:43 <gursewak> Got it.

16:59 <io7m> is it a known issue that NetworkManager-wait-online.service always fails on Vultr right now? i've been creating and destroying a lot of VMs lately for research purposes, and i've never once booted a VM without being informed that the unit failed on logging in

16:59 <io7m> everything seems to actually work correctly, that unit just seems to have failed without an error message

17:01 <dustymabe> io7m: interesting

17:01 <dustymabe> i don't think it's a known issue

17:02 <io7m> is there anything i could do that would be helpful? i'm sitting at a VM right now with the failed unit :)

17:03 <dustymabe> io7m: maybe open an issue?

17:03 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues

17:04 <io7m> oh, right

17:04 <dustymabe> including the full journal output (upload a file) would be useful probably

17:04 <io7m> yep

17:13 <io7m> dustymabe: https://github.com/coreos/fedora-coreos-tracker/issues/1246

17:14 <io7m> ... i've just realized the issue template asked for an ignition file and not a butane file

17:17 <dustymabe> io7m: that's fine - butane should be good

17:18 <io7m> it seems to happen even with a minimal does-nothing butane file, but i've attached everything anyway

17:19 <io7m> passwords and keys and so on are generated at random each time (i'm generating the butane files), so i don't care about any credentials that appear there

17:21 <io7m> i'm happy to give ssh access at a later date if someone wants to log in and poke around

17:28 <dustymabe> saqali: https://github.com/coreos/fedora-coreos-config/pull/1810/files#r914033169

17:33 <saqali> dustymabe: thx

18:37 <dustymabe> io7m: do you do anything to the networking on these boxes? For example, I see enp6s0 and enp1s0 in the logs, but on my instance I just created I only see enp6s0

18:37 <dustymabe> io7m: do you do anything to the networking on these boxes? For example, I see enp6s0 and enp1s0 in the logs, but on my instance I just created I only see enp1s0

18:44 <dustymabe> io7m: commented here: https://github.com/coreos/fedora-coreos-tracker/issues/1246#issuecomment-1175377397

19:25 <dustymabe> hmm "dracut: dracut: using auto-determined compression method 'pigz'"

19:26 <dustymabe> ahh, it's just parallel gzip