16:00:57 <adamw> #startmeeting F29-blocker-review
16:00:57 <adamw> #meetingname F29-blocker-review
16:00:57 <adamw> #topic Roll Call
16:00:57 <zodbot> Meeting started Mon Oct  8 16:00:57 2018 UTC.
16:00:57 <zodbot> This meeting is logged and archived in a public location.
16:00:57 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:57 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:00:57 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:52 * sumantro is here
16:01:57 * lbrabec is here
16:01:58 * Southern_Gentlem is here
16:02:16 * kalev is here
16:03:45 * cmurf might be here or there
16:04:22 <bcotton> .hello2
16:04:23 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:06:54 <adamw> morning folks
16:07:01 <adamw> how's everyone doing?
16:07:22 <frantisekz> .hello2
16:07:23 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:08:00 <jlanda> good afternoon ;)
16:08:06 <bcotton> couldn't be better, adamw, i'm here with you :-)
16:08:17 <adamw> #chair bcotton frantisekz
16:08:17 <zodbot> Current chairs: adamw bcotton frantisekz
16:08:21 <adamw> coremodule: around?
16:10:00 <adamw> anyone else want to secretarialize?
16:11:33 * bcotton is reading duties
16:11:35 <frantisekz> I can handle that, I'll just be few (~5-10) mins afk, I am trying hard to finish some coding thingie :)
16:11:53 <adamw> alright, no probs :)
16:12:01 <adamw> #info frantisekz will secretarialize
16:12:06 <adamw> poke me if you have any trouble
16:12:10 <frantisekz> sure :)
16:12:26 <adamw> #topic Introduction
16:12:26 <adamw> Why are we here?
16:12:26 <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:12:26 <adamw> #info We'll be following the process outlined at:
16:12:26 <bcotton> frantisekz++
16:12:27 <zodbot> bcotton: Karma for frantisekz changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:12:28 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:12:28 <adamw> #info The bugs up for review today are available at:
16:12:30 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:34 <adamw> #info The criteria for release blocking bugs can be found at:
16:12:36 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:12:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:12:40 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:12:42 <adamw> and we have:
16:12:44 <adamw> #info 8 Proposed Blockers
16:12:46 <adamw> #info 7 Accepted Blockers
16:12:48 <adamw> #info 1 Accepted Previous Release Blockers
16:12:50 <adamw> #info 6 Proposed Freeze Exceptions
16:12:52 <adamw> #info 2 Accepted Freeze Exceptions
16:12:54 <adamw> let's get started with proposed blockers!
16:12:58 <adamw> #info starting with proposed blockers
16:13:02 <adamw> #topic (1589332) UEFI, dual drive installation bootloader error message is unhelpful
16:13:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1589332
16:13:06 <adamw> #info Proposed Blocker, anaconda, ASSIGNED
16:13:26 <adamw> cmurf: i think this is just the same as https://bugzilla.redhat.com/show_bug.cgi?id=1168118 , which has been around for years, only a bit more text got added to the error for some reason.
16:13:46 <adamw> it hasn't been a blocker since 2014, so i can't see why it'd suddenly be one now. though i do wish someone would get around to fixing it.
16:14:15 <adamw> i'd probably be inclined to just close it as a dupe and note the error text has changed a bit in f29...
16:14:41 <cmurf> oh my god it has a massive backstory
16:15:14 <cmurf> *sigh*
16:15:27 <adamw> comments #59 and #60 have most of the story.
16:15:35 <cmurf> that's what i'm referring to
16:15:38 <adamw> you were around at the time, i think you maybe just forgot it.
16:15:59 <cmurf> i have 640KiB memory and have to swap shit out
16:16:21 <jlanda> enough memory for a human
16:16:33 <adamw> hehe
16:16:37 <cmurf> on the one hand it's a bad bug that I think violated the criteria in terms of intent, but on the other hand it sounds impractical to block on
16:16:50 <cmurf> given the current design
16:16:59 <adamw> also there's the fact it's been broken for years, so doing a new release with the same bug doesn't make anything *worse*
16:17:14 <adamw> yeah, it's not at all simple to fix.
16:17:38 <adamw> it's one of those bugs where you wind up wanting to rewrite everything, only rewriting how we handle boot-related partitioning is...not something you want to be doing at the end of a release cycle.
16:17:53 <cmurf> well, it would be simple if my world view were accepted that users should never have to deal with anything releated to bootloaders even in custom partitioning
16:18:01 <adamw> it'd be nice to know if the workaround still works i guess
16:18:07 <cmurf> it does
16:18:18 <adamw> cmurf: a simple idea is not necessarily simple to implement =)
16:18:22 <adamw> anyhow, yeah, -1 for me
16:18:23 <adamw> anyone else?
16:18:26 <frantisekz> -1
16:18:28 <adamw> (and probably close as dupe)
16:18:32 <jlanda> -1
16:18:35 <cmurf> yes all of that
16:18:38 <kalev> -1
16:18:40 <lbrabec> -1
16:18:45 <sumantro> -1
16:19:20 <Southern_Gentlem> -1
16:19:43 <bcotton> -1
16:20:05 <adamw> proposed #agreed 1589332 - RejectedBlocker (Final) - this is really the same as an old bug, #1168118, which was never fixed. That bug was rejected as a blocker and we uphold that decision here (it is not very commonly encountered, can be worked around, and fixing it would be quite disruptive and come with a risk of breaking something worse). we will close the bug as a dupe of the old one
16:20:15 <bcotton> ack
16:20:20 <frantisekz> ack
16:20:21 <cmurf> ack
16:20:24 <jlanda> ack
16:20:25 <lbrabec> ack
16:20:48 <adamw> #agreed 1589332 - RejectedBlocker (Final) - this is really the same as an old bug, #1168118, which was never fixed. That bug was rejected as a blocker and we uphold that decision here (it is not very commonly encountered, can be worked around, and fixing it would be quite disruptive and come with a risk of breaking something worse). we will close the bug as a dupe of the old one
16:21:00 <adamw> #topic (1636184) Default module streams appeared post-Beta for Fedora 29, this seems reckless
16:21:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636184
16:21:00 <adamw> #info Proposed Blocker, distribution, ASSIGNED
16:21:07 <adamw> mattdm: sgallagh: around to comment on this?
16:21:20 <adamw> i'm not sure we could take it as a blocker under the release criteria, but it does worry me a bit
16:21:25 <adamw> we could possibly kick it to fesco
16:22:14 <sgallagh> can you come back to it later? I’m away from my desk (on cellphone)
16:22:17 <bcotton> yeah, this seems more like a FESCo matter
16:22:20 <cmurf> kick to fesco
16:22:32 <sgallagh> Or that
16:23:44 <adamw> any other thoughts?
16:24:44 <adamw> ok then
16:25:16 <kalev> I'd like to accept it as a blocker as I think packagekit gladly updates to the new module streams
16:25:27 <adamw> proposed #agreed 1636184 - punt to FESCo - this doesn't really violate the release criteria, but we are concerned about it as it relates to the Change process, so we will file a ticket asking FESCo to consider it
16:25:39 <bcotton> ack
16:25:41 <frantisekz> ack
16:25:42 <adamw> kalev: well that's what's *meant* to happen, though if the bug about PK not then enabling the module is still there, that could be a problem
16:25:44 <jlanda> ack
16:25:57 <adamw> kalev: i'll find that bug and throw it in the fesco ticket...
16:25:59 <kalev> ahh
16:26:03 <kalev> ack
16:26:13 <adamw> #agreed 1636184 - punt to FESCo - this doesn't really violate the release criteria, but we are concerned about it as it relates to the Change process, so we will file a ticket asking FESCo to consider it
16:26:35 <adamw> #topic (1636239) get_best_query().filter(latest=True) is returning incorrect results
16:26:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636239
16:26:35 <adamw> #info Proposed Blocker, dnf, NEW
16:26:54 <adamw> this one's had some movement of late, it seems like the current state of affairs is dnf team reckons nothing in dnf is exactly broken and bcl should change the lorax code
16:27:54 <cmurf> i'm -1 blocker based on the comments
16:28:00 <adamw> i can't see any reason to take this as a blocker atm, it does not break composes
16:28:13 <bcotton> -1. there's a workaround in place
16:28:20 <frantisekz> -1 here
16:28:24 <lbrabec> -1
16:30:04 <kalev> -1
16:30:12 <adamw> proposed #agreed 1636239 - RejectedBlocker (Final) - there does not seem to be any current violation of the release criteria here, this is not affecting F29 composes
16:30:19 <frantisekz> ack
16:30:23 <jlanda> ack
16:30:42 <lbrabec> ack
16:30:44 <bcotton> ack
16:30:53 <Southern_Gentlem> ack
16:31:28 <adamw> #agreed 1636239 - RejectedBlocker (Final) - there does not seem to be any current violation of the release criteria here, this is not affecting F29 composes
16:31:44 <adamw> #topic (1625142) In Gnome Wayland, forward-key-event does not work well, breaks space key completely
16:31:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625142
16:31:45 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:31:57 <cmurf> Are we able to review/accept the PrioritizedBug proposal in c19? I don't see what criterion it violates to make it a blocker.
16:32:21 <cmurf> I'd be +1 to extending the freeze exception for final though.
16:32:29 * mattdm parachutes in
16:32:31 <cmurf> freeze is tomorrow right?
16:32:37 <kalev> I think this is going to be in the gnome-shell release that fmuellner is working on right now
16:32:42 <kalev> cmurf: freeze is today at 00:00
16:32:43 <jlanda> cmurf: yep
16:32:59 <mattdm> If this meeting advises that a particular bug should be accepted as a prioritized bug, we'll definitely take that into account
16:33:13 <adamw> right, but we can't make that decision
16:33:26 <cmurf> ok so prioritizedbug process is a different meeting?
16:33:27 <adamw> kalev: well, there seem to be a pair of MRs, one for mutter and one for gnome-shell
16:33:40 <adamw> is there gonna be a mutter release as well as gnome-shell ?
16:33:43 <kalev> yes
16:33:45 <adamw> cmurf: yeah.
16:33:47 <adamw> kalev: ok, thanks
16:34:01 <adamw> so, we did discuss this one once, but didn't come to a clear consensus
16:34:10 <adamw> it is already accepted as an FE
16:34:54 <adamw> the practical consequences of this bug is that the default input method for one language (Korean) is broken out of the box, making it difficult to really type anything at all
16:35:03 <adamw> some other non-default (but we know used by some folks) input methods are similarly broken
16:35:06 <bcotton> as i read it, it seems like a fairly narrow impact for accepting as a blocker. but it is pretty gnarly
16:35:26 <adamw> we are in https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F territory here, making a subjective decision
16:36:43 <bcotton> i guess if you pushed me to make a decision, i'd be -1
16:36:45 <cmurf> are there are any rules/guidelines on what languages we block on?
16:36:46 <adamw> if i put on my sgallagh hat and ask if we'd block the release on this if we found out about it an hour before the go/no-go meeting...i suspect the answer would be 'no'
16:36:53 <adamw> so from that perspective i'd be a reluctant -1
16:36:56 <adamw> cmurf: no
16:37:10 <adamw> the obvious common-sense rule is 'how many users of that language do we actually have'
16:37:18 <adamw> we don't have hard numbers for that, though
16:37:30 <adamw> there's just no collection of that data
16:37:43 <cmurf> yeah I can't assess that so I'm gonna be -1 blocker, recommend PrioritizedBug, and maintain the freeze exception
16:37:57 <cmurf> and hope it just gets fixed before release
16:38:02 <adamw> as kalev says we should be getting a fix for this today, so that's good
16:38:27 <adamw> anyone want to argue for +1 ?
16:38:30 * kalev nods.
16:38:40 <kalev> afk a bit, back in 15 minutes
16:38:40 <Southern_Gentlem> -1 bocker +fe
16:38:45 <adamw> thanks kalev
16:39:46 <frantisekz> weak -1 for me
16:40:04 <adamw> ok
16:40:15 <frantisekz> (-0.75)
16:40:59 <lbrabec> hm, -1 i guess, but it would be nice to have data, some kind of fedora census
16:41:53 <adamw> proposed #agreed 1625142 - RejectedBlocker (Final) - we agreed that while this is a bad bug, since it only affects one language that likely isn't a large percentage of Fedora's user base by default, it's not quite serious enough to be a blocker. It is already accepted as an FE, and we recommend Prioritized status (though it should be fixed today)
16:42:07 <cmurf> lbrabec: me2 but seems whenever such data collection comes up it results in privacy concerns :-\
16:42:09 <cmurf> ack
16:42:13 <lbrabec> ack
16:42:17 <Southern_Gentlem> ack
16:42:32 <jlanda> ack
16:42:37 <lbrabec> cmurf: yea, i know...
16:42:44 <adamw> #agreed 1625142 - RejectedBlocker (Final) - we agreed that while this is a bad bug, since it only affects one language that likely isn't a large percentage of Fedora's user base by default, it's not quite serious enough to be a blocker. It is already accepted as an FE, and we recommend Prioritized status (though it should be fixed today)
16:42:55 <adamw> #topic (1630233) Unable to unlock (or cancel) LUKS-encrypted USB drive or SD card in GNOME
16:42:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1630233
16:42:56 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:43:04 <adamw> this one also should be fixed today, for the record
16:43:20 <cmurf> +1 blocker
16:43:47 <lbrabec> +1 blocker
16:44:10 <frantisekz> +1
16:44:34 <bcotton> +1
16:45:46 <adamw> proposed #agreed 1630233 - AcceptedBlocker (Final) - accepted as a blocker under the "default panel functionality" and "application basic functionality test" criteria, per comment #6
16:45:55 <lbrabec> ack
16:46:18 <cmurf> ack
16:46:19 <Southern_Gentlem> ack
16:46:31 <jlanda> ac
16:46:33 <jlanda> k
16:46:34 <adamw> #agreed 1630233 - AcceptedBlocker (Final) - accepted as a blocker under the "default panel functionality" and "application basic functionality test" criteria, per comment #6
16:46:54 <jlanda> I had the worst connectivity in the world right now :D
16:46:57 <adamw> #topic (1632981) Cannot commit Japanese candidates or Korean Hangul in gnome-terminal and libreoffice
16:46:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632981
16:46:57 <adamw> #info Proposed Blocker, gtk3, NEW
16:46:58 <jlanda> have*
16:46:59 <adamw> ooo, more i18n
16:47:18 <cmurf> well I agree with sentiment in comment 5, but what's the criterion?
16:47:59 <adamw> it'd be a conditional violation of the default app basic functionality requirement i guess
16:48:04 <adamw> the condition being 'be using an affected language'
16:48:18 <adamw> so, compared to the other bug, this affects only particular apps (though ones nearly everyone uses), but more languages...
16:48:41 <cmurf> ok and what are the chances it can be fixed?
16:49:01 <cmurf> i know that's not supposed to matter but...
16:49:27 <cmurf> I'm definitely a +1 freeze exception, but I'm on the fence for blocking
16:49:33 <adamw> i dunno
16:49:46 <adamw> seems like they know roughly what the problem is
16:49:50 <adamw> i don't see an MR
16:51:31 <adamw> i guess i'd be +1 FE for sure, maybe would be nice to know if Chinese is affected to decide on blocker...
16:51:59 <bcotton> it's not entirely clear to me if this affects certain applications or all of them
16:52:42 <adamw> to me it sounds like it depends on the app.
16:52:50 <adamw> but i mean, if it affects gnome-terminal and LO, that's pretty bad. :)
16:54:05 <adamw> so i guess i'm voting to punt
16:54:16 <bcotton> aye. i think i'm like a +0.6 on blocking?
16:54:57 <adamw> oh man don't make me turn on FP mode
16:55:23 <bcotton> adamw: if we wait until next week to make a decision, what do you expect to have changed?
16:55:27 <cmurf> needinfo in bug if it affects chinese
16:55:45 <jlanda> i don't have a clear criteria on this
16:55:55 * sgallagh shows up fashionably (?) late
16:55:57 <cmurf> that too so it's subjective
16:56:00 <adamw> bcotton: i'd ask if we can find out what other languages (if any) it affects
16:56:17 <lbrabec> adamw: we can ask lnie, she's probably the best person I know to test Chinese
16:56:31 <cmurf> needinfo what other languages; and consider voting in bug. I think it needs to be a blocker this week if it's going to be a blocker, rather than punting to next week.
16:56:55 <adamw> lbrabec: the folks on the bug would be able to test also, but yeah.
16:58:24 <adamw> any other thoughts/votes?
16:58:43 <bcotton> since we don't have language-based criteria, i don't know that chinese being affected really changes anything
16:58:56 <adamw> bcotton: sure it does.
16:59:03 <adamw> bcotton: did you read the FAQ section I linked earlier?
16:59:15 <adamw> "This judgement will be based on multiple factors: "
16:59:22 <adamw> "*  The amount of users, overall, the issue is estimated likely to affect"
16:59:35 <adamw> obviously, the more languages it affects, the more users it affects.
17:00:18 <bcotton> but given we have no way of knowing how many users are affected, i don't know that three languages instead of two makes it more of a blocker
17:00:42 <adamw> bcotton: *i'd* be a lot more likely to vote +1 if chinese was affected, for one.
17:00:46 <bcotton> 10 instead of 2, sure. but it's not clear where that line is
17:00:47 <adamw> it's kind of a big language.
17:00:55 <adamw> you know, few billion people and all.
17:01:16 <bcotton> :-)
17:01:28 <adamw> so what's your vote? -1? +1?
17:01:32 <adamw> still 0.6? :)
17:01:45 <bcotton> if you're going to make me commit to an integer, i'll go +1
17:02:01 <adamw> ok
17:02:04 <adamw> sorry, gotta run downstairs
17:02:05 <adamw> back in a sec
17:07:25 <adamw> back, sorry
17:07:27 <adamw> so, is anyone else +1? if not we kinda go punt by default
17:08:25 <lbrabec> i'm more for a punt
17:08:46 <frantisekz> yep, let's punt, we'll have at least one more blocker mtg before the release
17:08:57 * kalev is back too
17:09:16 <Southern_Gentlem> +1punt
17:09:20 <adamw> proposed #agreed 1632981 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - this is definitely bad enough to warrant a freeze exception. We were not certain on blocker status; we would like to know if any other input methods, particularly major Chinese ones, are affected in order to be able to make a decision
17:09:32 <adamw> kalev: any notes on this one?
17:09:54 <lbrabec> ack
17:09:58 <jlanda> ack
17:10:03 <Southern_Gentlem> ack
17:10:03 <kalev> adamw: nothing to add from me
17:10:04 <kalev> ack
17:10:07 <bcotton> ack
17:10:08 <frantisekz> ack
17:10:15 <cmurf> ack
17:10:18 <adamw> ok
17:10:22 <adamw> #agreed 1632981 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - this is definitely bad enough to warrant a freeze exception. We were not certain on blocker status; we would like to know if any other input methods, particularly major Chinese ones, are affected in order to be able to make a decision
17:10:31 <adamw> #topic (1633328) Armv7 guest fails to boot with qemu-3.0.0-1
17:10:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1633328
17:10:31 <adamw> #info Proposed Blocker, qemu, NEW
17:10:38 <frantisekz> +1 imo
17:11:23 <cmurf> i'm not sure the work around in comment 13 makes this not a blocker
17:11:35 <Southern_Gentlem> +1
17:11:55 <Southern_Gentlem> just because there is a work around doesnt mean its a fix either
17:12:03 <adamw> by description i'd be +1, but from reading the bug, the story is not that simple
17:12:23 <frantisekz> cmurf, oh, didn't check the comments, I've used cached info about that bug from my head, will check :)
17:12:26 <sgallagh> This is conditional and only happens on 32-bit ARM, right?
17:12:34 <sgallagh> Which is only blocking for an XFCE desktop, I thought
17:12:41 <sgallagh> Am I misremembering?
17:13:05 <adamw> what does desktop have to do with anything here?
17:13:13 <adamw> the virt criteria apply to arm just as they do to x86_64...
17:14:10 <sgallagh> adamw: I realize it's lawyering a bit, but the criteria states that virt must be able to host a guest of the same OS version...
17:14:32 <sgallagh> not strictly that it must do so for all arches (or that one arch cannot host for another arch)
17:15:45 <sgallagh> I agree it's *ugly* that arm7 virt can't host an arm7 guest... but 1) is that *enough* to block on? and 2) Is virtualization on arm7 something people actually use? The processors are incredibly slow and memory-constrained to begin with...
17:17:21 <cmurf> if we can't clearly make a decision here then I'd kick it to fesco and let them decide, and from that decision clarify the criteria going forward
17:18:09 <sgallagh> Let me ask a different question
17:18:22 <bcotton> it seems like it's a straightforward violation of the criteria. but i agree with sgallagh that maybe it shouldn't be? i'd vote +1 but since there's a workaround, I'd live with it being put in Common Bugs
17:18:24 <cmurf> I guess the fix is a bit goofy in that fedora would have to carry a patch and be in conflict with upstream, not sure how bad that really is
17:18:29 <sgallagh> I'm having trouble parsing the comments on the BZ, but I *think* it implies that it's a hypervisor bug, right?
17:18:44 <sgallagh> So that's fixable with an update. If the problem was on the guest side, I'd be more inclined to block on it.
17:18:56 <adamw> we could change the behaviour post-release, yes.
17:19:22 <adamw> i don't think the 'fix' would be to put the LPAE kernel in the f29 release images, if that's what you're asking
17:19:54 <sgallagh> adamw: Not specifically; just that if we'd *never* be able to launch the release image from an F29 hypervisor, I'd be inclined to block.
17:21:40 <sgallagh> Right now, I'm -1 blocker on this. It's a pretty limited (and technically-knowledgeable) subset of people who would even encounter this bug and it can be fixed post-release.
17:22:05 <sgallagh> I'm good with FE though
17:24:07 <cmurf> +1 FE, -1 block, and +1 clarify the criterion
17:24:45 <adamw> sorry, just had to move again
17:24:47 * adamw catches up
17:24:55 <adamw> sgallagh: criteria that are not arch-specific apply to all release-blocking arches.
17:24:56 <sgallagh> bcotton: To respond to your statement, it's a conditional violation of the requirements. We only treat the XFCE spin of armv7 as blocking for that arch, and unless I'm mistaken that media doesn't include libvirt
17:25:43 <adamw> sgallagh: but that doesn't mean we only care about things included in the image.
17:26:05 <adamw> i don't think you can argue that because libvirt isn't installed out of the box on the blocking arm spins, it doesn't block. that doesn't fly for me.
17:26:12 <sgallagh> OK, that's fair.
17:26:27 <sgallagh> But I do think this is not so much a strict violation of the criteria as a conditional one
17:26:38 <sgallagh> And one that will affect a fairly small subset of users
17:27:47 <sgallagh> See my usual statement about "last blocker at Go/No-Go"
17:27:50 <adamw> anyhow, i'd vote -1 on the basis that you *can* do this, by using the parameter mentioned. worst case, we put that in common bugs. hopefully, libvirt and qemu folks can come up with some better mitigations.
17:27:53 * adamw counts votea
17:28:17 <sgallagh> -1 blocker / +1 FE (revoting for the record)
17:28:33 <adamw> so far we have +2, -3 - frantisekz, southern_gentlem, do you still vote +1?
17:29:19 <frantisekz> -1 b, +1 FE
17:29:25 <lbrabec> -1 blocker, +1 fe
17:29:30 * bcotton changes to -1 blocker, +1 FE
17:30:12 <adamw> ok
17:30:53 <Southern_Gentlem> -1 b +fe
17:31:31 <adamw> proposed #agreed 1633328 - RejectedBlocker AcceptedFreezeException (Final) - it seems the story here is complex and a simple 'fix' may not be possible. given that, we reject it as a blocker as it *is* possible to run ARM-on-ARM virt, it just requires a non-default arg for some guest cases. We grant an FE for any simple, testable mitigation that appears, and will document the issue in Common
17:31:31 <adamw> Bugs
17:31:41 <cmurf> ack
17:31:43 <adamw> (that's just short enough with the 'proposed' removed
17:31:43 <bcotton> ack
17:31:57 <sgallagh> ack
17:31:58 <jlanda> ack
17:31:59 <lbrabec> ask
17:32:07 <Southern_Gentlem> ack
17:32:13 <adamw> #agreed 1633328 - RejectedBlocker AcceptedFreezeException (Final) - it seems the story here is complex and a simple 'fix' may not be possible. given that, we reject it as a blocker as it *is* possible to run ARM-on-ARM virt, it just requires a non-default arg for some guest cases. We grant an FE for any simple, testable mitigation that appears, and will document the issue in Common Bugs
17:32:46 <adamw> #topic (1633786) SELinux is preventing (boltd) from 'create' accesses on the directory boltd.
17:32:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1633786
17:32:47 <adamw> #info Proposed Blocker, selinux-policy, NEW
17:33:13 <sgallagh> This seems like a pretty clear +1 blocker
17:33:24 <jlanda> I found the bug after upgrading a just installed default fc27 wks to fc29, so it should meet all release criterias and there is one of "no selinux denial notifications", so violates criteria. But boltd is an specific hardware subsystem (thunderbolt 3.0) and should have a workaround (didn't tested, but disabling security on tb may work), so a clear FE for me, but I'm not sure for blocker
17:33:36 <cmurf> +1 blocker
17:33:39 <bcotton> +1
17:33:42 <adamw> if we're sure this produces a notification, it's a clear +1
17:33:44 <cmurf> just FWIW there are lot of these
17:33:56 <sgallagh> adamw: I see multiple notifications of this sort on every login
17:33:56 <frantisekz> yep, happened also to me, didn't have time to report yet :)
17:33:56 <cmurf> does it make more sense to consolidate and make all of them blockers?
17:34:00 <adamw> jlanda: the criterion is actually about the impression caused by seeing these notifications on a default boot
17:34:10 <adamw> jlanda: it doesn't matter how bad the practical consequences of the denial are
17:34:22 <frantisekz> cmurf, lot of selinux warnings, not bug reports
17:34:25 <jlanda> adamw: i tested on two different boxes, same results.om both
17:34:33 <adamw> cmurf: it shouldn't matter hugely, selinux folks will tend to fix them all at once, but i'll send a mail and ask lukas to make sure they're all dealt with
17:34:40 <jlanda> adamw: i suspectted that. a clear +1 then
17:34:53 <frantisekz> +1
17:34:54 <jlanda> there are a bunch of relates bugs on bugtraq
17:34:54 <kalev> +1 blocker
17:34:56 <lbrabec> +1 blocker
17:35:05 <jlanda> related*
17:35:12 <Southern_Gentlem> +1
17:35:19 <adamw> proposed #agreed 1633786 - AcceptedBlocker (Final) - this is accepted as a violation of the criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:35:22 <cmurf> ack
17:35:23 <bcotton> ack
17:35:26 <frantisekz> ack
17:35:28 <Southern_Gentlem> ack
17:35:30 <lbrabec> ack
17:35:36 <kalev> ack
17:35:40 <jlanda> ack
17:35:41 <adamw> #agreed 1633786 - AcceptedBlocker (Final) - this is accepted as a violation of the criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:35:59 <adamw> ok, that's all proposed blockers
17:36:26 <adamw> #topic End of proposed blockers
17:36:34 <adamw> #info moving onto proposed Freeze Exception issues
17:36:41 <adamw> #topic (1635252) anaconda: Ignore errors activating unknown swap partitions
17:36:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1635252
17:36:41 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:36:43 <adamw> clear +1 FE for me
17:36:56 <cmurf> +1
17:36:57 <jlanda> +1
17:37:03 <kalev> +1 FE
17:37:13 <lbrabec> +1 fe
17:37:20 <bcotton> +1
17:37:40 <frantisekz> +1 FE
17:37:51 <adamw> proposed #agreed 1635252 - AcceptedFreezeException (Final) - this clearly can cause inconvenience during install in some cases and cannot be fixed with an update
17:38:04 <kalev> ack
17:38:10 <bcotton> ack
17:38:21 <cmurf> ack
17:38:32 <Southern_Gentlem> ack
17:38:32 <adamw> #agreed 1635252 - AcceptedFreezeException (Final) - this clearly can cause inconvenience during install in some cases and cannot be fixed with an update
17:38:33 <lbrabec> ack
17:38:38 <adamw> #topic (1637021) Installation should be aborted if module dependency errors are detected
17:38:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637021
17:38:38 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:38:47 <cmurf> +1 FE
17:38:51 <jlanda> +1
17:39:01 <kalev> +1 FE
17:39:04 <adamw> mm, i mean this looks like +1, but otoh, can you actually *get* modules in an f29 install at all?
17:39:18 <cmurf> good question
17:39:38 <sgallagh> adamw: What do you mean?
17:39:44 <kalev> there's the libgit2 module at least
17:39:57 <sgallagh> kalev: I'm looking into reverting that.
17:40:00 <adamw> well, aside from that, yeah (that seems to be against policy in itself)
17:40:00 <cmurf> my logic was that it's better to fail early, than whatever risk this fix entails
17:40:04 <kalev> sgallagh: ahh good
17:40:04 <sgallagh> That shouldn't have been allowed
17:40:22 <adamw> sgallagh: aside from that case, is there any way to actually include modular content at install time, for an f29 install?
17:40:32 <adamw> given that we shouldn't have any default module streams
17:40:45 <sgallagh> adamw: Kickstart
17:40:55 <adamw> is there kickstart syntax for it already?
17:41:16 <sgallagh> I think so?
17:41:24 * adamw looks
17:41:36 <sgallagh> I'm checking
17:41:57 <sgallagh> https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#module
17:41:58 <sgallagh> yes
17:42:01 <adamw> oh, yes, it seems there is.
17:42:05 <adamw> in that case, sure, +1.
17:42:14 <adamw> just didn't want to pull in change to fix something that actually couldn't happen.
17:42:58 <frantisekz> +1 FE then
17:43:04 <sgallagh> +1 FE
17:43:21 <adamw> proposed #agreed 1637021 - AcceptedFreezeException (Final) - this is clearly a useful and sensible protection and cannot be added post-release
17:44:19 <cmurf> ack
17:44:19 <bcotton> ack
17:44:22 <kalev> ack
17:44:23 <frantisekz> ack
17:44:28 <adamw> #agreed 1637021 - AcceptedFreezeException (Final) - this is clearly a useful and sensible protection and cannot be added post-release
17:44:51 <adamw> #info i think we can skip #1636184 as we're referring it to fesco and sgallagh is on it already
17:44:56 <cmurf> yes
17:45:02 * kalev agrees
17:45:03 <adamw> #topic (1631002) gnome-control-center stuck and starts consume memory abnormally if I try to change the background or lock screen image.
17:45:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1631002
17:45:03 <adamw> #info Proposed Freeze Exceptions, gnome-control-center, POST
17:45:11 <cmurf> +1 FE
17:45:18 <frantisekz> +1 FE
17:45:34 <Southern_Gentlem> +fe
17:45:41 <adamw> definitely +1 FE for this.
17:45:56 <kalev> +1 FE
17:46:17 <adamw> proposed #agreed 1631002 - AcceptedFreezeException (Final) - this is definitely a bad enough bug to be worth an FE to ensure it's fixed on live images and immediately after initial install or upgrade
17:46:42 <frantisekz> ack
17:46:47 <kalev> ack
17:46:47 <sumantro> ack
17:46:51 <jlanda> ack
17:47:21 <adamw> #agreed 1631002 - AcceptedFreezeException (Final) - this is definitely a bad enough bug to be worth an FE to ensure it's fixed on live images and immediately after initial install or upgrade
17:47:29 <cmurf> ack
17:47:37 <adamw> #info 1630233 was already accepted as a blocker, no need to discuss
17:47:44 <adamw> #topic (1636207) lorax-composer needs some commits from master: composer-cli rename, lock root account in images
17:47:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636207
17:47:44 <adamw> #info Proposed Freeze Exceptions, lorax, ON_QA
17:47:49 <adamw> i'm fine with +1 FE for this, if bcl wants it.
17:47:58 <kalev> +1 FE
17:48:02 <frantisekz> +1 FE
17:48:03 <cmurf> +1FE
17:48:10 <lbrabec> +1 fe
17:48:15 <bcotton> +1 FE
17:48:36 <sgallagh> +1 FE
17:49:20 <adamw> proposed #agreed 1636207 - AcceptedFreezeException (Final) - as this does not affect critical functionality, we're fine with letting bcl change it now if he needs to
17:49:31 <lbrabec> ack
17:49:40 <bcotton> ack
17:49:43 <kalev> ack
17:49:48 <frantisekz> akc
17:50:00 <adamw> #agreed 1636207 - AcceptedFreezeException (Final) - as this does not affect critical functionality, we're fine with letting bcl change it now if he needs to
17:50:07 <adamw> #topic End of proposed freeze exceptions
17:51:06 <adamw> #info moving on to some of the accepted blockers
17:51:16 <sgallagh> adamw: Hang on
17:51:17 <adamw> I'm gonna skip ones that are in pretty clear state atm (we know they're being handled)
17:51:20 <adamw> sgallagh: hanging!
17:51:23 <sgallagh> Can we roll back to 1636184?
17:51:33 <sgallagh> I want an FE ruling on my latest comment (from one minute ago)
17:51:39 <adamw> we sure can
17:51:50 <adamw> #info moving back to 1636184 as a proposed FE at sgallagh's request
17:51:52 <adamw> #topic (1636184) Default module streams appeared post-Beta for Fedora 29, this seems reckless
17:51:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636184
17:51:52 <adamw> #info Proposed Freeze Exceptions, distribution, ASSIGNED
17:52:11 <adamw> sure, +1 FE for that purpose
17:52:33 <kalev> +1 FE
17:52:40 <Southern_Gentlem> +1 fe
17:52:42 <sgallagh> tl;dr: I'd rather us not go backwards just as we enter Freeze for libgit2, since a bunch of stuff depends on it.
17:52:54 <jlanda> +1 FE
17:53:23 <bcotton> +1 FE
17:53:40 <frantisekz> +1 FE
17:54:01 <adamw> proposed #agreed 1636184 - AcceptedFreezeException (Final) - we grant freeze exception for all changes required to unpick the erroneous libgit2 default module stream addition here, including an FE for a non-modular libgit2 build to match the one that was in the default module stream
17:54:10 <sgallagh> Thanks; I noticed that the previous non-modular RPM in the repos was at least a point-release behind the module
17:54:16 <frantisekz> ack
17:54:20 <kalev> ack
17:54:21 <sgallagh> ack
17:54:35 <bcotton> ack
17:54:41 <Southern_Gentlem> ack
17:54:59 <adamw> #agreed 1636184 - AcceptedFreezeException (Final) - we grant freeze exception for all changes required to unpick the erroneous libgit2 default module stream addition here, including an FE for a non-modular libgit2 build to match the one that was in the default module stream
17:55:11 <adamw> #topic Really the end of proposed FEs
17:55:18 <adamw> #info really moving onto accepted blockers
17:55:35 <adamw> so just as a reminder, from this point on we're checking the status of these bugs, not voting on them any more
17:55:45 <adamw> it's just a mechanism to try and make sure no blockers get forgot/neglected
17:55:58 <sgallagh> No blocker left behind!
17:56:02 <adamw> #topic (1625269) The Region and Languages section displays in a very small window and therefore is difficult to use.
17:56:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625269
17:56:02 <adamw> #info Accepted Blocker, gnome-control-center, ON_QA
17:56:30 <adamw> #info QA needs to confirm the fix for this with current stable packages
17:56:52 <adamw> i'll needinfo lruzicka
17:57:23 <adamw> think that's all here...
17:57:25 <adamw> #topic (1628263) wifi doesnt connect from the drop down in live WS F29 Beta 1.1
17:57:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628263
17:57:25 <adamw> #info Accepted Blocker, gnome-shell, MODIFIED
17:58:06 <adamw> #info this one got lost in bodhi-land somewhere, should have been closed already
17:58:09 <adamw> i'll go ahead and close it
17:58:36 <adamw> #topic (1630899) unmounting ISO in Nautilus crashes gnome-shell and kills a wayland session
17:58:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1630899
17:58:36 <adamw> #info Accepted Blocker, gnome-shell, NEW
17:58:52 <kalev> I think I saw this got fixed upstream today or so
17:59:19 <adamw> oo, taht sounds good
17:59:24 <adamw> can you post an update in the bug?
17:59:26 <kalev> or hm, maybe I'm confusing it with something else, let me check
18:00:54 <kalev> no, sorry, it was something else :)
18:01:03 <adamw> ok
18:01:10 <adamw> can we say the ball's in your court to look into this one then?
18:01:36 <kalev> sure, I can try to get someone to look into it
18:01:58 <adamw> thanks
18:02:03 <cmurf> work around is 'eject sr0' ?
18:02:06 <adamw> #info we are still waiting on a fix for this, kalev will try and look into it
18:02:25 <adamw> i guess?
18:03:08 <adamw> #topic (1625253) gnome-shell on wayland might crash when moving bookmark in nautilus
18:03:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625253
18:03:08 <adamw> #info Accepted Blocker, mutter, NEW
18:03:39 <kalev> that was the one that I saw got fixed :)
18:03:40 <adamw> that MR is merged
18:03:42 <adamw> aha :)
18:03:46 <adamw> so we can set this to POST now i guess
18:03:55 <adamw> and the mutter / g-s update should be marked as fixing it
18:04:09 * kalev nods.
18:04:32 <adamw> #info the fix for this is merged upstream so the mutter release that's coming today should fix it
18:04:43 <adamw> #topic (1632656) iSCSI Reverse CHAP authentication not working
18:04:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632656
18:04:43 <adamw> #info Accepted Blocker, python-blivet, MODIFIED
18:05:09 <adamw> looks like we need lnie to confirm the fix here and get the update pushed stable
18:05:18 <adamw> #info fix for this is now in testing, we will ask lnie to confirm the fix
18:05:39 <adamw> ....aand that's everything
18:05:51 <Southern_Gentlem> yeah
18:06:17 <adamw> #topic End of accepted blockers
18:06:20 <adamw> #topic Open floor
18:06:23 <adamw> any other business, folks?
18:06:34 <cmurf> zippo
18:06:49 * sgallagh has nothing
18:06:50 <adamw> i don't think f29 has lighter technology i'm afraid
18:07:06 <sgallagh> adamw: It *does* seem to be starting a lot of fires...
18:07:07 <cmurf> you're gonna light the fuse so there you go
18:07:10 <adamw> =)
18:07:28 <adamw> everyone's a comedian, huh
18:08:18 <cmurf> corny jokes that make people run away?
18:08:19 <adamw> thanks a lot for coming, everyone
18:09:02 <frantisekz> thanks adamw
18:09:48 <adamw> #endmeeting