16:00:18 #startmeeting F39-blocker-review 16:00:18 Meeting started Mon Oct 9 16:00:18 2023 UTC. 16:00:18 This meeting is logged and archived in a public location. 16:00:18 The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:00:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:18 The meeting name has been set to 'f39-blocker-review' 16:00:18 #meetingname F39-blocker-review 16:00:18 The meeting name has been set to 'f39-blocker-review' 16:00:18 #topic Roll Call 16:00:22 ahoyhoyhoy folks 16:00:27 how's everyone diddly-doing 16:00:38 .hello2 rishi 16:00:39 rishi: rishi 'Debarshi Ray' 16:00:40 just diddly 16:00:45 .hello2 16:00:46 coremodule: coremodule 'Geoffrey Marr' 16:01:08 .hello2 16:01:09 nielsenb: nielsenb 'Brandon Nielsen' 16:01:31 hi geraldo 16:01:38 hello 16:02:03 .hello ngompa 16:02:04 Son_Goku: ngompa 'Neal Gompa' 16:02:08 .hello geraldosimiao 16:02:10 geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' 16:03:23 #chair geraldosimiao son_goku 16:03:23 Current chairs: adamw geraldosimiao son_goku 16:03:35 * kparal is here 16:03:37 boilerplate alert! 16:03:43 * lruzicka is here, too 16:04:02 lruzicka: good, i'm glad you're taking my message to heart and prioritizing the *important* stuff 16:04:15 adamw, I am all yours today :D 16:04:17 hehe 16:04:21 #topic Introduction 16:04:21 Why are we here? 16:04:21 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:04:21 #info We'll be following the process outlined at: 16:04:21 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:04:23 #info The bugs up for review today are available at: 16:04:26 such important, much priority 16:04:27 #link http://qa.fedoraproject.org/blockerbugs/current 16:04:29 #info The criteria for release blocking bugs can be found at: 16:04:31 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:04:33 #link https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria 16:04:35 #link https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria 16:04:37 #info For F39 Final, we have: 16:04:39 #info 3 Proposed Blockers 16:04:41 #info 13 Accepted Blockers 16:04:43 #info 4 Proposed Freeze Exceptions 16:04:45 #info 12 Accepted Freeze Exceptions 16:04:58 who would like to secretariariariarilize? 16:05:14 * Son_Goku wonders if that's a word 16:05:29 * michel-slm thinks it might be in German 16:05:32 adamw invented it 16:05:37 he has it patented 16:05:45 well then 16:05:47 darn right i do 16:05:55 I'll do it 16:07:22 alrighty then 16:07:26 #info coremodule will secretarialize 16:07:32 let's get started with: 16:07:35 #topic Proposed Final blockers 16:07:42 #topic (2242759) dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key 16:07:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=2242759 16:07:42 #link https://pagure.io/fedora-qa/blocker-review/issue/1392 16:07:42 #info Proposed Blocker, dnf-plugins-core, NEW 16:07:42 #info Ticket vote: FinalBlocker (+2,0,-0) (+lruzicka, +saluki) 16:08:47 .hello thebeanogamer 16:08:48 thebeanogamer: thebeanogamer 'Daniel Milnes' 16:09:05 this does seem pretty significant 16:09:08 if this is universal, then it seems to be a clear violation of our criteria 16:09:12 .hello salimma 16:09:13 michel-slm: salimma 'Michel Lind' 16:09:15 if we block on RPi4 16:09:21 per the description it doesn't seem to be universal 16:09:22 we had a list somewhere... 16:09:26 at a guess, it might depend on how old your pi 4 is? 16:09:32 RPi4 is a blocker arch? 16:09:44 we have *two* lists, i think. neither of which is up to date... 16:10:10 but yes, however you slice it, pi 4 is supported since f37. https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi 16:10:23 I'm confused, why can systemd-timesyncd set the time correct, but chronyd can't? 16:10:43 it's probably more a case of when they run 16:10:50 or whether they run in the system upgrade boot target 16:10:51 And won't that be an issue for all manner of SSL things 16:10:51 what leads you to believe this doesn't affect all RPi4s? 16:11:05 kparal: the line in the report that says "There are reports of success with this process on similar Raspberry Pi 4s from others so I have no idea is this is just highly localized. Both machines I tried failed." 16:11:24 nielsenb: because this is only happening in the system upgrade environment, as i read it. 16:11:31 thanks 16:11:47 Interesting, never considered that may be an issue 16:11:47 at least we have confirmation from 2 different people 16:11:54 hmm 16:12:27 on the whole, i lean +1 on this 16:12:28 at this moment I think we should go with +1 blocker 16:12:31 Wonder what systemd-timesyncd does differently to make the time correct in the update environment 16:12:34 would be great to have input from pbrobinson/pwhalen 16:12:41 nielsenb: i suspect the answer is 'it runs' 16:12:52 +1 FinalBlocker from me 16:13:23 he managed a workaround: "My workaround was to disable chronyd.service and enable systemd-timesyncd.service. After that, the upgrade was successful." 16:13:32 https://bugzilla.redhat.com/show_bug.cgi?id=2242759#c3 16:13:40 but yeah 16:13:48 +1 Final blocker 16:14:08 FinalBlocker +1 16:14:25 Though I'm still confused, but that's pretty perpetual these days 16:14:38 okay, that seems clear... 16:14:58 otoh if this was the last blocker, I'd probably keep it just documented and released :-D 16:15:30 not sure 16:15:36 me too 16:15:36 proposed #agreed 2242759 - AcceptedBlocker (Final) - this is accepted as a violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed.", on affected rpi 4 systems (we note rpi 4 is a supported arm platform) 16:15:49 ack 16:15:51 ack 16:15:52 ack 16:16:03 ack 16:16:27 #agreed 2242759 - AcceptedBlocker (Final) - this is accepted as a violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed.", on affected rpi 4 systems (we note rpi 4 is a supported arm platform) 16:16:55 #topic (2242874) The image is no longer recognized by 'toolbox list --images', etc. 16:16:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=2242874 16:16:55 #link https://pagure.io/fedora-qa/blocker-review/issue/1394 16:16:55 #info Proposed Blocker, fedora-toolbox, NEW 16:17:08 this is clear blocker 16:17:09 sumantrom: rishi: ping, your bug 16:17:27 toolbox can't function without recognized images 16:17:28 * rishi waves 16:17:40 JJust added a comment. 16:17:44 rishi, hi there, Avensis driver 16:17:51 in https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Toolbx_functionality it says "must be able to create and enter a new container" "The most recent stable image for the current stable Fedora release" 16:17:56 so yeah, looks like a blocker 16:18:03 lruzicka: Hello! How did you know? :P 16:18:17 kparal: The fix is pretty simple. 16:18:22 if "create --release 39" doesn't work 16:18:45 I am a bit hampered by the tooling which is totally new to me, but I am learning with lots of help from jednorozec 16:18:57 +1 FB 16:19:09 FinalBlocker +1 16:19:10 rishi is working on the fix and we do intend to test it before the release . I am Blocker +1 on this one. 16:19:14 rishi:  a PR for pungi to fix this. But is this also required as a fix? https://pagure.io/fedora-kickstarts/pull-request/994 16:19:26 "there's a PR" 16:19:53 kparal: The fedora-kickstarts changes are clean-ups and minor fixes. Only the pungi-fedora PRs are relevant to this blocker. 16:20:01 ok 16:20:35 sumantrom: The fix is ready, as far as I can see. 16:21:04 awesome , then I can test it :) 16:21:10 Either someone who understands pungi-fedora very well can review and merge, or I have to wait for permission to scratch build them and be sure. 16:22:09 um 16:22:24 did anyone say that this bug actually prevents "must be able to create and enter a new container"? 16:22:25 (sounds like trouble ahead) 16:22:37 the description only says "images don't show up in 'toolbox list' and can't be removed with 'toolbox rmi'" 16:22:41 which sucks, but...isn't that 16:22:43 adamw: No, doesn't prevent 16:22:57 ... 'create' and 'enter', because we are a bit lenient on those code paths. 16:23:15 my assumption was that `toolbox create --release 39` is broken. Is it or not? 16:23:16 another question: does the fix for this fix *existing* containers, or only newly-created ones? 16:23:39 It only affects images, not containers. 16:23:53 The containers show up fine in 'list', can be removed with 'rm', etc.. 16:23:57 ah, i see 16:24:12 It's the images that don't have a LABEL, so they don't show in 'list', can't be deleted with 'rmi', etc.. 16:24:24 and whenever we ship the fix, the image will start showing up in `toolbox list` for people, right? 16:24:32 (after an image actually gets built and pushed out and whatever) 16:24:49 We have a whole bunch of upstream CI tests failing because of this. Once the fix is live, I expect them to turn green. :P 16:24:52 assuming we plan to update the toolbox images after release? 16:25:02 adamw: Yes, exactly. 16:25:12 okay. i'm kinda -1 blocker but +1 FE then 16:25:31 with the +1 FE just so we can fix this during freeze and have it look right on release day (and unblock your CI) 16:25:46 I was originally +1 FE before 16:25:51 so, `create --release 39` works, `list` works, just `list --images` doesn't show F39, is that correct? 16:26:01 Yeah, I don't really mind the difference between blocker and FE here. 16:26:05 kparal: `list` will show an existing 39 *container* but not the 39 *image*, aiui 16:26:11 Just want to get the fix merged. They are pretty simple. 16:26:22 adamw: Yes, you are right. 16:26:23 kparal: run it now and see what you see - there's a section for the base images, and a section for containers you actually have on your system 16:26:29 FinalBlocker -1 16:26:32 FinalFE +1 16:26:41 kparal: yes, you got that right 16:26:45 ok, my F39 image is not in the list 16:26:57 in that case, the criterion is not actually violated, as it sounds 16:27:04 yeah, that's my understanding 16:27:12 FinalFE +1 regardless 16:27:22 an in the whole time I was using F39 toolbox, I never noticed 16:27:35 so -1 blocker +1 FE sounds good to me 16:27:41 ok, I change my vote: FinalBlocker -1 FinalFE +1 16:28:31 -1 blocker +1 FE 16:28:52 proposed #agreed 2242874 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this does not seem to violate the criteria we put in place and probably won't affect 'typical' usage, but it would be good to have it right on release day for folks who might notice, and unblock CI 16:29:21 ack 16:29:25 ack 16:29:26 ack 16:29:36 ack 16:29:47 ack 16:29:50 #agreed 2242874 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this does not seem to violate the criteria we put in place and probably won't affect 'typical' usage, but it would be good to have it right on release day for folks who might notice, and unblock CI 16:30:00 #topic (2242287) loadkeys from kbd 2.6.1 triggers all mounts in the cwd 16:30:00 #link https://bugzilla.redhat.com/show_bug.cgi?id=2242287 16:30:00 #link https://pagure.io/fedora-qa/blocker-review/issue/1381 16:30:00 #info Proposed Blocker, kbd, ON_QA 16:30:00 #info Ticket vote: FinalBlocker (+0,0,-1) (-saluki) 16:30:01 #info Ticket vote: FinalFreezeException (+4,0,-0) (+kparal, +lruzicka, +sumantrom, +adamwill) 16:30:19 note: this is already accepted as FE 16:30:23 then ehh 16:31:04 probably -1 blocker 16:31:06 yeah, it feels kinda ehhh. but on the whole, -1, it's a pretty corner-y case. 16:31:13 It feels really edge case to me 16:31:17 FinalBlocker -1 16:31:35 I agree, FB -1 16:33:13 FinalBlocker -1 16:34:35 it has a fix, so I think it doesn't matter either way 16:34:47 FB -1 16:34:55 proposed #agreed 2242287 - RejectedBlocker (Final) - we agreed that this is a nasty situation if you hit it, but the configuration to hit it seems very uncommon so it's not serious enough to block the release on 16:35:03 ack 16:35:07 ack 16:35:09 ack 16:35:11 Son_Goku: well, the difference is if it's FE and the fix breaks stuff, we'd just pull it back out and ship with the bug 16:35:17 but let's hope the fix doesn't break stuff. :D 16:35:25 #agreed 2242287 - RejectedBlocker (Final) - we agreed that this is a nasty situation if you hit it, but the configuration to hit it seems very uncommon so it's not serious enough to block the release on 16:35:31 ack 16:35:45 the fix is here https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa617966c7 16:36:09 okay, that's all the proposed blockers 16:36:10 moving on to: 16:36:15 #topic proposed Final freeze exception issues 16:36:25 #topic (2240311) cmake-3.27.4-7 breaks configuration - CMake can not determine linker language for target 16:36:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=2240311 16:36:25 #link https://pagure.io/fedora-qa/blocker-review/issue/1393 16:36:25 #info Proposed Freeze Exceptions, cmake, MODIFIED 16:36:26 #info Ticket vote: FinalFreezeException (+0,0,-3) (-kparal, -lruzicka, -adamwill) 16:36:38 we have -3 for this in ticket but just thought i'd bring it up for the meeting in case anyone has an argument to pull it in 16:37:13 FinalFE -1 16:37:37 FinalFE -1 16:37:39 ehh, I don't like the idea of a whole programming language being broken in here 16:37:47 in the GA repo even 16:38:16 on the flip side, I don't know if we ship anything FORTRAN on any media 16:38:16 it's just fortran 16:38:17 *ducks* 16:38:22 ruuude 16:38:38 My career started in Fortran... 16:38:41 would this be different if it was gcc? 16:38:53 I mean who needs to use the frozen version in the main repo? 16:39:00 right now, everyone 16:39:03 you obviously want to use the latest one 16:39:04 But still, it doesn't seem to break any builds related to release, and can be fixed at release. 16:39:06 that's the problem 16:39:17 you can't fix anything FORTRAN based that uses CMake _right now_ 16:39:19 Son_Goku, no just use updates-testing, or 0-day updates once we ship 16:39:27 that's not a choice in the buildroot 16:39:52 you're right 16:39:53 alright, that's a good point. Is it preventing something to be built at the moment? 16:39:56 My Fortran dev days used fix compiler versions... :D 16:40:03 the bug report points to one 16:40:22 ok, so it really must be a FE 16:40:26 yes 16:40:26 FinalFE +1 16:40:29 FinalFE +1 16:40:35 the way i'd usually want to handle this is, if we *needed* this to build something else to fix an FE or blocker, pull it in as a dep of that 16:40:37 in general, buildroot breakages should be FEs 16:40:44 in my opinion 16:40:52 but i'm not really opposed to fixing this, i guess 16:40:58 Am I missing what it breaks? 16:41:10 It says cmake can't link Fortran sources, not that cmake doesn't make it into release 16:41:26 it breaks building a package that orion is trying to get reviewed. 16:41:45 (which to be clear, is written in fortran) 16:41:55 Yes, but that isn't a package that needs to be built for release 16:42:04 indeed 16:42:21 hmm, I guess I'm 0 now 16:42:35 me too 16:42:43 but it uncovers that any fortran stuff built with cmake is basically stuck right now 16:42:46 this prevent building packages, even though they are not blockers, which feels bad 16:43:06 the fact that orion's package isn't in yet isn't the point 16:43:14 I agree, it definitely feels bad 16:43:17 the point is that stuff that is cannot be rebuilt right now 16:43:23 So, let's block on it :) after all. 16:43:29 +1 FE, you convinced me 16:43:56 the freeze can last a long time, unblocking buildroot for certain packages sounds reasonable 16:44:06 Yeah 16:44:29 we've had freezes last way too long before (*stares at F37*) 16:44:29 Ah, FE is on the line ... +1 then 16:44:41 FinalFE +1 16:44:55 For "niceness" reasons, not for any formal reasons. 16:45:56 okay, i think that adds up to three! 16:46:30 proposed #agreed 2240311 - AcceptedFreezeException (Final) - this is accepted in order to unblock building of fortran code with cmake, in case anyone needs to do that while we're in freeze 16:46:39 ack 16:46:41 ack 16:46:55 ack 16:46:58 ack 16:47:15 ack 16:47:21 #agreed 2240311 - AcceptedFreezeException (Final) - this is accepted in order to unblock building of fortran code with cmake, in case anyone needs to do that while we're in freeze 16:48:08 #topic (2239807) Fedora 39 GNOME (X11/Wayland) experiences regular screen blackouts at increasing intervals after login on amdgpu with kernel 6.5.3-300 and later 16:48:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=2239807 16:48:08 #link https://pagure.io/fedora-qa/blocker-review/issue/1359 16:48:08 #info Proposed Freeze Exceptions, kernel, NEW 16:48:08 #info Ticket vote: FinalBlocker (+1,0,-6) (+nixuser, -zbyszek, -kparal, -lruzicka, -geraldosimiao, -nielsenb, -adamwill) 16:48:11 #info Ticket vote: FinalFreezeException (+1,0,-0) (+asciiwolf) 16:48:27 oh god yeah 16:48:28 so we rejected this as a blocker, but i proposed it as an FE - if we *do* happen across a fix, seems like it'd be a good idea to include it. 16:48:38 +1 FE 16:48:44 +1FB 16:48:46 * Son_Goku wants to know why amdgpu is hell this cycle 16:48:51 +1 FB +1 FE 16:48:52 Sure, I am in support of this, +1 FE 16:48:59 It's one of those deals where I really worry a fix could break things for more people 16:49:07 FinalFE +1 16:50:12 Though for consistency, I think I've voted in favor of other amdgpu fixes 16:50:29 FinalFE +1 16:50:56 Leslie said: F39, installed using the vanilla Everything.iso. 16:51:19 maybe this affects something? 16:51:52 other than using a proper workstation iso? 16:52:09 * rishi has an AMD GPU on his main machine -- should probably test 16:52:10 huh I am running 6800, 6900 and 6950 on 39 without experiencing this 16:52:12 I'm confused by the last comment too, is F40 (rawhide) fixed? 16:52:37 yeah, I unbderstood that F40 is OK 16:53:18 "The logout/logon can be done multiple times without any issue as occurring with Fedora39." 16:53:54 I'm not sure if Leslie's issue is actually related to the discussed 16:54:00 *one 16:54:16 i would discount comments from leslie in general. he...gets confused a lot. 16:54:21 indeed 16:54:29 So we're back to one affected person 16:54:35 yeah, that's my reading. 16:54:47 And we don't really even know what component would need to be touched... 16:54:55 yes, Leslie bug is this other one https://bugzilla.redhat.com/show_bug.cgi?id=2241955 16:54:55 Could just be a hardware issue 16:55:12 I take my FE back 16:55:16 FinalFE +0 16:55:28 If someone else feels strongly about it, sure, but there's really not much to go on 16:55:36 My FE stands, but -1 FB 16:55:43 so now I'm confused 16:55:49 for me this is kind of a pocket vote - we give it an FE just in case a fix that's clearly sensible and low-risk shows up 16:55:56 as always, an FE doesn't mean we *have* to fix it 16:56:11 it just means we *can* fix it 16:56:14 I know 16:56:36 alright, I'll keep my +1 FE 16:57:34 proposed #agreed 2239807 - AcceptedFreezeException (Final) - this is accepted as an FE just in case we happen to diagnose this bug and hit on a fix that's clearly safe, so we can include it. 16:57:56 ack 16:58:02 ack 16:58:34 ack 16:58:49 ack 16:59:23 ack 16:59:33 #agreed 2239807 - AcceptedFreezeException (Final) - this is accepted as an FE just in case we happen to diagnose this bug and hit on a fix that's clearly safe, so we can include it. 16:59:45 #topic (1858437) /usr/bin/lspci symlink missing, causes Dying Light game not to launch 16:59:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1858437 16:59:45 #link https://pagure.io/fedora-qa/blocker-review/issue/1387 16:59:45 #info Proposed Freeze Exceptions, pciutils, ON_QA 16:59:45 #info Ticket vote: FinalFreezeException (+3,0,-3) (+lruzicka, +frantisekz, +ngompa, -kparal, -sumantrom, -nielsenb) 17:00:23 this is a pretty trivial fix... 17:00:31 sure, but on principle, it has to be -1 for me 17:00:40 :( 17:00:58 Oh, now suddenly even if a fix is trivial, you don't want it 17:01:02 :D 17:01:04 =) 17:01:53 Why on principle this should be -1? 17:01:56 wich criterion it affects? 17:03:15 we're not allowed to have criterion for games 17:03:21 ohh 17:03:50 well, we have so many FE and blocker right now... there is no harm in adding symlink to a package. 17:03:55 if dying light were, for e.g., on the games spin, it could be an FE 17:03:55 FinalFE +1 17:03:58 but it isn't 17:04:25 I dont see how this relates to any criterion 17:04:39 I mean, there is no criterion, it's a third party app, I understand, but we could just make this right for the image at no costs. 17:04:45 adamw: if it were in Fedora, we would have just patched it and fixed it :P 17:04:56 that's a dangerous way to think. :D the more change we put in, the more danger. sure, just adding a symlink seems safe (but we've had apparently-safe things break stuff before). but what if the update actually changes something else too? what if they typo the change and wipe /usr/bin ? the point of a freeze is, you don't change stuff unless you have a really good reason to 17:05:19 pciutils passed openqa tests, so I don't think we did any of that 17:05:28 we don't have criteria for FEs, we have principles. https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Freeze_exception_bug_principles 17:05:28 So my exact reasoning for the last change... 17:05:42 nielsenb: that one was different because it's a 'my system doesn't work' bug 17:05:46 we're adding a "feature" to F39 = compatible with older debian games 17:05:47 we can't properly fix those with 0-day updates 17:05:48 Mostly I don't buy the "other games" reasoning. 17:05:54 It seems to just be the one 17:05:57 And it's been years 17:06:09 * kparal agrees with adamw 17:06:12 I know, I'm mostly being glib 17:06:21 well this bug led to Nobara being created :P 17:06:34 and that person disengaging from Fedora more or less 17:06:55 now he/she can come back ;-) after F39 release, that is 17:07:11 So the toys have already been thrown from the pram 17:07:33 all you're going to do by rejecting this FE is hurt my feelings, no worries :P 17:07:55 Right, but will you throw any toys? Or suffer in silence. 17:07:59 We're okay with silence. 17:08:00 but seriously, yes it can also land as a 0day, it's just kind of crappy for such a tiny fix that passed openqa etc 17:08:12 nielsenb: you never know :P 17:08:20 it could be the *straw* 17:08:41 I think Neal and silence doesn't belong to the same sentence... 17:08:46 *the* *straw* 17:08:47 ;) 17:08:55 anyhow, i think we're kinda stuck at a non-resolution here 17:09:31 with my vote and geraldo's, we're at +4/-4 17:09:33 geraldosimiao: :D 17:09:37 punt, hehe 17:09:50 yeah punt 17:09:54 I am struggling a bit with how to square this with the desire for increased Steam / games testing 17:10:20 proposed #agreed 1858437 - punt (delay decision) - this is punted because we cannot agree on a decision. note the effect of a punt is similar to a rejection, which is intended. active acceptance must be the requirement to break the freeze. 17:10:34 ack 17:10:35 :( 17:10:36 withou this we don't make fedora a steam friendly distro... 17:10:44 ack 17:10:46 geraldo: all you have to do is *run an update* 17:10:48 ack :( 17:10:53 ack 17:11:01 which you are supposed to do anyway. all the time. you know, so people don't send you webps and hack your computer. 17:11:04 -1 from me as well 17:11:12 yeah, sorry ( steam friendly distro.. out of the box) 17:11:28 i know people want to see the FE/blocker process as a kind of popularity contest or importance signifier for bugs, but it really isn't 17:11:53 the guidelines/policies are specifically about *what makes sense to break a freeze for*, not what is 'important' 17:12:18 the process is *already* used that way 17:12:39 only when people vote wrong. i need to pass that law that gives me all the votes. :D 17:12:54 bottom line is: if we have done this change to the package earlier, before final freeze, it was all done 17:13:07 #agreed 1858437 - punt (delay decision) - this is punted because we cannot agree on a decision. note the effect of a punt is similar to a rejection, which is intended. active acceptance must be the requirement to break the freeze. 17:13:20 #topic (2241351) Apps depending on python-QtAwesome fail to start due to changes to fontawesome fonts 17:13:20 #link https://bugzilla.redhat.com/show_bug.cgi?id=2241351 17:13:20 #link https://pagure.io/fedora-qa/blocker-review/issue/1373 17:13:20 #info Proposed Freeze Exceptions, python-QtAwesome, POST 17:13:20 #info Ticket vote: FinalFreezeException (+2,0,-4) (+zbyszek, +frantisekz, -lruzicka, -kparal, -nielsenb, -geraldosimiao) 17:13:40 FE +1 17:13:44 I would like to see bugs automatically voted down for blockers unless a criteria is cited, but I digress... 17:14:14 nielsenb: it is not the proposer's obligation to know the criterion. It's our job to know it. 17:14:36 but I don't know how it's relevant here 17:14:43 i'm -1 on this, again, because there's just no reason to break the freeze here. 17:14:46 Okay, so don't count a +1 vote unless a criteria is noted... :D 17:14:47 it can be a 0-day update. 17:15:12 nielsenb: but we're talking about FE, not a blocker 17:15:27 I mentioned blockers in my initial "proposal" 17:16:07 -1 FE, as written in the ticket. No reason to go through freeze. 17:16:08 I stand by my FinalFE -1 for this one, easy 0 day fix 17:16:41 -1 FE 17:17:25 -1 FE, when things stand as they do 17:18:34 so, i think that's 2 additional -1s compared to the ticket (me and jednorozec), one additional +1 (neal) 17:18:40 which gives us +3 / -6 17:19:25 anyone else want to vote before i whack the gavel like an over-enthusiastic congressperson? 17:19:46 lol 17:20:08 :o 17:22:08 proposed #agreed 2241351 - RejectedFreezeException (Final) - this is rejected as there is no clear rationale for breaking the freeze to fix this. it can just be a 0-day update. 17:22:14 ack 17:22:40 ack 17:22:53 ack 17:22:57 ack 17:22:59 ack 17:23:36 ack 17:23:54 #agreed 2241351 - RejectedFreezeException (Final) - this is rejected as there is no clear rationale for breaking the freeze to fix this. it can just be a 0-day update. 17:24:05 okay, that's all the proposals 17:24:13 as it's go/no-go week monday, let's do a quick run through: 17:24:18 #topic Accepted blocker status review 17:24:35 as a reminder, we're not voting again (unless we decide that's an appropriate response to the status review). we're just checking in on the accepted blockers for progress. 17:24:53 #info i'm gonna skip ones which have updates going through the process - in general, please test and karma these 17:25:01 #topic (2241632) Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) 17:25:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=2241632 17:25:01 #link https://pagure.io/fedora-qa/blocker-review/issue/1354 17:25:01 #info Accepted Blocker, anaconda, ASSIGNED 17:25:18 #info we are waiting on anaconda team to diagnose and fix this one, the bug is well-described and reproduced. we're expecting an update from anaconda team tomorrow 17:25:30 anything else on that one? 17:25:59 not here 17:26:08 no 17:26:59 alrighty 17:27:06 #topic (2242437) updates-testing should be disabled, fedora-release should have release >= 1 17:27:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=2242437 17:27:06 #link https://pagure.io/fedora-qa/blocker-review/issue/1385 17:27:06 #info Accepted Blocker, fedora-release, POST 17:27:32 we have PRs for this, we just need to merge and build. i was kinda leaving it to see if sgallagh wanted to do it, but i guess we'll just go ahead and do it after this meeting - me or jednorozec or nirik or someone 17:27:32 that seems... obvious 17:28:45 so do we have anything else? 17:29:23 #info we just need to merge and build the fixes for this - I or releng will do this after the meeting 17:29:34 #topic (2113005) Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards 17:29:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=2113005 17:29:35 #link https://pagure.io/fedora-qa/blocker-review/issue/1154 17:29:35 #info Accepted Blocker, shim, NEW 17:29:43 #info it's kinda looking like we'll have to waive this again, sadly 17:31:01 anything else on it? 17:31:06 At least it looks like the long, frustrating, journey, is finally coming to an end 17:31:40 indeed 17:31:45 Just in time for most devices to ship with UEFI implementations that mostly work. 17:31:56 well now, don't get too crazy 17:32:21 #topic (2241252) Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 17:32:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=2241252 17:32:21 #link https://pagure.io/fedora-qa/blocker-review/issue/1352 17:32:21 #info Accepted Blocker, uboot-tools, ASSIGNED 17:32:43 well, this isn't great! 17:34:05 Just SBC things 17:34:56 lovely 17:36:16 so, we're just sort of waiting for someone to identify the problem here, i guess... 17:36:23 i've pinged pbrobinson on matrix 17:39:18 #info we are just waiting for developers to diagnose and fix this. not a lot anyone else can do at present 17:39:24 and that's the lot 17:39:27 #topic Open floor 17:39:32 any other business? late proposals? 17:40:24 I guess I do not have anything. 17:40:43 no 17:40:45 no 17:41:19 alrighty, thanks a lot for coming, everyone 17:41:44 ok, bye bye people 17:42:22 thanks all 17:42:28 thanks all, good bye 17:42:35 #endmeeting