f32-blocker-review
LOGS
16:00:26 <adamw> #startmeeting F32-blocker-review
16:00:26 <zodbot> Meeting started Mon Mar 30 16:00:26 2020 UTC.
16:00:26 <zodbot> This meeting is logged and archived in a public location.
16:00:26 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:26 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:00:26 <adamw> #meetingname F32-blocker-review
16:00:26 <adamw> #topic Roll Call
16:00:26 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:00:31 <adamw> ahoy mateys
16:00:35 <adamw> who's around for blocker review fun?
16:00:38 <coremodule> .hello2
16:00:39 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:00:41 <coremodule> ahoy
16:00:42 <bcotton> .hello2
16:00:43 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:01:41 * pwhalen is here
16:01:47 <lruzicka> .hello2
16:01:48 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:02:07 <lruzicka> yoha, coremodule
16:02:26 <coremodule> yo yo yo
16:02:30 * kparal is here
16:03:11 <frantisekz> .hello2
16:03:12 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:03:13 <cmurf> here!
16:04:12 <adamw> #chair lruzicka bcotton
16:04:12 <zodbot> Current chairs: adamw bcotton lruzicka
16:04:38 <adamw> impending boilerplate alert
16:04:39 <adamw> #topic Introduction
16:04:40 <adamw> Why are we here?
16:04:40 <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:04:40 <adamw> #info We'll be following the process outlined at:
16:04:40 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:04:44 <adamw> #info The bugs up for review today are available at:
16:04:46 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:04:48 <adamw> #info The criteria for release blocking bugs can be found at:
16:04:50 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:04:52 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
16:04:54 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
16:04:56 <adamw> #info for Final, we have:
16:05:00 <adamw> #info 7 Proposed Blockers
16:05:00 <adamw> #info 2 Accepted Blockers
16:05:05 <adamw> #info 3 Proposed Freeze Exceptions
16:05:05 <adamw> #info 1 Accepted Freeze Exceptions
16:05:13 <adamw> aaaaa the proposed blocker count keeps going up
16:05:16 * adamw hides the button
16:06:15 <adamw> who wants to secretarialize?
16:07:36 * sumantro is here :D
16:07:40 <coremodule> I'll do it
16:07:53 <adamw> thanks
16:07:57 <adamw> #info coremodule will secretarialize
16:08:00 <adamw> alrighty, let's get going
16:08:09 <adamw> #topic proposed Beta blockers
16:08:10 <adamw> er
16:08:11 <adamw> #undo
16:08:11 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fdff7d5b450>
16:08:16 <adamw> #topic proposed Final blockers
16:08:29 <adamw> come on adam, keep it together, you can do this, they don't have to know about the whiskey...
16:08:36 <adamw> #topic (1816098) blivet-gui fail to create a encrypted PV/VG partition
16:08:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1816098
16:08:36 <adamw> #info Proposed Blocker, blivet-gui, POST
16:09:11 <kparal> that's a really nice proxy error
16:09:28 <adamw> on bugzilla?
16:09:33 <adamw> it came up for me eventually
16:09:40 <kparal> reload fixed it
16:09:52 <kparal> but the speed recently has been... suboptimal!
16:09:57 <adamw> yeah
16:10:07 <cmurf> yeah
16:10:08 <adamw> welp, per the terrible criterion i wish we never wrote, definitely +1 :)
16:10:27 <kparal> +1
16:10:27 <frantisekz> +1 Blocker
16:10:34 <Southern_Gentlem> +1 blocker
16:10:34 <pwhalen> +1 blocker
16:10:39 <bcotton> +1 blocker
16:11:03 <cmurf> +1
16:11:31 <adamw> proposed #agreed 1816098 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration."
16:11:57 <frantisekz> ack
16:12:02 <sumantro> ack
16:12:02 <pwhalen> ack
16:12:12 <bcotton> ack
16:12:40 <kparal> ack
16:12:57 <lruzicka> ack
16:13:00 <adamw> #agreed 1816098 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration."
16:13:05 <adamw> #topic (1812596) repoquery suddenly missing results in --whatrequires on Fedora 32+ (seem to be related to virtual provides)
16:13:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1812596
16:13:06 <adamw> #info Proposed Blocker, dnf, POST
16:13:22 <frantisekz> hmm, I am not really sure about this one
16:13:30 <frantisekz> I'd incline to -1 here, +1 FE
16:13:57 <adamw> -1 blocker
16:14:07 <adamw> i'm not really seeing any particularly persuasive reason it even needs to be an FE
16:14:33 <frantisekz> hmm, yeah, It seems ok to expect somebody relying on whatrequires to have updated dnf
16:15:29 <cmurf> -1 blocker, -1 FE
16:15:33 <kparal> I can't really estimate the implications of such a bug
16:15:42 <kparal> we surely don't have a criterion for it
16:16:44 <pwhalen> -1 blocker
16:16:52 <frantisekz> hmm, worst case seems to be that some packager rebuilding library with dependencies will miss them and forget to rebuild them
16:17:02 <frantisekz> breaking Rawhide in the process :D
16:17:21 <lruzicka> so it can be a rawhide blocker then
16:17:26 <frantisekz> nope
16:17:41 <adamw> we're at -3 so far
16:17:44 <bcotton> -1 blocker
16:19:02 <lruzicka> I dont have an opinion here
16:19:24 <adamw> proposed #agreed 1812596 - RejectedBlocker (Final) - there is no indication that this breaks any of the release criteria, or any other justification for blocking release on this
16:19:31 <frantisekz> ack
16:19:50 <pwhalen> ack
16:20:12 <bcotton> ack
16:20:13 <kparal> ack
16:20:52 <adamw> #agreed 1812596 - RejectedBlocker (Final) - there is no indication that this breaks any of the release criteria, or any other justification for blocking release on this
16:20:59 <adamw> #topic (1816547) Firefox not using langpacks for localization
16:20:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1816547
16:20:59 <adamw> #info Proposed Blocker, firefox, NEW
16:23:04 <kparal> I didn't really know if that was the right criterion
16:23:08 <kparal> or if we have something better
16:23:25 <kparal> it feels like we should have a criterion for when the translations are available but don't get used
16:23:53 <frantisekz> hmm, I don't think Firefox falls under critpath/networking
16:24:06 <cmurf> I have this weird long standing bug where Firefox just flips from US English to Malawi
16:24:32 <kparal> cmurf: that happens to me often for grammar checking
16:24:47 <cmurf> is it grammar or spelling?
16:24:54 <kparal> spelling
16:25:00 <cmurf> i just checked this and it's flipped back to Malawi in the past two days
16:25:20 <frantisekz> anyhow, I'd say I am +0, unless we have better criterion and/or I am reading the proposed one wrong
16:25:22 <cmurf> i have no idea what triggers this; right now I can't even get the language selectino menu to draw, it flickers instead
16:26:01 <adamw> frantisekz: i mean, that was my initial reaction, but then...it is explicitly marked as critical path in comps
16:26:06 <bcotton> yeah, i'm +0 blocker, -1 FE
16:26:17 <adamw> there is a "critical-path-apps" group in comps with the description "A set of applications that are considered critical path"
16:26:21 <adamw> and firefox is in it
16:26:28 <adamw> so on that basis i'm kinda +1
16:26:45 <kparal> yes, but I my question was about "critical path actions"
16:26:46 <adamw> https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in#_657
16:26:51 <kparal> https://fedoraproject.org/wiki/Critical_path_package#Actions
16:27:17 <adamw> well
16:27:20 <kparal> I'm not sure why the criterion is written as it is
16:27:33 <adamw> my logic is, we clearly consider *something* in firefox part of the critical path
16:27:37 <adamw> and *none* of firefox is translated
16:27:38 <adamw> soo....
16:28:02 <adamw> kparal: it's written that way because there are some things that are part of critpath which do much more than just their critpath stuff
16:28:27 <kparal> I see
16:28:29 <pwhalen> +1, based on that logic
16:28:36 <kparal> so is networking the right action to pick here?
16:28:42 <kparal> because it seems nothing else applies
16:28:47 <adamw> kparal: i think so. it's been a while since this critpath stuff was, you know, 'touched'
16:28:53 <adamw> it's all a bit bitrotten
16:28:57 <lruzicka> I do not think a missing translation should be a blocker when the application works fine otherwise
16:29:01 <adamw> (note all the xorg-x11-drv packages in the gnome critpath definition)
16:29:13 <kparal> lruzicka: but you might not understand it
16:29:18 <adamw> lruzicka: missing translations aren't
16:29:31 <kparal> which is pretty severe for the only web browser in the system
16:29:38 <adamw> the criterion specifically is written that way
16:29:40 <adamw> it says "must correctly display all sufficiently complete translations available for use"
16:29:47 <adamw> i.e. *if* there is a translation available, it must be displayed
16:30:24 <cmurf> I'm a tentative +1 but I'd like to hear from the maintainer
16:30:25 <kparal> yes, this is against programming bugs, not missing translations
16:30:29 <cmurf> maybe punt and needinfo?
16:30:44 <kparal> I'm leaning towards +1 as well
16:30:46 <adamw> what info?
16:30:46 <lruzicka> where is it written, kparal's link does not show anything like that
16:30:55 <adamw> it seems pretty clearly broken, multiple people have reproduced
16:31:02 <kparal> lruzicka: https://bugzilla.redhat.com/show_bug.cgi?id=1816547#c8
16:32:52 <lruzicka> ok
16:33:01 <cmurf> did this ever work correctly? is it a regression?
16:33:20 <adamw> sure it did
16:33:23 <adamw> it says right in the bug
16:33:27 <adamw> it worked up until a recent build
16:33:33 <kparal> cmurf: https://bugzilla.redhat.com/show_bug.cgi?id=1816547#c5
16:33:48 <lruzicka> In F31, Firefox is translated into Czech, at least.
16:34:17 <cmurf> yeah i jus read that, seems to be a regression
16:34:53 <cmurf> 72 is a while ago
16:35:31 <cmurf> +1 blocker
16:35:42 <bcotton> okay, revising to +1 blocker
16:35:50 <lruzicka> +1 blocker, too
16:37:12 <adamw> proposed #agreed 1816547 - AcceptedBlocker (Final) - firefox is unambiguously marked critical path in comps, so this seems like it must violate "All critical path actions on release-blocking desktops must correctly display all sufficiently complete translations available for use."
16:37:54 <kparal> ack
16:38:18 <frantisekz> ack
16:38:33 <lruzicka> ack
16:38:42 <pwhalen> ack
16:38:58 <adamw> #agreed 1816547 - AcceptedBlocker (Final) - firefox is unambiguously marked critical path in comps, so this seems like it must violate "All critical path actions on release-blocking desktops must correctly display all sufficiently complete translations available for use."
16:38:59 <cmurf> ack
16:39:02 <adamw> #topic (1813515) [abrt] gnome-shell: cogl_matrix_stack_pop(): gnome-shell killed by SIGSEGV
16:39:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1813515
16:39:02 <adamw> #info Proposed Blocker, gnome-shell, POST
16:39:08 <adamw> oh goody, gnome-shell crashes, i love these
16:39:17 <cmurf> me 3
16:39:56 <cmurf> i'm tentatively +1 blocker even though i haven't hit it recently
16:40:48 <lruzicka> I even was not able to reproduce it on the same machine, so I am not sure.
16:41:10 <lruzicka> oh, I was,
16:41:11 <cmurf> crashes of the shell cause data loss, the user has no chance
16:41:36 <kparal> lruzicka: you just reproduced the issue?
16:42:06 <adamw> cmurf: yeah, we've historically had a strong tendency to accept known shell crashes because of this
16:42:10 <lruzicka> no, that is a different bug
16:42:15 * adamw wonders what became of that whole wrapper thing desktop team keeps promising
16:42:19 <lruzicka> sorry, I looked into a wrong window
16:42:30 <cmurf> wrapper?
16:42:47 <kparal> this bug has a lot of duplicates
16:43:04 <adamw> cmurf: there's this idea that they'll run the shell in some sort of simple wrapper process that shouldn't crash
16:43:08 <kparal> FAF says 935 unique crashes
16:43:13 <adamw> so shell crashes don't nerf the session any more
16:43:21 <cmurf> the other annoying this is that this crash could not be processed by the retrace server, i had to do it locally
16:43:24 <adamw> but i dunno if it's still a thing
16:43:47 <kparal> due to the number of people hitting this, I'm leaning towards +1
16:44:19 <adamw> yeah, me too
16:44:21 <pwhalen> +1, agree with kparal
16:44:26 <frantisekz> +1
16:44:27 <adamw> btw, has anyone else seen https://gitlab.gnome.org/GNOME/gjs/issues/294 ?
16:44:36 <adamw> openqa runs into that one relatively often
16:44:53 <adamw> though it does tend to be right at the start of a session so not a data loss candidate most likely
16:45:26 <kparal> I know you won't believe me, but I haven't seen a single shell crash on F32
16:45:34 <bcotton> +1 blocker
16:45:40 <kparal> I wonder if crashes only happen on wayland
16:46:08 <adamw> proposed #agreed 1813515 - AcceptedBlocker (Final) - accepted as a conditional violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" with reference also to "All known bugs that can cause corruption of user data must be fixed or documented at Common F32 bugs" (as Shell crashes can often cause data loss)
16:46:19 <coremodule> ack
16:46:22 <kparal> ack
16:46:24 <lruzicka> ack
16:46:25 <pwhalen> ack
16:46:28 <frantisekz> ack
16:46:37 <adamw> .fire kparal if things don't crash for you all the time what are you even good for
16:46:37 <zodbot> adamw fires kparal if things don't crash for you all the time what are you even good for
16:46:44 <adamw> #agreed 1813515 - AcceptedBlocker (Final) - accepted as a conditional violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" with reference also to "All known bugs that can cause corruption of user data must be fixed or documented at Common F32 bugs" (as Shell crashes can often cause data loss)
16:46:57 <adamw> #topic (1817082) gnome-shell: SIGSEGV when locking screen
16:46:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1817082
16:46:57 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:47:05 <adamw> oh hey look another one
16:47:10 <cmurf> haha
16:47:57 <cmurf> i haven't run into it, but basically the same logic
16:48:25 <lruzicka> So, this is the one. I have tried to reproduce it on the same machine, P50, it worked normally.
16:48:27 <adamw> depends how common it is i guess
16:48:41 <cmurf> yeah
16:48:44 <cmurf> this is hybrid graphics
16:49:03 <lruzicka> The laptop has two graphical cards, it worked on Nvidia only, and also on Nvidia+Intel
16:49:14 <cmurf> it'd be nice if someone who knows how to read the stack trace info attached, whether it could be related to hybrid graphics
16:49:15 <adamw> let's rename this the Stephen Needs A New Laptop bug
16:49:17 <cmurf> could be transient
16:49:26 <lruzicka> I was able to lock and unlock for at least 20 times consequently.
16:50:30 <frantisekz> hmm, weren't there any AVX2 erratums in Intel CPUs? new microcode/BIOS might fix that?
16:50:53 <frantisekz> on the other hand, Fedora should be using latest microcode on Intel, so... I don't know
16:51:19 <cmurf> FAF reports 1 unique report
16:51:47 * kparal votes for adamw's proposal
16:52:08 <frantisekz> -1 then
16:52:27 <kparal> until more people can reproduce it, -1
16:52:27 <adamw> also can't find any other report like this on upstream gitlab
16:52:30 <adamw> so yeah, -1 for me too
16:52:30 <pwhalen> -1 blocker, unless someone can reproduce it doesnt look to affact man people
16:52:39 <pwhalen> *many
16:52:45 <coremodule> -1 blocker
16:52:49 <adamw> sgallagh: also you can't sit with us at lunch
16:52:56 <lruzicka> -1 blocker
16:53:30 <lruzicka> but I would like to see Stephen to try without the external monitors and stuff - because I did not have it so I could not test that
16:53:41 <adamw> proposed #agreed 1817082 - RejectedBlocker (Final) - so far this seems somehow unique to sgallagh, others with same and similar laptops cannot reproduce it and we can find no indication anyone else has hit it in FAF or upstream gitlab
16:53:47 <bcotton> ack
16:53:50 <frantisekz> ack
16:53:53 <pwhalen> ack
16:53:54 <lruzicka> ack
16:53:59 <sgallagh> I’ll try to look into that when I’m not recovering from throwing my back out.
16:54:04 <kparal> ack
16:54:15 <lruzicka> sgallagh, ooo get better soon
16:54:24 <sgallagh> Thanks
16:55:26 <adamw> sgallagh: do re-propose if we can nail down the reproduction better and it seems significant enough
16:55:30 <adamw> #agreed 1817082 - RejectedBlocker (Final) - so far this seems somehow unique to sgallagh, others with same and similar laptops cannot reproduce it and we can find no indication anyone else has hit it in FAF or upstream gitlab
16:55:41 <adamw> #topic (1816761) in Wayland VM text is selected from line above pointer
16:55:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1816761
16:55:41 <adamw> #info Proposed Blocker, mutter, NEW
16:56:55 <kparal> so how well must mouse cursor work? :)
16:57:13 <adamw> is this the one that's just like a 1-pixel discrepancy? or the bigger one?
16:57:17 <adamw> iirc there were two...
16:57:41 <lruzicka> he says "one line"
16:57:52 <lruzicka> that is pretty much, I believe
16:58:03 <adamw> this is the bigger one i think
16:58:08 <kparal> when I try to resize a window, I have the cursor shifted 1-2 cursors width to the right
16:58:31 <kparal> it's definitely noticeable and inconvenient
16:58:38 <Southern_Gentlem> wayland VM in what
16:58:58 <kparal> F32 host and guest here
16:59:15 <adamw> https://gitlab.gnome.org/GNOME/mutter/-/issues/1094 has more detail on the issue
16:59:42 <adamw> i think i'm +1 on this one
16:59:55 <frantisekz> +1
16:59:58 <lruzicka> +1
17:00:06 <pwhalen> +1
17:00:06 <Southern_Gentlem> +1
17:00:25 <adamw> i *believe* it's a guest-side issue, from reading the upstream bug, also
17:00:32 <adamw> which means we can't fix it for lives with a post-release update
17:00:41 <kparal> you can see it here: blob:https://imgur.com/05ce0787-35d1-485a-a347-f89aa5095e05
17:00:53 <kparal> sigh
17:00:53 <adamw> yeah, that one's a good illustration
17:01:08 <kparal> https://i.imgur.com/hUOIFso.png
17:01:27 <kparal> it's pretty hard to find a spot where you can resize the window
17:01:31 <kparal> *the spot
17:01:34 <adamw> proposed #agreed 1816761 - AcceptedBlocker (Final) - accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and other desktop criteria when running in a VM using 'seamless mouse pointer' mode (which virt-manager and Boxes use by default)
17:01:56 <cmurf> ack
17:01:57 <pwhalen> ack
17:02:06 <Southern_Gentlem> ack
17:02:08 <lruzicka> ack
17:02:13 <kparal> ack
17:02:20 <frantisekz> ack
17:03:36 <adamw> #agreed 1816761 - AcceptedBlocker (Final) - accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and other desktop criteria when running in a VM using 'seamless mouse pointer' mode (which virt-manager and Boxes use by default)
17:03:45 <adamw> #topic (1817708) The desktop session will not start.
17:03:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1817708
17:03:45 <adamw> #info Proposed Blocker, plasma-desktop, NEW
17:05:38 <adamw> so...it's working now?
17:06:07 <lruzicka> so, it was working today with 20200328
17:06:08 <cmurf> good question
17:06:16 <cmurf> if not +1 blocker
17:07:08 <lruzicka> so, I might be -1 today
17:08:17 <adamw> i guess i'm kinda punt-y?
17:08:24 <lruzicka> When I saw this for the first time, it was in a VM, today I wanted to retest on bare metal, so I picked the latest compose on nightlies and realized it worked ok, so retested in VMs, both uefi and bios -> works
17:08:27 <adamw> might be nice to try with other composes and have other people try
17:08:36 <lruzicka> ok, punt is fine with me
17:09:04 <pwhalen> +1 punt
17:09:10 <Southern_Gentlem> +1p
17:09:13 <frantisekz> +1 punt
17:09:14 <lruzicka> +1 punt
17:11:09 <adamw> proposed #agreed 1817708 - punt (delay decision) - it would be good to have a few more folks try this out on different systems to confirm whether it's gone away
17:11:14 <coremodule> ack
17:11:16 <frantisekz> ack
17:11:20 <Southern_Gentlem> ack
17:11:26 <adamw> rdieter: did you have any thoguhts on this one?
17:11:35 <adamw> sorry, just realized we should ping :)
17:11:40 <pwhalen> ack
17:12:53 <lruzicka> ack
17:13:26 <adamw> just giving rdieter a bit of time
17:13:32 * adamw plays hold muzak
17:15:54 <adamw> okay, let's move on
17:15:57 <adamw> #agreed 1817708 - punt (delay decision) - it would be good to have a few more folks try this out on different systems to confirm whether it's gone away
17:16:16 <adamw> #topic Proposed Final freeze exceptions
17:16:21 <adamw> #info that was all the proposed blockers
17:16:48 <adamw> #info we already accepted 1816547 and 1816761 as blockers, so we'll skip those
17:16:53 <adamw> #topic (1814872) Lenovo T450s Touchpad barely works
17:16:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1814872
17:16:54 <adamw> #info Proposed Freeze Exceptions, kernel, NEW
17:17:07 <bcotton> +1 fe
17:17:38 <adamw> seems like a natural fe candidate
17:17:42 <frantisekz> +1 FE
17:17:45 <Southern_Gentlem> +1 fe
17:17:47 <pwhalen> +1 fe
17:17:49 <adamw> can't fix for lives with an update, and even for installs, it makes the initial install difficult
17:17:51 <adamw> +1
17:18:07 <Southern_Gentlem> i will take care of that
17:18:18 <lruzicka> +1 fe
17:19:20 <adamw> proposed #agreed 1814872 - AcceptedFreezeException (Final) - this is a significant bug that makes use of a live image difficult on affected systems
17:19:26 <adamw> patch
17:19:44 <adamw> proposed #agreed 1814872 - AcceptedFreezeException (Final) - this is a significant bug that makes use of a live image and initial installation difficult on affected systems, and those situations cannot be fixed with an update
17:20:00 <Southern_Gentlem> ack
17:20:04 <pwhalen> ack
17:20:57 <Southern_Gentlem> well can be fixed by updated isos
17:21:07 <lruzicka> ack
17:21:53 <frantisekz> ack
17:21:59 <kparal> ack
17:22:03 <adamw> #agreed 1814872 - AcceptedFreezeException (Final) - this is a significant bug that makes use of a live image and initial installation difficult on affected systems, and those situations cannot be fixed with an update
17:22:34 <adamw> #topic Accepted Final blockers
17:22:41 <adamw> #info that's all the proposals, let's check in briefly on accepted bugs
17:22:48 <adamw> #topic (1768206) DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories despite "rpm --import"-ing the keys first
17:22:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1768206
17:22:48 <adamw> #info Accepted Blocker, dnf, NEW
17:24:04 <frantisekz> need to run, thanks for the meeting, see you all next monday
17:25:28 <lruzicka> frantisekz, bye
17:26:58 <adamw> so, there seems to be a bit of confusion on dnf team's part here
17:27:01 <adamw> i'm adding a comment to try and clarify
17:27:11 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1768206#c18
17:27:14 <adamw> not sure we can do much more here
17:29:05 <cmurf> comment 14 concerns me
17:29:24 <adamw> that's the "confusion" i was referring tio
17:30:19 <adamw> #info there seem to be some perspective differences here, we have added a comment trying to clarify current state and requirements
17:32:25 <adamw> #topic (1815463) It's impossible to create another user account through KDE System Settings
17:32:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1815463
17:32:26 <adamw> #info Accepted Blocker, plasma-user-manager, NEW
17:32:29 <adamw> this one seems slightly confused also
17:32:43 <adamw> it magically went away? somewhere else than where rex thought it would?
17:32:50 <adamw> i guess we should needinfo frantisek to re-test
17:34:52 <lruzicka> I have tested it with 20200328 and I am able to create extra users using this any time
17:35:13 <lruzicka> if you start Users, it works, if you follow the reproducer in the bug, it works, too
17:35:31 <lruzicka> tested in a VM and bare metal
17:35:56 <adamw> did you test that you could reproduce the *problem* with an older build, though?
17:36:31 <lruzicka> give me 2 mins
17:36:42 <adamw> when i'm trying to reproduce something i like to make sure i can actually reproduce the bug, before i try and reproduce the fix :)
17:37:19 <lruzicka> yes, but I did not tried the fix
17:38:18 <Southern_Gentlem> yes you did you used 20200328 where they used 20200325
17:38:19 <lruzicka> I have been trying to create users for Desktop Login OpenQA test for the whole week and it went ok with 20200322, and now I tried 20200
17:38:24 <lruzicka> 20200328
17:38:52 <lruzicka> but the proposed fix is not a part of 28 yet
17:40:31 <lruzicka> the plasma systemsettings has the same version
17:40:37 <lruzicka> in both of the composees
17:41:22 <adamw> other things may have changed, though
17:41:29 <adamw> anyhow
17:41:41 <adamw> let's ask frantisek to test, as he knows for sure how he triggered the bug, and what with
17:41:59 <adamw> #info it is not clear if this bug has been resolved for sure, we will ask frantisek to re-test and give his current experience
17:42:35 <coremodule> ls -la
17:44:43 <adamw> embarrassingporn.mp4
17:44:53 <adamw> #topic Open floor
17:45:11 <adamw> that's everything, I believe
17:45:13 <adamw> any other business, folks?
17:45:35 <lruzicka> Well, one more question.
17:46:04 <lruzicka> How could have frantisekz used the 20200325 compose when the bug was created on 20200320 ?
17:47:17 <lruzicka> and I am sure I did not hit the bug in 20200322 nor 20200328. That is all I wanted to say.
17:50:43 <adamw> that's why we should ask him :)
17:53:08 <adamw> i needinfo'ed him
17:53:20 <lruzicka> Yeah, I've seen it.
17:53:56 <Southern_Gentlem> adamw, which him rdieter or frantisekz
17:54:05 <adamw> frantisekz
17:56:44 <adamw> okay, sounds like we're done!
17:56:47 <adamw> thanks for coming out, folks
17:58:20 <kparal> thanks adamw
17:59:02 <adamw> didn't I fire you
17:59:50 <lruzicka> thanks everybody, take care and stay healthy
18:00:30 <adamw> #endmeeting