16:01:35 <adamw> #startmeeting F37-blocker-review
16:01:35 <zodbot> Meeting started Mon Sep 26 16:01:35 2022 UTC.
16:01:35 <zodbot> This meeting is logged and archived in a public location.
16:01:35 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:01:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:35 <zodbot> The meeting name has been set to 'f37-blocker-review'
16:01:43 <adamw> #meetingname F37-blocker-review
16:01:43 <zodbot> The meeting name has been set to 'f37-blocker-review'
16:01:43 <adamw> #topic Roll Call
16:01:45 * kparal is here
16:01:45 <bcotton> .hello2
16:01:46 <adamw> ahoy folks, who's around for a short blocker fun time
16:01:46 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:01:49 * bcotton is half-here
16:01:50 <adamw> thanks for all the offline votes, everyone
16:01:55 <adamw> which half?
16:02:15 <bcotton> the left half
16:02:22 * coremodule is here
16:02:24 * AllanDay[m] here for ~30 minutes
16:02:31 <Penguinpee> .hello gui1ty
16:02:32 <zodbot> Penguinpee: gui1ty 'None' <gui1ty@penguinpee.nl>
16:03:01 <lruzicka> .hello2
16:03:03 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:04:49 * coremodule willing to act as secretary.
16:05:42 <geraldosimiao> .hello geraldosimiao
16:05:42 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:06:29 <adamw> alrighty, let's get rolling
16:06:39 <adamw> #chair bcotton lruzicka
16:06:39 <zodbot> Current chairs: adamw bcotton lruzicka
16:07:02 <adamw> boilerplate alert
16:07:03 <adamw> #topic Introduction
16:07:05 <adamw> Why are we here?
16:07:09 <adamw> #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:07:11 <adamw> #info We'll be following the process outlined at:
16:07:14 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:17 <adamw> #info The bugs up for review today are available at:
16:07:20 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:23 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:25 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:27 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Beta_Release_Criteria
16:07:30 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Final_Release_Criteria
16:07:35 <adamw> #info for Final, we have:
16:07:46 <adamw> #info 2 Proposed Blockers
16:07:51 <adamw> #info 4 Accepted Blockers
16:07:54 <adamw> #info 1 Accepted Previous Release Blockers
16:07:56 <adamw> #info 1 Proposed Freeze Exceptions
16:07:59 <adamw> #info 9 Accepted Freeze Exceptions
16:08:09 <adamw> #info coremodule will secretarialize
16:08:14 <adamw> let's get started with:
16:08:19 <adamw> #topic Proposed Final blockers
16:08:27 <adamw> #topic (2129914) Gnome-Maps crashes when searching for locations.
16:08:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2129914
16:08:31 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/923
16:08:33 <adamw> #info Proposed Blocker, gnome-maps, NEW
16:09:47 <kparal> "It's not really related to the location button, it happens often when "flying" to a place "far away" from the search result (probably due to many tiles being loaded quickly)."
16:09:59 <kparal> well, that sounds like a basic functionality of a map
16:10:47 <AllanDay[m]> easy to reproduce here
16:10:50 <bcotton> yeah, seems pretty foundational
16:11:11 <adamw> yeah, it's pretty close for me
16:11:12 <adamw> it's definitely FE at least
16:11:18 <adamw> and i'm leaning +1 blocker
16:11:20 <bcotton> adamw: what makes it close?
16:11:31 <kparal> +1 blocker
16:11:31 <adamw> i meant that in a positive sense
16:11:35 <adamw> er, positive for blockeriness
16:12:22 <bcotton> yeah, i'm +1 unless "close" means you have a reasonable argument for why it doesn't violate the "basic functionality" criterion
16:12:26 <cmurf> crashes when doing the thing we'd inevitably want it to do?
16:12:30 <cmurf> +1 blocker
16:13:00 <geraldosimiao> Agree. Maps could be slow to find new locations, but not crash. Maps crashing... Not good.
16:13:01 <geraldosimiao> +1 Blocker
16:14:45 <lruzicka> +1 blocker
16:15:06 <Penguinpee> FinalBlocker +1
16:15:17 <adamw> alrighty
16:15:31 <Penguinpee> FinalFE +1 unless that's implied being a blocker
16:16:13 <adamw> proposed #agreed 2129914 - AcceptedBlocker (Final) - this is agreed to be a violation of the requirement that all apps installed by default on x86_64 Workstation "withstand a basic functionality test", as we consider "flying to a new location" a pretty basic function of a Maps app
16:16:21 <adamw> Penguinpee: blocker status beats FE status
16:16:24 <kparal> ack
16:16:28 <cmurf> ack
16:16:30 <Penguinpee> ack
16:16:41 <lruzicka> ack
16:16:46 <bcotton> ack
16:17:05 <geraldosimiao> ack
16:17:45 <adamw> #agreed 2129914 - AcceptedBlocker (Final) - this is agreed to be a violation of the requirement that all apps installed by default on x86_64 Workstation "withstand a basic functionality test", as we consider "flying to a new location" a pretty basic function of a Maps app
16:17:50 <adamw> #topic (2127618) Nautilus thumbnailing doesn't work on hidpi screens
16:17:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2127618
16:17:57 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/918
16:18:00 <adamw> #info Proposed Blocker, nautilus, NEW
16:18:02 <adamw> #info Ticket vote: FinalBlocker (+0,0,-4) (-lruzicka, -bcotton, -geraldosimiao, -frantisekz)
16:18:05 <adamw> #info Ticket vote: FinalFreezeException (+6,0,-0) (+bcotton, +adamwill, +imsedgar, +gui1ty, +geraldosimiao, +frantisekz)
16:18:15 <adamw> so this one's at -4 but i left it on the list just in case we want to kick the tires a bit harder
16:18:33 <adamw> the "it spins the CPU constantly" part of it worries me
16:18:34 <adamw> the "you don't get thumbnails" part seems less serious
16:18:52 <kparal> it seems that it happens if you have display scaling enabled
16:19:03 <kparal> I wonder how many people have that
16:19:21 <kparal> having a constant cpu loop during the whole time nautilus is open is pretty bad in my eyes
16:19:45 <Penguinpee> kparal: Is it limited to scaled displays?
16:19:45 <adamw> kparal: well, anyone with a hidpi screen for a start
16:19:48 <adamw> which is a lot of people with laptops
16:20:03 <lruzicka> what is a hidpi screen? does 4k count?
16:20:09 <adamw> Penguinpee: it seems to be, yes
16:20:09 <kparal> Penguinpee: we don't know
16:20:16 <adamw> lruzicka: it's a function of resolution and density
16:20:29 <adamw> er. sorry. it's about density, which is a function of resolution and size.
16:20:37 <kparal> well I'm not sure if it affects 4k screens if you don't have scaling enabled
16:20:39 <adamw> i think the cutoff is like 180dpi.
16:20:41 <kparal> we don't have enough data
16:20:51 <kparal> but 1080p with scaling IS affected
16:20:57 <kparal> according to upstream responses
16:21:01 <lruzicka> ok, my monitors are not 180dpi any of them
16:21:07 <Penguinpee> My vote was/is based on it occupying a core completely.
16:21:19 <AllanDay[m]> is the issue just that the thumbnails are missing, or that it is constantly working to generate them?
16:21:40 <kparal> the latter
16:22:02 <AllanDay[m]> and you never get any thumbnails?
16:22:07 <kparal> no
16:22:16 <kparal> but that's the less worrying part
16:22:37 <kparal> we'd go with -1 blocker if just thumbnails were missing
16:23:10 <kparal> with the constant cpu load, I'd honestly vote for gathering a bit more feedback first, I guess. Perhaps this affects quite a lot of people.
16:23:47 <kparal> btw, this can be easily reverted in nautilus, it's a single line change. But they wanted to fix it properly in glib, which is valid, but will take more time
16:25:42 <Penguinpee> How about a temporary one line fix by the package maintainer?
16:26:43 <AllanDay[m]> let's focus on whether the issue is a blocker or not. we can figure out an appropriate fix based on that
16:27:02 <geraldosimiao> I suggest punt on the blocker status and grant a FE
16:27:50 <Penguinpee> geraldosimiao: I could along with that.
16:28:00 <Penguinpee> *go
16:29:36 <Penguinpee> +1 punt and move on. Enough votes for FE already.
16:29:49 <bcotton> i missed the CPU issue initially. i'd be willing to change my -1 to a punt
16:30:46 <AllanDay[m]> punt to when?
16:31:20 <kparal> why might learn which exact circumstances trigger this bug
16:31:28 <adamw> sorry folks, had to go talk to the dishwasher service guy
16:31:28 <kparal> and estimate the impact on users
16:31:53 <geraldosimiao> AllanDay[m]: tho the next blocker review meeting
16:32:01 <geraldosimiao> s/tho/to/
16:32:16 <adamw> kparal: i'm pretty sure it's scaling that triggers it. this makes logical sense. the higher the display density, the higher resolution thumbnails you need to look good.
16:32:45 <adamw> scaling is enabled automatically for hidpi displays and can be enabled manually too. i use 125% scaling on my desktop display.
16:32:59 <kparal> well for example if it was caused by 4k screen or just 1440p without scaling, it would be even worse than expected now
16:33:50 <adamw> yes, but there's no reason it would be caused by that.
16:34:00 <adamw> oh well, we can figure it out i guess.
16:34:01 <kparal> lruzicka: you have 4k screen right? with or without scaling? do you see the problem?
16:34:25 <lruzicka> adamw, how do you do 125% scaling? I can only do 200 and 300 using settings
16:34:32 <kparal> shrug, I'm blocker 0 here at the moment
16:34:44 <adamw> the nautilus commit literally says "thumbnails: Create larger thumbnails for higher density displays"
16:34:44 <lruzicka> kparal, 4k, no scaling, bigger fonts using accessibility layer
16:34:49 <coremodule> lruzicka, you have to enable fractional scaling
16:34:50 <adamw> so, yeah. that's what triggers it. :D
16:34:56 <lruzicka> coremodule, where?
16:35:03 <adamw> lruzicka: yeah, it's a non-default setting
16:35:06 <coremodule> through the cli
16:35:10 <coremodule> let me find the exact setting
16:35:25 <adamw> lruzicka: https://wiki.archlinux.org/title/HiDPI#Fractional_scaling
16:35:26 <coremodule> gsettings set org.gnome.mutter experimental-features “[‘scale-monitor-framebuffer’]”
16:35:26 <adamw> in the alternate fedora wiki
16:35:46 <kparal> fractional is not needed
16:35:49 <lruzicka> I can try to fiddle with that a bit, but I do not have high density display, I believe. It was quite cheap :D
16:35:59 <kparal> in the upstream report, there's a person affected with 200% scaling
16:36:05 <adamw> you can turn scaling on on any display
16:36:11 <adamw> it'll just make everything look huge on a regular one
16:36:16 <adamw> but for testing you can do it
16:36:42 <adamw> so the nautilus change did this:
16:36:46 <adamw> if we're at 100% scaling, no change
16:37:03 <adamw> if we're between 100% and 200% scaling, do an xlarge thumbnail
16:37:14 <adamw> if we're above 200% scaling, do an xxlarge thumbnail
16:37:27 <adamw> looking at the bug discussion, that would mean the problem is triggered any time scaling is set above 100%, i think.
16:38:04 <kparal> and you're saying 200% is the default for 4k?
16:38:48 <adamw> https://gitlab.gnome.org/GNOME/nautilus/-/commit/278435e3c20244b48986c6cd8b72c5317668c72d
16:38:48 <adamw> (if you have multiple displays at different scaling settings, it takes the highest)
16:39:46 <lruzicka> that can't be true - the system did not set the scaling to 200% by default on my laptop
16:40:14 <kparal> however, on that P16 we have in the office, I think it boots with 200% scaling
16:40:20 <kparal> perhaps some heuristics in play?
16:40:50 <adamw> kparal: no. it's not about resolution. it's about *density*.
16:40:59 <adamw> 200% is the default for displays above (iirc) 180dpi.
16:41:35 <kparal> ah, so it looks at the physical dimensions and resolution and computes density, ok
16:41:39 <adamw> a 4K display at 24" or less would trigger scaling
16:41:50 <kparal> (if EDID actually contains correct values)
16:41:56 <adamw> the most common case is high-resolution displays in laptops. what apple calls retina displays.
16:42:13 <lruzicka> adamw, mine is 32". and no scaling :D
16:42:51 <lruzicka> I mean external, the one in the laptop is below 4k
16:42:58 <adamw> yes. 4K at 32" is about 140dpi, which is higher than a typical monitor but not high enough for 2x scaling to make sense
16:43:08 <adamw> mine is the same, actually, and that's why I use 125% scaling
16:43:18 <adamw> don't you find everything looks kinda tiny on it at 100%? :D
16:43:37 <lruzicka> adamw, it does, so I am using "bigger text" in accessibility :D
16:43:56 <adamw> ah, right. try 125% scaling instead, you might like it more
16:43:57 <adamw> aaanyhoo
16:44:00 <lruzicka> I can live with that and 100% scaling
16:44:13 <adamw> since i'm fairly confident of the conditions that trigger the bug, does anyone want to vote? or want to wait for more details on how bad the CPU usage is?
16:45:38 <Penguinpee> I stick with my vote (in the ticket).
16:45:48 <bcotton> i'd like to know more about CPU usage, i think. but i'm willing to stick with my -1, too
16:46:08 <kparal> I'm 0 here
16:46:57 <geraldosimiao> I change my vote to 0 FB and keep +1 FE
16:47:26 <lruzicka> I am punt on blocker, grant FE
16:48:08 <adamw> Penguinpee: are you gui1ty?
16:48:43 <Penguinpee> adamw: as charged! ;)
16:48:49 <adamw> heh
16:49:00 <adamw> ok, so i think we're at -2 blocker
16:49:14 <adamw> geraldo and frantisek
16:49:31 <adamw> oh, geraldo said punt earlier, though
16:49:38 <geraldosimiao> yeah
16:49:40 <adamw> so i guess we're feeling punty
16:49:42 <geraldosimiao> +1 Punt
16:49:48 <geraldosimiao> sorry
16:50:43 <Penguinpee> Pretty much, yes. No vote on blocker from me on this at this stage.
16:50:49 <adamw> proposed #agreed 2127618 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - we're punting this to gather more info on how bad the CPU load issue is. We agree that the lack of thumbnails is an annoying cosmetic issue but not serious enough to block on. It's definitely serious enough (and in a component of the Workstation live, so not fully fixable with an update) to grant an FE
16:51:10 <lruzicka> ack
16:51:21 <Penguinpee> ack
16:51:44 <kparal> ack
16:52:39 <geraldosimiao> ack
16:52:48 <bcotton> ack
16:53:09 <adamw> #agreed 2127618 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - we're punting this to gather more info on how bad the CPU load issue is. We agree that the lack of thumbnails is an annoying cosmetic issue but not serious enough to block on. It's definitely serious enough (and in a component of the Workstation live, so not fully fixable with an update) to grant an FE
16:53:12 <adamw> ok, that's all the proposed blockers
16:53:22 <adamw> #topic Proposed Final freeze exceptions
16:53:32 <adamw> oh, we already did it.
16:53:40 <lruzicka> yup, I proposed both :D
16:53:43 <adamw> #info only 2129914 is proposed and we already gave it blocker status
16:53:46 <adamw> so, onto:
16:53:51 <adamw> #topic Accepted Final blocker status check
16:54:00 <adamw> as usual, a reminder we're not voting again, just checking status
16:54:10 <adamw> #topic (2128662) Abrt does not report a segfault which is reported in journalctl.
16:54:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2128662
16:54:15 <adamw> #info Accepted Blocker, abrt, ASSIGNED
16:54:24 <adamw> looks like there's investigation underway on this one but we didn't crack it yet
16:57:22 <adamw> #info this is being worked on, but we didn't crack the mystery yet
16:57:30 <adamw> #topic (2121944) greenboot-grub2-set-counter.service fails on 38 IoT with "cannot open `/boot/grub2/grubenv.new`: No such file or directory."
16:57:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2121944
16:57:34 <adamw> #info Accepted Blocker, greenboot, ON_QA
16:57:43 <adamw> I'm fairly confident I figured this one out, we just need the update to go stable
16:58:19 <adamw> we haven't had an iot build for several days so can't prove the openqa tests are fixed, but should be
16:58:49 <coremodule> cool, this is good
16:59:29 <Southern_Gentlem> 38??
16:59:58 <adamw> IoT rawhide composes are numbered (I forget why)
17:00:03 <adamw> but the bug affected both 37 and 38/tawhide
17:00:08 <Southern_Gentlem> ok
17:00:11 <adamw> s/tawhide/rawhide/
17:00:38 <adamw> #info fix for 2121944 is on its way stable and should work fine
17:00:43 <adamw> #topic (2049849) Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader
17:00:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2049849
17:00:49 <adamw> #info Accepted Blocker, grub2, NEW
17:01:09 <adamw> so, i proposed a criterion change to except Bitlocker, as we discussed during 36 cycle
17:01:18 <adamw> that will likely get pushed out this week, then this bug will no longer be a blocker
17:01:42 <adamw> #info release criterion change proposal to except Bitlocker-enabled systems from the requirement for grub boot of windows to work is in progress, when that is pushed out, this bug will no longer be a blocker
17:02:26 <bcotton> my favorite kind of fix!
17:02:41 <lruzicka> :)
17:04:12 <adamw> #topic (2123274) [abrt] totem: nouveau_pushbuf_data(): totem killed by SIGABRT
17:04:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2123274
17:04:13 <adamw> #info Accepted Blocker, mesa, ON_QA
17:04:19 <adamw> so it looks like we've gone ahead and backported the fix for this, which is exciting...
17:04:31 <adamw> it'd be great if folks with nvidia cards (not using proprietary driver) can test the new mesa and check for regressions
17:05:01 <adamw> #info fix for 2123274 is recently in updates-testing, it's a significant change that could break other things so we need folks with nvidia cards to check for regressions
17:05:38 <lruzicka> I am going to test it tomorrow, will have access to that computer :D
17:06:50 <adamw> awesome, thanks
17:07:01 <adamw> any other notes on any of the accepted blockers?
17:07:26 * Penguinpee has nothing
17:07:55 * kparal departs, see you
17:08:03 <lruzicka> not here
17:08:12 <adamw> alrighty then
17:08:14 <adamw> #topic Open floor
17:08:15 <adamw> any other business?
17:08:31 <geraldosimiao> no
17:09:05 <Southern_Gentlem> nope
17:10:20 <Penguinpee> nothing
17:11:16 <adamw> alrighty, thanks for coming everyone! thanks again for voting early and making it a short meeting
17:11:16 <adamw> #endmeeting