16:01:03 <roshi> #startmeeting F26-blocker-review
16:01:03 <zodbot> Meeting started Mon Jun  5 16:01:03 2017 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:03 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:01:03 <roshi> #meetingname F26-blocker-review
16:01:03 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:01:03 <roshi> #topic Roll Call
16:01:12 <roshi> who's around for some blocker review!?
16:01:14 <jkurik> .hello jkurik
16:01:15 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
16:01:18 <adamw> ahoyhoy
16:01:20 <adamw> .hello adamwill
16:01:22 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
16:01:26 <nathan95> hello
16:01:59 <adamw> hi again nathan
16:02:06 * roshi has coffee and something to eat - which is win :D
16:02:24 <roshi> #chair jkurik adamw tflink kparal sgallagh
16:02:24 <zodbot> Current chairs: adamw jkurik kparal roshi sgallagh tflink
16:02:39 * jkurik has no coffee, no food :(
16:02:48 * adamw has coffee and shreddies
16:02:52 <adamw> breakfast of champions
16:03:08 * roshi has 3 beer brats, and some sriracha mayo
16:03:15 * pschindl_wfh is here
16:03:22 <roshi> #chair pschindl_wfh
16:03:22 <zodbot> Current chairs: adamw jkurik kparal pschindl_wfh roshi sgallagh tflink
16:03:31 <roshi> #topic Introduction
16:03:31 <roshi> Why are we here?
16:03:31 <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:35 <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:40 <roshi> #info The bugs up for review today are available at:
16:03:42 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:45 <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:04:02 * kparal is here
16:04:16 <roshi> #info there's no proposals for Beta
16:04:25 <roshi> and we kinda already know the status of the libdb thing
16:04:27 <jkurik> \o/
16:04:31 <roshi> so moving directly into Final proposals'
16:04:40 <adamw> someone check the duct tape on kparal
16:04:44 <roshi> 7 proposed blockers
16:05:01 <adamw> he's trying to tap out 'BetaBlocker' with his eyebrows, i can see it
16:05:01 <roshi> first up
16:05:02 <roshi> #topic (1454854) DNF progress.start() broken with 2.5.0, breaking dnfdaemon (and dnfdragora)
16:05:05 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1454854
16:05:08 <roshi> lol
16:05:10 <roshi> #info Proposed Blocker, dnfdaemon, ON_QA
16:06:01 <adamw> the question of what's the 'default' package manager on KDE seems a bit complex ATM
16:06:06 <adamw> but dnfdragora at least seems to be in the running
16:06:17 * roshi for sure doesn't know wha tthe default is on KDE
16:07:22 <adamw> I did ask "Beyond this: what's the actual intended shape of package management and
16:07:22 <adamw> updates on KDE now? Is dnfdragora supposed to be responsible for all of
16:07:22 <adamw> it, or is...some other thing...supposed to handle updating, and
16:07:22 <adamw> dnfdragora is only supposed to be there for installing / removing?" on the KDE list a while back
16:07:25 <adamw> aha, just the person
16:07:40 <adamw> kevin, can you clarify what exactly is the 'default package manager' for KDE right now?
16:07:47 <roshi> welcome Kevin_Kofler :)
16:09:47 <jkurik> when I run "Software center" from KDE menu, it runs /usr/bin/plasma-discover
16:10:05 <kparal> +1 assuming dnfdragora is the default manager
16:10:10 <kparal> if not, we can retract
16:10:11 <jkurik> which seems to have the ability to update sw and install/remove packages
16:10:21 <kparal> it will be solved in a week anyway, hopefully
16:10:28 <roshi> yeah
16:10:35 <roshi> looks like there's a fix already
16:10:55 <roshi> since we don't know the default, what say we punt and see if it resolves before we meet again?
16:11:05 <adamw> i'd say ask for clarification in the bug, and punt
16:11:19 <jkurik> adamw: +1
16:12:13 <Kevin_Kofler> As I understand it, both dnfdragora and Plasma Discover should be shipped by default, Apper should not anymore.
16:12:32 <roshi> proposed #agreed - RHBZ#1454854 - Punt - It's not 100% clear what is the default package manager for KDE, so we can't determine blocker status for this issue.
16:12:38 <roshi> patch
16:12:39 <Kevin_Kofler> dnfdragora manages packages at package level, Plasma Discover is like GNOME Software (AppStream-based).
16:12:51 <Kevin_Kofler> I can ask on #fedora-kde.
16:12:52 <roshi> proposed #agreed - RHBZ#1454854 - Punt - It's not 100% clear what is the default package manager for KDE, so we can't determine blocker status for this issue at this time.
16:13:07 <roshi> that'd be great Kevin_Kofler
16:13:20 <kparal> ack
16:13:23 <roshi> circle back on this or wait?
16:13:26 * roshi is fine with either
16:13:31 <jkurik> ack
16:13:47 <roshi> ack to the proposed, or to waiting?
16:13:48 <Kevin_Kofler> I asked there, let's see if anybody knows more than me.
16:14:15 <adamw> okay. we may even have to amend the criteria to say default package manager(s) or something, then.
16:14:20 <Kevin_Kofler> rdieter probably knows for sure, but he's not online now.
16:14:24 <Kevin_Kofler> So maybe punt for now.
16:14:27 <adamw> and consider whether it's okay for just *one* to work, or if they all have to work...
16:15:08 <kparal> I'd say all. same as all default apps
16:15:14 <roshi> yeah
16:15:40 <roshi> but that would raise the question why kde needs 2 things (if I understand correctly)
16:16:08 <Kevin_Kofler> Because Discover manages only "applications", not packages.
16:16:16 <Kevin_Kofler> You see only what is in AppStream.
16:16:21 <adamw> yeah, same reason some people install yumex or whatever on Workstation.
16:16:25 <Kevin_Kofler> It also does not show the dependencies etc.
16:16:45 <roshi> and dnfdragora does which bits that dnf itself doesn't do?
16:16:50 <Kevin_Kofler> By the way, dnfdragora should work great on Workstation too, there is even a GTK+ backend. (It uses the libyui abstraction.)
16:17:00 <Kevin_Kofler> dnfdragora is a GUI for DNF. :-)
16:17:06 <adamw> so, i'm still fine with a punt
16:17:08 <roshi> ah
16:17:12 <Kevin_Kofler> (and an ncurses TUI too, libyui gives you that for free)
16:17:18 <roshi> so, acks to the proposed?
16:17:44 <Kevin_Kofler> It's a frontend for dnfdaemon which uses the DNF Python API.
16:17:48 <linuxmodder> .fas linuxmodder
16:17:48 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
16:17:58 <roshi> proposed #agreed - RHBZ#1454854 - Punt - It's not 100% clear what is the default package manager for KDE, so we can't determine blocker status for this issue at this time.
16:18:45 <jkurik> ack
16:18:46 <kparal> ack again
16:18:49 <adamw> ack
16:18:53 <roshi> #agreed - RHBZ#1454854 - Punt - It's not 100% clear what is the default package manager for KDE, so we can't determine blocker status for this issue at this time.
16:19:02 <roshi> ah
16:19:10 <roshi> can someone secretarialize?
16:19:18 * roshi forgot to ask for that earlier
16:19:41 <roshi> #topic (1452866) FreeIPA upgrade script requires network to be up, but network is not up during upgrade when using dnf system-upgrade
16:19:44 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1452866
16:19:45 <adamw> i can
16:19:46 <roshi> #info Proposed Blocker, freeipa, NEW
16:19:50 <roshi> thanks adamw
16:20:12 <adamw> so i've been looking into this one some more, but it's still not yet clear precisely what the impact is
16:20:15 <adamw> i need to run some more tests
16:20:35 <adamw> right now it's clear the upgrade process doesn't really work properly at all, but the server does still work to *some* extent despite the failed upgrade script
16:20:48 <adamw> we need to nail down some details on what the upgrade script failing actually breaks
16:22:00 <kparal> so punt?
16:22:16 <adamw> yeah, for no
16:22:17 <adamw> for now
16:22:23 <linuxmodder> sounds like  a valid blocker to me but like adamw I'd have to test some more
16:22:30 <linuxmodder> so I'm +1 punt
16:23:31 <roshi> works for me
16:23:36 * roshi was reading
16:24:20 <roshi> proposed #agreed - RHBZ#1452866 - Punt - It's still not 100% clear what the impact of this issue is, and we'll wait to determine blocker status until we have more information.
16:24:29 <adamw> ack
16:24:29 <jkurik> ack
16:24:39 <kparal> ack
16:24:40 <roshi> #agreed - RHBZ#1452866 - Punt - It's still not 100% clear what the impact of this issue is, and we'll wait to determine blocker status until we have more information.
16:24:48 <roshi> #topic (1450638) [abrt] gnome-font-viewer: gtk_header_bar_pack(): gnome-font-viewer killed by signal 11
16:24:51 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1450638
16:24:53 <roshi> #info Proposed Blocker, gnome-font-viewer, ON_QA
16:25:52 <kparal> I think I reproduced this one as well, very simple
16:25:54 <kparal> +1
16:26:12 <linuxmodder> not something I use but can see it being an issue
16:26:31 <adamw> sure, seems pretty 'basic functionality' to me
16:26:32 <adamw> +1
16:26:37 <jkurik> +1
16:26:43 <pschindl_wfh> +1
16:26:46 <jkurik> it seems to be already fixed anyway
16:27:21 <linuxmodder> in what package ? jkurik
16:28:01 <roshi> proposed #agreed - RHBZ#1450638 - AcceptedBlocker - This bug is a violation of the following Final criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:28:23 <jkurik> linuxmodder: I mean it is waiting for karma https://bodhi.fedoraproject.org/updates/FEDORA-2017-1d5ee3c3a7
16:28:35 <linuxmodder> jkurik, will check hat out
16:28:51 <jkurik> roshi: ack
16:29:09 <adamw> ack
16:29:09 <linuxmodder> took 2 weeks to get a +3  yikes
16:29:26 <kparal> ack
16:29:26 <Kevin_Kofler> Hmmm, now that I think of it, isn't the dnfdragora bug a blocker under this criterion even if we decide that Discover is the "default package manager" on KDE Plasma?
16:29:46 <roshi> #agreed - RHBZ#1450638 - AcceptedBlocker - This bug is a violation of the following Final criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:29:53 <kparal> he's correct
16:29:59 <roshi> Kevin_Kofler: seems like
16:30:12 <kparal> we should know our criteria better :)
16:30:14 <adamw> Kevin_Kofler: fair point
16:30:15 <linuxmodder> you can launch kde form sddm too so yeah makes sense
16:30:18 * roshi still wonders why a GUI for dnf is shipped, but hey, it's not my spin :)
16:30:23 <adamw> where's that dog-in-a-tie meme
16:30:23 <kparal> so we can go back to it and ack it
16:30:28 <Pharaoh_Atem> it should technically be fixed
16:30:47 <Pharaoh_Atem> the dnf guys fixed dnfdaemon, which I merged and released
16:31:06 <roshi> #topic (1454854) DNF progress.start() broken with 2.5.0, breaking dnfdaemon (and dnfdragora)
16:31:06 <Pharaoh_Atem> then they reverted their change, which besser82 applied downstream to dnfdaemon
16:31:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1454854
16:31:06 <Pharaoh_Atem> fixing it again
16:31:06 <roshi> #info Proposed Blocker, dnfdaemon, ON_QA
16:31:07 <roshi> ok, back to the bug in question
16:31:17 <roshi> under that criterion, I can be +1
16:31:21 <roshi> if it ships by default
16:31:37 <kparal> +1
16:32:01 <adamw> yep, +1 too
16:32:11 <jkurik> +1 makes sense
16:32:39 <pschindl_wfh> +1
16:32:50 <roshi> proposed #agreed - RHBZ#1454854 - AcceptedBlocker - Because this ships by default on KDE, it's a violation of the following criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:32:55 <kparal> ack
16:32:57 <dgilmore> +1 FE
16:33:01 <pschindl_wfh> ack
16:33:03 <jkurik> ack
16:33:12 <dgilmore> afaik it does not ship on any release blocking media
16:33:18 <Pharaoh_Atem> KDE
16:33:27 <Pharaoh_Atem> it ships in KDE, LxQt, and Cinnamon
16:33:28 <adamw> dgilmore: it's on KDE.
16:33:31 <Pharaoh_Atem> at least KDE is blocking
16:33:36 <dgilmore> okay
16:33:46 <roshi> #agreed - RHBZ#1454854 - AcceptedBlocker - Because this ships by default on KDE, it's a violation of the following criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:34:01 <roshi> #topic (1451914) [abrt] gnome-shell: GjsMaybeOwned<JS::Value>::trace(): gnome-shell killed by signal 6
16:34:04 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1451914
16:34:07 <roshi> #info Proposed Blocker, gnome-shell, NEW
16:35:01 <roshi> +1 under the same criterion
16:35:26 <kparal> I think we can fit it to the default panel functionality
16:35:28 <adamw> hum
16:35:32 <adamw> don't we have another report of this?
16:35:38 <adamw> i'd say the 'data loss' criterion
16:36:02 <kparal> see comment 18
16:36:15 <kparal> data loss is even better
16:36:26 <adamw> i was thinking of https://bugzilla.redhat.com/show_bug.cgi?id=1450639
16:36:42 <jkurik> +1, watching a movie is an important activity which should not be interrupted by gnome-shell crash
16:36:58 <adamw> heh
16:37:17 <kparal> the first one has more crashes in FAF
16:37:56 <adamw> so, thinking about it, i can be +1 to any commonly-encountered gnome-shell crash so long as gnome-shell crashing takes down the desktop under Wayland
16:38:01 <adamw> they keep saying they're gonna fix that but they haven't yet
16:38:07 <adamw> so, this seems to have lots of reports, so +1
16:38:12 <kparal> +1
16:38:34 <roshi> under the default functionality or data-loss criterion?
16:38:44 <roshi> I'm unsure of what "lost all data" means
16:39:47 * roshi assumes session data
16:39:53 <roshi> open docs and whatnot
16:40:09 <adamw> yea
16:40:11 <adamw> i think so
16:40:31 <adamw> i mean, we could even call it 'basic functionality' for gnome-shell, really
16:40:31 <jkurik> I would prefer the "default functionality" one, just because it fits better according to my feeling
16:40:32 <roshi> which, to me, is *technically* data loss, but not in the "oh noes!" tone it tends to be seen as
16:40:40 <adamw> it shouldn't be possible to crash the damn shell by playing a video
16:40:48 <roshi> yeah, true
16:40:53 <adamw> jkurik: which one do you mean specifically?
16:41:01 <roshi> no video has killed my i3wm setup!
16:41:21 <roshi> All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test.
16:41:25 <roshi> is my vote
16:41:47 <jkurik> adamw: yeah, this one ^^^
16:41:53 <adamw> sure
16:41:54 <jkurik> roshi: thanks, you were faster
16:41:58 <roshi> np
16:42:00 <adamw> we can even mention multiple criteria
16:42:02 <adamw> no law against it
16:42:03 <adamw> :P
16:42:05 <roshi> already had it open
16:42:47 <roshi> proposed #agreed - RHBZ#1451914 - AcceptedBlocker - This bug is a violation of a few criteria, but notably "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:43:02 <jkurik> ack
16:43:05 <adamw> ack
16:43:28 <kparal> ack
16:43:29 <roshi> #agreed - RHBZ#1451914 - AcceptedBlocker - This bug is a violation of a few criteria, but notably "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:43:40 <roshi> #topic (1455673) GNOME Software should make sure system is current on updates before upgrading to new release
16:43:43 <linuxmodder> with roshi  on this
16:43:43 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1455673
16:43:46 <roshi> #info Proposed Blocker, gnome-software, NEW
16:44:00 <kparal> oh look
16:44:13 <kparal> we just talked about this
16:44:32 <linuxmodder> lol
16:44:55 <kparal> is mattdm travelling through time?
16:45:02 <roshi> probably
16:45:07 * roshi suspects he's a bot as well
16:45:24 <roshi> so many people working in fedoraland don't seem to be human in their efforts
16:45:28 <jkurik> should not this be a Feature request, instead of a blocker bug ?
16:45:32 <kparal> the bots wars were already won by adamw
16:45:49 <adamw> nah, the puiterwijk cloud has me beat
16:45:53 <roshi> seems legit
16:46:01 <adamw> in general this feels a bit feature request-y, yeah
16:46:03 <roshi> this doesn't really violate any criteria
16:46:08 <adamw> but there is the context of the libdb issue
16:46:27 <roshi> sticking strictly to the intent of this meeting, I have to say -1
16:46:37 <jkurik> yes, I see the context as well... but ...
16:46:56 <roshi> since that's not really the purpose of the meeting, and I don't think we should use this meeting as the means to fix this particular issue
16:47:00 <kparal> we can't really mandate this, I think. we can block upgrade issues, or we can demand some solution. be it written instructions, ehm ehm...
16:47:31 <jkurik> -1 (sorry mattdm)
16:47:36 <roshi> FESCO could
16:48:22 <adamw> yeah
16:48:39 <adamw> right, i think the appropriate thing for this would be for FESCo to use its blocker wand or make it a prioritized bug
16:48:42 <roshi> I agree with the bug (I honestly thought that would be the default)
16:48:48 * kparal also notes https://bugzilla.redhat.com/show_bug.cgi?id=1336435
16:49:10 <kparal> let's propose it for a prioritized bug
16:49:14 <kparal> anyone remembers how?
16:49:53 <roshi> I SUMMON THEE FESCO!
16:49:55 * roshi waits
16:50:01 <roshi> er
16:50:04 * sgallagh pops in
16:50:05 <roshi> I SUMMON THEE, FESCO!
16:50:13 <roshi> just needed the comma
16:50:18 <adamw> did you sacrifice the rubber chicken?
16:50:18 <kparal> should I dupe it to 1336435 right away?
16:50:30 <roshi> it's a dupe, so I'd say yeah
16:50:32 <roshi> I did
16:50:40 <jkurik> +1 to dup
16:50:42 <sgallagh> https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process
16:50:44 <roshi> complete with vegan vegetable blood
16:52:40 <jkurik> I am +1 to mark both bugs as duplicates and then propose it as Prioritized (I can do the proposal then)
16:52:45 <kparal> ok, I just duped it and proposed it as prioritized
16:52:52 <roshi> proposed #agreed - RHBZ#1455673 - RejectedBlocker - This bug doesn't violate any criteria, and is therefore non-blocking. While we agree with the intent, we'll propose this as a PrioritizedBug for review (as that seems the more appropriate venue).
16:53:02 <roshi> thanks kparal
16:53:05 <kparal> ack
16:53:21 <adamw> ack
16:53:48 <jkurik> ack
16:53:54 <roshi> #agreed - RHBZ#1455673 - RejectedBlocker - This bug doesn't violate any criteria, and is therefore non-blocking. While we agree with the intent, we'll propose this as a PrioritizedBug for review (as that seems the more appropriate venue).
16:54:02 <roshi> #topic (1433884) SELinux is preventing (fwupd) from 'mounton' accesses on the directory /var/lib/fwupd.
16:54:05 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1433884
16:54:07 <roshi> #info Proposed Blocker, selinux-policy, NEW
16:54:31 <jkurik> btw: it gets immediatelly rejected as Prioritized bug by robatino
16:54:46 <adamw> i don't think he can do that...
16:54:57 <jkurik> I mean the #1336435 - why ?
16:55:08 <adamw> "orry about that. I just wanted to subscribe and didn't get the usual "mid-air
16:55:08 <adamw> collision" prompt."
16:55:31 <jkurik> ah, ok...
16:55:40 <kparal> I figured
16:55:48 <kparal> re-added it
16:55:55 <roshi> what're we talking about now?
16:55:57 <roshi> last bug?
16:56:16 <kparal> yeah. let's go to the current one
16:56:29 <kparal> so, no proposal, no information when this happens
16:57:10 <adamw> well, we had
16:57:11 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1429341https://bugzilla.redhat.com/show_bug.cgi?id=1429341
16:57:19 <adamw> which this is listed as a 'possible dupe' of, at two removes
16:57:39 <adamw> and indeed this was filed with 3.13.1-246 (while the fix was in 3.13.1-247)...
16:58:33 <jkurik> right, looks like duplicates and already fixed
16:58:49 <kparal> so, punt and ask to re-test
16:58:56 <adamw> sure
16:59:28 <roshi> for the current selinux bug?
16:59:42 * roshi lost track of who was talking about what there
16:59:47 <jkurik> yes, for the 1433884
17:00:41 <roshi> proposed #agreed - RHBZ#1433884 - Punt - It looks like this is already fixed. Please retest and update the bug.
17:01:06 <kparal> ack
17:01:06 <jkurik> patch
17:01:11 <adamw> ack
17:01:20 <roshi> go for it jkurik you have chair
17:01:39 <jkurik> proposed #agreed - RHBZ#1433884 - Punt - It looks like this is already fixed in build 3.13.1-247. Please retest and update the bug.
17:01:46 <roshi> ack
17:01:51 <jkurik> just to give a bit more info where to look for the fix
17:02:14 <roshi> you can go ahead and to the #agreed after the acks
17:02:22 <jkurik> #agreed - RHBZ#1433884 - Punt - It looks like this is already fixed in build 3.13.1-247. Please retest and update the bug.
17:02:35 <roshi> #topic (1449643) Running groupadd produces AVC denials about net_admin and write to system_dbusd_var_run_t
17:02:38 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1449643
17:02:40 <roshi> #info Proposed Blocker, selinux-policy, POST
17:04:08 <adamw> if it happens during an install of workstation, +1
17:04:35 <roshi> yeah
17:04:43 <kparal> I saw it several times during dnf install. but one of my comments says it happened during installation, so I guess I have to trust myself
17:05:01 <roshi> dangerous game, that
17:05:05 <roshi> trusting yourself
17:05:31 <roshi> proposed #agreed - RHBZ#1449643 - AcceptedBlocker - This bug violates the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:05:38 <jkurik> ack
17:06:30 <kparal> I wonder if I might have installed something prior to running installation
17:07:00 * kparal shrugs
17:07:08 <adamw> eh, we can downgrade it later
17:07:09 <adamw> ack
17:07:19 <roshi> #agreed - RHBZ#1449643 - AcceptedBlocker - This bug violates the following criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:07:25 <roshi> #topic Open Floor
17:07:28 <roshi> that's it for blockers
17:07:44 <roshi> I don't see a reason to go through proposed FEs since we're not close to Final Freeze
17:07:51 * kparal nods
17:08:03 * jkurik agrees
17:09:01 <adamw> agreed
17:09:06 <roshi> anything else?
17:09:13 <adamw> not from me
17:09:19 * roshi sets the fuse...
17:09:21 <roshi> 3...
17:09:25 <jkurik> more coffee for roshi
17:09:30 <roshi> yup yup
17:09:42 <roshi> couple tablespoons of butter, some cinnamon
17:11:09 <roshi> 2...
17:11:11 <roshi> 1...
17:11:15 <roshi> thanks for coming folks!
17:11:18 <roshi> #endmeeting