16:00:09 <coremodule> #startmeeting F29-blocker-review
16:00:09 <zodbot> Meeting started Mon Oct 22 16:00:09 2018 UTC.
16:00:09 <zodbot> This meeting is logged and archived in a public location.
16:00:09 <zodbot> The chair is coremodule. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:09 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:00:09 <coremodule> #meetingname F29-blocker-review
16:00:09 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:00:09 <coremodule> #topic Roll Call
16:00:15 <frantisekz> .hello2
16:00:15 <coremodule> Good morning everyone!
16:00:16 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:00:45 <bcotton> .hello2
16:00:47 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:00:49 * kparal is here, mostly available, perhaps
16:00:58 <coremodule> hi kparal :)
16:01:17 <coremodule> hi frantisekz and bcotton
16:01:19 <stickster> .hello pfrields
16:01:20 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
16:01:23 <lruzicka> .hello2
16:01:27 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:01:29 <frantisekz> hi coremodule :)
16:01:39 <coremodule> I guess it's not morning everywhere... but it is 5 o'clock somewhere.
16:01:41 <stickster> Here for one WS topic when it comes up... also need to cram food in my face simultaneously so relocating
16:01:47 <roshi> .hello2
16:01:48 <zodbot> roshi: roshi 'Mike Ruckman' <roshi@mykolab.com>
16:02:09 <coremodule> Who wants to secretarialize today?
16:02:54 * satellit listening
16:02:57 * nirik is lurking
16:02:59 <frantisekz> coremodule: will handle it :)
16:03:06 <lruzicka> frantisekz++
16:03:06 <zodbot> lruzicka: Karma for frantisekz changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:03:15 <coremodule> thanks frantisekz :)
16:03:25 <coremodule> #chair frantisekz bcotton
16:03:25 <zodbot> Current chairs: bcotton coremodule frantisekz
16:03:36 <frantisekz> you are leading all the meetings, so I can help you at least this way :D
16:03:42 <coremodule> well, lets get started!
16:03:49 <coremodule> #topic Introduction
16:03:49 <coremodule> Why are we here?
16:03:49 <coremodule> #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:49 <coremodule> #info We'll be following the process outlined at:
16:03:50 <coremodule> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:51 <coremodule> #info The bugs up for review today are available at:
16:03:53 <coremodule> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:57 <coremodule> #info The criteria for release blocking bugs can be found at:
16:03:59 <coremodule> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:04:01 <coremodule> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:04:03 <coremodule> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:04:15 <coremodule> #info Proposed Blockers
16:04:29 <coremodule> #topic (1636739) kickstart doesn't find standard repos Fedora 29 beta Everything netinst (metalink False)
16:04:30 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636739
16:04:30 <coremodule> #info Proposed Blocker, anaconda, MODIFIED
16:05:19 <frantisekz> +1 B
16:06:00 * satellit worked for me last week in vm
16:06:04 <nirik> +1 blocker. nice that there's a fix already.
16:06:10 <lruzicka> Today, I had a visitor from Anaconda team, who told me that they already have fixed this, tested it and merged in a "big bunch of updates". If we accept it as a blocker, it will be dealt away right on.
16:06:17 <bcotton> +1 blocker
16:06:21 <lruzicka> +1 blocker
16:06:49 * nirik does not like 'big bunch of updates' ;(
16:07:08 <stickster> unless each "update" is "specific bugfix"
16:07:32 <lruzicka> I do not know what that was supposed to mean.
16:07:39 <nirik> for an accepted blocker or fe. ;)
16:07:40 <frantisekz> just noting: we'll pull the fix with the new dnf 4 anyway
16:07:47 * pwhalen is here
16:07:56 <nirik> yeah, looks like it's in there already.
16:07:58 <lruzicka> I thought that they probably added it to more anaconda fixes-
16:08:00 <coremodule> proposed #agreed 1636739 - AcceptedBlocker - WE find this bug is a violation of the following criteria: "The installer must be able to use all supported local and remote package and installer sources." We note that the anaconda team says a fix has been submitted and merged and will be available ASAP.
16:08:08 <lruzicka> ack
16:08:11 <bcotton> ack
16:08:11 <roshi> ack
16:08:11 <pwhalen> +1 blocker/ack
16:08:12 <frantisekz> ack
16:08:20 <coremodule> #agreed 1636739 - AcceptedBlocker - WE find this bug is a violation of the following criteria: "The installer must be able to use all supported local and remote package and installer sources." We note that the anaconda team says a fix has been submitted and merged and will be available ASAP.
16:08:32 <coremodule> #topic (1637418) Switching keyboard layouts is not working without relogin/reboot
16:08:32 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637418
16:08:32 <coremodule> #info Proposed Blocker, gnome-shell, NEW
16:08:48 <lruzicka> +1 blocker
16:09:00 <roshi> +1
16:09:02 <frantisekz> Workstation WG voted +1B
16:09:19 <kparal> +1
16:09:21 <frantisekz> so it's blocker anyway If I am not mistaken
16:09:38 * satellit saw this in previous bug : https://bugzilla.redhat.com/show_bug.cgi?id=1631920
16:09:44 <lruzicka> yesterday's non-blocker is a today's blocker.
16:09:57 <lruzicka> kparal was right about the status last time. :)
16:09:59 <bcotton> +1 b if WS says so
16:10:18 <coremodule> #info Workstation WG voted +1 blocker
16:10:19 <pwhalen> +1
16:10:23 <stickster> Indeed, the keyboard switching bug was voted +1 blocker this morning because it basically makes the Live image unusable for anyone non-USA
16:10:50 <stickster> or, s/anyone/many people/
16:10:52 <coremodule> proposed #agreed 1637418 - AcceptedBlocker - We find this bug to be a violation of the following blocker criteria: "Default panel functionality - All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
16:10:55 <coremodule> whoops
16:11:35 <coremodule> proposed #agreed 1637418 - AcceptedBlocker - We find this bug to be a violation of the following blocker criteria: "Default panel functionality - All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." We note that the Workstation WG has voted +1 blocker on this bug.
16:11:47 <lruzicka> ack
16:11:49 <roshi> ack
16:11:56 <frantisekz> ack
16:11:57 <bcotton> ack
16:12:04 <coremodule> #agreed 1637418 - AcceptedBlocker - We find this bug to be a violation of the following blocker criteria: "Default panel functionality - All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." We note that the Workstation WG has voted +1 blocker on this bug.
16:12:06 <satellit> ack
16:12:18 <coremodule> #topic (1636271) LSI mpt3sas driver not in kernel
16:12:18 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636271
16:12:18 <coremodule> #info Proposed Blocker, kernel, MODIFIED
16:12:30 <frantisekz> what the hell is mpt3sas for?
16:12:39 <coremodule> hahaha
16:13:11 <coremodule> well, whatever it is, the fix is already available in the latest kernel.
16:13:57 <frantisekz> we should find some criterion for it, I tried to do some google thingie but didn't find anything useful and simple yet (aka ELI5)
16:14:19 <coremodule> hmm, it's a sas driver...
16:14:30 <coremodule> https://access.redhat.com/errata/RHEA-2016:1930
16:14:32 <stickster> It's a driver for an LSI brand SAS controller AFAICT
16:15:16 <lruzicka> -1 blocker, +1 fe
16:15:27 <bcotton> -1 b, +1 fe
16:15:35 <frantisekz> hmm, the fix is available, why not to pull it, but making it just FE makes sense
16:15:37 <lruzicka> I am not sure that there is a criteria for a specialized driver.
16:15:41 <stickster> If I get a vote, -1 B, +1 FE.
16:15:52 <frantisekz> it will get pulled anyway, we have plenty of time before the release... :D
16:15:55 <kparal> https://fedoraproject.org/wiki/Basic_Release_Criteria#storage-interfaces
16:16:14 <kparal> it leads to testcase SAS but SAS is not mentioned in "what are they"
16:16:18 <coremodule> ^^kparal
16:16:18 <kparal> so take your pick
16:16:48 <lruzicka> the test case says: All installable SAS devices are successfully detected by installer and are available for partitioning.
16:16:52 <stickster> kparal: That can't be a criterion here, because without including mpt3sas in the kernel, that interface isn't supported. ;-)
16:17:08 <lruzicka> in that case, I might revote +1 blocker
16:17:16 <frantisekz> but that's just one driver if i understand it correctly
16:17:32 <frantisekz> anyway... looks like it doesn't matter if it's blocker or just FE
16:17:33 <kparal> lruzicka: the test case doesn't define blockers, criteria do
16:17:33 <coremodule> probinson's description in-bug doesn't specify if this is an installer issue, or after the system has been loaded. I think we could play semantics there and go either way...
16:17:38 <lruzicka> frantisekz, which will spoil the installation if you happen to have that device
16:17:43 <stickster> lruzicka: Logically, it can't be a blocker on that criterion though. Until the driver is in the kernel, it couldn't possibly be considered supported by Fedora. ;-D
16:17:47 <pwhalen> +1 as noted in c#3 it affects a number of aarch64 hw
16:18:04 <lruzicka> kparal, but the test case gives me guidelines how to understand the criteria
16:18:15 <frantisekz> +0B / +1 FE for me
16:18:18 <coremodule> I am +1 blocker, especially since the fix is already in place and available.
16:18:29 <bcotton> revote to +1 b
16:18:34 <stickster> lol
16:18:46 <coremodule> based on kparal's criteria given above.
16:18:54 <kparal> give me a sec to read the bug
16:19:23 <lruzicka> stickster, I get your point :) However, if I have that SAS device and it did not work for me, I'd be pissed.
16:19:44 <coremodule> agreed. Especially if it worked with previous kernels/releases.
16:20:06 <kparal> did it? it sounds like a it's a new driver
16:20:33 <coremodule> The installer case is the big one, if this prevents a user from installing, then this is definitely a blocker.
16:20:35 <coremodule> hmm
16:20:36 <stickster> lruzicka: You could say the same about any device whose driver is not in the kernel, though. Was this driver, or a predecessor, previously in?
16:20:55 <coremodule> lets ping probinson and see if he's around.
16:21:16 <lruzicka> stickster, I do not know ... never had a sas device.
16:22:02 <coremodule> i dont think it's new, based on this:
16:22:02 <coremodule> https://access.redhat.com/errata/RHEA-2016:1930
16:23:24 <stickster> I don't think it's whether it's *new* as in "not old" that's the case here. It's whether the module is included by default. If that state hasn't changed, this is just a request for it to be included. And it can't be a blocker by the criterion.
16:23:46 <lruzicka> so, let's have another say .... technically, both a blocker and an FE works since we have it already.
16:23:49 <stickster> Anyway, I'm <eof/> on this one. It's going to end up included shortly either way.
16:24:02 <coremodule> But if it's included in RHEL, shouldn't it be included in Fedora as well?
16:24:30 <coremodule> And if it has been in RHEL since at least 2016, doesn't that mean we've supported it in Fedora-land since at least then?
16:24:34 <stickster> coremodule: there are drivers in RHEL that Fedora doesn't include. I think Fedora got rid of floppy driver well before RHEL for instance. That's not a criterion.
16:24:41 <kparal> accept as FE, punt on blocker, include it, done
16:24:45 <lruzicka> sticker
16:24:45 <stickster> kparal++
16:24:47 <zodbot> stickster: Karma for kparal changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:24:50 <frantisekz> let's do FE, we won't have to argue :D
16:24:59 <kparal> 0 blocker, +1 fe
16:25:02 <lruzicka> sorry, stickster, FE would do all right in the end
16:25:14 <pwhalen> we also have another FE for the same kernel version
16:25:15 <lruzicka> +1 fe then
16:26:27 <coremodule> proposed #agreed 1636271 - AcceptedFreezeException - We find this bug worthy of AcceptedFreezeException status as the fix is already available and we can't find specifics regarding if the mpt3sas driver has been included in Fedora before or if it is a new addition.
16:26:33 <bcotton> ack
16:26:38 <frantisekz> ack
16:26:39 <pwhalen> ack
16:26:44 <lruzicka> äck
16:26:44 <coremodule> #agreed 1636271 - AcceptedFreezeException - We find this bug worthy of AcceptedFreezeException status as the fix is already available and we can't find specifics regarding if the mpt3sas driver has been included in Fedora before or if it is a new addition.
16:27:18 <coremodule> #info moving on to AcceptedFreezeExceptions
16:27:32 <frantisekz> Proposed maybe?
16:27:41 <coremodule> whoops!
16:27:47 <coremodule> #undo
16:27:47 <zodbot> Removing item from minutes: INFO by coremodule at 16:27:18 : moving on to AcceptedFreezeExceptions
16:28:12 <coremodule> #agreed 1636271 - AcceptedFreezeException - We find this bug worthy of  RejectedBlocker AcceptedFreezeException status as the fix is already available and we can't find specifics regarding if the mpt3sas driver has been included in Fedora before or if it is a new addition.
16:28:17 <coremodule> darn it
16:28:30 <kparal> .fire coremodule
16:28:30 <zodbot> adamw fires coremodule
16:28:36 <coremodule> #agreed 1636271 - RejectedBlocker AcceptedFreezeException - We find this bug worthy of AcceptedFreezeException status as the fix is already available and we can't find specifics regarding if the mpt3sas driver has been included in Fedora before or if it is a new addition.
16:28:39 <coremodule> There!
16:28:40 <coremodule> hah
16:28:50 <lruzicka> How can adamw fire someone when he is on a vacation?
16:28:53 <coremodule> hmm...
16:28:56 <coremodule> .fire adamw
16:28:56 <zodbot> adamw fires adamw
16:29:01 <kparal> we rejected it as a blocker?
16:29:07 <frantisekz> yes
16:29:12 <lruzicka> a suicide now?
16:29:12 <roshi> adamw knows know limits in where or how he can fire people
16:29:15 <kparal> ok, I guess I missed it
16:29:31 <coremodule> #info moving on to Proposed Freeze Exceptions
16:29:43 <coremodule> #topic (1640409) Atomic Host Installclass detection not working
16:29:44 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1640409
16:29:44 <coremodule> #info Proposed Freeze Exceptions, anaconda, ON_QA
16:30:24 <coremodule> +1 FE
16:30:28 <frantisekz> let's skip all the anaconda/dnf FEs
16:30:35 <frantisekz> they'll get pulled with dnf 4
16:30:41 <frantisekz> no matter what we decide
16:30:58 <kparal> well that definitely shouldn't be the case
16:31:13 <frantisekz> it's in one update (anaconda depends on dnf somehow)
16:31:22 <frantisekz> already pushed stable
16:31:36 <kparal> if it's pushed stable, just close it
16:31:55 <frantisekz> it'll close itself
16:32:00 <coremodule> ah, it is stable
16:32:16 <kparal> ok, it makes sense to skip those
16:32:38 <coremodule> #info skipping all anaconda/dnf fe's as the updates surrounding those are already stable
16:32:47 <coremodule> #topic (1641268) dracut-network: iscsi module causes device timeout on boots with resume= cmdline arg
16:32:47 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1641268
16:32:47 <coremodule> #info Proposed Freeze Exceptions, dracut, NEW
16:34:15 <coremodule> The long wait time is annoying
16:35:48 <coremodule> I have pinged dustymabe for more info here as to what the fix would look like
16:36:01 <lruzicka> I am not sure, +1 FE perhaps, however the fix might not be ready anyway ...
16:36:09 <frantisekz> it'd be great to know if the fix is somehow isolated
16:36:11 * bcotton is relocatiing
16:36:17 <frantisekz> if it is, sure, let's do FE
16:36:55 <frantisekz> punt for now?
16:36:59 <coremodule> from dustymabe in #fedora-cloud: actually the fix is going to be not too hard
16:37:01 <frantisekz> we can vote on thursday
16:37:19 <coremodule> frantisekz, we won't look at the FE's on Thursday I don't think..
16:37:26 <frantisekz> ... my bad
16:37:42 <lruzicka> ok, if there is a chance that a fix will be available, then I am for +1 FE
16:37:44 <coremodule> dustymabe: but I actually vote -1 FE and let us send a 0 day update
16:37:58 <coremodule> dustymabe: let's just document as common bug
16:38:05 <coremodule> ^^ the above from dustymabe
16:38:21 <lruzicka> ok, in that case, -1FE
16:38:24 <frantisekz> I would vote +FE if I knew the fix wouldn't break anything else... but I am not sure atm
16:38:30 <frantisekz> so -1 FE
16:38:33 <coremodule> heres the fix
16:38:34 <coremodule> this is the fix we're going to go with https://github.com/dracutdevs/dracut/issues/480#issuecomment-431608097
16:38:47 <frantisekz> hmm
16:38:59 <frantisekz> looks like it's isolated to iscsi
16:39:22 <frantisekz> so, +1 FE?
16:39:38 <lruzicka> If the maintainer wants to vote -1FE, then why not listen to him?
16:39:56 <coremodule> not the maintainer, just the reporter
16:40:30 <lruzicka> ok .... so I am fully perplexed.
16:40:43 <frantisekz> the fix looks like it's pretty simple isolated thingie, so I am more inclined to +1FE
16:40:53 <stickster> This seems like a "if this happens to make it, it's worthwhile," which sounds +1FE and -1B
16:41:01 <coremodule> I do agree, it seems isolated to iscsid
16:41:07 <stickster> *nod
16:41:12 <coremodule> +1 FE
16:41:15 <lruzicka> ok, then lets be it
16:41:15 <pwhalen> +1 FE
16:41:21 <lruzicka> +1
16:41:32 <coremodule> #info A fix has been made, we're just waiting for it to get pulled in
16:42:33 <coremodule> proposed #agreed 1641268 - AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:42:41 <frantisekz> ack
16:43:31 <lruzicka> ack
16:44:10 <coremodule> #info the fix seems isolated to iscsid
16:44:14 <coremodule> one more ack...
16:44:20 <pwhalen> ack
16:44:23 <coremodule> #agreed 1641268 - AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:44:33 <coremodule> #topic (1628209) kernel 4.18.5-200.fc28.armv7hl has non-functional ethernet on wandboard quad
16:44:33 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628209
16:44:33 <coremodule> #info Proposed Freeze Exceptions, kernel, MODIFIED
16:44:45 <lruzicka> +1 fe
16:45:38 <pwhalen> +1 FE
16:45:43 <coremodule> =1 FE
16:45:46 <coremodule> +1 FE
16:45:46 <frantisekz> +1 FE
16:45:50 <bcotton> +1 FE
16:46:08 <coremodule> Proposed #agreed 1628209 - AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:46:15 <frantisekz> ack
16:46:18 <pwhalen> ack
16:46:19 <roshi> ack
16:46:26 <coremodule> #agreed 1628209 - AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:46:37 <coremodule> #topic (1639765) Rock960 hangs after boot
16:46:37 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1639765
16:46:37 <coremodule> #info Proposed Freeze Exceptions, kernel, MODIFIED
16:47:02 <pwhalen> +1 FE
16:47:17 <lruzicka> +1 FE
16:47:26 <coremodule> +1 FE
16:47:30 <bcotton> +1 FE
16:47:30 <frantisekz> +1 FE
16:47:33 <coremodule> Proposed #agreed 1639765 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:47:46 <pwhalen> ack
16:47:46 <lruzicka> ack
16:48:31 <coremodule> one more...!
16:48:38 <roshi> ack
16:48:39 <frantisekz> ack
16:48:48 <coremodule> #agreed 1639765 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:48:57 <coremodule> #topic (1641254) Backport a couple of mutter memory leaks
16:48:57 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1641254
16:48:57 <coremodule> #info Proposed Freeze Exceptions, mutter, MODIFIED
16:49:40 <kparal> +1 fe, but needs to get enough karma
16:49:46 <coremodule> +1 FE
16:49:50 <lruzicka> +1 FE
16:49:52 <pwhalen> +1 FE
16:49:54 * stickster goes to take dog out before his bug comes up in blocker status checks
16:49:57 <bcotton> +1
16:50:16 <coremodule> #info this bug needs more karma to go stable
16:50:26 <lruzicka> kparal, we can take a look tomorrow and karma if ok.
16:50:42 <coremodule> I'll also give it a look after the meeting
16:51:05 <coremodule> proposed #agreed 1641254 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException. We additionally note that this bug needs more positive karma to be pushed stable.
16:51:15 <lruzicka> ack
16:51:18 <frantisekz> ack
16:51:19 <kparal> stickster: we could've discussed it with priority, sorry :(
16:52:01 <coremodule> one more..
16:52:02 <stickster> np, back now.
16:52:52 <roshi> ack
16:52:56 <coremodule> #agreed 1641254 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException. We additionally note that this bug needs more positive karma to be pushed stable.
16:53:10 <coremodule> #topic (1640488) evince has moved from evince.desktop to org.gnome.Evince.desktop
16:53:10 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1640488
16:53:10 <coremodule> #info Proposed Freeze Exceptions, shared-mime-info, VERIFIED
16:53:35 <coremodule> +1 FE
16:53:51 <lruzicka> +1 FE, tested --- works
16:53:53 <bcotton> +1 FE
16:54:00 <kparal> +1 FE
16:54:00 <coremodule> based on in-bug votes...
16:54:01 <frantisekz> +1 FE
16:54:03 <coremodule> proposed #agreed 1640488 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:54:24 <coremodule> #info the fix has been tested and found to work
16:54:37 <bcotton> ack
16:54:40 <lruzicka> ack
16:54:48 <frantisekz> ack
16:54:51 <coremodule> #agreed 1640488 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException.
16:55:01 <coremodule> #topic (1640352) Final (hopefully) version of spin-kickstarts for f29
16:55:01 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1640352
16:55:01 <coremodule> #info Proposed Freeze Exceptions, spin-kickstarts, VERIFIED
16:55:13 <lruzicka> +1 FE, dtto
16:55:30 <kparal> +1 FE
16:55:31 <frantisekz> +1 FE
16:55:48 <Southern_Gentlem> +fe
16:55:58 <bcotton> +1 fe
16:56:19 <pwhalen> +1 fe
16:56:46 <coremodule> proposed #agreed 1640352 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException. It is also noted that the original blocker classification of this bug was based on old criteria, and as such no longer qualifies as a blocker.
16:56:53 <bcotton> ack
16:56:55 <frantisekz> ack
16:57:00 <pwhalen> ack
16:57:06 <lruzicka> ackingly ack
16:57:17 <coremodule> #agreed 1640352 – AcceptedFreezeException - This bug has been noted to be a "nice-to-have" fix, so we accept it as an AcceptedFreezeException. It is also noted that the original blocker classification of this bug was based on old criteria, and as such no longer qualifies as a blocker.
16:57:39 <coremodule> okay, review time! the best part of a three-course blocker review. mmm mmm
16:58:06 <coremodule> #info moving on to review the accepted blockers
16:58:16 <coremodule> #topic (1632177) dnf segfault in libdnf::TransactionItem::saveReplacedBy()
16:58:16 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632177
16:58:16 <coremodule> #info Accepted Blocker, dnf, VERIFIED
16:58:57 <lruzicka> This one is already closed.
16:59:02 <frantisekz> coremodule : I need to go no, secretary job is hopefully done, thanks for leading the meeting , bye all
16:59:08 <frantisekz> *to go... :D
16:59:09 <lruzicka> frantisekz, by
16:59:24 <kparal> frantisekz: not done, but we'll handle it
17:00:05 <lruzicka> #1632177 is closed -> errata
17:00:10 <coremodule> lruzicka, kparal if the bug is closed, when will it lose it's blocker status, or do we have to do that manually?
17:00:28 <kparal> it's closed, it's resolved, nothing to do
17:00:32 <kparal> just go to the next one
17:00:34 <coremodule> fantastic
17:00:44 <coremodule> #topic (1636743) dnf update --refresh fails for repo_gpgcheck=1
17:00:44 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636743
17:00:44 <coremodule> #info Accepted Blocker, dnf, VERIFIED
17:01:00 <kparal> surprise
17:01:02 <kparal> closed
17:01:15 <kparal> next :)
17:01:16 <lruzicka> seems the app did not update
17:01:25 <kparal> it did, just refresh
17:01:25 <coremodule> #topic (1633133) [abrt] gjs: gtk_box_pack(): gjs-console killed by SIGSEGV
17:01:25 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1633133
17:01:25 <coremodule> #info Accepted Blocker, gnome-maps, POST
17:01:47 <coremodule> oh wow
17:01:48 <lruzicka> What is the resolution on google maps, stickster?
17:02:02 <kparal> this one is the crasher, that's the non-controversial one I believe
17:02:03 <stickster> Thanks for the ping here lruzicka
17:02:08 * stickster back
17:02:09 <kparal> we'll discuss it for the next bug?
17:02:22 <stickster> The crasher SEGV has a fix upstream that is getting into the package now via kalev
17:02:25 <kparal> this one just got an update, which is great
17:02:27 <stickster> (now-ish)
17:02:41 <stickster> I'm here for the other one ;-)
17:02:41 <coremodule> thanks for the help frantisekz
17:03:05 <coremodule> #info we need karma on the fix for this
17:03:16 <coremodule> #info https://bodhi.fedoraproject.org/updates/FEDORA-2018-6dc96f6d57
17:03:33 <lruzicka> I can have a look tomorrow and heat it a little with Karma.
17:03:44 <coremodule> #topic (1637751) Display gets messed up when routing panel is active
17:03:44 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637751
17:03:44 <coremodule> #info Accepted Blocker, gnome-maps, NEW
17:03:50 <coremodule> lruzicka, that works great!
17:03:53 <stickster> This is the one :-)
17:04:15 <coremodule> stickster, you have the conn
17:04:17 <stickster> #info Workstation WG was grateful to be consulted here, and doesn't believe this belongs on the blocker list
17:04:59 <lruzicka> why do they think so?
17:05:02 <kparal> the argument is that it's not universally broken, because many people see it working fine, even on wayland (and bare metal)
17:05:21 <stickster> several reasons -- (1) the problem isn't reproducible in all expected cases -- including some people on wayland and/or baremetal
17:05:24 <kparal> however, our testing and community response was quite negative, a lot of "here as well"
17:05:34 <stickster> yes, it hit me as well
17:05:42 <coremodule> I agree, I haven't seen the bug personally, but a lot of people have...
17:06:03 <kparal> so it might be something in the graphics stack
17:06:08 <kparal> rather than the app
17:06:12 <coremodule> ^^
17:06:18 <stickster> (2) the fix may be far down the stack into clutter and we don't want to destabilize other stuff
17:06:45 <stickster> (3) given the test of "would we hold up the release for this?" this doesn't seem like it meets the bar
17:07:11 <stickster> Speaking only for myself, I would argue basic functionality is "can you get a map on screen, and are you located on it"
17:07:29 <kparal> well, there's basically two things you can do with gnome-maps - display a map, and plan a route
17:07:38 <kparal> there's not much anything else
17:08:13 <kparal> so I'd personally classify it under basic functionality. but I understand the "not universally broken" argument
17:08:33 <nb> /me would be tempted to say gnome-maps is not essential stuff, just pull that package if it is broken
17:08:37 <nb> don't hold up the release for it
17:08:41 <kparal> if it was universally broken, I'd stand by our criterion "basic functionality must work" (or we would need to cancel that criterion)
17:08:52 <kparal> nb: that was considered
17:09:09 <kparal> stickster: want to summarize pulling gnome-maps from a default install?
17:09:13 <coremodule> I also do not think that blocking on this is the best choice here, based on the above listed reasons and the chance that this is a graphics issue and not an app issue.
17:09:23 <lruzicka> kparal, I think stickster has his point here ... it shows you the route, but it only looks bad.
17:09:26 <stickster> I don't think we want to pull things from default on a bug with this kind of disagreement.
17:09:36 <lruzicka> kparal, so some functionality is there indeed.
17:09:50 <stickster> Plus, note the route function not working isn't debilitating. You can close the pane fine and continue using Maps for other things.
17:10:03 <stickster> btw, I am one of the people who sees this bug
17:10:03 <kparal> not always
17:10:10 <kparal> sometimes you don't even see the pane, just white space
17:10:42 <stickster> kparal: Did you know that if you have the pane open already and choose "Route to here," it may work fine?
17:10:43 <kparal> I remember we couldn't even resize the app
17:11:39 <kparal> I'm fine with moving it to common bugs and rejecting as a blocker, with the argument that in certain configurations it works fine
17:12:12 <coremodule> Let's take a vote:
17:12:18 <kparal> we should also clear up whether workstation wg has a final say in any question regarding workstation image. that would save us a lot discussion :)
17:12:30 <stickster> Yes, I noticed that too. I would say this is not "hold release" worthy and due to the total of all arguments, the WG was -1 to this being a blocker, but would be +1 FE if we can happen to get a fix from upstream
17:12:44 <nb> I agree with stickster
17:12:45 <bcotton> stickster: was workstation WG unanimous in this judgment?
17:13:04 <stickster> bcotton: I think everyone who participated in the discussion was agreed, yeah
17:13:16 <kparal> some of them asked for pulling gnome-maps from default install, iirc
17:13:42 <stickster> A couple did, but they also agreed with "OK for not blocking."
17:13:50 <bcotton> ok. i'm inclined to defer to Workstation on this since it's their deliverable
17:14:12 <kparal> yeah, that's what I said we should clear up in the future :)
17:14:21 <lruzicka> yeah, that makes sense.
17:14:25 <stickster> I think we may want to pull this from the default based on whether or not we can resolve the state of maintenance upstream, which is uneven. But that shouldn't be tied to F29 release (though arguably it should be tied to our F30 readiness)
17:14:26 <kparal> ok, based on workstation wg opinion, -1 blocker +1 FE +common bugs
17:14:52 <lruzicka> -1 blocker, -1 FE
17:14:58 <mboddu> -1 Blocker, +1 FE
17:15:04 <kparal> lruzicka: why -1 FE?
17:15:04 <bcotton> -1 B, +1 FE, +1 CB
17:15:07 <coremodule> -1 blocker
17:15:07 <pwhalen> -1 blocker +1 FE +common bugs
17:15:14 <lruzicka> oops, sorry, mistake
17:15:23 <lruzicka> s/-/+/
17:15:27 <kparal> gotcha
17:15:41 <kparal> unanimous we are
17:16:18 <stickster> fyi, I also asked bcotton to hold the Workstation WG to a survey of maintenance on our default apps for next release
17:16:37 <bcotton> stickster: ack
17:17:18 <stickster> Cool, thanks for the opp'ty to speak up here :-)
17:17:59 <stickster> <eof/>
17:18:06 <coremodule> proposed #agreed 1637751 – RejectedBlocker AcceptedFreezeException – After much deliberation and hearing from stickster as representative from the Workstation WG, we have unanimously decided to not block the release on this bug, based on the fact that 1) the bug is not universal, 2) the fix may destabilize other things, and 3) it seems overly-zealous to block the release on this bug. We accept it as a Freeze Exception
17:18:06 <coremodule> in case a fix comes about soon.
17:18:08 <kparal> stickster: please stay around, if you have updates regarding the rest of desktop blockers
17:18:13 <stickster> Oh yeah
17:18:34 <kparal> ack
17:18:47 <bcotton> ack
17:18:47 <pwhalen> ack
17:19:00 <lruzicka> ack
17:19:08 <coremodule> #agreed 1637751 – RejectedBlocker AcceptedFreezeException – After much deliberation and hearing from stickster as representative from the Workstation WG, we have unanimously decided to not block the release on this bug, based on the fact that 1) the bug is not universal, 2) the fix may destabilize other things, and 3) it seems overly-zealous to block the release on this bug. We accept it as a Freeze Exception in case a
17:19:09 <coremodule> fix comes about soon.
17:19:26 <coremodule> #topic (1640701) GNOME Software "update and restart" button appears to do nothing
17:19:26 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1640701
17:19:26 <coremodule> #info Accepted Blocker, gnome-software, NEW
17:20:04 <kparal> has anyone reproduced this?
17:20:50 <coremodule> Not personally, but I had heard from kalev who I *thought* said had a fix ready
17:20:52 <kparal> if not, and we're all trusting a single report, adamw will get you all fired
17:21:18 <stickster> I think kalev is working on this bug
17:21:43 <lruzicka> I can try it now, if you want. Will take 3 mins.
17:21:47 <stickster> When I run on my workstation, *something* happens, I get the "Checking..." prompt and the progress spinner.
17:21:54 <coremodule> lruzicka, yes please! :)
17:22:19 <coremodule> stickster, is that for an update that requires a Reboot?
17:22:31 <coremodule> #info lruzicka to test this right now
17:22:38 <stickster> these are firmware updates which I think do that?
17:22:47 <coremodule> ah, okay, want to give it a try?
17:22:55 <stickster> It'll drop me offline here, but sure :-)
17:23:06 <coremodule> we will hold the meeting for your return!
17:23:09 <stickster> lol
17:23:13 <lruzicka> I can see, that my installation does exactly what is described in this bug
17:23:14 <stickster> I hit the button, let's see what happens.
17:23:19 <coremodule> #info stickster to also attempt to reproduce the bug
17:23:35 <stickster> I don't have any other opinion on this bug. I only know kalev was working on it.
17:23:43 <lruzicka> wait, now it switched to the dialogue that lets me reboot and update
17:24:02 <lruzicka> so, I would say, that it shows cancel until the packages are ready and then goes on
17:24:17 <kparal> well, co I tried. dnf shows 500MB of updates, gnome-software claims there are none
17:24:46 <lruzicka> the only malfunction is, that the progress is not enough shown and waiting can be long with lots of updats
17:25:18 <lruzicka> and the comp is updating without further issues.
17:25:32 <kparal> it seems we'll have a gnome-software testing day tomorrow (or today, coremodule)
17:25:50 <stickster> So the firmware updates worked as expected.
17:25:55 <kparal> it's simply not showing me any updates
17:26:03 <lruzicka> tu sum up: The behaviour is not perfect, but it seems to me that it still works in the background.
17:26:05 <stickster> However, they  aren't the same as the bug filed. They don't seem to require reboot.
17:26:32 * stickster sorry his tests didn't really help here.
17:27:13 <lruzicka> What is reported in the bug is actually very correct.
17:27:19 <lruzicka> Problem: The button changes to a "cancel" button. Nothing happens for at least a few minutes. Clicking cancel aborts whatever it was doing.
17:27:41 <lruzicka> I can confirm this ... it does not take 5 minutes for me, but it could with a lot of updates.
17:27:52 <stickster> *nod
17:27:59 <lruzicka> solution: Kalev tells me that it's a UX problem and that if I waited long enough, it would eventually complete.
17:28:09 <lruzicka> I also can confirm that.
17:29:06 <kparal> I guess I'll file a new bug tomorrow. can't make it to show any updates
17:29:22 <lruzicka> maybe restart packagekit?
17:29:25 * stickster is hopelessly up to date on everything and can't either :-D
17:29:51 <coremodule> stickster, can you get with kalev and get some updates as to where the fix stands?
17:30:01 <coremodule> and report in bug?
17:30:53 <stickster> yep
17:31:24 <coremodule> #info stickster to get with kalev on the status of a fix for this bug and report any findings in-bug
17:32:13 <coremodule> #info coremodule to run some gnome-software tests today
17:32:18 <coremodule> #topic (1632981) Cannot commit Japanese candidates or Korean Hangul in gnome-terminal and libreoffice
17:32:18 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632981
17:32:18 <coremodule> #info Accepted Blocker, gtk3, NEW
17:32:24 <coremodule> thanks stickster
17:33:03 <coremodule> See comment 10 here
17:33:35 <coremodule> I have been corresponding with on of the gnome maintainers and he sounds confident to have multiple fixes available for this.
17:33:49 <coremodule> It's just a matter of time until they show up here.
17:34:28 <stickster> see also https://bugzilla.redhat.com/show_bug.cgi?id=1632981#c10
17:36:44 <stickster> Not sure what else there is to add here. and I'm late for another call at this point :-)
17:36:50 <stickster> I think this was the last desktop thing, though?
17:37:50 <coremodule> #info there are several fixes available that should be in GNOME 3.30.2, we are just waiting for them to land here in Fedora-land
17:38:06 <kparal> stickster: there's also packagekit, but that is assigned to libdnf
17:38:32 <kparal> that will be the last bug discussed I believe
17:39:09 <coremodule> #topic (1632518) PackageKit installs packages from default module streams, but does not enable the module stream
17:39:10 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632518
17:39:10 <coremodule> #info Accepted Blocker, libdnf, POST
17:40:21 <stickster> It looks like there's a working fix via both packages
17:40:46 <stickster> that's all I can see, and I have no other data hee, so I'm vanishing :-)
17:41:07 <kparal> stickster: thanks, see you
17:41:26 <coremodule> stickster, thanks for showing up and helping be our mediator between QA and Workstation WG :)
17:41:35 <stickster> np folks, thanks
17:41:41 <lruzicka> take care
17:42:28 <coremodule> it does look like a fix is in place here
17:46:08 <coremodule> #info a fix is in the works for this bug
17:46:45 <coremodule> okay everyone, do we have the strength to carry on to the accepted freeze exceptions??
17:47:21 <kparal> I'd say that's a homework for coremodule and frantisekz, ehm ehm...
17:47:50 <kparal> we can go through those that you're unsure whether to include or not in the next compose
17:48:25 <coremodule> I am okay with this. I haven't spent much time looking at the FEs so far, the blockers just seemed so much more... pressing. :P
17:48:28 <lruzicka> Well, as I see only two are verified --- the rest should not go anywhere
17:49:08 <kparal> those in modified have a koji build
17:49:23 <coremodule> #coremodule and frantisekz to look into the freeze exceptions and post in-bug there on any additional data found
17:49:24 <kparal> so those are the possible set to include
17:49:27 <lruzicka> kparal, why arent they on qa then?
17:49:38 <kparal> they'll be onqa once they're in updates-testing
17:49:52 <kparal> so either they're not submitted to bodhi yet, or not pushed yet
17:50:11 <coremodule> #info coremodule and frantisekz to look into the freeze exceptions and post in-bug there on any additional data found
17:50:39 <kparal> coremodule: hah, you're trying to have your own zodbot command!
17:50:43 <lruzicka> ok, so I can take a look tomorrow and if there's a koji build and I know how to test, I will and update the status.
17:50:51 <coremodule> #coremodule kparal
17:50:52 <kparal> thanks
17:50:53 <coremodule> ^^
17:51:08 * kparal feels modular
17:51:17 <lruzicka> modprobe kparal
17:51:25 <coremodule> ls -la kparal
17:51:27 <coremodule> lruzicka, lol
17:52:07 * kparal crashes
17:52:09 <lruzicka> I suggest we call this off now, seems like we are the only three people here.
17:52:15 <kparal> ack
17:52:20 <bcotton> /me is still here, but has nothing to contribute
17:52:22 <kparal> everyone else is fired
17:52:31 <coremodule> #topic Open Discussion
17:52:33 * bcotton has leading spaces, apparently
17:52:36 <coremodule> Okay anything else??
17:52:38 <Southern_Gentlem> great i work to do
17:52:46 <kparal> nothing here
17:53:12 * bcotton has nothing
17:53:13 <coremodule> alright everyone, thanks for showing up and being here...! Lets see what we can get done in the next couple of days!
17:53:16 <lruzicka> As already said, I will go and try to test what has koji builds and I will know how.
17:53:18 <coremodule> closing meeting in 3...
17:53:25 <coremodule> 2...
17:53:36 <coremodule> 1...
17:53:51 <coremodule> #endmeeting