17:01:34 <adamw> #startmeeting F36-blocker-review
17:01:34 <zodbot> Meeting started Mon Mar  7 17:01:34 2022 UTC.
17:01:34 <zodbot> This meeting is logged and archived in a public location.
17:01:34 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:01:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:34 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:01:38 <adamw> #meetingname F36-blocker-review
17:01:38 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:01:41 <adamw> #topic Roll Call
17:01:48 <adamw> ahoy folks, who's around for blocker review fun?
17:02:13 <lruzicka> .hello2
17:02:14 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:02:36 <coremodule> hello everyone
17:02:41 <nielsenb> I'm here
17:02:45 * coremodule here, willing to act as secretary.
17:03:07 <nielsenb> /msg NickServ IDENTIFY nielsenb `<QXso<WTPT&N%L4w7WuS3cf
17:03:11 <nielsenb> Whoops
17:03:26 <nielsenb> Going to need to change that now, but at least it's immortalized in the log
17:05:01 <nielsenb> :)
17:05:02 <adamw> oh dear, yes, sorry...don't think I can wipe lines from the log
17:05:09 <nielsenb> It's already changed
17:05:22 <nielsenb> I'm only twice as incompetent as it looks
17:05:24 <adamw> everyone else, you can stop trying to be brandon now
17:05:30 <bcotton> .hello2
17:05:33 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:06:03 * pwhalen is here
17:06:05 <nielsenb> I've been me long enough, perhaps it's time for me to explore other options
17:07:12 <adamw> does anyone else want to spam their password to the meeting to help out?
17:07:24 <bcotton> 404878
17:07:33 <nielsenb> hunter2
17:07:49 <pwhalen> bcotton: that is oddly close to my ph#
17:08:33 <adamw> ubunturocks
17:08:35 <adamw> i mean uh
17:10:13 <adamw> moving on!
17:10:18 <adamw> impending boilerplate alert
17:10:32 <adamw> #chair bcotton pwhalen
17:10:32 <zodbot> Current chairs: adamw bcotton pwhalen
17:10:37 <pwhalen> heh, I appreciated it :)
17:10:38 <adamw> #topic Introduction
17:10:43 <adamw> Why are we here?
17:10:47 <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.
17:10:51 <adamw> #info We'll be following the process outlined at:
17:10:55 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:10:59 <adamw> #info The bugs up for review today are available at:
17:11:02 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:11:04 <adamw> #info The criteria for release blocking bugs can be found at:
17:11:08 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:11:12 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
17:11:14 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
17:11:19 <adamw> #info for Beta, we have:
17:11:30 <adamw> #info 5 Proposed Blockers
17:11:30 <adamw> #info 7 Accepted Blockers
17:11:34 <adamw> #info 7 Proposed Freeze Exceptions
17:11:34 <adamw> #info 5 Accepted Freeze Exceptions
17:11:45 <adamw> #info for Final, we have:
17:11:54 <adamw> #info 2 Proposed Blockers
17:11:54 <adamw> #info 6 Accepted Blockers
17:12:04 <adamw> #info coremodule will secretarialize
17:12:10 <adamw> let's get started with...
17:12:16 <adamw> #topic Proposed Beta blockers
17:12:27 <adamw> #topic (2061440) bcm283x-firmware fails to boot on 32-bit arm
17:12:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2061440
17:12:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/647
17:12:38 <adamw> #info Proposed Blocker, bcm283x-firmware, ASSIGNED
17:12:40 <adamw> #info Ticket vote: BetaBlocker (+1,0,-0) (+bcotton)
17:13:34 <pwhalen> +1  BB, should be an easy fix
17:13:35 <nielsenb> Is 32 bit ARM a blocking arch?
17:13:40 <pwhalen> for minimal, yes
17:13:44 <lruzicka> +1 BB
17:13:47 <nielsenb> BetaBlocker +1
17:13:47 <pwhalen> Last time.
17:14:25 <adamw> yeah, if pwhalen and pbrobinson say we still care about this, +1
17:15:21 <adamw> proposed #agreed 2061440 - AcceptedBlocker (Beta) - this violates "All release-blocking images must boot in their supported configurations" for the release-blocking minimal image on the release-blocking 32-bit Raspberry Pi platform
17:15:51 <bcotton> ack
17:15:53 <nielsenb> ack
17:15:56 <pwhalen> ack
17:16:00 <coremodule> ack
17:16:01 <lruzicka> äck
17:16:37 <adamw> #agreed 2061440 - AcceptedBlocker (Beta) - this violates "All release-blocking images must boot in their supported configurations" for the release-blocking minimal image on the release-blocking 32-bit Raspberry Pi platform
17:16:48 <adamw> #topic (2060414) On Fedora 36 KDE, dnfdragora does not start.
17:16:48 <frantisekz> .hello2
17:16:49 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:16:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2060414
17:16:56 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/642
17:16:59 <adamw> #info Proposed Blocker, dnfdragora, NEW
17:17:44 <adamw> so it seems that on KDE, dnfdragora and Discover are kinda considered to both be the 'default' package manager - dnfdragora is there to support things discover doesn't support
17:17:51 <adamw> but we could potentially drop it if it's busted
17:18:06 <adamw> Onuralp Sezer: was working on fixing this, I dunno what current status is
17:18:11 <lruzicka> In that case, +1 BB, unless we want to drop it
17:20:03 <frantisekz> if it's default, then +1 Beta Blocker
17:20:08 <adamw> well, it can be +1 blocker and the fix can be dropping it, that's allowed
17:20:14 <nielsenb> I don't love the 2 defaults, but if that's really the expect state, it's a blocker
17:20:36 <pwhalen> +1 BB
17:22:08 <bcotton> so fwiw, if you open an RPM it lauches Discover
17:22:17 <bcotton> which makes me think dnfdragora shouldn't count
17:22:49 <bcotton> but that's a reading of the term "default" intended to be very narrow :-)
17:22:50 <adamw> it's kind of a corner case
17:23:01 <nielsenb> I feel like it should be very narrow?
17:23:03 <adamw> we do actually have wording covering the case of more than one app being present
17:23:08 <OnuralpSezer[m]> <adamw> "Onuralp Sezer: was working on..." <- I was looking service problem probably will handle today or tomorrow
17:23:11 <nielsenb> I think most people's understanding of "default" is one thing
17:23:36 <OnuralpSezer[m]> I had some busy work stuff on my end to finish and today is finish Day hopefully
17:23:44 <bcotton> i'm -1 on principle
17:24:11 <adamw> but that wording is from the final criterion on app types, not the beta criterion on packaging...
17:24:32 <nielsenb> Yeah, dnfdragora is installed by default right? So technically it still has to work.
17:24:33 <adamw> the beta criterion just says "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)."
17:25:00 <adamw> nielsenb: we are parsing the word 'default'. like all words it seems to get fuzzy if you stare at it too hard. :D
17:25:21 <bcotton> another data point: a default install has Discover running at login but not (afaict) dnfdragora
17:25:30 <nielsenb> I mean "default" in the sense it's a default application, but not the default package manager
17:25:42 <nielsenb> So really, there's 2 defaults at play here, for bonus parsing fun!
17:25:53 <adamw> Ben Cotton (he/him): well, that's because discover is handling update notifications.
17:26:10 <lruzicka> bcotton, dnfdragora is installed on clean KDE installations
17:26:11 <adamw> the idea here is that dnfdragora is there for handling packages that do not have appinfo metadata
17:26:14 <adamw> discover does not handle those packages
17:26:59 <nielsenb> I think I have to be reluctantly +1 BetaBlocker
17:27:15 <adamw> whether we'd consider the criterion to cover it seems...a bit fuzzy, i guess.
17:27:17 <nielsenb> I hate that the user story is "use this app for these packages, this app for these other packages", but it is.
17:27:50 <adamw> (by comparison, GNOME ships Software to deal with packages that have appinfo, and nothing graphical at all for other packages. on GNOME you leave 'em alone or use dnf or install something else yourself)
17:28:22 <nielsenb> Yeah, was just going to ask what the state of play in Gnome was, because I didn't think it was much better.
17:28:50 <bcotton> does an "average user" know how to draw that distinction? or even that they have to?
17:29:11 <adamw> i've no idea
17:29:13 <lruzicka> I understand that Discover == Software, plus you have dnfdragora to deal with DNF graphically
17:29:28 <adamw> presumably the idea is the average user fumbles around in the menus for three hours and finds something that seems to do what they want
17:29:39 <adamw> that's KDE's user interface design philosophy, right? :D
17:29:51 <lruzicka> bcotton, I am not sure how much regular users need to install libraries and non-graphical apps
17:29:53 <nielsenb> Or if they fumble into a CLI, they will also eventually look up "how to install a package from the cli"
17:29:55 <cmurf> 3 hours is extremely patient
17:30:04 <cmurf> i start throwing rocks after about 3 minutes
17:30:07 <bcotton> i'm just not convinced that dnfdragora counts as a default package manager for anything but the most pedantic interpretation
17:30:18 <nielsenb> And after trying apt, apt-get, pacman, they might try yum or dnf
17:30:26 <cmurf> maybe i'm becoming more docile in old age
17:30:28 <bcotton> (and while i do enjoy pedantry, i'm not sure that's a good basis for blocker decisions)
17:30:31 <adamw> i can see the argument for not covering it. i could make this betaFE / finalblocker
17:30:42 <adamw> Ben Cotton (he/him): i wouldn't call it pedantry, though
17:30:53 <lruzicka> bcotton, I am experiencing a serious trouble with Software at the moment, so dnfdragora is not the only problem.
17:31:02 <adamw> the +1 argument is "it's an app for package management that's right there on the desktop, and you can't do any package management with it, it just crashes"
17:31:34 <cmurf> i think we have two defaults?
17:31:41 <nielsenb> Yeah, a package manager installed by default is near enough to a default package manager to me I feel like it counts
17:31:42 <bcotton> the -1 argument is "it's installed by default, but it's not a default application"
17:31:44 <adamw> i'm not sure if that argument is better or "but there's another app that does work so everything's fine!" is better
17:31:56 <bcotton> which is an important distinction to draw for this context
17:32:00 <adamw> Ben Cotton (he/him): the thing is, most people don't double-click on RPMs to install them, i don't think
17:32:09 <adamw> you look for a software management app and then you search for the software in it
17:32:18 <cmurf> i'd get on board with "the default package manager are those installed by default"
17:32:36 <adamw> is Marlon Rando going to find "dnfdragora" or "Discover" first if they're looking to manage some software? Uh.
17:33:12 <lruzicka> adamw, discover is easier to find, I guess
17:33:25 <bcotton> people are probably double-clicking RPMs more than we'd want to admit :-) but the fact that Discover has a system tray icon makes it more likely that Marlon Rando will ...discover it
17:33:34 <lruzicka> adamw, when you type "software" it jumps at you
17:33:40 <cmurf> but since this is KDE, I'd also leave it up to KDE SIG to define what they mean by the default package installer
17:34:16 <lruzicka> bcotton, I would disagree. They would mean they go and download RPMs from somewhere - this is too difficult to end up with a working app
17:34:19 <adamw> okay, everybody toss a coin and vote so we can move on
17:34:31 <lruzicka> +1 bb
17:34:35 * bcotton remains -1
17:34:46 <cmurf> on Workstation, I expect dnf and Software to each comply with the release criterion's install, remove, update
17:34:51 <nielsenb> +1 BetaBlocker, unless someone from the KDE SIG comes and calls us silly
17:35:00 <cmurf> seems reasonable
17:35:03 <cmurf> +1 beta blocker
17:35:10 <frantisekz> +1 BetaBlocker
17:35:20 <adamw> cmurf: that case is a bit different as we have specific separate criteria for console and graphical tools
17:35:27 <adamw> i'm gonna vote +1 in the interests of moving on with the meeting
17:36:37 <adamw> proposed #agreed 2060414 - AcceptedBlocker (Beta) - the criteria did not entirely anticipate the case of a desktop shipping *two* package management applications, but a majority decided that in this case, one of them not working violates Beta criterion "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g.
17:36:37 <adamw> default graphical package manager)"
17:36:47 <bcotton> ack
17:36:59 <coremodule> adamw, can you shorten it a bit?
17:37:11 <adamw> ugh, fine
17:37:17 <coremodule> 'default graphical package manager)"' didn't make it in IRC
17:37:39 <nielsenb> ack
17:37:42 <lruzicka> ack
17:37:53 <adamw> proposed #agreed 2060414 - AcceptedBlocker (Beta) - the criteria did not anticipate a desktop shipping two package managers, but a majority decided that in this case, one of them not working violates Beta criterion "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)"
17:37:57 <lruzicka> ack
17:37:59 <coremodule> ack
17:38:02 <cmurf> ack
17:38:02 <pwhalen> ack
17:38:11 <frantisekz> ack
17:38:21 <adamw> #agreed 2060414 - AcceptedBlocker (Beta) - the criteria did not anticipate a desktop shipping two package managers, but a majority decided that in this case, one of them not working violates Beta criterion "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)"
17:38:37 <adamw> #topic (2060868) Cannot configure WPA2 Enterprise WiFi SSID
17:38:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2060868
17:38:43 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/643
17:38:49 <adamw> #info Proposed Blocker, libnma, NEW
17:38:53 <cmurf> ouch
17:38:54 <adamw> #info Ticket vote: BetaBlocker (+0,0,-4) (-imsedgar, -catanzaro, -nielsenb, -bcotton)
17:38:55 <cmurf> really?
17:38:57 <adamw> #info Ticket vote: FinalBlocker (+4,0,-0) (+catanzaro, +imsedgar, +nielsenb, +bcotton)
17:39:01 <adamw> #info Ticket vote: BetaFreezeException (+2,0,-0) (+nielsenb, +bcotton)
17:39:03 <adamw> yeah
17:39:09 <nielsenb> Yeah, it's really gross
17:39:10 <adamw> this and the VPN bug (coming up next) are very similar
17:39:16 <cmurf> just on the description i'm +1 final blocker
17:39:29 <adamw> gnome-control-center loads in various UI elements defined in other packages for this kinda advanced network management
17:39:30 <nielsenb> I don't really see how it can be anything but
17:39:33 <cmurf> is there a contra argument for not taking it as a blocker?
17:39:58 <adamw> but apparently nobody co-ordinated having those updated for GTK4 with g-c-c getting bumped to GTK4
17:40:04 <cmurf> oops
17:40:13 <adamw> so the tricky part here is, we have strong negative votes for beta blocker on both bugs
17:40:38 <adamw> but i left both on the agenda because it doesn't seem like the voters specifically considered the networking criterion proposal
17:41:02 <Eighth_Doctor> +1 BetaFE
17:41:08 <nielsenb> I had hoped to help out with these more, but it was so hard to build the latest gnome-control-center for awhile I kind of never got a chance
17:41:13 <adamw> with the existing criteria, it's a bit hard to justify these as beta blockers, so -1 on that is appropriate
17:41:24 <frantisekz> -1 BetaBlocker, +1 BetaFE
17:41:25 <adamw> but, we did agree to resurrect the networking criteria proposal i wrote back in 2020:
17:41:27 <Eighth_Doctor> +1 FinalBlocker
17:41:38 <cmurf> right
17:41:47 <cmurf> and that networking proposal applies to beta?
17:41:57 <adamw> i'm finding the link right now
17:42:10 <nielsenb> If we're saying that criteria is going to apply to beta, this immediately becomes a beta blocker in my mind
17:42:17 <adamw> iirc, i proposed it for Basic
17:42:23 <cmurf> oi
17:42:25 <nielsenb> So yeah
17:42:42 <lruzicka> heh, basic criterion broken :D
17:43:34 <adamw> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/ZK6FRRRWQNC3FQVX7ZTMUHQMPPEAZSJA/
17:43:50 <adamw> that was the initial proposal, and yes, I said "My proposal would be to add this to the Basic criteria."
17:44:23 <bcotton> i'm on board with the networking criterion, but since it's not adopted yet, and given where we are in the schedule, i don't feel like voting +1 on the basis of a pending criterion
17:44:23 <adamw> still, that's just a proposal. the question is, do we think that's the right thing to do, or do we want to keep some 'advanced' netwokr functionality for Final?
17:44:24 <cmurf> i think adamw is going to have to make the call if it's sufficiently close to the finish line to be applicable to f36 cycle, and i can get on board with that
17:44:30 <bcotton> i think we're better served by calling this not a beta blocker and block final on it
17:45:00 <adamw> i've ping mcatanzaro, btw
17:45:09 <cmurf> well it's it's still in proposal land, then -1 beta blocker, +1 final blocker and activate the networking proposal for f37 as a basic release criterion
17:45:23 <lruzicka> sounds good to me
17:45:32 <nielsenb> I'm inclined to agree
17:45:33 <pwhalen> +1 Beta FE, +1 Final Blocker
17:45:40 <cmurf> s/it's/if/
17:46:05 <adamw> hi Michael Catanzaro
17:46:06 <cmurf> also +1 Beta FE
17:46:51 <adamw> Michael Catanzaro: you should have scrollback, but to recap briefly, i kept this on the agenda because we have an open proposal for networking criteria that nobody referred to explicitly in the voting so i wasn't sure if it had been taken into consideration
17:47:15 <adamw> it was proposed in 2020 but got a bit forgotten about, i resurrected it this week. the thread is https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/ZK6FRRRWQNC3FQVX7ZTMUHQMPPEAZSJA/
17:47:53 <adamw> so i figured we should take that into account in the voting, and we could potentially take these bugs as beta blocker if there was strong agreement that we should adopt the criteria for basic or beta, and apply that decision to f36.
17:47:57 <MichaelCatanzaro> My -1 BetaBlocker vote was because there is currently no criterion
17:48:35 <MichaelCatanzaro> If that changes, my vote changes too, but then we would have to downgrade gnome-control-center or else slip a while, because I'm sure this won't be fixed overnight
17:49:32 <adamw> so far the voting seems to be broadly OK with making this FE for beta and blocker for final, but i wanted to make sure we cover all angles
17:49:51 <adamw> btw, on that topic, do we know for sure that g-c-c 41 will work OK with the rest of gnome at 42, or has that not been tested yet?
17:50:40 <nielsenb> I know it "runs", I had such a setup going a week or so ago
17:50:55 <nielsenb> But I was really only going through some printer flows, I can't speak to much past that
17:51:16 <MichaelCatanzaro> adamw: I do not know, probably something or other will be broken... but any such problems should be fixable
17:51:35 <adamw> ok
17:51:56 <adamw> so, it sounds like overall, folks are inclined to applying the current criteria for f36 and taking this as betaFE / final blocker
17:52:06 <adamw> does anyone strongly feel we should take this as beta blocker?
17:53:07 <adamw> ok then!
17:55:10 <adamw> proposed #agreed 2060868 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this does not violate the current Beta criteria, and there wasn't enough support for applying the proposed networking criteria that do cover it to F36 Beta, but it is bad enough to be an FE. For Final, it violates the default app functionality and panel criteria
17:55:28 <frantisekz> ack
17:55:35 <Eighth_Doctor> ack
17:55:47 <coremodule> ack
17:56:02 <bcotton> ack
17:56:02 <adamw> #agreed 2060868 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this does not violate the current Beta criteria, and there wasn't enough support for applying the proposed networking criteria that do cover it to F36 Beta, but it is bad enough to be an FE. For Final, it violates the default app functionality and panel criteria
17:56:17 <adamw> #topic (2057719) VPN connection editors do not load in gnome-control-center Network pane (need porting to GTK4)
17:56:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2057719
17:56:25 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/630
17:56:29 <adamw> #info Proposed Blocker, NetworkManager-openvpn, NEW
17:56:31 <adamw> #info Ticket vote: BetaBlocker (+0,1,-3) (bcotton, -imsedgar, -catanzaro, -nielsenb)
17:56:35 <adamw> #info Ticket vote: FinalBlocker (+4,0,-0) (+bcotton, +catanzaro, +imsedgar, +nielsenb)
17:56:35 <Eighth_Doctor> isn't this related?
17:56:35 * bcotton copies, pastes
17:56:38 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
17:56:39 <adamw> yeah
17:56:55 <adamw> this is a similar issue affecting a different feature. so, logically speaking, we should vote the same.
17:57:00 <lruzicka> +1
17:57:03 <adamw> anyone want to handle it differently?
17:57:09 <Eighth_Doctor> nah
17:57:16 <nielsenb> I'll be logical, but just this once
17:57:24 <adamw> heheh
17:57:31 <adamw> it's always worth trying something new!
17:57:41 <nielsenb> Like passwords
17:58:38 <adamw> alright then
17:58:49 <nielsenb> Should this also be a beta FE? Or is that automatic with it being a final blocker?
17:59:08 <adamw> not automatic, but i'm assuming everyone would want that too
17:59:18 <adamw> i'm just gonna use the same agreed text with the bug number changed unless anyone objects
17:59:36 <bcotton> do it!
17:59:54 <adamw> #agreed 2057719 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this does not violate the current Beta criteria, and there wasn't enough support for applying the proposed networking criteria that do cover it to F36 Beta, but it is bad enough to be an FE. For Final, it violates the default app functionality and panel criteria
18:00:08 <adamw> #topic (2054016) SDDM in Fedora 36 - menus do not open properly and cause a strobe effect, plus minor cosmetic issues
18:00:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2054016
18:00:15 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/645
18:00:20 <adamw> #info Proposed Blocker, sddm, ON_QA
18:00:23 <adamw> #info Ticket vote: BetaBlocker (+0,0,-1) (-bcotton)
18:00:26 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+bcotton)
18:00:29 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
18:02:10 <nielsenb> Is anyone here seeing this? And does the update fix it?
18:02:26 <coremodule> punt for more info
18:02:38 <Eighth_Doctor> it's pretty easily reproducible
18:02:49 <Eighth_Doctor> click on a menu, watch it flicker rapidly
18:03:10 <nielsenb> I definitely wouldn't block beta on it unless there's some specific criteria I've missed, but it definitely warrants a freeze exception
18:03:17 <Eighth_Doctor> it's been a problem for weeks and finally a fix came from upstream to make it go away
18:03:19 <lruzicka> I also saw it but it is merely cosmetic
18:03:58 <Eighth_Doctor> I'd rather not accidentally cause someone to have a seizure
18:04:23 <nielsenb> I'd rather not ship something with the first screen a user sees after install being broken
18:04:48 <adamw> the keyboard layout thing actually bothers me more than anything else, but let's see if openqa is seeing that...
18:05:11 <nielsenb> Yeah, the keyboard layout makes it a final blocker if you massage the given criteria a little
18:05:20 <Eighth_Doctor> I haven't had a chance to see if OpenQA sees an improvement
18:05:27 <adamw> i don't think you have to massage anything? pretty sure we have a specific criteria for it
18:05:37 <Eighth_Doctor> though Rex seems to indicate things are better now in his local tests
18:05:38 <lruzicka> the keyboard layout not being visible would be a final blocker for me, you can still use it
18:05:42 <adamw> and yeah, openqa does see the keyboard layout bug. but it also sees it in current rawhide, which should have the fix for the other problems?
18:05:53 <adamw> lruzicka: not that it's not visible, that it's *wrong*
18:06:31 <lruzicka> adamw, I have reported this bug also having seen  this https://bugzilla.redhat.com/show_bug.cgi?id=2054016
18:06:36 <adamw> ah, that's a final criterion too.
18:06:53 <lruzicka> adamw, which was closed as a duplicate of a bug, we are talking about
18:07:08 <adamw> maybe re-open it then...
18:07:57 <adamw> oh, well, your bugs were more about the cosmetic side too
18:07:58 <lruzicka> Martin Břiza thinks it should be considered together with 2054016
18:08:10 <adamw> seems like we should have a separate bug for the layout being wrong by default
18:08:16 <nielsenb> Yeah
18:08:24 <lruzicka> adamw, you mean the AF layout being the default?
18:08:33 <adamw> yes
18:08:46 <nielsenb> Presumably after selecting something else during install
18:08:52 <Eighth_Doctor> yeah that one is weird and different
18:08:57 <Eighth_Doctor> I don't know what causes that
18:09:00 <Eighth_Doctor> I was focused on the strobing issue
18:09:05 <lruzicka> nielsenb, yeah ... I always select czech and end up with AF
18:09:26 <nielsenb> Yeah, that's a final blocker I would say
18:09:41 <Eighth_Doctor> but yeah, that bug should be reopened so we can go back to upstream about it
18:10:26 <adamw> anyhoo
18:10:31 <adamw> all these feel like final blocker / beta FE to me
18:10:38 <adamw> so -1 beta blocker, +1 final blocker, +1 beta FE
18:11:13 <lruzicka> yeah, count me for the same portfolio
18:11:18 <nielsenb> -1 BetaBlocker, +1 BetaFE, +1 FinalBlocker
18:11:31 <Eighth_Doctor> I doesn't matter much right now since I have an update for it, so...
18:11:37 <frantisekz> -1 BetaBlocker, +1 BetaFE, +1 FinalBlocker from me too
18:11:50 <Eighth_Doctor> +1 BetaBlocker, +1 BetaFE, +1 FinalBlocker
18:12:29 <coremodule> -1 BetaBlocker, +1 BetaFE, +1 FinalBlocker
18:12:32 <kk4ewt> -BB +BFE
18:12:40 <kk4ewt> +1 FB
18:14:09 <adamw> proposed #agreed 2054016 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - nothing reported here quite seems to violate the Beta criteria, but it's definitely bad enough to be worth fixing if possible. The 'default keyboard layout is wrong' portion violates Final criterion "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in via the
18:14:09 <adamw> default login manager for a release-blocking desktop"
18:14:18 <nielsenb> ack
18:14:24 <bcotton> ack
18:14:24 <lruzicka> patch
18:14:27 <Eighth_Doctor> ack
18:14:29 <lruzicka> too long
18:14:47 * bcotton has to leave. enjoy your FE voting :-)
18:14:54 <lruzicka> bye, bcotton
18:15:02 <coremodule> 'default login manager for a release-blocking desktop"'
18:15:03 <adamw> how much too long?
18:15:05 <adamw> thanks ben!
18:15:14 <coremodule> adamw ^^
18:15:14 <adamw> grr
18:15:16 <lruzicka> about ten words?
18:15:57 <adamw> proposed #agreed 2054016 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - doesn't quite seem to violate the Beta criteria, but bad enough to be worth fixing. 'Default keyboard layout is wrong' portion violates Final criterion "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in via the default login manager for a release-blocking
18:15:57 <adamw> desktop"
18:16:02 <lruzicka> one word
18:16:02 <frantisekz> one word
18:16:07 <adamw> that's ok
18:16:09 <coremodule> 'desktop"'
18:16:13 <adamw> because proposed
18:16:18 <coremodule> ah, right
18:16:19 <coremodule> ack
18:16:19 <lruzicka> ack
18:16:21 <nielsenb> ack
18:16:21 <frantisekz> ack
18:16:26 <Eighth_Doctor> ack
18:16:38 <adamw> #agreed 2054016 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - doesn't quite seem to violate the Beta criteria, but bad enough to be worth fixing. 'Default keyboard layout is wrong' portion violates Final criterion "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in via the default login manager for a release-blocking desktop"
18:16:42 <lruzicka> nice
18:16:49 <lruzicka> you know your stuff, adamw
18:16:57 <adamw> ok, let's go to:
18:16:59 <adamw> i can count!
18:17:04 <adamw> #topic Proposed Beta freeze exceptions
18:17:11 <adamw> #topic (2059685) Include PyPy 3 in the Fedora Python Classroom Lab 36 Beta
18:17:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2059685
18:17:17 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/638
18:17:21 <adamw> #info Proposed Freeze Exceptions, distribution, POST, depends on other bugs
18:17:24 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
18:17:29 <lruzicka> +1
18:18:01 <Eighth_Doctor> BetaFE +1
18:18:11 <frantisekz> +1
18:18:24 <nielsenb> +1 BetaFE
18:18:25 <adamw> looks like this goes with 2059670 so i'll do that next
18:18:32 <adamw> seems fine, shouldn't hurt anything blocking
18:18:34 <adamw> +1
18:18:36 <coremodule> +1 BetaFE
18:19:15 <adamw> proposed #agreed 2059685 - AcceptedFreezeException (Beta) - giving spins their intended contents is a reasonable grounds for an FE and this should not hurt anything else
18:19:21 <nielsenb> ack
18:19:24 <Eighth_Doctor> ack
18:20:12 <coremodule> ack
18:20:13 <lruzicka> ack
18:20:41 <adamw> #agreed 2059685 - AcceptedFreezeException (Beta) - giving spins their intended contents is a reasonable grounds for an FE and this should not hurt anything else
18:21:04 <adamw> #topic (2059670) Make PyPy 3.9 the main pypy3 in Fedora 36
18:21:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2059670
18:21:11 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/637
18:21:14 <frantisekz> +1
18:21:16 <adamw> #info Proposed Freeze Exceptions, pypy3.9, ON_QA
18:21:19 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
18:21:20 <Eighth_Doctor> +1
18:21:30 <adamw> these two sorta go together, the first won't work without this one
18:21:39 <adamw> and again, seems reasonable and not likely to hurt anything important, so +1
18:21:52 <nielsenb> +1 BetaFE
18:22:46 <lruzicka> +1 bfe
18:23:20 <adamw> proposed #agreed 2059670 - AcceptedFreezeException (Beta) - this is needed for 2059685 which we accepted, and again seems unlikely to hurt anything else important
18:23:39 <frantisekz> ack
18:23:40 <Eighth_Doctor> ack
18:23:42 <coremodule> ack
18:23:43 <nielsenb> ack
18:23:45 <lruzicka> ack
18:24:06 <adamw> #agreed 2059670 - AcceptedFreezeException (Beta) - this is needed for 2059685 which we accepted, and again seems unlikely to hurt anything else important
18:24:13 <adamw> #topic (2061392) Drop non-upstream chromium support patch
18:24:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2061392
18:24:28 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/646
18:24:31 <adamw> #info Proposed Freeze Exceptions, ffmpeg, ASSIGNED
18:24:53 <frantisekz> +1
18:25:08 <nielsenb> +1 BetaFE
18:25:23 <cmurf> tentatively +1 but does something bad happen if it's only available as an update once freeze is lifted?
18:25:23 <Eighth_Doctor> (if it's not clear, the chromium patch isn't used by anything in Fedora right now)
18:25:28 <lruzicka> +1 bfe
18:25:32 <Eighth_Doctor> well, it's an ABI break
18:25:41 <Eighth_Doctor> since we add a function to ffmpeg and change the function signatures
18:25:50 <cmurf> so we're better off getting rid of it now?
18:25:53 <Eighth_Doctor> yes
18:26:01 <cmurf> ok +1 beta FE
18:26:09 <Eighth_Doctor> nobody uses the function added and The Other Repo(tm) deleted the patch
18:26:16 <Eighth_Doctor> so I want it gone to synchronize the ABI
18:26:28 <cmurf> go it
18:26:33 <cmurf> * got it
18:26:39 <adamw> the update policy doesn't actually say anything about abi/api changes and the beta release
18:26:49 <Eighth_Doctor> but it does for post-GA
18:27:03 <adamw> the wording "Avoid ABI/API changes where possible. If unavoidable, use a side-tag to rebuild packages" is introduced at updates-testing activation, which we already passed
18:27:19 <adamw> right, but i'm just saying, that doesn't actually give any grounds for making this an FE...
18:28:11 <adamw> i guess i can buy 'let's just straighten things out asap', but there isn't a rule that you can't do it after beta or anything.
18:28:20 <frantisekz> (but, anything can technically be a fe, can't it?)
18:29:04 <adamw> well...sorta :P
18:29:10 <adamw> there has to be a justification, though.
18:29:30 <adamw> do we have to rebuild anything to go along with this?
18:30:02 <Eighth_Doctor> a few packages
18:30:05 <Eighth_Doctor> I put it in the email I sent this morning
18:30:20 <Eighth_Doctor> the main reason I want to do it sooner rather than later is because things are starting to use ffmpeg and I'd like the chain to be small atm
18:31:08 <adamw> the three deps don't seem very important, so...i guess that at least makes it not too dangerous...
18:31:35 <Eighth_Doctor> yeah
18:32:24 <adamw> i guess a weak +1
18:32:29 <adamw> and i'll yell at you if you break stuff
18:32:31 <adamw> :D
18:33:09 <Eighth_Doctor> haha
18:35:34 <adamw> proposed #agreed 2061392 - AcceptedFreezeException (Beta) - it seems reasonable to get the desired ABI stable ASAP to prevent incompatibility with other builds existing for too long and too many things using the 'wrong' ABI
18:35:44 <Eighth_Doctor> ack
18:36:45 <lruzicka> ack
18:36:52 <frantisekz> ack
18:36:55 <copperi[m]> ack
18:36:59 <nielsenb> acl
18:37:01 <adamw> #agreed 2061392 - AcceptedFreezeException (Beta) - it seems reasonable to get the desired ABI stable ASAP to prevent incompatibility with other builds existing for too long and too many things using the 'wrong' ABI
18:37:02 <nielsenb> ack
18:37:13 <adamw> #topic (2059776) Bootloader install fails on ostree installs since Fedora-Rawhide-20220301.n.0
18:37:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2059776
18:37:19 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/640
18:37:23 <adamw> #info Proposed Freeze Exceptions, grub2, NEW
18:37:26 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
18:37:29 <adamw> easy +1 here
18:37:51 <frantisekz> +1
18:38:13 <Eighth_Doctor> +1
18:38:17 <nielsenb> +1 BetaFE
18:38:17 <copperi[m]> +1
18:39:06 <lruzicka> +1
18:39:20 <adamw> although, hm. the new grub2 hasn't been built for f36
18:39:24 <adamw> so this is rawhide-only for now
18:40:02 <adamw> so, i guess -1 for now...since the new grub2 wouldn't get in without its own fe, and we wouldn't push it without a fix for this...
18:40:18 <nielsenb> Well fine
18:40:24 <nielsenb> -1 BetaFE
18:40:35 <adamw> it's a rollercoaster ride :D
18:40:45 <adamw> i guess since i proposed it, i can just unpropose it
18:40:55 <copperi[m]> :)
18:41:18 <lruzicka> -1 fe
18:41:26 <adamw> #info adamw has withdrawn the proposal for this bug as the broken grub2 has not yet been sent to F36
18:41:43 <adamw> #topic (2046850) prusa-slicer: FTBFS in Fedora rawhide/f36, fails to install
18:41:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2046850
18:41:50 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/641
18:41:55 <adamw> #info Proposed Freeze Exceptions, prusa-slicer, ON_QA, depends on other bugs
18:41:57 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
18:42:04 <lruzicka> +1 fe
18:42:08 <Eighth_Doctor> +1 BetaFE
18:42:10 <nielsenb> +1 BetaFE
18:42:23 <frantisekz> +1
18:42:46 <copperi[m]> +1
18:43:04 <frantisekz> (shouldn't we make some automatic FTBFS/FTI FE mechanism for non-critpath/non on blocking media packages?)
18:43:22 <Eighth_Doctor> yes
18:43:32 <adamw> sure, +1 FE
18:43:45 <frantisekz> (I'll try to come up with something)
18:44:09 <adamw> frantisekz: we could, there *are* cases where we might want to be careful though, e.g. where the packages provides: something that another package provides: , or is in comps and might cause an image to go oversize or something
18:44:18 <adamw> don't think those are factors here though.
18:44:55 <adamw> proposed #agreed 2046850 - AcceptedFreezeException (Beta) - this is accepted as we usually grant FEs to FTBFS/FTI bugs as it's always better to have installable packages in the frozen repos
18:45:08 <frantisekz> ack
18:45:35 <lruzicka> ack
18:45:44 <copperi[m]> ack
18:45:59 <nielsenb> ack
18:46:02 <adamw> #agreed 2046850 - AcceptedFreezeException (Beta) - this is accepted as we usually grant FEs to FTBFS/FTI bugs as it's always better to have installable packages in the frozen repos
18:46:12 <adamw> #topic (2036866) qt6 not available on s390x
18:46:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2036866
18:46:17 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/644
18:46:21 <adamw> #info Proposed Freeze Exceptions, qt6-qtbase, ON_QA
18:48:09 <lruzicka> +1 fe
18:48:10 <nielsenb> +1 BetaFE
18:48:15 <Eighth_Doctor> +1 BetaFE
18:48:38 <copperi[m]> +1
18:48:40 <adamw> i mean, in theory this is very virtuous yes
18:48:50 <adamw> is anyone actually running anything that uses qt6 on big iron? :D
18:49:23 <nielsenb> Don't let your dreams be dreams
18:50:13 <nielsenb> Qt has a new in-app marketing platform they won't stop emailing me about, and big iron customers have deep pockets. I'm sensing opportunity here!
18:50:32 <Eighth_Doctor> 😆
18:51:04 <adamw> i'm just a bit leery about taking 29 rebuilds in release week to fix a very theroetical problem
18:51:18 <adamw> (and there are actual changes to at least one of the packages, too)
18:52:23 <Eighth_Doctor> I think the fact OpenQA has been happy with it on Rawhide for a while now makes me reasonably confident here
18:52:45 <adamw> ehhh
18:52:56 <adamw> i once again reserve the right to yell at you
18:53:04 <Eighth_Doctor> sure
18:53:33 <adamw> proposed #agreed 2036866 - AcceptedFreezeException (Beta) - this is accepted because we apparently care a lot about arch support, and definitely want people to be able to launch graphical applications with a bleeding-edge toolkit on their mainframes
18:53:41 <nielsenb> Isn't that a fix that could potentially help other consumers of SpirV?
18:53:50 <Eighth_Doctor> ack
18:53:53 <nielsenb> ack
18:53:54 <lruzicka> ack
18:54:00 <copperi[m]> ack
18:54:24 <Eighth_Doctor> people like fancy VDI on mainframes :)
18:54:26 <adamw> nielsenb: the spirv fix is stable already, aiui
18:54:41 <adamw> this is just re-enabling s390x for qt6-related packages
18:56:20 <adamw> #agreed 2036866 - AcceptedFreezeException (Beta) - this is accepted because we apparently care a lot about arch support, and definitely want people to be able to launch graphical applications with a bleeding-edge toolkit on their mainframes
18:56:29 <adamw> #topic (2057184) cgroupify: Error moving pid into new cgroup (11)
18:56:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2057184
18:56:39 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/623
18:56:41 <adamw> #info Proposed Freeze Exceptions, uresourced, ON_QA
18:58:38 <adamw> oh, this one again
18:58:38 <adamw> sigh
18:58:39 <adamw> where we we
18:59:49 <nielsenb> I don't see an update by the maintainer
19:00:21 <adamw> yeah, but we didn't exactly ask either
19:00:34 <adamw> sorry, i should've checked on that
19:00:50 <adamw> oh wait, i think he may have followed up on the ticket
19:01:10 <adamw> no...but...i'm sure i saw a follow-up somewhere. grr.
19:01:43 <cmurf> yeah it's not necessary to take as FE
19:01:46 <cmurf> it's nbd
19:01:49 <adamw> oh right
19:01:50 <adamw> 18:35:27 <cmurf> ok just talked to ben berg, it's not a big deal to reject this
19:01:56 <cmurf> 0.5.1 is working for me fine
19:01:56 <adamw> from last week's log
19:01:59 <cmurf> folks will get it in an update
19:02:00 <adamw> it came in just after we had moved on
19:02:17 <adamw> #info just after we discussed this last week, the maintainer told cmurf the bug isn't a big deal and it's fine to fix it with an update
19:02:20 <adamw> so, -1 from me
19:02:46 <nielsenb> -1 BetaFE
19:03:34 <cmurf> -1 beta FE
19:03:40 <cmurf> voting against my own proposal...
19:03:43 <Southern_Gentlem> -1bfe
19:03:45 <frantisekz> -1 BetaFE
19:04:11 <adamw> proposed #agreed 2057184 - RejectedFreezeException (Beta) - per feedback from the maintainer, this is not a major bug and it's fine to fix it with an update
19:04:36 <lruzicka> ack
19:04:46 <frantisekz> ack
19:04:47 <cmurf> ack
19:04:55 <copperi[m]> ack
19:05:07 <adamw> #agreed 2057184 - RejectedFreezeException (Beta) - per feedback from the maintainer, this is not a major bug and it's fine to fix it with an update
19:05:26 <adamw> ok, nearly there!
19:05:29 <adamw> let's deal with:
19:05:33 <adamw> #topic Proposed Final blockers
19:05:38 <adamw> #topic (2058920) [abrt] gnome-control-center: cc_object_storage_create_dbus_proxy_finish(): gnome-control-center killed by SIGABRT
19:05:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2058920
19:05:46 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/632
19:05:49 <adamw> #info Proposed Blocker, gnome-control-center, NEW
19:05:53 <adamw> #info Ticket vote: FinalBlocker (+0,0,-2) (-catanzaro, -nielsenb)
19:06:08 <adamw> this has a couple of -1s on the ground it's kinda transient and not clearly reproducible
19:06:13 <adamw> chris, is your latest reproducer reliable?
19:09:32 <adamw> cmurf: ^^
19:12:15 <adamw> welp
19:12:57 <nielsenb> Could punt, maybe we can see if any of us can reprodue?
19:13:00 <nielsenb> *reproduce
19:13:15 <nielsenb> Or if it starts happening all the time in beta
19:13:20 <adamw> i can't reproduce just by launching bluetooth settings from the user menu, and i have a bluetooth device connected (mouse, not headset)
19:13:36 <adamw> i'm kinda -1 for now as nobody else seems to be hitting it
19:14:09 <adamw> https://retrace.fedoraproject.org/faf/reports/364456/ shows 2 reports, which are probably both chris
19:15:22 <frantisekz> good point about faf, let's -1 it then, it can be re-proposed if needed
19:16:57 <adamw> proposed #agreed 2058920 - RejectedBlocker (Final) - this still doesn't seem clearly reproducible or commonly encountered at present. We will reconsider if clear steps to reproduce are found
19:17:03 <nielsenb> ack
19:17:04 <lruzicka> ack
19:17:11 <adamw> (that's counting -2 from the vote system and -2 from me and frantisekz)
19:17:15 <coremodule> ack
19:17:18 <frantisekz> ack
19:17:23 <copperi[m]> ack
19:18:15 <adamw> #agreed 2058920 - RejectedBlocker (Final) - this still doesn't seem clearly reproducible or commonly encountered at present. We will reconsider if clear steps to reproduce are found
19:18:25 <adamw> #topic (2010595) Cannot install firmware if secureboot is enabled
19:18:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2010595
19:18:32 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/635
19:18:36 <adamw> #info Proposed Blocker, shim, NEW
19:18:39 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
19:19:29 <frantisekz> I am kinda -1 here; it seems to affect only thinkpads? apart from that, this can be fixed as a post-release upgrade and there is ton of hw that's not supported by fwupd anyway
19:19:54 <adamw> so, we punted this last week for a couple of things that haven't transpired...
19:20:17 <nielsenb> Hardware not supported doesn't display the notification though, right?
19:20:26 <frantisekz> yeah, that's fair point
19:20:32 <adamw> not sure about what range of hardware it affects, i was assuming it affected any case where firmware updates were actually available and secure boot was enabled?
19:20:45 <adamw> i guess we could punt again and actually ask the question this time
19:21:04 <frantisekz> I don't know, I thought it was broken with secureboot on thinkpads for some time and that it was issue lenovo-side
19:25:10 <adamw> proposed #agreed 2010595 - punt (delay decision) - there hasn't been much movement on this from last week (info about how this affects software updates is not yet provided), so we will delay the decision again
19:25:21 <lruzicka> ack
19:25:24 <nielsenb> ack
19:25:29 <coremodule> ack
19:27:08 <cmurf> oops sorry
19:27:49 <cmurf> it is not reproducible - it just transiently happens sometimes
19:27:50 <adamw> #agreed 2010595 - punt (delay decision) - there hasn't been much movement on this from last week (info about how this affects software updates is not yet provided), so we will delay the decision again
19:27:54 <coremodule> adamw, I proposed a final blocker at 19:03 UTC, don't think it has synced yet...
19:27:59 <coremodule> .bug 2061528
19:28:00 <zodbot> coremodule: 2061528 – Fedora IoT - Failed to start systemd-userdbd.service - User Database Manager - https://bugzilla.redhat.com/2061528
19:28:01 <cmurf> i've hit it maybe 1/2 dozen times
19:28:53 <nielsenb> +1 FinalBlocker
19:29:04 <nielsenb> Services need to start
19:29:05 <adamw> coremodule: ah yeah that's bad timing, it syncs at the top of the hour
19:29:15 <adamw> please don't vote yet
19:29:16 <adamw> i didn't set a topic
19:29:19 <cmurf> that would seem to be a beta blocker, how could things work at all if that service isn't working?
19:29:49 <adamw> well, most iot tests are passing in openqa
19:29:51 <nielsenb> Vote early, vote often
19:29:57 <adamw> i think we assume non-root users aren't used a lot
19:30:12 <adamw> hold on, gotta do the boilerplate manually
19:30:34 <coremodule> sorry adamw, these bugs just didn't want to be found until they *knew* it would cause you extra work
19:30:42 <adamw> #topic (2061528) Fedora IoT - Failed to start systemd-userdbd.service - User Database Manager
19:30:45 <adamw> heh
19:30:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2061528
19:31:11 <adamw> #info Proposed Blocker, systemd, NEW
19:31:16 <adamw> alrighty
19:31:40 <adamw> seems +1-y, though the 'only on first boot' thing complicates it a bit
19:31:44 <pwhalen> this only seems to happen on first boot and is fine when restarted
19:31:53 <lruzicka> -1. common bugs
19:32:11 <lruzicka> +1 fe
19:32:24 <nielsenb> Definitely +1 FE
19:36:38 <adamw> anyone else?
19:37:08 <coremodule> I can see a -1 Final Blocker, +1 BetaFE, and add to commonbugs
19:37:16 <coremodule> because of the only on first boot deal
19:37:23 <nielsenb> +1 FinalBlocker
19:37:40 <nielsenb> Criterion doesn't carve out "but works on reboots", and I'm picky
19:37:46 <coremodule> but I think it violates the criterion without fudging said criterion
19:38:02 <adamw> i'd say the criterion doesn't exactly specify either way
19:38:29 <adamw> it says "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."
19:38:38 <nielsenb> "after installation" implies on first boot to me
19:38:42 <adamw> is that violated if on fifty boots it fails once but works 49 times? hmm.
19:38:56 <adamw> it's more meant to mean, you know, in general
19:39:01 <pwhalen> -1 Beta Blocker, +1 BFE, +1 Final blocker
19:39:03 <adamw> this kind of failure is pretty rare, i don't think we saw it before.
19:39:11 <nielsenb> and "propertly" is every time to me
19:39:21 <adamw> more common is "it always works", "it always fails", or "sometimes it fails"
19:39:21 <nielsenb> But again, I'm picky, and I accept the other side too
19:39:43 <nielsenb> I also agree that it seems like users and IoT don't necessarily go real commonly together
19:39:48 <adamw> i guess thinking about it, on the whole, i'll go -1 final blocker, 'just reboot and it'll work forever more' seems okay
19:39:56 <pwhalen> I dont think there is any impact on the system, but its is alarming to see the red go by
19:40:02 <adamw> do we want to grant a beta FE?
19:40:11 <coremodule> aye, +1 beta FE
19:40:18 <nielsenb> +1 BetaFE
19:42:41 <adamw> proposed #agreed 2061528 - RejectedBlocker (Final) AcceptedFreezeException (Beta) - as this seems to have no practical consequences and works on every boot after the first, we decided it's not a sufficient violation of the criterion to block the release on. However it is confounding to see on first boot, so we grant an FE to fix that for Beta if possible
19:42:54 <nielsenb> ack
19:43:16 <copperi[m]> ack
19:43:18 <coremodule> ack
19:43:39 <adamw> #agreed 2061528 - RejectedBlocker (Final) AcceptedFreezeException (Beta) - as this seems to have no practical consequences and works on every boot after the first, we decided it's not a sufficient violation of the criterion to block the release on. However it is confounding to see on first boot, so we grant an FE to fix that for Beta if possible
19:43:42 <adamw> ok
19:43:59 <adamw> in the interests of everyone's sanity, let's not do a blow-by-blow on the accepted beta blockers. i will be working those hard today and tomorrow of course
19:44:49 <adamw> #topic Open floor
19:44:59 <adamw> any other business? including any beta blockers anyone wants to talk about?
19:45:10 <coremodule> oh yeah, I just proposed two new beta blockers..............
19:45:12 <coremodule> just kidding!
19:45:19 <frantisekz> .fire coremodule
19:45:19 <zodbot> adamw fires coremodule
19:45:50 <adamw> overall they're all kinda in progress, the biggest worries are 2016613 (not sure of the eta for that) and 2017043 (nobody but me has actually volunteered to do anything about that, and I'm bad at C and didn't get round to it yet)
19:46:40 <adamw> mclasen: Michael Catanzaro if you can get anyone to work on that it'd be appreciated. upstream report is https://gitlab.gnome.org/GNOME/mutter/-/issues/2154
19:46:42 <frantisekz> two hard to fix, both, fire the release away! :D
19:46:52 <cmurf> that's an aggressive firing, where was the diplomacy first? could be a U.N. charter violation here...
19:46:54 <adamw> i will still try and write a fix if i can, but i really am bad at C. i'm not promising anything. :D
19:47:03 <cmurf> (we getting punchy time for this blocker review to end) :P
19:48:13 <frantisekz> cmurf, before the U.N. decides anything, we'll have company vpns blocked and we'll living in the USSR here in Brno... (so much for the punchy end of the meeting :D )
19:48:33 <adamw> yeah i think we may be in "too soon" territory here :D
19:49:43 <cmurf> where is the invitation to have a meeting to decide when to have a lunch meeting to decide what constitutes a diplomatic agenda for the pre-meeting discussing what we think needs being discussed ...
19:50:32 <adamw> cmurf: i faxed it to your secretary last tuesday
19:51:17 <cmurf> she's in a lunch meeting with the fax repair guy discussing terms for the phone call to discuss what the problem might be
19:51:34 <cmurf> actually my secretary is he, i just have to put another hat on
19:51:44 <lruzicka> I need to leave, have a nice time everyone.
19:53:24 <adamw> thanks everyone
19:53:32 <adamw> #endmeeting