16:01:55 <adamw> #startmeeting F36-blocker-review
16:01:55 <zodbot> Meeting started Mon Mar 21 16:01:55 2022 UTC.
16:01:55 <zodbot> This meeting is logged and archived in a public location.
16:01:55 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:01:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:55 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:01:59 <adamw> #meetingname F36-blocker-review
16:01:59 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:02:01 <adamw> #topic Roll Call
16:02:13 <adamw> who's around for blocker fun times?
16:02:26 * coremodule is here, willing to act as secretary.
16:02:27 <nielsenb> I'm here
16:02:45 * lruzicka resides around
16:03:56 <adamw> tap tap is this bot working
16:04:00 <adamw> zodbot: hey
16:04:52 <adamw> nirik: i think the bot's on the fritz?
16:05:02 <nielsenb> The uprising has begun
16:06:11 <adamw> ooh, it's alive
16:09:07 <adamw> #chair cmurf nielsenb
16:09:07 <zodbot> Current chairs: adamw cmurf nielsenb
16:09:11 <adamw> #topic Introduction
16:09:15 <cmurf> .hello2
16:09:16 <zodbot> cmurf: cmurf 'Chris Murphy' <chris@cmurf.com>
16:09:40 <adamw> Why are we here?
16:09:43 <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:09:46 <adamw> #info We'll be following the process outlined at:
16:09:50 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:53 <adamw> #info The bugs up for review today are available at:
16:09:56 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:59 <adamw> #info The criteria for release blocking bugs can be found at:
16:10:02 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:10:05 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
16:10:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
16:10:22 <adamw> #info for Beta, we have:
16:10:29 <adamw> #info 1 Proposed Freeze Exceptions
16:10:41 <adamw> #info for Final, we have:
16:10:42 <adamw> #info 2 Proposed Blockers
16:10:52 <adamw> ...so it should be a short meeting unless stuff comes up
16:11:14 <adamw> #info coremodule will secretarialize
16:11:18 <adamw> so let's start with:
16:11:23 <adamw> #topic Proposed Beta freeze exception
16:11:32 <adamw> #topic (2061141) rpm --rebuilddb issue with /usr/lib/sysimage
16:11:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2061141
16:11:38 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/680
16:11:41 <adamw> #info Proposed Freeze Exceptions, selinux-policy, ON_QA
16:11:44 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+sgallagh)
16:11:49 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+sgallagh)
16:12:23 <cmurf> uhh hmmm
16:12:31 <cmurf> could this prevent upgrades from working?
16:12:34 <adamw> "This bug has a potential to cause problems with upgrades"
16:12:37 <adamw> i don't really see how?
16:12:42 <cmurf> i never ran into this problem in my testing
16:12:48 <adamw> rebuilding the RPM database isn't a typical operation.
16:12:49 <cmurf> is it recent?
16:12:51 <nielsenb> I don't see where that's mentioned?
16:12:56 <cmurf> well it has to be rebuilt on upgrade
16:13:00 <cmurf> it isn't just moved
16:13:17 <cmurf> actually it's not rebuilt on upgrade, it's rebuilt on the reboot following upgrade
16:13:38 <cmurf> Conan Kudo:  ^^
16:14:16 <adamw> yeah, i see that
16:14:54 <adamw> uh
16:15:06 <cmurf> i just don't know how i didn't run into it
16:15:11 <adamw> on another note, why does the migration script not at least remove the /var/lib/rpm/.migratedb file?
16:15:38 <adamw> does that not mean we leave it around forever and run rpmdb-migrate.service uselessly on every boot?
16:15:43 <adamw> it still appears to exist on my system
16:15:54 <cmurf> i'm not sure
16:16:06 <cmurf> does rpmdb-migrate.service run on every boot?
16:16:10 <cmurf> do you see it mentioned in the journal?
16:16:12 <adamw> the service shows as disabled, though...
16:16:26 <adamw> anyway, off-topic i guess.
16:16:27 <cmurf> i think it's a one shot and then gets disabled IIRC
16:17:10 <cmurf> i'm not sure what sets or consumes /var/lib/rpm/.migratedb
16:17:33 <adamw> so, um. i can see that in theory this could cause problems, but if it was, shouldn't it be causing...more problems?
16:17:59 <cmurf> I'm gonna have to do another clean install i guess
16:18:19 <cmurf> because on this f36 clean from feb does not have a /var/lib/rpm dir at all
16:18:20 <adamw> i should be able to get some logs from openqa
16:18:54 <cmurf> i thought there's supposed to be a symlink there, /var/lib/rpm points to /usr/lib/sysimage/rpm or something
16:19:32 <cmurf> >ls: cannot access '/var/lib/rpm': No such file or directory
16:21:00 <adamw> ugh, brb
16:23:12 * cmurf is tempted to use nightly branched 20220321 instead of beta rc
16:24:36 <cmurf> i'll use beta rc 1.3
16:24:47 <adamw> it shouldn't make a difference to this
16:24:48 <adamw> um
16:25:10 <adamw> i kinda feel like i want to vote provisional +1 beta fe then investigate this some more after the meeting and figure out what actually happens on upgrade
16:25:14 <cmurf> ok
16:25:20 <cmurf> +1 beta FE
16:25:33 <nielsenb> Yeah, I haven't noticed anything wrong in my use of F36
16:25:37 <adamw> in the openqa logs it sort of looks like the db rebuild service never actually runs
16:25:39 <nielsenb> But I'm a pretty boring user
16:25:46 <nielsenb> +1 BetaFE
16:25:49 <adamw> i see "RPM database rebuild was skipped because of a failed condition check (ConditionPathExists=/usr/lib/sysimage/rpm/.rebuilddb)"
16:26:01 <coremodule> +1 Beta FE
16:26:25 <adamw> ah
16:26:27 <adamw> ha
16:26:46 <cmurf> i wonder if the mv fails in the offline environment or if creating the .rebuilddb fails in the offline environment - due to the selinux issue
16:27:17 <cmurf> and thus the rebuild doesn't happen in the reboot that follows upgrade
16:27:18 <adamw> anyways, let's try and figure it out
16:27:22 <cmurf> yeah
16:28:15 <adamw> proposed #agreed 2061141 - AcceptedBetaFE - this is accepted provisionally while we check whether it actually does interfere with the intended move/rebuild of the RPM database on upgrade. If it does not we will re-vote, but we don't want to block the meeting on investigating that process
16:28:16 <lruzicka> +1 BFE
16:28:22 <lruzicka> ack
16:28:26 <nielsenb> ack
16:29:43 <coremodule> ack
16:30:04 <cmurf> ack
16:30:28 <cmurf> question: how different is dnf system upgrade from gnome-software's? i know both use libdnf
16:30:29 <adamw> #agreed 2061141 - AcceptedBetaFE - this is accepted provisionally while we check whether it actually does interfere with the intended move/rebuild of the RPM database on upgrade. If it does not we will re-vote, but we don't want to block the meeting on investigating that process
16:30:40 <adamw> cmurf: they should work the same once the reboot is triggered.
16:30:53 <cmurf> k
16:31:13 <adamw> #topic Proposed Final blockers
16:31:38 <adamw> #topic (2063969) Real cursor position is slightly offset from displayed position on Wayland in virtual machine (kde spin)
16:31:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063969
16:31:42 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/665
16:31:45 <adamw> #info Proposed Blocker, kwin, NEW
16:31:48 <adamw> #info Ticket vote: FinalBlocker (+2,0,-0) (+geraldosimiao, +nielsenb)
16:33:21 <adamw> we took this as a blocker for f35, so i guess i'm +1 for f36
16:33:25 <adamw> there's a patch upstream i'll backport later
16:33:40 <adamw> i'm also gonna propose this as beta fe and vote +1
16:33:53 <coremodule> sounds good to me
16:34:03 <coremodule> +1 Beta FE, +1 Final Blocker
16:34:33 <cmurf> +1 beta FE, +1 final blocker
16:34:42 <lruzicka> +1 beta FE, +1 final blocker
16:35:07 <nielsenb> Is BetaFE not automatically applied via final blocker?
16:35:13 <nielsenb> +1 BetaFE
16:36:02 <adamw> nielsenb: no, the two don't necessarily follow
16:36:19 <nielsenb> Good to know
16:36:59 <adamw> proposed #agreed 2063969 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is a significant problem in using virtual machines with a release-blocking desktop; we accepted an identical bug as blocker for F35 Final. As it will affect the KDE live we would also like to fix it in Beta if possilbe
16:37:08 <adamw> er, i'll fix the spelling of 'possible' :D
16:37:18 <coremodule> ack
16:37:28 <nielsenb> ack
16:38:19 <cmurf> ack
16:38:54 <adamw> #agreed 2063969 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is a significant problem in using virtual machines with a release-blocking desktop; we accepted an identical bug as blocker for F35 Final. As it will affect the KDE live we would also like to fix it in Beta if possible
16:39:01 <adamw> #topic (2063156) Workstation Live is frozen in a VM with QXL video driver (Virtio works OK)
16:39:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063156
16:39:12 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/656
16:39:13 <adamw> #info Proposed Blocker, mutter, NEW
16:39:32 <adamw> this is probably bad enough to be a final blocker for me...
16:39:40 <cmurf> i haven't crashed with mutter-42.0-2.fc36.x86_64
16:39:40 <adamw> at least if it's reproducible...
16:39:48 <cmurf> but oh nvm different bug
16:40:03 <nielsenb> I feel like it needs to be a blocker, there's no way to fix it after launch, is there?
16:40:05 <adamw> i did try reproducing it and failed, but i didn't do it with a fresh vm
16:40:21 <nielsenb> I'm rerunning my test by the way, virtio just seems broken on the machine I'm testing with
16:40:35 <nielsenb> But I cannot seem to recreate the issue with QXL and user mode
16:41:00 <cmurf> if f36 beta is freezing as guest on an f35 host using qxl (which is the default) then yeah that's pretty blockery
16:41:12 <cmurf> even if the work around is pretty straight forward
16:41:32 <cmurf> but does this block qxl in f36? or on f35?
16:42:19 <adamw> cmurf: "if f36 beta is freezing as guest on an f35 host using qxl (which is the default) then yeah that's pretty blockery" - this seems to be what kparal is suggesting
16:42:22 <adamw> i don't think we know where the fix would be yet
16:43:20 <cmurf> and also i wonder if it's still happening with the guest kernel full up to date, i.e. a 4.17.0 kernel
16:43:56 <cmurf> or heck even kernel-5.17.0-0.rc8.123.fc36 i guess
16:44:12 <nielsenb> I still need to try a non-user session
16:44:26 <nielsenb> Really though, can't we just say blocker, and if it doesn't reproduce on new composes, great?
16:44:31 <cmurf> oh that's right it's only happening with user session
16:44:32 * kparal lurks
16:44:48 <kparal> cmurf: not "only", just more often
16:45:01 <cmurf> ew so it's also racy
16:45:13 <kparal> for me
16:46:12 <cmurf> hmmm maybe we need a blocker exception for "easy work around available and documented in common bugs"
16:46:38 <nielsenb> Yeah, that's the only reason I didn't just vote blocker, it feels easy to work around
16:46:43 <adamw> we can already consider that for conditional violations
16:47:18 <adamw> https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F
16:48:05 <cmurf> i can get on board
16:48:28 <cmurf> not least of which is the default is changing to virtio anyway
16:48:58 <kparal> this should be waived only if it is hard to fix, not because it is easy to work around
16:49:15 <cmurf> it may not be hard to fix but might be hard to isolate
16:49:29 <cmurf> right now we don't know what to fix
16:49:39 <adamw> i kinda feel like i'd like a bunch of people to try this and see just how common it is
16:50:01 <nielsenb> I'm trying! The machine is question is just a little creaky
16:50:25 <kparal> cmurf: that's also hard to fix 🙂
16:50:41 <cmurf> fair
16:51:26 <adamw> i can try this on my backup laptop after the meeting
16:51:31 <adamw> since this is a final proposal, 'punt' is a choice
16:51:41 <adamw> might be my favorite choice at this point
16:52:17 <nielsenb> Poor thing has been punted so many times
16:52:56 <nielsenb> But I could be on team punt
16:55:57 <adamw> anyone else?
16:56:40 <coremodule> +1 punt for testing, I can test after the meeting
16:56:46 <coremodule> and report in-bugh
16:56:46 <cmurf> +1 punt
16:56:52 <nielsenb> +1 punt
16:58:14 <lruzicka> -1 blocker
16:58:43 <lruzicka> +1 fe
16:59:21 <cmurf> +1 beta fe is ok
16:59:45 <adamw> i think it's already bet afe.
16:59:53 <cmurf> ha ok
17:00:23 <adamw> oh, no, it isn't
17:00:44 <adamw> i guess i'd be +1 beta fe in principle, though seems unlikely a fix is gonna show up today
17:00:51 <cmurf> right
17:01:04 <cmurf> but no complaints about miracles or gift horses
17:01:23 <cmurf> even if they're as common as unicorns
17:02:33 <lruzicka> cmurf, they are pretty common where I live: https://www.mbenzin.cz/Ceny-benzinu-a-nafty/Nova-100566-Mikulov-Jihomoravsky-kraj/Retezce/Unicorn
17:02:45 <adamw> heh
17:03:58 <cmurf> that's around $8 a gallon, and Californian's are cranky about $5.70
17:04:05 <adamw> proposed #agreed 2063156 -punt (delay decision) on Final blocker, AcceptedFreezeException (Beta) - it's still not clear how common this bug is, so we can't really make a Final blocker determination yet. We will try to test it further after the meeting. We do accept it as a Beta freeze exception, just in case the fix is in the client side and shows up soon
17:04:33 <nielsenb> Yeah, gas is still "cheap" in the US comparatively
17:04:41 <nielsenb> ack
17:04:49 <coremodule> ack
17:05:01 <cmurf> ack
17:05:12 <adamw> #agreed 2063156 -punt (delay decision) on Final blocker, AcceptedFreezeException (Beta) - it's still not clear how common this bug is, so we can't really make a Final blocker determination yet. We will try to test it further after the meeting. We do accept it as a Beta freeze exception, just in case the fix is in the client side and shows up soon
17:05:34 <adamw> #topic Open floor
17:05:42 <adamw> any other business? Any late proposals?
17:05:52 <nielsenb> Is smart card support just broken on F36?
17:05:58 <nielsenb> And if yes, does that matter?
17:06:03 <adamw> note, the candidate composes are bad, we are going to need a new one
17:06:07 <nielsenb> I guess I mean graphically via gnome
17:06:11 <adamw> so i'll try and pull in any FE fixes that make sense
17:06:17 <kparal> I hope I manage to file a blocker proposal today, I think I had a good one
17:06:22 <kparal> *have
17:06:24 <adamw> nielsenb: it's not blocking. i don't know if it's broken, i don't have a smart card reader.
17:06:35 <adamw> kparal: can we get a preview?
17:06:38 <nielsenb> https://bugzilla.redhat.com/show_bug.cgi?id=2060868#c11
17:06:40 <lruzicka> kparal, which one?
17:06:48 <cmurf> haha kparal
17:07:19 <kparal> the keyring is broken after Workstation install, it's always locked with an unknown password. Which means you can't report a crash from abrt, because it all breaks when you don't unlock the keyring.
17:07:33 <nielsenb> Oh, great
17:07:38 <cmurf> late blocker criterion applies :P
17:07:55 <cmurf> that's a bad bug
17:08:10 <cmurf> esp for beta
17:08:28 <cmurf> please test and report bugs... oh, oops
17:08:32 <lruzicka> kparal, yeah ... I do not know how to test the keyring. I have not ever used it so I skipped this in the matrices. It seems you are the first one to have tried.
17:08:47 <nielsenb> I also don't use the keyring
17:08:55 <nielsenb> Or know how to use the keyring
17:08:57 <nielsenb> I'm such a hack
17:08:59 <adamw> huh. i thought we had a test that hits that.
17:09:16 <lruzicka> adamw, automated? I do not think.
17:09:22 <adamw> maybe not automated...
17:09:23 <adamw> https://fedoraproject.org/wiki/QA:Testcase_desktop_keyring
17:09:27 <adamw> criterion is Final, apparently
17:09:33 <adamw> https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#desktop-keyring
17:09:47 <kparal> right, but the abrt criterion is beta, right?
17:09:49 <nielsenb> I don't think connecting to an encrypted network triggers the keyring?
17:10:17 <adamw> no, final.
17:10:21 <nielsenb> And I connect to remote sessions via SSH in gnome-terminal all the time, again, don't see a keyring prompt
17:10:24 <lruzicka> adamw, Perform an action which should result in a password being stored in a keyring. Common examples would be setting up an account in the desktop's native email client, connecting to an encrypted wireless network, or using a passphrase-protected SSH key in some way, for instance by logging in to a remote system via SSH
17:10:30 <kparal> (we should improve the test case to have some concrete tips how to test the keyring)
17:10:51 <lruzicka> adamw, this is unclear to me. If I use Nautilus to connect via ssh and store the password ... does it count?
17:10:52 <adamw> it's intentionally vague because it differs between desktops and over time
17:11:12 <lruzicka> kparal, yeah ... maybe, if I know exactly what to do, I could automate :D
17:11:19 <adamw> lruzicka: if that saves the password to the keyring and you then test that you can connect again without entering the password again, yes
17:11:23 <kparal> adamw: oh, that's... surprising. Everything is rainbows, then
17:11:28 <adamw> i usually test it by setting up an email account
17:11:40 <adamw> kpar: i mean, unless i'm missing something :D
17:11:43 <lruzicka> adamw, it asks whether to store password but no word about keyring ... how shall I know :D
17:11:52 <kparal> I usually test it by filling out credentials in abrt
17:11:56 <cmurf> i use it all the time for ssh
17:12:04 <cmurf> seems to be working
17:12:08 <nielsenb> Insert "is this...is this a keyring?" meme
17:12:12 <kparal> and you can see the keyring contents using seahorse
17:12:13 <cmurf> PKI
17:12:13 <adamw> kparal: we require crash reporting from *installer* in Basic
17:12:16 <lruzicka> kparal, abrt now uses BZ api key
17:12:23 <adamw> but desktop crash reporting is in Final under 'default applications'
17:12:35 <cmurf> yeah the abrt bz api key thing was a surprise for me
17:12:46 <kparal> adamw: I wonder if abrt reporting from Live would work or not. Need to test it.
17:13:00 <adamw> yeah, let us know...
17:13:04 <lruzicka> kparal, adamw: bash: seahorse: command not found...
17:13:09 <lruzicka> on a fresh install
17:13:22 <kparal> lruzicka: guess why 😀
17:13:29 <lruzicka> kparal, no idea :D
17:13:34 <nielsenb> Sad seahorse noises
17:13:55 <kparal> because you haven't installed it!
17:14:18 <adamw> it used to be installed by default, if it's not any more i guess we can update the test case...
17:14:20 <lruzicka> kparal, the test case however does not talk about installing it. :D
17:14:31 <nielsenb> And adamw mentioned email accounts
17:14:39 <nielsenb> Which definitely ask to save the password, even without seahorse
17:14:39 <lruzicka> And yes, you can report bugs using Arbt on Live system
17:14:52 <adamw> yeah, the keyring itself is implemented elsewhere
17:14:54 <adamw> seahorse is a viewer/editor for it
17:15:29 <nielsenb> Feels like something that should be in gnome-control-center, but that's a different topic
17:15:43 <lruzicka> nielsenb, yeah, I agree
17:15:47 <adamw> kparal: could the issue you faced be that you had an old abrt/libreport/something so it was still asking you for username/password, not an API key?
17:16:06 <kparal> adamw: no, fresh installs, two of them to make sure
17:16:36 <adamw> okay
17:17:02 <kparal> it asks for api_key, but then asks to unlock the keyring, which you can't, and then freezes for 20 seconds and depending on what you do, you might or might not end up continuing the report process
17:17:37 <kparal> there's an error about a dbus timeout etc
17:18:00 <kparal> there might be some workaround if you hit some specific buttons in the correct order 🙂
17:18:33 <adamw> fun :|
17:18:52 <kparal> sorry, need to change the diaper, brb 😀
17:18:55 <adamw> did you check other keyring-y things behave the same way?
17:18:59 <adamw> anyhoo, we have lots of stuff to test!
17:19:04 <adamw> any other business, folks?
17:19:24 <adamw> on the candidate composes - they got the wrong versions of gnome-shell and firefox. we'll definitely need a 1.4. i'll try and include any other FEs we can fix.
17:23:15 <adamw> alrighty, sounds like we're done
17:23:16 <adamw> thanks folks!
17:23:26 <adamw> #info there will be a Beta-1.4 later today, hang on to your hats
17:23:27 <nielsenb> Until next time!
17:23:28 <adamw> #endmeeting