16:01:48 <adamw> #startmeeting F33-blocker-review
16:01:48 <zodbot> Meeting started Mon Sep 14 16:01:48 2020 UTC.
16:01:48 <zodbot> This meeting is logged and archived in a public location.
16:01:48 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:48 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:01:48 <adamw> #meetingname F33-blocker-review
16:01:48 <adamw> #topic Roll Call
16:01:48 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:01:55 * kparal is here
16:02:00 <bcotton> .hello2
16:02:00 <adamw> ahoyhoy once more
16:02:00 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:05 <nb> .hello2
16:02:06 <zodbot> nb: nb 'Nick Bebout' <nick@bebout.net>
16:02:13 <Lailah> .fas lailah
16:02:15 <zodbot> Lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:02:41 <kalev> .hello2
16:02:45 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:02:59 <coremodule> .hello2
16:03:00 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:03:34 <adamw> #chair bcotton kalev
16:03:34 <zodbot> Current chairs: adamw bcotton kalev
16:03:44 * coremodule willing to secretarialize.
16:03:47 <adamw> impending boilerplate alert!
16:03:49 <adamw> thanks coremodule
16:03:51 <adamw> #topic Introduction
16:03:51 <adamw> Why are we here?
16:03:51 <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:03:52 <adamw> #info We'll be following the process outlined at:
16:03:52 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:54 <adamw> #info The bugs up for review today are available at:
16:03:55 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:57 <adamw> #info The criteria for release blocking bugs can be found at:
16:03:59 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:04:01 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:04:03 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:04:07 <adamw> #info for Beta, we have:
16:04:09 <adamw> #info 1 Proposed Blockers
16:04:11 <adamw> #info 7 Accepted Blockers
16:04:13 <adamw> #info 3 Proposed Freeze Exceptions
16:04:15 <adamw> #info 13 Accepted Freeze Exceptions
16:04:19 <adamw> #info for Final, we have:
16:04:24 <adamw> #info 2 Proposed Blockers
16:04:24 <adamw> #info 1 Accepted Blockers
16:04:36 <adamw> #info coremodule will secretarialize
16:04:38 <coremodule> I might have a new blocker to propose... just trying to find an appropriate criteria...
16:04:42 <adamw> without further ado, let's start with...
16:04:46 <adamw> #topic Proposed Beta blockers
16:04:56 <adamw> #topic (1878317) doesn't offer option to process stack traces locally
16:04:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1878317
16:04:57 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/86
16:04:57 <adamw> #info Proposed Blocker, abrt, NEW
16:05:04 <adamw> so this is more in the general category "abrt don't work"
16:05:23 <adamw> i feel like it's kinda the same thing as https://bugzilla.redhat.com/show_bug.cgi?id=1873029 maybe?
16:05:50 <kparal> it's a different bug
16:06:00 <kalev> I think it makes sense to make sure abrt works for the beta. no idea if it's the same bug or different :)
16:06:08 <lruzicka> .hello2
16:06:08 * pwhalen is here
16:06:08 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:06:26 <kparal> this bug is about abrt preventing local tracing when the remote server is down
16:06:42 <adamw> kparal: well, i thought that was effectively the issue in the other case too?
16:06:53 <kparal> I don't think so
16:07:09 <kparal> either way, I'm just testing an update that appeared 1h ago
16:07:19 <adamw> okay
16:07:27 <adamw> yeah they keep throweing out new updates
16:07:40 <adamw> i see cmurf's package list is newer than the one in your bug
16:07:51 <kparal> aaand the update is broken, this bug
16:07:53 <adamw> did you try with the same packages he tried with there?
16:08:02 <kalev> kparal's summary in the voting ticket is very good, I think:
16:08:04 <kalev> Also please note I'm voting for a blocker with a requirement that ABRT must be able to report a bug. Whether it allows a local tracing or remote tracing is, I believe, an implementation detail. But at least one option must work (and the other option must not be very prominently broken, that would make it seem as a basic functionality).
16:08:15 <adamw> kparal: there was an attempt over the weekend which still had a reportd built against old libreport
16:08:18 <adamw> same thing?
16:08:24 <michel_slm> .hello salimma
16:08:25 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
16:08:25 <kalev> I think I agree with this above that one of the two must work, but doesn't super much matter which
16:08:37 <kparal> I'm now testing: https://bodhi.fedoraproject.org/updates/FEDORA-2020-444a3363f0
16:08:46 <kparal> and I hit this bug
16:08:52 <adamw> anyhow, i guess i'm fine with accepting all bugs that fall under 'abrt won't report anything'
16:09:01 <cmurf> haha
16:09:22 <adamw> once we get an update that actually does allow us to report something, we can close 'em all...
16:09:24 <Lailah> Yeah, I've got a strange message from ABRT
16:09:36 <Lailah> And it falls under  "abrt won't report anything"
16:10:09 <cmurf> beta blocker on the basis that it won't report anything or offer the option to process locally?
16:10:18 <kparal> I think we can close the other two and keep just this one open, and push the update stable. It will not work, but if fixes the other two bugs at least
16:10:38 <cmurf> there is a basic functionality requirement that applies to the gui abrt, but that's a final release criterion
16:10:47 <Lailah> cmurf:  In my case it just didn't report. No options to process locally.
16:10:54 <adamw> cmurf: we're using the 'substantially hinders test coverage' thing
16:10:59 <cmurf> ok
16:11:02 <adamw> we accepted the other bugs of this kind on that basis
16:11:08 <adamw> so it's reasonable to take this one too
16:11:10 <adamw> so, votes?
16:11:11 <adamw> +1 blocker
16:11:13 <pwhalen> +1
16:11:17 <cmurf> +1 blocker
16:11:18 <Lailah> +1 blocker
16:11:22 <kparal> +1 beta blocker
16:11:22 <michel_slm> +1
16:11:28 <kalev> +1 beta blocker
16:11:31 <lruzicka> +1 bb
16:12:16 <adamw> proposed #agreed 1878317 - AcceptedBlocker (Beta) - accepted on the grounds that it "hinders execution of required Beta test plans or dramatically reduces test coverage", like the other similar bugs. we will sort out which bugs do and don't exist with which updates after the meeting
16:12:27 <cmurf> ack
16:12:27 <bcotton> ack
16:12:31 <kalev> ack
16:12:31 <lruzicka> ack
16:12:34 <Lailah> ack
16:12:42 <adamw> #agreed 1878317 - AcceptedBlocker (Beta) - accepted on the grounds that it "hinders execution of required Beta test plans or dramatically reduces test coverage", like the other similar bugs. we will sort out which bugs do and don't exist with which updates after the meeting
16:12:57 <adamw> OK, moving on to:
16:13:03 <adamw> #topic Proposed Beta freeze exceptions
16:13:10 <adamw> #topic (1878828) Include GNOME 3.38.0 in F33 Beta
16:13:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1878828
16:13:10 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/89
16:13:10 <adamw> #info Proposed Freeze Exceptions, distribution, NEW
16:13:18 <adamw> i'm gonna say, +1 if we slip
16:13:28 * kalev nods.
16:13:33 <adamw> let's test it, if we slip, put it in thursday or friday
16:13:43 <cmurf> +1 beta FE
16:13:44 <bcotton> +1 conditional on being no-go on thursday
16:13:56 <kalev> put it in as soon as we know that we slip, that leaves more time for testing/fixing
16:14:00 <michel_slm> +1 on putting it in after the no-go
16:14:01 <pwhalen> +1 conditional on being no-go on thursday
16:14:15 <kalev> +1 conditional on being no-go
16:14:18 <kparal> I have tracker-extract-3 stuck in a loop in my VM. That's part of the megaupdate, right? :(
16:14:20 <Lailah> +1 on conditional
16:14:38 <kalev> kparal: grr; can you file a bug upstream please? it is part of it
16:14:42 <cmurf> kparal: i have tried to reproduce and haven't so far, anything special?
16:14:55 <kalev> I'll ask garnacho to look at it
16:15:01 <adamw> proposed #agreed 1878828 - AcceptedFreezeException (Beta) - this is accepted as a major useful change that affects live images, but we will only pull it in if we slip this week and it tests out well in the meantime
16:15:11 <bcotton> ack
16:15:12 <kparal> kalev: I'll file it
16:15:12 <kalev> ack
16:15:15 <kalev> thanks kparal
16:15:17 <Lailah> ack
16:15:19 <kparal> ack
16:15:23 <pwhalen> ack
16:15:23 <adamw> (that includes fixing kparal's loopy thing :>)
16:15:25 <jlanda> ack
16:15:33 <adamw> #agreed 1878828 - AcceptedFreezeException (Beta) - this is accepted as a major useful change that affects live images, but we will only pull it in if we slip this week and it tests out well in the meantime
16:15:34 <cmurf> ack
16:15:50 <adamw> #topic (1878526) fedora-repos-modular-33-0.12 requires fedora-repos-rawhide
16:15:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1878526
16:15:50 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/88
16:15:50 <adamw> #info Proposed Freeze Exceptions, fedora-repos, ON_QA
16:15:58 <kparal> cmurf: nothing special, this happens all my life :(
16:16:14 <adamw> +1 FE because it'll affect install time package set, can't be fully fixed with an update
16:16:16 <cmurf> kparal: pretty sure nirik ran into it
16:16:21 <michel_slm> +1 FE
16:16:34 * nirik looks up
16:16:36 <lruzicka> +1fe
16:16:38 <bcotton> +1 FE
16:16:42 <kalev> +1 FE
16:16:42 <jlanda> +1fe
16:16:50 <pwhalen> +1 FE
16:16:51 <cmurf> nirik: the tracker2 loop thing
16:16:56 <cmurf> oops tracker3
16:17:03 <robatino> i originally gave the bodhi update a -1 but i'm pretty sure my testing was faulty. maybe someone can give it a +1 just to cancel mine out
16:17:04 <nirik> ah, yes. I hadn't reported it yet.
16:17:07 <Lailah> +1 FE
16:17:33 <adamw> robatino: will test it later
16:17:35 <nirik> kparal: can you cc me? :)
16:17:42 <kparal> nirik: sure
16:18:10 <adamw> proposed #agreed 1878526 - AcceptedFreezeException (Beta) - accepted as it'll affect live image and install time package sets and can't be fully fixed with an update, we don't want to pull rawhide repos into f33 installs
16:18:23 <coremodule> ack
16:18:28 <michel_slm> ack
16:18:29 <cmurf> ack
16:18:33 <bcotton> ack
16:18:34 <adamw> #agreed 1878526 - AcceptedFreezeException (Beta) - accepted as it'll affect live image and install time package sets and can't be fully fixed with an update, we don't want to pull rawhide repos into f33 installs
16:18:36 <lruzicka> ack
16:18:49 <adamw> #topic (1876162) anaconda storage configuration is extremely slow with an existing btrfs filesystem containing hundreds of snapshots
16:18:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1876162
16:18:49 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/64
16:18:49 <adamw> #info Proposed Freeze Exceptions, python-blivet, NEW
16:18:54 <adamw> so this one's a bit tricky it seems
16:19:05 <adamw> cmurf isn't confident the proposed change would be useful enough in 'real world' situations
16:19:12 <adamw> have you been able to test it yet?
16:19:19 <cmurf> yes, it helps
16:19:29 <cmurf> but my test case is overly simplistic
16:19:32 <adamw> even with snapshots that actually differ?
16:19:35 <cmurf> 500 snapshots, no differences between them
16:19:46 <cmurf> that's kinda time consuming
16:19:47 <adamw> ah right, was wondering if you'd managed a better test case
16:19:50 <cmurf> nope
16:20:00 <adamw> someone needs to do an old suse install and update it a few times :P
16:20:18 <Lailah> adamw:  Why not a new suse?
16:20:28 <adamw> because we'd need updates
16:20:29 <Lailah> To save updates...
16:20:34 <adamw> we want the updates
16:20:40 <adamw> those create the snapshots
16:20:44 <lruzicka> adamw, how many snapshots does it create with one such update?
16:20:48 <Lailah> Ooooohhh...
16:20:48 <cmurf> or just add/remove packages many times, separately
16:20:50 <Lailah> Right.
16:20:54 <Lailah> Got it, adamw
16:20:56 <cmurf> 2-4 snapshots per change
16:20:58 <lruzicka> cmurf, on suse?
16:21:01 <cmurf> yes
16:21:12 <cmurf> well it's not strictly susse
16:21:14 <cmurf> suse
16:21:16 <cmurf> it's snapper
16:21:28 <jlanda> Could neal have such a box?
16:21:33 <cmurf> the original reporter was actually using gentoo with snapper set up to have a rentention based on space available
16:21:38 <cmurf> so he ended up with 500
16:22:07 <cmurf> unfortunately that file system got obliterated in favor of fedora
16:22:42 <cmurf> same guy, hej, who did the kernel bisect over the weekend (he's getting a real fedora indoctrination!)
16:22:46 <adamw> hehe
16:22:56 <cmurf> anyway
16:23:17 <cmurf> like adamw i'm wondering what all the udevadm settles are for in the first place
16:23:24 <cmurf> if they're there they presumably are needed?
16:23:46 <adamw> cmurf: i mean, it's not *that* simple as things have changed a lot over time and they may just be a vestige
16:23:49 <adamw> but it'd be nice to know
16:23:57 <cmurf> if anaconda folks want to go this route i'm fine with it
16:24:01 <cmurf> yes
16:24:54 <adamw> so uh
16:24:56 <adamw> what do i vote
16:24:56 <adamw> :P
16:25:19 <cmurf> there are already enough FE's in the new app tracker
16:25:21 <adamw> i think i'm kinda +1 on principle, but we might choose not to put the change in in the end
16:25:29 <Lailah> adamw:  No idea. What would you like?
16:25:38 <bcotton> i'm a hesitant +1 FE
16:25:43 <adamw> bcotton: yeah
16:25:45 <cmurf> a stronger opinion from anaconda folks :)
16:25:47 <adamw> the issue in itself is worth an fe
16:26:15 <michel_slm> can we make it like the GNOME update? make it a FE if we slip
16:26:28 <Lailah> I'm 0 here because I don't have knowledge or experience enough with this to understand the issue.
16:26:40 <cmurf> maybe get the patch into rawhide and let openqa chew on it a while at least? *shrug*
16:26:53 <adamw> michel_slm: it's not so strongly tied to that for me, it's more about how dangerous it'd be to lose the settles plus how much losing them actually helps a real snapshot case
16:27:00 <adamw> cmurf: yeah, we could do that
16:27:47 <adamw> proposed #agreed 1876162 - AcceptedFreezeException (Beta) - this is accepted on the basis that it's a significant installer issue that can't be fixed with an update, but we may still decide the change is too dangerous or not worthwhile after more consideration/testing
16:27:57 <bcotton> ack
16:27:58 <cmurf> if we ran into a real case of 500 snapshots, i think we may see other issues entirely with all these mount/umount loops interrupting btrfs-cleaner
16:28:02 <cmurf> ack
16:28:03 <michel_slm> ack
16:28:07 <Lailah> ack
16:28:10 <lruzicka> ack
16:28:17 <cmurf> heck even 50 if the diffs are big enough
16:29:04 <coremodule> adamw, I added a proposed FE right as the meeting started (missed the FE sync)
16:29:06 <coremodule> ack
16:29:06 <cmurf> you know... maybe we need a long term test image of this sort of thing
16:29:12 <adamw> #agreed 1876162 - AcceptedFreezeException (Beta) - this is accepted on the basis that it's a significant installer issue that can't be fixed with an update, but we may still decide the change is too dangerous or not worthwhile after more consideration/testing
16:29:15 <lruzicka> cmurf, the snapshots could be made inside of a VM?
16:29:17 <cmurf> cuz i'm thinking it's not just snapper stuff
16:29:17 <adamw> cmoremod: it'll sync again in a minute
16:29:25 <cmurf> it's also containers
16:29:26 <adamw> cmoremod, that's your new name now
16:29:40 <cmurf> folks doing container things with btrfs sometimes have thousands of snapshots
16:29:46 <adamw> or else it's some horrific hybrid of cmurf and coremod
16:29:49 <coremodule> its pronounced "s'more-mod", if you please
16:30:05 <adamw> Just Doin' Container Things
16:31:08 * adamw resyncs manually
16:31:28 <coremodule> or "Seymour-mod", after the late-great Seymour Cray
16:32:21 <adamw> #topic (1878836) anaconda won't set hostname in KDE live
16:32:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1878836
16:32:21 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/90
16:32:21 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
16:32:29 <adamw> coremodule: this is it?
16:32:37 <coremodule> aye, thats the one
16:32:56 <Lailah> adamw:  I'm going to test that one as soon as I finish downloading the ISO
16:33:07 <coremodule> I just ran it in a VM too, (original bug was baremetal) and experienced the same thing
16:33:08 <adamw> uh. did you check if the installed system had the new hostname?
16:33:13 <adamw> i don't think it's intended to change it in the live env
16:33:23 <adamw> well, not 100% sure, really.
16:33:49 <Lailah> I don't remember having a problem when I installed my KDE Spin...
16:33:58 <cmurf> it might only do hostnamectl set-hostname while in the chroot at the end of the installation
16:34:04 <cmurf> post scripts stuff
16:34:04 <coremodule> I don't think that's right, just judging by the field next to the "Apply" button that lists the current host name. I could be wrong, but it seems misleading if that's the case (see the attached image for what I mean)
16:34:14 <cmurf> :D
16:34:16 <cmurf> i agree
16:34:37 <adamw> hmm, that's a point i guess
16:34:50 <cmurf> esp if it works differently between workstation and kde
16:34:55 <adamw> would be nice to know that
16:34:59 <adamw> i'm either +1 or punt for more info
16:35:24 <Lailah> Last time I installed KDE Spin, a couple of months ago, it changed just fine from that window you see in the screenshot.
16:35:37 <adamw> Lailah: ah, that's interesting, so it sounds like a regression...
16:35:44 <adamw> wonder if the tool anaconda uses is not on the kde live any more or something
16:35:50 <adamw> i don't recall how that's implemented off the top of my head
16:36:27 <lruzicka> I am +1 punt and test more.
16:36:33 <coremodule> Lailah is going to test later, and I can look into more info in the meantime if we want to punt.
16:36:47 <Lailah> It showed as changed there, and the change remained. When I rebooted into the installed system it was there.
16:37:09 <adamw> note of course we can vote in the voting system once we have more info
16:37:14 <adamw> no need to wait for another meeting
16:37:20 <coremodule> wfm
16:37:27 <coremodule> i will try workstation right now
16:37:41 <adamw> proposed #agreed 1878836 - punt (delay decision) - this looks like a good candidate but we could do with a bit more testing and info. once more info is available we will vote in the async voting system
16:37:52 <jlanda> ack
16:37:52 <coremodule> ack
16:38:04 <bcotton> ack
16:38:09 <adamw> #agreed 1878836 - punt (delay decision) - this looks like a good candidate but we could do with a bit more testing and info. once more info is available we will vote in the async voting system
16:38:13 <adamw> OK, we need to circle back to:
16:38:15 <adamw> #topic Proposed Beta blockers
16:38:19 <adamw> #info a new proposal came in
16:38:25 <adamw> #topic (1815392) avc:  denied  { write } for  pid=507 comm="systemd-journal" name="/" dev="dm-0"
16:38:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1815392
16:38:25 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/25
16:38:25 <adamw> #info Proposed Blocker, systemd, NEW
16:38:29 <jlanda> yay
16:38:37 <adamw> let me see what's going on here
16:38:57 <jlanda> A proxy error on my side
16:39:23 <adamw> huh?
16:39:25 <adamw> this is weird
16:39:33 <bcotton> this is a very confusing bug
16:39:35 <adamw> i don't know why this showed up in the list
16:39:44 <adamw> it is not marked as a proposed f33 beta blocker at all
16:39:48 <adamw> we must have a bug in blockerbugs
16:40:55 <bcotton> yeah, i have no idea why blockerbugs found it (among other questions i have about this bug)
16:41:03 <adamw> #info this is some kind of blockerbugs error, this bug is not proposed as an F33 blocker at all
16:41:04 <cmurf> cloned?
16:41:05 <coremodule> bug-ception
16:41:38 <adamw> #topic Proposed Final blockers
16:41:49 <Lailah> Good.  Some bug oddities to pepper the evening...
16:41:51 <adamw> #topic (1816547) Firefox not using langpacks for localization
16:41:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1816547
16:41:52 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/69
16:41:52 <adamw> #info Proposed Blocker, firefox, ASSIGNED
16:42:08 <adamw> there's +3 in the ticket
16:42:13 <adamw> from bcotton, kparal and sumantro
16:42:19 <adamw> so unless anyone is -1, this is looking accepted
16:42:20 <adamw> i'm also +1
16:42:31 <coremodule> +1 blocker
16:42:32 <Lailah> +1
16:42:36 <jlanda> +1 fb
16:42:42 <adamw> #info +3 votes in https://pagure.io/fedora-qa/blocker-review/issue/69 from bcotton, kparal, sumantro
16:42:45 <cmurf> this sounds familiar
16:42:51 <pwhalen> +1 fb
16:42:58 <cmurf> didn't we have this as a final blocker for f32?
16:42:59 <adamw> cmurf: yeah we had a similar bug for f32
16:43:02 <lruzicka> +1 fb
16:43:04 <jlanda> Yep
16:43:08 <michel_slm> +1 fb
16:43:15 <cmurf> +1
16:43:27 <adamw> proposed #agreed 1816547 - AcceptedBlocker (Final) - accepted as a violation of "All critical path actions on release-blocking desktops must correctly display all sufficiently complete translations available for use" (with precedent from a similar bug in F32)
16:43:31 <lruzicka> ack
16:43:32 <coremodule> ack
16:43:36 <cmurf> ack
16:43:44 <Lailah> ack
16:43:48 <adamw> #agreed 1816547 - AcceptedBlocker (Final) - accepted as a violation of "All critical path actions on release-blocking desktops must correctly display all sufficiently complete translations available for use" (with precedent from a similar bug in F32)
16:43:56 <adamw> #topic (1876162) anaconda storage configuration is extremely slow with an existing btrfs filesystem containing hundreds of snapshots
16:43:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1876162
16:43:56 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/64
16:43:56 <adamw> #info Proposed Blocker, python-blivet, NEW
16:44:00 <adamw> same bug as earlier for Beta FE
16:44:17 <adamw> i'm not sure i want to vote on final blocker without more testing/evaluation
16:44:32 <adamw> definitely one of those things where we might have to say 'it's just not plausible to fix this for f33'
16:44:47 <adamw> would be really useful to have a real-world test case with differences between the snapshots
16:45:26 <jlanda> let punt and find a suse boz with many snapshots
16:45:29 <adamw> so, i'm punt
16:45:57 <cmurf> +1 punt
16:46:02 <bcotton> +1 punt
16:46:04 <Lailah> +1 punt
16:46:04 <michel_slm> +1 punt
16:46:49 <adamw> proposed #agreed 1876162 - punt (delay decision) - we would like more evaluation from anaconda team and also testing with a real-world case (not identical snapshots) to figure out what's really plausible in an f33 timeframe before voting on this
16:47:14 <bcotton> ack
16:47:16 <Lailah> ack
16:47:18 <cmurf> ack
16:47:22 <adamw> #agreed 1876162 - punt (delay decision) - we would like more evaluation from anaconda team and also testing with a real-world case (not identical snapshots) to figure out what's really plausible in an f33 timeframe before voting on this
16:47:25 <adamw> okay
16:47:27 <adamw> i have to run out
16:47:39 <cmurf> adamw needs to get another arm
16:47:42 <Lailah> Run out of what?
16:47:43 * adamw hands reins to bcotton
16:47:49 * kalev has to leave as well
16:47:52 <cmurf> cat took his other one
16:47:53 <adamw> cmurf: i have to go get the abscess in my back looked at actually...
16:47:53 * bcotton is the captain now!
16:48:10 <adamw> bcotton: can either go through accepted blockers, or close out the meeting with open floor, up to you
16:48:13 <Lailah> adamw:  Oh, that sounds bad.
16:48:14 <adamw> cya later, folks
16:48:18 <cmurf> adamw sharks with laser beams and good aim
16:48:18 <adamw> Lailah: it wasn't super fun!
16:48:25 <coremodule> look at him. look at him. he's the captain now. *points to bcotton*
16:48:38 <Lailah> adamw:  I can imagine. Speedy recovery, old chap!
16:48:40 <bcotton> coremodule++
16:48:56 * Lailah staring at bcotton
16:49:05 <bcotton> #topic Fedora 33 Beta accepted blockers
16:49:16 <bcotton> #info Go/No-Go is Thursday
16:49:19 <bcotton> so
16:49:34 <bcotton> let's see if we can make any of these go away
16:49:47 * bcotton sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/bcXbbivYoIKSMDVasbITckXt/message.txt >
16:50:11 <bcotton> hmmm. does it not like multi-line via matrix?
16:50:13 <cmurf> oh interesting matrix snagged that
16:50:14 <bcotton> #undo
16:50:14 <zodbot> Removing item from minutes: INFO by bcotton at 16:49:16 : Go/No-Go is Thursday
16:50:27 <Lailah> bcotton:  It doesn't look very long to me...
16:50:29 <bcotton> weird, it just completely ignores it. good to know
16:50:36 <bcotton> #info Go/No-Go is Thursday
16:50:40 <bcotton> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
16:50:40 <cmurf> how does adamw avoid that? his lines are way longer
16:50:51 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
16:50:59 <bcotton> #link https://pagure.io/fedora-qa/blocker-review/issue/16
16:51:06 <bcotton> #info Accepted Blocker, dbus-broker, NEW
16:51:07 <Lailah> cmurf:  Because adamw is magic.
16:51:11 <cmurf> i guess
16:51:19 <bcotton> so this one is a hot potato of sorts
16:51:29 <cmurf> the dbus-broker thing
16:51:33 <Lailah> Oh... *this one*
16:51:35 <cmurf> so there's some discussion in the bug recently
16:51:42 <bcotton> more like dbus-broken, amirite?
16:51:47 <cmurf> heh
16:52:07 <Lailah> But there are people who tried with dbus-daemon and still get the same issue.
16:52:19 <Lailah> So I'm not convinced the problem is on dbus-broker
16:52:27 <cmurf> ugh
16:52:46 <Lailah> Also, I got to log out and in again while using Wayland.
16:52:52 <Lailah> I have no idea why.
16:52:59 <bcotton> yeah, this has been a "nobody is quite sure what the problem is" problem for a while. we were able to ignore that until we got silly and decided to create a release criterion for it
16:53:13 <Lailah> LOL
16:53:15 <Lailah> Damn
16:53:42 <bcotton> this is feeling like a "let's find an excuse to waive it" bug, though :/
16:53:51 <cmurf> well we have one of those
16:54:23 <cmurf> https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases
16:54:27 <cmurf> difficult to fix blocker bugs
16:54:40 <cmurf> for sure it's difficult to fix if you can't even locate the bug :)
16:54:44 <bcotton> right, it's just a matter of making a case for that :-)
16:54:56 <cmurf> we know something is wrong, but we don't know what the something is
16:55:35 <Lailah> Yeah...
16:55:43 <Lailah> I had that for ages with this bug.
16:56:00 <cmurf> it might be an argument for better logging somewhere
16:56:09 <bcotton> anyone have anything meaningful to add on this for now?
16:56:14 <cmurf> nope
16:56:17 <Lailah> Not really.
16:56:51 <Lailah> I'll test again when I finish downloading the Spin, but I'm not holding my breath.
16:57:18 <bcotton> #topic (1849430) Fedora 33: Everything boot x86_64 image exceeds maximum size
16:57:25 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1849430
16:57:27 <bcotton> is also
16:57:36 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1849431
16:57:48 <bcotton> sgallagh are you around?
16:57:59 <sgallagh> For about three minutes, yes
16:58:16 <bcotton> any updates on shrinkifying the image?
16:58:23 <sgallagh> "It's hard"
16:58:32 <cmurf> what got bigger?
16:58:41 <sgallagh> cmurf: Short answer: everything
16:58:43 <cmurf> ha
16:58:47 <cmurf> i regret asking now
16:58:55 <sgallagh> Longer answer: Mostly linux-firmware
16:59:03 <cmurf> oh yeah that
16:59:12 <cmurf> that is unreasonble
16:59:14 <bcotton> eh, who needs firmware anyway
16:59:17 <cmurf> but it's worse to not include it
16:59:22 <cmurf> i wonder if it can be subset
16:59:23 * mclasen thinks thats the fastest-growing package
16:59:39 <sgallagh> I have tdawson looking into places we can trim, but I haven't gotten an update from him in a bit (my fault, not his)
16:59:43 <sgallagh> Let me reach out.
17:00:06 <bcotton> awesome
17:00:20 <bcotton> #info Main cause appears to be growth in linux-firmware
17:00:28 <bcotton> #info tdawson is looking into places we can trim
17:01:14 <bcotton> anything this group can do to help at this point?
17:02:32 <cmurf> not really, not our fault
17:02:34 <cmurf> du -sh /usr/lib/firmware
17:02:36 <cmurf> 412M /usr/lib/firmware
17:03:07 <sgallagh> This group specifically? Niot sure. Any individuals who maintain packages on the CD could look and figure out if they can trim out any dependencies
17:03:09 <sgallagh> Or soften them
17:03:11 <cmurf> it does compress down somewhat
17:03:17 <sgallagh> (We only pull strict deps on the media)
17:03:55 <bcotton> ok
17:05:10 <bcotton> #topic libreport bugs (1860616 and 1873029)
17:05:18 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1860616
17:05:24 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1873029
17:07:08 <bcotton> anything to add here? it seems like this is a maze of twisty little bugs, all alike
17:07:22 <cmurf> "make it go"
17:08:36 <Lailah> bcotton: No idea, looks messy to me.
17:08:44 <bcotton> yeah :/
17:10:18 <bcotton> #topic (1863041) systemd-resolved.service not work with DNS server placed behind VPN (openconnect)
17:10:30 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1863041
17:10:37 <bcotton> #info Accepted Blocker, NetworkManager, NEW
17:10:53 <bcotton> this one got reopened
17:11:15 <michel_slm> oof
17:12:37 <bcotton> it looks like the issue has meandered from what was originally reported
17:13:56 <cmurf> oh dear, that always makes for rough reading
17:14:24 <bcotton> although i suppose it's still "not working", it's just "not working" in a different way
17:15:13 <cmurf> is it worth asking for a summary comment?
17:15:30 <bcotton> i think so
17:15:41 <bcotton> #action bcotton to ask for updated summary in the bug
17:15:49 <cmurf> the backlog is too long...
17:17:29 <bcotton> okay, so let's look at the other related bug...
17:17:44 <bcotton> #topic (1873856) resolv.conf misconfigured on fresh install
17:17:48 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1873856
17:17:54 <bcotton> #link https://pagure.io/fedora-qa/blocker-review/issue/53
17:18:00 <bcotton> #info Accepted Blocker, systemd, ASSIGNED
17:18:25 <Lailah> Folks! I have to leave, sorry.  See you later.
17:18:39 <bcotton> #info There's a proposed fix (to remove /etc/resolv.conf and replace it with a symlink on install)
17:18:53 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1873856#c14
17:21:30 <bcotton> i guess i'll nudge the maintainers to see what they think of it
17:21:51 <bcotton> #action bcotton to nudge the maintainers to see what they think of the proposed fix
17:22:03 <bcotton> #topic Open floor
17:22:11 <bcotton> Anything else for today?
17:22:54 <sgallagh> bcotton: I guess I have to ask: how likely is the netinstall iso size issue to block the release if we had go/no-go this week?
17:23:19 <bcotton> i mean, it's a blocker so in theory 100%
17:23:25 <sgallagh> Actually, let me give my update first.
17:23:54 <sgallagh> It turns out that adamw has made a bunch of changes in Rawhide that have shrunk the ISO quite a lot. (Yay!)
17:23:56 <bcotton> #topic Image size blockers (1849430 and 1849431)
17:24:12 <sgallagh> It is still larger than 700 MiB (less yay) at 704 MiB
17:24:28 <bcotton> #info adamw has made a bunch of changes in Rawhide that have shrunk the ISO quite a lot, but still over size
17:24:37 <jlanda> We can remove 4 random mbs
17:24:43 <sgallagh> Those changes haven't yet made it down to F33, so I don't know for sure if it will be small enough there.
17:24:45 * jlanda runs
17:24:59 <sgallagh> jlanda: That's about the size of systemd, right? :-D
17:25:47 <sgallagh> But my question is this: Would this issue pass the "last blocker at Go/No-Go" test?
17:26:26 <sgallagh> I don't think it would; I suggest we'd probably just not ship the netinst for Beta and advise people to use the Server DVD for network installs.
17:26:30 <bcotton> personally, it would not. but from a process standpoint, i'm not sure we have good excuse to ignore our rules in that case
17:27:30 <sgallagh> Well, the justification is this: the size restriction is due to the "requirement" that it fits on an outdated media format
17:27:31 <lruzicka> sgallagh, bcotton Well, I would rather live with a netinst that is slightly over the line than to not have it at all ...
17:28:07 <sgallagh> lruzicka: Yeah, I agree; Consider that revised to say "Release noted" or something.
17:28:21 <sgallagh> Because it would still fit on a 1 GiB USB thumbdrive or a DVD
17:28:36 <lruzicka> sgallagh, bcotton: this is intended for CDs, but if it does not fit on a CD, it still can fit onto a small USB, if we give up on that, then people would have to download 2Gib for a netinstall.
17:28:39 <sgallagh> Both of which are far more readily-available than CDs at this point
17:28:41 <bcotton> yeah, i'd be real curious who we alienate if a physical CD isn't an option
17:29:00 <sgallagh> bcotton: I think we should still block GA on this
17:29:06 <lruzicka> bcotton, we tried last time, there was quite an outcry on the list
17:29:25 <bcotton> outcry on mailing lists and actual impact are different matters :-)
17:29:28 <sgallagh> Because there *are* probably valid cases, but I'm not sure Beta is necessarily the right place.
17:29:38 <cmurf> yeah
17:29:43 <lruzicka> bcotton, there are people there who still burn CDs and use it for installations.
17:29:51 <coremodule> I use CD's exclusively. A buddy says, "hey coremodule, can I get a copy of that blocker review meeting log?", and I say "Sure buddy, let me just burn it to a CD, it'll only take 10 minutes."
17:29:53 <cmurf> there are servers out there with optical drives for doing installs
17:29:58 <cmurf> but they also can handle dvds
17:30:08 <michel_slm> for people who burn CDs, are DVDs not an option?
17:30:08 <cmurf> even the ones with glued usb ports
17:30:15 <bcotton> but yeah, waiving for beta and not for GA seems like a reasonable compromise if we don't have other blockers
17:30:28 <sgallagh> lruzicka: There are still people who use 3.5" floppy drives, but I don't much care about them either :-P
17:30:29 <lruzicka> bcotton, I would be +1 on this one
17:30:30 <cmurf> i can't imagine there are any practical cases where dvd is not ok
17:31:03 <lruzicka> sgallagh, saw Sheldon Cooper using it for his hatelist ... the floppy did not work and he could not read it
17:31:04 <coremodule> I think CD's (and DVD's for that matter) have gone the way of i386...
17:31:07 <cmurf> at this point in the year 2020, weird ancient junk all can read dvd
17:31:25 <coremodule> We got noise on the list when i386 was dropped but...
17:31:59 <bcotton> i do think there's some value in keeping the netinst "small", but "small" doesn't necessarily have to be "fits on a physical CD"
17:32:04 <cmurf> right
17:32:08 <sgallagh> Agreed
17:32:32 <cmurf> the way opensuse deals with this, is they have a significant payload downloaded during startup phase
17:32:37 <bcotton> but we don't have to decide anything now. we have plenty of blockers to fix in the next couple of days for this to matter
17:32:44 <cmurf> their netinstall is something like 250M
17:33:06 <sgallagh> Personally, I've been wanting for years for us to create a tool in Weldr/Cockpit to trivially set up a PXE boot environment which would sidestep this entirely
17:33:07 <cmurf> but the whole environment isn't present, in fact i think the installer itself is downloaded
17:33:41 <bcotton> so basically it's a self-contained downloader for the installer?
17:33:55 <cmurf> yeah
17:33:58 <sgallagh> cmurf: I think it's very similar to how our boot-from-install-tree works for libvirt
17:34:35 <sgallagh> It might be worth exploring whether we could have a similar approach for general use.
17:34:52 * bcotton looks forward to sgallagh's f34 change proposal ;-)
17:34:53 <nirik> we could have a stage1 and a stage2 to the installer... oh wait, we did for a long time and scrapped it. ;)
17:35:02 <cmurf> haha
17:35:12 <cmurf> everything old is new again
17:35:32 <lruzicka> cmurf, as always
17:35:58 <cmurf> i liked the bfo project, that was pretty cool - it was just slow because the internet was slow
17:36:04 <cmurf> for the use case we're talking about, it's not a factor
17:36:22 <bcotton> phase 1: steal installer.  phase 2: ???.  phase 3: profit!
17:36:36 <cmurf> underinstaller gnomes
17:36:57 <nirik> you can use https://netboot.xyz/ if you like ipxe.
17:37:09 <bcotton> #topic Open floor
17:37:22 <bcotton> anything else to discuss, apart from underinstaller gnomes>
17:37:59 <cmurf> nope
17:38:13 <lruzicka> not here
17:38:45 <bcotton> okay, then!
17:39:05 <bcotton> thanks everyone, let's go gently put some bugs outside so they can live fulfilling lives without causing problems for us
17:39:08 <bcotton> #endmeeting