16:00:11 <roshi> #startmeeting F23-blocker-review
16:00:11 <zodbot> Meeting started Tue Sep 22 16:00:11 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:11 <roshi> #meetingname F23-blocker-review
16:00:11 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:00:11 <roshi> #topic Roll Call
16:00:23 <roshi> who's around for some blockery goodness?
16:01:21 * satellit_e listening
16:01:36 * adamw is blockeriffic
16:01:41 <sgallagh> I'm in an all-day meeting so I can't really participate, but if my input is specifically needed, please ping me
16:01:53 <adamw> sgallagh: what did you do to deserve this
16:02:09 <sgallagh> adamw: It's the middle day of three all-day meetings
16:02:11 * roshi can't tell if adamw thinks it's a prize or a punishment
16:02:28 * tflink is around
16:02:29 <danofsatx> meh
16:02:33 <roshi> #chair adamw satellit_e tflink sgallagh danofsatx
16:02:33 <zodbot> Current chairs: adamw danofsatx roshi satellit_e sgallagh tflink
16:02:36 <sgallagh> adamw: I suspect I may have committed an atrocity in a past life.
16:02:38 * danofsatx is cleaning out inbox
16:03:00 <roshi> well, we have 5 proposed blockers
16:03:12 <roshi> !
16:03:18 <roshi> I almost forgot the boilerplate
16:03:20 <roshi> #topic Introduction
16:03:20 <roshi> Why are we here?
16:03:20 <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:25 <roshi> #info We'll be following the process outlined at:
16:03:27 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:30 <roshi> #info The bugs up for review today are available at:
16:03:32 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:35 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:37 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:03:40 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:03:43 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:03:46 <roshi> might have boiled over w/o that plate in place
16:03:49 <roshi> ok, first up:
16:03:51 <roshi> #topic (1263677) it's very easy to end up with a partially-upgraded system
16:03:54 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263677
16:03:57 <roshi> #info Proposed Blocker, dnf-plugin-system-upgrade, NEW
16:04:17 <adamw> what would we do without boilerplate
16:04:53 <roshi> not sure if we couldn't boil, or if we'd get boiled
16:04:55 <roshi> tbh
16:05:23 <tflink> the boilers would explode and we'd all die in a horrible, steamy accident, methinks
16:05:55 * satellit_e use --best to test first ?
16:06:08 <adamw> i don't want to bikeshed the ideal fix here, but i do think something needs fixin'
16:06:14 * roshi is still reading the tome
16:06:16 <sgallagh> This needs to go to FESCo
16:06:17 <adamw> the current behaviour doesn't strike me as shippable
16:06:19 * tflink is also still reading
16:06:27 <adamw> but yeah, fesco might be a good way to go with it at this point
16:07:23 <roshi> +1 to going to fesco
16:07:46 <tflink> same here
16:07:54 <roshi> +1 blocker, with a note to send it to fesco on how to get fixed
16:08:43 <roshi> also, notice pschindl isn't here to secretarialize... how convenient for him :p
16:09:04 <tflink> we're also missing jan
16:09:35 <tflink> so much for pschindl "sending" him in his place :)
16:09:36 <danofsatx> +1
16:10:13 <tflink> +1 blocker, send to fesco for decision on which way to fix this - for clarity in logs
16:10:36 <roshi> proposed #agreed - 1263677 - AcceptedBlocker Final - This bug is a conditional violation of the following Beta criterion: "The upgraded system must meet all release criteria." This bug is serious enough that we think it needs to be discussed by fesco to find a solution.
16:10:41 <adamw> ack
16:10:45 <adamw> well, patch
16:10:59 <adamw> it's not so much seriousness as just the fact that it's kind of a policy decision not just a technical issue
16:11:32 <adamw> we don't send bugs like 'this crashes all systems everywhere' to FESCo for discussion, so clearly the issue isn't how serious it is :)
16:11:37 <roshi> proposed #agreed - 1263677 - AcceptedBlocker Final - This bug is a conditional violation of the following Beta criterion: "The upgraded system must meet all release criteria." This bug brings up some policy questions that we think should be discussed by fesco to find a solution.
16:11:48 * mclasen___ doesn't see how policy can make much of a difference if there's a wild mix of 3rd party software on the system
16:12:08 <roshi> it always used to work, and dnf changed that
16:12:32 <adamw> well, it depends on what you mean by 'work'
16:12:43 <adamw> mclasen___: the policy is about what's the appropriate thing to do when the tool encounters that situation
16:13:35 <mclasen___> do you really need policy to tell you that its best to tell the user "this may not work, we've found things on your system that we may not be able to upgrade cleanly. here they are:..."
16:14:05 <adamw> mclasen___: and if it's an unattended run?
16:14:20 <tflink> ack
16:14:35 <adamw> etc, anyway
16:14:37 <adamw> it's not our problem :)
16:14:41 <adamw> ack
16:14:44 <roshi> #agreed - 1263677 - AcceptedBlocker Final - This bug is a conditional violation of the following Beta criterion: "The upgraded system must meet all release criteria." This bug brings up some policy questions that we think should be discussed by fesco to find a solution.
16:14:53 <roshi> #topic (1245838) Upgrade to F23 crashes early in upgrade boot
16:14:53 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1245838
16:14:53 <roshi> #info Proposed Blocker, fedup, MODIFIED
16:16:29 <adamw> hum, what's this doing here.
16:16:44 * roshi was just wondering that
16:16:56 <adamw> wwoods reopened it to track getting rid of upgrade.img files
16:17:00 <adamw> i guess it still had blocker metadata
16:17:24 <adamw> so i guess we could evaluate whether we think 'repos still have upgrade.img' is a blocker
16:17:47 <adamw> i'm gonna go with -1, so long as dnf-plugin-system-upgrade is stable for all supported releases the upgrade.img files aren't gonna cause any problems, just sit there and waste space on mirrors.
16:18:27 <tflink> yeah, doesn't seem like a blocking issue to me
16:18:57 <roshi> -1
16:19:03 <roshi> he readded the final blocker
16:19:09 <Southern_Gentlem> there does need to be something to tell people not to use fedup
16:19:09 <roshi> it was beta blocker
16:20:09 <adamw> Southern_Gentlem: dnf-plugin-system-update obsoletes fedup and provides a /usr/bin/fedup .
16:20:38 <roshi> proposed #agreed - 1245838 - RejectedBlocker Final - This bug seems to be resolved for end users. Providing that dnf-plugin-system-upgrade is stable for all supported releases, there's no reason to keep this as a blocker (upgrade.img files won't cause problems in that case).
16:20:59 <adamw> ack
16:21:26 <tflink> ack
16:21:36 <roshi> #agreed - 1245838 - RejectedBlocker Final - This bug seems to be resolved for end users. Providing that dnf-plugin-system-upgrade is stable for all supported releases, there's no reason to keep this as a blocker (upgrade.img files won't cause problems in that case).
16:21:43 <roshi> #topic (1264904) "Log out" from gnome-shell causes complete system lock-up
16:21:46 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1264904
16:21:49 <roshi> #info Proposed Blocker, gnome-shell, NEW
16:22:13 <tflink> sounds blockery to me, +1
16:22:22 <roshi> +1
16:23:55 <danofsatx> +1
16:24:00 <roshi> proposed #agreed - 1264904 - AcceptedBlocker Final - This bug violates the following Beta criterion: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops."
16:24:11 <tflink> ack
16:25:01 <adamw> er, hold a bit
16:25:30 <adamw> ok, not the one i was thinking of. +1,  i guess (has anyone confirmed this?)
16:25:37 <danofsatx> ack
16:25:38 <roshi> I haven't
16:25:47 <roshi> #agreed - 1264904 - AcceptedBlocker Final - This bug violates the following Beta criterion: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops."
16:26:09 <roshi> can today while I futz with atomic for the test day
16:26:33 <roshi> #topic (1263570) Selinux prevents system from rebooting after update to new policy
16:26:36 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263570
16:26:39 <roshi> #info Proposed Blocker, selinux-policy, NEW
16:27:53 <tflink> +1 assuming it's still valid
16:28:00 <adamw> meh
16:28:11 <adamw> i'd want more details
16:28:23 <adamw> is this actually going to affect fresh installs, which are gonna start out with the newer policy?
16:28:40 <tflink> sounds like no
16:28:40 <adamw> i'm not sure there's anything to be done to 'address' this on frozen media, i'd want that clarified before being +1
16:28:48 <roshi> if it's not paired with a systemd update, shouldn't this package reload systemd when it's installed?
16:29:14 <roshi> just curious
16:29:38 <adamw> roshi: i think this was one *specific case*, it's not just 'every selinux-policy update requires a systemd daemon reload'
16:29:49 <adamw> but i don't think there's enough info in the bug to be 100% certain, that's just my inference
16:30:18 <roshi> I took it as "because it's not coupled with a systemd update" to mean this package ought to take that into account when installing
16:30:20 <tflink> yeah, it sounded like it was a "no systemd update and new policy affected systemd"
16:30:28 <roshi> but I guess there's no way to for them to know that
16:30:47 <roshi> does systemd reloads hurt something?
16:30:49 <adamw> roshi: i was just reading it as 'these two specific updates should've been done together but weren't, oops'
16:31:01 <roshi> oh, yeah
16:31:04 <roshi> I can see that
16:31:10 <adamw> roshi: i think it's safe.
16:31:18 <adamw> anyhow, my vote on this is 'punt;'
16:31:25 <roshi> I can live with that
16:31:27 <roshi> punt
16:31:40 <tflink> punt++
16:32:30 <roshi> proposed #agreed - 1263570 - Punt Final - We'd like some more information on if this bug is still an issue before we vote on it.
16:32:59 <tflink> ack
16:33:25 <adamw> ack
16:33:54 <roshi> #agreed - 1263570 - Punt Final - We'd like some more information on if this bug is still an issue before we vote on it.
16:34:05 <roshi> #topic (1264872) Fedora 23 Workstation x86_64 Beta-1 fails to boot
16:34:08 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1264872
16:34:11 <roshi> #info Proposed Blocker, xorg-x11-drv-nouveau, NEW
16:34:33 <tflink> more info needed, I think
16:35:09 <roshi> yeah
16:35:27 <roshi> I feel like if this was widespread we'd have caught it in testing
16:35:34 <danofsatx> This needs confirmed. I've got an nvidia GPU, I'll see if I can boot Beta tonight.
16:36:06 <Southern_Gentlem> live or what iso?
16:36:14 <danofsatx> in other news, there is a video memory leak in nouveau on F22, but only in Plasma. I don't know if this is also in 23 yet.
16:36:21 <roshi> it's if a monitor is connected to a dock
16:36:29 <tflink> Southern_Gentlem: workstation live
16:36:31 <roshi> and nouveau drivers I'd wager
16:36:44 <Southern_Gentlem> tflink, installing now in a vm
16:36:54 <roshi> nouveau (at least on my machine) can't run the external monitors (HDMI/DisplayPort)
16:37:03 <roshi> I use the nvidia blobs because of that
16:37:15 <tflink> Southern_Gentlem: not sure a VM would catch this, sounds hardware related - specifically graphics
16:37:20 <danofsatx> mine can. I'll hook it up to a display at school in ~4 hours and test it then.
16:37:24 <adamw> probably system specific
16:37:30 <roshi> +1 more info
16:37:46 * adamw is typing this on one of two monitors plugged into an NVIDIA adapter, so.
16:37:49 <danofsatx> anyhow, +1 punt to gather info before decision.
16:37:52 <tflink> especially with a less-common adapter
16:38:28 <roshi> proposed #agreed - 1264872 - Punt Final - We need some more information to determine how hardware specific this is.
16:38:38 <danofsatx> ack
16:38:51 <tflink> ack
16:39:31 <roshi> #agreed - 1264872 - Punt Final - We need some more information to determine how hardware specific this is.
16:39:41 <roshi> that's it
16:39:47 <roshi> #topic Open Floor
16:39:52 <roshi> anyone have anything?
16:41:03 <adamw> don't think so
16:41:11 <adamw> was anyone secretarializing or shall I do it?
16:41:32 <roshi> hasn't been determined yet
16:42:06 <tflink> I've not been doing it
16:42:48 * roshi sets the fuse...
16:43:39 <Southern_Gentlem> tflink, well at least it it boots and installs and boots in a vm we know it works to that point
16:44:09 <roshi> 3...
16:44:35 * adamw will secretarialize
16:44:45 <adamw> Southern_Gentlem: we do test it to *that* point before releasing it, believe it or not =)
16:45:15 <tflink> Southern_Gentlem: always good to confirm that but I think that there'd be some whisky-revocation coming if beta didn't boot and install in a VM :)
16:46:08 <roshi> 2...
16:46:10 <Southern_Gentlem> adamw,  i know but sometimes change when herding cats
16:46:11 <roshi> thanks adamw
16:46:30 <roshi> 1...
16:46:35 <roshi> thanks for coming folks!
16:46:38 <roshi> #endmeeting