01:54 <dustymabe> quentin9696[m]: is it you who opened https://github.com/coreos/fedora-coreos-tracker/issues/1487 ?

01:55 <quentin9696[m]> dustymabe: no, but I opened [the ](https://github.com/fedora-selinux/selinux-policy/issues/1675)

01:55 <quentin9696[m]> s/[the ](//

01:55 <dustymabe> either way maybe your issue is https://bugzilla.redhat.com/show_bug.cgi?id=2188714 ?

01:57 <quentin9696[m]> nope, it's not

01:58 <dustymabe> different SELinux issue

01:58 <quentin9696[m]> but I think all those issues have a common point: the fact that wg-quick let us create PostUp directives where we can call whatever we want

01:58 <dustymabe> I guess

01:59 <dustymabe> quentin9696[m]: right

01:59 <dustymabe> I subscribed to the GH issue. The maintainers don't always engage there though

01:59 <quentin9696[m]> on my side, it's the fact I use systemd-creds, in the bugzilla it's because he's trying to use iptables, and in the coreos tracker it's because he's using ip route

02:00 <dustymabe> it would help if you could work with both the selinux maintainers and the wireguard maintainer to figure out the best path forward - sounds like confining wireguard might be harder than originally thought

02:00 <dustymabe> or maybe the default policy could be to keep it confined like it is today but have an selinux boolean escape hatch for running these other programs

02:01 <dustymabe> that selinxu boolean may exist already :)

02:01 <quentin9696[m]> I'm not sure how we can solve this. I'm new to SE Linux and I don't know what is the best way to manage that

02:01 <dustymabe> quentin9696[m]: exactly - that's why it would be best to work with the maintainer of wireguard and selinux

02:01 <dustymabe> quentin9696[m]: it would be useful for you to state in the BZ and the FCOS issue your summary that you gave me above

02:02 <dustymabe> i.e. there's a common thread here even if the exact issue wasn't the same

02:02 <dustymabe> i.e. the symtoms are a pattern of the same problem (just used in different ways)

02:02 <quentin9696[m]> dustymabe: that's exactly what I think. Keep the confine mode for common basic usecase, and let us create excaptions for other common usage, like iptables, ip route or systemd-creds

02:03 <quentin9696[m]> dustymabe: Yeup I'll do that

02:03 <quentin9696[m]> dustymabe: This is what I did for the SE linux part, I'll also create something on the wireguard side, thanks for the advise

02:06 <dustymabe> quentin9696[m]: np - the work you're doing (if we can get everyone pulled together) will help everyone. It's clearly been hit several times already

02:07 <dustymabe> quentin9696[m]: also.. if you have any extra compute capacity running `testing` or `next` streams will help you find problems like this before it gets to `stable`

02:12 <quentin9696[m]> We already have servers that needs systemd 253 features that are running next stream

02:12 <quentin9696[m]> dustymabe: I use coreos at work, and it's where I face the issue this morning after the auto-update. I saw your testing day and we plan to do something, but my teams is pretty new and we didn't find the time to do it. But I'm 100% agree with you and we will try for the next major release (at least major)

02:23 <dustymabe> quentin9696[m]: nice.. do you mind if I ask where you work? (can send a PM if not comfortable with public)

02:23 <dustymabe> i'm always interested in how people/organizations are using FCOS

02:25 <quentin9696[m]> So, I updated in all side. I'm not sure if Wireguard is involve in that issue, since it only involve SE Linux policies and Pre/Post actions on wg-quick which is basically an exec command

02:29 <quentin9696[m]> <dustymabe> "quentin9696: nice.. do you..." <- I PM you

02:37 <dustymabe> quentin9696[m]: I sent you a PM on here. did you get it? I didn't get yours

02:38 <quentin9696[m]> dustymabe: I receive your but don't think you get mine. I'm on matrix, so it may cause troubles

02:39 <quentin9696[m]> > <@dustymabe:libera.chat> quentin9696: I sent you a PM on here. did you get it? I didn't get yours

02:39 <quentin9696[m]> * I receive yours but don't think you don't get mine. I'm on matrix, so it may cause troubles

02:40 <dustymabe> one sec - let me try to log in elsewhere

12:20 <fifofonix> quentin9696[m]: glad to hear others out there are running next! we def need more of that.

12:55 <fifofonix> dustytmabe: to test the cifs issue i think i am going to need an f39 rawhide build. `sudo rpm-ostree rebase fedora-compose:fedora/x86_64/coreos/rawhide` failing for me rn.

12:56 <fifofonix> dustymabe: ^, what should i expect from rawhide, like can i choose a prior build easily if the latest is failing etc etc.

13:31 <dustymabe> fifofonix: the link from the BZ was just telling you how to grab the RPM

13:31 <fifofonix> dustymabe: but the rpm is f39 and won't install on a next node, so i think i need to update.

13:31 <dustymabe> you'd have to get the *.rpm files and then `rpm-ostree override replace foo.rpm bar.rpm` etc.

13:32 <dustymabe> yeah, right - easier if you are on the `rawhide` stream already

13:33 <dustymabe> what failure are you getting from the rebase?

13:34 <quentin9696[m]> quick question: if I have a FCOS 37, and I keep the auto updates, what happened when zincati will run ? It will update to FCOS 38 ?

13:39 <dustymabe> quentin9696[m]: yes, eventually

13:39 <dustymabe> we "roll" on

13:40 <fifofonix> dustymabe: my bad. my terraform cicd is too clever. it adjudged no ignition change so didn't zap node like i thought it would. so this is f38 stuck node due to curl issue.

13:40 <dustymabe> if you notice F38 was released 2 weeks ago but we hold it back from the stable stream for a period of time longer to hopefully identify issues

13:41 <dustymabe> we try to be practical about holding or pushing based on known issues - usually discuss at the community meetings on Wednesday's

13:41 <quentin9696[m]> that's what I was thinking too. I'll temporary disable auto update, while my wireguard issue is not fix or I find a work around. Safer for production environment

16:16 <dustymabe> jlebon: this should get us migrated over to what we want in terms of rerun success: https://github.com/coreos/coreos-ci-lib/pull/148 I think

16:17 <dustymabe> i still need to test it

16:40 <jlebon> dustymabe: reviewed!

17:15 <dustymabe> jlebon: for https://github.com/coreos/coreos-assembler/issues/3456 is that happening because we recently changed the meta.json output for kubevirt?

17:16 <dustymabe> in https://github.com/coreos/coreos-assembler/pull/3438

17:28 <jlebon> dustymabe: i'm not sure on the full history, but essentially, we're not outputting the right release metadata (which then gets turned into stream metadata)

17:28 <jlebon> i don't think https://github.com/coreos/coreos-assembler/pull/3438 is the issue. i think it's just when kubevirt support was initially added to generate-release-meta

17:29 <jlebon> i started hacking on this but have to leave now. i can finish it up early next week if no one picked it up.

17:29 <jlebon> ttyl!

19:05 <dustymabe> gursewak: marmijo[m]: mind a review on https://github.com/coreos/fedora-coreos-pipeline/pull/871 ?

19:06 <dustymabe> hopefully once we merge that and https://github.com/coreos/coreos-ci-lib/pull/148 we can look at many fewer pipeline flakes

19:07 <dustymabe> or... at least we'll be able to ID the next class of flakes to take on

20:07 <dustymabe> walters: have I made you proud? https://github.com/coreos/fedora-coreos-tracker/issues/1447#issuecomment-1536706863

20:14 <walters> thanks for trying it out

20:24 <dustymabe> I'll probably move my silverblue config (at least the layered packages) over to it at some point since I have multiple silverblue machines.

20:45 <dustymabe> walters: the container from https://github.com/coreos/fedora-coreos-tracker/issues/1447#issuecomment-1536706863 did build and I was able to rebase a system to it. did I just get lucky?