17:00:02 #startmeeting F33 Beta Go/No-Go meeting 17:00:02 Meeting started Thu Sep 24 17:00:02 2020 UTC. 17:00:02 This meeting is logged and archived in a public location. 17:00:02 The chair is bcotton_. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:02 The meeting name has been set to 'f33_beta_go/no-go_meeting' 17:00:04 #meetingname F33-Beta-Go_No_Go-meeting 17:00:04 The meeting name has been set to 'f33-beta-go_no_go-meeting' 17:00:17 #topic Roll call 17:00:25 alright, friends, who's here? 17:00:49 good morning bcotton , /me is here 17:00:50 .hello mohanboddu 17:00:51 mboddu: mohanboddu 'Mohan Boddu' 17:00:57 I am here, with my foot hovering over the GO! pedal 17:01:01 morning 17:01:08 .hello2 17:01:12 coremodule: coremodule 'Geoffrey Marr' 17:01:14 #agreed we're go because matthew says so :-) 17:01:23 .hello2 17:01:24 pwhalen: pwhalen 'Paul Whalen' 17:01:37 #chair bcotton 17:01:37 Current chairs: bcotton bcotton_ 17:01:44 #chair coremodule 17:01:44 Current chairs: bcotton bcotton_ coremodule 17:02:01 welcome everyone 17:02:29 .hello2 17:02:30 frantisekz: frantisekz 'František Zatloukal' 17:02:46 #topic Purpose of this meeting 17:02:48 #info Purpose of this meeting is to check whether or not F33 Beta is ready for shipment, according to the release criteria. 17:02:50 #info This is determined in a few ways: 17:02:51 #info 1. No remaining blocker bugs 17:02:53 #info 2. Release candidate compose is available 17:02:54 #info 3. Test matrices for Beta are fully completed 17:03:10 #topic Current status - blockers 17:03:11 #link https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist 17:03:17 okay, this is going to take a while, so let's start 17:03:31 #info 4 Proposed Blockers 17:03:32 #info 2 Accepted Blockers 17:03:34 #info 0 Accepted 0-day Blockers 17:03:48 #topic (1882358) Installing KDE from the Everything Iso, results in a system with no web browser. 17:03:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=1882358 17:03:51 #link https://pagure.io/fedora-qa/blocker-review/issue/125 17:03:53 #info Proposed Blocker, comps, NEW 17:04:00 Since mattdm wants a release, betablocker -1 for all ;P 17:04:08 yay! 17:04:11 IMHO, this is intended behavior... -1 blocker 17:04:13 this is easy 17:04:18 #info in the ticket BetaBlocker (+0, 2, -4) 17:04:23 Yeah, -1 blocker 17:04:33 -1 Blocker 17:04:42 coremodule: btw, will you secretarialize these after the meeting, pleeeeeeeeeeeeaaaaaaase 17:05:02 :) you got it 17:05:18 one down! mwhahaha 17:05:23 :) 17:05:30 -1 Blocker 17:05:33 proposed #agreed 1882358 - RejectedBlocker (Beta) - This is intended behavior, but it may be worth later discussion about how we apply the criterion in question 17:05:41 ack 17:05:43 (everyone, prepare late blocker procedure! :D ) 17:05:44 ack 17:05:45 ack 17:05:49 ack 17:05:52 ack 17:06:12 #agreed 1882358 - RejectedBlocker (Beta) - This is intended behavior, but it may be worth later discussion about how we apply the criterion in question 17:06:30 #topic (1881495) Outdated Firefox is going to be shipped in the Fedora 33 Beta 17:06:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=1881495 17:06:33 #link https://pagure.io/fedora-qa/blocker-review/issue/118 17:06:35 #info Proposed Blocker, firefox, ON_QA 17:06:50 -1 Blocker, we have no criterion for it 17:06:51 -1 blocker. We can push it stable as soon as we are go, so it will be used by upgrades. 17:07:03 and yeah, no critera at beta also 17:07:06 agreed, -1 blocker on criteria 17:07:08 -1 blocker 17:07:11 #info in the ticket: BetaBlocker (+0, 2, -8), Accepted BetaFE (+5, 0, -0), 0Day (+1, 0, -0) 17:07:14 I think there's general agreement to reject blocker. 17:07:21 As per criterion -1 Blocker +1FE (in case we need another rc compose) 17:07:32 -1 blocker 17:07:34 Workstation WG seemed a little unhappy about this, fwiw 17:08:09 .hello2 17:08:10 lruzicka: lruzicka 'Lukáš Růžička' 17:08:20 Yeah, its good if we can ship the latest FF, oh well... 17:08:29 any workstation WG folks here want to clarify on why? 17:08:29 +1 for final but beta people expect little issues 17:08:31 so, this would be fixed for upgrades, I've already requested it in https://pagure.io/releng/issue/9725 17:08:38 but as there's a fix that can be in stable on release day, the case where it's harmful is "installed f33 beta and launched firefox before running updates" which for beta i think we can say "don't do that" 17:08:40 so, users wouldn't lose data on upgrade 17:08:41 frantisekz++ 17:09:30 firefox is on a _monthly_ release cycle. It is highly likely that we are going to be in this situation over and over again 17:09:32 anyhow, I think we can just reject blocker on this and move on? 17:09:34 proposed #agreed 1881495 - RejectedBlocker (Beta) - A fixed package is built and will be available in the stable repo on release day 17:09:40 ack 17:09:43 ack 17:09:43 patch? 17:09:45 ack 17:09:46 ack 17:09:48 nirik: go ahead 17:09:52 "has been built" 17:09:54 :) 17:09:57 :) +1 17:09:59 ack 17:10:03 oh, I see... 17:10:04 i'll allow it 17:10:05 ack that patch 17:10:08 ok, ack, either way. 17:10:11 ack 17:10:21 #agreed 1881495 - RejectedBlocker (Beta) - A fixed package has been built and will be available in the stable repo on release day 17:10:27 it just sounded like it wasn't made yet... doesn't matter. it is. 17:10:34 #topic (1868141) Select Printer Driver hangs 17:10:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1868141 17:10:38 #link https://pagure.io/fedora-qa/blocker-review/issue/124 17:10:39 #info Proposed Blocker, gnome-control-center, NEW 17:10:53 oh! 17:11:04 i thought printing was final but ok... 17:11:05 this one is already rejected, the app just didn't pick it up yet 17:11:06 that's easy 17:11:12 so, can anyone add a printer without hitting this? 17:11:14 *whew* 17:11:15 \o/ 17:11:18 ok... 17:11:23 yay 17:11:32 lruzicka, you tested this, can you sum up somehow pretty please :) ? 17:11:32 #info Rejected in the ticket: Rejected BetaBlocker (+0, 0, -5) 17:11:35 okay 17:11:41 Ok, 17:11:48 I see it's in the bug 17:11:51 no need then :) 17:11:52 yep 17:11:52 #topic (1880499) rpm-ostree rebase fails when using aarch64 disk images 17:11:54 #link https://bugzilla.redhat.com/show_bug.cgi?id=1880499 17:11:56 #link https://pagure.io/fedora-qa/blocker-review/issue/104 17:11:57 #info Proposed Blocker, ostree, NEW 17:12:09 this is a fun one. 17:12:14 #info in the ticket: BetaBlocker (+3, 0, -0) 17:12:30 * mboddu agrees with nirik 17:12:32 this affects the Gnome Settings dialog for Adding/Modifying printers, because when you want to search through drivers, it becomes unresponsive and no drivers are shown. 17:12:44 the 'fix' is in the f32 package, but that same version in f33 breaks iot composes. 17:12:55 ohh, ok, will not waste your time then 17:12:57 "If IoT isn't blocking for Fedora 32, and is newly blocking for Fedora 33 going forward, then I'd say it's not a blocker bug. If upgrades from 32 are release blocking, what about from 31?" 17:13:07 from the ticket 17:13:23 yeah, this is a bit of a case without precedent 17:13:31 lruzicka: sorry, we moved on. ;) But if thats not a blocker (as noted) we will at least need common bugs on it, so thats good info for that 17:13:38 ^^ what frantisekz said 17:13:49 legislating from the bench, as it were, i'd say N-1 upgrades should block but not N-2 17:13:52 I think we shouldn't count votes in the ticket as they're made before that statement 17:13:58 but that's a policy question to make later 17:14:01 nirik, you can always set up printers using the web interface on cups 17:14:09 i think it's not a beta blocker, block on f32 upgrades to f33 until it's fixed in f32 17:14:46 cmurf: well, that means we need a 0day update in f32 at f33 beta release 17:14:51 i think this one also brough up the question of "can previous release blockers block beta?" because i think we've generally only used those to block fina 17:14:52 -1 Beta Blocker, let's block on upgrades from F33 in the future, wdyt? 17:15:06 but if no ostree there is not iot release correct 17:15:06 also... 17:15:07 we can block final, ofc 17:15:24 or reprovision 17:15:34 if you can't fix the bug in f32, then you have to clean install 17:15:35 say we push a f32 update that fixes upgrades to f33. People still need to apply it... they won't always magically have it. 17:15:40 pwhalen: (and pbrobinson if you can pull away from your other meeting) how do you feel about this, as IoT folks 17:16:13 nirik: we specify that you're supposed to apply latest updates before upgrading 17:16:15 * nirik is inclined to say -1 blocker for f33 beta, if we can get a f32 fix out before beta release great. If not, too bad. 17:16:30 zbyszek: sure, but we don't enforce that. :) 17:16:32 a significant feature of rpm-ostree has been that they are ephemeral installs to be blown away and reprovisioned 17:16:40 whenever necessary 17:17:05 so the idea of blocking on upgrades is a curiousity 17:17:07 * nirik doesn't think he agrees with that 17:17:56 I'd be fine with a PreviousReleaseBlocker for F33final 17:18:34 seems like the general consensus is "not a blocker" 17:18:39 nirik: that's what Colin Walters has said 17:18:40 The f32 update has been pushed, so users should be able to upgrade now. But the f33 compose broke when the same fix was added in to f33. As per the last comment in the bug, something isn't quite right. 17:19:09 those that do upgrade, won't be able to update further, fwiu 17:19:16 well, if upgrades are "a curiosity" we shouldn't have them in release critera? 17:19:17 until fixed in f33 17:19:49 pwhalen: if we call Fedora-IoT-33-20200920.0 the Beta, does that solve^Whide the problem until we can fix 33 composes? 17:19:49 once it's fixed on the remote side, does it just start working? or is manual intervention now needed? 17:19:52 x86 is not affect, just aarch64 17:20:51 mattdm: not sure, manual intervention might be needed 17:21:09 bcotton_: I don't think so... it just means they are on f33 and can't upgrade further until it's fixed? 17:21:12 bcotton_: it gives us a compose, but I need to kick the tired. The 16th was the last fully tested 17:21:18 * sgallagh is here now. 17:21:23 s/tired/tires 17:22:13 Since we cannot run updates on f33, that seems like a +1 betablocker for me (concerning security) 17:22:41 mboddu: a fresh install of f33 is not affected, just the upgrade from f32 17:23:03 cmurf: I didn't say anything at all like that 17:23:07 which is why we are in the corner case 17:23:34 iot and coreos folks: what's your thoughts on blocking the release for this? 17:23:39 pwhalen: is it possible to not offer the f32->f33 upgrade? or that already is possible by just rebasing now? 17:23:55 nirik++ 17:24:04 👋 17:24:09 .hello ngompa 17:24:10 Eighth_Doctor: ngompa 'Neal Gompa' 17:24:23 nirik: I don't think we prompt for upgrades at all; I think you have to know what release you want to rebase to ahead of time 17:24:25 It *should* be possible to work around it as I did to test the upgraded package, I think 17:24:30 So we could just... not announce it? 17:24:31 yeah is it possible to hide the f33 remotes (on aarch64 only, even) until this is fixed and not block the general release? 17:24:40 walters: rpm-ostree installs aren't primarily intended to be reprovisionable? 17:24:59 so just reprovision if you can't upgrade 17:25:02 cmurf: correct, it works just as well for "pet" systems as it does reprovisionable 17:26:04 walters: Do I remember correctly that new rebase targets aren't visible on the system, you have to know what it will be and enter it manually? 17:26:26 (I mean, they're reasonably guessable, but still) 17:26:42 I think it should be possible... chmod 000 those refs... but not sure if that breaks other things or has weird side effects. 17:27:30 ok well if IoT is more of a "pet" than "reprovisionable" then I guess I'm just confused 17:27:59 nirik: What if there is a CVE after release? 17:28:00 but otherwise it's case of just blow it away and reinstall, no big deal 17:28:00 because we're in the weird edge-case land, and because it's beta not final, I think I'd prefer to do that and then common bugs it / put it in the release notes 17:28:18 I think the small subset of users that might be affected can either remain on f32 until f33 is fixed in a future compose. 17:28:35 sgallagh: for coreos it both isn't a manual operation and is intended to feel "single stream"; silverblue has separate refs and manual action needed, but I am not aware of us building sb for aarch64 - this is mostly affecting iot 17:28:36 mboddu: they would still be on f32 and get the upgrade there? 17:28:38 I know the chances are very low, but I dont know how to vote on this 17:28:49 so i'm making my vote 0 based on what mattdm and pwhalen have said 17:28:51 sgallagh: You can list available refs with ostree remote refs fedora 17:28:54 mattdm: ..I see what you did there.. "edge" case : ) 17:29:02 pwhalen: :) 17:29:03 +1 mattdm 17:29:17 nirik: What about who are on f33? Since we are making the ref invisible, right? 17:29:32 and if i'm being perfectly transparent, i'd be much more likely to call this a blocker 3 weeks ago 17:29:42 adding this revert is pretty safe 17:29:45 mboddu: you mean people who updated pre-beta? 17:29:47 mboddu: if they did a new install... they would get it. 17:29:54 those people should know what they're in for :) 17:29:55 mattdm: Yes 17:30:16 haha :) 17:30:26 but if they are on f33 what is the issue 17:30:30 I expect this will be fixed before too long... lots of smart folks involved. We make no promises for SLA on CVE's. 17:30:35 it's a beta. :) 17:31:17 okay,let's put some votes out there 17:31:19 I guess we should just vote 17:31:21 I suppose we could mention in the announcement "if you are a brave soul on aarch64 on iot, please stick with f32 for now, see...link for details' 17:31:26 bcotton++ ;) 17:31:26 mboddu: Karma for bcotton changed to 29 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:31:33 -1 Beta Blocker 17:31:38 nirik++ 17:31:42 -1 beta blocker 17:31:48 -1 beta blocker 17:31:49 -1BB 17:31:50 -1 beta blocker 17:31:58 -1 bb 17:32:04 -1 Beta Blocker, +1 Final Blocker 17:32:07 -1 17:32:24 +1 FB 17:32:32 let's just stick to beta for now 17:32:45 we can deal with final in monday's regular review meeting 17:33:00 if we're still in this situation with final all the more reason to just reprovision 17:33:23 I guess we are making mattdm' 17:33:26 s wish come true 17:34:01 proposed #agreed 1880499 - RejectedBlocker (Beta) CommonBugs - It affects a small group of users, is in a beta, and is an edge case, and we expect it to be fixed soon 17:34:01 :) 17:34:10 mboddu: why do you think i told him to come? ;-) 17:34:11 ack 17:34:13 ack 17:34:16 ack 17:34:17 ack 17:34:27 ack 17:34:31 ack 17:34:42 ack 17:34:54 ack 17:34:55 #agreed 1880499 - RejectedBlocker (Beta) CommonBugs - It affects a small group of users, is in a beta, and is an edge case, and we expect it to be fixed soon 17:35:12 #action bcotton to update mattdm's release announcement draft with appropriate information 17:35:17 lol 17:35:26 this is the beta! it's mboddu's release announcement! 17:35:36 mattdm: the magazine article, more specifically 17:35:56 unless you want to hide it a little bit, but we can discuss that afterward 17:36:09 2020 seems like a really long year, feels like its been ages since I made the beta announcement 17:36:22 #agreed 2020 has been a long decade 17:36:38 okay, i think we managed to reject all of the proposed blockers, so let's look at the accepted ones 17:36:39 lol 17:36:43 2020beta branch 17:36:56 #topic (1881745) abrt-action-generate-backtrace crashes during local processing 17:36:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=1881745 17:36:59 #link https://pagure.io/fedora-qa/blocker-review/issue/119 17:37:01 #info Accepted Blocker, abrt, VERIFIED 17:37:12 fixed with -6 release 17:37:38 so... can we demote this one to 0day blocker somehow :) ? 17:37:40 could plausibly be a 0day fix 17:37:41 this one is verified, and we had a general consensus on monday that at this point we're willing to ship with a broken abrt rather than delay indefinitely to fix the onions 17:38:13 i don't think having it working on the beta media or as installed, is blocker worthy 17:38:34 #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one) 17:38:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700 17:38:35 it's a kinda bad look, but perhaps it's ok... 17:38:37 #link https://pagure.io/fedora-qa/blocker-review/issue/16 17:38:38 #info Accepted Blocker, sddm, ASSIGNED 17:38:40 okay, here's the other fun one 17:38:59 no fun! 17:38:59 shouldn't we do one at a time? :) 17:39:05 so... we won't release another Fedora... at all, never, it seems with this one, as a blocker 17:39:15 frantisekz yeah, that :( 17:39:17 Yeah, whats the decision on abrt bug? 17:39:19 one at a time please 17:39:23 i was just gonna say this is one fast train 17:39:43 1881745 is in verified state so there's not much to do about it 17:39:52 But its not in the rc media 17:39:54 non working abrt is annoying, but who can say how long does it take to fix all the issues 17:40:03 okay, i'll back the train up for a moment 17:40:05 #undo 17:40:05 Removing item from minutes: INFO by bcotton_ at 17:38:38 : Accepted Blocker, sddm, ASSIGNED 17:40:07 #undo 17:40:07 Removing item from minutes: 17:40:08 #undo 17:40:08 Removing item from minutes: 17:40:10 #undo 17:40:10 Removing item from minutes: 17:40:10 lruzicka: therein lies the problem with making it 0day 17:40:34 the abrt bugs are clearly on their own schedule, they're gonna get fixed whenever they get fixed 17:40:38 so, I guess our choices here are... 17:40:41 lruzicka: One month. Of course, months in 2020 last somewhere between 50 and 3256 days. 17:40:44 so longer story: we've been fighting a bunch of layers of abrt bugs 17:40:50 sgallagh, :D 17:41:06 and it's not clear that the abrt team has a good handle on the big picture at the moment 17:41:22 a) just release and get the update, b) respin today and hurridly retest abrt stuff and try go tomorrow, c) slip/block for it... but we don't know when all the issues will be fixed. 17:41:37 (a) +1 17:42:00 a+1 17:42:01 +1 A 17:42:07 (a) +1 because we might be blocking for a longer time 17:42:07 yeah, thats seeming like the best option right now... since we don't even know how many more things are lurking 17:42:20 For now a:+1, but I will also hold on to b, based on the other blocker decision 17:42:22 and it's a beta, we get to find out later what else is lurking :) 17:42:41 yeah A 17:42:41 I think we know my answer :) 17:42:41 do we want to blocker vote? or ? 17:42:57 seems like the consensus is "ship it" 17:43:01 -1 bb 17:43:12 (insert boat emoji) 17:43:16 yep, -1bb 17:43:39 insert trademarked version: USS Ship It™ 17:43:40 -1bb 17:43:49 -1 beta blocker 17:43:52 boat it? 17:43:55 -1 beta blocker 17:44:03 so you're all wrong 17:44:04 * sgallagh runs off to register "HMS ShipIt" 17:44:05 -1 pellet 17:44:08 it's a blocker 17:44:10 *BUT* 17:44:23 it was nominated 2 days ago, so we can waive it 17:44:31 which i'm going to take all of your -1s to mean 17:44:38 :) 17:44:40 And we have the "infeasible to solve in a reasonable amount of time" option 17:44:53 Since we have no way of knowing what else is lurking 17:45:04 I love the soudn of that 17:45:10 fills me with confidence! 17:45:12 proposed #agreed 1861700 - Waived - We are waiving this under the late blocker exception since for Beta getting the fix in an update is sufficient 17:45:51 ack 17:45:54 * nirik suspects some reviewer will complain about the bug reporting tool being broken when they try and report a bug 17:46:04 ack 17:46:08 ack 17:46:10 ack 17:46:18 ack 17:46:20 nirik, but they still can report it manually 17:46:21 nirik blame the move 17:46:22 nirik: probably :( 17:46:28 Southern_Gentlem++ 17:46:30 mattdm: Karma for jbwillia changed to 7 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:46:34 update to -6 or better and abrt-cli report 17:46:36 it works :) 17:46:51 #agreed 1861700 - Waived - We are waiving this under the late blocker exception since for Beta getting the fix in an update is sufficient 17:47:05 sure, there's lots of options... we will see. ;) 17:47:10 okay, now let's go have the fun one 17:47:14 #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one) 17:47:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700 17:47:17 #link https://pagure.io/fedora-qa/blocker-review/issue/16 17:47:18 #info Accepted Blocker, sddm, ASSIGNED 17:47:33 so this one is based on a newly-added criterion and doesn't represent a regression 17:47:37 do we have a 'this bug is too hard, skip' ? ;) 17:47:43 yes 17:47:50 and comments earlier today suggest we're getting closer to an answer but 17:47:53 sgallagh mentioned it just before 17:47:53 nirik: I would like that option 17:48:00 I think it's a complete mess. I would expect F34 beta to a good ETA for a fix. 17:48:00 i think we literally have to do that here :( 17:48:09 yes, we can definitely invoke the "too hard to fix" exception 17:48:17 * nirik sighs at regression. Nothing in fedora really is a regression. :) 17:48:23 yep, "too hard to fix" +1 17:48:29 #link https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases 17:48:41 -1 BB, +1 commonbugs 17:48:43 it's been ~3 weeks of this 17:48:44 zbyszek: :( you have any idea what it is yet? 17:49:12 yeah we can't delay until f34 beta :( 17:49:23 catanzaro thinks it might explain a bug he was seeing in gnome-shell 17:49:31 nirik: bberg points a finger at bad dbus interactin. My and cmurf's debugging points at busted qqt internals. 17:49:33 proposed #agreed 1861700 - Waived - We are waiving this under the "Difficult to fix blocker bugs" exception due to the difficulty in isolating the cause 17:49:33 "my old daddy said "if it hurts to do that, dont do that"" 17:49:42 accessibility related 17:49:46 It's probably both. 17:49:57 ack 17:49:58 ack 17:50:03 ack 17:50:09 ack 17:50:13 ack 17:50:14 ack 17:50:15 yeah, icky. well, at least lots of work for people to track it down. ;) 17:50:21 ack 17:50:25 mattdm: Finally our chance to skip a release and work on clean up stuff ;P 17:50:30 * mboddu hides from mattdm :D 17:50:31 ack 17:50:47 #agreed 1861700 - Waived - We are waiving this under the "Difficult to fix blocker bugs" exception due to the difficulty in isolating the cause 17:51:06 #topic Current status - blockers 17:51:06 should likely be another common bugs? 17:51:27 #info All accepted blockers are fixed or waived 17:51:27 doesn't hurt to inform 17:51:41 YAY 17:51:48 cmurf: yes 17:51:50 nice 17:51:51 thus +1 commonbug 17:52:03 Hi 17:52:08 .fas lailah 17:52:09 Lailah: lailah 'Sylvia Sánchez' 17:52:23 #topic Current status - test matrices 17:52:25 I would say all waived blockers -> commonbugs 17:52:27 #link https://fedoraproject.org/wiki/Category:Fedora_33_Beta_Test_Results 17:52:44 frantisekz: are you the designated sharer of news? 17:53:11 I'm still running AD tests for Server. I'm having some issues, but I *think* they're on the AD Server side and not Fedora 17:53:21 yep 17:53:35 I'm in the middle of installing a new AD Server VM to retry against. 17:53:48 Test results are solid, the only major missing category is Active Directory 17:53:57 lruzicka: no objection 17:54:20 well... 17:54:21 sgallagh++ 17:54:33 sgallagh++ 17:54:33 frantisekz: Karma for sgallagh changed to 9 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:54:36 #info Test results are solid, the only major missing category is Active Directory, which sgallagh is working on 17:54:45 frantisekz++ 17:54:45 mattdm: Karma for frantisekz changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:54:47 sgallagh++ 17:54:47 sgallagh++ 17:54:48 mattdm: Karma for sgallagh changed to 10 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:54:51 Southern_Gentlem: Karma for sgallagh changed to 11 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:54:51 sgallagh++ 17:54:58 sgallagh++ 17:54:58 sumantro: Karma for sgallagh changed to 12 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:55:03 sgallagh++ 17:55:03 cmurf: Karma for sgallagh changed to 13 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:55:04 tl;dr version: I can join a domain and authenticate successfully, but I'm getting pam_access() rejected 17:55:24 I suspect I changed something in the bowels of GPO last time around and now I can't find it, so I'm starting fresh to confirm 17:55:38 I have ~90% confidence that we're good here 17:55:57 sgallagh: how much time do you need to verify? 17:56:01 well, and it would be 100% within 5 days, and thus a late blocker exception :) 17:56:02 we can play elevator music and tell dad jokes until you are done? 17:56:13 cmurf++ 17:56:28 bcotton_: 10-20 minutes? 17:56:35 So... I have a proposal how to fix the abrt server issue 17:56:47 zbyszek: remove it from the default packages? 17:56:51 :D 17:56:51 :D 17:57:00 .fire bcotton_ 17:57:00 adamw fires bcotton_ 17:57:03 now if you think about it, egg salad is still chicken 17:57:03 😢 17:57:05 Better. Just fix all other bugs. Then the abrt server not needed. 17:57:13 brilliant! 17:57:13 😆 17:57:18 zbyszek++ 17:57:20 zbyszek++ 17:57:20 nirik: Karma for zbyszek changed to 9 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:57:21 haha 17:57:39 okay, are there any other questions or comments about the testing while we stall? 17:57:49 zbyszek++ 17:57:49 mboddu: Karma for zbyszek changed to 10 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:58:06 or should we go to releng with info about the RC and come back? 17:58:09 zbyszek++ 17:58:09 Conan_Kudo: Karma for zbyszek changed to 11 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:58:16 * nirik sees no sugar testing. sighs sadly. ;( 17:58:25 zbyszek++ 17:58:25 sumantro: Karma for zbyszek changed to 12 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:58:30 speaking of badges, reminder for anyone who has done btrfs testing and doesn't have a btrfs badge 17:58:38 ask me or Eighth_Doctor 17:59:06 OMG Do we have a Time Lord here? 17:59:41 Eighth_Doctor :-) 17:59:44 👋 17:59:51 Would you like to have a jelly baby? :) 18:00:00 Yes, please, thank you! 18:00:08 #topic Current status - RC 18:00:15 * Eighth_Doctor gives Lailah a couple of jelly babies 18:00:21 okay mboddu what can you tell us about our lovely RC 18:00:37 bcotton_: Well, we got all the release blocking artifacts ;P 18:00:51 hey, that's a good starting point 18:00:58 what are we missing on the non-blocking side? 18:01:05 But silverblue on aarch64, Scientific_KDE, Robotics anf few images on armhfp failed 18:01:16 #info https://pagure.io/releng/failed-composes/issue/1806 18:01:24 #info silverblue on aarch64, Scientific_KDE, Robotics and few images on armhfp failed 18:01:25 * mboddu is not a chair 18:01:25 oh dear 18:01:37 i think you can still #info 18:01:53 are these transient issues or actual problems with the variants? 18:02:05 i'm assuming the silverblue aarch64 one is the ostree issue we were talking about earlier? 18:02:06 arnhfp images are expected failures 18:02:06 * Lailah makes happy noises and eats the jelly babies from Eighth_Doctor 18:02:13 :) 18:02:27 #info the armhfp failures are expected 18:02:38 bcotton_: well, it's on the owners of those to debug them. ;) 18:02:40 the ones we care about are there 18:02:54 I don't see any variants that are release blocking failed 18:03:36 yeah, the compose fails if any of those fail. :) 18:03:42 we do need to solve this problem though 18:03:50 not today :) 18:03:58 bcotton_: Yeah, what other had said 18:04:33 is it fair to say that life in the new datacenter has reduced the occurence of "welp, this one just failed this time sorry" failures? 18:04:34 scientific-kde failed due to some eclipse deps 18:05:03 bcotton_: do we have enough time to quantify that yet? 18:05:23 The lab failures are missing deps 18:05:28 Sorry, folks. This is taking longer than expected. My fresh install got a BSoD immediately upon login 18:05:29 robotics failed due to fawkes broken deps 18:05:31 Eighth_Doctor: maybe? maybe not. partly i'm giving sgallagh time :-) 18:05:32 armhfp are expected one's as pwhalen said 18:05:34 Less stuff is up and running, so I'd say it's too early. 18:05:47 ****ing Windows 18:05:52 I'd say it's early, but optimistic. ;) 18:06:26 sgallagh: alas it's too bad we can't use samba AD for testing AD stuff 18:06:27 sgallagh: boo bsod. should we keep waiting or are you comfortable with the testing you've been able to do? 18:06:58 Give me a few more minutes? 18:07:14 👍️ 18:07:30 mboddu / pwhalen: the armv7 ones are... ? 18:08:13 sgallagh: we can do that 18:08:16 #topic Intermission 18:08:19 I mean, are caused by what? do we have a bug/etc? 18:08:41 #info We are waiting a few more minutes for sgallagh to run a few AD tests 18:08:50 some look space related (the image needs more space defined). Some look virt defined. (some weird kvm error) 18:08:54 nirik: we do, I'd have to look for it, but I am pretty sure there was an update this week 18:09:05 * bcotton_ uses this time to get another coke 18:09:25 * bcotton_ is not sponsored by Coca-Cola, but can be bought 18:09:28 nirik: Yeah, I haven't paid attention to the bug, it should be there 18:09:31 * mboddu checks as well 18:09:56 I think some of these can be fixed in kickstarts... or perhaps that would just expose the kvm/virt bug. :) 18:09:58 * Lailah already brought biscuits and coke 18:10:31 nirik: even if the ks is fixed, they will likely fail until imagefactory is fixed 18:10:41 Hmm, the kde-scientific failure is strange. 'dnf install eclipse-{egit,mpc,pde,pydev}' works fine in F33, with both updates-testing and not. 18:11:11 zbyszek: modules? might be you get modular and the image doesn't? 18:12:12 coke =/= Coca-Cola in certain circles... 18:12:55 I've always known Coke to mean Coca-Cola 18:13:10 Coke =/= coke 18:13:18 nirik: no, I disabled modular repos, the result is the same. 18:13:26 coremodule: We're healthy people, we don't do that another type of coke 18:13:54 The other kind is only for heroics, and we said we're not doing that. 18:13:59 Also, originally Coca-Cola had coke in it so... not that far off. 18:14:05 coremodule: i like to keep people guessing about what i mean when i say I had a "coke-fueled burst of productivity" 18:14:19 LOL 18:14:26 lol bcotton_++ 18:14:42 bcotton: That's brilliant! 18:14:45 zbyszek: odd. then not sure whats going on. 18:15:24 zbyszek: Is scientific lab still on? I thought they took it down. 18:15:31 Lailah: don't get used to it ;-) 18:15:57 bcotton: Don't get used to coke or don't get use to your brilliance? 18:16:03 Confirmed, it was an AD issue. 18:16:04 Lailah: Yeah, its still a thing 18:16:04 Lailah: both, really 18:16:13 hooray! 18:16:15 Uh oh 18:16:24 So Fedora 33 AD support is fine 18:16:35 \o/ 18:16:38 #info Fedora 33 Beta AD support is fine 18:16:38 mboddu: Great! I liked it even when I don't normally use it. 18:16:40 * nirik starts walking up the walkway to where the USS SHIPIT is docked. 18:16:50 okay, let's get all NASA control room then 18:16:58 #topic Go/No-Go decision 18:16:59 I will poll each team. Please reply “go” or “no-go” 18:17:00 nirik: hmm, I think I see. I removed eclipse-dltk-sh-5.11.0-1.fc31.noarch from my system, and now eclipse is uninstallable. 18:17:02 FESCo? 18:17:05 Go 18:17:08 go 18:17:13 #info FESCo is GO 18:17:17 Releng? 18:17:27 Go 18:17:30 #info RelEng is GO 18:17:31 go go go... 18:17:33 QA? 18:17:44 Go 18:17:49 Go 18:17:49 go 18:17:57 #info QA is GO 18:18:07 #agreed Fedora 33 Beta is GO 18:18:09 #info Fedora 33 Beta will release on 2020-09-29 18:18:16 YES! 18:18:18 mission control, we are go. over. 18:18:20 thanks everybody for attending! 18:18:31 * bcotton_ nearly copypasta'ed the no-go text by accident. that would have been tragic 18:18:35 \o/ 18:18:38 #action bcotton to announce decision 18:18:44 LOL 18:18:48 #topic Open floor 18:18:49 Anything else we need to discuss before closing? 18:19:01 i think we covered it all in intermission, but 18:19:01 I will update the common bugs tomorrow 18:19:05 lruzicka++ 18:19:14 #action lruzicka to update commonbugs 18:19:30 Not that I can remember. I have some pesky bugs but nothing worth the attention in a GO / NO GO meeting. 18:19:52 frantisekz: FYI, I am not pushing https://pagure.io/releng/issue/9725#comment-688133 since we will push all the stable updates that are on hold anyway before beta GA 18:19:55 and just to make sure i don't lie in the email, the RC is 1.3, right? 18:19:59 Thanks for the patience while I tied up that last loose end. 18:20:09 bcotton_, yes 18:20:11 mboddu: okay, thanks for letting me know :) 18:20:12 sgallagh: thanks for subjecting yourself to it 18:20:15 lruzicka: thanks 18:20:25 bcotton_: Yes 18:20:30 sgallagh: no worries 18:20:36 okay, well everyone take a deep breath. the window to final freeze is short! 18:20:38 * sgallagh goes to shower after dealing with Windows Server 18:20:42 bcotton_: what dates change? if any? 18:20:50 none 18:21:05 ok yeah that's what i thought 18:21:20 so final freeze is in... 18:21:25 a week and a half 18:21:26 2 weeks 18:21:28 So we're still in schedule, right? 18:21:32 Dates didn't change 18:21:35 Correct 18:21:41 We hit our secondary Beta target date 18:21:42 Right 18:21:46 #info Subsequent schedule milestones have not changed 18:21:48 Which means we don't adjust the GA dates 18:21:48 #link https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html 18:22:02 #info Final Freeze begins 6 October 18:22:03 10/20-10/27 18:22:05 sgallagh: GA ? 18:22:07 sgallagh: Nope, we missed the secondary target date 18:22:16 i thought beta slipped twice 18:22:19 mboddu: no, we missed the preferred and target date #1 18:22:24 beta slipped twice 18:22:27 Lailah: GA (General Availability) == Final 18:22:43 Oh, my mistake 18:22:46 nirik: so the eclipse snafu is fixed by the package in updates-testing. 18:23:04 zbyszek: great. should fix up after the updates flood gates open again. 18:23:11 Yep. 18:23:20 bcotton_: Ahh right, I assumed it wrong 18:23:20 oh, okay. Thanks sgallagh 18:23:35 alright, i'm going to call this done 18:23:38 thanks everyone 18:23:39 so it will be a zeroday for beta 18:23:45 bcotton_++ 18:23:49 it was an adventure, but we did it! 18:23:57 bcotton_ ++ 18:23:58 #endmeeting