00:00:39 <adamw> #startmeeting F38 Final Go/No-Go meeting continued
00:00:39 <zodbot> Meeting started Fri Apr 14 00:00:39 2023 UTC.
00:00:39 <zodbot> This meeting is logged and archived in a public location.
00:00:39 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
00:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:00:39 <zodbot> The meeting name has been set to 'f38_final_go/no-go_meeting_continued'
00:00:49 <adamw> #topic Roll call
00:00:54 <adamw> who's still awake
00:01:06 <pboy> hi
00:01:14 <pboy> .hi
00:01:15 <zodbot> pboy: pboy 'Peter Boy' <pboy@uni-bremen.de>
00:01:16 <adamw> hi pboy
00:01:31 <farribeiro> .hi
00:01:32 <zodbot> farribeiro: farribeiro 'Fábio Ribeiro' <farribeiro@gmail.com>
00:01:49 <amoloney> morning!
00:02:00 <adamw> amoloney: you made it!
00:02:02 <adamw> #chair amoloney
00:02:02 <zodbot> Current chairs: adamw amoloney
00:02:06 <amoloney> I sure did :)
00:02:06 <adamw> handing over chair duties
00:02:07 <nirik> morning
00:02:23 <geraldosimiao> .hello geraldosimiao
00:02:24 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
00:02:31 <amoloney> 'light' chair duties please, Im still learning!
00:02:37 <geraldosimiao> here is 21h still
00:02:41 <adamw> =)
00:02:48 <amoloney> evening then :)
00:03:08 <amoloney> so is there a need to go back to test matrices?
00:03:20 <amoloney> or where best to begin for reconvened meetings?
00:03:44 <amoloney> well first I'll info I suppose
00:03:45 <nirik> drinking? sorry...
00:03:53 <mattdm> hi!
00:04:10 <adamw> i guess we can take a quick trip through the candidate and test matrix topics to update status
00:04:18 <adamw> this will give us more time to test stuff :P
00:04:54 <amoloney> #info the F28 Go/No Go meeting was paused temporarily while a new RC was staged. We will start with the testing matrices from this point as blockers remain unchanged
00:05:07 <geraldosimiao> F38
00:05:11 <geraldosimiao> not 28
00:05:49 <amoloney> ha whoops
00:05:51 <adamw> you can #undo and try again
00:05:52 <amoloney> F8
00:06:14 <amoloney> dang it Im having a mare
00:06:52 <amoloney> Im just copy pasting that info again with an edit if thats an ok shortcut
00:07:57 <amoloney> #info the previous info had a typo. The correct version of Fedora is F38 and the F38 Go/No Go meeting was paused temporarily while a new RC was staged. We will start with the testing matrices from this point as blockers remain unchanged
00:08:58 <amoloney> #topic Current Status - Test Matrices
00:09:16 <amoloney> #link https://fedoraproject.org/wiki/Category:Fedora_38_Test_Results
00:09:24 <adamw> so, obviously, we're not exactly full for RC-1.6 yet
00:09:28 <adamw> let me put things on the record...
00:10:03 <adamw> #info RC-1.6 is essentially unchanged from RC-1.5: the contents are the same, we just re-ran the compose to avoid the network issues that caused several images to fail in RC-1.5
00:10:28 <adamw> #info for this reason we will consider only 'smoke testing' of RC-1.6 necessary - that's testing the release-blocking images to be sure they boot and deploy normally
00:11:13 <adamw> we are currently in progress on that testing
00:11:27 * coremodule is here
00:11:35 <adamw> geraldo and I are working on workstation and kde, tflink is working on server, coremodule is working on arm images...where's everyone at?
00:12:02 <adamw> workstation live is good on bios and uefi
00:12:10 <adamw> i'm just finishing up the kde bios test
00:12:24 <geraldosimiao> and cheksumm is ok too, for workstation and kde
00:12:35 <geraldosimiao> and sway
00:12:38 <tflink[m]> Server x86_64 is good on previous KVM bios, hardware uefi
00:12:54 <pboy> working with server, but not nvme, biosboot
00:13:18 <nirik> worth noting that rc-1.6 only had silverblue aarch64 install image missing. This has been broken a while and we are not sure why. All other artifacts are included.
00:13:24 <geraldosimiao> will do everything iso now
00:13:37 <pboy> tflink including nvme issue?
00:14:36 <adamw> i'm grabbing the everything boot iso now
00:16:10 <adamw> in case it's not obvious, we are now spinning out the meeting while we do all the testing. :D
00:16:10 <tflink[m]> pboy: yep, did the same thing on the same machine when I first hit the nvme issue and didn't hit it
00:17:22 <pboy> thanks! I'm happy. :-)
00:21:16 <adamw> running bios install of everything netinst now
00:21:21 <coremodule> okay, all blocking aarch64 deliverables boot
00:21:26 <adamw> woohoo
00:21:32 <adamw> coremodule: wanna go onto cloud images?
00:22:01 <adamw> did you test the uefi boot of isos as well as disk images?
00:22:05 <coremodule> let me see what I can do, I haven't booted a cloud image in a while...
00:22:09 <coremodule> not yet, trying uefi now
00:22:21 <adamw> ok, you do the uefi thing then, i'll get onto cloud
00:22:25 <coremodule> rog
00:22:29 <geraldosimiao> I'll test basic video driver at bios, kde
00:22:40 <davdunc[m> coremodule: I'm around if you have difficulty.
00:23:00 <coremodule> thanks davdunc[m
00:23:10 <davdunc[m> ah. adamw ditto for you.
00:23:39 <adamw> davdunc (@davdunc:fedora.im): okay, since you're here: why can i never ssh into newly-created instances until i do some random fiddling with the security policies? :D
00:23:48 <adamw> whichever policy i  choose to apply to a newly-created instance, i can't ssh into it
00:23:59 <adamw> i have to create it, then apply a *second* policy to it, before i can get in
00:24:12 <davdunc[m> hmm. like a change in the security group?
00:24:15 <adamw> yeah
00:24:24 <adamw> it doesn't matter if i use an existing one or let the wizard create one for me
00:24:37 <davdunc[m> i have a script that I use in ansible to generate the security group at the same time that I build the instances.
00:24:47 <adamw> i just use the webui
00:25:17 <davdunc[m> ah. yea the only way to make that work from everywhere is to make it available from 0.0.0.0/0
00:25:24 <davdunc[m> and that's really not advised.
00:25:27 <adamw> that's what one of the policies i have set does, i think
00:25:39 <adamw> but if i use that one, i still can't ssh till i add another (more restrictive) one
00:25:54 <davdunc[m> let me whip up a security group modifier from the command line.
00:26:07 <adamw> i mean, i know how to workaround it now, it's just...weird. :D
00:26:51 <davdunc[m> yea.
00:27:02 <geraldosimiao> XFCE checksum is ok
00:27:05 <davdunc[m> unreachable by default. :D
00:27:15 <adamw> so yeah, i have a security group called 'default' which is set to allow 'all traffic', 'all' protocols, 'all' ports, inbound and outbound
00:27:24 <adamw> i created a new instance and applied that group to it
00:27:26 <adamw> and i can't ssh into it
00:27:48 <davdunc[m> https://paste.centos.org/view/38675a68
00:28:23 <davdunc[m> well, you may be running into the same cloud-init bug I just hit.
00:28:48 <adamw> now i add a group to it called launch-wizard-1, which only allows ssh
00:28:50 <adamw> and now i can ssh in
00:29:12 <adamw> but if i do it the other way round, same result (create the instance with 'launch-wizard-1', can't log in; add 'default', can log in)
00:29:13 <davdunc[m> aha.
00:29:59 <davdunc[m> there's something wrong with that default group. Either the protocol is defined incorrectly or there's something weird there.
00:30:13 <davdunc[m> it might be associated with the local network.
00:30:32 <adamw> but then why does adding that group to the launch-wizard-1 group make it work when i do things that way around?
00:30:35 <adamw> oh well, it's just weird.
00:30:45 <tflink[m]> adamw: have you done the EC2 tests?
00:30:50 <adamw> tflink (@tflink:fedora.im): i'm working on them
00:30:51 <davdunc[m> I'll have to look at it.
00:31:06 <adamw> davdunc (@davdunc:fedora.im): yeah, i can bug you agbout it later
00:31:11 <tflink[m]> k, I won't start them then
00:31:14 <adamw> just thought it might be a Known Issue or something
00:31:23 <adamw> tflink (@tflink:fedora.im): well, you can do the aarch64 ones?
00:31:24 <adamw> i'm on x86_64
00:31:51 <tflink[m]> do we upload aarch64 amis?
00:32:14 <adamw> yeah
00:32:17 <nirik> yep
00:32:20 <adamw> they're on the cloud page, but collapsed by default
00:32:31 <adamw> expand the header "arm64 hvm standard AMIs"
00:32:52 <tflink[m]> ah, for some reason, I read that as empty rather than collapsed
00:32:54 <adamw> (if we expand all the lists by default the page gets huge)
00:32:58 <tflink[m]> starting ec2 aarch64
00:36:51 <geraldosimiao> basic video driver at KDE / bios is OK
00:39:00 <adamw> everything netinst is good both bios and uefi
00:39:03 <adamw> doing server netinst now
00:39:35 <adamw> man, this is taking me back to the days when i actually tested stuff
00:40:00 <adamw> cloud tests on x86_64 are all good
00:40:03 <geraldosimiao> 😁
00:40:58 <geraldosimiao> will do workstation bios basic video driver now
00:41:02 <pboy> I test serever x84 dvd biosboot hardware and netinstall on uefi hardware, both are fine
00:41:25 <adamw> pboy: can you fill in the server dvd usb bios block on the matrix then? that one's missing
00:41:40 <tflink[m]> is there a default username/password for the cloud AMI? something that would work over serial console?
00:41:48 <adamw> tflink (@tflink:fedora.im): i just ssh in
00:42:00 <adamw> register an ssh keypair with ec2 and assign it to the instance then you can ssh in
00:42:22 <tflink[m]> yeah, I know how ec2 works. this instance isn't responding to ssh and I wanted to poke at it via serial console
00:42:26 <adamw> oh hah
00:42:31 <adamw> sorry, dunno, that'd be for davdunc
00:42:39 <adamw> i don't think there's a sekrit backdoor though
00:42:42 <pboy> adamw I'm still struggeling with that matrix, unfortunately. ashes on my head
00:42:53 <davdunc[m> no. The serial console doesn't work.
00:42:53 <adamw> pboy: `dnf -y install relval`, `relval report-results`
00:43:09 <davdunc[m> tflink: you can get the system log though.
00:43:20 <pboy> starting with server aarch64 SBC image, or did someone already test it?
00:43:20 <tflink[m]> davdunc: tried that, it's a blank
00:43:35 * nirik has used the serial console just fine... but the default image has no root pw set of course.
00:43:48 <tflink[m]> yeah, the console is working, I just can't log in
00:43:54 <davdunc[m> nirik: on aarch64?
00:44:08 <davdunc[m> I know it can work on the x86_64
00:44:08 <nirik> oh, perhaps not.
00:44:21 <davdunc[m> yea. I don't think it will work on arm.
00:44:33 <davdunc[m> let me look into that.
00:45:05 <davdunc[m> we can set the password in cloud-init
00:45:30 <adamw> pboy: coremodule already did i think, confirmation is always great of course
00:45:54 <adamw> i think all we have left to knock out is server x86_64 netinst (i'm working on that) and aarch64 cloud
00:46:01 <coremodule> aarch64 server dvd boots and installs with uefi
00:46:12 <adamw> yay
00:46:13 <coremodule> working on aarch64 server netinst uefi now...
00:46:27 <tflink[m]> davdunc: I have a responding serial console using t4g.medium, not sure if that's what you meant by working serial console, though
00:47:13 <davdunc[m> tflink: that's good enough for me.
00:47:22 * nirik waits for the testing to complete 🤞
00:47:53 <adamw> i think we should be good in another ~15-20 mins
00:48:44 <nirik> the openqa bot seems to be doing pretty well... knocking out lots of things there.
00:48:54 <tflink[m]> does anyone know how to set a root password @ creation time for an ec2 instance?
00:49:03 <geraldosimiao> media writer is fine, for F38 and F37
00:49:10 <tflink[m]> or would I have to create a custom AMI
00:49:18 <nirik> FYI, content is now fully synced out to alt/stage/
00:49:26 <davdunc[m> tflink: using cloud-config.txt, you can set it.
00:50:42 <davdunc[m> here's an issue off the web that describes it https://github.com/vmware/photon/issues/659#issuecomment-769450194
00:51:23 <geraldosimiao> doing server dvd checksum
00:53:56 <adamw> ok, i'm onto server netinst uefi
00:54:24 <geraldosimiao> I'll do server DVD bios
00:54:29 <geraldosimiao> usb bios
00:55:32 <pboy> geraldosimiao server dvd on biosboot x86 is working here
00:55:54 <geraldosimiao> oh, goo. then I'll test other thing
00:55:58 <geraldosimiao> aborting
00:56:41 <geraldosimiao> *good
00:57:17 <pboy> Just notice, it's 2 am here in Europe. cool action :)
00:57:37 <nirik> pboy++ thanks for testing things!
00:57:39 <zodbot> nirik: Karma for pboy changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
00:57:56 <pboy> oh thanks
00:58:20 * mattdm will check back later :)
00:58:28 <geraldosimiao> pboy++
00:58:28 <zodbot> geraldosimiao: Karma for pboy changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
01:00:30 * nirik will be back in a few min.
01:00:57 <adamw> server netinst uefi install running
01:01:08 <coremodule> the aarch64 server netinst will take a long time, fyi
01:01:16 <coremodule> like an hour give or take
01:01:50 <geraldosimiao> i3 doing fine too
01:02:24 <pboy> server aarch raw.xz works fine, too
01:02:36 <adamw> coremodule: you know, if it made it to the install phase, we can probably say it's good
01:02:52 <geraldosimiao> pboy can I fill the test matrix with your username, at server dvd biosboot success?
01:03:12 <coremodule> adamw, works for me. I'm not there yet (image still writing), but I'll let oyu know
01:03:13 <pboy> yes please ! I have to learn it
01:03:24 <tflink[m]> ok, got the ec2 ami communicating. finishing up the other basic tests
01:03:26 <coremodule> pboy, which aarch64 hardware are you using?
01:03:27 <tflink[m]> ec2 aarch64 ami
01:03:48 <pboy> rockpro64 an d rockpi 4
01:03:55 <coremodule> pboy, cool!
01:04:03 <adamw> ok, server netinst x86 is all good
01:04:29 <coremodule> I lied when I said aarch64 server dvd uefi was done.
01:04:41 <coremodule> It was *almost* done, and I thought it would just be a little longer.
01:04:55 <coremodule> It's still chugging away. No problems, just takes for fricken ever
01:05:35 <adamw> heh
01:07:42 <geraldosimiao> I'll do checksum cloud images
01:11:45 * nirik is back
01:13:20 <adamw> alrighty, where we at
01:14:03 <adamw> we're waiting on the aarch64 cloud tests and aarch64 uefi tests i believe
01:14:11 <adamw> that should be it
01:14:44 <nirik> openqa seems to have finished or softfailed all the x86_64 tests... still churning on the aarch64 ones
01:15:19 <tflink[m]> almost done with the aarch64 ami test
01:16:06 <adamw> yeah, openqa aarch64 takes a while, i wouldn't wait on it
01:18:17 <nirik> fair enough
01:18:55 <geraldosimiao> checksums are good
01:19:38 <geraldosimiao> installing budgie now, just in case
01:20:24 <tflink[m]> ec2 aarch64 passed
01:21:21 <adamw> yay
01:22:08 <nirik> so just aarch64 uefi?
01:23:12 <adamw> yup
01:23:28 <tflink[m]> isn't coremodule working on that?
01:24:08 <coremodule> yeah, it takes forever
01:24:29 <coremodule> I'm almost(?) done with aarch64 server dvd uefi
01:25:02 <coremodule> disks are burned for netinst, so I'll get it to the installer and then report back, we can get the meeting going and I'll just let it install while we do.
01:25:31 <adamw> yeah, i think if server dvd completes and netinst reaches install phase, we're good
01:26:19 <dustymabe> 🎉
01:26:38 * tflink[m] is poking at a form of win11 dual-boot and mac fmw but neither of those are blocking
01:27:09 <geraldosimiao> coremodule: I'll fill an "inprogress" with your name at the test matrix
01:27:32 <geraldosimiao> for aarch64 usb uefi server dvd
01:28:45 <coremodule> thanks geraldosimiao
01:28:59 <geraldosimiao> oh, good, robatino double checked the checksums too.
01:29:43 <geraldosimiao> ho did aarch64 usb uefi server netinst ?
01:30:09 <coremodule> geraldosimiao, me, not there yet
01:30:11 <tflink[m]> geraldosimiao: i think that coremodule is about to start that
01:30:24 <geraldosimiao> ok, no problem
01:31:09 <adamw> #info at this point smoke testing of rc-1.6 is almost complete with no problems appearing
01:32:09 <geraldosimiao> Adam, the vms you build, the host was F38 or F37?
01:32:35 <geraldosimiao> we dont have "current KVM" filled at virtualization matrix
01:34:13 <pboy> geraldosimiao I installed libvirt and our Server KVM without issue, if that helps
01:35:29 <adamw> geraldosimiao: openqa effectively crosses that off, i guess, since it's running f37.
01:35:42 <adamw> or wait, does 'current' mean 'the same release' in this context
01:35:43 <geraldosimiao> ok
01:35:43 <adamw> anyway, meh
01:35:52 <geraldosimiao> current means f38
01:35:53 <adamw> i'm running f38 on my laptop and i can start vms, so it's fine. :P
01:35:57 <adamw> hold on a sec
01:35:59 <Eighth_Doctor> so did we do it?
01:36:20 <Eighth_Doctor> .hello ngompa
01:36:24 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
01:36:34 <nirik> hey Conan Kudo
01:36:43 <adamw> i'll run an install in a vm while we wait for coremodule. :P
01:36:48 <coremodule> oof
01:36:51 <coremodule> almost there
01:36:51 <adamw> Conan Kudo: we're just finishing up testing, but it looks good
01:36:57 <Eighth_Doctor> yay
01:37:01 <coremodule> dvd works, plugging in the netinst drives now
01:37:20 <Eighth_Doctor> I threw LXQt up and it worked okay
01:37:28 <Eighth_Doctor> or at least not worse than the previous compose
01:38:14 <geraldosimiao> here:     Prepare a machine with the current development release (Fedora 38) installed
01:38:14 <geraldosimiao> Install Package-x-generic-16.pngvirt-manager (or other tool to control KVM virtual machines)
01:38:14 <geraldosimiao> If you want to test your guest system using UEFI, you need to set it up first.( Note: IoT testing requires UEFI.)
01:38:38 <geraldosimiao> adamw: I filled with your name there
01:38:51 <adamw> thanks
01:40:22 * nirik waits for the USS 🛳️it so he can go have some dinner. ;)
01:40:57 <Eighth_Doctor> seems Weston is installed in the LXQt image still, which makes the installed environment default to it
01:40:59 <Eighth_Doctor> that's fun
01:42:01 * Eighth_Doctor is checking to see if that was the case in F37 now
01:42:14 <geraldosimiao> Fedora-Budgie-Live-x86_64-38-1.6.iso installed and booted fine
01:42:59 <nirik> weston, wayland...all towns in the same state at least. :)
01:43:09 <Eighth_Doctor> hehe
01:43:24 <geraldosimiao> see you're already using the "emoji version" at words nirik lol
01:43:33 <coremodule> okay, aarch64 uefi server netinst makes it to the installer, no issues.
01:43:55 <nirik> Yeah, as I get more 😫 I start using more. ;)
01:44:16 <geraldosimiao> Fedora-Server-dvd-x86_64-38-🥱.6.iso
01:45:57 <adamw> current kvm is just fine
01:46:22 <adamw> alright
01:46:25 <adamw> i think we can say we're good
01:46:35 <adamw> #info Sufficient smoke testing of RC-1.6 has been completed without any problems
01:46:43 <amoloney> hurray!
01:47:20 <amoloney> #topic Current Status - RC
01:47:37 <adamw> #info RC-1.6 has all images except aarch64 silverblue, and no known blockers
01:48:05 <amoloney> is it time to poll?
01:48:18 <Eighth_Doctor> oh lol, I think sddm is running in weston on lxqt 38
01:48:28 <adamw> well, next topic
01:48:54 <amoloney> exciting! Thats the decision one :)
01:49:05 <adamw> we do need to hit on IoT and CoreoS
01:49:06 <amoloney> #topic Go/No Go decision
01:49:07 <adamw> which i forgot earlier
01:49:11 <adamw> so, before we vote
01:49:17 <adamw> pbrobinson: not around, are you?
01:49:24 <coremodule> I can speak for IoT
01:49:39 <coremodule> for pbrobinson, pwhalen
01:49:53 <adamw> i think technically we should wait for the next IoT compose and ship that, right?\
01:49:59 <nirik> if lorax speaks for the trees, who speaks for the ostrees? :)
01:49:59 <adamw> since we only just pushed the last packages stable today
01:50:08 <coremodule> We wanted 20230413.0
01:50:12 <coremodule> We are on 20230413.4
01:50:20 <adamw> and given https://pagure.io/releng/issue/11099 we might actually need to do *two* composes
01:50:26 <dustymabe> 👋
01:50:28 <adamw> ...or four! four is also good!
01:50:28 <Eighth_Doctor> O.o
01:50:31 <Eighth_Doctor> that's... weird
01:51:08 <coremodule> I've been messing with 20230413.4 since it composed (~1.5hrs), think we're good to go with that particular image.
01:51:28 <adamw> coremodule: does it have all the stuff we pushed stable earlier?
01:51:42 <adamw> https://pagure.io/releng/issue/11306#comment-851442 ?
01:52:14 <coremodule> Good question, let me see...
01:52:27 <dustymabe> i can speak for FCOS
01:53:25 <adamw> for fcos i assume we're fine, since i asked and nobody said there were any problems :D
01:53:53 <dustymabe> the `next` we shipped yesterday to end users was pretty close to the final package set
01:54:02 <coremodule> adamw, I don't think any of those changes apply to IoT anyway...
01:54:11 <coremodule> f38 backgrounds, definitely not
01:54:33 <adamw> anaconda would be in there
01:54:35 <adamw> not sure about fuse3
01:54:39 <coremodule> yeah, good point
01:54:54 <dustymabe> the most recent `next-devel` compose includes the updates from https://pagure.io/releng/issue/11306#comment-851164 but not the ones from the most recent push https://pagure.io/releng/issue/11306#comment-851442
01:55:09 <coremodule> im booting an image now. I know the most release compose was made like an hour and a half ago. Don't know for certain if those packages were explicitly pulled in. trying to check now
01:55:09 <dustymabe> so I think at this point we're just missing the fuse3 update
01:55:28 <adamw> it has the older anaconda, according to https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-38-20230413.4/logs/x86_64/IoT/ostree_installer-2/pylorax.log
01:55:47 <dustymabe> but I don't anticipate any problems there?
01:56:06 <adamw> dustymabe: well, the fuse3 update is for a container issue, so it's probably relevant
01:56:13 <dustymabe> adamw: indeed
01:56:20 <adamw> it'd be good to make sure that when we cut fcos over to f38 'officially', it has the fuse3 update
01:56:44 <dustymabe> there be a new `next-devel` in the morning and we'll probably cut a new `next` tomorrow and ship it out to our users
01:57:00 <dustymabe> that same content will get promoted to `testing` on Tuesday
01:57:13 <adamw> the anaconda change is for fixing crash reporting when packaging.log is empty, which actually probably does apply to both coreos and iot
01:57:16 <dustymabe> so our users will have 3 days or so to report any major issues :)
01:57:24 <adamw> rgr
01:57:27 <adamw> sounds like fcos is fine
01:57:31 * dustymabe notes coreos doesn't use anaconda
01:57:41 <adamw> oh, right, i always forget we don't have an anaconda installer image for it.
01:57:54 <adamw> so, fcos has a plan
01:58:04 <dustymabe> adamw: we always have a plan!
01:58:12 <adamw> for iot we probably want to try and make sure we get a compose with new fuse3 in the ostree and new anaconda on the installer image
01:58:15 <adamw> heh
01:58:58 <adamw> coremodule: do you see any problems making sure we have an iot compose ready by, say, tomorrow?
01:59:11 <adamw> who does that have to be synced up with? releng?
01:59:34 <coremodule> yeah, good question. I think pwhalen is handling the image builds these days...
02:00:17 <adamw> nirik (@nirik:libera.chat): can you kick off iot composes?
02:01:20 <nirik> I've not ever done so, dunno how off hand...
02:01:30 <adamw> oh, fun
02:01:36 <nirik> it's using osbuild
02:01:50 <nirik> huh, there's one running now?
02:01:51 <adamw> i assumed it was just a slightly different pungi command or whatever
02:01:56 <adamw> there is? well that's...good?
02:01:56 <nirik> https://koji.fedoraproject.org/koji/taskinfo?taskID=99907669
02:02:17 <adamw> oh, the .4 one? that's the one i was looking at
02:02:21 <adamw> it still has the older anaconda in it
02:02:47 <nirik> yeah, thats 38.20230413.4 apparently.
02:02:54 <coremodule> yeah, pwhalen kicked that off maybe 2 hours ago
02:03:01 <adamw> meanwhile, we're gonna hit 100 million koji tasks soon. yikes.
02:03:37 <pwhalen> adamw: we've been having some network issues with osbuild. I'll make sure we pull in the new packages for the official compose devel->stable
02:03:53 <adamw> huh. it used the newer fuse3 but the older anaconda. why
02:04:00 <adamw> okay
02:04:12 <adamw> pwhalen: we just need to make sure the timeframe is workable
02:04:26 <adamw> aiui we need releng to know what the Final Compose for iot is for staging tomorrow, is that right nirik?
02:05:01 <pwhalen> Right, planning a sync with pbrobinson tomorrow to discuss. I think our is handled separately
02:05:23 <nirik> yeah, I think it's sperate since it has it's own ostree dir/tree...
02:05:28 <adamw> well, it all still has to be staged and synced out and ready to go on tuesday, right?
02:05:45 <pwhalen> understood
02:05:45 <adamw> fcos follows its own schedule to an extent but aiui we expect the iot bits ready to go same day as regular
02:05:54 <nirik> ideally for sure.
02:06:31 <adamw> okay, well...it's not ideal that we're always kinda leaving this part to the last minute, but i guess it's probably okay to trust we can pull it together
02:06:37 <nirik> so, those sorted? move on to decision process?
02:07:16 <nirik> this is more last minutely than we have had in a while. ;)
02:07:54 <adamw> yeah, let's just sign this damn thing off, i need dinner
02:08:09 <amoloney> #topic Polling
02:08:10 * dustymabe notes we strive hard to ship our `testing` stream with the GA content set
02:08:16 <dustymabe> on GA day
02:08:17 <adamw> per the QA policy, there are no blockers, test coverage is sufficient, we're not looking too hard at IoT, therefore QA votes go
02:08:33 <adamw> for rc-1.6, that is
02:08:38 <amoloney> Ack
02:08:41 <amoloney> FESCo?
02:08:55 <nirik> go go go
02:09:00 <amoloney> Ack
02:09:03 <amoloney> RelEng?
02:09:07 * nirik swaps another hat on
02:09:11 <nirik> releng is go
02:09:15 <amoloney> Ack
02:09:31 <amoloney> #agreed Fedora Linux 38 Final is GO
02:09:44 <Eighth_Doctor> we... did it?
02:09:46 <amoloney> #info Fedora Linux 38 Final will release on the early target date (2022-04-17)
02:09:46 <adamw> it's all niriks, all the way down
02:09:54 <itguyeric> Eeek!!
02:09:55 <pboy> Hurray!
02:09:56 <nirik> hurray!
02:09:59 <adamw> we did! and with absolutely strict following of all policies and procedures, no less
02:10:00 <geraldosimiao> 18-04
02:10:05 * adamw keeps straight face
02:10:05 <Eighth_Doctor> oh my!
02:10:08 <geraldosimiao> not 17-04
02:10:14 <amoloney> good grief
02:10:17 <Eighth_Doctor> April 18
02:10:20 <Eighth_Doctor> not 17
02:10:23 <geraldosimiao> yeah
02:10:24 <adamw> #undo
02:10:24 <zodbot> Removing item from minutes: INFO by amoloney at 02:09:46 : Fedora Linux 38 Final will release on the early target date (2022-04-17)
02:10:28 <adamw> try again :)
02:10:35 <amoloney> thank you :)
02:10:44 <amoloney> this would technically be right yesterday...
02:10:57 <dustymabe> if someone wants to LGTM this FCOS fast-track for fuse3 I can get our processes started a bit sooner: https://github.com/coreos/fedora-coreos-config/pull/2370
02:11:21 <amoloney> #info Fedora Linux 38 Final will release on the early target date (2022-04-18)
02:11:30 <dustymabe> FTR - CoreOS is 👍 for GO
02:11:39 <geraldosimiao> 🎉
02:11:43 <nirik> hurray for go
02:11:49 <geraldosimiao> go!!!!!
02:11:56 <amoloney> #action amoloney to announce decision
02:12:03 <geraldosimiao> 🚀
02:12:04 <amoloney> #topic Open Floor
02:12:05 <farribeiro> 🎉
02:12:24 <amoloney> Congrats all and serious kudos to those testing!!!
02:12:39 <adamw> allllrighty
02:12:39 <geraldosimiao> adamw: Bug 2172854 will be at common-issues then.
02:12:50 <adamw> welp that's the first time we ever hit *both* early target dates, good lord
02:12:54 <amoloney> is there anything else or shall we drop the curtain?
02:13:03 <adamw> geraldosimiao: yeah, unfortunately
02:13:11 <geraldosimiao> ok
02:13:26 <adamw> i don't think we have to decide anything else here
02:13:33 <adamw> you can do a quick open floor in case anyone has anything
02:13:51 <amoloney> I did, were open right now :)
02:14:01 <geraldosimiao> I'm hungry and need sleep 😂
02:14:14 <coremodule> open floor? lets do karaoke
02:14:23 <amoloney> littered the log with typos but i managed that command ok I think :-D
02:14:25 <geraldosimiao> open bar?
02:14:27 <itguyeric> I’m down for that!
02:14:32 <amoloney> +1
02:15:04 <geraldosimiao> 🍻
02:15:08 <adamw> oh i missed it :D
02:15:20 <adamw> thanks for all the last minute testing everybody, great job
02:15:35 <nirik> yeah, many thanks everyone.
02:15:42 * nirik heads to find some dinner.
02:16:03 <adamw> that sounds like a plan
02:16:13 <dustymabe> adamw++
02:16:20 <dustymabe> thanks all for the hard work
02:17:31 <amoloney> if thats all then thanks folks, ending this meeting now
02:17:34 <amoloney> #endmeeting