16:00:34 <adamw> #startmeeting F25-blocker-review
16:00:34 <zodbot> Meeting started Mon Oct  3 16:00:34 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:34 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:34 <adamw> #meetingname F25-blocker-review
16:00:34 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:34 <adamw> #topic Roll Call
16:00:38 <adamw> ahoyhoy folks
16:00:48 <adamw> ah, we scared mclasen away already, good good
16:00:52 * kparal is here
16:00:55 <adamw> who else is around to review some blockers? :)
16:01:14 <coremodule> cornmodule is here.
16:01:29 <jkurik> .hello jkurik
16:01:30 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
16:01:30 * pschindl is here and is willing to do the secretarization
16:01:33 * garretraziel will be somewhat lurking around
16:02:57 <sgallagh> .hello sgallagh
16:02:58 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:04:00 * cmurf is completely totally convinced he's here
16:04:15 <jkurik> cmurf: are you sure ?
16:04:26 <cmurf> absolutely
16:04:33 <cmurf> just waiting for adamw to tell me I'm wrong
16:04:48 <cmurf> or even better, confused
16:05:05 <adamw> you are feeling very sleepy
16:05:59 * cmurf zzzzzzz
16:06:35 <adamw> #chair coremodule jkurik
16:06:35 <zodbot> Current chairs: adamw coremodule jkurik
16:06:40 <cmurf> gonna go make a coffee while we're gathering i guess
16:06:43 <adamw> #info pschindl will secretarialize
16:07:18 * coremodule standing by for any other duty that may come up during the course of the meeting.
16:08:18 <adamw> #info coremodule will refill adamw's drink
16:08:39 <coremodule> lol. Not that kind of doody.
16:08:39 <adamw> #topic Introduction
16:08:40 <adamw> Why are we here?
16:08:40 <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:08:40 <adamw> #info We'll be following the process outlined at:
16:08:40 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:41 <adamw> #info The bugs up for review today are available at:
16:08:43 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:45 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:47 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
16:08:51 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
16:08:53 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
16:08:55 <adamw> coremodule: you'd better have the swiftest hands in the west
16:09:05 <kushal> .hellomynameis kushal
16:09:06 <zodbot> kushal: kushal 'Kushal Das' <mail@kushaldas.in>
16:09:06 <adamw> for Beta, we have:
16:09:07 <adamw> #info 3 Proposed Blockers
16:09:08 <adamw> #info 3 Accepted Blockers
16:09:18 <adamw> for Final, we have:
16:09:26 <adamw> #info 6 Proposed Blockers
16:11:17 <adamw> i believe sgallagh has another blocker proposal to add as well?
16:11:28 <sgallagh> adamw: No, I was talking about one of the known ones
16:11:37 <sgallagh> I was reading ahead of the class ;-)
16:11:40 <adamw> oh, okay. i don't see a beta one? anyhoo
16:11:52 <sgallagh> .bug 1381045
16:11:52 <zodbot> sgallagh: Bug 1381045 – xorg-x11-drv-qxl update lets sddm coredump - https://bugzilla.redhat.com/1381045
16:12:17 <adamw> oh, missed that
16:12:18 <adamw> alrighty
16:12:25 <adamw> starting with the proposed beta blockers:
16:12:31 <adamw> #topic (1379865) Current Fedora 25 and Rawhide cannot detect Intel firmware RAID set
16:12:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1379865
16:12:31 <adamw> #info Proposed Blocker, libblockdev, POST
16:12:44 <adamw> this one seems pretty slam dunk-y, intel firmware raid detection just no worky
16:12:54 <adamw> there's a fix i need to test, didn't get time yet
16:13:20 * cmurf thinks he voted in the bug
16:13:28 <sgallagh> adamw: I think it has enough votes in the bug to be approved already.
16:13:35 <adamw> probably
16:13:46 <pschindl> +1
16:13:59 <sgallagh> I was +1 in the bug, ftr
16:14:02 <adamw> we have +3 from the bug report
16:14:06 <adamw> so we're at +4 now
16:14:08 <adamw> anyone -1?
16:14:24 <kparal> +1
16:14:26 <jkurik> I am +1
16:15:17 <garretraziel> +1
16:15:18 <adamw> proposed #agreed 1379865 - AcceptedBlocker - violates Beta criterion "     The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:15:31 <sgallagh> ack
16:15:35 <pschindl> ack
16:15:42 <coremodule> ack
16:16:11 <sgallagh> Do we expect to get a fix for this today? I see there's a patch upstream.
16:16:12 <kparal> ack
16:16:29 <adamw> yes, like i said, there's a fix that I need to test.
16:16:35 <jkurik> ack
16:16:39 <adamw> #agreed 1379865 - AcceptedBlocker - violates Beta criterion "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:16:48 <adamw> #topic (1377113) [selinux-policy] media inserted into by optical drive do not get auto-mounted
16:16:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1377113
16:16:48 <adamw> #info Proposed Blocker, selinux-policy, POST
16:17:00 <jkurik> +1 to be a blocker
16:17:08 <adamw> i'm +1 to this too, automount is in beta criteria, and until you get selinux 216 it doesn't work
16:17:17 <cmurf> +1 still
16:17:17 <adamw> all we need for this is an update for -216 i believe
16:17:17 <coremodule> +1 here.
16:18:05 <pschindl> +1
16:18:06 <sgallagh> +1
16:18:50 <RaphGro> ola
16:19:19 <adamw> proposed #agreed 1377113 - AcceptedBlocker (Beta) - violates Beta criterion "Automatic mounting of removable media on insertion must work in release-blocking desktops."
16:19:21 <RaphGro> sorry, I could not use the blocker app because it was not possible to set rhbz credentials
16:19:32 <adamw> RaphGro: you have a bug to propose?
16:19:39 <coremodule> ack
16:19:40 <RaphGro> already done
16:19:43 <cmurf> RaphGro: known bug
16:19:48 <kparal> ack
16:19:50 <jkurik> ack
16:20:16 <sgallagh> ack
16:20:17 <RaphGro> adamw, 1381045 see above. that's from me.
16:20:24 <sgallagh> Right, we'll get there next
16:20:47 <cmurf> RaphGro: sorry, blocker app problem is what I was referring to
16:20:55 <RaphGro> cmurf, no problem
16:21:37 <adamw> #agreed 1377113 - AcceptedBlocker (Beta) - violates Beta criterion "Automatic mounting of removable media on insertion must work in release-blocking desktops."
16:21:47 <adamw> #topic (1381045) xorg-x11-drv-qxl update lets sddm coredump
16:21:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1381045
16:21:48 <adamw> #info Proposed Blocker, xorg-x11-drv-qxl, NEW
16:22:29 <sgallagh> So, this sounds like it's not a blocker *today*, but would be if we had to let in an update to X11 for another reason
16:22:31 <adamw> as per #c5 I don't think this is actually affecting stable atm.
16:22:39 <adamw> since openQA tests are passing (they use qxl)
16:23:08 <cmurf> is qxl the driver VM's are expected to work with?
16:23:30 <cmurf> i.e. if there's a work around using a different driver, we'd block on qxl?
16:24:02 <sgallagh> cmurf: I think that would be slushy for Beta and strict for Final. (Just my personal opinion)
16:24:34 <adamw> cmurf: it's the default for newly created VMs atm, i think, so i'd be inclined to block on it
16:24:49 <adamw> but yeah, i think we can reject for now
16:24:53 <adamw> -1 for me
16:24:54 <sgallagh> Proposal: Since this *will* hit stable once we exit freeze, re-propose as Final Blocker
16:25:07 <adamw> or perhaps it would be better to un-propose it
16:25:10 <adamw> sure, that seems reasonable too
16:25:12 <jkurik> hmmm, if we have a workaround (as stated in comment #4) it should not be a blocker even for final IMO
16:25:28 <cmurf> -1 beta blocker
16:25:34 <sgallagh> -1 Beta, +1 Final
16:25:56 <jkurik> -1 beta blocker; ? for final
16:26:05 <cmurf> maybe there needs to be a qxl add on to whatever the applicable final release criterion is?
16:26:10 <kparal> so is this not a 0day blocker?
16:26:25 <kparal> as long as updates-testing is enabled by default, it would make sense to treat it the same way as stable updates
16:26:27 <pschindl> -1 Beta
16:26:32 <kparal> except that it doesn't block compose
16:26:40 <cmurf> right
16:27:17 <adamw> kparal: hum, we've never really considered that case
16:27:22 <kparal> I know
16:27:26 <sgallagh> kparal: No, because the VMs will still boot until you update
16:27:36 <kparal> and then they won't
16:27:44 <cmurf> yeah hence 0day blocker
16:28:09 <sgallagh> When have we ever done a 0day blocker for Beta?
16:28:23 <sgallagh> Let's just mark it as a Final Blocker and trust the maintainers to get it fixed ASAP
16:28:49 <adamw> sgallagh: we've only had 0day blockers for one cycle :)
16:28:49 <cmurf> that is the easiest thing to do
16:29:23 <sgallagh> adamw: Don't you go spouting "facts" and "realities" at me!
16:29:26 <cmurf> it's pretty reasonable to make it a 0day if it's reasonable to make it a final blocker
16:29:29 <adamw> still, in this case i'd probably be ok with mentioning this in common bugs and suggesting people disable u-t or skip the x update if it's not fixed by release ady
16:29:32 <adamw> sorry!
16:29:35 <cmurf> because it's kinda crappy to release working beta, and then break it on update
16:29:38 <dgilmore> cmurf: indeed
16:30:05 <sgallagh> Remind me what 0day blocker entails?
16:30:21 <sgallagh> If Xorg doesn't get it fixed in time, do we slip after Go/No-Go?
16:30:30 <adamw> "Accepted0Day is used for cases where the fix does not need to appear in the final frozen release, but must be available as an update on release day."
16:30:31 <dgilmore> sgallagh: that the bug is fixed by release time and pushed out as a 0 day update
16:30:43 <kparal> sgallagh: either fixed on unpushed in this case
16:30:45 <dgilmore> as in we can be ready and not release if its not fixed
16:31:03 <adamw> if we were to apply it to this case, i guess it'd mean that by beta release day, either a fixed xorg-x11-drv-qxl must be in the update or the update must be yanked
16:31:11 <sgallagh> So we would do everything else for the release except announce it?
16:31:26 <dgilmore> sgallagh: and release it
16:31:41 <cmurf> ok so why not just unpush the busted update now?
16:31:41 <dgilmore> it would remain staged but hidden
16:31:50 <adamw> i think we decided that in practice if the fix wasn't in place by go/no-go day we'd vote no-go, right?
16:31:53 <sgallagh> Right, that's what I meant
16:31:54 <dgilmore> cmurf: we could
16:32:10 <dgilmore> adamw: likely
16:32:25 <cmurf> ok so just unpush the bad update, making it 0day is effectively the same power being used, and unpush now is a lot more reliable without last minute what is happening here stuff
16:32:30 <kparal> adamw: yes
16:32:42 <sgallagh> /me nods
16:32:56 <sgallagh> OK, in this case, the "unpush" option seems perfectly reasonable
16:33:05 <sgallagh> Shall we also go negkarma it as a group?
16:33:12 <sgallagh> (So it doesn't slip in by accident)
16:33:16 <cmurf> bingo
16:34:25 <kparal> or we could disable updates-testing for Beta release
16:34:30 <kparal> when do we flip this?
16:34:34 <kparal> usually
16:34:45 <sgallagh> kparal: Final RCs, I think
16:34:46 <adamw> proposed #agreed 1381045 - Accepted0DayBlocker (Beta) - the affected package is in updates-testing, so the Beta compose is not affected, but Beta installs will break on first update. So we accept this as a 0-day blocker, meaning (for Beta) a fixed package must be added to the update or the update must be unpushed, by go/no-go day
16:34:53 <cmurf> kparal: final
16:35:02 <adamw> yeah, right around Final freeze.
16:35:10 <sgallagh> adamw: Ack
16:35:13 <adamw> proposed #agreed 1381045 - Accepted0Day (Beta) - the affected package is in updates-testing, so the Beta compose is not affected, but Beta installs will break on first update. So we accept this as a 0-day blocker, meaning (for Beta) a fixed package must be added to the update or the update must be unpushed, by go/no-go day
16:35:33 <kparal> ack
16:35:44 <sgallagh> ack
16:35:58 <cmurf> ack
16:36:03 <jkurik> ack
16:36:10 <adamw> #agreed 1381045 - Accepted0Day (Beta) - the affected package is in updates-testing, so the Beta compose is not affected, but Beta installs will break on first update. So we accept this as a 0-day blocker, meaning (for Beta) a fixed package must be added to the update or the update must be unpushed, by go/no-go day
16:36:33 <adamw> OK, moving on to the accepted blockers
16:36:46 <adamw> #info Moving to Beta accepted blockers: not reviewing blocker status but checking that fix is in progress
16:36:53 <adamw> #topic (1369786) Autopart fails on installation from live usb created by l-i-t-d
16:36:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1369786
16:36:53 <adamw> #info Accepted Blocker, anaconda, POST
16:38:15 <cmurf> ok so this gets to my late email about adamw's wiki update, and how this relates to what is officially supported methods of creating USB stick media
16:38:33 <cmurf> I think Fedora Media Writer should be it. The current wiki lists five methods I don't think all should be officially supported.
16:38:56 <sgallagh> I agree with cmurf here. FMW should be the only *blocking* tool.
16:38:58 <cmurf> And as litd is getting stale I'm really on the fence there also.
16:39:06 <cmurf> Esp for beta.
16:39:09 <cmurf> Just not worth it.
16:39:22 <adamw> i don't think we can suddenly change that now.
16:40:03 <cmurf> There have been far worse bugs than this that we didn't make people fix. *shrug*
16:40:17 <cmurf> Esp people who don't have time to maintain the tool.
16:40:39 <cmurf> And the wiki is vague on what is officially supported anyway. Only FMW is "recommended" in the current wiki.
16:40:46 <sgallagh> adamw: Let's at least make the assertion for F26 now, so there's no question.
16:40:51 <kparal> I'm not sure whether it's ok to change this during F25 release cycle, but I'd also remove litd from the recommended tools list
16:41:01 <kparal> or at least not block on it
16:41:07 <adamw> sgallagh: let's not, this meeting isn't the place to make that decision
16:41:16 <sgallagh> /me shrugs
16:41:29 <sgallagh> Frankly, I don't think that blocking on unmaintained software makes sense in general.
16:41:48 <cmurf> I'm -1 blocker, because the prior wiki and current wiki do not state l-i-t-d is a recommended or officially supported tool for creating USB stick media.
16:41:59 <adamw> cmurf: given that i wrote the current page, i'd say that litd is covered.
16:42:10 <cmurf> If litd is covered, then unetbootin is covered.
16:42:15 <adamw> cmurf: i would disagree with that assessment, and i wrote both versions of the page and the criteria.
16:42:25 <cmurf> I read the whole thing there is no differentiating language.
16:42:26 <adamw> cmurf: no, it is not, because the wiki page explicitly says *not* to use unetbootin and that we do not support it.
16:42:29 <adamw> sure there is.
16:42:58 <adamw> the unetbootin section has a big yellow box at the top that says "Fedora cannot guarantee support for UNetbootin-written images."
16:43:12 <adamw> then some more text that says "If you encounter problems with UNetbootin, please contact the UNetbootin developers, not the Fedora developers."
16:43:23 <adamw> the section explicitly exists in order to state that we don't support unetbootin.
16:43:28 <adamw> none of that is true of the litd section.
16:44:16 <cmurf> there is a metric ass ton of text on that page - no offense
16:44:23 <kparal> :)
16:44:24 <adamw> i already cut as much of it as possible
16:44:35 <cmurf> it's like, Rube Goldberg contraption of how to make Fedora install media
16:44:53 <adamw> i know, but if you take any more out, people start whining about it.
16:44:57 <cmurf> reads like the rules of hockey, except when there's blood then it's a 4 minute penalty
16:45:15 <cmurf> OK then GNOME Disk Utility is blocking too?
16:45:19 <cmurf> There's no exception for that.
16:45:49 <adamw> well, that's an interesting case
16:46:05 <adamw> since the page says it's "for people running Linux (or another *nix) with GNOME, Nautilus and the GNOME Disk Utility installed."
16:46:13 <cmurf> The only one explicitly recommended on that page, still, is FMW.
16:46:35 <RaphGro> argh, I missed the discussion of my blocker proposal. but I'm fine with the decision. go ahead.
16:46:43 <cmurf> everything else is "may be useful" I don't think it's OK to block on "may be useful".
16:47:10 <cmurf> And how can things not explicitly recommended be officially supported?
16:47:22 <adamw> i think you're reading more into it than i wrote into it.
16:47:37 <adamw> the problem is we're still a bit in transition
16:47:54 <kparal> we'll need to discuss properly on the mailing list. for the moment, it would probably make sense to continue with how we evaluated things in the past
16:47:56 <adamw> FMW does not really cover everything yet. particularly, you can't easily use it on non-Fedora Linux
16:48:11 <adamw> anyway, we already *accepted* this as a blocker
16:48:22 <cmurf> oh christ
16:48:24 <adamw> the idea isn't to re-litigate that decision (unless we really need to) but to check in on the progress of the fix
16:48:29 <kparal> good point :)
16:48:36 <cmurf> yes indeed good point
16:48:38 <adamw> this bug is in POST and the PR is acked
16:49:04 <cmurf> whoops sorry ;-P bill the cat moment
16:50:57 <adamw> so i think this should be in hand
16:51:15 <sgallagh> I need to go and get lunch. Adios
16:52:04 <cmurf> so moving on?
16:53:07 <adamw> sgallagh: cya
16:53:09 <adamw> i guess
16:53:25 <adamw> i notice one reviewer asked for changes in the PR, so I posted a poke...
16:53:48 <adamw> #topic (1374864) initial-setup is not completable when there's no network link
16:53:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374864
16:53:49 <adamw> #info Accepted Blocker, anaconda, POST
16:54:31 <adamw> so there's a proposed fix for this, but some more testing would be good
16:54:40 <adamw> i asked dgilmore in the bug and i just poked him on IRC too
16:55:43 <cmurf> ack?
16:56:04 <adamw> oh, i should've done #info...oh well, we can skip it for one bug
16:56:21 <adamw> #info a proposed fix for this is under review, we have asked dgilmore to check status with current nightlies and test proposed fix if possible
16:56:27 <adamw> #topic (1225184) Live installer does not detect RAID devices
16:56:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1225184
16:56:28 <adamw> #info Accepted Blocker, python-blivet, VERIFIED
16:57:12 <adamw> this was a different RAID bug, we've verified that it's fixed with https://github.com/rhinstaller/anaconda/pull/812
16:59:28 <adamw> so should be fixed in next anaconda build
16:59:38 <adamw> #info the fix for this has been tested, only needs a new anaconda build
16:59:53 <adamw> alright, that should be all Beta blockers covered
16:59:59 <adamw> anything else before we go to proposed Final blockers?
17:00:49 <kparal> nothing here
17:01:15 <adamw> alrighty
17:01:21 <adamw> #info moving to proposed Final blockers
17:01:35 <adamw> #topic (1378156) TypeError: Must be number, not str
17:01:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1378156
17:01:35 <adamw> #info Proposed Blocker, anaconda, NEW
17:01:40 <adamw> more iSCSI fun, iirc.
17:01:45 <cmurf> pretty clearly a blocker
17:01:47 <cmurf> +1
17:02:15 <cmurf> even though I pine for the day of iscsi going away
17:02:22 * adamw checks this is still hitting current f25 nightlies, as exactly how iscsi is broken seems to change daily
17:02:27 <kparal> adamw: we're hitting this repeatedly, right?
17:02:48 <adamw> yep, same error today.
17:02:50 <adamw> https://openqa.fedoraproject.org/tests/38358/file/disk_custom_iscsi-anaconda.log
17:02:56 <cmurf> i see iscsi related tracebacks in anaconda logs - program or storage, not sure if that's related
17:03:08 <kparal> +1
17:03:34 <jkurik> +1 to final blocker
17:03:49 <pschindl> +1
17:04:32 <adamw> proposed #agreed 1378156 - AcceptedBlocker (Final) - violates "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
17:04:56 <jkurik> ack
17:04:57 <kparal> ack
17:05:00 <cmurf> ack
17:05:10 <coremodule> ack
17:05:41 <adamw> #agreed 1378156 - AcceptedBlocker (Final) - violates "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
17:05:48 <adamw> #topic (1379459) Fedora 25 official backgrounds not yet present in images / installed systems
17:05:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1379459
17:05:49 <adamw> #info Proposed Blocker, desktop-backgrounds, ON_QA
17:06:01 <adamw> this one's probably fixed now, just need to check it
17:06:15 <adamw> some non-blocking desktops will still need comps/kickstarts changes, i can propose those today
17:06:23 <adamw> but GNOME, KDE and Xfce should be good, at least if i can read
17:06:41 <adamw> anyhow, i'm +1, it's a clear blocker
17:07:04 <cmurf> +1 final blocker
17:07:07 <coremodule> +1
17:07:28 <pschindl> +1
17:07:29 <kparal> +1
17:07:53 <jkurik> +1
17:08:38 <adamw> proposed #agreed 1379459 - AcceptedBlocker (Final) - violates "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme."
17:08:48 <cmurf> ack
17:08:50 <jkurik> ack
17:08:53 <pschindl> ack
17:09:05 <coremodule> ack
17:09:06 <kparal> ack
17:09:58 <adamw> #agreed 1379459 - AcceptedBlocker (Final) - violates "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme."
17:10:08 <adamw> #topic (1381039) USB devices aren't found or enumerated, results in boot failure from USB stick installation media
17:10:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1381039
17:10:08 <adamw> #info Proposed Blocker, kernel, NEW
17:10:12 <adamw> huh, this is a new one.
17:10:18 <cmurf> gist of this one: I guess the release criterion would be that the install media has to boot; but since it only affects 1 of 4 of my systems, I went with the kernel team's FAQ instead.
17:10:36 <dgilmore> adamw: I can confirm that initial-setup is still broken
17:10:54 <cmurf> suggestion: punt or vote conditional, see if the kernel team has any idea what's going on and whether and how I can provide more information?
17:11:08 <jforbes> It is, but given that it seems to only impact 1 system, I would be hard pressed to call it a blocker just yet
17:11:41 <cmurf> jforbes: it is, what?
17:11:51 <jforbes> cmurf: a new one, typing slow today
17:11:53 <adamw> dgilmore: can you test the fix?
17:12:16 <cmurf> gotcha
17:12:44 <adamw> jesus, that wiki text is old.
17:13:01 <adamw> so yeah, as long as we only know of one system suffering from this and it's not a regression, i'm inclined to -1
17:13:09 <adamw> we can't really block the release on random hardware enablement
17:13:35 <adamw> anyone else seen this, by any chance?
17:13:51 <jforbes> I would be all for it if this were impacting a number of systems or a common chipset
17:13:58 <cmurf> it's a brand new out of box HP Spectre, it's not exotic hardware
17:14:33 <cmurf> It's just really new. No idea if HP is doing something silly, or if Intel just doesn't have supporting code upstream? I don't really know what the deal is...
17:14:36 <adamw> cmurf: doesn't really matter how exotic it is
17:14:55 <adamw> jforbes: presumably we don't have a flood of these reports for all skylake systems or anything?
17:15:15 <jforbes> adamw: no, we don't
17:15:29 <cmurf> Ok well I did what the kernel FAQ asked :-) that's the only reason why I nominated it a blocker.
17:16:01 <adamw> anyway, yeah, i'm -1 unless we find out this affects other systems or we find that a million people just bought spectre 13s and are desperate to run fedora on them.
17:16:36 <kparal> -1, same reason
17:17:48 <jforbes> Wow, that page needs an update
17:18:05 <adamw> =)
17:18:20 <adamw> counting jforbes as -1, that's -3
17:18:27 <pschindl> -1
17:18:31 <jkurik> -1 as well
17:19:10 <adamw> proposed 1381039 - RejectedBlocker - so far we only know of a single affected system, and it's not a regression; this isn't a broad enough impact for a hardware-specific bug to be counted as a violation of the criteria. this decision can be revisited if more systems are found to be affected
17:20:07 <kparal> ack
17:20:13 <coremodule> ack
17:20:19 <jkurik> ack
17:20:33 <adamw> #agreed 1381039 - RejectedBlocker - so far we only know of a single affected system, and it's not a regression; this isn't a broad enough impact for a hardware-specific bug to be counted as a violation of the criteria. this decision can be revisited if more systems are found to be affected
17:20:44 <adamw> #topic (1380859) Should obsolete liveusb-creator
17:20:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1380859
17:20:44 <adamw> #info Proposed Blocker, mediawriter, NEW
17:21:28 <adamw> i'm kinda convinced to +1 this on the rationale that the thing you get if you try to install our 'supported tool' from Software isn't the right thing and doesn't work
17:21:40 <adamw> though we're not sure just adding an obsoletes will entirely fix that...
17:22:09 <adamw> i guess there's also the point that if you had our previous 'supported tool' installed, it might not work any more and there's nothing much to tell you what to do
17:22:10 <kparal> maybe I should have reported it separately. the important thing is that obsoletion is not strictly important, but people have to be able to install FMW from gnome-software
17:22:22 <kparal> (or at least not install LUC while believing it's FMW)
17:22:27 <cmurf> +1 obsolete it
17:22:39 <cmurf> maybe use epoch if necessary to get rid of the renamed LUC as FMW
17:23:04 <kparal> I talked to mbriza and he considers either obsoleting it, or reverting the graphics overhaul LUC received last cycle
17:23:15 <kparal> (and also reverting the appstream metadata, hopefully)
17:23:34 <kparal> after metadata is fixed, we will need to poke hughsie to rebuild them and submit an update
17:26:13 <kparal> other votes?
17:26:22 <adamw> hum, i'd be a bit worried about keeping the liveusb-creator package with no obsoletion because then people who already have it installed or just have the package name memorized are never going to get the good tool...
17:26:36 <adamw> i'm just trying to think whether it really makes sense to block on the obsoletion specifically.
17:26:48 <adamw> i think maybe we'd be better off with some kind of more general bug as a blocker if anything
17:26:50 <kparal> adamw: if it gets renamed back to LUC, and we talk about FMW everywhere, then they'll just install FMW from gnome-software, no?
17:27:05 <adamw> kparal: people showing up fresh and reading the instructions, yeah
17:27:12 <kparal> hmm
17:27:12 <adamw> kparal: people who already know liveusb-creator, not necessarily
17:27:27 <kparal> we can't really dictate that LUC has to get obsoleted
17:27:40 <adamw> not via this process, nope
17:27:52 <adamw> it would just feel strange to me if we were to keep it around, i mean, why would we want to have both tools
17:28:21 <kparal> I think the crux of this blocker bug should be "LUC must not be presented as FMW in gnome-software, because it's misleading"
17:28:44 <kparal> that's why I said I might have hijacked your report
17:28:53 <kparal> but it made sense earlier :)
17:29:39 <kparal> adamw: mbriza said LUC can also do "cp mode" and persistent overlays, which FMW can't
17:29:45 <kparal> but we all know how well that works
17:30:21 <kparal> but it was a reason why he was thinking about keeping LUC installable
17:31:27 <jkurik> I think keeping LUC in F25 makes sense, however it must be clear that it is LUC and not FMW
17:31:39 <kparal> right
17:31:48 <adamw> kparal: yeah, if no-one's going to support or test that it's an anti-feature.
17:32:05 <dgilmore> adamw: the proposed fix worked
17:32:09 <adamw> dgilmore: great
17:32:12 <kparal> ok, so let's add our recommendation to obsolete it
17:32:14 <adamw> can you update the bug?
17:32:21 <adamw> ok
17:32:39 <adamw> so, are we inclined to take this as a blocker, or not? I guess I'm -1 on the grounds that adding the obsoletion specifically doesn't really mesh with any critera
17:32:42 <kparal> and block on "FMW != LUC"
17:32:57 <adamw> but i could +1 a 'only the real FMW should appear in Software' bug as a blocker at least
17:33:11 <adamw> yeah, if you want to file and propose it quick we could do it in the meeting, otherwise it can wait for next week
17:33:27 <kparal> I'll file it right away
17:33:30 <coremodule> +1 on the 'only the real FMW should appear in Software' criteria
17:33:40 <adamw> if luc doesn't get obsoleted i think at least the package description should grow a 'you probably want FMW instead' disclaimer too
17:34:11 <coremodule> I agree with that.
17:34:36 <adamw> proposed #agreed 1380859 - RejectedBlocker (Final) - we don't think adding this Obsoletes: specifically would really resolve anything that could be described as a 'criteria violation'. however, we discussed some other cases which may be more suitable and will propose new blockers
17:34:38 <jkurik> adamw: yes, we can propose that, but we should not block on it
17:34:39 <cmurf> +1 on only the real FMW should please stand up
17:34:40 * adamw brb call of nature
17:34:57 <jkurik> +1
17:36:41 <kparal> ack
17:36:48 * kparal proposed https://bugzilla.redhat.com/show_bug.cgi?id=1381327
17:37:30 <kparal> we don't even need to formally vote, I can just shift the blocker proposal from this one to the new one
17:37:37 <adamw> #agreed 1380859 - RejectedBlocker (Final) - we don't think adding this Obsoletes: specifically would really resolve anything that could be described as a 'criteria violation'. however, we discussed some other cases which may be more suitable and will propose new blockers
17:37:56 <adamw> too late :P
17:37:57 <adamw> #topic (1379800) systemd does not create new machine-id file if none is present
17:37:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1379800
17:37:57 <adamw> #info Proposed Blocker, systemd, NEW
17:38:18 <kparal> adamw: go to 1381327 instead?
17:38:23 <pwhalen_> we worked around this for arm images, touching the file in the ks
17:38:52 <kparal> everybody keep the context in your head, we'll get back to LUC :)
17:39:53 <coremodule> pwhalen, Did that fix for ARM get released?
17:40:01 <coremodule> The new kickstart?
17:40:16 <adamw> kparal: sorry, just working through the list or i'll get confused...
17:40:30 <pwhalen> coremodule, thankfully yes, its now included
17:41:11 <kparal> +1
17:41:23 <kparal> per comment 13
17:42:05 <coremodule> pwhalen, Gotcha, okay. If we can do the same for Cloud, that'd work.
17:42:49 <coremodule> I'm +1.
17:43:19 <adamw> yeah, I can +1 this
17:43:46 <adamw> hmm
17:43:47 <adamw> actually
17:43:59 <adamw> this should be a Beta blocker, I think?
17:44:06 <adamw> Alpha criterion "A system logging infrastructure must be available, enabled by default, and working."
17:44:39 <coremodule> adamw, Good point. That criteria seems to be more this-case specific.
17:44:50 <adamw> well, 'this case' involves a release blocking image, right?
17:45:05 <adamw> if the upshot of this is that anyone who deploys the Cloud base image gets no logging, I'm ok with blocking Beta on that
17:45:11 <coremodule> Cloud x86_64
17:45:14 <pschindl> +1
17:45:29 <pwhalen> for arm, we strip the file.. it is created, but we want unique machine-id's .. i think systemd should create it, but i dont know if we should block on this, not sure when a fix will be available.. does cloud strip the file?
17:45:31 <adamw> presumably we can work around it with the 'empty file' trick if systemd can't be fixed immediately, right?
17:45:48 <adamw> pwhalen: comment #13 says it does.
17:46:02 <adamw> pwhalen: per the bug, we can make things work by putting the file in the image but having it *empty*.
17:46:11 <adamw> #c6
17:46:24 <coremodule> In Cloud, the file is non-existent. If you create it and reboot or run systemd-machine-id-setup, then it populates the file with the machine-id.
17:46:58 <adamw> coremodule: right. so what i'm saying is, we don't necessarily need a systemd fix immediately, we can just have the image include an empty file instead of stripping it entirely.
17:47:12 <coremodule> adamw, Sure, that'd work.
17:48:05 <adamw> so...votes, again? if +1, state whether for beta or final
17:48:28 <jkurik> +1 for final
17:49:09 <pschindl> +1 final
17:49:10 <kparal> why Final?
17:49:35 <adamw> right, if we don't take this for Beta we need a rationale for why not, given that it seems to violate an Alpha criterion.
17:49:54 <jkurik> there is a workaround for it, so IMO we can live with it for Beta
17:50:11 <kparal> but the workaround needs to be implemented in the compose tool, no?
17:50:31 <pwhalen> looks like cloud already has the workaround - http://koji.fedoraproject.org/koji/taskinfo?taskID=15922122
17:50:31 <kparal> or do you mean "create the file manually" workaround?
17:50:44 <adamw> kparal: the bugs reads like you can create the file manually and reboot as a workaround.
17:50:47 <jkurik> yes, I mean the manual way
17:50:58 <pwhalen> in the ks: touch /etc/machine-id
17:51:13 <kparal> ok, but that doesn't help the cloud, unless it is really fixed already in it
17:51:14 <adamw> ah yeah
17:51:22 <adamw> pbrobinson applied it to all relevant kickstarts, it looks like: https://pagure.io/fedora-kickstarts/c/30c3f7e721709b354d2a98b48d533c359d57bb87?branch=master
17:51:28 <pwhalen> nice
17:51:30 <coremodule> Great!
17:51:37 <adamw> same on f25: https://pagure.io/fedora-kickstarts/c/73645f341ed34239e13c27ce8e7e8702487a6718?branch=f25
17:51:50 <adamw> so i guess we can say this doesn't need to a be a blocker since we've worked around it in kickstarts?
17:51:56 <kparal> yes
17:52:03 <jkurik> ok
17:52:11 <coremodule> Yes here.
17:52:40 <adamw> proposed #agreed 1379800 - RejectedBlocker (Final) - this would be a blocker, but it has been worked around in fedora-kickstarts by ensuring the images contain an empty file, so we do not actually need to block on it so long as that works
17:52:49 <nb> ack
17:53:07 <coremodule> ack
17:53:34 <jkurik> ack
17:53:35 <kparal> ack
17:53:39 <adamw> #agreed 1379800 - RejectedBlocker (Final) - this would be a blocker, but it has been worked around in fedora-kickstarts by ensuring the images contain an empty file, so we do not actually need to block on it so long as that works
17:54:07 <adamw> so, to kparal's new proposal
17:54:42 <adamw> #topic (1381327) LUC is presented as FMW in gnome-software
17:54:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1381327
17:54:54 <adamw> #info Proposed Blocker, liveusb-creator, NEW
17:55:09 <jkurik> +1
17:55:16 <adamw> +1 final for me, yeah
17:55:20 <kparal> +1
17:55:23 <adamw> i think we can live with the mess for beta but not final
17:55:41 * jkurik has the same pov
17:56:49 <adamw> proposed #agreed 1381327 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods", as we think we can live with the confusion for Beta but it's not acceptable for Final
17:57:10 <kparal> ack
17:57:29 <coremodule> ack
17:57:35 <jkurik> ack
17:57:42 <nb> ack
17:58:23 <pschindl> ack
17:59:03 <adamw> #agreed 1381327 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods", as we think we can live with the confusion for Beta but it's not acceptable for Final
17:59:14 <adamw> okay, I think that's the lot
17:59:26 <adamw> now we'd better get to lining up ducks to get an RC built tomorrow...
17:59:31 * pwhalen added a new proposal for beta - https://bugzilla.redhat.com/show_bug.cgi?id=1379311
17:59:34 <pwhalen> sorry
17:59:42 <adamw> sigfh
18:00:34 <jkurik> hmm, this looks like +1 :(
18:00:45 * adamw can't parse it.
18:00:52 <adamw> what exactly is this about?
18:01:00 <pwhalen> autopart defaults to 15G root partitions
18:01:09 <adamw> #topic (1379311) 15Gigs root partition maxSize not customisable in anaconda kickstart script
18:01:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1379311
18:01:35 <adamw> #info Proposed Blocker (Beta), anaconda, NEW
18:01:37 <adamw> okay, and?
18:01:41 <dgilmore> that was a choice the ServerWG made
18:02:10 <dgilmore> I am -1 blocker as it is the intended server behaviour
18:02:16 <pwhalen> oh :/ interesting.. i didnt realize that
18:02:26 <kparal> so you can't override partitioning in kickstart now?
18:02:48 <dgilmore> kparal: that would likely be a anaconda bug
18:02:49 <adamw> i don't read the bug as saying that
18:02:51 <adamw> though it's very confusing
18:03:10 <adamw> it seems to just be saying that  you'll get different behaviour with the same kickstart (relying on auto-partitioning) depending on which image you use, which, yes, you will
18:03:16 <adamw> but that's neither a blocker nor even a bug, i don't think
18:03:17 <pwhalen> im sure you can, but autopart just does 15G.. I didnt realize this was intended. hrm, ok..
18:03:30 <kparal> "cannot be tweaked in the anaconda-ks.cfg file for another automated installation " - what does that mean?
18:03:39 <cmurf> I think it does 15G if you have at least 15G
18:04:00 <adamw> kparal: yeah, that's one of the bits i'm having trouble grokking.
18:04:03 <dgilmore> if you go auto partitioning you should get the defaults for the product being installed
18:04:10 <cmurf> dgilmore: right
18:04:12 <dgilmore> xfs on server ext4 on workstation
18:04:24 <dgilmore> sever says / should be only 15G
18:04:27 <dgilmore> server
18:04:29 <kparal> adamw: I think you're right in your interpretation
18:05:00 <adamw> so basically i'm -1 as far as i understand the bug. :P
18:05:05 <cmurf> I don't understand the failure. Is this a kickstart asking for autopart but then trying to customize it? I wouldn't expect that to work.
18:05:13 <dgilmore> if you use autopart you get teh defaults, to me this is not even a bug
18:05:15 * nb thinks he is -1 if he understands it correctly
18:05:21 <kparal> so unless someone can demonstrate that manual partitioning in kickstart is broken, -1
18:05:28 <jkurik> I did read it in the same way as kparal, however you have convinced me it is not the right way :)
18:05:33 <pwhalen> i just didnt expect autopart to give me a 15G root partition, if this was by design.. ok
18:05:50 <adamw> yeah, it's by design.
18:05:53 <jkurik> so, -1 to block on this
18:05:54 <pwhalen> hrm
18:05:55 <dgilmore> pwhalen: it will probably surprise some people
18:06:02 <pwhalen> i think to most
18:06:07 <cmurf> If you're using a kickstart, I think you need to explicitly ask for what you want, and not use autopart. If you want a different autopart then I think you want to start out with the Everything netinst.
18:06:07 <pwhalen> alas
18:06:09 <adamw> i mean, you can take up the design with server sig, if you like :) but it's not a bug.
18:06:09 <kparal> pwhalen: where does the rest of the space go?
18:06:31 <pwhalen> in the same vg
18:06:35 <cmurf> kparal: It should be in the VG, but unclaimed.
18:06:38 <pwhalen> right
18:06:38 <kparal> ah
18:06:43 <adamw> cmurf: the complaint in the bug is basically that the reporter wants kickstarts to be entirely deterministic, i think.
18:06:48 <adamw> "Maybe this option could be made available someway in an anaconda option, that would make the kickstart file self-contained ?"
18:07:03 <cmurf> The idea is to make it possible for the sysadmin to decide what to do with the space rather than decide it at autopart time, when it's too late to use it for some other purpose.
18:07:43 <kparal> well it's not that hard to shrink an LV, but whatever
18:07:44 <cmurf> Someone might want a big LV for /opt or /data or whatever, someone else might want it used with docker-storage-setup which will autoconfigure that space as LVM thin.
18:07:52 <cmurf> kparal: can't shrink XFS
18:07:53 <dgilmore> pwhalen: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/D7ZK7SILYDYAATRFS6BFWZQWS6KSRGDG/#PMU52NQX7XYMJ2HPR6QRKH2ARK5F2YM7
18:08:06 <kparal> cmurf: well now it makes more sense
18:08:15 <kparal> interesting file-system
18:08:20 <adamw> proposed #agreed 1379311 - RejectedBlocker (Beta) - so far as we can determine there is not even a bug here, let alone a blocker. It is just the intended behaviour: if you specify autopart in your kickstart, the exact result will differ between Fedora flavors.
18:08:24 <pwhalen> thanks dgilmore
18:08:42 <jkurik> ack
18:08:45 <kparal> ack
18:08:48 <dgilmore> ack
18:08:49 <pschindl> ack
18:08:57 <adamw> #agreed 1379311 - RejectedBlocker (Beta) - so far as we can determine there is not even a bug here, let alone a blocker. It is just the intended behaviour: if you specify autopart in your kickstart, the exact result will differ between Fedora flavors.
18:09:16 <adamw> alright, so do we have any other additional proposals or anything?
18:10:07 <adamw> #topic Open floor
18:10:15 <adamw> so...we're once again in Beta crunch time, sigh
18:10:39 <adamw> go/no-go is Thursday, we cannot build an RC until at least tomorrow as sbueno says there will not be an anaconda build till then
18:11:03 <adamw> in the meantime we need to be knocking out tests with the current validation nightly, and confirming / karma'ing the blocker fixes we do have
18:11:08 <adamw> i'll try and send out status mail etc. later today
18:11:46 <jkurik> adamw: are you going to be present on the go/no-go ?
18:11:50 <adamw> yeah.
18:12:58 <jkurik> ok, thanks
18:14:02 <adamw> any other thoughts, notes, issues etc?
18:14:53 <pschindl> I'm missing one proposed Final blocker. Shouldn't be there 6 + 1 newly created by Kamil?
18:15:21 <pschindl> probably not :)
18:16:22 <adamw> i think we covered them all
18:16:38 <adamw> there's only two still showing in blockerbugs' proposed list, both of which we hit
18:19:20 <adamw> alright, sounds like that's everything
18:19:22 <adamw> thanks for coming, folks
18:19:24 * adamw sets fuse
18:19:54 <coremodule> Thanks for hosting adamw.
18:20:59 <adamw> see you at the go/no-go, folks
18:21:01 <adamw> #endmeeting