17:03:30 <adamw> #startmeeting F30-blocker-review
17:03:30 <zodbot> Meeting started Mon Mar  4 17:03:30 2019 UTC.
17:03:30 <zodbot> This meeting is logged and archived in a public location.
17:03:30 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:30 <zodbot> The meeting name has been set to 'f30-blocker-review'
17:03:30 <adamw> #meetingname F30-blocker-review
17:03:30 <zodbot> The meeting name has been set to 'f30-blocker-review'
17:03:30 <adamw> #topic Roll Call
17:03:39 <adamw> morning folks! who's around for super fun f30 blocker review times?
17:03:48 <jlanda> .hello2
17:03:49 <zodbot> jlanda: jlanda 'Julen Landa Alustiza' <julen@zokormazo.info>
17:04:06 * sumantro is here
17:04:14 * coremodule is here, ready to act as Secret Terry.
17:04:23 * satellit listening
17:04:23 <coremodule> *secretary
17:04:35 <lbrabec> .hello2
17:04:38 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com>
17:04:51 <bcotton> .hello2
17:04:52 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:05:30 <lruzicka> .hullo
17:05:39 <lruzicka> .hello lruzicka
17:05:40 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:06:06 <adamw> #info coremodule will secret terrialize
17:06:25 <adamw> (OK, that's officially the point at which no-one will ever understand that line in the minutes ever again)
17:06:34 <frantisekz> .hello2
17:06:35 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:06:43 <adamw> #chair bcotton lruzicka
17:06:43 <zodbot> Current chairs: adamw bcotton lruzicka
17:07:17 <coremodule> lol
17:07:42 <adamw> incoming boilerplate alert
17:07:42 <adamw> #topic Introduction
17:07:43 <adamw> Why are we here?
17:07:43 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:07:44 <adamw> #info We'll be following the process outlined at:
17:07:44 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:07:46 <adamw> #info The bugs up for review today are available at:
17:07:48 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:07:50 <adamw> #info The criteria for release blocking bugs can be found at:
17:07:52 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:07:54 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria
17:07:56 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria
17:09:48 <adamw> for Beta, we have:
17:09:49 <adamw> #info 3 Proposed Blockers
17:09:50 <adamw> #info 2 Accepted Blockers
17:09:54 <adamw> #info 2 Proposed Freeze Exceptions
17:10:01 <adamw> #info above was for Beta
17:10:10 <adamw> #info for Final, we have:
17:10:13 <adamw> #info 1 Proposed Blockers
17:10:24 <adamw> #info we will start with proposed Beta blockers
17:10:32 <adamw> #topic (1683197) gdm Fails to load with "nomodeset"
17:10:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1683197
17:10:32 <adamw> #info Proposed Blocker, gdm, NEW
17:11:14 <coremodule> +1
17:11:20 <sumantro> +1
17:11:23 <adamw> if this truly happens on any hardware, it seems reasonable
17:11:30 <adamw> would be nice to have more confirmation of that though
17:11:34 <adamw> has anyone else tried?
17:11:58 <lruzicka> I did not.
17:11:59 * pwhalen is here
17:12:18 <lruzicka> can test now
17:12:21 <jlanda> +1
17:13:14 <adamw> lruzicka: sounds good
17:14:21 <frantisekz> +1
17:14:23 <lruzicka> adamw, my VM froze
17:14:35 <lruzicka> so, I am +1 on this one
17:15:02 <adamw> oh, testing on metal would be more interesting than testing on VM
17:15:23 <jlanda> but vm gives and some kind of hardware agnostic test
17:15:24 <adamw> 1) there are only a few VM configurations, 2) nomodeset is much more practically useful on metal than on VMs
17:15:38 <adamw> a hardware agnostic test is exactly the *opposite* of what we want for a bug like this :)
17:15:40 <adamw> anyhow
17:16:07 <adamw> i think we can accept it for now with a note that it can be reconsidered if further testing indicates it
17:16:25 <lruzicka> I can test tomorrow on bare metal, thats no problem,
17:16:36 <lruzicka> testing it now would take some 10 minutes
17:16:46 <lruzicka> however, I can still do it if you wish, Adam
17:17:12 <adamw> proposed #agreed 1683197 - AcceptedBlocker (Beta) - for now we accept this as a violation of the cited criterion, note further testing on bare metal systems may cause a re-evaluation if the bug turns out not to happen in some cases
17:17:14 <pwhalen> +1
17:17:20 <adamw> nah, it's fine, we can do it as follow-up
17:17:22 <bcotton> +1
17:17:23 <coremodule> ack
17:17:24 <pwhalen> ack
17:17:25 <frantisekz> ack
17:17:32 <adamw> #agreed 1683197 - AcceptedBlocker (Beta) - for now we accept this as a violation of the cited criterion, note further testing on bare metal systems may cause a re-evaluation if the bug turns out not to happen in some cases
17:17:42 <adamw> #topic (1673710) [abrt] virt-manager: gst_caps_set_simple_valist(): python3.7 killed by SIGSEGV
17:17:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1673710
17:17:42 <adamw> #info Proposed Blocker, gstreamer1, NEW
17:18:24 <lruzicka> adamw, fyi I checked the BM computer here, it had Rawhide on it, does the same thing
17:18:28 <adamw> so, it seems clearly the case that both the 'supported' virt apps don't work right for graphical VMs in their default configs (using qxl / virtio)
17:18:57 <adamw> er, using SPICE, rather
17:19:05 <adamw> you can work around the problem by using VNC, not sure how easy that is for Boxes
17:19:30 <adamw> definitely +1 final for me, probably +1 beta, not sure the workaround is enough
17:19:51 <frantisekz> +1 beta blocker from me
17:20:40 <jlanda> +1 beta
17:20:44 <sumantro> +1 beta blocker
17:20:55 <coremodule> +1
17:21:04 <coremodule> +1 beta
17:21:06 <lruzicka> +1 beta blocker, you cannot workaround it properly because you receive no sound
17:21:55 <adamw> ok
17:23:08 <bcotton> +1 beta from me too
17:23:13 <adamw> proposed #agreed 1673710 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release". We note that using VNC can be considered a 'workaround', but still think the bug is a blocker, and note that it is not straightforward to do this in Boxes and it is not equal in quality to the default config
17:23:29 <frantisekz> ack
17:23:37 <jlanda> ack
17:23:40 <coremodule> ack
17:23:44 <sumantro> ak
17:23:47 <sumantro> ack
17:23:56 <bcotton> ack
17:25:29 <adamw> #agreed 1673710 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release". We note that using VNC can be considered a 'workaround', but still think the bug is a blocker, and note that it is not straightforward to do this in Boxes and it is not equal in quality to the default config
17:25:38 <adamw> #topic (1684612) Review Request: f30-backgrounds - Fedora 30 default desktop background
17:25:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1684612
17:25:38 <adamw> #info Proposed Blocker, Package Review, NEW
17:26:50 <adamw> so, this is basically the 'background must be different from previous releases' thing
17:26:58 <frantisekz> +1
17:27:01 <adamw> i'm fine with taking this bug as a proxy for it
17:27:19 <adamw> and at least it's happening now and not two days before release!
17:27:23 <jlanda> +1
17:27:27 <frantisekz> yay! :D
17:27:30 <coremodule> +1
17:27:46 <sumantro> +1
17:28:08 <lruzicka> +1
17:28:22 <bcotton> +1
17:28:56 <adamw> proposed #agreed 1684612 - AcceptedBlocker (Beta) - accepted as a violation of "The default desktop background must be different from that of the last two stable releases" (the new package needs to be approved, built and pushed in order to meet that criterion)
17:29:08 <sumantro> ack
17:29:12 <jlanda> ack
17:29:19 <lruzicka> ack
17:29:33 <coremodule> ack
17:29:35 <bcotton> ack
17:29:36 <frantisekz> ack
17:30:03 <adamw> #agreed 1684612 - AcceptedBlocker (Beta) - accepted as a violation of "The default desktop background must be different from that of the last two stable releases" (the new package needs to be approved, built and pushed in order to meet that criterion)
17:30:25 <adamw> #topic Proposed Beta freeze exceptions
17:30:40 <adamw> #info as we'll be in Beta freeze very shortly, let's review these next
17:30:52 <adamw> also note a new one has shown up since start of meeting, so we have 3
17:30:58 <adamw> #topic (1684808) dark theme in Mate leads to unreadable text
17:30:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1684808
17:30:58 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
17:31:10 <adamw> there's a screenshot in the bug, +1 FE for me, obviously can't be fixed with an update, and worth fixing
17:31:28 <adamw> i'm slightly worried about why anaconda did this in the first place and if just taking it out will affect something else, but...
17:31:40 <satellit> makes it very hard to use installer...only in mate
17:31:55 <jlanda> +1 FE
17:31:59 <satellit> +1 FE
17:32:36 <bcotton> +1 FE
17:32:42 <lruzicka> +1 FE
17:32:59 <sumantro> +1 FE
17:33:37 <adamw> proposed #agreed 1684808 - AcceptedFreezeException (Beta) - this bug makes it hard to read the installer in MATE and obviously cannot be fixed with an update
17:35:20 <bcotton> ack
17:35:26 <satellit> ack
17:35:30 <sumantro> ack
17:35:46 <jlanda> ack
17:36:01 <lruzicka> ack
17:36:56 <adamw> #agreed 1684808 - AcceptedFreezeException (Beta) - this bug makes it hard to read the installer in MATE and obviously cannot be fixed with an update
17:37:02 <adamw> #topic (1600444) Wrong conflicts between dnf and yum prevents upgrade
17:37:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1600444
17:37:03 <adamw> #info Proposed Freeze Exceptions, dnf, ASSIGNED
17:37:25 <adamw> i proposed this as an FE for 30 because we took it as an FE for 29, it's the same bug
17:37:42 <adamw> it prevents upgrade without --allowerasing in a fairly common scenario
17:39:34 <bcotton> i'm +1 FE but I also wonder if we're just going to be granting a freeze exception for this until the end of time
17:39:45 <adamw> there's no inherent reason why that should be the case
17:39:49 <adamw> it's just the dnf team being weird again
17:40:01 <adamw> i have no idea why they decided to "solve" this for f29 with a release-based conditional in the spec file
17:40:11 <adamw> and i pointed that out at the time, to which the response was crickets
17:41:40 <bcotton> fwiw, i had dinner with the DNF PM last week and am going to try to insert myself into their meetings a bit, so hopefully we'll get more of a voice in the future
17:41:51 <adamw> yay
17:43:33 <adamw> any other votes?
17:43:42 <jlanda> +1FE +1 bigger dinner budget for bcotton then
17:43:54 <bcotton> jlanda++
17:43:54 <zodbot> bcotton: Karma for jlanda changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:43:58 <lruzicka> but how does +1 FE solves the situation?
17:44:09 <jlanda> It doesn't really
17:44:33 <lruzicka> if we had that as a blocker it would make them act accordingly, right?
17:45:08 <lruzicka> We sit next to the dnf team here and I know how terribly busy they are, but why not do it once and properly?
17:45:08 <frantisekz> +1 FE , they are going to fix it even if it's FE
17:45:39 <frantisekz> also.... I don't think need to have --allowerasing should be blocker, definitely not the beta blocker
17:45:42 <adamw> lruzicka: granting the bug an FE does nothing to compel the dnf team to fix it in a non-silly way, but it does at least mean the bug can get fixed. :P
17:46:16 <lruzicka> adamw, the least we can do
17:46:18 <adamw> the reason for an FE for an upgrade bug, btw, is so that people who try and upgrade during the freeze can get the fix, since upgrades run with the repo config from the system being upgraded, and stable installs usually don't have updates-testing enabled, so upgrades usually run without packages from u-t
17:46:22 <satellit> +1
17:46:51 <pwhalen> +1 FE
17:47:02 <sumantro> +1 FE
17:47:41 <adamw> proposed #agreed 1600444 - AcceptedFreezeException (Beta) - accepted as this interferes with upgrades in a common case. Granting an FE allows a fix to go to F30 stable during freeze, so upgrades run without updates-testing enabled (the usual case) during freeze period will not hit the bug
17:47:41 <lruzicka> +1 FE
17:47:48 <lruzicka> ack
17:47:57 <sumantro> ack
17:48:04 <satellit> ack
17:48:47 <bcotton> ack
17:48:56 <pwhalen> ack
17:49:18 <adamw> #agreed 1600444 - AcceptedFreezeException (Beta) - accepted as this interferes with upgrades in a common case. Granting an FE allows a fix to go to F30 stable during freeze, so upgrades run without updates-testing enabled (the usual case) during freeze period will not hit the bug
17:49:27 <adamw> #topic (1677732) "Advanced Network Configuration" appears in "X-GNOME-Sundry" folder
17:49:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1677732
17:49:27 <adamw> #info Proposed Freeze Exceptions, gsettings-desktop-schemas, NEW
17:49:41 <adamw> i think some other things showed up in this weird folder too in recent composes, though i didn't look into it in detail
17:49:52 <adamw> abrt is one, it breaks the openQA desktop app test
17:50:06 <adamw> as this looks weird and is confusing i'm +1 FE
17:50:13 <adamw> (and it's in the workstation live so can't be fixed with an update)
17:50:24 <jlanda> Resume: upstream moved from 'System' to 'Utilities' and we have some garbage on gnome-shell. This is a SHOULD not a MUST in our criteria pointed guidelines, but it worth it
17:50:42 <lruzicka> +1FE
17:50:50 <bcotton> +1 FE. seems weird and shouldn't break anything to fix it
17:50:55 <lruzicka> adamw, my test is broken because of that?
17:50:57 <sumantro> +1 FE
17:51:06 <adamw> lruzicka: well, i mean, the test isn't broken
17:51:17 <adamw> but it fails :)
17:51:23 <jlanda> +1 FE
17:51:26 <adamw> just that step, all the other steps pass.
17:51:43 <lruzicka> adamw, shall I make it work or shall we wait until this gets fixed?
17:52:50 <pwhalen> +1 FE
17:53:32 <adamw> uh i'll look at it later
17:54:02 <adamw> proposed #agreed 1677732 - AcceptedFreezeException (Beta) - this will be visible and confusing in the Workstation live, so it's worth fixing and cannot be fixed with an update
17:55:06 <pwhalen> ack
17:55:11 <sumantro> ack
17:55:32 <lruzicka> ack
17:55:36 <bcotton> ack
17:55:37 <adamw> #agreed 1677732 - AcceptedFreezeException (Beta) - this will be visible and confusing in the Workstation live, so it's worth fixing and cannot be fixed with an update
17:55:43 <adamw> #topic Proposed Final blocker
17:55:49 <adamw> #info finally, we'll do the proposed Final blocker
17:55:52 <adamw> #topic (1683189) [abrt] gnome-remote-desktop: handle_socket_data(): gnome-remote-desktop-daemon killed by SIGABRT
17:55:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1683189
17:55:53 <adamw> #info Proposed Blocker, gnome-remote-desktop, MODIFIED
17:58:12 <adamw> so, crashes after you connect to a host then disconnect?
17:58:36 <bcotton> maybe this is moot because it appears to be fixed already, but.... it's not clear to me what the problem is. does the crash on disconnect prevent future connections?
17:58:44 <adamw> not sure either
17:58:51 <adamw> it's not exactly moot if we're frozen for beta soon either
17:58:57 <adamw> maybe punt for more info and consider a beta fe?
17:59:13 <bcotton> well moot for a final blocker, at least :-)
17:59:15 <lruzicka> it seems so. If you disconnect, then it fails and you cannot reconnect
17:59:34 <bcotton> but yeah. i'd favor a beta FE and see if we have to deal with it again later :-)
17:59:47 <frantisekz> I see in the comment: "Installing gnome-remote-desktop-0.1.7-1.fc30 the issue doesn't appear anymore."
18:00:11 <adamw> ah
18:00:15 <adamw> and that's tagged f30
18:00:22 <adamw> so should make the next compose if it's not in one already...
18:00:36 <frantisekz> if it's going to happen.... :D
18:00:49 <adamw> well, there has to be a compose before we can do a release =)
18:00:59 <adamw> i think easiest thing to do is just close it as FIXED...
18:01:27 <adamw> #info the fix for this is built and tagged f30 so will be in any future composes, thus no practical need to consider this bug, we will close it
18:01:29 <adamw> sound OK?
18:01:32 <bcotton> wfm
18:01:46 <lruzicka> yeah
18:02:14 <adamw> alrighty
18:02:17 <adamw> #topic Open floor
18:02:32 <adamw> any other business? new proposals, F30 release process related stuff...
18:03:56 <lruzicka> adamw, I can bring it up here ... I am not sure how to deal with modularity bugs
18:03:58 <bcotton> the blocker review email may come out early or very late this week since i'll be on the proverbial road
18:04:32 <adamw> bcotton: rgr
18:04:39 <adamw> lruzicka: how do you mean?
18:04:59 <lruzicka> I have tried to install every single module in F30 and lots of them:
18:05:03 <lruzicka> a) cannot be installed
18:05:20 <lruzicka> b) have profiles named default by they do not behave as default really
18:05:30 <lruzicka> c) some have no profiles at all
18:05:37 <lruzicka> d) some cannot be installed
18:05:47 <lruzicka> sorry, a and d is the same
18:06:04 <adamw> ok, and the question is...
18:06:39 <lruzicka> what is the difference between a feature and a bug here
18:06:46 <lruzicka> and what are moduler blockers?
18:06:53 <lruzicka> I think we do not have any rules set.
18:07:04 <adamw> sgallagh: any thoughts?
18:07:23 <lruzicka> I was told, for example, that some modules are not installable on purpose ... how shall I know as a tester
18:07:24 <lruzicka> :
18:07:26 <lruzicka> ?
18:07:51 <adamw> to me, so far as blocking *releases* goes, issues in a module can only be release blocker bugs if it's a default stream module and the bug prevents some feature in the criteria from working because it should be provided by that default stream module
18:07:57 <sgallagh> I’m in an all day meeting today and tomorrow.
18:07:59 <adamw> no bug in a module that isn't a *default* can block the release afaics
18:08:05 <adamw> sgallagh: rip :(
18:08:06 <sgallagh> Can we discuss this on Wednesday?
18:08:13 <adamw> sure
18:08:15 <lruzicka> sgallagh, yeah
18:08:21 <sgallagh> Thanks
18:08:33 <adamw> lruzicka: as for being a blocker *in the context of the module itself*...i think at least to an extent that's something the module itself gets to define
18:08:51 <adamw> i'm not sure if there are any specific standards/expectations like 'all modules must have a working default profile' or anything, that's why i pinged sgallagh
18:09:06 <adamw> or if there's a specific process to follow if any of those standards (if they exist) are not followed by a given module
18:09:08 <sgallagh> No, they need not
18:09:09 <lruzicka> adamw, in RHEL they started to call profiles common and not default to avoid misinterpretation
18:09:10 <adamw> but we should definitely find that out
18:09:45 <adamw> lruzicka: OK, so let's follow this up some more with sgallagh when he's less busy :)
18:09:48 <adamw> anything else?
18:09:52 <lruzicka> I will think about some questions for sgallagh and discuss it with him later.
18:09:57 <adamw> sounds good
18:10:26 <sgallagh> lruzicka: Actually, book an hour tomorrow with me. We are currently at a hackfest on Modularity and this would be a good topic to cover.
18:11:04 <lruzicka> ok, sgallagh, what time suits best?
18:11:11 <adamw> alrighty, let's wind up the meeting
18:11:14 <adamw> thanks for coming, folks
18:11:17 <adamw> see you next time!
18:11:18 <adamw> #endmeeting