16:00:45 <roshi> #startmeeting F26-blocker-review
16:00:45 <zodbot> Meeting started Thu Jun 29 16:00:45 2017 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:45 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:00:45 <roshi> #meetingname F26-blocker-review
16:00:45 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:00:45 <roshi> #topic Roll Call
16:01:07 <roshi> who's around for some blocker review funtime!?
16:01:19 * kparal is here
16:01:48 <roshi> #chair adamw kparal pschindl_wfh sgallagh
16:01:48 <zodbot> Current chairs: adamw kparal pschindl_wfh roshi sgallagh
16:02:02 <sgallagh> .hello sgallagh
16:02:02 <adamw> .hello adamwill
16:02:02 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:02:05 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
16:03:30 <roshi> #topic Introduction
16:03:30 <roshi> Why are we here?
16:03:30 <roshi> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:03:34 <roshi> #info We'll be following the process outlined at:
16:03:37 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:38 <kparal> pschindl_wfh: ping
16:03:38 <zodbot> kparal: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
16:03:39 <roshi> #info The bugs up for review today are available at:
16:03:42 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:44 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:47 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
16:03:50 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
16:03:53 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria
16:03:56 <roshi> #info 6 proposed Blockers, 18 proposed FEs
16:03:56 * pschindl_wfh is here
16:04:09 <roshi> welcome all :)
16:04:27 <roshi> let's get started
16:04:28 <roshi> #topic (1443662) installation problems with repos accessed via NFS
16:04:31 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1443662
16:04:33 <roshi> #info Proposed Blocker, anaconda, NEW
16:05:07 <roshi> mattdm voted -1 in bug
16:05:23 <adamw> given the result of my attempts to reproduce i'm probably -1
16:05:31 <roshi> guess I'm -1 since it's not reproducible
16:06:06 <adamw> btw, for the record, comment #8 really should've come *before* comments 6 and 7.
16:06:28 <sgallagh> I'm -1 as well
16:06:37 <roshi> proposed #agreed - RHBZ#1443662 - RejectedBlocker - While this is a serious bug, it doesn't seem to be reproducible. Because of this, it's not considered a blocker as we're unable to verify it.
16:06:50 <kparal> ack
16:06:59 <sgallagh> ack
16:07:02 <roshi> #agreed - RHBZ#1443662 - RejectedBlocker - While this is a serious bug, it doesn't seem to be reproducible. Because of this, it's not considered a blocker as we're unable to verify it.
16:07:11 <roshi> who wants to secretarialize?
16:09:20 <roshi> #topic (1465472) Error at open session: 0x3 when installling IPA server in F26
16:09:23 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1465472
16:09:25 <roshi> #info Proposed Blocker, freeipa, MODIFIED
16:11:03 <sgallagh> So this sounds like it's not a blocker, since the offending package isn't likely to get an FE
16:11:04 <kparal> seems -1
16:11:06 <sgallagh> -1
16:11:13 <roshi> -1
16:11:27 <adamw> yeah, -1
16:11:32 <adamw> i'm working on the update editing atm
16:12:07 <adamw> roshi: i'll secretarialize
16:12:40 <roshi> proposed #agreed - RHBZ#1465472 - The update that is causing this issue won't make it into the F26 composes, so doesn't block release.
16:12:43 <roshi> thanks adamw
16:12:59 <sgallagh> ack
16:13:12 <pschindl_wfh> ack
16:13:31 <roshi> #agreed - RHBZ#1465472 - The update that is causing this issue won't make it into the F26 composes, so doesn't block release.
16:13:39 <roshi> #topic (1462444) [abrt] gnome-shell: std::_Rb_tree<_ConnectData*, _ConnectData*, std::_Identity<_ConnectData*>, std::less<_ConnectData*>, std::allocator<_ConnectData*> >::equal_range(): gnome-shell killed by signal 11
16:13:43 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1462444
16:13:45 <roshi> #info Proposed Blocker, gjs, NEW
16:14:27 <adamw> well, if we have to make a decision on this, i'm -1 for now
16:14:32 * kparal agrees
16:15:58 <adamw> there just doesn't seem to be a flood of people hitting this
16:16:00 <roshi> yeah
16:16:04 <adamw> it's obviously a bad bug if you *do* hit it, but
16:16:08 <sgallagh> I'm running Workstation on several devices, some with Wayland and others with X and I haven't hit it.
16:16:13 <roshi> -1 at this point
16:16:19 <sgallagh> Perhaps it's hardware-specific?
16:16:30 <sgallagh> But yeah, -1
16:16:59 <roshi> proposed #agreed - RHBZ#1462444 - This bug doesn't seem to be wide spread enough to qualify as a blocker. Until it can be reliably reproduced, it is not considered a blocker.
16:16:59 <adamw> it seems to be *something* specific
16:17:01 <adamw> ack
16:17:17 <kparal> ack
16:17:26 <roshi> #agreed - RHBZ#1462444 - This bug doesn't seem to be wide spread enough to qualify as a blocker. Until it can be reliably reproduced, it is not considered a blocker.
16:17:29 <roshi> #topic (1418360) grub2 incorrectly initialises the boot_params from the kernel image
16:17:32 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1418360
16:17:34 <roshi> #info Proposed Blocker, grub2, ON_QA
16:18:55 <adamw> so pjones followed up on this one (and its friend) by email
16:19:25 <sgallagh> This doesn't sound like a blocker to me, though I could see a good argument for an FE
16:19:26 <roshi> does not knowing about secure boot violate a criteria?
16:19:27 <adamw> it sounds like it's more serious than i first thought: basically the OS doesn't know SB is enabled so it doesn't kick in the necessary additional protections that are usually enabled in SB mode to prevent an attacker doing things to subvert SB
16:19:36 <roshi> I mean, if the install works as expected...
16:19:39 <sgallagh> If only because someone might want to verify secure boot status during installation
16:19:48 <adamw> let me see if i can grab a pjones
16:20:26 <adamw> one thing that would worry me here is, we're kind of being a bad SB actor here, it sounds like
16:21:05 <adamw> i don't wanna guess too far, pjones would know for sure, but it's the kind of thing that might come up in terms of our SB signing status
16:21:34 <roshi> huh
16:21:39 <adamw> but yes, i'm not aware of any criteria it violates, exactly. i'm definitely +1 FE, and if I understand it right, i suggest it'd maybe be a good candidate for a fesco blocker, although since we have fixes, we may not need to go that far
16:22:02 <adamw> roshi: well, i mean, theoretically speaking, if you're the Gatekeeper Of SB Trust, you wouldn't want to be giving out signing keys to OSes that make subverting SB easy.
16:22:14 <roshi> true
16:22:23 <sgallagh> adamw: Well, it still might be worth raising as a FESCo blocker in case the fix is insufficient
16:22:45 <adamw> here's what pjones wrote in full:
16:23:16 <adamw> "They absolutely are: basically Secure Boot doesn't trigger kmod signature checking, read-only /dev/mem, etc., in the current trees. This update fixes a grub bug that's triggering that behavior in the newer kernels, but was not triggering it in the older ones. So yes, I very much think these should be blockers."
16:23:38 <adamw> (those are all protection measures to guard against someone subverting SB, AIUI)
16:24:52 <roshi> +1 to raise it to fesco
16:25:01 <kparal> so this is a security which we have in criteria
16:25:02 <roshi> as we can only compare to the criteria
16:25:09 <kparal> *security issue
16:25:11 <sgallagh> Actually, this might violate criteria
16:25:32 <sgallagh> It could conceivably be a violation of the "Don't ship with serious known security vulnerabilities" criterion
16:25:37 <adamw> hm, plausibly, yeah
16:25:38 <sgallagh> I forget the exact phrasing
16:25:56 <adamw> though we usually only use that for things which are *formally* security issues (i.e. they have a CVE and a proper severity assessment)...
16:25:59 <adamw> anyhow
16:26:02 <sgallagh> ah, I missed kparal's comment
16:26:02 <roshi> yeah
16:26:06 <adamw> shall we just make it +1 FE for now and leave blocker status open?
16:26:15 <roshi> works for me
16:26:18 <sgallagh> Sure
16:26:20 <roshi> and elevate to fesco
16:26:42 * kparal shrugs, would vote +1 already
16:26:54 <kparal> but either way works
16:27:11 <sgallagh> kparal: I'm *inclined* to do the same, but then we're bypassing the criteria, which really is FESCo's job
16:27:24 <sgallagh> ... don't quote me on that
16:27:26 <adamw> heh
16:27:33 <adamw> there's a case to be made for the 'security' criterion, sure.
16:27:46 <roshi> proposed #agreed - RHBZ#1418360 - AcceptedFreezeException - It's unclear if this actually violates any of our Release Criteria, so we're accepting it as a FE and leaving the blocking decision to FESCo.
16:28:20 <roshi> aiui, it's not a security issue on the installed machine, it's a impact to our ability to get SB signed stuff in the future, right?
16:29:24 <adamw> well, it's both
16:29:32 <sgallagh> roshi: I was interpreting it as "our implementation might be vulnerable to attack, which in turn would impact our ability to get signatures in the future"
16:29:38 <adamw> if an attacker can subvert SB on the system, then of course all the security protections of SB are gone
16:29:46 <adamw> right
16:29:56 <adamw> i'd say 'could', like i said, i don't want to run too far ahead :)
16:30:04 <roshi> yeah
16:30:05 <adamw> pjones would be the authority, i'm just playing him on tv since he doesn't seem to be around
16:30:07 <roshi> acks?
16:30:08 <kparal> ack
16:30:10 <adamw> ack
16:30:20 <roshi> #agreed - RHBZ#1418360 - AcceptedFreezeException - It's unclear if this actually violates any of our Release Criteria, so we're accepting it as a FE and leaving the blocking decision to FESCo.
16:30:41 <roshi> #topic (1451071) Secure boot flag could not be determined
16:30:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1451071
16:30:42 <roshi> #info Proposed Blocker, kernel, ON_QA
16:31:37 <kparal> the same resolution here?
16:31:44 <sgallagh> This is fixed by the same build of dracut, yes?
16:31:49 <sgallagh> or, wait. this is grub
16:31:50 <roshi> I think so
16:31:57 <roshi> same resolution, I mean
16:32:28 <sgallagh> Rephrasing: if we accepted the other one and don't accept this, someone would be forced to split the changes out?
16:32:41 <adamw> theoretically, yeah
16:32:46 <adamw> i'm kinda assuming the two go together
16:32:49 <adamw> so, i'd say same resolution
16:33:04 <roshi> wfm
16:33:26 <roshi> proposed #agreed - RHBZ#1451071 - AcceptedFreezeException - It's unclear if this actually violates any of our Release Criteria, so we're accepting it as a FE and leaving the blocking decision to FESCo.
16:33:38 <sgallagh> ack
16:34:08 <kparal> ack
16:34:38 <roshi> #agreed - RHBZ#1451071 - AcceptedFreezeException - It's unclear if this actually violates any of our Release Criteria, so we're accepting it as a FE and leaving the blocking decision to FESCo.
16:34:43 <roshi> #topic (1459779) [abrt] glib-networking: JS_AbortIfWrongThread(): glib-pacrunner killed by signal 11
16:34:47 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1459779
16:34:49 <roshi> #info Proposed Blocker, libproxy, NEW
16:35:13 <adamw> it reads like this only occurs if you have a proxy configured
16:36:09 <adamw> sgallagh: can/did you check for *sure* whether you had a proxy set up or not, when you hit this?
16:36:16 <kparal> 260 unique crash count
16:36:20 <kparal> 2300 total
16:36:46 <sgallagh> adamw: I did
16:37:02 <adamw> and you did? :)
16:37:15 <sgallagh> Specifically, I had an autoconfiguration URL set
16:37:18 <adamw> alright
16:37:25 <kparal> -1
16:37:37 <adamw> so, yeah, at least on the polish criterion i'm -1, as it's supposed to cover things that happen always, or nearly always
16:37:49 <adamw> and probably -1 FE because we can fix it pretty well with an update
16:37:59 <roshi> wfm
16:38:33 <sgallagh> I'm -1/-1 as I said in the BZ
16:39:29 <roshi> proposed #agreed - RHBZ#1459779 - RejectedBlocker RejectedFreezeException - Because of the nature of how this bug presents, it doesn't violate any criteria. Because it can be fixed in an update, we're also not going to grant FE this close to release.
16:39:38 <pwhalen> note, new blocker proposal added
16:39:48 <roshi> thanks pwhalen  :{
16:39:51 <roshi> :P
16:40:04 <kparal> ack
16:40:12 <sgallagh> ack
16:40:36 <roshi> #agreed - RHBZ#1459779 - RejectedBlocker RejectedFreezeException - Because of the nature of how this bug presents, it doesn't violate any criteria. Because it can be fixed in an update, we're also not going to grant FE this close to release.
16:41:05 <adamw> ack
16:41:07 <roshi> #topic (1387733) Blank screen after boot on Raspberry Pi
16:41:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1387733
16:41:07 <roshi> #info Proposed Blocker, kernel, ASSIGNED
16:43:12 <sgallagh> Seems like a straightforward +1 to me
16:43:17 <roshi> yeah
16:43:57 <kparal> +1
16:44:33 <pbrobinson> I've been testing it against a scratch build over the last couple of days and it seems to improve a lot of devices that had issues in the past, like 4 monitors that never worked in the office now do
16:44:49 <roshi> proposed #agreed - RHBZ#1387733 - AcceptedBlocker - This bug violates the following Alpha criterion: "All release-blocking images must boot in their supported configurations."
16:44:53 <roshi> Release-blocking ARM disk images must boot to the initial-setup utility.
16:45:01 <roshi> bah, copied newlines
16:45:07 <roshi> will fix after acks
16:45:45 <roshi> proposed #agreed - RHBZ#1387733 - AcceptedBlocker - This bug violates the following Alpha criterion: "All release-blocking images must boot in their supported configurations. All release-blocking images must boot in their supported configurations."
16:45:57 <roshi> grrr
16:46:17 <adamw> ack
16:46:20 <sgallagh> It's a slightly weak definition of "boot", but I'm okay with it. ack
16:46:24 <kparal> ack
16:46:46 <roshi> #agreed - RHBZ#1387733 - AcceptedBlocker - This bug violates the following Alpha      criterion: All release-blocking images must boot in their supported configurations. Release-blocking ARM disk images must boot to the initial-setup utility."
16:47:02 <roshi> onto the FEs
16:47:26 <roshi> 13 of them...
16:47:27 <roshi> #topic (1465283) broken dependency for atomicapp in Fedora 26 - depends on docker on ppc64
16:47:30 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1465283
16:47:32 <roshi> #info Proposed Freeze Exceptions, atomicapp, ON_QA
16:47:48 <sgallagh> Did we cover the one pwhalen mentioned?
16:47:53 <sgallagh> s/one/blocker proposal/
16:47:55 <roshi> yep
16:47:57 <pwhalen> that was it
16:47:58 <sgallagh> ok
16:48:00 <roshi> that was the rpi one
16:48:01 <pwhalen> thanks
16:48:01 <sgallagh> Just making sure
16:48:33 <adamw> i'm theoretically OK with all 'broken dep' FEs, so long as the update *only* fixes the dependencies
16:48:40 <adamw> should we do some sort of group thing?
16:48:54 * roshi hasn't had a chance to look through them all
16:49:02 <roshi> if you have a grouping, go for it :)
16:49:12 <adamw> i haven't looked through them each in detail either
16:50:02 <adamw> but "anything with 'broken dependency' in the title" is the group
16:50:11 <adamw> how about this:
16:50:42 <adamw> proposed #agreed all 'broken dependency' proposed FEs are accepted, but only updates that *only* fix the broken dependency will be pushed. no other changes will be accepted unless there is a separate FE / blocker covering them
16:50:49 * nirik suggests if we are taking these, we should should do it asap... so we can make sure and fix any fallout.
16:50:57 <roshi> sgtm
16:50:59 <roshi> ack
16:51:03 <adamw> sure, that was the point - we can do a push right away.
16:52:01 <kparal> ack
16:52:22 <sgallagh> adamw: ack
16:53:21 <pschindl_wfh> ack
16:53:55 <adamw> #agreed all 'broken dependency' proposed FEs are accepted, but only updates that *only* fix the broken dependency will be pushed. no other changes will be accepted unless there is a separate FE / blocker covering them\
16:53:58 <adamw> grr
16:53:59 <adamw> #undo
16:53:59 <zodbot> Removing item from minutes: AGREED by adamw at 16:53:55 : all 'broken dependency' proposed FEs are accepted, but only updates that *only* fix the broken dependency will be pushed. no other changes will be accepted unless there is a separate FE / blocker covering them\
16:54:03 <adamw> #agreed all 'broken dependency' proposed FEs are accepted, but only updates that *only* fix the broken dependency will be pushed. no other changes will be accepted unless there is a separate FE / blocker covering them
16:54:24 <roshi> now move through the list of all !broken_dep?
16:54:51 <adamw> yep
16:54:57 <roshi> #topic (1401481) calligra-3.0.0 is available
16:54:57 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1401481
16:54:57 <roshi> #info Proposed Freeze Exceptions, calligra, ON_QA
16:55:37 <roshi> +1
16:56:03 <roshi> self-contained
16:56:09 <roshi> though, can be fixed with an update
16:56:30 <adamw> well...
16:56:33 <kparal> is it on some install medium?
16:56:44 <adamw> if it's in the live image, it's a potential thing that could be working now but broken with the update
16:56:47 <adamw> which would be a release blocker
16:57:04 <adamw> but otoh, being on the live image is a reasonable justification for granting an FE..
16:57:20 * adamw checks update feedback
16:57:29 <adamw> none at all.
16:58:15 <adamw> brb, call of nature
17:01:15 * kparal downloading KDE live image
17:03:57 <kparal> door bell, brb in 5 min
17:04:02 <roshi> kk
17:06:10 <adamw> i'm kinda in two minds on this one
17:06:17 <roshi> yeah
17:08:05 <roshi> I can see both
17:08:43 * kparal is back
17:08:54 <roshi> my assumption is that the first TC will need respun, so I kinda lean towards including it to see
17:09:02 <roshi> and we can roll back if it fails for the next one
17:09:47 * kparal booting
17:09:49 <sgallagh> I'm going to make my usual assertion that if there's not a strong reason why it must be fixed in the frozen set, it should not be included at this point.
17:10:20 <adamw> hehe
17:10:22 <roshi> I don't feel strongly about it
17:10:24 <kparal> "calligra" is not on KDE Live
17:10:24 <adamw> roshi's a practical guy
17:10:28 * roshi shrugs
17:10:34 <kparal> at least not in app finder
17:10:48 <roshi> that might be the closest thing to a compliment I've gotten all day :)
17:10:52 <kparal> neither as rpm
17:10:54 <sgallagh> If it's not on the install media, then I see no problems with it being a 0-day update
17:10:56 <roshi> I love you too, adamw
17:11:22 <kparal> -1 fe
17:11:34 <sgallagh> (at the same time, I suppose that also implies that it's limited in its ability to cause trouble as well...)
17:11:34 <roshi> -1 if it's not on the media
17:11:39 <sgallagh> But -1
17:11:46 <adamw> well, i guess technically shipping a major version update as a 0-day update is violating the update policy
17:11:48 <adamw> but...meh
17:12:11 <adamw> in a way that makes me more +1...if we give this an FE we establish that 3.x is the 'baseline version' for f26, without threatening the install media...
17:12:38 <roshi> hadn't considered that
17:12:44 <sgallagh> ah, hmm
17:12:45 * kparal shrugs, shouldn't matter
17:13:08 <sgallagh> Well, KDE has a blanket permission to rev mid-release too, doesn't it?
17:13:34 <adamw> oh, hmm, i remember something like that, yeah
17:13:39 <sgallagh> Or is this only KDE-adjacent?
17:13:42 <adamw> let's just go -1 and say we reckon shipping it as a 0-day update is fine
17:13:49 <sgallagh> WFM
17:13:52 <adamw> i dunno if it's officially part of KDE or not, i doubt people will complain
17:15:41 <adamw> so, -1 from me too
17:15:45 <roshi> proposed #agreed - RHBZ#1401481 - RejectedBlocker - There isn't a strong reason to include this in the frozen set as it can be fixed in an update.
17:15:50 <kparal> ack
17:16:00 <sgallagh> patch
17:16:16 <roshi> go for it
17:16:59 <sgallagh> proposed #agreed - RHBZ#1401481 - RejectedBlocker - This package doesn't ship as part of the frozen set, so it's least risky to ship as a 0-day update. We explicitly give it permission for this update to set the baseline major version for F26.
17:17:13 <roshi> ack
17:17:55 <adamw> i guess ack
17:18:07 <adamw> though it's not really our place to make official decisions about the updates policy, is it?
17:18:29 <adamw> if you want to be legalistic about it, that #agreed is basically the blocker review group arrogating the right to grant exceptions to the update policy...
17:18:36 <sgallagh> Perhaps not, but it would be de-facto setting it
17:18:37 <adamw> but hey :P
17:19:00 <kparal> the previous #agreed was better
17:19:36 <adamw> yeah, ack #1
17:19:38 <kparal> there's no updates policy violation, because the new major version will be in 0-day stable updates
17:19:45 <kparal> and it's not on any install medium
17:19:48 <sgallagh> ok
17:19:53 <sgallagh> ack #1
17:20:06 <roshi> #agreed - RHBZ#1401481 - RejectedBlocker - There isn't a strong reason to include this in the frozen set as it can be fixed in an update.
17:20:15 <roshi> #topic (1465208) Unlocking disk from dracut is broken
17:20:15 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1465208
17:20:16 <roshi> #info Proposed Freeze Exceptions, clevis, ON_QA
17:20:20 <adamw> kparal: it's technically against the update policy to do a major version update as a stable update (even a 0-day update, at least as i read the policy). but people break the update policy all the time, it's not really a huge deal.
17:20:35 * adamw wonders what clevis is
17:21:19 <roshi> never heard of a clevis
17:21:29 <kparal> adamw: maybe technically, but an F26 user can't easily install the older version, so it's moot
17:21:47 <adamw> "Automated decryption framework"
17:22:21 <adamw> the justification sounds reasonable on its face, and i don't think this package is usually on any media, so okay, +1
17:23:26 <kparal> if it's not on any media, we don't need to give it +1
17:23:50 <sgallagh> kparal: No, incorrect.
17:24:03 <adamw> no, i think he's right
17:24:07 <sgallagh> In this case, if someone kickstarted from a netinstall, they could end up with an installation using the bad code.
17:24:25 <adamw> only if they don't use the updates repo for their install...
17:24:30 <sgallagh> (If their kickstart didn't point at the updates... yeah)
17:24:52 <adamw> we've generally kinda assumed people include updates in installs when making FE decisions, i think.,
17:25:03 <sgallagh> It's an edge case, but since it's not on the media, the risk to the release by including it is minimal
17:25:11 <adamw> yeah
17:25:12 <kparal> anaconda has a checkbox for this
17:25:16 <roshi> proposed #agreed - RHBZ#1465208 - AcceptedFreezeException - It would be good to get this fix in for network installs.
17:25:18 <kparal> I wonder what the default state is
17:25:24 <kparal> (and whether it works at all)
17:25:28 <adamw> kparal: GUI default is to use the updates repo
17:25:35 <kparal> ok
17:25:41 <sgallagh> adamw: I thought it was the opposite: it was likely to be a valid FE if it could potentially introduce an issue at install time that is difficult to fix with an update.
17:25:50 <adamw> but you'd need a kickstart to include the package anyway
17:25:55 <kparal> either way is fine with me here
17:26:12 <sgallagh> +1 FE
17:26:43 <adamw> ack
17:27:26 <sgallagh> ack
17:27:29 <roshi> #agreed - RHBZ#1465208 - AcceptedFreezeException - It would be good to get this fix in for network installs.
17:27:39 <roshi> #topic (1465440) Cloud-init sysconifg.py called util.write_file incorrectly
17:27:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1465440
17:27:45 <roshi> #info Proposed Freeze Exceptions, cloud-init, ON_QA
17:29:40 <kparal> +1
17:29:47 <sgallagh> DigitalOcean is becoming a very popular way to deploy Fedora. I'm +1
17:30:06 <roshi> yeah
17:30:08 <sgallagh> I'm surprised this isn't actually blocking media for Cloud
17:30:12 <roshi> +1
17:30:22 <roshi> we have little direct impact on DO or how they push images
17:30:41 <roshi> blocking would be things we can impact directly (aiui, at least)
17:30:53 <roshi> since the DO folks are the ones that have to add the images - we can't do it
17:31:00 <roshi> unlike AWS
17:31:14 <adamw> sure, i guess +1
17:31:25 <nb> +1
17:31:44 <roshi> proposed #agreed - RHBZ#1465440 - AcceptedFreezeException - It would be good to get this fix in to support up to date Droplets on DO.
17:31:47 <nb> ack
17:32:06 <kparal> ack
17:32:22 <adamw> ack
17:32:34 <roshi> #agreed - RHBZ#1465440 - AcceptedFreezeException - It would be good to get this fix in to support up to date Droplets on DO.
17:32:42 <roshi> #topic (1435623) cyrus-imapd-3.0.1 is available
17:32:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1435623
17:32:42 <roshi> #info Proposed Freeze Exceptions, cyrus-imapd, ON_QA
17:33:58 <adamw> kinda similar to the calligra one...
17:34:40 <sgallagh> With Calligra, even if they installed the older one, the updated one would be compatible (as I understood it)
17:34:43 <adamw> cyrus-sasl and cyrus-imapd are in the 'mail server' group
17:34:49 <adamw> which i think is on the server DVD
17:34:53 <sgallagh> In this case, if someone installed without updates and then updated, it wouldn't be compatible.
17:34:54 <kparal> +1
17:35:17 <sgallagh> +1 FE
17:35:24 <adamw> i guess i can go +1
17:35:29 <roshi> +1 makes sense to me
17:35:38 <adamw> just hope it doesn't somehow break the server DVD...
17:35:41 <nb> +1
17:35:54 <sgallagh> Yeah, I'm aware of the risk
17:36:11 <roshi> proposed #agreed - RHBZ#1435623 - We'd like to see a fix for this get in to ease updates in the future.
17:36:22 <nb> ack
17:36:25 <sgallagh> ack
17:36:35 <roshi> #agreed - RHBZ#1435623 - We'd like to see a fix for this get in to ease updates in the future.
17:36:45 <roshi> #topic (1464555) package should provide Obsoletes:
17:36:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1464555
17:36:45 <roshi> #info Proposed Freeze Exceptions, gnome-backgrounds, ON_QA
17:37:19 <adamw> so on the one hand, upgrades are always gonna use the update repos
17:37:34 <adamw> otoh, if we push this *now* it stops people upgrading to f26 between now and the update unfreeze from hitting the bug
17:37:40 <adamw> so i'm probably +1 for that
17:37:43 <roshi> +1
17:37:48 <sgallagh> Yeah, +1
17:38:09 <roshi> proposed #agreed - RHBZ#1464555 - AcceptedFreezeException - It would be good to get a fix for this in.
17:38:21 <adamw> patch
17:38:29 <roshi> go for it
17:38:41 <adamw> proposed #agreed - RHBZ#1464555 - AcceptedFreezeException - It would be good to get a fix for this in to fix upgrades now rather than at the update unfreeze
17:38:50 <kparal> ack
17:38:56 <sgallagh> ack
17:39:00 <roshi> ack
17:39:28 <adamw> #agreed - RHBZ#1464555 - AcceptedFreezeException - It would be good to get a fix for this in to fix upgrades now rather than at the update unfreeze
17:39:58 <roshi> the next two were blockers already
17:40:07 <roshi> the kernel flag/SB stuff
17:40:10 <roshi> skipping those
17:40:21 <roshi> last one that isn't broken_dep
17:40:21 <roshi> #topic (1465610) resolved: an out-of-bounds write
17:40:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1465610
17:40:22 <roshi> #info Proposed Freeze Exceptions, systemd, ON_QA
17:41:26 <roshi> +1
17:41:45 <adamw> theoretically +1, but i'm gonna check the update with a fine-toothed comb to make sure he's not slipping anything else in there  :P
17:41:59 <roshi> makes sense
17:42:02 <sgallagh> adamw: I was just about to express that concern
17:42:09 <sgallagh> So... conditional +1 from me
17:42:11 <roshi> +1 provided it's *just* that fix
17:42:13 <kparal> +1
17:43:26 <roshi> proposed #agreed - RHBZ#1465610 - AcceptedFreezeException - Provided the fix *only* addresses this security issue, we'll consider the fix during freeze.
17:43:46 <sgallagh> ack
17:44:10 <kparal> ack
17:44:10 <adamw> ack
17:44:46 <roshi> #agreed - RHBZ#1465610 - AcceptedFreezeException - Provided the fix *only* addresses this security issue, we'll consider the fix during freeze.
17:44:58 <roshi> #topic Open Floor
17:45:06 <roshi> that's it, afaict
17:45:10 <roshi> anyone have anything else?
17:45:12 <roshi> pwhalen: ?
17:45:29 <pwhalen> nothing from me
17:45:37 <roshi> kparal: ?
17:45:40 <kparal> so, an RC won't be anytime soon I guess?
17:45:47 <roshi> you two tend to keep a couple up your sleeves... :P
17:45:48 <sgallagh> kparal: why do you say that?
17:46:05 <pwhalen> heh, emptied my sleeves earlier
17:46:06 <kparal> we still have blockers, right?
17:46:17 * kparal waits until blocker bugs app refreshes at the top of the hour
17:46:29 <sgallagh> kparal: I thought all the ones we accepted already had patches
17:46:47 <kparal> if that's the case, great
17:47:07 <roshi> I think they do
17:47:08 <sgallagh> Ah, maybe the RPi one needs a day or two
17:47:12 <kparal> it seems I'll be the only one in brno testing it next week
17:47:16 <sgallagh> Sounded like they were on top of that at least
17:47:22 <kparal> and just on monday and tuesday
17:47:35 <roshi> I have a couple RPis I can test with too
17:47:39 * sgallagh is on vacation all next week
17:47:41 <adamw> i'll aim for tomorrow for the rc
17:47:44 <roshi> just a few though, it's not like 10, or anything like that
17:47:45 <sgallagh> roshi: Which generation?
17:47:48 <adamw> sounds like we will get the bodhi/anaconda builds then
17:47:49 <roshi> yes
17:48:00 <roshi> 1/2/3/zero
17:48:01 <kparal> tomorrow morning our time would be nice :)
17:48:08 <sgallagh> roshi: Awesome
17:48:40 <sgallagh> adamw: Might be worthwhile to make an RC request immediately, even if it's missing one blocker.
17:48:49 <adamw> we can't do that.
17:48:59 <sgallagh> We used to have TC requests...
17:49:00 <adamw> do you mean a non-RC candidate compose?
17:49:01 <roshi> can't, or won't? :p
17:49:07 <adamw> it can't be an RC.
17:49:13 <adamw> we can do a candidate compose, but not sure it's worth it?
17:49:16 <mkolman> we plan to do a coordinated Anaconda/Blivet GUI build & bodhi tomorrow
17:49:42 <adamw> oh, a new FE was just proposed
17:49:48 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1463408
17:49:53 <sgallagh> adamw: Given the resource constraints we have next week, I'd rather find out a day earlier if we have any compose problems
17:50:14 <adamw> well, we do a compose every day...
17:50:17 <adamw> today's 26 compose went fine
17:50:18 <roshi> #topic (1463408) Obsolete devassistant
17:50:20 <sgallagh> ok
17:50:33 <mattdm> adamw: but didn't last time around the nightly compose go fine but the RC fail?
17:50:44 <mattdm> I'm worried about a repeat of this
17:50:49 <mattdm> of that i mean
17:50:53 <nirik> adamw: actually todays died in a fire, but yesterdays .1 worked and landed this morning early.
17:50:54 <adamw> i don't recall
17:51:00 <adamw> DETAILS
17:51:00 <adamw> :P
17:51:03 <adamw> what was the fire?
17:51:18 <nirik> DEBUG util.py:439:  Unable to create appliance : Failed mount disks : Failed to allocate loop device for '/var/tmp/imgcreate-AhiPBV/tmp-2cjZKT/Fedora-Xfce-armhfp-26-20170629.n.0-sda.raw'
17:51:46 <nirik> we have seen it do that in the past, but never tracked it down.
17:52:42 <nirik> perhaps if we are going to push anything stable we should do that and then fire another compose today. ;)
17:52:57 <roshi> can this one be fixed via a 0day update?
17:53:10 <sgallagh> nirik: I feel like that's more or less exactly what I was proposing :-)
17:53:26 <nirik> roshi: which one?
17:53:31 <sgallagh> roshi: Yeah, I don't see any reason why it couldn't be
17:53:46 <sgallagh> .bug 1463408
17:53:46 <zodbot> sgallagh: Bug 1463408 – Obsolete devassistant - https://bugzilla.redhat.com/1463408
17:53:50 <roshi> the FE in topic
17:53:51 <sgallagh> nirik: ^^
17:53:54 <nirik> ah, right
17:54:07 <adamw> well, there's the 'what about upgrades now?' argument
17:54:16 <adamw> but in this case, it's easy enough just to tell people to use --allowerasing
17:54:24 <adamw> or remove the package manually firest
17:54:30 <adamw> so prolly -1
17:54:37 <sgallagh> -1 from me as well
17:55:21 <roshi> proposed #agreed - RHBZ#1463408 - RejectedFreezeException - There's no reason to include this as an FE because it can be fixed via 0day update.
17:56:00 <adamw> ack
17:56:13 <sgallagh> ack
17:56:24 <roshi> #agreed - RHBZ#1463408 - RejectedFreezeException - There's no reason to include this as an FE because it can be fixed via 0day update.
17:56:29 <roshi> #topic Open Floor
17:56:34 <roshi> ok, really done this time
17:56:50 <roshi> unless we give it 4 minutes and the list refreshes and we see what kparal has done
17:56:59 <mattdm> noooooo :)
17:57:15 <adamw> the neverending meeting
17:57:15 <kparal> end it quick
17:57:31 <kparal> tick tock
17:57:58 * roshi sets the fuse
17:57:59 <roshi> 3...
17:58:07 <roshi> 2..
17:59:02 <roshi> 1.
17:59:04 <adamw> oh no, we've lost 1
17:59:36 <roshi> ?
18:00:43 <adamw> i started typing before you said 1.
18:00:48 <roshi> lol
18:00:56 <roshi> thanks for coming folks!
18:01:01 <roshi> #endmeeting