16:03:34 #startmeeting F30-blocker-review 16:03:34 Meeting started Mon Mar 18 16:03:34 2019 UTC. 16:03:34 This meeting is logged and archived in a public location. 16:03:34 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:03:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:03:34 The meeting name has been set to 'f30-blocker-review' 16:03:34 #meetingname F30-blocker-review 16:03:34 The meeting name has been set to 'f30-blocker-review' 16:03:34 #topic Roll Call 16:03:46 wahay, we have zodbot 16:03:56 so, who's around for some blocker review fun? or alternatively, blocker review not fun? 16:03:56 .hello2 16:03:57 frantisekz: frantisekz 'FrantiĊĦek Zatloukal' 16:03:59 zodbot++ 16:04:02 .hello2 16:04:03 bcotton: bcotton 'Ben Cotton' 16:04:13 * bcotton has to cut out in about 90 minutes 16:04:22 hmm.... so many people ... :D 16:04:43 * coremodule is here. 16:04:46 * sgallagh is semi-here 16:04:50 Also in FESCo meeting 16:04:57 I can be the secretary for the meeting. 16:05:07 thanks coremodule 16:05:19 sgallagh: man, we have to get you out of this 'fesco' thing that keeps conflicting 16:05:22 it can't be that important 16:05:42 * sgallagh shakes his head 16:05:50 #chair frantisekz bcotton 16:05:50 Current chairs: adamw bcotton frantisekz 16:06:03 * bcotton has the power! 16:06:05 impending boilerplate alert! 16:06:06 #topic Introduction 16:06:06 Why are we here? 16:06:06 #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:06:08 #info We'll be following the process outlined at: 16:06:08 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:06:10 #info The bugs up for review today are available at: 16:06:11 #link http://qa.fedoraproject.org/blockerbugs/current 16:06:13 #info The criteria for release blocking bugs can be found at: 16:06:15 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:06:17 #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria 16:06:19 #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria 16:06:37 #info for Beta, we have: 16:06:38 #info 2 Proposed Blockers 16:06:43 #info 3 Accepted Blockers 16:06:48 #info 3 Proposed Freeze Exceptions 16:06:48 #info 6 Accepted Freeze Exceptions 16:06:57 #info there are no Final proposals 16:07:05 #info coremodule will secretarialize 16:07:17 so without further ado... 16:07:23 #info we'll start with the proposed Beta blockers 16:07:31 #topic (1648907) grub2-common kernel.d plugin removes $ESP// directory rendering machine unbootable 16:07:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1648907 16:07:31 #info Proposed Blocker, grub2, POST 16:08:15 +1 blocker :D 16:08:17 so...this affects people who use systemd-boot 16:08:18 i am not voting twice 16:08:19 which is not default 16:08:34 but if you *do* decide to use it, then you upgrade to fedora 30...your system doesn't boot any more. this seems bad 16:08:37 or maybe I am if it's just adamw and I 16:09:06 in the bug I proposed accepting it under a provision we don't often use: 16:09:07 https://bugzilla.redhat.com/show_bug.cgi?id=1648907#c6 16:09:31 see https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Beta_Blocker_Bugs for that 16:09:35 yeah, sounds like +1 :) 16:09:46 is there any reason to consider blocking it for final instead of beta? 16:09:54 i understand the logic, but also there are a lot of non-default ways to hose your boot 16:10:27 i think i'd be 0 beta blocker and +1 final blocker from the "if this were the only blocker, would we delay the release?" standpoint 16:10:52 Yeah, I agree with bcotton here. If this was the only thing stopping Beta from going out the door, I'd not call it a blocker. 16:11:05 bcotton: true but there is an unfortunate irony in that the Fedora BLS feature is taking the spec from the systemd-boot folks, modifying it, and now stepping on systemd-boot 16:11:26 i'm fairly sure there *isn't* an irony threshold for blockers. :P 16:11:33 I honestly might not even call it a Final blocker, since the only way to get into this situation is to intentionally change your bootloader, which is absolutely not something that people do without deep technical knowledge. 16:11:57 i think i'm still at least +1 final blocker. i don't think it's reasonable to know about this bug and ship a release without fixing it. 16:12:02 * satellit_ listening late 16:12:11 I don't think Fedora should be a bull in a China shop 16:12:14 I'm -1 Beta Blocker, -1 Beta FE 16:12:15 adamw: if Alanis Morrissette starts singing about a proposed blocker, I'd +1 on that 16:12:22 sgallagh: -1 FE? 16:12:25 Yes 16:12:32 hey let's borrow that spec, change it, and oopsie! 16:12:35 I don't want any "fix" for this breaking the bootloader. 16:12:48 If it works today for standard usage, let's not destabilize that 16:13:04 i mean, if we refuse an FE they're just going to push it stable immediately after beta anyway, so if it breaks the bootloader, it's still gonna. 16:13:04 i agree with sgallagh, let's not risk breaking the bootloader for everyone by fixing a non-default case 16:13:16 ok we're already changing the bootloader functionality in Fedora 30 in the single most significant way ever since moving to grub2 16:13:21 only we won't find out about it until someone complains in the update feedback... 16:13:36 I would sooner say revert the BLS feature... 16:14:19 the Workstation WG last meeting brought up the BLS feature bugs during upgrades and wonder if it should be pushed to Fedora 31 16:14:42 so thursday is the go/no-go meeting. which means we'd really like to have a candidate composite today or tomorrow, so unless they fix it while we're arguing, it's sort of a moot point anyway. if we're no-go on Thursday then they have more time to get it in and tested 16:14:51 i'm not sure which position i'm arguing for here, actually 16:15:22 I can totally accept beta users getting bootloader nerfed 16:15:24 but not for final 16:15:40 beta users ^who experiment with systemd-boot or any other bootloader 16:15:46 adamw: If it lands after the Beta, it doesn't delay Beta. 16:16:08 They have time to fix it without derailing the release train in that case 16:16:22 i'm OK with that 16:16:35 okay, so, what does everyone else vote? 16:16:36 okay, i'll say my vote unqualified 16:16:43 -1 beta blocker, +1 final blocker 16:16:57 -1 beta blocker... changed my mind a little 16:17:14 -1 beta FE too, if we're asking about that 16:17:27 -1 beta blocker, -1 beta FE, 0 Final Blocker right now. (I could be persuaded on Final) 16:17:34 baring a compelling contra argument, -1 beta blocker, -1 beta FE; +1 final blocker 16:18:28 we need votes for beta blocker and FE at this poin 16:18:38 we don't necessarily need to decide on final blocker right now. 16:18:49 fair enough 16:18:50 -1/-1 for beta then 16:20:51 proposed #agreed 1648907 - RejectedBlocker RejectedFreezeException (Beta) - as this does not involve a default or supported bootloader, and the change required looks like it could break stuff badly if it goes wrong, we agreed this is not a blocker for Beta and the risk of taking the change as an FE is too high 16:21:05 ack 16:21:14 ack 16:21:44 ack 16:22:26 #agreed 1648907 - RejectedBlocker (Beta) RejectedFreezeException (Beta) - as this does not involve a default or supported bootloader, and the change required looks like it could break stuff badly if it goes wrong, we agreed this is not a blocker for Beta and the risk of taking the change as an FE is too high 16:22:38 #topic (1688462) System upgrades involving modular content require explicit --setopt=module_platform_id to work correctly 16:22:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=1688462 16:22:38 #info Proposed Blocker, libdnf, NEW 16:23:03 so, there's a bit of backstory here...we've had #1656509 on the accepted blocker list for a while but it's one of those messy bugs that sort of covers a lot of ground 16:23:22 so we decided to split it up a bit to be more clear 16:23:24 if it weren't for the upgrade problems i've been reading about, I'd be nervous about how few blocker bugs we've had this cycle... 16:23:52 cmurf++ 16:24:10 1656509 now covers system-upgrade plugin not handling the module platform id properly *at all*, even with an explicit --setopt; this covers the module platform ID not being detected somehow, so the explicit --setopt is needed, even after that first bug is fixed 16:24:25 cmurf: lack of successful composes isn't really helping :/ 16:25:00 i put this on proposed beta blockers so we can discuss it, but i think i'm -1 beta blocker, i think the --setopt workaround is OK for a beta 16:25:03 The opinion of the Modularity WG is that requiring any specialized arguments for this is undesirable and that upgrades should work the same as they have previously. 16:25:12 i'm +1 final blocker, as modularity wg agreed, we shouldn't require the --setopt at final 16:25:23 But yeah, I'm okay with -1 beta blocker, +1 final blocker 16:25:39 i'm so totally in the dark understanding modularity and what's expected behavior, that I don't feel like I can vote 16:25:49 cmurf: well, you don't need much knowledge really 16:25:52 -1 beta, +1 final 16:25:58 cmurf: The expected behavior is that you shouldn't have to understand modularity to perform upgrades 16:26:02 This breaks that expectation 16:26:02 haha 16:26:10 the issue is just this: for an upgrade from f29 to f30 to work properly you need to add a special magic parameter to the dnf system-upgrade command that you didn't need before 16:26:42 OK so then why should upgrades work for final but not beta? isn't it a release criterion for beta that upgrades work? 16:26:43 if you just use the same command you used for the last X releases, it'll likely fail with a fairly cryptic error about module dependencies 16:27:04 cmurf, upgrades work, just with one more parameter for dnf 16:27:08 cmurf: for me, i'm OK with a beta release note and commonbug that just says "yeah it does that, add this magic parameter" 16:27:11 i think that's OK for a beta 16:27:14 i just don't think it's OK for final 16:27:31 ok that's convincing 16:27:37 Yeah, I think we've previously agreed that minor workarounds are okay for Beta 16:27:39 I don't mind an extra hoop for beta users anyway 16:27:54 kinda like a "are you REALLY sure?" 16:28:09 -1 beta block, +1 final block 16:28:39 -1 beta blocker, -1 beta fe, +1 final blocker 16:29:38 Ah, yeah. I'm also -1 beta FE at this point. 16:29:43 Best not to rock the boat 16:29:50 -1 beta FE as well 16:29:55 yeah, especially since dnf team seems not to understand the 'fix one bug at a time' concept 16:30:00 this is the U.S.S. Ship It 16:30:13 whenever we ask for a blocker/FE fix we get eight updates to six packages with seventeen changes and a rewrite of the database system 16:30:15 cmurf: you're funny today :-) 16:30:30 adamw++ 16:30:39 * cmurf is funny everyday :P 16:30:48 that's what his mom told him anyway 16:32:01 shhh shhh i'm still laughing it's ok, go on 16:32:01 proposed #agreed 1688462 - RejectedBlocker (Beta) RejectedFreezeException (Beta) AcceptedBlocker (Final) - we agreed that the workaround here (using --setopt) is OK for Beta, but not acceptable for Final, so this is accepted as a Final blocker. We do not grant a Beta FE as we don't think fixing this late for Beta is worth the risk of taking more DNF change. 16:32:14 ack 16:32:17 ack 16:32:17 ack 16:32:22 ack 16:32:27 #agreed 1688462 - RejectedBlocker (Beta) RejectedFreezeException (Beta) AcceptedBlocker (Final) - we agreed that the workaround here (using --setopt) is OK for Beta, but not acceptable for Final, so this is accepted as a Final blocker. We do not grant a Beta FE as we don't think fixing this late for Beta is worth the risk of taking more DNF change. 16:33:44 #topic Accepted Beta blockers 16:33:57 #info that's all the proposed Beta blockers, moving onto existing accepted ones 16:34:04 since we're now close to release, we'd best check in on all of these 16:34:13 #topic (1688925) Need kde-settings-30 with appropriate settings for F30, including desktop background 16:34:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1688925 16:34:13 #info Accepted Blocker, kde-settings, ON_QA 16:34:41 yeah it's hammer time for the accepted blockers 16:34:56 this one is fairly straightforward, we just need to test and karma the update and push it stable 16:35:26 if folks can do that it'd be appreciated, probably all that's needed is to install KDE in a VM, update this kde-settings, reboot and check nothing explodes (and hopefully the new background shows up) 16:35:28 * jlanda waves 16:35:41 #info the update is submitted, we just need to test it so it can be pushed stable 16:35:49 ack 16:35:55 ack 16:36:23 Acks aren't needed on status check-ins 16:36:26 (Right?) 16:36:41 it's just short for acknowledge the ##info 16:36:47 yeah, right 16:36:53 unless we have to agree something 16:36:57 pipe down there ack chorus :P 16:36:59 I coulda done an Ackbar 16:37:07 adamw can say it's a trap 16:37:08 #topic (1656509) F29 to F30+ upgrades fail unless --allowerasing is used due to issue with module_platform_id, even explicit --setopt=module_platform_id does not work 16:37:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=1656509 16:37:09 #info Accepted Blocker, libdnf, ON_QA 16:38:00 ok so beta users would need to use two flags on upgrades? 16:38:03 so, this one is the first stage of the dnf bug 16:38:22 no, for this one you actually can't get a correct upgrade with dnf system-upgrade, aiui anyway 16:38:23 the `--setopt` one in addition to `--releasever`, yeah 16:38:35 that's not my understanding? 16:38:41 --releasever is always required 16:38:46 the other bug is about --setopt being required 16:38:55 adamw: I meant *after* this one is implemented, you need both of those to upgrade 16:39:04 oh, yes. 16:39:08 I may have chosen confusing language 16:39:18 hmm, I see I didn't understand it properly when testing that last week 16:39:22 but the problem this bug covers is, even with --setopt, without this fix, dnf system-upgrade doesn't work right. 16:39:32 ok in this bug is suggesting some edge case where you might need --allowerasing (a third flag) 16:39:38 the only way to get an upgrade through is with --allowerasing , and it removes stuff it shouldn't remove. 16:39:54 oh i see 16:40:05 it's not a true fix/workaround, it just lets the operation proceed with the bug, by removing any packages it affects. 16:40:32 the only way to get a 'correct' upgrade with this bug, again aiui, is just to use dnf distro-sync...but then you're doing it online and it might blow up on you. 16:40:45 ok and depending on what packages are removed, the resulting upgrade might still be confused but at least it completes? 16:40:59 well, i mean, it won't be confused, it'll just be *missing stuff*. 16:41:00 :P 16:41:14 guess it depends on what it's missing don't it? 16:41:14 (anything that's part of a module, i think, more or less.) 16:41:38 got it 16:41:43 anyway, it's an accepted blocker 16:41:45 Can it delete paclages that are part of any blocking pack? 16:41:48 so what's the status of the fix? 16:42:01 the criterion specifically says "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)." 16:42:06 ok, so that's the other thing 16:42:11 it would be weird to upgrade a default wks and end without gnome :D 16:42:15 this was never actually directly reviewed as an f30 blocker 16:42:31 was this the one we punted to fesco? 16:43:01 This sound a clear blocker if it deletes non deprecated packages 16:43:10 And it does 16:43:13 it was reviewed as an f29 blocker, then the bug was closed (by me) (apparently incorrectly), later it was reopened and bumped to f30 beta blocker, but the 'acceptedblocker' tag wasn't removed 16:43:37 so we have not specifically reviewed it as an f30 blocker, but given my understanding of the bug (as described above), i'd say it is one. 16:43:44 haha 16:43:46 convenient 16:43:53 does anyone object to it being an f30 beta blocker? 16:43:58 +1 bb 16:45:07 That logic is... impeccable. So yeah, +1 beta blocker 16:45:14 +1 16:45:35 +1bb (-1 objection to adams question) 16:45:37 +1 beta blocker; the U.S.S. Ship It's boatswain has a frowny face now... 16:46:10 ? 16:46:14 #info this was never formally reviewed as an F30 Beta blocker due to various shenanigans with it being closed and opened and bumped, but we agreed at this meeting that it ought to be one 16:46:47 so, as far as a fix goes...it seems we basically have one, but i am still trying to figure out from the dnf folks whether it needs to be pushed to a) f29, b) f30 or c) both for the bug to be fixed 16:47:10 it also seems that upgrades from f28 to f30 would be affected and fixing that isn't as easy 16:47:19 though less things were modular in f28 16:47:59 but, f28 didn't have modular repos enabled by default, or did? 16:48:15 frantisekz: f28 server did, iirc 16:49:12 Yes, F28 Server Edition had the module repos 16:49:29 hmm, so, yeah, we'll have to fix it in F28 too :/ 16:49:33 But even then, there were very few modules 16:49:39 And none of them default. 16:49:48 So I think we're *probably* going to get away with it 16:49:52 yeah 16:49:54 okay 16:50:00 i'm not actually seeing that any of the openqa tests are hitting it atm 16:50:02 so it's probably okay 16:50:13 Just keep an eye out for any meddling kids... 16:50:29 enable all modules you can, do an upgrade? 16:50:59 cmurf: that wouldn't hit the criterion, though, the criterion covers only default package sets of release blocking media 16:51:00 AAANYHOO 16:51:35 #info so far as a fix goes, one exists and updates are submitted for f29 and f30, they just need to be tested and we need to clarify which one(s) need to be pushed for the issue to be resolved 16:52:06 #topic (1683197) gdm Fails to load with "nomodeset" 16:52:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1683197 16:52:07 #info Accepted Blocker, systemd, ASSIGNED 16:52:12 so, this one's getting fun. 16:52:46 ajax came up with a fix for this, only...turns out it's not really a complete fix. 16:52:55 yeah I thought it was complicated before finding out systemd was involved 16:52:58 basically, it only fixes UEFI. 16:53:42 i suspect that there are more bios boxed wih weird gpus that actually need nomodeset than uefi ones 16:54:00 still, we know a bit more about the bug now...on the one hand, it very likely *does* affect all systems, it is not in any way hardware-specific, at least as I now understand it 16:54:13 on the other hand, f29 had the same bug and we shipped that and no-one's dead. 16:54:27 (though i dunno if anyone's complained about it.) 16:54:30 lol 16:54:39 the anchor has been missing for a year! 16:54:46 I am okay with not blocking on this... at least not beta 16:54:57 we're fine as long as we don't need a shore to land on 16:55:18 but we should change our criterions / test cases in that case 16:55:24 well, here's one person 16:55:24 https://www.reddit.com/r/Fedora/comments/9twenw/fedora_29_install_boot_hangs/ 16:55:26 I wish we knew how many systems were affected 16:55:39 The criterion had more sense 5 years ago than today 16:55:56 with Fedora 29 fail you could fall back to Fedora 28 media 16:56:01 But nowadays? 16:56:14 and if it's not going to be fixed by final, I'd vote to remove the basic graphics option from the boot menu 16:56:18 here's another 16:56:19 https://ask.fedoraproject.org/en/question/130444/unable-to-boot-on-live-usb-with-nomodeset/ 16:56:53 OK so I opened an issue for the Workstation WG for this topic and they haven't flagged it for a meeting to discuss criteria stuff 16:57:39 I agree with kparal that some kind of basic video should actually work, based on the test case expectations, rather than merely having a boot menu item present that sets whatever parameter 16:58:16 so, i think i'm gonna try and get some followup on this today 16:58:31 But I'm also not willing to block on this until the Workstation WG settles exactly what to block on 16:58:33 but we may end up having to debate whether to keep the criterion at go/no-go, or something 16:58:42 yeah I'm fine with that 16:58:53 And a basic install option that runs anaconda on text mode instead of that? Would that be possible? 16:58:56 we can't ignore not many people were affected with this problem for Fedora 29 16:59:12 cmurf: as far as we know 16:59:33 bcotton: we are all powerful and omnicient 17:00:57 i mean, i find quite a lot more results, now i'm googling around 17:01:08 just google "fedora 29" "nomodeset" and "fedora 29" "basic graphics" 17:01:55 google... I do "fedora 29" "nomodeset" and I see results from 2016... that is not helpful 17:02:22 anyway yeah it might be more than a few people affected 17:02:38 cmurf: look through the ask.fp.o and reddit results, that's where most of the people are. :P 17:02:52 i'll take your word for it 17:02:59 #info the proposed fix for this turns out not to be a complete fix, so this is putting the release at risk at this point 17:03:16 #action adamw to follow up with graphics and systemd folks to see if a fix is still plausible 17:03:22 would this block beta or final? or is that also an open question? 17:03:58 right now i would.go on -1bb +1fe +1fb 17:04:12 We have this bug on current, no sense on blocking beta 17:04:17 it's a basic criterion 17:04:22 so it's hard to argue for it blocking final 17:04:22 But we should fix it 17:04:31 so it *ought* to be for beta 17:04:44 by the criteria it should either block beta or nothing 17:04:49 roger 17:04:51 I'd like to suggest that we temporarily call this "not a blocker" if it's the only thing holding up an RC today 17:05:08 Leaving it open to be reconsidered at Go/No-Go 17:05:38 I think we need to take it seriously on the one hand; but I think it's an overcorrection from Fedora 29 to block beta because of it. 17:05:42 we...don't really need to do that 17:05:55 we already let the cat out of the bag so to speak 17:06:06 as there is no actual practical difference between a 'candidate compose' and an 'RC' these days except what we call it in the tickets 17:06:07 adamw: Well, we don't spin RCs until the known blockers are fixed. 17:06:18 yep 17:06:25 I'm with sgallagh 17:06:26 adamw: I thought there was still a couple things that differed. 17:06:27 if we want a candidate i can just create one and we can decide what to call it later. :P 17:06:39 haha ok fine do that then 17:06:41 If my info is old, sure 17:06:52 nah, there's a difference between a nightly and a candidate, but what releng does when i request a 'candidate compose' versus an 'rc' is exactly the same. at least so far as i remember. 17:07:19 i'll check with mboddu later, though. 17:07:49 By criterion is a clear beta blocker but is weird blocking the beta with a bug present on our current supported releaae 17:07:52 OK, as long as we get a "candidate compose" that isn't blocked on this, I'm fine with it 17:07:56 roger 17:08:21 jlanda: precisely - I'm suggesting a compromise given the fact we fudged on this for all of Fedora 29 without intention or even awareness we fudged it 17:08:31 i don't think we actually fudged on it for f29 17:08:36 i think we just didn't consider it 17:08:38 but i'd have to check 17:08:42 besides, we don't even know what we're blocking on exactly since we're not even sure of what the fix can be 17:08:57 and it's an open question if the criterion has the support of the WG 17:09:39 and whether it needs revision and relocation to be explicitly beta or final blocking 17:09:48 cmurf: the f29 bug you referenced is a different one 17:09:57 i think this bug showed up later in the f29 cycle but was never caught for some reason 17:09:59 same outcome 17:10:21 nah, the earlier f29 bug was definitely configuration-dependent - note it was UEFI only, for instance 17:11:14 i recognized the details are different, the outcome of a black screen instead of GDM was the same 17:11:24 on an affected system. yes. 17:11:27 anyhow 17:11:32 i think we talked this to death at this point 17:11:34 I had more information about the failure with the F29 bug than the F30 bug, on the same systems 17:11:50 #topic Open floor 17:11:54 horse is hamberdered 17:12:11 anyone have other bugs to bring up, anything else that's threatening f30 beta at this point? 17:12:26 oh wait 17:12:28 did i miss FEs? 17:12:32 yep 17:12:40 yes i did 17:12:41 sorry 17:12:42 i wanna know where all the bugs are 17:12:46 #topic Proposed Beta freeze exceptions 17:12:52 #info sorry, went to open floor too soon 17:13:01 #topic (1686851) nm-connection-editor should be moved to the X-GNOME-Utilities folder 17:13:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=1686851 17:13:01 #info Proposed Freeze Exceptions, gnome-menus, ON_QA 17:13:48 seems safe? 17:13:57 i'm +1 for this, it's a visible annoyance on the workstation live and the fix looks very safe 17:14:01 +1 17:14:05 +1 17:14:06 +1 FE 17:14:30 +1 17:15:02 +1 fe 17:15:50 But. The visible annoiance is not so big anymore 17:16:22 They fixed on upstream: now their just on the frond foldee 17:16:37 s/frond whatever/wrong foldsr 17:16:42 Ar, folder :D 17:17:26 proposed #agreed 1686851 - AcceptedFreezeException (Beta) - this bug is quite visible in the Workstation live image (so cannot be fixed with an update) and the fix is very safe 17:17:33 ack 17:17:56 ack 17:18:03 ack 17:18:38 #agreed 1686851 - AcceptedFreezeException (Beta) - this bug is quite visible in the Workstation live image (so cannot be fixed with an update) and the fix is very safe 17:18:40 #topic (1684424) [Wayland][ja_JP] [Firefox][wayland] Not able to commit Japanese input from the candidate list, on address bar or search field. 17:18:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=1684424 17:18:40 #info Proposed Freeze Exceptions, mutter, NEW 17:19:33 +1 FE 17:19:36 so, we had this as a final blocker (iirc) in f29 17:19:47 +1 beta FE 17:19:48 it seems it was worked around in gnome 3.30 but neither the workaround nor a fix is in 3.32, so it's back 17:19:52 so FESCo voted to push wayland by default to F31 17:20:03 I wouldn't block beta on that 17:20:14 i don't think this relates to firefox being wayland native 17:20:39 counterpoint: https://bugzilla.redhat.com/show_bug.cgi?id=1684424#c2 17:20:53 hmm 17:21:09 i am not 100% sure about that 17:21:23 i'm not sure bhushan did quite what martin wanted... 17:21:56 +1 FE if it's still relevant 17:22:00 so it's Xwayland related 17:22:25 +1 fe 17:23:36 i'm confused if it only happens with ffwayland, or with ffxwayland, clearly sounds like it's not happening with ffx11 17:23:55 the tester doesn't actually say they tested with firefox-x11 17:24:06 they say "Martin, yes the issue is with wayland. It works fine i.e I'm ablke to commit jpn input properly with x11." 17:24:16 that could equally mean they tried an X11 *session* instead of a Wayland one, and it worked 17:24:23 comment 2 says he gets it to work on x11 17:24:47 i.e. they didn't test native vs. non-native firefox on a wayland session 17:24:48 anyhow 17:24:53 right 17:24:55 i'm not sure we need to decide that, i guess 17:25:06 +1 FE for me too 17:25:40 proposed #agreed 1684424 - AcceptedFreezeException (Beta) - as described this is a significant problem for CJK-type input that will be present in the Workstation live and so cannot be fixed fully with an update 17:25:50 ack 17:25:53 ack 17:28:14 #agreed 1684424 - AcceptedFreezeException (Beta) - as described this is a significant problem for CJK-type input that will be present in the Workstation live and so cannot be fixed fully with an update 17:28:19 #topic (1687896) python-aniso8601 cannot be installed on Fedora 30 17:28:20 #link https://bugzilla.redhat.com/show_bug.cgi?id=1687896 17:28:20 #info Proposed Freeze Exceptions, python-aniso8601, NEW 17:28:37 apparently this is preventing some builds going ahead in copr, i guess i'd be ok with an FE for that purpose 17:28:42 i guess I can go either way on this 17:28:42 hmm, package I maintain, I broke that, I created FE... :) 17:28:58 it Shouldn't be able to break anything significant ;) 17:29:05 +1 beta FE 17:29:06 +1 FE 17:29:09 +1 17:29:44 +1 17:31:24 proposed #agreed 1687896 - AcceptedFreezeException (Beta) - this package is a build dependency for others, so it not being installable is causing problems for other package builds. We grant it an FE to solve that issue. It should not affect the actual Beta composes at all. 17:31:34 ack 17:31:41 ack 17:31:59 ack 17:32:00 ack 17:32:36 #agreed 1687896 - AcceptedFreezeException (Beta) - this package is a build dependency for others, so it not being installable is causing problems for other package builds. We grant it an FE to solve that issue. It should not affect the actual Beta composes at all. 17:32:40 ok, so NOW we can do... 17:32:43 #topic Open floor 17:32:46 same question as before. :P 17:32:55 finally ... free :D 17:34:07 #info the go/no-go meeting is at 1700 UTC Thursday in #fedora-meeting 17:34:28 dun dun DUNNNN 17:34:31 #info the release readiness meeting is at 1900 UTC Thursday in #fedora-meeting, even if we are no-go 17:35:16 #info for F32, I will make sure the go/no-go and release readiness meetings don't fall on the first weekend of the NCAA men's basketball tournament :-D 17:36:01 psshhh and then it conflicts with lacrosse or hockey instead? thxbutnothx 17:37:23 (basketball and baseball, there's what 4000 games per season between them?) 17:37:39 cmurf: E_TOOFEWGAMES 17:37:57 hey, just so long as i don't miss the Milton Keynes Invitational Tiddlywinks Grand Master Tournament everything will be fine 17:38:18 what the 17:38:22 you made that up! 17:38:45 hey adamw how about some more MOM jokes huh? 17:39:26 yes. yes i did. 17:43:26 alrighty, sounds like we're done here 17:43:30 thanks for coming, everyone 17:43:31 #endmeeting