16:00:11 <coremodule> #startmeeting F36-blocker-review
16:00:11 <zodbot> Meeting started Mon Apr  4 16:00:11 2022 UTC.
16:00:11 <zodbot> This meeting is logged and archived in a public location.
16:00:11 <zodbot> The chair is coremodule. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:11 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:00:11 <coremodule> #meetingname F36-blocker-review
16:00:11 <coremodule> #topic Roll Call
16:00:11 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:00:22 <coremodule> hello everyone, who is around for a blocker review?
16:00:24 <nielsenb> I'm here
16:01:05 <kparal> I probably won't be able to attend this meeting, but I voiced my opinions in review tickets. You can always try to ping me, of course, if you want some clarifications. But I might be afk.
16:03:27 <lruzicka> I am also here
16:03:33 <lruzicka> .hello2
16:03:34 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:03:48 <OnuralpSezer[m]1> .hello thunderbirdtr
16:03:48 <zodbot> OnuralpSezer[m]1: thunderbirdtr 'Onuralp SEZER' <thunderbirdtr@gmail.com>
16:04:24 <frantisekz> .hello2
16:04:25 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:04:33 <jforbes> .hello2
16:04:34 <zodbot> jforbes: jforbes 'Justin Forbes' <jforbes@redhat.com>
16:04:38 <frantisekz> coremodule: feel free to make me a secretary :)
16:04:41 <davdunc[m> .hello2
16:04:41 <zodbot> davdunc[m: Error: Missing "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.
16:04:51 <coremodule> #chair frantisekz lruzicka nielsenb
16:04:51 <zodbot> Current chairs: coremodule frantisekz lruzicka nielsenb
16:05:00 <coremodule> #info frantisekz will act as secretary.
16:05:03 <coremodule> Thanks frantisekz
16:05:06 <coremodule> frantisekz++
16:05:06 <zodbot> coremodule: Karma for frantisekz changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:05:09 <davdunc> .hello2
16:05:10 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:05:26 <coremodule> Boilerplate inbound!
16:05:30 <coremodule> #topic Introduction
16:05:30 <coremodule> Why are we here?
16:05:30 <coremodule> #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:05:30 <coremodule> #info We'll be following the process outlined at:
16:05:31 <coremodule> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:32 <coremodule> #info The bugs up for review today are available at:
16:05:34 <coremodule> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:36 <coremodule> #info The criteria for release blocking bugs can be found at:
16:05:38 <coremodule> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:05:40 <coremodule> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
16:05:42 <coremodule> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
16:05:45 <coremodule> Today we have:
16:05:49 <coremodule> #info 8 Proposed Blockers
16:05:58 <coremodule> #info 1 Proposed Freeze Exceptions
16:06:17 <coremodule> #topic (2063410) Printer setting: can't scroll media size list
16:06:17 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063410
16:06:17 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/659
16:06:17 <coremodule> #info Proposed Blocker, gnome-control-center, NEW
16:06:18 <coremodule> #info Ticket vote: FinalBlocker (+4,0,-1) (+bcotton, +kparal, +lruzicka, +catanzaro, -nielsenb)
16:06:19 <coremodule> #info Ticket vote: FinalFreezeException (+3,0,-1) (+geraldosimiao, +catanzaro, +imsedgar, -nielsenb)
16:07:17 <coremodule> This is +4 blocker in blockerbugs, but which criterion should we file it under?
16:07:34 <nielsenb> Basic functionality? Or real printer?
16:08:27 <frantisekz> +1 FB
16:08:41 <frantisekz> I'd say it considerably breaks the real printer criterion
16:09:02 <coremodule> I am thinking a conditional violation of "Printing must work in release-blocking desktops on at least one printer using each of the following drivers:"
16:09:19 <nielsenb> I would say technically printing works on "at least one printer", because I can use mine
16:09:33 <nielsenb> But for anyone that needs to change paper size, it's pretty broken
16:10:04 <frantisekz> coremodule: wording seems okay for me
16:10:06 <lruzicka> I would rather use the Basic Functionality ... printing is not hindered by this, but the experience is unpleasant
16:10:28 <Eighth_Doctor> .hello ngompa
16:10:29 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:10:39 <lruzicka> so it is basically Gnome-Control-Center - basic functionality
16:10:40 <nielsenb> Well, if you can't figure out how to set your paper size correctly, you won't be able to print in any meaninful way
16:10:44 <SeanM[m]> .hello se-sm-ca
16:10:45 <zodbot> SeanM[m]: Sorry, but user 'se-sm-ca' does not exist
16:10:56 <SeanM[m]> .hello seaninspace
16:10:57 <zodbot> SeanM[m]: seaninspace 'None' <seanmottles@posteo.net>
16:11:30 <coremodule> lruzicka, this one?
16:11:31 <coremodule> https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria#Printing
16:11:44 <lruzicka> nielsenb, I bet the default paper size will be used when you try printing, so it will work. But the settings cannot be done an easy way.
16:12:05 <nielsenb> But if the default is wrong?
16:12:18 <lruzicka> coremodule, this one https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality
16:12:43 <lruzicka> nielsenb, how probably it is, that the printer sends out an unusable paper size to the computer by default?
16:12:50 <kparal> The printing criterion is fine, because in printing dialogs there is no problem
16:12:52 <frantisekz> I'd stay with the printer criterion, it doesn't feel right to get this in under basic criterion
16:12:55 <kparal> Just setting the defaults sucks
16:13:03 <nielsenb> But for legacy, no IPP printers
16:13:09 <nielsenb> You get whatever the PPD default is
16:13:20 <lruzicka> nielsenb, IPP will not be default in F36
16:13:41 <nielsenb> It is for printers that only support IPP
16:13:46 <nielsenb> I believe
16:13:49 <kparal> lruzicka: IPP works out of the box for network printers
16:13:55 <nielsenb> Has been since IPP has been supported in CUPS
16:13:57 <kparal> just ipp-usb will not be installed by default
16:13:59 <lruzicka> kparal, I am not saying it does not
16:14:28 <nielsenb> Anyway, this all feels a little academic, I'm okay with basic functionality
16:14:34 <lruzicka> +1
16:15:45 <coremodule> proposed #agreed 2063410 – This is accepted as a conditional violation of the following Beta criterion: “Printing must work in release-blocking desktops on at least one printer available to those performing validation testing.”
16:15:55 <frantisekz> ack
16:16:14 <lruzicka> I still do not think.
16:17:05 <kparal> I think the other criterion is better, but I don't mind that much
16:17:08 <kparal> ack
16:17:17 <nielsenb> I'm okay with either I guess
16:17:19 <nielsenb> ack
16:17:37 <lruzicka> ack, if you want it
16:18:16 <coremodule> for brevity's sake, we'll go with this. If you want to state your case in-bug lruzicka we can talk about it there
16:18:22 <coremodule> #agreed 2063410 – This is accepted as a conditional violation of the following Beta criterion: “Printing must work in release-blocking desktops on at least one printer available to those performing validation testing.”
16:18:39 <coremodule> #topic (2071394) Connecting/disconnecting an external monitor switches GNOME to the login screen
16:18:39 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2071394
16:18:39 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/713
16:18:39 <coremodule> #info Proposed Blocker, gnome-shell, NEW
16:18:39 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-2) (+lruzicka, -kparal, -catanzaro)
16:19:17 <nielsenb> I wonder if this is related to the "Possible regression in GNOME..." discussion going on in Devel
16:19:24 <lruzicka> coremodule, no need to waste time on different wording, if you feel it differently
16:19:41 <nielsenb> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2J62APXU2GSC6HN3DQO2MIKVUPR4235D/
16:19:58 <nielsenb> _Something_ seems a little borked with Gnome and display changes
16:20:44 <frantisekz> doesn't sound like a blocker for me, -1 FB, +1 FE
16:21:21 <nielsenb> Yeah, I don't think I would block on it
16:21:34 <nielsenb> But it sounds annoying, as is the getting booted issue in VMs
16:21:40 <lruzicka> well, it does for me, because anytime I forget to switch on my external display, I will be moved to GDM - I do not see this as an ideal behaviour for an operating system.
16:21:48 <coremodule> I agree, it's ugly but doesn't cause data loss per kparals comment, -1 blocker, +1 Final FE
16:22:08 <frantisekz> it's not ideal, but what criterion does it break?
16:22:52 <frantisekz> I mean... it could be feature, if somebody evil connects a secret monitor to your laptop/pc... :D
16:22:57 <kparal> lruzicka: but this is not the "ideal behavior meeting" 🙂
16:23:08 <jforbes> I am inclined to to agree on the feature aspect
16:23:10 <kparal> sure, in annoys me as well
16:23:15 <kparal> s/in/it/
16:23:18 <nielsenb> Can it be? That meeting sounds like it would longer
16:23:32 <nielsenb> :D
16:23:36 <jforbes> it actually seems useful in some contexts, though it seems like it should be switchable if it was intentional
16:23:46 <coremodule> nielsenb, only if you buy the donuts
16:24:12 <lruzicka> frantisekz, https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Dual_monitor_setup
16:24:16 <nielsenb> I only have capital Os rendered in your IRC font of choice
16:24:58 <jforbes> lruzicka: it is correctly shown, it just gets locked if one of them changes state right?
16:25:04 <frantisekz> lruzicka : how does this bug break the criterion?
16:25:55 <kparal> actually, the session might not get locked, just switched. So there could be some slight security issue. But I'd need to verify
16:26:06 <kparal> either way, I don't think it would be a blocker
16:26:15 <lruzicka> frantisekz, it is not correctly displayed in the moment
16:26:41 <frantisekz> how? the criterion doesn't say what's correct.. this can be the correct way
16:26:47 <kparal> lruzicka: it is displayed correctly, just not the content that you want/expect
16:26:52 <frantisekz> I mean... I understand where you're coming from
16:26:57 <kparal> displayed = pixels are shown
16:27:21 <kparal> it has the right layout, resolution, everything
16:27:36 <lruzicka> kparal, I really "love" the uselessness of twisting the meanings to advocate for a view
16:28:14 <nielsenb> The criteria also doesn't really mention _when_ correct happens
16:28:19 <lruzicka> if I expect to be seeing something, and it is not, then it is not correctly displayed
16:28:23 <nielsenb> If somebody would like to bend it that way instead
16:28:32 <kparal> well I understand the purpose of the criterion quite differently than you  do, apparently 🙂
16:28:34 <nielsenb> It is correct, after you turn both your monitors on and log in again
16:28:45 <coremodule> \
16:28:59 <kparal> I'm understanding the criterion more like a hardware-level criterion
16:29:24 <coremodule> we could also punt for more info to give time to investigate any security issues that the bug might bring up
16:29:40 <kparal> not that the OS does exactly what you expect at all times, including session locking
16:29:41 <coremodule> although, I'm inclined to believe that any security issue would be minimal
16:30:13 <lruzicka> I tend to see it from the users's perspective, but if the majority is against, let's dismiss it then and move forward
16:30:17 <kparal> well I can test it in 30 seconds
16:30:37 <coremodule> kparal, do you mind? we can wait...
16:31:18 <coremodule> lruzicka, I see your point, "from the user's perspective"
16:31:21 <kparal> ok, the session doesn't get locked
16:31:31 <coremodule> alright, so lets get a final vote count
16:31:45 <kparal> ctrl+alt+f2 gets you back without providing a password
16:31:45 <nielsenb> Is that more, or less, desirable?
16:31:51 <kparal> so if the user got confused and walked away, you could get to their session until the screensaver kicks in
16:31:59 <nielsenb> Gross
16:32:10 <kparal> I still think that the security impact is quite low, though
16:32:18 <coremodule> kparal, but the whole time the login screen is being shown on that monitor?
16:32:40 <lruzicka> yeah, if the computer looks like locked, nobody is going to try and hit Ctrl-Alt-F2
16:32:48 <lruzicka> if we do not make it public
16:32:52 <nielsenb> Right
16:33:04 <nielsenb> Wonder if that applies to the VM bug too
16:33:10 <lruzicka> which we will do and warn about it in advance
16:33:19 <lruzicka> in common bugs
16:33:23 <kparal> lruzicka: hey, I'm well known for heavily defending our poor general users! I just think that in this case it's not a blocker material, because very little harm gets done (if any)
16:33:47 <nielsenb> Does the user get reunited with the original session after logging in?
16:33:53 <lruzicka> nielsenb, yes
16:33:58 <nielsenb> Okay
16:34:02 <nielsenb> -1 FinalBlocker
16:34:04 <nielsenb> +1 FinalFE
16:34:09 <kparal> the session doesn't look "locked", it's not the usual locked screen. It's gdm, as if you used "switch user".
16:34:34 <lruzicka> kparal, what happens if you log in again with the same credentials?
16:34:49 <lruzicka> kparal, do you arrive into the same session or a new one?
16:34:58 <kparal> you go back to your session, as I described in the bug report
16:35:19 <kparal> an in my explanation why I give it -1
16:35:23 <kparal> s/an/and/
16:36:30 <kparal> https://pagure.io/fedora-qa/blocker-review/issue/713#comment-790267
16:36:35 <coremodule> proposed #agreed 2071394 – RejectedBlocker AcceptedFreezeException - This is an ugly bug, but we don’t think it violates the blocker criteria as stated and agree that the impact it has is minimal. We do grant an FE though as it would be nice to have if a fix were available.
16:36:50 <lruzicka> ack
16:36:56 <frantisekz> ack
16:37:01 <nielsenb> ack
16:37:12 <coremodule> #agreed 2071394 – RejectedBlocker AcceptedFreezeException - This is an ugly bug, but we don’t think it violates the blocker criteria as stated and agree that the impact it has is minimal. We do grant an FE though as it would be nice to have if a fix were available.
16:37:12 <kparal> ack
16:37:23 <coremodule> #topic (2066528) Cannot print except when rebooting computer after upgrade from F35 -> after recommended manual intervention, now cannot print except after turning off printer and then printing a blank page in LibreOffice
16:37:23 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2066528
16:37:23 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/696
16:37:23 <coremodule> #info Proposed Blocker, hplip, NEW
16:37:23 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-1) (+kparal, -lruzicka)
16:37:45 <nielsenb> No ipp-usb by default anymore, right?
16:37:51 <nielsenb> So this shouldn't happen in final?
16:38:06 <frantisekz> yeah, if I understand it right
16:38:22 <nielsenb> So we can pretend we didn't see this? :)
16:38:28 <kparal> please read https://bugzilla.redhat.com/show_bug.cgi?id=2066528#c49
16:39:01 <nielsenb> So, freeze exception?
16:39:08 <kparal> nielsenb: no pretending, this time
16:39:31 <nielsenb> And also a note that this is ugly enough that it should have a formal change proposal, and maybe a test day or two, next cycle?
16:39:39 <kparal> we can drop the blocker status once updates are stable, though
16:40:18 <kparal> freeze exception is not enough this time, I believe. FEs don't need to be granted, they don't block release.
16:40:20 <frantisekz> queued stable kparal
16:40:54 <kparal> frantisekz: ok, but not enough 🙂
16:40:54 <frantisekz> nielsenb sounds right!
16:41:02 <kparal> also, even if this is stable, we actually need to verify it
16:41:07 <frantisekz> yeah, it should make it before the freeze
16:41:13 <frantisekz> yes, ofc
16:41:41 <kparal> in that case we can make a punt and hope if makes it in before freeze
16:42:03 <kparal> (it was not queued stable an hour ago)
16:42:03 <kparal> I think
16:42:51 <frantisekz> I mean... there shouldn't be much to verify https://src.fedoraproject.org/rpms/cups/c/bae21bb3a279dca38a7bfeb08029b6c9a32c1775?branch=rawhide , it just can't be broken (tm :D )
16:43:07 <kparal> haha
16:43:44 <coremodule> punt, or accept as blocker? I'm good with either. Blocker would ensure the fix gets where it needs to go in time, but like frantisekz said, it'll most likely make it before freeze.
16:43:58 <kparal> frantisekz: this one is not pending stable: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5eac55ee86
16:44:14 <nielsenb> I guess I would like to see it be a blocker for bookkeeping?
16:44:21 <frantisekz> yeah, make it a blocker
16:44:29 <coremodule> yeah, I think I agree. +1 blocker
16:44:34 <frantisekz> kparal: gimme a sec, I'll make it pending stable :P
16:44:39 <nielsenb> +1 FinalBlocker
16:44:47 <lruzicka> +1 FinalBlocker
16:44:47 <frantisekz> +1 FB
16:46:10 <kparal> frantisekz: that's cheating and I'll get your privileges revoked! 😉
16:46:41 <frantisekz> :D
16:46:50 <coremodule> proposed #agreed 2066528 – AcceptedBlocker – We are accepting this as a blocker as a violation of the following criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." Note that it shouldn’t be too much longer before the fix lands in stable.
16:46:57 <nielsenb> ack
16:46:58 <frantisekz> ack
16:47:15 <lruzicka> ack
16:47:28 <coremodule> #agreed 2066528 – AcceptedBlocker – We are accepting this as a blocker as a violation of the following criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." Note that it shouldn’t be too much longer before the fix lands in stable.
16:47:39 <coremodule> #topic (2053729) RPi4 wired network fails - eth0 (bcmgenet): transmit queue 1 timed out
16:47:39 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2053729
16:47:39 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/709
16:47:39 <coremodule> #info Proposed Blocker, kernel, POST
16:47:40 <coremodule> #info Ticket vote: FinalBlocker (+2,0,-1) (+nielsenb, +lruzicka, -bcotton)
16:48:40 <coremodule> +1 Final Blocker, although what's supported and what's not on ARM is difficult to define. I don' think we'd actually block the release if it came down to this bug.
16:48:59 <coremodule> The fix should also land later this week, so it should be a moot point.
16:49:22 <jforbes> Here's the thing with kernel. 5.17.1 was never intended to be the release kernel. I wouldn't push it to F35 either.  In fact the testweek build for F35 has a number of critical bug fixes not in the F36 build
16:49:36 <frantisekz> -1 FB I guess, or is rpi4 supported platform now?
16:49:52 <frantisekz> in any case, +1 FE
16:50:11 <coremodule> frantisekz, no, ARM SIG agreed to take hardware blockers on a case-by-case basis
16:50:19 <coremodule> like we do with x86
16:50:41 <jforbes> It is not officially supported in that desktop acceleration does not work.  But a large number of RPi 4 users are headless, and no network makes it much harder to update
16:51:03 <nielsenb> Which makes for a bit of a frustrating user story in the ARM space, "Is my board supported?" "It's complicated..."
16:51:22 <frantisekz> mhm, in any case, I think FE would do the job just fine, arm sig can say otherwise? wdyt pwhalen?
16:51:34 <nielsenb> I agree
16:51:37 <nielsenb> +1 FreezeException
16:51:52 <jforbes> But the F36 kernel also can't mount QNAP nas devices in nfs without manual intervention, doesn't boot on some aarch64 boards (not sure if they are supported), and has a config for AMD PState that is different than .2 will
16:52:26 <jforbes> Plus a couple of CVEs, etc. Basically, shipping .1 isn't an option
16:52:44 <pwhalen> +1 FreezeException
16:54:17 <coremodule> proposed #agreed 2053729 – AcceptedFreezeException – We are delaying the classification of this bug as a blocker but accepting it as an FE. The fix in the kernel should land later in the week, which should make this a moot point.
16:54:25 <nielsenb> ack
16:54:28 <lruzicka> ack
16:54:31 <pwhalen> ack
16:54:47 <coremodule> #agreed 2053729 – AcceptedFreezeException – We are delaying the classification of this bug as a blocker but accepting it as an FE. The fix in the kernel should land later in the week, which should make this a moot point.
16:55:02 <coremodule> #topic (2068773) systemd-oomd kills rpm-ostree when installing a package on Fedora IoT 36 on the Raspberry Pi Zero 2 W
16:55:02 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2068773
16:55:02 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/703
16:55:02 <coremodule> #info Proposed Blocker, libdnf, NEW
16:55:03 <coremodule> #info Ticket vote: FinalBlocker (+0,0,-4) (-jmracek, -nielsenb, -lruzicka, -frantisekz)
16:56:59 <lruzicka> So I am still -1
16:57:41 <coremodule> pbrobinson, pwhalen, any thoughts here? It seems like it's not an ostree or RAM issue, but perhaps in DNF. We have -4 votes already, but just want to get your thoughts before we finalize.
16:58:53 <nielsenb> Again, without an explicit "this is supported", it's really hard to call it a blocker
16:59:23 <frantisekz> yeah, also, the affected platform is stated as "not supported"
16:59:27 <nielsenb> Right
16:59:59 <frantisekz> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Supported_Hardware ; "Initial support for the new Zero 2W is under review."
17:00:05 <pwhalen> I think it might work with a swapfile, as a possible workaround. Not ideal, but we've hit this issue in cloud instances as well
17:00:25 <frantisekz> btw, shouldn't zram help in these cases? or is it still not enough even with it?
17:01:29 <pwhalen> It doesnt help, I have a system with 256M I use a swapfile and it works.
17:02:18 <coremodule> proposed #agreed 2068773 – RejectedBlocker – The RPi Zero 2W is explicitly stated that it is not currently supported by Fedora ARM, so we reject this bug as a blocker.
17:02:19 <frantisekz> hmm, sounds like a common bug with described swap workaround would do then?
17:02:24 <frantisekz> ack
17:02:28 <nielsenb> ack
17:02:56 <lruzicka> ack + common bugs
17:03:11 <coremodule> #agreed 2068773 – RejectedBlocker – The RPi Zero 2W is explicitly stated that it is not currently supported by Fedora ARM, so we reject this bug as a blocker.
17:03:22 <coremodule> #topic (2071226) anaconda failed to start a live session on  a VM with QXL video driver (Virtio works OK)
17:03:22 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2071226
17:03:22 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/710
17:03:22 <coremodule> #info Proposed Blocker, mutter, NEW
17:03:23 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-1) (+lruzicka, -nielsenb)
17:04:56 <kparal> see my summary https://pagure.io/fedora-qa/blocker-review/issue/710#comment-790277
17:05:04 <nielsenb> Really wish I knew why I'm unable to repro these QXL issues
17:05:23 <kparal> it's a race condition
17:05:32 <frantisekz> I am thinking about asking the virt-manager maint about backporting QXL > virtio change
17:05:38 <frantisekz> so we could forget about these...
17:06:00 <kparal> there might be more to it, but even that race is enough to show up just sometimes and somewhere
17:06:30 <kparal> frantisekz: that would help. But wouldn't affect existing VMs, if somebody reuses it instead of creating new. Just a note.
17:06:55 <kparal> it would be enough to work around the blocker, though, I believe
17:07:07 <frantisekz> yeah, it'd be common bug material then
17:08:02 <frantisekz> also, I'd say virt-manager users are more like power users, who would be able to checkup common bugs/ change the setting, boxes use virtio for a long time by default afaik
17:08:43 <kparal> I think virt-manager is even quite older on F34, so there might be some reasons why the default would be problematic to switch. Just speculating.
17:09:28 <kparal> either way, we need to start poking upstream about this
17:09:45 <kparal> frantisekz: asking Cole would be a good thing to do asap
17:10:15 <frantisekz> yep, any way to reach him fastest? gchat/irc?
17:10:34 <kparal> no idea, shoot him an email
17:11:31 <frantisekz> will do
17:11:36 <kparal> so, about this, it would be great if lruzicka could confirm that the cases where he had "stuck/hung" issues were the same as the other qxl bug
17:11:55 <kparal> in that case we could consider this bug to only cover autologin failure
17:12:01 <kparal> and vote on that
17:12:37 <kparal> we can assume that this is the case and vote about it right now
17:13:02 <kparal> or just be on the safe side and vote on the system stuck issue as well, i.e. make it a blocker
17:13:12 <kparal> no real preferences here
17:13:23 <coremodule> lruzicka, are you able to test during the meeting?
17:13:25 <coremodule> as in right now?
17:13:43 <lruzicka> coremodule, I can try.
17:14:11 <coremodule> that would be helpful in making a decision...
17:14:15 <coremodule> lruzicka++
17:14:15 <zodbot> coremodule: Karma for lruzicka changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:14:20 <kparal> lruzicka: if the system looks stuck, but Escape closes the welcome dialog (and no other input works), then it's the other qxl issue
17:18:12 <lruzicka> kparal, with a newly created VM using QXL I am getting the same behaviour as I described in lnie's bug (the one we discuss right now)
17:18:55 <kparal> well, that's expected, no?
17:19:02 <lruzicka> the VM is not stuck, but autologin does not work, when I click on the Live User login button, it takes me to Live session and I can start Anaconda.
17:19:03 <kparal> so what happens if the system gets stuck?
17:19:51 <lruzicka> when I tried in the afternoon, it got mostly stuck after trying to login . in that case I was having an empty GDM screen
17:20:10 <kparal> aha, so I misunderstood your description
17:20:13 <lruzicka> when I tried now, it did not get stuck
17:20:22 <kparal> after you clicked Login, you only saw a gray screen?
17:20:29 <kparal> or what exactly did happen?
17:20:51 <lruzicka> The login button went away, the screen remained GDMish
17:21:07 <lruzicka> but did not respond to clicks anywhere
17:21:18 <kparal> ok, that at least visually looks different from my qxl issue
17:21:38 <kparal> so in that case I'd propose to accept this as a separate blocker
17:21:41 <frantisekz> (FYI), virt-manager maint agrees with changing QXL > virtio in f35, I'll make a pr, maybe after this meeting, more probably tomorrow
17:22:01 <kparal> frantisekz: cool. What about F34?
17:22:03 <kparal> Do we block on that?
17:22:07 <frantisekz> we don't afaik
17:22:33 <kparal> The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release.
17:22:41 <kparal> https://fedoraproject.org/wiki/Basic_Release_Criteria#Guest_on_current_stable_release
17:22:53 <kparal> So, is "current stable" the latest stable?
17:22:57 <frantisekz> is f34 current stable?
17:22:58 <frantisekz> heh :D
17:23:07 <kparal> Adam would know 😀
17:23:20 <lruzicka> according to this definition, F34 should not be "current stable"
17:23:34 <kparal> Well I can see it both ways
17:23:42 <kparal> Currently F34 and F35 are stable
17:23:45 <frantisekz> amazing, I'll bisect/educatedly guess the correct commit to backport and make changes
17:23:49 <nielsenb> F34 is supported for ~4 weeks after F36 launches
17:24:02 <lruzicka> yeah, sort of ... it is still supported now
17:24:11 <nielsenb> "Supported"
17:24:12 <frantisekz> it's not current... :D
17:24:14 <nielsenb> Needs more quotes
17:24:22 <coremodule> proposed #agreed 2063156 – AcceptedBlocker – After some in-meeting testing by lruzicka, we are under the impression that this is a different bug than 2063156. We accept it as a blocker as it violates this criterion: “The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release.“
17:24:25 <kparal> I'll ask Adam
17:24:40 <frantisekz> ack
17:24:41 <lruzicka> ack
17:24:43 <kparal> ack
17:24:50 <nielsenb> ack
17:24:53 <coremodule> #agreed 2063156 – AcceptedBlocker – After some in-meeting testing by lruzicka, we are under the impression that this is a different bug than 2063156. We accept it as a blocker as it violates this criterion: “The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release. “
17:24:57 <coremodule> thanks for the testing lruzicka
17:25:08 <coremodule> #topic (2057563) The About button sends Discover into loop and the application stops responding.
17:25:08 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2057563
17:25:08 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/627
17:25:08 <coremodule> #info Accepted Blocker, plasma-discover, NEW
17:25:21 <coremodule> whoos
17:25:23 <coremodule> whoops
17:25:33 <coremodule> #undo
17:25:33 <zodbot> Removing item from minutes: INFO by coremodule at 17:25:08 : Accepted Blocker, plasma-discover, NEW
17:25:40 <coremodule> #undo
17:25:40 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fccad600da0>
17:25:44 <coremodule> #undo
17:25:44 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fccad5f4978>
17:25:51 <coremodule> #undo
17:25:51 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fccad82c470>
17:26:04 <lruzicka> coremodule, no problem
17:26:07 <coremodule> #topic (2071343) [tr_TR] curl: (35) error:03000072:digital envelope routines::decode error with LANG=tr_TR.utf8
17:26:07 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2071343
17:26:07 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/712
17:26:07 <coremodule> #info Proposed Blocker, openssl, NEW
17:26:07 <coremodule> #info Ticket vote: FinalBlocker (+2,0,-1) (+nielsenb, +thunderbirdtr, -catanzaro)
17:26:09 <coremodule> #info Ticket vote: FinalFreezeException (+4,0,-0) (+nielsenb, +lruzicka, +thunderbirdtr, +frantisekz)
17:28:09 <nielsenb> So, yeah, I was called out for not having a locale specific criterion at hand
17:28:14 <nielsenb> Does such a thing exist?
17:28:55 <nielsenb> It feels a little like basic functionality, like, you can select Turkish in Anacdonda, and then not be able to use anything that uses OpenSSL3?
17:29:48 <kparal> well, we don't block on curl. But rpm-ostree is blocking in IoT, right?
17:30:03 <coremodule> kparal, yeah
17:30:48 <nielsenb> Isn't curl just an easy reproducer?
17:30:49 <kparal> in that case it violates https://fedoraproject.org/wiki/Basic_Release_Criteria#rpm-ostree_requirements for Turkish, it seems
17:31:09 <kparal> nielsenb: sure, I know. We need to demonstrate a real impact.
17:31:27 <lruzicka> there sure are Turkish Fedora users
17:31:53 <nielsenb> https://github.com/fedora-silverblue/issue-tracker/issues/241
17:31:57 <nielsenb> From there, DNF broke as well
17:32:03 <nielsenb> https://github.com/fedora-silverblue/issue-tracker/issues/241#issuecomment-1086789609
17:32:05 <nielsenb> Better link
17:32:22 <nielsenb> Actually, no
17:32:29 <nielsenb> Reading comprehension, I should get some
17:32:52 <kparal> looks like +1 Final blocker to me
17:33:25 <OnuralpSezer[m]1> nielsenb: For me it is very easy and that also break dnf/git/flatpak and others too
17:33:40 <lruzicka> +1 FinalBlocker then
17:33:46 <coremodule> +1 Final Blocker
17:33:51 <nielsenb> +1 FinalBlocker
17:34:06 <OnuralpSezer[m]1> +1 FinalBlocker
17:34:16 <frantisekz> +1 FB
17:35:53 <coremodule> proposed #agreed 2071343 – AcceptedBlocker – This bug impacts an IoT users ability to interact with ostree using “rpm-ostree” and is thus a violation of the IoT Edition rpm-ostree requirements. We grant this bug blocker status.
17:36:01 <nielsenb> ack
17:36:13 <lruzicka> ack
17:36:22 <frantisekz> ack
17:36:34 <coremodule> #agreed 2071343 – AcceptedBlocker – This bug impacts an IoT users ability to interact with ostree using “rpm-ostree” and is thus a violation of the IoT Edition rpm-ostree requirements. We grant this bug blocker status.
17:36:42 <coremodule> #topic (2070764) selinux-policy is preventing flatpak from updating / installing  / removing flatpaks
17:36:42 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2070764
17:36:42 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/702
17:36:42 <coremodule> #info Proposed Blocker, selinux-policy, NEW
17:36:42 <coremodule> #info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +lruzicka)
17:37:52 <frantisekz> +1 FB, just the criterion, do we offer flatpaks by default in gnome sw?
17:38:13 <kparal> my opinion is in both bugzilla and ticket review
17:38:16 <copperi[m]> It is tied to it
17:38:19 <kparal> I saw nobody else reproduce this
17:38:23 <kparal> and I couldn't
17:38:35 <lruzicka> frantisekz, yes Fedora Flatpaks
17:38:55 <lruzicka> frantisekz, and Flathub with Third Party repos
17:38:55 <coremodule> +1 punt for more testing, kparal couldn't reproduce this
17:39:09 <kparal> has anybody else tried?
17:39:10 <lruzicka> I am not having Flatpak issues either
17:39:26 <nielsenb> I'm trying to check, but gnome-software is being slow on this system
17:39:29 <lruzicka> but I have not tried to test the bug specifically, just installed some Flatpaks
17:39:34 <copperi[m]> I had this issue and got it fixed by removing old rules
17:40:08 <kparal> copperi: what do you mean by old rules?
17:40:59 <copperi[m]> semodule -X 200 -r snappy -r container  -X 300 -r my-chown -X 400 -r my-chown -r my-systemctl
17:41:20 <copperi[m]> those my-chown where done somewhere in the past
17:41:43 <kparal> for us selinux ignorants - does this mean you have modified the system defaults and had to reset it back?
17:43:10 <copperi[m]> I removed those 4 packages I got complaints with while trying to update flatpak.
17:43:26 <copperi[m]> Then run dnf reinstall -y container-selinux
17:44:18 <kparal> Note that there IS something fishy going on with selinux and containers, nobody proposed it as a blocker yet:
17:44:18 <kparal> https://ask.fedoraproject.org/t/dnf-upgrade-of-some-packages-fail-after-upgrade-from-f35/20983
17:44:21 <copperi[m]> But I have seen error (bugzilla) with other rules as well
17:44:28 <kparal> but I'm not sure if it is related to this very bug report
17:44:37 <nielsenb> I'm leaning punt
17:44:49 <kparal> I'd also punt this
17:44:55 <nielsenb> But I do think our criteria should be updated to be more specific in regards to flatpak
17:44:58 <kparal> and we need to look into the other selinux + containers reports
17:45:28 <kparal> nielsenb: you can start a discussion on test list, send us some proposals/thoughts
17:45:33 <nielsenb> Yeah
17:45:37 <coremodule> proposed #agreed 2070764 – punt – Per kparal’s comment in-bug and lruzicka’s comment during the meeting, neither were able to reproduce this. We would like to have more widespread testing before we vote one way or the other on this bug, so we will punt for now.
17:45:46 <frantisekz> ack
17:45:47 <nielsenb> ack
17:46:05 <copperi[m]> ack
17:46:13 <coremodule> #agreed 2070764 – punt – Per kparal’s comment in-bug and lruzicka’s comment during the meeting, neither were able to reproduce this. We would like to have more widespread testing before we vote one way or the other on this bug, so we will punt for now.
17:46:16 <coremodule> okay
17:46:24 <coremodule> moving on to our single FE
17:46:33 <coremodule> #info moving onto proposed FE's
17:46:47 <coremodule> #topic (2071098) "Installing software" and other strings displayed during installation are untranslated
17:46:47 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2071098
17:46:47 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/715
17:46:47 <coremodule> #info Proposed Freeze Exceptions, anaconda, ASSIGNED
17:47:13 <lruzicka> I was asked by jkonecny to bring it up
17:47:23 <nielsenb> +1 FreezeException
17:47:25 <lruzicka> he has some problems to propose it
17:47:30 <lruzicka> +1 FE
17:47:44 <copperi[m]> +1 fe
17:48:33 <coremodule> proposed #agreed 2071098 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
17:48:39 <nielsenb> ack
17:48:54 <copperi[m]> ack
17:49:02 <kparal> hmm, didn't we have a criterion for this?
17:49:16 <frantisekz> ack
17:49:24 <kparal> oh yes we did! https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Installer_translations
17:49:35 <frantisekz> good catch
17:49:39 <kparal> "The installer must correctly display all sufficiently complete translations available for use. "
17:49:46 <coremodule> One or two translated strings not being displayed will not usually constitute a violation of this criterion (unless the ones missing are very important strings).
17:49:47 <kparal> "One or two translated strings not being displayed will not usually constitute a violation of this criterion (unless the ones missing are very important strings)."
17:49:54 <kparal> so.... how many? 😀
17:50:00 <kparal> this might well be a blocker
17:50:02 <coremodule> it's just one per the bug
17:50:14 <nielsenb> Bug says "and other" :)
17:50:15 <coremodule> https://bugzilla-attachments.redhat.com/attachment.cgi?id=1870004
17:50:28 <kparal> "The "Installing software" and other strings that are displayed next to the spinner"
17:51:14 <kparal> so let's make it +1FE and I'll sneakily propose it as a blocker, and perhaps it gets closed before the next blocker meeting
17:51:30 <kparal> and if it doesn't, we have to figure out how many strings are broken
17:51:30 <lruzicka> Does it say which language?
17:51:42 <lruzicka> I can take a look.
17:51:54 <kparal> nope
17:52:01 <coremodule> #agreed 2071098 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
17:52:42 <coremodule> alright, that's all the proposed bugs
17:52:58 <coremodule> #topic Open Floor
17:53:42 <frantisekz> guys, if you have some time, please give a https://bodhi.fedoraproject.org/updates/FEDORA-2022-c43760a865 try/karma it
17:54:03 <frantisekz> you can just grab packages from updates/testing, just qt-creator is different since the karma reset
17:54:13 <lruzicka> kparal, it looks like there are several strings when "Zahájit instalaci" is pressed.
17:54:25 <lruzicka> The comments above the progress bar are in English
17:54:36 <OnuralpSezer[m]1> frantisekz:  please take look kde-meeting If you can (please :)  )
17:55:07 <coremodule> thanks for sticking around kparal, even though you tried to go afk at the beginning of the meeting :)
17:55:19 <kparal> also, everyone, please help us completely fill out this
17:55:20 <kparal> https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Summary
17:55:47 <coremodule> I plan to do the aarch64 stuff later today
17:55:52 <kparal> coremodule: averted a few family crises, could stay, win
17:56:11 <coremodule> alright everyone, thanks for coming
17:56:16 <coremodule> #endmeeting