16:00:58 <adamw> #startmeeting F28-blocker-review
16:00:58 <zodbot> Meeting started Mon Apr 23 16:00:58 2018 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:58 <zodbot> The meeting name has been set to 'f28-blocker-review'
16:00:58 <adamw> #meetingname F28-blocker-review
16:00:58 <adamw> #topic Roll Call
16:00:58 <zodbot> The meeting name has been set to 'f28-blocker-review'
16:01:06 <adamw> morning folks, who's around for some blocker review?
16:01:10 * sumantro is here
16:01:12 * lruzicka is here
16:01:31 <frantisekz> .hello2
16:01:32 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:01 * kparal is here
16:02:14 <sgallagh> .hello2
16:02:15 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:02:22 <dustymabe> .hello2
16:02:23 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:03:39 * Southern_Gentlem 
16:05:03 <Lailah> Hello
16:05:05 * satellit listening
16:05:13 <Lailah> .fas lailah
16:05:13 <zodbot> Lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:05:13 * pwhalen is here
16:05:28 <lroca> .fas roca
16:05:30 <kparal> frantisekz: is pschindl coming, do you know?
16:05:31 <adamw> morning folks!
16:05:32 <zodbot> lroca: aliasgiogiwyvernspur 'Kenny Bolser' <kbolsre@procadguru.com> - grocanar 'Eric Doutreleau' <eric@doutreleau.fr> - roca 'Luis Roca' <luisroca@protonmail.com> - bhamilton 'Benjamin Hamilton' <bhamilton@metrocast.com> - pedrocarvalho 'pedro carvalho' <p@43.lc> - dgollub 'Daniel Gollub' <dgollub@brocade.com> - rixx 'Rick Tessari' <rixx@metrocast.net> - rocavalcante 'Rodrigo Araujo Cavalcante' <rodrigoibka@gmail.com> (1 more message)
16:05:34 <adamw> how's everyone doing?
16:05:40 * kparal pokes coremodule
16:05:44 <Lailah> Good afternoon
16:05:46 <adamw> #chair sgallagh dustymabe
16:05:46 <zodbot> Current chairs: adamw dustymabe sgallagh
16:05:49 <kalev> .hello2
16:05:50 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:05:57 <frantisekz> kparal: Don't know for sure, but I wouldn't be ton it
16:05:57 <adamw> impending boilerplate alert:
16:05:58 <adamw> #topic Introduction
16:05:58 <adamw> Why are we here?
16:05:59 <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:05:59 <adamw> #info We'll be following the process outlined at:
16:05:59 <lruzicka> Hello, I am fine, hope you're too
16:06:00 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:01 <adamw> #info The bugs up for review today are available at:
16:06:01 <lroca> Hello
16:06:03 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:05 <adamw> #info The criteria for release blocking bugs can be found at:
16:06:07 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:06:09 <adamw> #link https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria
16:06:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_28_Final_Release_Criteria
16:06:13 <adamw> anyone want to secretarialize?
16:06:39 <kparal> frantisekz: hint hint
16:06:52 <frantisekz> :D
16:07:06 * adamw prepares the Volunteering Stick
16:07:17 <frantisekz> well then :)
16:07:28 <sgallagh> adamw: Is that the blunt one or the sharp one?
16:07:29 <Lailah> What is a volunteering stick adamw ?
16:07:35 <kparal> awesome, nice counting on you frantisekz :)
16:07:54 <adamw> sgallagh: it's the one with splinters and nails in it
16:08:07 <sgallagh> I thought that one was the clue-by-four
16:08:13 <adamw> #info frantisekz will secretarialize
16:08:21 <adamw> we have:
16:08:32 <lroca> What is the cut off for blockers, bugs etc.?
16:08:33 <adamw> #info 3 Proposed Blockers
16:08:33 <adamw> #info 4 Accepted Blockers
16:08:39 <adamw> #info 10 Proposed Freeze Exceptions
16:08:39 <adamw> #info 4 Accepted Freeze Exceptions
16:08:44 <adamw> lroca: how do you mean, 'cutoff'?
16:08:58 <sgallagh> lroca: A "Go" declaration at a Go/No-Go meeting
16:09:18 <sgallagh> After that point, the machinery is in motion and not realistically stoppabel
16:09:22 <lroca> I entered a bug report this morning for gnome-calendar
16:09:22 <sgallagh> *stoppable
16:09:43 <sgallagh> lroca: Did you submit it for consideration?
16:10:10 <lroca> sgallagh: To bugzilla but didn't label it
16:10:26 * lbrabec is here
16:10:27 <lbrabec> hi
16:10:28 <adamw> it won't come up unless it's proposed as a blocker or FE
16:10:31 <adamw> you can propose it now if you like
16:10:33 <sgallagh> lroca: If you think it's a blocker, propose it using https://qa.fedoraproject.org/blockerbugs/propose_bug
16:11:37 <kparal> lbrabec++
16:11:37 <zodbot> kparal: Karma for lbrabec changed to 1 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:11:51 <lroca> I'll do both for (here and on the form)
16:12:10 <adamw> OK, let's get started with the proposed blockers!
16:12:19 <adamw> #info starting with proposed blockers
16:12:25 <adamw> #topic (1569321) cloud-init-17.1-4.fc28 sets BOOTPROTO=none when using EC2 private network only
16:12:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1569321
16:12:25 <adamw> #info Proposed Blocker, cloud-init, MODIFIED
16:13:12 <sgallagh> From the replies on the BZ, it sounds like a judgement call. It's not going to affect everyone, so we have to decide if it's a sufficiently-large subset of Cloud users to block on.
16:13:31 <sgallagh> I'm definitely +1 FE in any case and there appears to be a fix ready.
16:13:39 <kalev> I don't have a strong opinion on blocker status, but definitely +1 FE
16:14:12 <frantisekz> +1 FE
16:14:14 <sgallagh> The size of the patch makes me a little nervous, but it's fixing a serious issue so I'd be amenable
16:14:14 <sumantro> +1FE
16:14:23 <kparal> it's going to affect everyone with private ip, doesn't it?
16:14:23 <lruzicka> I think that this one is not so severe to block the whole release
16:14:23 <adamw> i'm rather influenced to +1 blocker by https://bugzilla.redhat.com/show_bug.cgi?id=1569321#c3
16:14:26 <lruzicka> +1 FE
16:14:40 <adamw> do the math on that comment: out of 200 VMs he has running Fedora, 6 have public IPs
16:14:44 <adamw> that means 194 *don't*
16:14:50 <adamw> and thus would be affected by the bug...
16:14:56 <kparal> it seems like a clear blocker to me unless I'm missing something
16:15:09 <Southern_Gentlem> +1 blocker
16:15:10 <pwhalen> adamw, agreed, +1 blocker
16:15:11 <adamw> of course, that's just one user, but...seems significant
16:15:32 <lroca> +1 blocker
16:15:43 <Lailah> I don't understand this one TBH so I'm +0
16:15:45 <Lailah> Sorry
16:16:16 <sgallagh> adamw: Well, it's hard to say how significant it would be.
16:16:22 <sgallagh> I don't have any information on how common a setup that is.
16:16:37 <sgallagh> If 99.99% of Amazon users use only public IPs... ?
16:16:42 <lruzicka> according to the bugzilla, it is fixed anyway
16:17:05 <adamw> well, yeah, but if we make this a blocker, if any issue appears with the fix, we have to fix that
16:17:09 <kparal> lruzicka: the point is, if this is a blocker, the fix is pulled in and it has to work. so it it turns out it's not working, we will wait further
16:17:11 <adamw> if we make it an FE, we can back out the fix and still ship
16:17:18 <adamw> so it's still significantly
16:17:24 <adamw> Lailah: that's fine, better than voting at random :) thanks
16:17:55 <sgallagh> I guess I'm 0 on blocker because I don't have a sense of how widespread it might be. I'm definitely +1 FE
16:18:04 <sgallagh> (And, reading the patch, the fix seems sensible)
16:18:13 <kparal> I can't say how often public IPs are used in cloud envs, but unless proven otherwise, I'd assume the answer is "significantly enough"
16:18:29 <adamw> kparal: it's the opposite
16:18:33 <lbrabec> would this bug affect testcloud instances in taskotron stack?
16:18:35 <adamw> kparal: instances *with* public IPs are fine
16:18:42 <adamw> kparal: it's instances *without* public IPs that have the bug
16:18:53 <kparal> s/public/private
16:18:59 <adamw> =)
16:19:01 <kparal> mistyped
16:19:08 <sgallagh> Right, and in general (it seems to me) the point of using a public cloud would be for your VMs to be, well, publicly accessible
16:19:27 <lruzicka> kparal: adamw: I feel the same as sgallagh, I think that it is too strict to block everything based on this one ...
16:19:27 <kparal> like, say, projects on github?
16:19:30 <sgallagh> But obviously we know of at least one case where there's a different policy
16:19:42 <adamw> sgallagh: not really. we're all about the microservices and containers now, right?
16:19:57 <adamw> sgallagh: only the ones which are ultimately public-facing need public IPs - the public-facing web server or whatever.
16:20:01 <kparal> deploying a cloud image without connectivity is pretty bad, seems to me
16:20:06 <adamw> all the microservices that whir away in the background don't need to be.
16:20:13 * sgallagh nods
16:20:15 <adamw> they only need to be able to talk to *each other*
16:20:23 <kparal> adamw: good point
16:20:40 <dustymabe> does anyone have any questions about the bug
16:20:40 <kparal> or we can ask cloud sig, of course
16:20:42 <sgallagh> I'm not disagreeing with you, it's that I just have no information about the relative usage
16:20:43 <dustymabe> I might be able to answer
16:20:51 <kparal> dustymabe: welcome
16:20:56 * dustymabe waves
16:21:11 <kparal> dustymabe: how often do cloud instances have private IPs?
16:21:19 <lruzicka> please explain. dustymabe
16:21:33 <adamw> dustymabe: i don't think we have questions about the bug
16:21:40 <dustymabe> kparal: it depends on the user.
16:21:42 <adamw> the question is how common/uncommin it's likely to be.
16:21:57 <dustymabe> so for example a lot of "cloud shops" tend to set up a few nodes as entrypoints for services
16:22:12 <dustymabe> and then they connect to other hosts within a "private" network
16:22:16 <adamw> are there lots of folks out there running fedora on cloud instances with no public ip, like Joe, or are there...not.
16:22:54 <dustymabe> adamw: I think if you are running a more compicated setup (like most businesses do) then you are probably using a setup like what Joe is doing
16:23:00 <sgallagh> dustymabe: Sounds like you're saying this would be the rule rather than the exception for the set of users Fedora Cloud addresses, yes?
16:23:04 <adamw> well
16:23:07 <adamw> there's a missing link there
16:23:11 <dustymabe> if you are a casual user, then no you wouldn't do this
16:23:25 <adamw> are 'most businesses' running 'more complicated setups' going to be running *fedora*? :P
16:23:31 <dustymabe> adamw: :)
16:23:48 <dustymabe> good question, probably more of them would be running CentOS or RHEL
16:23:52 <lruzicka> dustymabe: Would such businesses use Fedora for their cloud?
16:23:54 <Southern_Gentlem> most csual users are not running amazon clouds either
16:24:04 <sgallagh> adamw: Not a valid question.
16:24:07 <lruzicka> adamw: You were faster :)
16:24:16 <sgallagh> I think the real answer is "If they ARE running Fedora, would they be doing this?"
16:24:25 <dustymabe> Southern_Gentlem: I think "spin a node up in AWS" is becoming a lot more common than you think
16:24:30 <sgallagh> s/real answer/real question/
16:24:44 <sgallagh> Because if the answer to that question is "yes", I'd call it a blocker
16:24:55 <adamw> sgallagh: i'd say they're the same question spun two different ways.
16:25:26 <kalev> is it worth arguing over the blocker status? let's just take the fix and argue over blocker status if it doesn't work?
16:25:30 <dustymabe> note, i'm not necessarily advocating for *blocker* here, just trying to present information
16:25:30 <adamw> sgallagh: if our userbase is 99% people experimenting on single nodes, that's one case. if our userbase is 50% that and 50% people running serious setups at scale, that's another case.
16:25:47 <adamw> kalev: i had a proposal for that lined up when we started interrogating dusty...
16:25:48 <adamw> proposed #agreed 1569231 - AcceptedFreezeException (Final), punt (delay decision) on blocker - this is a judgment call as it depends how common ec2 instances with only private IPs are. We agree this is at least serious enough to be an FE; we don't yet have enough data to be totally sure if it's serious enough to be a blocker. If the fix presents problems, we will revisit whether to make this a blocker.
16:25:58 <kalev> ack
16:25:59 <dustymabe> adamw: +1
16:26:00 <dustymabe> ack
16:26:02 <sgallagh> adamw: Yes, that's what I'm trying to work out
16:26:03 <frantisekz> ack
16:26:04 <lruzicka> ack
16:26:06 <Lailah> ack
16:26:08 <Southern_Gentlem> ack
16:26:09 <sumantro> ack
16:26:12 <lbrabec> ack
16:26:12 <adamw> #agreed 1569231 - AcceptedFreezeException (Final), punt (delay decision) on blocker - this is a judgment call as it depends how common ec2 instances with only private IPs are. We agree this is at least serious enough to be an FE; we don't yet have enough data to be totally sure if it's serious enough to be a blocker. If the fix presents problems, we will revisit whether to make this a blocker.
16:26:13 <pwhalen> ack
16:26:16 <adamw> alrighty then!
16:26:17 <lroca> ack
16:26:19 <sgallagh> ack
16:26:24 <adamw> #topic (1557655) Install to system with HPSA storage fails to boot, stops at "Failed to start udev Wait for Complete Device Initialization"
16:26:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557655
16:26:25 <adamw> #info Proposed Blocker, kernel, NEW
16:26:32 <dustymabe> if I get some cloud images prepared would anybody here be willing to test it out?
16:27:23 <Lailah> Uhm,  let me read....
16:27:26 <adamw> coremodule's not around, right? OK, I volunteer him. :P
16:27:31 <adamw> i also volunteer sgallagh
16:27:33 <pwhalen> dustymabe, sure
16:27:37 * adamw wipes the blood off the Volunteering Stick
16:27:40 <dustymabe> thanks!
16:27:48 <sumantro> dustymabe, for sure!
16:27:53 <kparal> also lbrabec is our local cloud guru
16:28:02 <kparal> let's volunteer him as well
16:28:04 <dustymabe> yeah? that's awesome
16:28:11 <sgallagh> Didn't we decide a release or two ago that we didn't have the test capability to block on FCoE?
16:28:20 <kparal> dustymabe: meaning he knows what the cloud is, which we don't
16:28:21 <adamw> sgallagh: well, two things.
16:28:22 * lroca wishes "Steps to reproduce" was filled out more often
16:28:26 <adamw> one, now we do, which is why this bug.
16:28:35 <adamw> two, this bug is not in fact about fcoe any more, which is why i re-proposed it.
16:28:39 <sgallagh> oh
16:28:44 * sgallagh reads further
16:28:50 <adamw> lroca: "steps to reproduce" involves "go get a system with an HPSA raid controller".
16:29:09 <Lailah> adamw:  Another bug I don't understand  :-(
16:29:19 <adamw> well, it's not actually that complicated
16:29:20 * jforbes notes this bug is also not kernel
16:29:33 <adamw> if you've got a system with a particular storage controller, installing to it doesn't work.
16:29:36 <adamw> is more or less what it boils down to.
16:29:45 <Lailah> Oh...
16:29:59 <Lailah> And how common is this particular type of storage?
16:30:04 <adamw> good question!
16:30:18 <adamw> jforbes: stop me if i'm wrong anywhere here, this is all five-minutes-of-google expertise
16:30:21 <lroca> adamw: true :)
16:30:27 <adamw> aiui, hpsa is HP's enterprise storage stuff
16:30:30 <lbrabec> kparal: sure
16:30:35 <adamw> it stands for 'hp smart array' i think
16:30:37 <adamw> so, stuff like https://www.hpe.com/us/en/product-catalog/servers/smart-array-controllers-and-smart-host-bus-adapters.hits-12.html
16:30:42 <jforbes> right
16:31:07 <jforbes> As a fedora userbase I expect usage is low, but not nonexistent.
16:31:23 <adamw> if you do 'man hpsa' you'll see a list of supported models
16:31:27 <sgallagh> https://www.idc.com/getdoc.jsp?containerId=prUS43274017 suggests that HP has the largest chunk of the storage market. Not sure how much of that is HPSA though
16:31:29 <adamw> (it's quite long so i won't paste it here)
16:31:42 <Lailah> Okay
16:32:13 <adamw> sgall "enterprise storage systems" covers quite a lot of...stuff, i think...
16:32:31 <jforbes> sgallagh: that has no relevance on how it is connected, I know shops with massive racks of IBM storage, not connected to a single IBM machine or using their adapters
16:32:36 * sgallagh nods
16:32:52 <adamw> i cited the criterion and relevant footnote at https://bugzilla.redhat.com/show_bug.cgi?id=1557655#c43
16:33:03 <adamw> so i'd say we're basically making a judgment call under that footnote here
16:33:26 <adamw> i'm probably inclined to -1 on the basis that i really suspect this is pretty niche hardware for fedora usage
16:33:31 <sgallagh> I'm leaning towards -1
16:33:34 * sgallagh nods
16:33:35 * mkolman sees smart array being mentioned and remembers how bloody annoying to was it to fix it yet again back in RHEL 5
16:33:41 <mkolman> never again
16:33:43 <Lailah> Me too
16:33:44 <adamw> =)
16:33:44 <Lailah> -1
16:33:46 <sumantro> -1
16:33:50 <Southern_Gentlem> -1
16:33:56 <jforbes> I would agree, though it would be nice to see it fixed still.
16:34:05 <pschindl_wfh> -1
16:34:06 <lruzicka> -1
16:34:07 <sgallagh> I'd actually also go so far as to -1 FE it, since I worry that fixes might break other stuff
16:34:16 <adamw> i'd want to see the fix before voting on any fe
16:34:24 <sgallagh> yes
16:34:36 <lruzicka> reasonable
16:34:40 <jforbes> sgallagh: at this point, we don't even know where the issue lies other than "not kernel" since the F28 kernel works fine with that storage on F27
16:34:57 <sgallagh> It sounds like it doesn't break DURING install, so if it was fixed post-release, we could recommend installing with network repos available
16:35:27 <adamw> proposed #agreed 1557655 - RejectedBlocker (Final) - we consider this bug as falling under the "System-specific bugs" footnote to the RAID criterion, and our feeling is that this family of storage controllers is not sufficiently commonly used with Fedora to make this bug constitute a release blocker.
16:35:45 <lruzicka> ack
16:35:46 <lbrabec> ack
16:35:48 <sgallagh> ack
16:35:49 <Southern_Gentlem> ack
16:35:50 <kalev> ack
16:35:50 <sumantro> ack
16:35:53 <frantisekz> ack
16:35:56 <adamw> sgallagh: no, I think the installer hangs.
16:35:57 <Lailah> ack
16:36:02 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1557655#c10
16:36:02 <sgallagh> Oh?
16:36:07 <adamw> "As shown in the attached screenshot,the installer just hang there"
16:36:09 <pschindl_wfh> ack
16:36:18 * sgallagh sighs
16:36:25 <adamw> we can ship an upadtes.img, though.
16:36:29 <adamw> #agreed 1557655 - RejectedBlocker (Final) - we consider this bug as falling under the "System-specific bugs" footnote to the RAID criterion, and our feeling is that this family of storage controllers is not sufficiently commonly used with Fedora to make this bug constitute a release blocker.
16:36:30 <kparal> ack
16:36:30 <sgallagh> I'm sticking with my statement
16:36:40 <adamw> #topic (1570552) Email composing loses Text when clearing selection by clicking
16:36:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1570552
16:36:41 <adamw> #info Proposed Blocker, webkit2gtk3, NEW
16:36:57 <lroca> Do we have any hardware usage data via surveys etc.?
16:37:00 <adamw> oh man, if we're gonna block on evolution composer bugs, we wouldn't have shipped for the last ten releases. :P
16:37:07 <adamw> lroca: not really, no, unfortunately
16:37:36 <Lailah> Okay, wait a second, I need to read this....
16:37:45 <lruzicka> yes, after reading sgallagh's comment in bugzille, I'd go with -1
16:38:14 <adamw> huh, this one does sound bad, though.
16:38:20 <adamw> i've never once run into it, though.
16:38:26 <kparal> I guess the difference is X vs Wayland
16:38:27 <lroca> adamw: I suppose it's like herding cats
16:38:36 <lruzicka> yup, wayland only
16:38:55 <kparal> lruzicka: well, you haven't tested latest compose with wayland
16:38:57 <sgallagh> I'm not thrilled with the idea of fixing it with a rebase of the package though
16:39:02 <lruzicka> kparal: I have
16:39:03 <kparal> at least according to your description
16:39:04 <adamw> hmm, the update that fixes this is a big change
16:39:10 * adamw runs wayland
16:39:13 <kalev> I think I'd be -1 blocker, but possibly +1 FE -- the update that is fixing that has been in updates-testing for 5 days now and has gotten good karma
16:39:16 <adamw> oh, the bug is a new one?
16:39:21 <Lailah> It says that it should be fixed
16:39:28 <lruzicka> kparal: How come, today the latest was 2018-04-22, I tested on this
16:39:31 <adamw> kalev: well, the update that *introduced* this apparently got good karma too, so...;)
16:39:35 <Southern_Gentlem> +1 FE
16:39:37 <kalev> yeah :)
16:39:45 <kparal> lruzicka: ok, now I understood how you meant it, I guess
16:39:46 <lruzicka> kparal: I tried to reproduce the bug and I did :)
16:39:49 <Lailah> Anyway, I don't think is a blocker
16:39:51 <lroca> +1 FE
16:39:58 <Lailah> +1 FE
16:40:00 <pschindl_wfh> I'm -1 blocker.
16:40:05 <lruzicka> +1 FE
16:40:10 <adamw> i'm not sure i agree with -1 blocker, tbh
16:40:12 <pschindl_wfh> But totally +1 FE
16:40:14 <adamw> this is pretty basic stuff
16:40:24 <Lailah> adamw:  Finally a bug I understand :D
16:40:30 <adamw> do we *really* want to ship a desktop OS that eats your text entry?
16:40:36 <adamw> i mean, that's a pretty bad bug, let's be honest.
16:40:40 <kparal> none of those apps mentioned are on a default install
16:40:46 <adamw> evolution is.
16:40:50 <lroca> Evolution
16:40:52 <lruzicka> adamw: But it only happens if you double click on a chunk of text and then click next to it
16:40:57 <kparal> are you sure evolution is in?
16:41:03 <sgallagh> lruzicka: Only directly next to it?
16:41:05 <kparal> and not just evolution-data-server?
16:41:07 <Lailah> Which is a pretty common action.
16:41:08 * adamw double checks.
16:41:11 <Southern_Gentlem> kparal, has been for years
16:41:12 <Lailah> I often did it
16:41:13 <sgallagh> Yeah, I thought they dropped evo
16:41:15 <lruzicka> Evolution is the core app
16:41:24 <kparal> alright
16:41:37 <adamw> it's in workstation-product.
16:41:46 <sgallagh> lruzicka: Does it matter where you click, or only directly next to it?
16:41:49 <Lailah> Yup. It's the mail default
16:41:54 <sgallagh> ok
16:41:55 <kparal> so this happens every time you select a text and then unselect it?
16:41:58 <lroca> I use it daily but I have to change prefs from edit in text editor to test this
16:42:13 * adamw still can't reproduce this locally, but if two other people can...that's bad enough.
16:42:16 <lruzicka> sgallagh: I did click next to it. Bu I can try, it's still running in my VM
16:42:31 <adamw> oh hah
16:42:37 <adamw> i can't reproduce it because i have the fixed gtk3 installed. duh
16:42:48 <kparal> bad adamw for installing updates
16:42:58 <Lailah> adamw:  So the fix works?
16:43:03 <sgallagh> adamw: Upkarma!
16:43:07 <adamw> i mean, if i can't reproduce the bug, i guess it does?
16:43:23 * sgallagh installs evo to try
16:43:24 <kparal> not necessarily. you can also be lame
16:43:26 <Southern_Gentlem> so +fe should allow the fix in, if we can test a new compose with this then we can say blocker
16:43:39 <lruzicka> guys: I cannot reproduce it now, but I did not do anything to the VM
16:43:41 <adamw> Southern_Gentlem: eh?
16:43:52 <lruzicka> just started Evolution for the second time
16:43:57 * lruzicka is perplexed
16:44:02 <kparal> lruzicka: still wayland?
16:44:07 <lruzicka> kparal: Yes
16:44:13 <Southern_Gentlem> adamw,  has the new fix been allowed in a new compose ?
16:44:18 <kparal> lruzicka: check gtk version
16:44:43 <sgallagh> I can't reproduce this with gtk3-3.22.29-1.fc28.x86_64
16:45:03 <lruzicka> kparal: I am checking
16:45:17 <adamw> https://bugzilla.gnome.org/show_bug.cgi?id=794630 has another report of it
16:45:26 <adamw> "PS. Even worse composer bug has appeared after yesterday's update too: sometimes text gets seemingly randomly deleted just by left-clicking in the text area."
16:45:45 <adamw> kalev: do we actually know that the two bugs described are the same bug?
16:46:15 <kalev> I don't know
16:46:15 <kparal> lruzicka: it can be a race condition
16:46:31 <adamw> because the RH bug we're discussing here is clearly a report of "text gets eaten" but it's been marked as a downstream of the upstream bug https://gitlab.gnome.org/GNOME/gtk/issues/132 , which is clearly a report of "auto-scroll happens unexpectedly"
16:46:59 <lruzicka> kparal: GTK is 3.22.30
16:47:12 <sgallagh> lruzicka: That's the fixed version (supposedly)
16:47:16 * adamw goes to hunt down an mclasen
16:47:18 <sgallagh> You sure you didn't update it?
16:47:25 <mclasen> I'm here, just distracted
16:47:28 <mclasen> whats the question ?
16:47:37 <kparal> lruzicka: that's the fixed version
16:47:38 <kalev> adamw: https://bugs.webkit.org/show_bug.cgi?id=184446 seems to indicate it's the same bug
16:47:44 <kparal> lruzicka: so you have updated it
16:47:45 <lruzicka> sgallagh: Oh wait, now I remember. It cried for updates and I did update
16:47:53 <adamw> "cried" :P
16:48:19 <lruzicka> sorry for having mistaken you
16:48:27 <kparal> lruzicka: at least we can confirm the fix works :)
16:48:37 <kparal> give it a karma
16:48:48 <sgallagh> I still can't reproduce the issue with the .29 version though
16:48:56 <sgallagh> So it definitely doesn't apply to all systems
16:49:16 <adamw> the reports use words like "sometimes" and "often"
16:49:21 <kalev> mclasen: the question was, does gtk+ 3.22.30 fix https://bugzilla.redhat.com/show_bug.cgi?id=1570552 ?
16:49:22 <adamw> which seem to suggest it's not a 100% reproducer
16:49:41 <adamw> mclasen: right, specifically, i'm concerned that two bugs seem to be treated as one
16:49:46 <sgallagh> adamw: I've been opening and closing windows in EVO and typing everywhere I can find
16:50:00 <Southern_Gentlem> sgallagh, X or wayland?
16:50:03 <adamw> mclasen: the RH bug that's proposed as a blocker is clearly about "highlighted text sometimes gets eaten"
16:50:05 <sgallagh> Southern_Gentlem: Wayland
16:50:19 <adamw> mclasen: but the upstream bug it's been linked to seems to be about "auto-scrolling happens unexpectedly"
16:50:42 <sgallagh> Southern_Gentlem: Wayland on Nouveau as opposed to Intel, though. Which I suppose could be relevant.
16:50:50 <adamw> those seem like rather different bugs to me...so i want to be sure that pulling in what appears to be the fix for "auto-scrolling happens unexpectedly" in fact also fixed "highlighted text gets eaten"
16:50:53 <sgallagh> But if the fix is in gtk3, I wouldn't expect that to be the case
16:54:05 <sgallagh> I'm -1 Blocker, +1 FE here, but I'm (still) not thrilled with the idea of pulling in a rebase to fix it. But if it's sufficiently karma'd, I'll be okay with it
16:54:16 <Southern_Gentlem> the so-called fix appears to be done so what do we need to do for it to be iin the final compsde
16:54:37 <adamw> in any case...since we have three different people saying they'd hit this (j. haas, lukas, and tanu in https://bugzilla.gnome.org/show_bug.cgi?id=794630 ), i'm really kinda inclined to +1 it, i really don't think we can ship a 'stable' workstation OS that is known to do this.
16:54:45 <kalev> +1 FE
16:54:56 <adamw> to be clear, i meant +1 blocker
16:55:03 <adamw> but if everyone else is -1, hey.
16:55:09 <kalev> ok, +1 blocker too then :)
16:55:11 <lroca> +1
16:55:20 <sumantro> +1 blocker
16:55:42 <Lailah> Mmmh...
16:55:42 <lruzicka> ok, +1 blocker
16:55:44 <frantisekz> +1 blocker
16:55:47 <Lailah> Still think the same
16:55:54 <mclasen> adamw: can't look in detail right now. I'll put it on my list
16:55:57 <Lailah> -1 blocker  +1 FE
16:56:13 <mclasen> there was at least one fix wrt to input methods. not sure if I cherry picked that for 3.22
16:56:14 <adamw> mclasen: thanks
16:56:17 <mclasen> will check
16:56:45 <adamw> mclasen: if we can look into it in more detail later today that'd be great, i want to be sure someone knows what's going on with this one...
16:57:18 <adamw> oh, https://bugs.webkit.org/show_bug.cgi?id=184446 also seems relevant. fun
16:57:19 <mclasen> I have it open in a tab now, so there's hope
16:57:27 <pwhalen> +1 blocker
16:57:58 <adamw> ah. that appears to be the source of the claim that they're the same bug: it says that "wayland: Don't emit signals if nothing changed" fixes it.
16:58:06 <adamw> OK, let's follow up after the meeting
16:58:08 * adamw counts votes
16:58:16 <kparal> +1 blocker
16:58:34 <adamw> we have -2/+8 blocker, i think
16:58:41 <adamw> that seems a big enough consensus to accept
16:59:26 <adamw> btw, i'll note that one evolution composer issue I *do* know about is that 'undo' is nowhere near 100% reliable in evolution
16:59:48 <adamw> formatting issues and particularly anything that touches anywhere near the signature can really confuse it
17:00:05 <adamw> you can't rely at all that if you do 5 things in the evo composer than undo them, you'll be back in the state you started
17:00:07 <adamw> so.
17:00:23 * lroca nods
17:00:56 <adamw> proposed #agreed 1570552 - AcceptedBlocker (Final) - accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must...withstand a basic functionality test", on the basis that being able to type, select and unselect text is pretty 'basic functionality' for Evolution, dissenting votes from sgallagh and lailah
17:01:13 <sgallagh> ack
17:01:18 <lroca> ack
17:01:19 <kalev> ack
17:01:20 <pwhalen> ack
17:01:28 <lbrabec> ack
17:01:29 <Lailah> ack
17:01:31 <frantisekz> ack
17:01:31 <sumantro> ack
17:01:35 <kparal> ack
17:01:46 <adamw> #agreed 1570552 - AcceptedBlocker (Final) - accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must...withstand a basic functionality test", on the basis that being able to type, select and unselect text is pretty 'basic functionality' for Evolution, dissenting votes from sgallagh and lailah
17:02:08 <lruzicka> ack
17:02:10 <adamw> OK, that's all the proposed blockers
17:02:28 <lroca> may I propose the gnome-calendar?
17:02:37 <adamw> ah, yes
17:03:00 <adamw> what bug is that?
17:03:01 <lroca> #1570879
17:03:43 <lroca> When I select an event calendar crashes
17:03:44 <adamw> lroca: you've reported it as a private bug.
17:03:49 <adamw> so most people here will not be able to see it.
17:03:52 <lroca> :(
17:04:05 <lroca> Can I change that?
17:04:15 <Lailah> Iroca:  why did you do that?
17:04:47 <sgallagh> I fixed it
17:05:01 <lroca> Lailah: problem reporting flagged keybase and pass phrases as exposed
17:05:24 <lroca> I thought I "deselected" from the checkbox list but.. guess not
17:05:34 <adamw> Lailah: it's a common issue with abrt...
17:05:41 <Lailah> ah
17:05:55 <adamw> #topic (1570879) [abrt] gnome-calendar: gcal_date_chooser_day_set_date(): gnome-calendar killed by SIGSEGV
17:05:57 <lroca> sgallagh: thank you
17:06:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1570879
17:06:12 <adamw> #info Proposed Blocker, gnome-calendar, NEW
17:06:38 <kparal> is calendar preinstalled now?
17:06:45 <adamw> it's in gnome-desktop comps group
17:06:48 <adamw> which is in the workstation kickstart
17:06:51 <adamw> so i think yes
17:06:52 * adamw double checks
17:06:53 <sumantro> kparal, yes
17:07:09 <sgallagh> Hmm, I just went ahead and installed it and I'm not seeing the reported crash
17:07:16 <sgallagh> This happens every time for you lroca ?
17:07:21 <lruzicka> kparal: I think it is.
17:07:25 <lroca> Every time. Just did again
17:07:32 <kparal> it might be specific to lroca's events
17:07:41 <adamw> what's the source for your calendar, lroca?
17:07:43 <lroca> I can't select an event.. any event
17:07:46 <lruzicka> kparal: I have also reported such crash via abrt, but I have not seen it for a while now.
17:08:03 <adamw> the backtrace points to a memory allocation issue for some reason, bwt
17:08:03 <adamw> error: Cannot access memory at address 0x38
17:08:04 <kparal> lruzicka: can you check now?
17:08:11 <lroca> These are imported from Fedora Calendar. I was trying to change a meeting time for comm-ops
17:08:16 <lruzicka> kparal: Of course.
17:08:20 <adamw> we could also be in i18n stuff here, i guess
17:08:24 <adamw> what's your locale, lroca?
17:08:28 <kparal> lroca: you can't edit fedocal events remotely
17:08:35 <adamw> kparal: clicking on one shouldn't crash the app.
17:08:38 <kparal> but of course that doesn't disqualify this bug
17:09:11 <adamw> can't reproduce here either (with my own calendar server as the data source...)
17:09:22 <lroca> Creating a new event /within/ the calendar does not crash the app when I click to edit
17:09:46 <Lailah> I remember long ago getting some sort of warning like  "This is a read-only event"  or something like that, not crashing. So I think that is quite a nasty bug.
17:09:58 <adamw> i have a read-only event in my caaaalendar too, as it happens
17:09:59 <lroca> Anything I've imported from FedoCal crashes
17:09:59 <adamw> it's not crashing
17:10:07 <Lailah> I mean, it's frustrating trying to do something and the app just crashes without explanation
17:10:11 <adamw> lroca: how did you 'import' the events exactly?
17:10:47 <lroca> From the site.. selected the iCal (i believe). It opened up calendar and I added it
17:10:55 <lroca> this worked before F28
17:11:35 <lroca> Selecting an event wouldn't crash. .. There were /other/ issues like UTC not syncing I couldn't quite explain but not this
17:12:30 <adamw> lroca: i asked before, but - what's your locale?
17:12:48 <lroca> NYC metro
17:12:56 <lruzicka> how do I delete an event? if click on it, left right button it only opens
17:12:58 <lroca> ..Jersey (:
17:14:02 <sgallagh> I can't reproduce this issue here either
17:14:02 <lroca> lruzicka: these events won't open. Calendar crashes the moment I select them so I can't even delete and start over or reimport
17:14:26 <adamw> hum, seems like date = 0x0 is wrong here.
17:14:28 <sgallagh> So while I feel bad for lroca, I am inclined to vote -1 blocker
17:14:33 <lruzicka> lroca: In my instance, I can create and delete events without crashes, but I did not try import a calendar
17:14:49 <adamw> yeah, it looks to me like there's clearly an issue here but it's not sufficiently reproducible to block fedora on...
17:14:55 <sgallagh> lroca: Can you try `california` as a replacement and see if you can edit your entries through that?
17:15:26 * sgallagh refers to the app named california and is not recommending that lroca move across the continent.
17:15:32 <lruzicka> lroca: kparal: adamw: I am going to report another bug, since the event cannot be deleted when the "announcement" is switched on
17:15:32 <lroca> sgallagh: trying...
17:16:11 <lruzicka> lroca: And now, after the event has been deleted ... it crashed
17:16:40 <lruzicka> And since the calendar is a core app .... definitely a blocker to me
17:16:53 <adamw> lruzicka: sorry, can you explain what you did in more detail?
17:17:13 <lruzicka> adamw: Now ... I have just opened the calendar, added a new event.
17:17:17 <lruzicka> That went fine.
17:17:22 <lroca> sgallagh: crashes
17:17:55 <sgallagh> lroca: That suggests to me that you may actually have bad data somewhere and the underlying routines they both share breaks when parsing it.
17:17:57 <lruzicka> I also changed some event's details, went fine. Then I wanted to delete it, but there was no delete button to be seen until I switched off anouncements.
17:18:06 <lruzicka> After I deleted the event, it crashed.
17:18:12 <adamw> there are some extremely bizarre year, month and date values in this backtrace
17:18:16 <sgallagh> So... a painful bug, but I'm still not convinced we should block on it.
17:18:17 <lroca> IIRC calendar events are imported via Evolution, no?
17:18:21 <adamw> which i suspect is the source of the problem...
17:18:30 <adamw> lroca: evolution-data-server is likely involved
17:18:38 <kparal> adamw: does it start with "star date"?
17:18:41 <sgallagh> adamw: Either that or lroca is a time-traveler.
17:18:59 <adamw> kparal: well, look at frame 13
17:18:59 <adamw> y1 = 2025
17:18:59 <adamw> m1 = 12
17:18:59 <adamw> d1 = 31
17:19:00 <adamw> y2 = 1
17:19:00 <adamw> m2 = 0
17:19:02 <adamw> d2 = 1415120992
17:19:17 <adamw> d2 looks a lot like some sort of integer signing wraparound, in fact?
17:19:25 <adamw> or, wait
17:19:25 <adamw> no
17:19:27 <kparal> not a unix timestamp?
17:19:28 <adamw> it looks like a timestamp
17:19:28 <adamw> yeah
17:19:29 * lroca jumps back into his police box
17:19:31 <adamw> that's what i meant
17:19:56 <adamw> for Tue, 04 Nov 2014 17:09:52 GMT apparently.
17:20:14 <sgallagh> Can't you see!? lroca is trying to warn us that the world will end on New Year's Eve, 2025!
17:20:26 <lroca> :D
17:20:31 <Kohane> LMAO
17:20:39 <adamw> so, i can kinda cut this both ways
17:21:00 <adamw> on the one hand, you can boot a clean VM, run gnome-calendar, and create and delete and edit some simple events
17:21:04 <adamw> which is kinda what i'd call 'basic functionality'
17:21:11 <adamw> otoh, two people have been able to crash it without trying too hard
17:21:32 <sgallagh> And I can't crash it while trying everything I can think of
17:21:33 <lruzicka> adamw: When I deleted now a simple event, it crashed.
17:21:43 <lroca> I'm of the mind to push this and see if evolution-data-server is involved
17:21:54 <lruzicka> adamw: So the basic functionality is still questionable
17:21:56 <adamw> still, to me, it's in a bit of a different bucket from Evolution, yes it's in the default install, but i'm not really sure it's got the kind of functionality expectation behind it...
17:21:58 <adamw> awkward one
17:22:20 <lroca> I'd like to see if this happens on calendar importing...
17:22:35 <sgallagh> I take that back, I finally reproduced it
17:22:35 <lroca> err.. because of importing
17:23:21 <sgallagh> In this case, I just kept adding and deleting events in the local calendar until it crashed
17:23:41 <sgallagh> I'm still not convinced I would slip the release over this though
17:24:12 <kalev> I think I'd not block over this either
17:24:50 <kalev> it's also not something that neccessarily needs to be on the media, can easily be fixed with a 0 day update
17:25:49 <lroca> I'm not disputing and would go from +1 to 0 but does this not violate basic functionality?
17:26:05 <sgallagh> kalev: Are you suggesting that we just drop it from the default install to bypass the blocker criterion?
17:26:12 <sgallagh> (FTR, I'd be fine with that)
17:26:56 <lroca> sgallagh: what would Evolution use as a calendar?
17:27:02 <lruzicka> Well, I would like to mention that a calendar somehow is a "basic" app that the gnome users might expect
17:27:03 <sgallagh> lroca... it has its own
17:27:07 <adamw> lroca: "basic functionality" has turned out to be an extremely elastic phrase :P
17:27:11 <adamw> evolution is its own calendar
17:27:16 <adamw> this crash is clearly in gnome-calendar code
17:27:21 <sgallagh> Hmm, I wonder if the built-in one has this same bug
17:27:30 <adamw> it's possible e-d-s is feeding it garbage, but even so it should probably cope.
17:27:34 <kalev> sgallagh: no, I was suggesting that this bug doesn't sound serious enough to cause a slip for a whole fedora release
17:27:39 <lroca> adamw: I thought they were connected
17:27:54 <adamw> lroca: they both ultimately store the data in e-d-s.
17:28:09 <adamw> look at e-d-s as the common backend storage and evolution and gnome-calendar as alternative clients.
17:28:24 <adamw> but this crash is clearly happening in code that's unique to gnome-calendar.
17:28:41 <adamw> nothing in the bug suggestions evolution itself would crash in the same way.
17:28:53 <adamw> i mean, it's easy enough to check - run evolution and try importing the event through that...
17:28:59 <lroca> adamw: thanks for the clarityRE e-d-s
17:29:02 <sgallagh> Yeah, doing that now
17:29:50 <lroca> Evolution doesn't crash
17:29:54 <lroca> (:
17:30:19 <sgallagh> Yeah, I can't crash it there either
17:30:49 <adamw> ok
17:31:03 <adamw> so yeah, this comes down to whether we consider this to be breaking 'basic functionality' of gnome-calendar, really
17:31:47 <adamw> i think i'm shading -1 blocker, it's obvious there's some buggy code in the app, but given it's a relatively new app that probably doesn't have the same expectations as shell or evolution or firefox or something, i think this just falls the other side of the line for me
17:32:02 * kalev agrees.
17:32:11 <lroca> 0
17:32:18 <lruzicka> Ok ... as you wish.
17:32:45 <sgallagh> Yeah, I'm -1 here.
17:33:14 <sgallagh> It wouldn't pass the "last blocker" test for me
17:33:53 <kalev> -1 blocker
17:33:59 * lroca switches to using Evolution calendar for...
17:34:24 <kalev> I'll keep an eye on this and if a fix appears, I'll propose it as a FE
17:34:39 <Kohane> I'm +1 to FE
17:34:43 <adamw> kalev: i might have a quick poke at it after the meeting, i'm intrigued now
17:34:49 <kalev> cool :)
17:35:26 <adamw> proposed #agreed 1570879 - RejectedBlocker (Final) - this is close, but we agreed it doesn't quite meet the definition of "basic functionality" - people testing in meeting were able to make gnome-calendar crash by poking at it a bit, but no-one else could exactly reproduce lroca's crash, and just the basics of creating and editing events don't reliably crash the app
17:35:27 <lroca> Thanks all. Didn't mean to hold us up on this
17:35:36 <adamw> patch
17:35:46 <adamw> proposed #agreed 1570879 - RejectedBlocker (Final) - this is close, but we agreed it doesn't quite meet the definition of "basic functionality" - people testing in meeting were able to make gnome-calendar crash by poking at it a bit, but no-one else could exactly reproduce lroca's crash, and just the basics of creating and editing events don't reliably crash the app. We will consider an FE if crasher fix(es) appear
17:36:03 <kalev> ack
17:36:06 <lroca> ack
17:36:09 <lruzicka> ack
17:36:46 <adamw> #agreed 1570879 - RejectedBlocker (Final) - this is close, but we agreed it doesn't quite meet the definition of "basic functionality" - people testing in meeting were able to make gnome-calendar crash by poking at it a bit, but no-one else could exactly reproduce lroca's crash, and just the basics of creating and editing events don't reliably crash the app. We will consider an FE if crasher fix(es) appear
17:37:04 <adamw> with my 'meta' hat on, those two gnome bugs we just considered are an interesting pair...=)
17:37:07 <adamw> anyhoo!
17:37:12 <adamw> #info moving onto proposed freeze exception
17:37:27 <adamw> we've got like 10 of these, so let's try and be quick
17:37:27 <adamw> #topic (1570363) Update to 0.6.46
17:37:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1570363
17:37:28 <adamw> #info Proposed Freeze Exceptions, accountsservice, MODIFIED
17:38:22 <adamw> this...is unfortunately timed
17:38:26 <adamw> i'd've been a lot more +1 on it last week
17:38:48 <kalev> yes, same here
17:38:50 <sgallagh> Yeah, I'm -1
17:38:58 <sgallagh> There's too much churn for an FE
17:39:02 <adamw> for information, this is a really key bit of workstation
17:39:11 <adamw> accountsservice is deeply wired into the whole process of authentication in gnome
17:39:29 <sgallagh> I'd honestly have been -1 on it last week too
17:39:48 <adamw> so, i think =1
17:39:49 <adamw> -1
17:39:54 <kalev> the memory leak is something that can easily fixed with a 0 day. at the same time, would be nice to ship the fix on the base media, to ensure it goes through all the final validation, as it's really a key component
17:39:56 <adamw> i did just ping pbrobinson to give us a chance to come lobby us
17:40:08 <adamw> kalev: i'm honestly happier doing it as an update
17:40:15 <kalev> ok
17:40:21 <lroca> account services as in "Google, Pocket etc."?
17:40:28 <adamw> lroca: it's really everything
17:40:32 <sgallagh> lroca: No, that's GNOME Online Accounts
17:40:37 <adamw> just logging in as a local user still runs through accountsservice
17:40:40 <kalev> no, accountsservice is local accounts
17:40:42 <kalev> yeah
17:40:46 <sgallagh> This is the service that feeds GDM for logins, gnome-shell for screen-lock...
17:41:09 <lroca> got it
17:41:22 <adamw> anyone want to argue for +1?
17:41:22 <sgallagh> kalev: Well, login accounts rather than local accounts
17:41:28 <sgallagh> Since SSSD is in play too
17:41:28 <pwhalen> +1, any memory improvements for workstation are welcome on low end systems like arm
17:42:07 <sgallagh> pwhalen: Not arguing, just asking that your vote implies you're willing to risk possible breakage for those improvements?
17:42:24 <adamw> pwhalen: and you don't think it's sufficient to ship them as updates?
17:42:43 <kalev> I'm slightly worried about shipping it as 0 day because I know then it won't get as much testing as if we include it on the media. at the same time, including can easily cause us to slip, if something is wrong there
17:42:59 <kalev> accountsservice maintainer is halfline and can probably quickly address any issues if something crops up though
17:43:10 <pwhalen> it would be nice out of the box, get lots of testing done
17:43:19 <kalev> that was my pitch for +1 :) (not sure I'm +1 myself, just tried to list some reasons)
17:43:36 <adamw> i don't think it's actually a particularly good argument for workstation components
17:43:50 <adamw> they get a lot of testing as updates
17:44:01 <adamw> and it's more likely to be in-depth and/or hit less common configurations than validation testing is
17:44:15 <adamw> validation testing is commonly done as just 'install in a VM create a local account and call it good'
17:44:15 <sgallagh> adamw: Well, *apps* do, but I'm not sure if the services get tested specifically as much
17:44:26 <Kohane> Sorry, guys, I have to go. See ya.
17:44:27 <kalev> ok, fair enough
17:44:29 * Kohane waves
17:44:35 <adamw> sgallagh: well not tested specifically, but people are at least likely to notice if their stuff breaks and start yelling
17:45:00 <sgallagh> adamw: Sure, but for services I think that tends to end up happening after it goes stable
17:45:20 <sgallagh> But I'll stop arguing because I'm still on the -1 FE side of this
17:45:34 <sgallagh> The risks (to me) outweigh the benefits
17:45:40 <adamw> even there, a bad update is notably less disastrous than the bad thing being baked into the released workstation media forever
17:45:49 <adamw> that's the case that worries me the most, in fact, not a slip
17:45:50 <sgallagh> adamw++
17:46:04 <adamw> bad updates we have options; we can, in the worst case, just pull one, we've done that before
17:46:15 <lruzicka> I agree ...
17:46:16 * sgallagh nods
17:47:03 <lroca> -1 FE, I'm convinced
17:47:04 <adamw> proposed #agreed 1570363 - RejectedFreezeException (Final) - while the improvements to resource use are attractive, the risks of a major update to something as significant as accountsservice this late in the release process substantially outweigh the benefits
17:47:15 <sgallagh> ack
17:47:18 <lroca> ack
17:47:22 <Southern_Gentlem> ack
17:47:24 <frantisekz> ack
17:47:25 <kalev> ack
17:47:26 <pwhalen> ack
17:47:40 <adamw> #agreed 1570363 - RejectedFreezeException (Final) - while the improvements to resource use are attractive, the risks of a major update to something as significant as accountsservice this late in the release process substantially outweigh the benefits
17:47:51 <adamw> #topic (1507940) Root password listed as 'set' on AArch64 disk images
17:47:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1507940
17:47:51 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:47:59 <pwhalen> +1
17:48:19 <kalev> +1 FE
17:48:31 <Southern_Gentlem> +1 FE
17:48:35 <jsmith> +1 FE
17:48:52 <sgallagh> +1 FE
17:49:13 <frantisekz> +1 FE
17:49:40 <adamw> proposed #agreed 1507940 - AcceptedFreezeException (Final) - this can result in the user being locked out of the install, and cannot be fully fixed with a post-release update
17:49:54 <Southern_Gentlem> ack
17:49:54 <kalev> ack
17:49:56 <pwhalen> ack
17:50:01 <sgallagh> ack
17:50:01 <adamw> #agreed 1507940 - AcceptedFreezeException (Final) - this can result in the user being locked out of the install, and cannot be fully fixed with a post-release update
17:50:12 <adamw> #topic (1569045) kickstart file trigger critical exception in anaconda
17:50:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1569045
17:50:13 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:50:38 <kalev> +1 FE
17:50:50 <lruzicka> +1
17:50:51 <jsmith> +1 FE
17:50:53 <frantisekz> +1 FE
17:51:23 <pwhalen> +1 FE
17:51:25 <sgallagh> I think I'm +1 FE here as well, mostly because it's sufficiently exercised by automated testing
17:51:26 <Southern_Gentlem> +1 FE
17:51:41 <adamw> proposed #agreed 1569045 - AcceptedFreezeException (Final) - this can cause kickstart / console installs to crash on certain systems, and cannot be fixed with a post-release update
17:51:46 <Southern_Gentlem> ack
17:51:47 <lruzicka> ack
17:51:50 <kparal> ack
17:51:54 <kalev> ack
17:52:07 <pwhalen> ack
17:52:18 <frantisekz> ack
17:52:31 <sgallagh> ack
17:52:34 <jsmith> ACK
17:52:37 <adamw> #agreed 1569045 - AcceptedFreezeException (Final) - this can cause kickstart / console installs to crash on certain systems, and cannot be fixed with a post-release update
17:52:44 <adamw> #topic (1567622) bluetoothd (bluez 5.49) crashes on start: core-dump
17:52:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1567622
17:52:45 <adamw> #info Proposed Freeze Exceptions, bluez, ON_QA
17:52:52 <kalev> I looked at the patch fixing this the other day and it's just adding a != NULL guard, should be safe to take
17:53:00 <kalev> and nice to get a hardware support fix on the media
17:53:04 <jsmith> +1 FE
17:53:05 <kalev> +1 FE
17:53:08 <lruzicka> +1FE
17:53:19 <lroca> +1FE
17:53:20 <kparal> +1 fe
17:53:21 <pwhalen> +1 FE
17:53:35 <frantisekz> +1 FE
17:53:49 <sgallagh> This feels like a blocker to me, actually
17:53:53 <Southern_Gentlem> +1
17:54:01 <adamw> sgallagh: i was wondering the same
17:54:08 <adamw> though, not quite sure
17:54:09 <adamw> what criterion?
17:54:22 <adamw> it seems it only crashes if you actually try and pair some hardware
17:54:32 <adamw> ("so long as you don't use it, it doesn't crash!")
17:54:38 <sgallagh> Basic functionality of the desktop env?
17:55:05 <sgallagh> It’s presented as a prominent feature of gnome-shell
17:55:10 <kparal> panel functionality?
17:55:15 <kparal> it's in the menus
17:55:19 <sgallagh> It’s right in the UI panel, not even buried in settings.
17:56:01 <adamw> yeah, fair argument
17:56:03 <adamw> i can go +1 blocker on that
17:56:05 <adamw> other votes?
17:56:13 <sgallagh> +1 blocker
17:56:14 <kparal> +1
17:56:32 <halfline> (glad you guys didn't push accountsservice, there was a regression found in the release a couple of days ago, going to do a new release soon)
17:56:58 <kalev> yay :)
17:57:46 <adamw> score one for conservatism!
17:57:50 <lruzicka> be it ... +1 blocker
17:59:12 <adamw> proposed #agreed 1567622 - AcceptedBlocker (Final) - we are accepting this as a blocker (not just FE) for Final as a violation of criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use", this is a major function which can be reached (and users with bluetooth devices will commonly interact with) via the panel
17:59:33 <kalev> ack
17:59:51 <frantisekz> ack
17:59:52 <lruzicka> ack
17:59:54 <lroca> ack
17:59:57 <pwhalen> ack
18:00:02 <adamw> #agreed 1567622 - AcceptedBlocker (Final) - we are accepting this as a blocker (not just FE) for Final as a violation of criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use", this is a major function which can be reached (and users with bluetooth devices will commonly interact with) via the panel
18:00:38 <adamw> #topic (1568670) gnome-shell should obsolete caribou in F28+
18:00:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1568670
18:00:38 <adamw> #info Proposed Freeze Exceptions, gnome-shell, NEW
18:01:04 <adamw> this is a sensible change, but i don't think it really needs an FE, particularly.
18:01:10 <adamw> we can just do it as an update with the same effect.
18:01:19 * kalev agrees.
18:01:20 <Southern_Gentlem> -1
18:01:34 <sgallagh> -1 FE
18:01:36 <kalev> -1 FE
18:01:37 <lruzicka> -1 FE
18:01:39 <lroca> -1
18:02:19 <kalev> I also don't think gnome-shell should obsolete caribou. I can imagine cases where someone has uninstalled gnome-shell, but forgotten caribou, and then this obsolete would put gnome-shell back
18:02:36 <kalev> fedora-bosolete-package feels like a better place
18:02:47 <kalev> fedora-obsolete-packages
18:03:15 <adamw> kalev: i'm not sure if Obsoletes works that way, but interesting point
18:03:29 <adamw> we should check, can you mention it in the bug?
18:03:36 <sgallagh> adamw: I think he's right, actually.
18:03:38 <kalev> sure
18:03:40 <adamw> i think gnome-shell would also have to *provides* caribou
18:03:42 <adamw> but imbw
18:03:42 <sgallagh> Or... wait.
18:03:44 <sgallagh> Yeah
18:04:19 <adamw> of course, it means then that your theoretical person wouldn't get caribou removed either. but hey
18:04:45 <adamw> proposed #agreed 1568670 - RejectedFreezeException (Final) - there's no reason we can think of that this actually needs an FE, it can be done fine as an update
18:04:59 <kparal> ack
18:05:06 <kalev> ack
18:05:09 <lroca> ack
18:05:11 <lruzicka> ack
18:05:13 <sgallagh> ack
18:05:56 <pschindl_wfh> ack
18:06:23 <adamw> #agreed 1568670 - RejectedFreezeException (Final) - there's no reason we can think of that this actually needs an FE, it can be done fine as an update
18:06:30 <adamw> #topic (1566988) repomd.xml GPG signature verification error: gpgme_op_verify()
18:06:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1566988
18:06:30 <adamw> #info Proposed Freeze Exceptions, gpgme, NEW
18:07:47 <kalev> looks like the PR linked has been rejected by our gnupg2 maintainer. https://src.fedoraproject.org/rpms/gnupg2/pull-request/1
18:08:09 <kalev> ahh, sorry, I failed to read further comments
18:08:13 <kalev> scratch that :)
18:08:59 <lroca> Is there a link to the gnupg2 bug file?
18:09:33 <sgallagh> I think I'm a weak +1 here. If this bug is breaking repos (including the OpenH264 repo), then it's hard to fix with an update
18:09:43 * kalev nods.
18:10:23 <kalev> I think I'm leaning towards +1 as well here, for the same reason as sgallagh
18:10:48 <adamw> yeah, it's at least plausible to hit it between install and update and be sad.
18:10:50 <adamw> so i guess +1.
18:10:57 <lruzicka> +1
18:11:26 <lroca> +1
18:11:49 <pwhalen> +1
18:12:28 <kalev> do we need someone from this meeting to submit the update to bodhi?
18:13:03 <adamw> well, if we want to get the fix in, someone should submit an update, yeah.
18:13:06 <adamw> nothing goes in without an update.
18:13:09 <kalev> I'll go do it now then
18:13:43 <adamw> proposed #agreed 1566988 - AcceptedFreezeException (Final) - this can affect trying to enable repos from live environments or between install and first update, and could affect installing updates in that case, so fixing it in the release seems worthwhile
18:13:51 <lroca> ack
18:13:54 <Southern_Gentlem> ack
18:13:55 <kalev> ack
18:14:22 <lruzicka> ack
18:14:27 <kalev> https://bodhi.fedoraproject.org/updates/gpgme-1.10.0-4.fc28
18:14:38 <kparal> ack
18:14:46 <adamw> #agreed 1566988 - AcceptedFreezeException (Final) - this can affect trying to enable repos from live environments or between install and first update, and could affect installing updates in that case, so fixing it in the release seems worthwhile
18:15:18 <adamw> (next one in list was accepted as a blocker already, skipping)
18:15:18 <adamw> #topic (1531140) no console output with acpi on mustang (Warning: unable to open an initial console.)
18:15:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1531140
18:15:20 <adamw> #info Proposed Freeze Exceptions, kernel, POST
18:16:11 <adamw> +1 for me, this is awkward on affected hardware, can't be fully fixed with update (would affect install)
18:16:23 <lruzicka> +1
18:16:23 <pwhalen> +1, acpi is default on m400
18:16:30 <kalev> +1
18:16:39 <sgallagh> Do we have an isolated fix or would we be pulling in a kernel rebase for it?
18:17:41 <pwhalen> sgallagh, not isolated afaik
18:18:08 <sgallagh> 🎌
18:18:31 <sgallagh> (I don't know if that shows up as red flags on all implementations, but..)
18:19:03 <sgallagh> I get really tense when I hear "kernel rebase as a freeze exception"
18:19:17 <adamw> well, we could do a build from kernel git at the point this fix was added i think
18:19:20 <adamw> there is no rebase involved
18:19:39 <sgallagh> I'd be +1 in that case (I just looked at the patch, it's super-constrained)
18:20:03 <adamw> it'd pull in one other patch
18:20:14 <adamw> well, commit
18:20:15 <adamw> "actually add the full PocketBeagle DT"
18:20:19 <adamw> commit 5c3e312120cfa5c750421047eebd1fa592113a2c
18:20:51 <adamw> i'll talk to jforbes and pbrobinson about the details after the meeting...
18:21:38 <adamw> proposed #agreed 1531140 - AcceptedFreezeException (Final) - this is a significant issue on affected hardware which can't be fully fixed with an update. however, we note there are several other unrelated changes in current f28 kernel git branch, and would strongly prefer an update to fix this pull in as few other non-blocker/non-FE changes as possible
18:21:42 * jforbes notes kernel rebases in this sense are stable updates, not major rebases
18:22:02 <adamw> jforbes: still, the policy is supposed to be that during freezes we *only* pull in changes that fix FE/blocker issues
18:22:11 <adamw> not "the change that fixes those plus whatever other changes come along for the ride"
18:22:23 <kparal> ack
18:22:24 <adamw> i've been a bit slack about pushing people on this for the last *cough* years, but it's still what's supposed to happen
18:22:24 <kalev> ack
18:22:35 <sgallagh> ack
18:22:38 <lruzicka> ack
18:22:40 <pwhalen> ack
18:22:50 <adamw> #agreed 1531140 - AcceptedFreezeException (Final) - this is a significant issue on affected hardware which can't be fully fixed with an update. however, we note there are several other unrelated changes in current f28 kernel git branch, and would strongly prefer an update to fix this pull in as few other non-blocker/non-FE changes as possible
18:23:04 <jforbes> adamw: I hear you, at the same time, this is the way kernel has always maintained the branch
18:23:15 <adamw> #topic (1569242) Weak dependencies (Recommends, Supplements) not included in install trees, hence DVD media, ostrees
18:23:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1569242
18:23:15 <adamw> #info Proposed Freeze Exceptions, pungi, ASSIGNED
18:23:32 <adamw> jforbes: what i'm saying is, if we can at least just do a build at fa3b85b25c112a965b70546d3a0bb274290ca8ac , that would be a lot better than building current f28 head, from that perspective
18:23:41 <adamw> (since there are two other commits since that one, one which looks big)
18:24:26 <adamw> so, this one...the basic issue is relatively simple, the consequences of the change are not *entirely* predicted yet
18:25:31 <jforbes> Neither are actually that big, and they are all fixes for tiny arm platforms
18:25:52 <kalev> I'd very much like to see this fixed because this is causing various packages to keep falling out of Atomic WOrkstation, compared to regular Workstation live media
18:26:02 <sgallagh> adamw: This is *intentional* behavior. We want the trees to be more minimalist and explicit.
18:26:03 <kalev> but at the same time, slightly worried about a late change in pungi that could have unforseen consequences
18:26:36 <adamw> sgallagh: did whoever "intended" it think through the consequences?
18:27:07 <adamw> sgallagh: note, we are talking about the *trees* here. not the contents of the installer environment or anything like that.
18:27:15 <sgallagh> adamw: The intention is that we need to be able to use pungi to produce minimal things like container base images and cloud images
18:27:21 <adamw> sgallagh: fundamentally i don't see a defence for the inconsistency i described.
18:27:38 <adamw> sgallagh: i don't see what that has to do with populating the install trees.
18:27:57 <sgallagh> Hmm, maybe I'm confusing pungi and lorax again
18:28:11 <adamw> the image compose tools/processes obviously don't have to pull in *every* package that's in the tree they're using as a source. nor do any of them actually *do* that unintentionally, AFAIK.
18:28:27 <adamw> sgallagh: i honestly don't know which of them is responsible for this
18:28:46 <kparal> +1 fe
18:29:06 <lruzicka> +1 fe
18:29:09 <adamw> sgallagh: but the actual...thing the bug is about, ultimately, is basically: "does trousers wind up in https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180423.n.0/compose/Server/x86_64/os/Packages/t/ or not?"
18:29:43 <adamw> it's not about whether trousers should be in a minimal cloud image or disk image or anything like that.
18:29:51 <sgallagh> adamw: OK, I think there's a good argument to be made for making the trees more complete.
18:30:06 <adamw> i can add a comment to the bug to clarify this.
18:30:11 <sgallagh> I'm *really* not comfortable changing our compose process three days and change before Go/No-Go
18:30:22 <kalev> if we accept this, can we action item someone to check that it doesn't make cloud images explode with new pulled in packages?
18:30:24 <sgallagh> It's been like this for several releases
18:30:32 <adamw> sgallagh: but we haven't used Recommends much.
18:30:48 <adamw> the more people start using it, the more problems this might expose.
18:30:53 <adamw> it already entirely broke Atomic Workstation last week.
18:31:19 <adamw> still, i can see the argument that we can just try and keep on top of it for f28 given that we're in freeze
18:31:21 <sgallagh> adamw: It's not going to break anyone more than they already are for the frozen set
18:31:22 <adamw> and change it for f29 or whatever
18:31:31 <sgallagh> Yeah, that's what I'm suggesting
18:31:32 <adamw> still, there's clearly at least *one* inconsistency already baked into f28 because of this
18:31:36 <adamw> and i've no idea if there are others
18:31:49 <adamw> i didn't look through 300 potential cases and find just 1, this was the very first case i looked at
18:31:51 <sgallagh> adamw: For the one we know about, I can add it to our comps definition
18:31:55 <adamw> (aside from the FAW one)
18:32:08 <sgallagh> If you are particularly concerned about the disconnect
18:32:17 <adamw> i don't know how concerned to be, honestly
18:32:28 <kalev> the linux-firmware PR / FE request that was resolved in the ticket was about this issue, by the way
18:32:30 <adamw> what would be useful, i guess, is a list of all the Recommends / Supplements actually in f28 packages as of now.
18:32:46 <adamw> kalev: ah, this was also why linux-firmware wasn't in FAW?
18:32:52 <kalev> I believe so
18:33:01 <sgallagh> I don't think we'd necessarily want Supplements included.
18:33:12 <adamw> sgallagh: Supplements is the same strength as Recommends.
18:33:22 <sgallagh> Oh, wait. Sorry.
18:33:29 <sgallagh> I parsed that as Suggests:
18:33:29 <adamw> it's just in the opposite direction.
18:33:30 <sgallagh> Never mind
18:34:07 <adamw> so...proposal, punt this briefly and see if we can get a bit more data? find *all* the potentially affected cases and think through the consequences?
18:34:17 <sgallagh> adamw: +1
18:34:21 <lroca> +1 punt
18:34:48 <kalev> +1 punt
18:35:13 <lroca> ..and, unfortunately, I have to go
18:35:29 <adamw> proposed #agreed 1569242 - punt (delay decision) - we would like to gather more data on this, particularly get a list of all Recommends: and Supplements: in F28 stable at present, and think through the potential consequences of changing or not changing this before making a decision
18:35:33 <adamw> lroca: thanks, we're nearly done anyhow
18:35:52 <lroca> thanks all... speak again soon
18:36:06 <lruzicka> ack
18:36:10 <kalev> ack
18:36:23 <sgallagh> ack
18:36:24 <pwhalen> ack
18:37:34 <adamw> #agreed 1569242 - punt (delay decision) - we would like to gather more data on this, particularly get a list of all Recommends: and Supplements: in F28 stable at present, and think through the potential consequences of changing or not changing this before making a decision
18:37:44 <adamw> #topic (1360289) CVE-2016-7103 python-XStatic-jquery-ui: jquery-ui: cross-site scripting in dialog closeText [fedora-all]
18:37:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1360289
18:37:44 <adamw> #info Proposed Freeze Exceptions, python-XStatic-jquery-ui, ASSIGNED
18:38:42 <kalev> I don't know if it's on media, but I guess if it's on media then we should accept this since it's a security issue, and if it's not on a media then it should be safe to pull in anyway ...
18:38:46 <kalev> +1 FE :)
18:39:13 <sgallagh> Impact is LOW according to the CVE BZ
18:39:25 <adamw> mehhhhhh ?
18:39:27 <sgallagh> Also there's no update currently available for it
18:39:43 * adamw tosses a coin
18:39:51 <adamw> coin lands on edge
18:40:07 <kalev> ahh, no update available? pffff
18:40:47 <adamw> let's just punt it
18:41:13 <pwhalen> +1 punt
18:41:22 <sgallagh> I'm happy enough with -1 FE
18:41:37 <kalev> +1 punt
18:41:58 <sgallagh> But sure, punt. Whatever.
18:42:00 <lruzicka> +1 punt
18:42:20 <adamw> proposed #agreed 1360289 - punt (delay decision) - there's no update here, so we can't really judge how significant the change would be and thus whether it's worth pulling in for a LOW severity CVE
18:42:31 <adamw> (aka 'make up some crap')
18:42:41 <kalev> ack
18:42:44 <lruzicka> ack
18:42:57 <pwhalen> ack
18:43:11 <sgallagh> avk
18:43:33 <adamw> #agreed 1360289 - punt (delay decision) - there's no update here, so we can't really judge how significant the change would be and thus whether it's worth pulling in for a LOW severity CVE
18:43:40 <adamw> alright, that's all the proposals
18:43:53 <adamw> unless anyone had any other off-the-books ones (or ones they've proposed in the last hour or so)
18:44:03 <lruzicka> I do not
18:44:07 <lruzicka> :)
18:44:28 * kalev is looking forward to having dinner.
18:44:47 <adamw> ok
18:44:56 <adamw> let's take a quick look at the status of accepted blockers then wrap up
18:45:02 <adamw> #info quick accepted blocker check-in
18:45:23 <adamw> skipping uninteresting ones
18:45:23 <adamw> #topic (1560481) Some core applications in Gnome 3.28 are unresponsive and not working on AMD graphics cards
18:45:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1560481
18:45:23 <adamw> #info Accepted Blocker, gnome-shell, NEW
18:45:35 <adamw> this one i'm a bit worried about as it's accepted but not clearly going anywhere
18:45:44 <adamw> kalev: is anyone driving this from your side?
18:45:54 <kalev> I don't think so
18:46:12 <kalev> mclasen: do you know who's supposed to take care of clutter these days?
18:46:23 <sgallagh> The maid?
18:46:29 <sgallagh> (sorry)
18:46:32 <adamw> .fire sgallagh
18:46:33 <zodbot> adamw fires sgallagh
18:46:42 * adamw reports sgallagh to HR
18:46:52 <mclasen> kalev: the only clutter we care about is the one inside mutter
18:47:26 <kalev> mclasen: the stand alone one that totem and cheese and maps uses has a bug that prevents people from clicking on buttons
18:47:52 <kalev> and it's accepted as a fedora blocker
18:48:01 <mclasen> anything else using clutter is living on borrowed time
18:48:51 <adamw> when those 'things' include core workstation apps, we seem to have a problem
18:49:39 * mclasen has no better answers
18:50:10 <kalev> I think we could maybe ask jadahl to port the mutter fix to the stand alone cogl+clutter?
18:51:04 <adamw> well, jonas has clearly been doing some follow-up in bug, which is great
18:51:25 <adamw> i just want to make sure someone's clear that as things stand this needs bodging up somehow by, like...tomorrow
18:52:03 <adamw> we can revisit whether it's a blocker, but honestly i'm still pretty +1 on it
18:52:13 <adamw> 'users of lots of common graphics hardware can't click on buttons in core apps' is badf
18:52:55 <jsmith> I would tend to be +1 on it as well...
18:53:10 <adamw> kalev: "Sadly we can't just port over the fix in mutter since mutter itself has its own cogl backend where the issue is fixed."
18:53:17 <adamw> kale (from #c31)
18:53:33 <kalev> ah
18:53:49 <kparal> we can perhaps disable 10bit colors support then?
18:53:58 <adamw> since it seems there's some magic setting that can be used to disable rgb10 configs entirely, perhaps we could ask jonas if we can just *do* that at the level of clutter itself at least as a temporary fix?
18:54:06 <adamw> can we just build it entirely without that support?
18:54:20 <adamw> until at least we come up with a better fix, which can then be shipped as an update...
18:54:32 <kalev> sounds like a good plan to me
18:55:03 <adamw> OK, i'll mention it in the bug, but can you guys talk to jonas about it? obviously you all know each other better :)
18:55:24 <kalev> sure, I'll talk to him tomorrow
18:55:27 <adamw> thanks a lot
18:56:13 <lruzicka> Yes, I agree with getting rid of the rgb10 support temporarily
18:56:26 <adamw> #info there is some progress being made on this, but kalev will talk to jonas and explain the need to do some kind of fix/bodge for this urgently given the release schedule
18:56:37 <adamw> #topic (1569411) When installing Fedora to dual boot with Windows, Anaconda does not add GRUB entry for Windows.
18:56:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1569411
18:56:37 <adamw> #info Accepted Blocker, grub2, NEW
18:56:57 <adamw> so i talked to pjones about this and he said he'd do a build/update of grub2 with the dep restored, but...he hasn't
18:57:19 <adamw> the tricky thing here is, only a few people can tag builds of grub2, it's part of the set of packages that's protected due to being the boot chain
18:57:54 <adamw> so our choices here are: 1) get pjones to actually do it, 2) get someone else with the necessary superpowers to do it (nirik? puiterwijk? who else can do it?), 3) add the dep to anaconda instead as a hack
18:58:08 <adamw> #info our choices here are: 1) get pjones to actually do it, 2) get someone else with the necessary superpowers to do it (nirik? puiterwijk? who else can do it?), 3) add the dep to anaconda instead as a hack
18:58:11 * jsmith would prefer 1, then 2 if 1 can't be done.
18:58:21 <jsmith> 3 sounds very hackish :-)
18:58:33 <adamw> agreed
18:58:39 <kalev> the kernel people should be able to build grub as well
18:58:41 <adamw> those were in order of preference for me too :P
18:58:45 <adamw> oo, point
18:58:49 <adamw> jforbes: could/would you do this?
18:58:58 <adamw> i can send you the log of my chat with pjones if it helps :)
19:00:11 <adamw> welp, we're at the 3 hour cutoff
19:00:38 <adamw> #action adamw to follow up with pjones again and also try to find someone else who can do a grub2 build with the dep re-added if pjones can't
19:00:47 <adamw> and with that, i guess we're done
19:00:47 <lruzicka> ok
19:00:50 <adamw> #topic Open floor
19:01:02 <adamw> anything super mega-urgent enough to be worth extending beyond 3 hours?
19:01:08 <kalev> dinneeeeer! :)
19:01:08 <jsmith> adamw: Once again, thanks for running the gauntlet... three hours is a long meeting to run :-)
19:01:15 <jsmith> adamw++
19:01:15 <zodbot> jsmith: Karma for adamwill changed to 19 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:01:17 <adamw> thanks for sticking it out folks
19:01:21 <adamw> sorry to hold up your dinner, kalev :)
19:01:24 <kparal> adamw++
19:01:24 <zodbot> kparal: Karma for adamwill changed to 20 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:01:28 * nirik is happy to help if you cannot find pjones.
19:01:33 <adamw> .fire kparal what, you hadn't ++ed me before?
19:01:33 <zodbot> adamw fires kparal what, you hadn't ++ed me before?
19:01:37 <kalev> no worries, thanks for running the meeting adamw!
19:01:38 <lruzicka> thank you adamw and other, too
19:01:47 <sgallagh> nirik++
19:02:18 <adamw> thanks again, folks
19:02:18 <kparal> sgallagh: nirik already overflowed the int range with his karma
19:02:21 <adamw> #endmeeting