16:00:21 <adamw> #startmeeting F33-blocker-review
16:00:21 <zodbot> Meeting started Tue Sep  8 16:00:21 2020 UTC.
16:00:21 <zodbot> This meeting is logged and archived in a public location.
16:00:21 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:21 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:00:21 <adamw> #meetingname F33-blocker-review
16:00:21 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:00:21 <adamw> #topic Roll Call
16:00:26 <adamw> morning folks
16:01:04 * kparal is here but reinstalling his work laptop atm
16:03:10 <adamw> who else is around?
16:03:16 * coremodule is here
16:03:34 <coremodule> willing to act as secretary as well.
16:03:35 * cmurf is here
16:04:41 <cmurf> .hello chrismurphy
16:04:42 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:04:51 <cmurf> the bot is alive today!
16:06:04 <cmurf> 35C yesterday, -1C today in Denver
16:06:14 <cmurf> smoke and ash for two days from fires and now snow
16:06:18 <coremodule> wait... cmurf, are you in denver?
16:06:19 * lruzicka is here for a while but will need to go soonish
16:06:28 <cmurf> jawohl
16:06:45 <coremodule> interesting! I'm in co springs
16:06:55 <coremodule> had no idea
16:07:11 <cmurf> i'm in a cherry creek highrise, 16th floor and can't see downtown denver for three days
16:07:26 <cmurf> howdy neighbor!
16:07:34 <adamw> #chair cmurf coremodule
16:07:35 <zodbot> Current chairs: adamw cmurf coremodule
16:07:58 <coremodule> yeah, i was at the spaghetti factory in brighton on saturday, we could pick the ash out of the air and crush it between our fingers... so dark out
16:08:04 <adamw> incoming boilerplate alert
16:08:09 <adamw> #topic Introduction
16:08:10 <adamw> Why are we here?
16:08:10 <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:10 <adamw> #info We'll be following the process outlined at:
16:08:12 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:12 <adamw> #info The bugs up for review today are available at:
16:08:15 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:17 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:19 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:08:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:08:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:08:25 <adamw> #info for Beta, we have:
16:08:51 <adamw> #info 1 Proposed Blockers
16:08:51 <adamw> #info 10 Accepted Blockers
16:08:55 <adamw> #info 13 Accepted Freeze Exceptions
16:08:59 <adamw> (oof that's a lot)
16:09:03 <adamw> #info for Final, we have:
16:09:13 <adamw> #info 2 Proposed Blockers
16:09:13 <adamw> #info 1 Accepted Blockers
16:09:22 <adamw> you know, Final's looking in much better shape than beta
16:09:27 <adamw> proposal: we skip to final release immediately
16:09:37 <cmurf> ack
16:09:38 <coremodule> ack
16:09:49 * adamw wonders where bcotton is anyway
16:09:54 <cmurf> maybe we should +1 before acking
16:09:57 <coremodule> *i read that as "we skip the final release immediately"
16:10:00 <coremodule> i rescind my ack
16:10:08 <cmurf> but why not skip the votes since we're skipping beta?
16:10:22 <cmurf> it's fine, it's done
16:10:39 <cmurf> USS Ship It
16:11:05 <cmurf> (i think i say that at least once per release anyway)
16:11:15 * pwhalen is here
16:11:26 <adamw> #info coremodule will secretarialize
16:11:50 <adamw> let's start with the...
16:11:53 <adamw> #topic Proposed Beta blocker
16:12:00 <adamw> #topic (1828188) dasbus.error.DBusError: cannot initialize a disk that has partitions
16:12:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1828188
16:12:00 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/60
16:12:00 <adamw> #info Proposed Blocker, kernel, NEW
16:12:28 <adamw> #info ticket has -2 from cmurf and lruzicka: https://pagure.io/fedora-qa/blocker-review/issue/60
16:12:54 <cmurf> only reproducer is an ancient kernel
16:13:08 <adamw> reporter said they can't reproduce
16:14:01 <coremodule> -1
16:14:16 <kparal> -1 beta blocker and let them propose as final if it happens again
16:14:21 <coremodule> no reproducer and lnie herself says she cant reproduce
16:14:22 <pwhalen> -1
16:14:34 <adamw> backstory here seems to be this is basically a five month old bug but kparal found a private bug (1825067) which was proposed as a beta blocker, that doesn't really work, only public bugs can really work with the blocker system
16:14:43 <cmurf> :D
16:14:45 <adamw> so he closed it as a dupe of a public bug and proposed that as a blocker instead
16:14:47 <regenbogen> Hi! Sorry I'm late
16:14:53 <regenbogen> .fas lailah
16:14:53 <adamw> i'm -1 and/or just close the bug
16:14:53 <zodbot> regenbogen: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:14:55 <cmurf> old kernel, old qemu, old libvirt
16:14:57 <adamw> hi lailah
16:15:05 <regenbogen> Hi adamw
16:16:04 <adamw> proposed #agreed 1828188 - RejectedBlocker (Beta) - there's no indication this bug is still present in current F33 (or Rawhide), reporter tried and cannot reproduce, neither can anyone else. It should probably be closed, but we definitely reject it as a blocker for now
16:16:11 <coremodule> im okay with -1/close
16:16:18 <coremodule> ack
16:16:24 <cmurf> ack
16:16:36 <kparal> ack
16:16:41 <pwhalen> ack
16:16:45 <adamw> #agreed 1828188 - RejectedBlocker (Beta) - there's no indication this bug is still present in current F33 (or Rawhide), reporter tried and cannot reproduce, neither can anyone else. It should probably be closed, but we definitely reject it as a blocker for now
16:16:47 <regenbogen> ack
16:17:06 <adamw> OK, that's all the Beta proposals, let's do the...
16:17:10 <adamw> #topic Proposed Final blockers
16:17:19 <adamw> #topic (1876162) anaconda storage configuration is extremely slow with an existing btrfs filesystem containing hundreds of snapshots
16:17:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1876162
16:17:20 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/64
16:17:20 <adamw> #info Proposed Blocker, anaconda, NEW
16:17:33 * bcotton is here now
16:18:02 <adamw> this was rejected for Beta by ticket vote, but we have no final votes yet
16:18:35 <kparal> hum, adamw, why do you hate updating the discussion tickets with AGREED ?
16:18:37 <cmurf> i'd like to hear from anaconda team
16:18:39 <adamw> aiui, cmurf's comments indicate it's unlikely typical use of Fedora 33+ will produce hundreds of snapshots, but there are other situations where it can happen
16:18:49 <regenbogen> Well...  what is the criteria this bug would be breaking? adamw
16:18:51 <adamw> kparal: because i forgot you have to do that...it should be magic
16:18:56 <adamw> there's too much work in this convenience system :)
16:19:07 <cmurf> but i'd say chances are it's not getting fixed for F33
16:19:10 <kparal> ups & downs
16:19:42 <bcotton> i'm leaning toward -1 FB at the moment. it's not crashing and it seems unlikely that most users would encounter it
16:19:51 <adamw> regenbogen: see https://bugzilla.redhat.com/show_bug.cgi?id=1876162#c7
16:20:05 <kparal> well, opensuse does those snapshots for some time, right? and so far we've heard little complaints
16:20:18 <kparal> so it's probably not that critical
16:20:39 <adamw> kparal: srsly though, i should really only need to do...stuff...once and The System should pick it up. i don't have to do everything twice in bugzilla and blockerbugs, i shouldn't have to do everything twice in bugzilla and the votey thing
16:20:47 <regenbogen> adamw I read the bug but my knowledge of BTRFS is null.
16:21:07 <regenbogen> Reading the bug doesn't tell me much, I don't know what should I expect in normal cases.
16:21:08 <adamw> kparal: ok, a bug that's proposed as both Beta and Final blocker being 'rejected' as Beta is an awkward case because all you can really do is unpropose it
16:21:15 <adamw> you can't actually mark it rejected
16:21:18 <cmurf> adamw wants a neural scan interface
16:21:25 <adamw> AI blocker systems!
16:21:26 <kparal> adamw: you can't do that in bugzilla
16:21:31 <kparal> you can do it in pagure
16:21:56 <adamw> kparal: yeah, I meant in bz
16:22:15 <adamw> regenbogen: btrfs has this snapshotting feature where you can take a 'snapshot' of the filesystem at any time and later roll back to it
16:22:23 <kparal> you're right, we have to unpropose it in bz, yes
16:22:38 <regenbogen> adamw Okay.
16:22:52 <regenbogen> But why would anyone have hundreds of snapshots?
16:23:06 <regenbogen> That sounds like an unlikely scenario.
16:23:41 <adamw> regenbogen: if you do that a lot so the filesystem has hundreds of stored snapshots, then try to install Fedora, it will take a long time to try and read it
16:23:52 <cmurf> common on (open)SUSE setups out of the box
16:24:02 <adamw> regenbogen: openSUSE, for instance, does a snapshot automatically when you update the system
16:24:06 <adamw> so you can roll back if the update's broken
16:24:13 <adamw> so you can easily end up with a lot
16:24:26 <regenbogen> OH. Okay. Got it.
16:24:27 <cmurf> i don't wanna get into whether it's a reasonable number of snapshots to retain :)
16:24:35 <regenbogen> Thanks for the explanation  adamw
16:24:43 <cmurf> because i like our opensuse neighbors
16:24:46 <adamw> kparal: so in *that* case i can see that it'd be hard for pagure to pick up the change from bz. but pagure changes could propagate to bz...i dunno, i just demand convenience :P
16:25:08 <kparal> adamw: but you know the bz integration is planned if we like the current system
16:25:19 <kparal> it's not like we haven't talked about this before :)
16:25:36 <kparal> we can discuss the improvements after the meeting
16:25:41 <coremodule> convenience would be nice
16:25:49 <coremodule> the sooner the better! (if we plan to keep it)
16:26:07 <adamw> so on this bug
16:26:11 <adamw> i'm kinda torn...
16:26:18 <cmurf> anyway, hypothetically this is a blocker - but practically it can't be for now
16:26:30 <cmurf> hence i wanna hear from Anaconda folks
16:26:39 <adamw> cmurf: why do you say practically it can't be?
16:26:48 <cmurf> resources to fix it
16:26:50 <cmurf> scope unknown
16:27:13 <adamw> cmurf: well, i'd be fine with "slap a timeout or a maximum snapshot count or something on it" as a resolution
16:27:24 <adamw> that doesn't seem unreasonably hard in time for final
16:27:37 <adamw> i can go with 'punt for installer team input on what's reasonable' though
16:27:46 <cmurf> for btrfs yes, because subvols do not require tear down, just wipe the magic
16:28:05 <kparal> adamw: asking the installer team sounds most reasonable in this case
16:28:11 <cmurf> that's not the case with the LVM equivalent though
16:28:18 <adamw> cmurf: why are you making trouble for us here :P
16:28:21 <adamw> no-one asked about lvm
16:28:29 <pwhalen> heh
16:28:36 <adamw> just delete your comment and pretend we never heard of LVM
16:28:37 <adamw> :P
16:29:00 <cmurf> snapper supports the same regime with lvm thinp as btrfs :)
16:29:07 <adamw> LALALAICANTHEARYOU
16:29:42 <cmurf> :D
16:29:48 <cmurf> just like the good old days
16:30:16 <regenbogen> I was missing these meetings...
16:31:03 <cmurf> how likely is this and is there a reasonable work around? yes
16:31:23 <cmurf> i think it's suboptimal but reasonable to just blkdiscard the partition: LVM PV or Btrfs
16:31:26 <cmurf> then launch the installer
16:32:07 <adamw> proposed #agreed 1876162 - punt (delay decision) - this seems like a reasonable blocker candidate but we're concerned about the extent to which it can realistically be addressed in a practical timeframe for F33. we will punt for input from installer team on this
16:32:16 <cmurf> the LVM case is harder actually, the installer never gets to the language screen; at least with Btrfs if you're really patient, Autopart will blow it away and clean install just fine
16:32:19 <kparal> ack
16:32:26 <cmurf> ack
16:32:30 <coremodule> ack
16:32:47 <pwhalen> ack
16:32:59 <regenbogen> ack
16:33:16 <adamw> #agreed 1876162 - punt (delay decision) - this seems like a reasonable blocker candidate but we're concerned about the extent to which it can realistically be addressed in a practical timeframe for F33. we will punt for input from installer team on this
16:33:27 <adamw> #topic (1875140) g-i-s fails to completely launch following clean install, opens in a tiny non-resizeable window instead
16:33:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1875140
16:33:27 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/61
16:33:27 <adamw> #info Proposed Blocker, gnome-initial-setup, NEW
16:33:43 <adamw> so this one's a bit awkward; the initial setup screen is actually there, it's just tiny
16:34:00 <adamw> and if you don't know what's supposed to be happening you might not twig that you need to resize this weird tiny window (or even notice it)
16:34:13 <adamw> also, we don't know the conditions to trigger this yet
16:34:19 <adamw> might be candidate for a mailing list call
16:34:24 <cmurf> twig, are you trying to Canadianish all of us?
16:34:36 <adamw> that's britishish!
16:34:42 <regenbogen> adamw Is there a screenshot? I'd love to see the tiny setup screen.
16:34:54 <regenbogen> adamw  LOL
16:34:55 <adamw> would you prefer "cotton on"
16:35:00 <coremodule> I see the same as lruzicka, I haven't seen this on any baremetal installs
16:35:19 <adamw> regenbogen: there are screenshots attached to the bug
16:35:26 <regenbogen> Oh, great, thanks
16:35:40 <kparal> even if this only concerned VMs, I'd definitely still be FinalBlocker +1
16:35:41 <bcotton> adamw: i'm always on
16:35:58 <cmurf> now that you mention it, i do need a bold strategy from cotton
16:36:21 <regenbogen> adamw it downloads the image instead of opening it  :-|
16:36:33 <adamw> kparal: it doesn't even affect VMs all the time - openQA hits it, i dunno, one time in six or so
16:36:43 <adamw> regenbogen: that's kinda browser-dependent
16:36:52 <kparal> cmurf said 4 out of 10
16:36:56 <regenbogen> I just saw it adamw
16:37:02 <regenbogen> It's hilarious.
16:37:02 <adamw> yeah we seem to have different experiences there
16:37:07 <adamw> regenbogen: yeah it looks pretty bad
16:37:11 <regenbogen> But very confusing if you're new
16:37:12 <kparal> it's still quite frequent
16:37:17 <adamw> true
16:37:25 <adamw> enough that i get bored of restarting the failures :)
16:37:26 * cmurf is amused, munches on popcorn
16:37:31 <kparal> even 1 of 6 is frequent
16:37:32 <regenbogen> So no idea what triggers this?
16:37:46 <adamw> regenbogen: timing!
16:37:50 <adamw> always the safe fallback position
16:37:52 * regenbogen pinches from cmurf pop corn
16:38:12 <adamw> it's almost never *not* a timing problem of some kind
16:38:21 <adamw> the trick is figuring out what :P
16:38:27 <regenbogen> Now I'm confused....
16:38:42 <cmurf> rats i forgot to mention this bug in Workstation wg meeting when kalev was around
16:38:50 <adamw> regenbogen: it's probably caused when something happens earlier or later than something else was expecting
16:38:55 <cmurf> just fire me permanently
16:39:00 <regenbogen> Ah.
16:39:05 <regenbogen> Well, that's pretty vague.
16:39:21 <cmurf> theory: computers are deterministic machines
16:39:23 <bcotton> regenbogen: that's why adam is so confident about it
16:39:24 <adamw> regenbogen: any time you have a bug that sometimes happens and sometimes doesn't in (apparently) the same circumstances, that tends to be the case. but it's not much *use* as a general statement unfortunately, because you need to figure out the details
16:39:48 <adamw> cmurf: that's patently absurd
16:39:50 <cmurf> reality: non-determinsism is a fact of life
16:39:51 <adamw> have you ever met a computer
16:40:04 <cmurf> yes i've met two of them
16:40:08 <adamw> everyone knows they work faster if you yell at them
16:40:35 <regenbogen> adamw Not true. Mine work faster when I stroke them & promise treats.
16:40:41 <cmurf> not if they run hard drives - vibration from the yelling slows them down :)
16:40:51 <bcotton> i remain non-committal on this one. i'd be in favor of punting a decision until after Beta in the hopes that we'll either have a better sense of the conditions under which this happens or it will get fixed and we won't need to decide at all
16:41:09 * adamw wonders what sort of treats you feed a computer
16:41:17 <bcotton> bytes
16:41:20 <coremodule> mega-bytes
16:41:22 <adamw> .fire bcotton
16:41:22 <zodbot> adamw fires bcotton
16:41:23 <coremodule> beat me to it
16:41:25 <adamw> .fire coremodule
16:41:25 <zodbot> adamw fires coremodule
16:41:31 <cmurf> oh my
16:41:46 <coremodule> l;ol
16:41:54 <cmurf> there's a statler and waldorf moment
16:42:23 <regenbogen> Personally I do think it's a blocker. It really makes for a bad user experience.
16:42:33 <regenbogen> But I'd like to know what's causing it.
16:42:34 <adamw> yeah, it is pretty bad
16:42:49 <cmurf> ok so let's agree to make it a beta blocker since we're looking likely to slip anyway
16:42:55 <adamw> it's a proposed final blocker
16:43:11 <cmurf> that's a given i think
16:43:33 <adamw> i thought that's what we were discussing :P
16:43:44 <adamw> you know, that being the way the meeting works and all
16:43:47 <adamw> so uh. votes?
16:43:48 * cmurf is confused per usual
16:43:54 <regenbogen> I'm +1
16:44:02 <kparal> FinalBlocker +1, as in ticket
16:44:15 <cmurf> final blocker for sure, only question from my point of view is beta
16:44:24 <kparal> cmurf: already rejected
16:44:29 <pwhalen> +1 FB for sure
16:44:36 <kparal> unless you want to reopen that discussion
16:44:54 <cmurf> i'll go ask
16:44:57 <adamw> kparal: oh sorry, forgot to check ticket votes
16:45:20 <kparal> this new voting system sucks, too many places to check!
16:45:21 <adamw> #info we have +2 ticket votes from kparal and frantisekz
16:45:27 <adamw> kparal: yeah whose awful idea was it
16:45:36 <regenbogen> kparal yes, it's confusing.
16:45:43 <kparal> I kinda agree, but at the same time I'm extremely happy with it
16:45:55 <adamw> kparal: no, i agree, it saved like six votes today
16:46:06 <adamw> ok so we're at +4 right now with regenbogen and cmurf
16:46:17 <regenbogen> I think so...
16:46:31 <regenbogen> I'm not counting, that's your job adamw
16:46:31 <cmurf> ok but we should take it as beta FE if a fix comes up
16:46:45 <kparal> cmurf: already accepted
16:46:52 <cmurf> :facepalm:
16:46:55 <bcotton> 0 FinalBlocker
16:47:04 <kparal> cmurf: just look at our new shiny voting system!!! https://pagure.io/fedora-qa/blocker-review/issue/61 :D
16:47:08 <adamw> proposed #agreed 1875140 - AcceptedBlocker (Final) - this is accepted as a violation of "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system", when the bug happens, g-i-s is definitely not "clearly presented"
16:47:13 <cmurf> i've been using it
16:47:17 <bcotton> ack
16:47:20 <cmurf> i just don't refer to it during blocker review :P
16:47:20 <regenbogen> ack
16:47:23 <kparal> :)
16:47:30 <kparal> ack
16:47:33 <cmurf> ack
16:48:34 <pwhalen> ack
16:48:41 <coremodule> ack
16:48:50 <adamw> #agreed 1875140 - AcceptedBlocker (Final) - this is accepted as a violation of "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system", when the bug happens, g-i-s is definitely not "clearly presented"
16:49:07 <adamw> OK, so let's go back to Beta and **REVIEW** (not vote on) the...
16:49:11 <adamw> #topic Accepted Beta blockers
16:49:29 <adamw> #topic (1872056) Booting Server DVD then selecting a mirrorlist repository does not work
16:49:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1872056
16:49:29 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/35
16:49:29 <adamw> #info Accepted Blocker, anaconda, ON_QA
16:49:37 <adamw> so on this one the plan is to check the next rawhide compose as it has the same fix
16:49:42 <adamw> so we can tell if it worked there
16:50:13 <adamw> #info same fix should be in next Rawhide compose, we can verify (or not) there
16:50:16 <adamw> #topic (1849430) Fedora 33: Everything boot x86_64 image exceeds maximum size
16:50:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1849430
16:50:16 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/21
16:50:16 <adamw> #info Accepted Blocker, distribution, ASSIGNED
16:50:34 <adamw> so i worked on this some last week, i have a PR in right now which for me got an f33 image to exactly the max size limit
16:50:39 <adamw> https://github.com/weldr/lorax/pull/1070
16:50:44 <adamw> planning to do some more work on it today
16:50:48 <regenbogen> adamw what does  "maximum size"  mean?
16:51:08 <adamw> regenbogen: we have a maximum size defined for all release-blocking images
16:51:15 <adamw> for the netinsts it is exactly the maximum size of a standard CD
16:51:33 <regenbogen> Oh...
16:51:35 <regenbogen> Okay.
16:51:39 <regenbogen> I didn't know.
16:52:09 <regenbogen> Thanks  adamw
16:52:33 <adamw> #info adamw has a PR posted that does some initial work here, more planned soon: https://github.com/weldr/lorax/pull/1070
16:52:53 <adamw> #topic (1849431) Fedora 33: Server boot x86_64 image exceeds maximum size
16:52:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1849431
16:52:54 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/20
16:52:54 <adamw> #info Accepted Blocker, distribution, ASSIGNED
16:53:06 <adamw> #info exactly same as previous bug (the installer environment is effectively the same in both)
16:53:11 <adamw> #topic (1869892) Release-blocking Fedora 33 images have Fedora 32 backgrounds
16:53:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1869892
16:53:12 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/27
16:53:12 <adamw> #info Accepted Blocker, distribution, NEW
16:53:35 <cmurf> waiting on kde or is that fixed now?
16:53:41 <adamw> #info the dependent KDE bug https://bugzilla.redhat.com/show_bug.cgi?id=1872054 is now ON_QA
16:53:51 <cmurf> oh good
16:54:13 <adamw> #info again, easiest way to check this will be in Rawhide, adamw has sent a build of the same kde-settings to Rawhide so we can check the next Rawhide compose's results
16:54:46 <adamw> note the openQA test here failed, but that's actually expected given how KDE does backgrounds. it doesn't mean the fix didn't work.
16:55:46 <adamw> ideally i should actually tweak openQA update tests so we build a KDE live as well as a workstation one, and the background test runs on the newly-built live images...anyhoo
16:56:34 <adamw> #topic (1874117) 5.8.3-300.fc33.aarch64 kernel panic on boot (X-Gene PMU)
16:56:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1874117
16:56:34 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/59
16:56:34 <adamw> #info Accepted Blocker, kernel, VERIFIED
16:57:15 <adamw> #info bug comments indicate that https://bodhi.fedoraproject.org/updates/FEDORA-2020-5081eec059 fixes this, but it is not marked as fixing it
16:57:46 <adamw> #info i'll mark the update as fixing the bug, then it should get pushed stable soon and we'll be OK
16:58:07 <regenbogen> okay
16:58:18 <pwhalen> thanks adamw
16:58:58 <adamw> #topic (1860616) abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33
16:58:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1860616
16:58:58 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/15
16:58:59 <adamw> #info Accepted Blocker, libreport, ON_QA
16:59:01 <adamw> erf, this.
16:59:34 <cmurf> previous bug, does that mean all archs get 5.8.6 or just aarch64?
17:01:40 <adamw> cmurf: all arches
17:01:47 <cmurf> cuz there's gpu bugs present in 5.8.3, fixed in 5.8.4 and 5.8.6 might be nice to have it...
17:01:49 <cmurf> ok super
17:02:50 <adamw> #info we have two bugs - this one and the next, https://bugzilla.redhat.com/show_bug.cgi?id=1873029 - plus https://pagure.io/fedora-workstation/issue/156 which altogether boil down to: the whole abrt/libreport infrastructure is broken and it needs to work
17:02:59 <cmurf> i thought the arbt-server bug was fixed and the remaining issue is that the retrace service is still down?
17:03:11 <cmurf> yeah, eek
17:03:56 <adamw> #info there seem to be a number of specific problems, but our top-line expectation here is that we at least need sufficient functionality to successfully file crash reports.
17:04:06 <cmurf> agreed
17:04:10 <adamw> cmurf: the thing is, it ought to be able to file reports with retrace server down. it should just fall back to local generation
17:04:14 <adamw> if it doesn't, *that's* a bug
17:04:27 <cmurf> that's expensive
17:04:43 <cmurf> massive pile of debuginfos
17:04:47 <adamw> sure
17:05:13 <regenbogen> FWIW it's been a long time that ABRT doesn't work for me.
17:06:19 <cmurf> i do it anyway because i know it's a huge turn off for people
17:06:56 <cmurf> but what can we do?
17:08:19 <regenbogen> cmurf  That's a good question
17:08:32 <adamw> #action adamw to talk to abrt/libreport team again about expectations and practicalities here
17:08:49 <adamw> #topic (1873029) bugs can't be reported: "No matching actions found for this event"
17:08:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1873029
17:08:49 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/45
17:08:49 <adamw> #info Accepted Blocker, libreport, NEW
17:08:55 <adamw> #info see discussion on previous bug, all part of the same area
17:09:02 <adamw> #topic (1863041) systemd-resolved.service not work with DNS server placed behind VPN (openconnect)
17:09:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1863041
17:09:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/24
17:09:03 <adamw> #info Accepted Blocker, NetworkManager, NEW
17:09:33 <cmurf> oh they just keep getting better
17:09:45 <cmurf> so would it help if i clean installed rawhide on bare metal?
17:09:49 <regenbogen> (0-0)
17:10:00 <cmurf> and tested some of these versions so we can get them onto 33 media?
17:10:15 <cmurf> because right now 33 media has stale versions that are pointless to test further
17:10:57 <cmurf> or just push systemd-246.4 and nssmdns whatever -9
17:11:17 <cmurf> oh and authselect too i guess
17:11:33 <cmurf> regenbogen: it's complicated, you're confused because it's confusing :)
17:11:36 <adamw> those two updates just got pushed
17:11:41 <adamw> so next compose will have them
17:11:47 <adamw> is there an authselect update?
17:12:07 <adamw> yeah, i'm confused too
17:12:09 <cmurf> maybe it was spitballing an authselect update
17:12:16 <adamw> but my spidey sense says this whole resolved thing is going to be a disaster
17:12:19 <adamw> oh well
17:12:26 <cmurf> :D
17:13:06 <cmurf> well i had that sense from the get go expressly about mdns because you're right, it is fragile, and both systemd-resolved and avahi conflict when it comes to mdns
17:13:15 <cmurf> and then on top of it the whole weird /etc/nsswitch.conf madness
17:13:16 <adamw> #info systemd and nss-mdns updates were just pushed stable, so we can see how this works in the next compose
17:13:22 <regenbogen> cmurf:   I feel better now, it's not only me.  :-P
17:13:23 <cmurf> seriously folks do not hand edit that file
17:13:27 <adamw> yeah that's giving me the screaming heebie jeevies
17:13:30 <adamw> jeebies*
17:13:43 <cmurf> no joke, i could not figure out how to fix my system after hand editing it
17:13:49 <cmurf> i had to do a rollback
17:14:13 <regenbogen> Why people keep hand editing it then?
17:14:14 <cmurf> file system level rollback, rpm downgrade did't cut it
17:14:41 <cmurf> regenbogen: well i didn't know :) at first, and figured a one line change could be reverted
17:14:55 <cmurf> but no, that file gets eaten by other things and... it's a no
17:14:57 <cmurf> just no
17:15:19 <adamw> #topic (1871990) FreeIPA server upgrade from Fedora 32 or Fedora 31 fails with java.lang.UnsupportedClassVersionError
17:15:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1871990
17:15:19 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/34
17:15:19 <adamw> #info Accepted Blocker, pki-core, ASSIGNED
17:15:20 <cmurf> not people, just cmurf
17:15:27 <adamw> so far as i know, freeipa team still working on this.
17:16:19 <adamw> #info upstream PR appears to have been merged, just pinged the bug to ask if we can get a downstream build
17:16:25 <regenbogen> cmurf:  Why do you keep hand editing it then?
17:16:48 <cmurf> only once
17:17:17 * regenbogen looks askance at cmurf, not completely believing him
17:17:38 <adamw> i think there's a futurama meme for that :P
17:17:46 <adamw> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
17:17:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
17:17:46 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/16
17:17:46 <adamw> #info Accepted Blocker, sddm, NEW
17:17:48 <cmurf> ok maybe twice, it's possible one of them was so traumatic i've blocked it from memory
17:17:57 <adamw> cmurf: i keep telling you, that's what whiskey is for
17:18:15 <adamw> so this is the other worrying one atm because it's just...sitting here
17:18:21 <adamw> we are still waiting for input from devs
17:18:23 <cmurf> you have never ever ever given me drinking advice
17:18:46 <cmurf> except one or two or three times
17:19:14 <cmurf> oh yeah this....sddm?
17:19:23 <regenbogen> adamw  Oh I know this one!
17:19:42 <regenbogen> It's super weird.  It doesn't happen every time, at least for me.
17:19:55 <cmurf> yeah...i'm not getting the good kind of warm fuzzy with this bug
17:21:35 <cmurf> maybe it just needs a poke
17:21:47 <regenbogen> Any idea what causes it or...  anyting at all about it?
17:22:10 <adamw> regenbogen: that's what we're waiting for the developers to figure out from the logs kamil provided :/
17:22:27 <regenbogen> cmurf:  I have some long sticks for poking purposes.  Should I use them?
17:23:01 <regenbogen> adamw:  I can add some logs too, if it helps.
17:23:09 <regenbogen> It's with SDDM, right?
17:23:40 <adamw> regenbogen: yeah
17:24:26 <regenbogen> Okay, yes. I have it. I experienced this issue. Sometimes.
17:24:37 <regenbogen> Is there anything I can do to help?
17:26:38 <adamw> regenbogen: i'm not sure, any info you can get further than kparal's would be useful
17:26:47 <adamw> or if you can reproduce what kparal did and see if it looks the same or different in your case
17:27:34 <regenbogen> Okay. Noted.
17:27:58 <regenbogen> I'll try some testing and add what I find to the bug.
17:28:02 <adamw> thanks
17:28:14 <regenbogen> My pleasure.
17:28:56 <adamw> #info we're quite worried about this bug as it doesn't look easy to solve and there has not been a lot of action on it. kparal has provided what looks like sufficient info for developers to start looking into it.
17:29:00 <adamw> #topic Open floor
17:29:05 <adamw> that's everything on the lists
17:29:07 <adamw> any other business, folks?
17:29:14 <regenbogen> Not from my side.
17:30:23 * pwhalen has nothing else
17:32:16 <kparal> nothing here
17:32:25 <regenbogen> Okay, if there's nothing else for today, I'm leaving.
17:33:11 <coremodule> re some messages in #fedora-qa, i request we restart active bug triaging... and adamw spearheads the push
17:33:21 <coremodule> :D
17:34:50 <regenbogen> Okay, bye, see you. A pleasure to finally attend again.  Hope I can keep up. I'll test the SDDM issue. Tschuss!
17:53:34 <adamw> .fire coremodule
17:53:34 <zodbot> adamw fires coremodule
17:53:40 <adamw> thanks for coming, everyone (belatedly)
17:53:44 <adamw> #endmeeting