07:00 <michele> I set my rollout_wariness = 1 in my zincati config, and I am on N-1 release (38.20230414.3.0) - my zincati strategy is "periodic" and periodic window is set for days = [ "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun" ] at 02:00. I know that the newest release (38.20230430.3.1) has been out since May 15. When should my zincati pick up the updates?

14:13 <dustymabe> hey jlebon - travier[m] - anyone else -- want to get together before the community meeting today (maybe at the turn of the next hour) and do some pre-filtering of https://github.com/coreos/fedora-coreos-tracker/issues/1491 ?

14:14 <jlebon> WFM

14:32 <travier[m]> dustymabe: wfm too

14:32 <travier[m]> I'm free until the community meeting

14:50 <dustymabe> cool - will drop a link at the turn of the hour

14:50 <dustymabe> for now brb

15:01 <dustymabe> https://meet.google.com/wyw-need-tgq

15:05 <dustymabe> jlebon: travier[m] ^^

15:06 <dustymabe> michele: what do the logs from zincati say? `sudo journalctl -u zincati`

15:07 <michele> dustymabe: zincati[2687048]: [ERROR zincati::cincinnati] failed to check Cincinnati for updates: server-side error, code 502: (unknown/generic server error)

15:08 <dustymabe> michele: the rollout window hasn't finished for the 38.20230430.3.1 release and the wariness of 1 means you want to wait until the rollout window has completed (IIUC)

15:09 <dustymabe> so basically your system should complete the update tomorrow night

15:09 <michele> dustymabe: how do I know when the rollout window is finished?

15:09 <dustymabe> the rollout window finishes up tomorrow around this time

15:09 <dustymabe> jlebon: travier[m] here's the hackmd link https://hackmd.io/OY3Y2FsFSw2uIkC881b2rg?view

15:09 <michele> (w/o asking you ;))

15:10 <dustymabe> michele: in general you don't - your systems passively pick up the update when the parameters that we and you allow

15:10 <michele> dustymabe: no I mean, is there a tracker for checking "rollout completed for everybody"

15:10 <dustymabe> michele: but you can view the sources of the information here: https://github.com/coreos/fedora-coreos-streams/pull/711

15:10 <michele> or, IOW, how do you know that "the rollout window hasn't finished"

15:11 <michele> 2023-05-16 18:00:00+02:00 Berlin/France/Poland

15:11 <michele> got it

15:11 <michele> thanks dustymabe

15:11 <dustymabe> we (or anyone) can know the rollout hasn't finished because we know the start time and the duration

15:11 <dustymabe> michele: no problem

15:11 <michele> I meant: 2023-05-16 18:00:00+02:00 Berlin/France/Poland+duration: 2880m (48.0h)

16:20 <dustymabe> walters: jmarrero: I'm trying to understand the versions on GitHub for `ostree`: https://github.com/ostreedev/ostree/tags

16:20 <dustymabe> why do we seem to alternate between 0.x.y format and 202x.y format ?

16:29 <dustymabe> aaradhak anthr76 apiaseck davdunc dustymabe gursewak jaimelm jbrooks jcajka jdoss jlebon jmarrero lorbus miabbott nasirhm quentin9696[m] ravanelli saqali walters

16:29 <dustymabe> FCOS community meeting in #fedora-meeting-1

16:29 <dustymabe> If you don't want to be pinged remove your name from this file: https://github.com/coreos/fedora-coreos-tracker/blob/main/meeting-people.txt

16:42 <jmarrero> dustymabe: AFAIK we only consume the 202x.y format in fedora/rhel but the 0.x.y is for rust/cargo following their versioning conventions: https://crates.io/crates/ostree but I could be wrong :D

16:48 <dustymabe> jmarrero: good to know

16:48 <dustymabe> so rust requires semver?

16:49 <dustymabe> wondering if we could just modify to use 202x.y.z format and unify the version numbering

16:49 <dustymabe> anyway.. the reason I was asking is because I'm trying to figure out when an upstream PR will land in a release/RPM for https://github.com/coreos/fedora-coreos-tracker/issues/1467#issuecomment-1551708677

16:57 <jmarrero> dustymabe: I think cargo does and the cargo-release tool seems to expect only semver: https://github.com/crate-ci/cargo-release/blob/master/docs/reference.md?plain=1#L85 but I am not sure what we would break if we change versioning schemes. I bet Colin has some reason to not just use semver. As for a ostree release I can check later today and let you know a ETA by EOD.

17:00 <dustymabe> thanks jmarrero~~

17:00 <dustymabe> jmarrero++

17:00 <zodbot> dustymabe: Karma for jmarrero changed to 1 (for the release cycle f38): https://badges.fedoraproject.org/tags/cookie/any

17:07 <walters> yeah the tags are combined now unfortunately, but separate repositories was worse

17:08 <dustymabe> walters: ahh so it was because it used to be a separate repo for the rust bits

17:08 <dustymabe> could we switch to 202x.y.z format and unify it all?

17:08 <walters> I'd like to fold in ostree-rs-ext too which would worsen this problem, but maybe that can be solved by folding the crates

17:09 <walters> eventually probably the fix is ostree stops being a CLI tool and turns into a library completely, then effectively we'd only be releasing a rust crate (eventually)

18:04 <jmarrero> dustymabe: we should have one by end of tomorrow.

19:34 <dustymabe> jmarrero: youfast!

19:47 <jmarrero> dustymabe: let's see ;) maybe I am under estimating.

20:03 <dustymabe> there's adding kernel arguments and then there is ADDING KERNEL ARGUMENTS: https://github.com/glenmillard/ButaneIgnitionFiles/blob/d2ef4022bbf8f575ea37b7d71c4fb532578e43b5/GlenGeneric.ign#L5-L31

20:03 <dustymabe> something tells me UKI won't be ideal for this person