16:09:55 <adamw> #startmeeting F36-blocker-review
16:09:55 <zodbot> Meeting started Tue Apr 19 16:09:55 2022 UTC.
16:09:55 <zodbot> This meeting is logged and archived in a public location.
16:09:55 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:09:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:09:55 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:09:55 <adamw> #meetingname F36-blocker-review
16:09:56 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:09:56 <adamw> #topic Roll Call
16:10:07 <adamw> morning folks, sorry for the late start, who's around for blocker fun?
16:10:14 * pwhalen is here
16:10:39 * coremodule is here, willing to act as secretary.
16:11:01 * lruzicka is here, too
16:11:22 <adamw> give me a few mins to run through the ticket votes
16:12:08 * kparal half lurks half AFK
16:12:53 <OnuralpSezer[m]> * onuralp is listening too
16:12:59 <OnuralpSezer[m]> * * onuralp is listening too
16:13:06 <OnuralpSezer[m]> *  * onuralp
16:13:14 * NishantMishra[m] is here
16:13:34 <NishantMishra[m]> adamw: hello
16:13:46 * Eighth_Doctor is sort of here
16:13:58 <NishantMishra[m]> is there any audio room for this meeting?
16:14:38 <Eighth_Doctor> no, this is a text meeting
16:14:42 <NishantMishra[m]> ok
16:15:48 <adamw> yup, we're old-fashioned :D
16:15:58 <adamw> sorry, still doing votes
16:18:18 <adamw> okay, uh
16:18:24 <adamw> #chair pwhalen coremodule
16:18:24 <zodbot> Current chairs: adamw coremodule pwhalen
16:18:27 <adamw> boilerplate alert
16:19:18 <adamw> #topic Introduction
16:19:20 <adamw> Why are we here?
16:19:24 <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:19:27 <adamw> #info We'll be following the process outlined at:
16:19:30 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:19:33 <adamw> #info The bugs up for review today are available at:
16:19:37 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:19:40 <adamw> #info The criteria for release blocking bugs can be found at:
16:19:44 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:19:47 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
16:19:49 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
16:20:22 * nirik hangs out in the cheap seats in the back
16:21:20 <adamw> sorry, just getting updated bug counts
16:21:36 <adamw> we really need to write fedmsg integration for blockerbugs, sigh
16:22:15 <adamw> #info 4 Proposed Blockers
16:22:18 <adamw> #undo
16:22:18 <zodbot> Removing item from minutes: INFO by adamw at 16:22:15 : 4 Proposed Blockers
16:22:25 <adamw> #info For Final, we have:
16:22:26 <adamw> #info 4 Proposed Blockers
16:23:15 <adamw> #info 10 Accepted Blockers
16:23:29 <adamw> #info 5 Proposed Freeze Exceptions
16:23:33 <adamw> #info 12 Accepted Freeze Exceptions
16:23:47 <lruzicka> I am seeing totally different numbers. Why?
16:24:04 <lruzicka> 7 proposed, 9 accepted, 8 prop fe ...
16:24:08 <adamw> lruzicka: because i just accepted a bunch
16:24:13 <lruzicka> oh, ok
16:24:27 <adamw> the prod blockerbugs is only updated every half hour, so it's behind
16:24:34 <adamw> i want to write fedmsg integration to fix this, but roundtuits...
16:24:47 * nirik could poke it, but it should run in 6min also
16:25:06 <adamw> i'm using a local instance
16:25:28 <adamw> #info coremodule will secretarialize
16:25:32 <adamw> let's get started with:
16:25:36 <adamw> #topic Proposed Final Blockers
16:25:49 <adamw> #topic (2076364) [abrt] gjs: g_main_context_iterate.constprop.0(): gjs-console killed by SIGSEGV
16:25:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2076364
16:25:58 <adamw> #info Proposed Blocker, gjs, NEW
16:27:11 <adamw> i think i'm -1 blocker on a crash-on-exit
16:27:15 <adamw> if it doesn't actually break anything
16:27:23 <adamw> iirc that's been past convention
16:27:29 <nirik> yeah, -1 blocker
16:28:07 <coremodule> -1 blocker
16:29:00 <lruzicka> -1
16:29:08 <pwhalen> -1 blocker
16:29:27 <adamw> in the bug, bcotton and kparal are +1
16:30:05 <adamw> nielsenb, lruzicka and frantisekz are -1
16:30:16 <adamw> so adding me, nirik, coremodule and pwhalen we're at -7 / +2
16:31:10 <adamw> proposed #agreed 2076364 - RejectedBlocker (Final) - a crash on exit does not seem serious enough to count as violating the "basic functionality" requirement; this is consistent with past decisions. Note, bug is already accepted as a freeze exception issue
16:32:11 <coremodule> ack
16:32:25 <nirik> ack
16:32:28 <pwhalen> ack
16:33:08 <lruzicka> ack
16:34:27 <adamw> #agreed 2076364 - RejectedBlocker (Final) - a crash on exit does not seem serious enough to count as violating the "basic functionality" requirement; this is consistent with past decisions. Note, bug is already accepted as a freeze exception issue
16:34:29 <adamw> sorry, multitasking :)
16:35:31 <adamw> #topic (2076596) The KDE ibus panel does not work as expected.
16:35:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2076596
16:35:43 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/766
16:35:45 <adamw> #info Proposed Blocker, ibus, NEW
16:35:46 <adamw> #info Ticket vote: FinalBlocker (+3,0,-0) (+kparal, +frantisekz, +lruzicka)
16:36:25 <adamw> oh, looks like this just got votes in the ticket recently
16:36:39 <adamw> so we have +3, does anyone disagree? it does seem a reasonable blocker to me
16:36:54 <coremodule> yeah, I'm +1 blocker too
16:37:03 <nirik> yeah, sadly looks blockery
16:37:20 <adamw> we should probably amend the final criteria to specifically require this to work, really
16:37:36 <pwhalen> +1 blocker
16:37:41 <adamw> there are enough countries where switching is required that it just makes sense
16:38:48 * sgallagh turns up
16:39:33 <adamw> proposed #agreed 2076596 - AcceptedBlocker (Final) - this is 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"; we also note it violates the spirit of the "keyboard layout configuration" criterion, which should be updated to require that switching work for default-switched configurations
16:39:49 <lruzicka> ack
16:39:54 <coremodule> ack
16:41:07 <Southern_Gentlem> ack
16:41:34 <adamw> #agreed 2076596 - AcceptedBlocker (Final) - this is 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"; we also note it violates the spirit of the "keyboard layout configuration" criterion, which should be updated to require that switching work for default-switched configurations
16:41:54 <adamw> #topic (2075989) libyui-mga-qt doesn't require libyui-qt
16:41:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2075989
16:42:01 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/760
16:42:03 <adamw> #info Proposed Blocker, libyui-mga-qt, MODIFIED
16:42:07 <adamw> #info Ticket vote: FinalBlocker (+5,0,-1) (+geraldosimiao, +bcotton, +nielsenb, +ngompa, +frantisekz, -kparal)
16:42:45 <adamw> so there's +4 in the ticket here, but there seemed to be a bit of a debate about what the 'default' package manager should be taken to mean in the ticket, so i figured we could discuss it
16:45:23 <adamw> it does seem a bit of a grey area. silly me thinking that desktops would be okay with just *one* "default package manager".
16:45:38 <nirik> default should mean one right?
16:45:54 <adamw> i think for consistency within F36 we should be +1 here, but it would be a good idea for F37 to think about clarifying that wording in the package management criteria
16:46:16 <adamw> nirik: when i wrote that, there was just dnf, and one graphical app in KDE and one in GNOME
16:46:17 <adamw> simple times!
16:46:27 <adamw> now there are, uh,...complications
16:46:55 <adamw> apart from KDE having two graphical software apps, we have to think about where flatpak / rpm-ostree and stuff fit in
16:47:07 <lruzicka> I do not see what a problem is. on latest compose dnfdragora starts and can be used. If some backends are not chosen correctly, that's cosmetics.
16:47:19 <adamw> #action adamw to reconsider the "default application" wording in the package management criteria for Modern Times
16:47:36 <adamw> lruzicka: yeah, that bit does seem a bit fuzzed over too - what exactly the practical effect is
16:47:55 <adamw> the bug report says "It makes difficulties on GUI so, Users had hard time to install package because of the inconsistent UI backend selection"
16:47:57 <adamw> which seems a bit vague
16:47:59 * nirik nods would be good to know
16:48:17 <geraldosimiao> .hello geraldosimiao
16:48:18 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:48:29 <geraldosimiao> 😬
16:48:41 <lruzicka> I also believe that Discover is similar to Software, it only handles graphical applications, where dnfdragora is able to handle everything.
16:49:06 <lruzicka> and that's entirely missing from WS and nobody cares
16:49:33 <adamw> well, it's not that nobody cares
16:49:36 <adamw> for WS it's intentional
16:49:45 <lruzicka> because if you need specific packages on CLI, you probably know how to handle DNF
16:50:01 <lruzicka> adamw, yeah I mean "nobody in the audience cares"
16:50:04 <adamw> GNOME wants the default graphical app to display only certain things. they do not want things that aren't in software graphically available by default.
16:50:09 <adamw> ah
16:50:33 <adamw> for KDE the opposite is true, though. they specifically include both for this reason. at least atm, though there was talk about dropping dnfdragora for being too much trouble
16:51:01 <adamw> anyhow...i guess we can punt on the basis of lack of information and then it'll get fixed as an FE
16:51:38 <coremodule> +1 punt
16:51:49 <nirik> +1 punt and find out more
16:51:50 <lruzicka> -1 blocker
16:52:25 <lruzicka> imo, it does not break any of the criteria because it is not said which UI it should use
16:52:27 <adamw> i'm +1 punt
16:52:31 <pwhalen> +1 punt
16:52:42 <geraldosimiao> +1 punt
16:53:43 <lruzicka> also, I do not understand what happens now ... are we slipping? if we do not know whether this is blocking or not?
16:54:14 <adamw> proposed #agreed 2075989 - punt (delay decision) - it's not clear whether this is a blocker because there is not enough detailed information on the practical consequences of the wrong backend being used; the description is too vague. We will delay the decision on blocker status, though in practice this means the fix will be pushed as FE and we likely won't need to consider it further
16:54:31 <nirik> ack
16:54:35 <adamw> lruzicka: we're almost certainly slipping for other reasons, plus this is accepted as FE already so it's going in
16:54:48 <coremodule> ack
16:55:03 <lruzicka> because if this would be the "last one standing" I will gladly send it out of the coral
16:55:35 <adamw> nah, we're not at 'last bug standing' time unfortunately :(
16:55:57 <geraldosimiao> <lruzicka> "I do not see what a problem is..." <- It's not cosmetic. Without it one cannot use correctly dnfdragora on hd resolutions
16:56:28 <lruzicka> geraldosimiao, what does it mean? the window is just small or too small? or too big?
16:56:37 <lruzicka> geraldosimiao, does it fit on the screen?
16:56:55 <geraldosimiao> adamw: Sorry for being late, but I can explain the practical effects
16:57:01 <lruzicka> please do
16:58:38 <geraldosimiao> I opened a ticket explaining that, let's find here
16:59:32 <geraldosimiao> https://bugzilla.redhat.com/show_bug.cgi?id=2075976
16:59:48 <geraldosimiao> Window too small, one cannot see the last line
17:00:17 <geraldosimiao> Just the place where the buttons "apply" stand
17:00:53 <Eighth_Doctor> basicaly, the probably is when you're less than 1080p, GTK padding makes the window blow out of the screen
17:00:57 <Eighth_Doctor> *problem
17:01:12 <geraldosimiao> Yeah
17:01:22 <Eighth_Doctor> so 1280x720 and 1366x768 is unusuable with GTK
17:01:23 <adamw> oh, yeah, i think i actually saw that problem at low resolution in a vm, heh
17:01:33 <adamw> ok, on that basis i'm +1
17:01:44 <OnuralpSezer[m]> adamw: Yes, we fixed by adding qt package
17:01:52 <OnuralpSezer[m]> Yesterday
17:01:57 <Eighth_Doctor> we have this problem with gnome-abrt because GTK has terrible mandatory padding
17:02:16 <geraldosimiao> Yes, same case
17:02:18 <OnuralpSezer[m]> Is abrt has qt ui or just gtk ?
17:02:29 <Eighth_Doctor> nobody has written a Qt UI for ABRT
17:02:34 <Eighth_Doctor> so we're stuck with GNOME ABRT
17:02:35 <lruzicka> So, if it affects usability that much, let's +1 Final Blocker
17:02:54 <Eighth_Doctor> lruzicka: you can't hit the apply/cancel buttons at lower resolutions :(
17:02:57 <Eighth_Doctor> it's pretty bad
17:02:59 <geraldosimiao> But with abrt one can move the window
17:03:01 <adamw> new proposal then
17:03:12 <geraldosimiao> And find the button
17:04:19 <adamw> proposed #agreed 2075989 - AcceptedBlocker (Final) - this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type" for dnfdragora in KDE at lower vertical resolutions
17:04:50 <lruzicka> ack
17:04:58 <geraldosimiao> Ack
17:05:49 <Eighth_Doctor> ack
17:06:24 <adamw> #agreed 2075989 - AcceptedBlocker (Final) - this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type" for dnfdragora in KDE at lower vertical resolutions
17:06:25 <OnuralpSezer[m]> Ack
17:06:35 <adamw> #topic (2074789) Basic graphics mode broken for X11 with Nvidia GPU and UEFI
17:06:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2074789
17:06:43 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/749
17:06:46 <adamw> #info Proposed Blocker, xorg-x11-server, POST
17:06:49 <adamw> #info Ticket vote: FinalBlocker (+0,0,-5) (-lruzicka, -geraldosimiao, -kparal, -bcotton, -frantisekz)
17:06:52 <adamw> #info Ticket vote: FinalFreezeException (+6,0,-0) (+asciiwolf, +geraldosimiao, +nielsenb, +kparal, +bcotton, +frantisekz)
17:07:09 <adamw> so this has -5, but i did want to bring it up because to me it does seem to have a solid argument
17:07:43 <adamw> as i read it, the case in the bug is exactly the case where we need 'basic graphics mode' to work - nouveau does not work on the user's adapter
17:07:48 <adamw> so if basic graphics mode doesn't work either, they're stuck
17:08:23 <adamw> and the nature of the bug kinda suggests this pattern may repeat - this isn't going to affect everyone, but i wouldn't be surprised if other hardware that's affected is also hardware that does not work in 'default' graphics mode
17:09:37 <Eighth_Doctor> yeah, I encountered similar issues before with other nvidia things
17:09:59 <Eighth_Doctor> I wish we could get firmware blobs for older NVIDIA cards so nouveau worked properly...
17:10:01 <adamw> see comments #18 and #19
17:10:24 <OnuralpSezer[m]> Eighth_Doctor: And quadro series too
17:10:55 <adamw> kparal: might you reconsider your -1 blocker in light of the "situation change" as you put it? or are you still -1?
17:10:55 <NishantMishra[m]> adamw: it works for me
17:10:56 <NishantMishra[m]> +1
17:11:14 * kparal looks up
17:11:36 <NishantMishra[m]> Nvidia GTX 1650 and Acer Aspire 7 UEFI
17:11:55 <kparal> adamw: I'm fine with anything here, really
17:11:56 * kparal afk
17:12:10 <NishantMishra[m]> can somebody explain the issue once again if thats possible
17:12:59 <Southern_Gentlem> to me this is commonbugs issue
17:13:00 <lruzicka> NishantMishra[m], when a user has got an Nvidia card which is not supported by the Nouveau driver, they might arrive into an issue where they will not be able to install Fedora in the graphical regime
17:13:03 <NishantMishra[m]> basic graphics as in Black Screen while booting?
17:13:38 <adamw> Nishant Mishra: "basic graphics" is a choice on the boot menu for fedora installers and live images
17:13:38 <NishantMishra[m]> I do use live images but have never come across basci graphics
17:13:45 <lruzicka> NishantMishra[m], no, basic graphics as in --nomodeset kernel parameter which spins out the basic resolution, usually 1024x768
17:13:53 <NishantMishra[m]> s/basci/basic/
17:14:05 <adamw> it tries to boot using a sort of fallback graphical path. it's intended for cases where attempting to boot with normal graphics drivers fails because the driver doesn't work on the hardware or something
17:14:22 <Eighth_Doctor> looks like a fix has been proposed for it: https://src.fedoraproject.org/rpms/xorg-x11-drv-vesa/pull-request/1
17:14:29 <geraldosimiao> If the ability to make a graphic installation is a Bleecker, so this must be too.
17:14:33 <geraldosimiao> *blocker
17:14:34 <NishantMishra[m]> lruzicka: for me it gives me 1920x1080 on my Acer Aspire
17:14:38 * bcotton is here now, catching up on this bug's discussion
17:14:44 <lruzicka> this might be worked around using the text installation and then using the proprietary drivers, but it is nothing an inexperienced user would be able to do
17:14:45 <geraldosimiao> So I'm prone to change my vote
17:14:55 <NishantMishra[m]> Ben Cotton (he/him): Hello Ben
17:14:56 <lruzicka> NishantMishra[m], because it seems that Nouveau drivers work for your card
17:15:21 <NishantMishra[m]> lruzicka: I have to enter Nouveau.modeset=0 though
17:15:25 <geraldosimiao> lruzicka: And it's acceptable by the blocking standards?
17:15:34 <geraldosimiao> A text instalation?
17:16:19 <lruzicka> geraldosimiao, oh ... not on WS. I forgot about this option only being possible on netinst
17:16:25 <Eighth_Doctor> we're going to have to be mindful that the vesa driver is going away in F37
17:16:48 <geraldosimiao> Oh, and that's too
17:17:05 <Eighth_Doctor> we need to rethink how basic graphics is going to work for F37+
17:17:10 <lruzicka> geraldosimiao, but sort of ... if you know how to make it happen, you could install WS from netints
17:17:36 <adamw> Conan Kudo: that seems out of scope :D
17:17:51 <adamw> so, i think i'm a light +1 on this
17:17:57 <Eighth_Doctor> same
17:17:57 <Eighth_Doctor> +1
17:18:04 <Eighth_Doctor> there's also a PR with a fix, so I'm reasonably okay here
17:18:14 <lruzicka> all right then
17:18:28 <lruzicka> +1
17:18:32 <Eighth_Doctor> if need be, I can roll up my sleeves and ship the fix since the developer isn't able to yet
17:18:44 <geraldosimiao> +1
17:18:48 <adamw> i can do that, it's not a problem.
17:18:53 <Eighth_Doctor> 👍️
17:18:59 <Eighth_Doctor> it's probably better you do it
17:19:09 <Eighth_Doctor> one less person screaming at me this week :)
17:19:15 <NishantMishra[m]> i can help Conan
17:19:16 <bcotton> yeah, i think i'm a +1 on this one nwo
17:19:54 <OnuralpSezer[m]1> +1
17:19:55 <adamw> okay, so we're at, uh, +5, -2 now. if i'm counting right
17:20:00 <adamw> +6/-2
17:20:18 <adamw> or maybe +6/-1 if we count kparal as 0 now
17:20:27 <adamw> frantisekz is the only remaining -1 i think
17:20:31 <adamw> (and that's from the ticket before this discussion)
17:20:44 <NishantMishra[m]> so 6-1 in favour of punt?
17:20:52 <adamw> in favor of accepting
17:20:56 <lruzicka> NishantMishra[m], blocker
17:21:10 <NishantMishra[m]> ok
17:22:26 <adamw> proposed #agreed 2074789 - AcceptedBlocker (Final) - this is accepted as a violation of "The generic video driver option...must function as intended...there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on...wide classes of hardware", affecting all cases where the UEFI simpledrm driver may kick in
17:22:39 <lruzicka> ack
17:22:43 <bcotton> ack
17:23:32 <Eighth_Doctor> ack
17:24:05 <geraldosimiao> ack
17:24:08 <adamw> #agreed 2074789 - AcceptedBlocker (Final) - this is accepted as a violation of "The generic video driver option...must function as intended...there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on...wide classes of hardware", affecting all cases where the UEFI simpledrm driver may kick in
17:25:13 <adamw> ok, that's all the proposed blockers
17:26:53 <adamw> #info there are no outstanding proposed FEs, so let's move on to a review of:
17:27:00 <adamw> #topic Accepted Blockers
17:27:17 <adamw> as a reminder, we're not voting on these, unless we decide there's a reason to reconsider their status - we're just checking on on progress
17:27:54 <adamw> #topic (2070764) selinux-policy is preventing flatpak from updating / installing  / removing flatpaks
17:27:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2070764
17:28:00 <adamw> #info Accepted Blocker, container-selinux, ON_QA
17:28:20 <adamw> so i'm a bit concerned about this. it's marked ON_QA and there's an update in stable, but latest comments seem to suggest there is still a problem here
17:28:25 <adamw> kpar
17:28:27 <adamw> grr
17:28:33 <adamw> kparal: is there a tl;dr for this?
17:29:00 * kparal looks up
17:29:16 <kparal> tldr: it's a big mess
17:30:13 <adamw> okay :D
17:30:15 <kparal> my system is affected, and the updates there only seem to be for F35 fixing the upgrade
17:30:35 <kparal> Zdenek didn't reply to my question how are we going to fix affected F36 users
17:30:41 <adamw> so the idea is that if you upgrade, now, from a fully-updated f35 to current f36, the bug won't happen?
17:31:08 <kparal> that's the idea. It has a few flaws, of course.
17:31:15 <NishantMishra[m]> i dont know why but this works fine for me
17:31:27 <kparal> for example gnome-software doesn't push users to updating before upgrading
17:31:32 <kparal> we had a fiery debate with rhughes over this a long time ago
17:32:14 <NishantMishra[m]> how does this affect your system ? kparal
17:32:33 <kparal> I can't run flatpak update
17:32:41 <kparal> it prints the errors as in comment 0
17:32:45 <NishantMishra[m]> hmm okay
17:33:43 <NishantMishra[m]> indeed a blocker
17:35:01 <NishantMishra[m]> will the release be delayed beyond 26th ? if we still have blocker bugs?
17:35:16 <adamw> Nishant Mishra: more or less, yes
17:35:30 <NishantMishra[m]> oh ok I am new to all this so I asked
17:35:41 <adamw> kparal: as far as the criteria go, though, if that's true, this should be resolved as a blocker, because that's what the criteria require
17:36:09 <adamw> i'd agree there's still an outstanding bug, but if we can verify that a clean upgrade from current f35 works, we should consider it resolved as a blocker, i think
17:36:24 <kparal> I was thinking about whether this has to be fixed for F36 as well, or we can just say "everybody fresh install, sorry"
17:36:38 <kparal> and I think it has to be fixed for existing F36 users as well
17:36:47 <kparal> because we guarantee that upgrade works at beta
17:36:53 <kparal> and the upgraded system must work as well as a fresh install
17:37:04 <kparal> ergo the criteria should cover it even in this case
17:38:50 <adamw> kparal: i wouldn't read that as saying that we must fix things for anyone ever affected by an upgrade bug who upgraded before final, personally.
17:38:59 <adamw> that's not how i'd intended anything i wrote to work.
17:39:49 <kparal> I read somewhere a note about selinux being in an undefined state if you upgrade before the fixes land in F35. But perhaps I'm mistaking that with the other selinux issue.
17:40:08 <kparal> But if that's the case, asking all F36 users to reinstall because things can randomly break is... concerning.
17:40:57 <kparal> Well, it seems I'm mistaking this with the other bug: https://bugzilla.redhat.com/show_bug.cgi?id=2056303#c32
17:41:23 <lruzicka> it is interesting I do not face any of those issues with flatpak on my machine
17:41:28 <kparal> But they might have the same root cause
17:42:00 <kparal> lruzicka: Because the bug is random depending on the ordering of upgraded packages and the updates you had installed at that time
17:42:18 <kparal> Which is a lovely issue to reproduce, of course
17:42:53 <kparal> Time to switch to ostree-based systems, right? 🙂
17:43:10 <adamw> ok, well, this is taking a while, i guess we can follow up in the bug
17:43:15 <adamw> but summary is, it's complicated!
17:43:42 <adamw> #info status on this bug is a bit complicated, we may be able to treat it as resolved from a blocker point of view (though bugs remain), but we will follow up further on the bug
17:45:13 <lruzicka> kparal, thats pretty stupid then
17:46:30 <adamw> #topic (2068470) online accounts: can't disable sync on items
17:46:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2068470
17:46:36 <adamw> #info Accepted Blocker, gnome-control-center, NEW
17:46:51 <adamw> so the status here seems to be "everyone agrees this is a bug, but there doesn't seem to be any obvious progress on a fix" :(
17:47:12 <adamw> Michael Catanzaro: seems to have taken a look at it a week ago upstream, but i see nothing much since then
17:47:46 <MichaelCatanzaro> adamw: I did not look, but I do have it open in a browser tab, waiting for me to look...
17:48:03 <adamw> aha :|
17:48:13 <adamw> i can try and look at it too, but i'd be starting frm scratch
17:48:40 <MichaelCatanzaro> Let me look first, then I'll let you know if I need help
17:51:08 <adamw> rgr
17:51:29 <adamw> #info this has been waiting for developer attention, but mcatanzaro has now volunteered so we hope it will move forward, thanks
17:52:05 <adamw> note, i'm skipping bugs where a fix seems to be fairly straightforwardly available, just checking in o nthe tricky cases
17:52:16 <adamw> #topic (2073708) pyanaconda.modules.common.errors.installation.StorageInstallationError: device is active
17:52:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2073708
17:52:27 <adamw> #info Accepted Blocker, plasma-desktop, NEW
17:52:57 <adamw> this one seems to be ping-ponging around a bit. i'm hoping we can get KDE team to look at it now, as it seems to me the problem is really in KDE's choices about what to automount
17:53:07 <adamw> i might also try reproducing this myself just to see if i have the right idea there
17:53:27 <adamw> Conan Kudo: geraldosimiao wdyt?
17:53:50 <Eighth_Doctor> makes sense to me
17:54:05 <Eighth_Doctor> if you figure out what we need to disable, then we can add it to the livesys-scripts in kickstart and the new package
17:54:22 <Eighth_Doctor> I don't know why we're automounting at all
17:55:04 <adamw> Conan Kudo: we want automount of removable devices on live media
17:55:14 <adamw> thumb drives, dvds (remember those)
17:55:20 <adamw> at least, i guess, we do if the desktop decides that's what it wants to do
17:55:31 <adamw> but we don't want it automounting things that actually seem to be...non-removable drives...
17:55:44 <adamw> anyhow, i do want to try and poke it a bit and see if kde's behaviour actually changed and if so when
17:55:58 <geraldosimiao> I can test it if you want, but not right now.
17:56:12 <bcotton> yeah, i'd accept KDE SIG saying "we're not going to automount anything on live images" as a solution, but not the optimal solution
17:58:05 <adamw> #info we think the issue here may be a KDE change in what kinds of devices it automounts, but we're not 100% sure, and will do some more investigation on that
17:58:22 <Eighth_Doctor> I don't like turning off removable automount, but I'd rather people be able to install things
17:58:36 <Eighth_Doctor> *install Fedora
18:00:35 <adamw> #topic (2071259) gnome-initial-setup hangs when I try to setup a google/microsoft online account
18:00:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2071259
18:00:43 <adamw> #info Accepted Blocker, selinux-policy, ASSIGNED
18:04:19 <adamw> so this is quite long, but it seems to boil down to an selinux issue
18:04:25 <adamw> we're waiting on zdenek to do an selinux-policy build
18:04:42 <adamw> #info this is waiting on an selinux-policy build with a fix; zdenek seems to know what is needed, but build has not appeared yet
18:04:53 <adamw> #topic Open floor
18:04:56 <adamw> OK, that's everything on the list
18:04:59 <adamw> any other business, folks?
18:05:14 <Eighth_Doctor> nothing blockery I think
18:05:24 <nirik> looking pretty sad for a tuesday. ;(
18:05:32 <Eighth_Doctor> I've got a redhat-rpm-config update that seems to have failed tests for some reason :/
18:05:41 <Eighth_Doctor> but that's not related to this at all
18:05:48 <geraldosimiao> Does we have a target date #2?
18:06:27 <geraldosimiao> I saw only #1 at schedule (26/04)
18:06:44 <adamw> nirik: yup
18:06:49 <adamw> we'll do our best to clean things up
18:06:58 <bcotton> geraldosimiao: target date n is one week after target date n-1
18:06:59 <adamw> at least we should be able to knock several blockers out soon and drill down to the laggards
18:07:26 <geraldosimiao> bcotton: Ok, thanks Ben
18:08:11 <geraldosimiao> So it would be 03/05
18:08:22 <geraldosimiao> Target #2
18:10:08 <Eighth_Doctor> so we're not going to make it for #1, is that it?
18:11:10 <geraldosimiao> We have two days for gi no-go
18:11:13 <adamw> Conan Kudo: yeah, at this point we can call that
18:11:16 <geraldosimiao> Go no-go
18:11:23 <adamw> there is no realistic chance we're getting a compose with all blockers fixed in time for thursday
18:11:53 <Eighth_Doctor> I guess we're going to be cursed with years of missing #1 again
18:11:59 <geraldosimiao> Two days for smash bugs, build rc and run the tests
18:12:10 <geraldosimiao> Eighth_Doctor: Oh... Sad
18:12:20 <NishantMishra[m]> No go i think
18:12:31 <NishantMishra[m]> damn second release in a row after F35
18:12:39 <NishantMishra[m]> s/damn//
18:12:40 <geraldosimiao> It's ready when it's ready...
18:12:51 <NishantMishra[m]> * second release in a row after F35 which is delayed
18:12:58 <bcotton> i got my promotion. we don't need to ship on time anymore ;-)
18:13:09 <OnuralpSezer[m]1> bcotton: Congratz ! :)
18:13:13 <geraldosimiao> 🤔😆
18:13:18 <NishantMishra[m]> bcotton: Congrats
18:13:34 <OnuralpSezer[m]1> > <@funnelfiasco:matrix.org> i got my promotion. we don't need to ship on time anymore ;-)
18:13:34 <OnuralpSezer[m]1> * Congrats ! :)
18:13:57 <NishantMishra[m]> Onuralp Sezer: need help with some kde stuff later after this meeting
18:14:13 <lruzicka> bcotton, congratulations
18:15:11 <adamw> there's always another promotion!
18:15:33 <geraldosimiao> adamw: Words of wisdom...
18:15:44 <nirik[m]> Congrats. 😉
18:16:58 * nirik was trying matrix threading there. meh...
18:17:07 <OnuralpSezer[m]1> It works
18:18:22 <adamw> alrighty, thanks for coming everyone
18:18:30 <adamw> let's try and knock out the remaining blockers for next week at least...
18:18:33 <adamw> #endmeeting