16:00:06 <adamw> #startmeeting F33-blocker-review
16:00:06 <zodbot> Meeting started Mon Oct 12 16:00:06 2020 UTC.
16:00:06 <zodbot> This meeting is logged and archived in a public location.
16:00:06 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:06 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:00:06 <adamw> #meetingname F33-blocker-review
16:00:06 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:00:06 <adamw> #topic Roll Call
16:00:16 <adamw> morning folks, who's around to review some blockers?
16:01:26 <coremodule> I am!!
16:01:51 <coremodule> Good morning adamw too, glad you're back (I know youve been back for a week, but I can say it now too, dammit)
16:02:20 * coremodule willing and able to secretarialize.
16:03:01 <adamw> roger roger
16:03:09 <adamw> if it's just you and me it'll get a bit lonely though
16:03:13 <adamw> coremodule, are you officially here?
16:03:17 <adamw> kalev: ping
16:03:17 <zodbot> adamw: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
16:03:18 <coremodule> .hello2
16:03:20 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:03:22 <adamw> zodbot: shut up
16:03:26 <adamw> the data was implied, damnit
16:03:32 <adamw> er
16:03:32 <coremodule> lol
16:03:33 <adamw> i meant
16:03:36 <adamw> bcotton: are you officially here?
16:04:04 <coremodule> bcotton: "Here, because he's not all there."
16:04:43 <Southern_Gentlem> .hello jbwillia
16:04:44 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:04:52 <bcotton> .hello2
16:04:53 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:05:01 <bcotton> adamw: i am. i was just making lunch :-)
16:07:54 <adamw> it's breakfast time, damnit
16:08:11 <adamw> welp, i guess we can go ahead, we do have several bugs with some votes in the tracker so we can make quorum combined
16:08:32 <adamw> #chair bcotton coremodule
16:08:32 <zodbot> Current chairs: adamw bcotton coremodule
16:08:39 <adamw> boilerplate alert!
16:08:41 <adamw> #topic Introduction
16:08:41 <adamw> Why are we here?
16:08:41 <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:08:41 <adamw> #info We'll be following the process outlined at:
16:08:41 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:44 <adamw> #info The bugs up for review today are available at:
16:08:45 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:47 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:49 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:08:51 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:08:53 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:08:55 <adamw> #info for Final, we have:
16:08:57 <adamw> #info 3 Proposed Blockers
16:08:59 <adamw> #info 6 Accepted Blockers
16:09:01 <adamw> #info 3 Proposed Freeze Exceptions
16:09:05 <adamw> #info 10 Accepted Freeze Exceptions
16:09:16 <adamw> #info coremodule will secretarialize
16:09:22 <adamw> #topic Proposed Final blockers
16:10:48 <adamw> #topic (1886187) bcm283x-firmware-20200928-2.f0eab3a.fc33.aarch64 fails to boot on Raspberry Pi 3 Model B
16:10:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1886187
16:10:48 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/160
16:10:48 <adamw> #info Proposed Blocker, bcm283x-firmware, ON_QA
16:11:52 <bcotton> +1 blocker. booting is important
16:12:02 <adamw> hmm
16:12:08 <adamw> seems to be some confusion in the bug report
16:12:12 <bcotton> it seems to impact a large enough subset of hardware to be worthwhile
16:12:13 <adamw> peter thought he fixed it, reporter disagrees...
16:12:48 <adamw> Pi up to series 3 is listed at https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices / https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
16:13:04 <adamw> so i'd say i'm +1 blocker for now, can revise if more info suggests this is somehow not a widespread issue
16:14:11 <adamw> coremodule: any thoughts?
16:14:22 * coremodule still looking
16:14:25 <Southern_Gentlem> reporter didnt follow directions
16:15:21 <adamw> what directions?
16:15:23 <adamw> i just see "Joern: Can you test this new build and let me know how you get on with it."
16:15:26 <Southern_Gentlem> sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e35fa0cfb3
16:15:50 <Southern_Gentlem> Installed:
16:15:50 <Southern_Gentlem> bcm2711-firmware-20201008-1.63b1922.fc33.aarch64
16:15:59 <adamw> it's the same
16:16:12 <coremodule> I haven't seen this, would like to punt for later in the meeting and try to reproduce during meeting... If not, I'm +1 blocker
16:16:22 <bcotton> yeah, that's the package from the update. maybe the user already has updates-testing enabled
16:16:34 <coremodule> *I haven't tested for this
16:16:42 <adamw> coremodule: i'm fine with punting for that
16:16:52 <coremodule> Give me 10-15 to try this myself
16:16:56 <Southern_Gentlem> +1 blocker or +1FE
16:17:08 <bcotton> i'm happy to come back to this
16:17:19 <adamw> #info we'll circle back to this one later in the meeting, coremodule is going to see if he can reproduce it
16:17:20 <Southern_Gentlem> +1 Punt as well
16:17:32 <adamw> #topic (1885479) Google account: Credentials have expired
16:17:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1885479
16:17:32 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/142
16:17:32 <adamw> #info Proposed Blocker, gnome-online-accounts, ASSIGNED
16:17:43 <adamw> so this one was previously accepted as a blocker, however New Information has emerged
16:18:05 <adamw> it appears the bug only happens if you've changed your user password outside of GNOME's expectations and confused the poor dear
16:18:33 <adamw> which is a thing that happens, but it's probably not a wide enough impact to keep the bug as a blocker, especially as it's a situation that's unlikely to happen on first boot or in live usage, so fixing it with an update should be fine
16:18:36 <lruzicka> .hello2
16:18:37 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:18:42 <adamw> morning lruzicka
16:19:07 <bcotton> hmph. this is still crappy, but i guess it's not crappy enough to block on
16:19:13 <adamw> #info currently -3 in the ticket, from mcatanzaro, kparal and adamw: https://pagure.io/fedora-qa/blocker-review/issue/142
16:19:28 <bcotton> -1 blocker, +1 fe
16:19:53 <Southern_Gentlem> -1 b +1FE
16:20:28 <lruzicka> I am not sure, probably -1 but common bugs?
16:22:23 <adamw> yeah i'm not even sure about FE on this one, i'm kinda 0 FE
16:23:48 <Southern_Gentlem> is it reproducible ?
16:24:16 <adamw> i believe it's reproducible so long as you change the user password with 'passwd' (which means GNOME doesn't know about the change and update the keyring password) first
16:24:36 <adamw> can probably also reproduce by changing password through FreeIPA or something like it
16:25:02 <Southern_Gentlem> ok 0 FE
16:25:28 <adamw> proposed #agreed 1885479 - RejectedBlocker (Final) - this is now rejected with the information that it only happens when user password is changed in a certain way (that is fairly unlikely to be encountered on first boot or in live usage)
16:25:37 <adamw> we can vote FE in the ticket, I guess
16:25:46 <bcotton> ack
16:25:51 <lruzicka> ack
16:25:55 <Southern_Gentlem> ack
16:26:36 <adamw> #agreed 1885479 - RejectedBlocker (Final) - this is now rejected with the information that it only happens when user password is changed in a certain way (that is fairly unlikely to be encountered on first boot or in live usage)
16:26:56 <adamw> #topic (1887367) Gnome applications cannot be forwarded via ssh.
16:26:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1887367
16:26:56 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/161
16:26:56 <adamw> #info Proposed Blocker, gnome-session, NEW
16:27:52 <bcotton> X11 forwarding doesn't seem like "basic functionality" to me
16:27:59 <adamw> yeah, i'm -1 on this
16:28:17 <bcotton> -1, also
16:28:20 <adamw> #info we have -2 in the ticket currently, from kparal and adamw
16:28:26 <Southern_Gentlem> -1
16:28:54 <bcotton> lruzicka: want to change our minds?
16:29:10 <lruzicka> I am not sure if I can
16:29:12 <Southern_Gentlem> +1 commonbugs
16:29:43 <lruzicka> I sort of feel that this is not totally basic, but I believe it is good practice in linux that you can do it that way
16:29:56 <lruzicka> however, there is an easy workaround
16:30:34 <lruzicka> I will accept -1 I proposed it for discussion.
16:31:16 <bcotton> fwiw, i strongly prefer that it works, i just don't think it meets the criterion
16:32:40 <adamw> lruzicka: proposing a bug isn't an automatic +1
16:32:43 <adamw> you can propose and vote -1
16:32:44 <adamw> or 0
16:33:02 <adamw> of course, if your opinion is +1, i'm not trying to change that :)
16:33:06 <lruzicka> this proves the discussion point :D
16:33:22 <lruzicka> I am not sure about the blocker, but I am sure this should work D:
16:34:03 <adamw> oh yeah, but that's kinda...normal
16:34:12 <adamw> there's lots of bugs we really think should be fixed, but aren't release blockers. to me this is one
16:34:23 <adamw> so we have...*counts*...-4 +1ish
16:34:28 <adamw> (counting lruzicka as +1ish)
16:34:51 <lruzicka> ok :D
16:35:16 <adamw> proposed #agreed 1887367 - RejectedBlocker (Final) - we don't think this really meets the criterion cited or any other, ssh X forwarding does not seem like basic functionality
16:35:39 <bcotton> ack
16:35:43 <Southern_Gentlem> ack
16:35:52 <coremodule> ack
16:36:01 <lruzicka> ack
16:36:09 * Eighth_Doctor waves
16:38:47 <adamw> #agreed 1887367 - RejectedBlocker (Final) - we don't think this really meets the criterion cited or any other, ssh X forwarding does not seem like basic functionality
16:38:49 <adamw> ahoyhoy
16:39:44 <coremodule> booting rpi now, will install firmware and report
16:39:50 <adamw> rgr
16:40:04 <Southern_Gentlem> lruzicka, have you tested with X?
16:42:16 <adamw> #topic Proposed Final freeze exceptions
16:42:22 <adamw> #topic (1863531) fawkes: FTBFS in Fedora rawhide/f33
16:42:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1863531
16:42:22 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/159
16:42:22 <adamw> #info Proposed Freeze Exceptions, fawkes, ON_QA
16:42:35 <adamw> #info we have +2 in the ticket from kparal and adamw
16:42:55 <adamw> this one seems straightforward, we usually take FTBFS bugs as FEs in the interest of having the frozen repo be as installable as possible
16:43:26 <bcotton> +1 fe
16:43:39 <cmurf> +1 FE
16:44:35 <coremodule> +1FE
16:46:14 <adamw> proposed #agreed 1863531 - AcceptedFreezeException (Final) - accepted as we conventionally accept FTBFS bugs to try and make the frozen final repo as installable as possible
16:46:24 <bcotton> ack
16:46:48 <Southern_Gentlem> ack
16:46:49 <lruzicka> ack
16:48:31 <adamw> #agreed 1863531 - AcceptedFreezeException (Final) - accepted as we conventionally accept FTBFS bugs to try and make the frozen final repo as installable as possible
16:48:37 <adamw> #topic (1886561) RPM spec file syntax highlighting is not working
16:48:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1886561
16:48:38 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/153
16:48:38 <adamw> #info Proposed Freeze Exceptions, nano, VERIFIED
16:48:40 <adamw> so, this is a bit awkward
16:49:09 <adamw> eighth_doctor fixed it, but kdudka took exception to him fixing it
16:49:23 <adamw> kdudka being the maintainer, i think
16:49:34 <Eighth_Doctor> yeah
16:49:56 <adamw> accepting this as an FE would look a bit like an attempt to referee that debate, i think
16:50:03 <adamw> for that matter, rejecting it might too
16:50:31 <adamw> i think i'd vote to punt on this till after neal and kamil have had a duel at high noon or something
16:50:34 <Eighth_Doctor> it seems like he agrees with my rationale, but doesn't think I should have just done it
16:50:47 <cmurf> +1 adamw :D
16:50:59 <adamw> i mean, he didn't exactly say he agrees or disagrees with the change yet
16:51:07 <Eighth_Doctor> I don't know how we're going to duel since I think Kamil and I are on opposite timezones
16:51:11 <Eighth_Doctor> :P
16:51:14 <cmurf> it's been so long since we've had a duel at high noon
16:51:15 <Southern_Gentlem> zoom
16:51:45 <adamw> i'm also not sure how important it really is to fix it for release, do you often edit RPM specs from the installer environment or live images?
16:52:03 <adamw> (even if you do you could always just copy or move the file manually...)
16:52:45 <Eighth_Doctor> I didn't propose it as a blocker for that reason
16:53:02 <Eighth_Doctor> but I do think it's weird that we just suddenly lost a third of our syntax highlights midway through F33 development
16:53:05 <adamw> well it's clearly not a blocker
16:53:08 <Southern_Gentlem> its fixed and others need to deal with the other politics else where
16:53:11 <Southern_Gentlem> +1FE
16:53:11 <Eighth_Doctor> (we didn't just lose rpm, we lost a few others)
16:53:13 <adamw> anyhow, yeah, my vote is punt
16:53:43 <bcotton> +1 FE here
16:53:52 <cmurf> +1 FE as well
16:53:59 <lruzicka> +1 fe
16:54:02 <Eighth_Doctor> and so far, kdudka didn't revert it and accepted another PR on top and pushed it to Koji
16:54:18 <lruzicka> so is it fixed?
16:54:38 <Eighth_Doctor> the PR is for something else
16:54:49 <Eighth_Doctor> this was for the vim-default-editor subpackage "fun" that was introduced in Rawhide
16:55:02 <Eighth_Doctor> but he so far has not elected to revert my change
16:55:12 <adamw> er, so the build to 'fix' this would have another change in it?
16:55:14 <adamw> that's also an issue
16:55:30 <adamw> i note you didn't move just the rpm syntax back, you moved everything in extra
16:55:38 <Eighth_Doctor> well, yes, he'd have to revert https://src.fedoraproject.org/rpms/nano/c/0273023e2e30a38251837ebe8306f88a12e502f5?branch=master
16:55:48 <adamw> the release note text you cited would clearly justify moving the rpm syntax back, it's less clear that it justifies moving everything
16:55:52 <Eighth_Doctor> adamw: yes, because I found out that several grammars were missing
16:56:03 <Eighth_Doctor> I only found out because of the rpm one
16:56:21 <Eighth_Doctor> I filed the bug first, then did research to fix it
16:57:08 <adamw> well, 'fix' seems to be a subjective call here
16:57:17 * Eighth_Doctor shrugs
16:57:18 <adamw> as kamil says, upstream presumably thinks they shouldn't be there, that's why they moved them
16:58:05 <bcotton> it's our job to be opinionated
16:58:07 <Eighth_Doctor> upstream also suggested downstreams move the file sup if they want them enabled
16:58:10 <Eighth_Doctor> *files up
16:58:55 <bcotton> given that nano is our default editor now and this change appears to cause no harm, i'm in favor of accepting it
16:59:20 <Eighth_Doctor> 👍️
16:59:23 <adamw> i do wish upstream explained a bit better why they think it makes sense to have syntaxes but hide them
16:59:36 <cmurf> seems clear in commit 0273023e that the syntax highlight should be enabled
16:59:37 <adamw> but it does seem like they think that makes sense for some reason
17:00:00 <Eighth_Doctor> the thread upstream is not particularly enlightening and I really don't want a kinda-crippled nano in a release where it's a "feature"
17:00:30 <lruzicka> Eighth_Doctor++
17:01:12 <adamw> oh, https://lists.gnu.org/archive/html/nano-devel/2020-04/msg00023.html is the rationale, it seems
17:01:44 <adamw> on the whole i actually agree with you, but we should at least ensure kdudka actually agrees too
17:02:09 <Eighth_Doctor> is kdudka around?
17:02:22 <adamw> "Also, having an extra/ subdir allows us to ship some more syntaxes in the tarball without burdening the default install with them" implies that one concern for upstream is size
17:02:31 <adamw> do we actually ship the contents of extra/ in the package?
17:02:37 <Eighth_Doctor> yes
17:02:38 <Eighth_Doctor> we did before
17:02:43 <Eighth_Doctor> they all get installed regardless
17:02:55 <Eighth_Doctor> all I did was move them up one directory
17:03:48 <adamw> yeah, i see https://lists.gnu.org/archive/html/nano-devel/2020-04/msg00029.html now too
17:03:59 <adamw> okay, i really don't understand benno's position here at all, it seems nuts. :P
17:04:11 <Eighth_Doctor> I'm open to the idea in the future that we split out some grammars as subpackages for languages and stuff, but for now, just moving things back up a level makes it at parity with what we had in earlier F33 snapshots and in F32
17:04:13 <adamw> so i think i change to +1, with the only caveat being it'd be nice to get kdudka's signoff, we can ask in bug
17:04:57 * Eighth_Doctor is glad he's not the only one confused by benno's position on this
17:05:20 <cmurf> +1 adamw
17:06:45 <adamw> proposed #agreed 1886561 - AcceptedFreezeException (Final) - we think it makes sense to maintain continuity here and we disagree with upstream's rationale for moving these in the first place. it would be good to get kdudka's clear ack before pushing this, though
17:07:08 <bcotton> ack
17:07:13 <coremodule> ack
17:07:15 <Eighth_Doctor> ack
17:07:17 <lruzicka> ack
17:07:26 <adamw> #agreed 1886561 - AcceptedFreezeException (Final) - we think it makes sense to maintain continuity here and we disagree with upstream's rationale for moving these in the first place. it would be good to get kdudka's clear ack before pushing this, though
17:07:36 <adamw> #topic (1770599) os-prober very slow - taking up to 20 minutes
17:07:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1770599
17:07:36 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/158
17:07:36 <adamw> #info Proposed Freeze Exceptions, os-prober, ON_QA
17:08:07 <adamw> #info we have +2 in the ticket from kparal and adamw
17:08:08 <Eighth_Doctor> oh os-prober, how I loathe ye
17:08:20 <adamw> i mean it's no dracut, but it's a strong contender
17:08:32 <Eighth_Doctor> I just +1 FE in the ticket
17:08:52 <bcotton> +1 FE
17:09:01 <cmurf> oh dear 20 minutes?
17:09:04 <cmurf> what is it doing?
17:09:12 <cmurf> this is an old bug too
17:09:42 <Eighth_Doctor> lots of runs of linux-prober
17:09:42 <adamw> yeah, that usually makes the case for FE weaker, but in this case i'm still +1 because if you do have an affected config it sucks to sit around for 10-20 minutes during install
17:09:51 <adamw> fixing it would be good, if we're confident the fix is safe
17:10:21 <Southern_Gentlem> +1fe
17:10:35 <lruzicka> +1fe
17:11:06 <cmurf> *shrug* +1fe
17:11:17 <Eighth_Doctor> adamw: the fix in os-prober is a workaround for grub2-mount being terrible
17:11:31 <adamw> proposed #agreed 1770599 - AcceptedFreezeException (Final) - this is a sensitive thing to touch, but the bug is pretty bad for affected folks. We think it makes sense to accept a fix if we're confident about its safety, to save affected folks from a 10-20 minute delay during install
17:11:37 <Eighth_Doctor> ack
17:11:37 <cmurf> ack
17:11:47 <lruzicka> ack
17:11:47 <Southern_Gentlem> ack
17:13:54 <adamw> #agreed 1770599 - AcceptedFreezeException (Final) - this is a sensitive thing to touch, but the bug is pretty bad for affected folks. We think it makes sense to accept a fix if we're confident about its safety, to save affected folks from a 10-20 minute delay during install
17:14:08 <adamw> #topic Proposed Final blockers (redux)
17:14:14 <adamw> #info circling back to the one we delayed earlier
17:14:24 * zbyszek is lurking
17:14:24 <adamw> #topic (1886187) bcm283x-firmware-20200928-2.f0eab3a.fc33.aarch64 fails to boot on Raspberry Pi 3 Model B
17:14:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1886187
17:14:25 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/160
17:14:25 <adamw> #info Proposed Blocker, bcm283x-firmware, ON_QA
17:14:29 <adamw> coremodule, what'd you find out?
17:14:37 <adamw> zbyszek: any particular bug you have an interest in?
17:15:00 <coremodule> the update does not work and causes the system to hang at a black screen upon boot
17:15:20 <coremodule> So I'm +1 blocker
17:15:24 <adamw> and you reproduced the bug?
17:15:26 <coremodule> aye
17:15:28 <Southern_Gentlem> +1 B
17:15:29 <adamw> alrighty
17:15:50 <Ilgaz> Hello I am one of the guys effected by https://bugzilla.redhat.com/show_bug.cgi?id=1885479 and there is a misunderstanding, I haven't changed my password to trigger the issue, I actually have autologin enabled
17:15:56 <zbyszek> adamw: 1880628, but afaik it won't be discussed today
17:16:41 <adamw> proposed #agreed 1886187 - AcceptedBlocker (Final) - Raspberry Pis up to series 3 are on the ARM supported hardware list, and we have confirmation of the bug from coremodule, so accepting as a clear violation of Basic criterion "All release-blocking images must boot in their supported configurations"
17:16:48 <Eighth_Doctor> +1 Blocker for bug 1886187
17:16:56 <coremodule> ack
17:16:58 <lruzicka> ack
17:17:00 <Eighth_Doctor> ack
17:17:02 <bcotton> ack
17:17:03 <Southern_Gentlem> ack
17:17:14 <adamw> #agreed 1886187 - AcceptedBlocker (Final) - Raspberry Pis up to series 3 are on the ARM supported hardware list, and we have confirmation of the bug from coremodule, so accepting as a clear violation of Basic criterion "All release-blocking images must boot in their supported configurations"
17:17:55 <adamw> llgaz: seems like you and cmurf may have different issues
17:17:56 <Southern_Gentlem> Ilgaz, has more info on 142 (google)
17:18:46 <adamw> llgaz: can you do the stuff at https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Debugging too and post your results? that should let us figure out if your issue is a different one
17:18:55 <Ilgaz> adamw: What bugs me is the rarity of the issue, I don't want to waste anyones time if it only effects me
17:19:08 <adamw> i'd guess your case is more likely to do with which email address you use, rather than autologin
17:19:10 <adamw> but debug info will help
17:19:21 <Ilgaz> adamw: I did https://bugzilla.redhat.com/show_bug.cgi?id=1885479#c11
17:19:39 <adamw> ah, sorry, didn't see that. let me have a quick look
17:20:19 <adamw> huh, it does look like the same error..
17:20:52 <Ilgaz> I also used both ilgaz.nsa@gmail.com and ilgaz@fastmail.fm . When I tried logging on couple/triple times I could logon to google, I verified using google drive.  That time, system complained about locked credentials
17:20:57 <cmurf> yeah it does
17:21:15 <cmurf> what i'm not sure is if the gnome-keyring is unlocked with autologin?
17:21:37 <adamw> hmm...i mean, you'd think it should be
17:21:42 <adamw> could stand further testing, i guess
17:21:44 <cmurf> *shrug*
17:22:01 <cmurf> a plausible experience is login the user to the environment but keep their keyring locked
17:22:07 <Eighth_Doctor> afaik, keyring is not unlocked with autologin
17:22:21 <Eighth_Doctor> (that would be an interesting security issue if it did)
17:22:23 <cmurf> because the keyring contains secrets
17:22:36 <cmurf> yeah i think so
17:22:49 <cmurf> in which case there should be a dialog asking for keyring access
17:22:51 <adamw> but i mean, enabling autologin sort of implies you don't care about security...
17:23:05 <cmurf> not quite that far no :)
17:23:05 <Ilgaz> Could this have anything to do with logging it on a fresh install, use dnf -y update to update the system and rebooting?
17:23:10 <adamw> but yeah, it seems plausible as a theory
17:23:17 <adamw> in both cases the keyring isn't unlocked, for different reasons
17:23:25 <adamw> and then https://gitlab.gnome.org/GNOME/libsecret/-/issues/7 means you don't get prompted to unlock it
17:23:43 <cmurf> Ilgaz: if you've never changed your password, but just have autologin enabled, then i think the working hypothesis that it's autologin related is valid
17:23:54 <adamw> so, i've asked mcatanzaro and debarshi to comment in the bug
17:24:00 <cmurf> yep good
17:24:06 <adamw> we can keep an eye on the developments and always re-vote once more if necessary
17:24:22 <adamw> thanks for flagging it up, ilgaz
17:24:25 <Ilgaz> I have spare space and CPU , I can test with Autologin disabled fresh install?
17:24:31 <adamw> sure, or test in a VM
17:24:38 <adamw> probably easier that way
17:24:39 <cmurf> or just change one thing at a time
17:24:48 <cmurf> just disable autologin, does it now work?
17:25:33 <cmurf> for sure with a clean install it works, making no other changes to defaults
17:25:52 <cmurf> and still works following password change in User's panel
17:26:17 <adamw> yeah, methodical testing like that will be useful
17:26:21 <adamw> OK, let's follow that up in the bug
17:26:27 <adamw> let's do a quick check in on...
17:26:33 <adamw> #topic Accepted Final blockers
17:26:56 <adamw> #topic (1884260) cheese creates invalid and extremely long video files, each app restart making them longer
17:26:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1884260
17:26:56 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/136
17:26:56 <adamw> #info Accepted Blocker, cheese, ASSIGNED
17:27:23 <adamw> #info this is waiting on a code fix, basically. nothing much we can do here unless someone wants to dive in and fix it
17:28:38 <cmurf> this might need some visibility that it's a blocker
17:29:19 <adamw> yeah, i'll ping the desktop team
17:29:35 <adamw> #action adamw to ping desktop team to see if they can help fix #1884260
17:29:47 <adamw> #topic (1883681) [abrt] gnome-calendar: on_calendar_monitor_completed_cb(): gnome-calendar killed by SIGABRT
17:29:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1883681
17:29:47 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/156
17:29:47 <adamw> #info Accepted Blocker, gnome-calendar, NEW
17:31:43 <Southern_Gentlem> so this a abrt bug or calendar bug
17:32:37 <adamw> calendar bug
17:32:50 <adamw> there's an upstream issue and pull request for this, though the PR has a possible issue
17:32:54 <adamw> i've just commented on the bug
17:33:08 <adamw> same as the last one i think we should alert desktop team to this being an unfixed blocker, i can do that
17:33:25 <adamw> #action adamw to ping desktop team to see if they can help fix #1883681 also
17:33:33 <lruzicka> I am sorry but I need to go ... take care and have a nice day.
17:34:24 <adamw> thanks lruzicka
17:34:37 <adamw> #topic (1874117) 5.8.3-300.fc33.aarch64 kernel panic on boot (X-Gene PMU)
17:34:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1874117
17:34:37 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/145
17:34:38 <adamw> #info Accepted Blocker, kernel, ON_QA
17:34:55 <jforbes> That was submitted for stable this morning
17:35:03 <adamw> aha, indeed, was just checking
17:35:15 <adamw> #info this is fixed and fix submitted for stable, should go out in the next stable push request
17:35:23 <adamw> #topic (1882718) Server crashes after one connection attempt, all subsequent attempts will fail
17:35:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1882718
17:35:23 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/131
17:35:23 <adamw> #info Accepted Blocker, libvncserver, ASSIGNED
17:35:32 <adamw> #info jadahl and I are currently working on this one
17:35:38 <Ilgaz> cmurf: it is indeed related to auto login
17:36:07 <Ilgaz> I disabled auto login and now I can logon to google
17:36:35 <cmurf> Ilgaz: ok cool, update the bug with your finding - i suspect that in this case it should cause a dialog to authenticate+unlock the keyring and that's not happening for some reason
17:37:31 <adamw> cmurf: the probable reason for that is https://gitlab.gnome.org/GNOME/libsecret/-/issues/7 i believe, someone linked that in the bug
17:38:10 <cmurf> gotcha
17:38:15 <adamw> cmurf: so both paths wind up in the same place - whether because of changing password with passwd or using autologin, the keyring isn't unlocked on login, and then GNOME should prompt you to unlock it when needed but it doesn't because of that bug, i guess
17:38:29 <cmurf> yeah makes sense
17:38:30 <adamw> (of course, the passwd change case is tricky because to unlock the keyring you'd have to enter the *old* password)
17:38:41 <cmurf> yep
17:38:43 <adamw> i have this fun regularly when i change my account password with freeipa
17:39:04 <adamw> you can actually fix it by going into seahorse and changing the keyring password to match the user password
17:40:00 <Ilgaz> I updated the bug with comment, thanks for all
17:40:46 <adamw> yeah, i think we understand what's going on with that one better now
17:40:58 <adamw> i'll add a comment after the meeting's done too and we can reconsider blocker status once more
17:41:25 <adamw> so yeah, on 1882718, jadahl and I are going to throw a couple more crasher fixes at it after this meeting is done and see if that helps
17:41:45 <adamw> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
17:41:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
17:41:45 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/16
17:41:45 <adamw> #info Accepted Blocker, sddm, ASSIGNED
17:43:06 <adamw> so, this one. fun
17:43:28 <adamw> we're still waiting on someone to do bberg's proposed fix
17:43:34 <adamw> i guess i can try and do it if no-one else will
17:43:58 <adamw> #info still waiting on someone to try bberg's proposed fix here
17:44:18 <cmurf> i was under the impression this is an F34 thing
17:44:32 <cmurf> as in, not enough time to get it fixed for f33
17:44:33 <adamw> we waived it at beta
17:44:41 <adamw> by policy if you waive a bug it goes to the next milestone
17:44:49 <adamw> we can waive it again, if we *want* to.
17:45:20 <adamw> it's hard to argue we don't have enough time to fix it if there's a suggested fix lying around that no-one tried to do yet.
17:45:27 <bcotton> spoiler alert: i am strongly leaning toward waiving it if we can't get a reasonable fix in by next monday's meeting :-)
17:46:14 <adamw> #topic (1883609) Secure Boot fails to boot F33 Beta image
17:46:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1883609
17:46:15 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/135
17:46:15 <adamw> #info Accepted Blocker, shim, NEW
17:46:23 <adamw> ze mystery boog
17:47:00 <adamw> i think kparal is going slowly insane
17:47:02 <cmurf> hey! Canadianish!
17:47:11 <cmurf> well he has two kids...
17:47:27 <adamw> i mean, this bug is driving him slowly insane
17:47:28 <cmurf> so there's sleep deprevation on top of firmware joy
17:48:01 <cmurf> yeah well actually trying to understand problems can have that effect
17:48:50 <adamw> this showed up as accepted blocker because of FESCo https://pagure.io/fesco/issue/2479 , but i think that may be wrong
17:48:59 <adamw> see https://bugzilla.redhat.com/show_bug.cgi?id=1883609#c46
17:49:02 <cmurf> why
17:49:21 <adamw> didn't we decide kparal's bug has nothing to do with the key revocation thing?
17:49:27 <Eighth_Doctor> no?
17:49:35 <adamw> okay now i'm going fastly insane
17:49:45 <cmurf> shhh calm down no one is on crazy pills
17:49:57 <Eighth_Doctor> my reading indicates that it's because of revocation updates being applied somehow
17:50:01 <cmurf> kparal's issue is probably something else
17:50:17 <cmurf> neither bug 1883609 nor fesco#2479
17:50:44 <cmurf> this is why the two issues are related: https://bugzilla.redhat.com/show_bug.cgi?id=1883609#c38
17:51:03 <cmurf> so 1883609 is basically a blocker process placeholder for fesco#2479
17:51:09 <adamw> oh, i see
17:51:14 <adamw> so Alex is likely running into key revocation
17:51:20 <adamw> but we don't know what the hell kamil has?
17:51:27 <cmurf> no idea
17:51:30 <cmurf> that's fakaked
17:51:46 <cmurf> because he def does not have a dbx at all, so the clear sB keys option in his firmware did work
17:51:52 <Eighth_Doctor> yeah, Kamil's thing confuses me
17:52:03 <cmurf> his denial might be because there's not even a microsoft key present
17:52:12 <adamw> okay, we should sort this bug out a bit, then
17:52:22 <cmurf> and then also it could be garbage collection related where some key is coming back from the dead
17:52:28 <Eighth_Doctor> oh, that would make sense, actually
17:52:29 <cmurf> (which could be the microsoft key)
17:52:42 <Eighth_Doctor> no registered keys should have the same impact as revoked keys
17:53:24 <cmurf> anything in dbx is revoked, but it's peculiar to say the least you can revoke a revocation list but that's also another discussion :)
17:53:52 <cmurf> summary of my weekend fireside chat on fedora-qa
17:54:05 <cmurf> Ubuntu 20.04 is not updating dbx at all
17:54:11 <cmurf> ^ISO
17:54:50 <cmurf> Ubuntu 20.04.1 ISO likewise is not updating dbx. There is a secureboot-db update for 20.04.1 that does update dbx to version 77, which is pre-BootHole
17:55:19 <cmurf> so I still don't know exactly what is applying the embargoed dbx
17:55:36 <Eighth_Doctor> did we check to see if there's a secureboot-db update applied via snap?
17:55:42 <cmurf> we'd have to ask pjones what came of  his meeting from last week, how wide the scope is
17:56:02 <cmurf> Eighth_Doctor: I didn't. I just did the recommended updates.
17:56:19 <Eighth_Doctor> hmm
17:56:23 <adamw> posted https://bugzilla.redhat.com/show_bug.cgi?id=1883609#c47
17:56:25 <cmurf> There could be other updates, and maybe that's how it sneaks in? Or maybe it's already turned off? I have no idea.
17:57:16 <cmurf> adamw: yeap
17:57:41 <adamw> #info there's still a lot of confusion about who's running into what problem here, but it seems we're broadly treating this bug as being about a scenario where the Secure Boot key that our initial bootloader (shim) is signed with gets revoked somehow (due to the BootHole vulnerability)
17:58:19 <adamw> #info FESCo has agreed to treat this problem as a FESCo blocker - https://pagure.io/fesco/issue/2479#comment-694834 - but stipulates that the resolution "does not necessarily have to be technical"
17:58:35 <adamw> #info so we're broadly waiting on FESCo and pjones to decide what to do about this
17:58:47 <adamw> cmurf: does that all sound right to you?
17:58:51 <cmurf> yessir
17:58:58 <adamw> thanks, and thanks for working on it
17:59:40 <adamw> okay, and that's all the bugs
17:59:43 <adamw> #topic Open Floor
17:59:46 <adamw> any other business, folks?
18:00:53 <cmurf> that secure boot blocker might get waived because it's actually inconvenient to sign old shim with a new key now; and have to resign it when new shim is ready
18:00:59 <cmurf> and new shim is ready in months
18:01:38 <Eighth_Doctor> we don't know that it'll take months to resign
18:01:45 <Eighth_Doctor> the fact we keep presuming it is extremely weird
18:01:48 <cmurf> so one thing fesco#2479 is about, is contingency for either reissuing images or i guess an alternative is fast tracking the next release
18:02:06 <cmurf> it doesn't take months to sign, maybe a couple weeks
18:02:26 <cmurf> there's an shim 15 (what we have now) and shim 16 is imminent but not done
18:02:41 <cmurf> so if we need newly signed shim now, it'd be shim 15
18:02:50 <cmurf> but then we'd have to resign shim 16 when it's ready
18:04:07 <cmurf> and pjones was hoping to avoid having to issue new-world keys with shim 15, and just do it all at once with shim 16
18:04:16 <adamw> well yeah, we all hate working :P
18:04:46 <adamw> but anyway, it's kinda above this meeting's pay grade
18:04:59 <adamw> as long as someone is Working On It our purpose is served
18:05:10 <sgallagh> Well, part of the problem is that the space used by key revocation is limited and expensive
18:05:21 <cmurf> yeah that too
18:05:45 <sgallagh> So it's non-trivial to have extra, short-lived signatures.
18:05:52 <sgallagh> Since their revocation will live forever.
18:06:00 <cmurf> the solution for which is Secure Boot 2.0, which has its own expense which is a ton of firmware updates
18:06:12 <adamw> i think the solution is Yak Farm 1.0
18:06:13 <cmurf> a lot of which might not ever happen *shrug*
18:06:22 <cmurf> adamw you're on Yak Farm 3.0
18:06:30 <cmurf> or 13.0
18:06:36 <adamw> the office in my yak farm is going to have a writing desk, a drawer full of envelopes, a really good pen and a filing cabinet
18:06:45 <cmurf> no electricity!
18:06:48 <cmurf> no internet!
18:06:50 <adamw> electricity is fine
18:06:55 <adamw> just no network connections
18:06:57 <cmurf> just go with fire
18:07:20 <adamw> alrighty
18:07:24 <adamw> thanks for coming, everyone
18:07:47 <cmurf> thanks
18:07:53 <sgallagh> (Sorry for being late, but my Mondays are a solid wall of meetings from 8:30am to 2:00pm Eastern)
18:11:14 <adamw> #endmeeting