20:11:15 <roshi> #startmeeting F23-blocker-review
20:11:15 <zodbot> Meeting started Thu Oct 15 20:11:15 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:11:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:11:15 <roshi> #meetingname F23-blocker-review
20:11:15 <zodbot> The meeting name has been set to 'f23-blocker-review'
20:11:15 <roshi> #topic Roll Call
20:12:00 <roshi> heh, adamw beat me to the fedora-devel channel
20:12:08 * satellit listening
20:12:11 <roshi> who's around for some aync blocker goodness?
20:12:13 * nirik is lurking around
20:12:23 <roshi> #chair nirik satellit jpigface adamw
20:12:23 <zodbot> Current chairs: adamw jpigface nirik roshi satellit
20:12:39 <roshi> #topic Introduction
20:12:39 <roshi> Why are we here?
20:12:40 <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.
20:12:41 <adamw> this is sync
20:12:43 <adamw> it's so sync it hurts
20:12:43 <roshi> #info We'll be following the process outlined at:
20:12:46 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
20:12:46 * jpigface is still performing tests, but is listening
20:12:48 <roshi> #info The bugs up for review today are available at:
20:12:51 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
20:12:53 <roshi> #info The criteria for release blocking bugs can be found at:
20:12:56 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
20:12:59 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
20:13:02 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
20:13:05 <roshi> lol
20:13:07 <roshi> 4 proposed
20:13:13 <roshi> first up:
20:13:14 <roshi> #topic (1261569) old kernel boots by default after upgrade
20:13:14 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1261569
20:13:14 <roshi> #info Proposed Blocker, anaconda, POST
20:13:37 <adamw> so i've got a fix for this, i'm pretty sure it works, though it'd be good if others would confirm.
20:13:58 <adamw> as cmurf said, istr we accepted a bug like this in the past
20:14:00 <nirik> uh... anaconda ? upgrades?
20:14:05 * nirik reads the bug
20:14:18 <adamw> nirik: anaconda writes a wrong value to /etc/sysconfig/kernel , which causes problems when kernel updates happen
20:15:20 <nirik> ok, makes sense.
20:15:28 <roshi> yeah, I recall a bug like this being blocker
20:15:45 <adamw> the new kernel entry isn't saved to grubenv , which sometimes stops it being the default boot choice. sometimes, somehow, it still does become the default boot option, but it's definitely wrong and causes problems at least sometimes. for me it seems like UEFI installs wind up booting the old kernel, BIOS installs wind up booting the new kernel, we're theorizing that sometimes grubenv isn't read properly for some reason, and when grubenv isn't re
20:15:46 <adamw> ad properly the top entry in the list will be default so the bug is hidden...
20:15:48 <nirik> +1 whatever, we should pull it in. Blocker I guess.
20:15:57 <adamw> iirc the criterion we used before was the update criterion
20:16:06 <adamw> the argument being that updates aren't applied 'properly' if new kernels don't become the default
20:16:18 <adamw> a classic piece of criterion ninjutsu indeed
20:16:35 <roshi> it makes sense to me
20:16:36 <kalev> +1, makes sense to fix this
20:16:37 <roshi> +1
20:16:42 <roshi> #chair kalev
20:16:42 <zodbot> Current chairs: adamw jpigface kalev nirik roshi satellit
20:16:43 <adamw> note that we have an anaconda build today with all *other* blockers fixed, so this would be the sole (current known) reason to do another anaconda build'
20:16:55 <adamw> but i think it's bad enough to be worth that, especially since we still have *other* outstanding blockers
20:17:03 * roshi is fine with that
20:18:42 <roshi> proposed #agreed - 1261569 - AcceptedBlocker Final - This bug is a violation of the following Beta criterion: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." While the latest kernel is *installed*, it's not set up to be the default as it should be - which potentially leaves users without the latest
20:18:48 <roshi> security patches in the kernel.
20:18:55 <roshi> proposed #agreed - 1261569 - AcceptedBlocker Final - This bug is a violation of the following Beta criterion: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." While the latest kernel is *installed*, it's not set up to be the default as it should be - which potentially leaves users exposed.
20:19:01 <roshi> there, and it's small enough
20:19:16 <kalev> -ETOOLONGFORIRC
20:19:16 <adamw> ack
20:19:20 <kalev> ack
20:19:22 <satellit> ack
20:19:25 <jpigface> ack
20:19:26 <nirik> ack
20:19:27 <roshi> #agreed - 1261569 - AcceptedBlocker Final - This bug is a violation of the following Beta criterion: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." While the latest kernel is *installed*, it's not set up to be the default as it should be - which potentially leaves users exposed.
20:19:40 <roshi> adamw: are you going to secretarialize?
20:20:29 <adamw> sure
20:21:01 <roshi> thanks :)
20:21:02 <roshi> #topic (1269581) GNOME autologin makes boot and shutdown last 90 seconds more
20:21:05 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1269581
20:21:08 <roshi> #info Proposed Blocker, gnome-keyring, ASSIGNED
20:21:26 <adamw> halfline has a proposed fix for this hot off the press: http://koji.fedoraproject.org/koji/taskinfo?taskID=11464853
20:21:51 <adamw> i'm kinda on the fence about blocker status - on the one hand it's not really that terrible in effect, forcibly shutting down a live boot is fine, on the other hand it'd affect everyone who ever booted an f23 live forever
20:21:56 <adamw> which is a bad look
20:22:44 <roshi> true
20:22:50 <roshi> I'm +1 FE for sure
20:22:58 <roshi> not 100% sold on blocker
20:23:01 <kalev> I think it's already marked as FE
20:23:04 <roshi> about +.75
20:23:11 <jpigface> but a forced shutdown is not fine (even in live), IMHO :)
20:23:17 <roshi> yeah, it is
20:23:34 <roshi> marked an FE, I mean
20:24:11 <adamw> yeah, if i'm forced to pick i guess i'd go +1
20:24:25 <nirik> +1 blocker? or fe?
20:24:25 <jpigface> lot of non-technical reviews base their vote on things like boot times etc.
20:24:32 <adamw> blocker
20:24:40 <roshi> that's a fair point jpigface
20:24:42 <adamw> yeah, reviewers would likely kill us for it
20:24:49 <adamw> 'they couldn't even fix THIS?'
20:24:50 <nirik> yeah, I can be +1 blocker I guess.
20:24:50 * satellit not as important since persistence lo longerer works in USB's?
20:24:53 * roshi looks for the criteria
20:26:09 <roshi> so, looks like we've got 2.75+ blocker?
20:26:11 <kalev> I think I'd lean towards marking it as a blocker as well
20:26:22 <adamw> halfline: what's your take?
20:26:30 <satellit> a fix would be nice
20:26:32 <adamw> roshi: unfortunately the existing criteria are specifically tied to post-install
20:26:41 * roshi would personally just tell people to not use autologin
20:26:46 <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."
20:26:53 <adamw> roshi: autologin is used on the live images, you can't change it
20:27:07 <roshi> oh yeah
20:27:18 <adamw> so the blocker part of this bug is really 'shutting down the live image takes forever'
20:27:25 <adamw> (aiui)
20:27:27 <roshi> but kparal was talking about the popularity of the feature outside of that
20:27:33 <roshi> yeah, that's what I grokd as well
20:27:37 <adamw> true, i guess, but post-release can fix with an update
20:27:48 <adamw> to do this right i'd say we should approve in principle that we extend the shutdown requirement to installer images
20:27:56 <halfline> adamw: don't have a strong opinion
20:28:14 <adamw> we've had issues with installer images not shutting down/rebooting after install that apparently causes pain for remote deployment too iirc
20:28:27 <halfline> adamw: (but hope the fix works so the discussion is moot!)
20:28:36 * satellit seen that
20:28:41 <adamw> halfline: heh, yeah
20:29:12 <jpigface> I'm still +1 blocker, because new users (and reviewers, as noted above) often base their decisions to lives' performances.
20:29:27 <roshi> proposed #agreed - 1269581 - The practical impact of this bug is a violation of the following Beta criterion when using a live image: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops"
20:29:47 <roshi> er
20:29:58 <roshi> proposed #agreed - 1269581 - AcceptedBlocker Final - The practical impact of this bug is a violation of the following Beta criterion when using a live image: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops"
20:30:31 <kalev> ack, I think it makes sense to extend this criteria to live media
20:31:21 <roshi> as do I
20:31:39 <jpigface> kalev: +1. We're not talking about an exotic package which is crashing, we're talking about basic functionalities (IMHO)
20:31:40 <nirik> sur
20:31:41 <nirik> sure
20:31:58 <satellit> +1
20:32:01 <roshi> #agreed - 1269581 - AcceptedBlocker Final - The practical impact of this bug is a violation of the following Beta criterion when using a live image: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops"
20:32:08 <roshi> #topic (1264012) liveusb-creator doesn't create bootable Live i686 image in default cp mode
20:32:11 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1264012
20:32:13 <roshi> #info Proposed Blocker, liveusb-creator, NEW
20:32:28 <satellit> see my comment at end
20:33:00 <adamw> i was trying this just now to confirm it's the same syslinux problem as litd, but i'm not sure yet
20:33:14 <adamw> my first try seemed to fail with 'Missing operating system' which usually means the partition isn't marked bootable...
20:33:21 <satellit> results are te same from f23
20:33:37 <satellit> the*
20:34:07 <nirik> so, syslinux is still busted, news at 11?
20:34:33 <jpigface> (btw, I remember this one too: https://bugzilla.redhat.com/show_bug.cgi?id=1250712)
20:34:34 <satellit> also with nuei liveusb-creater (copr)
20:34:47 <roshi> seems so nirik
20:35:33 <nirik> well, is there any chance we can get it fixed at this point? it's been broken for a long while now... ;(
20:36:01 <satellit> disks-restore works fine as fallback
20:36:26 <kalev> has anyone who understands syslinux even looked at it?
20:36:28 <adamw> assuming this *is* the same syslinux bug, we're kinda at the mercy of upstream and possibly pjones
20:36:40 <adamw> last i checked with pjones he said he was aware of it, hadn't looked at it
20:36:44 <nirik> still 0 commits this year on upstream. ;)
20:36:50 <adamw> i did email h. peter anvin to see if he can help but did not receive a reply yet
20:37:06 <kalev> how did it regress, due to a gcc update or something I bet?
20:37:07 <adamw> nirik: eh? http://repo.or.cz/w/syslinux.git/
20:37:11 <adamw> kalev: GCC, yeah
20:37:16 <adamw> it's almost certainly GCC 5
20:37:28 <nirik> oh, thats not the repo listed on the main site...
20:37:29 <nirik> but ok
20:37:41 <kalev> if that's the case, we could probably do a ugly ugly hacky workaround by building it in a f22 chroot and submitting it as a f23 update
20:38:00 <roshi> heh
20:38:14 <adamw> ooh, that sounds horrible.
20:38:16 * nirik shudders
20:38:16 <adamw> let's do it!
20:38:19 <adamw> :P
20:38:41 <nirik> I suppose we could try git head... seems a lot of commits on that repo
20:38:51 <adamw> already done it
20:38:53 <adamw> doesn't help
20:39:16 <adamw> nirik: see my comments on the other bug - https://bugzilla.redhat.com/show_bug.cgi?id=1263988#c11
20:39:47 <nirik> ok. I wasn't aware that you had done another git head test.
20:40:20 <adamw> ooo
20:40:23 * adamw checks upstream mailing list
20:40:23 <adamw> http://www.syslinux.org/archives/2015-October/024358.html
20:40:45 <adamw> http://www.syslinux.org/archives/2015-September/024318.html
20:40:48 <kalev> ohhhh, that looks like our issue
20:40:52 <adamw> http://www.syslinux.org/archives/2015-September/024319.html
20:41:01 * adamw will test a syslinux with those patches
20:41:10 <nirik> seems possible
20:41:20 <nirik> proposal: punt for more testing? or ?
20:41:37 <adamw> it's getting a bit late to be punting, but otoh, these *would* be 'special blockers' - they don't need to hold up compose
20:41:45 <adamw> they'd be 'must be in 0-day updates' cases, i guess
20:42:08 <roshi> yeah
20:42:11 <roshi> votes?
20:42:21 <adamw> guess i'm ok with punting to monday
20:42:33 <roshi> wfm
20:43:09 <jpigface> +1. that's reasonable.
20:43:14 <kalev> yeah, I don't think it needs to be in todays TC, so fine to punt :)
20:43:27 <kalev> or any TC or RC
20:43:27 <roshi> proposed #agreed - 1264012 - Punt Final - There are some patches we'd like to take a look at before voting on this. Punting until the Blocker Review meeting on Monday (2015-10-19)
20:43:32 <satellit> +1
20:43:37 <kalev> ack
20:43:41 <nirik> ack
20:43:43 <jpigface> ack
20:43:43 <satellit> ack
20:43:51 <roshi> #agreed - 1264012 - Punt Final - There are some patches we'd like to take a look at before voting on this. Punting until the Blocker Review meeting on Monday (2015-10-19)
20:43:55 <roshi> #topic (1263988) livecd-iso-to-disk doesn't create bootable usb drive
20:43:58 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263988
20:44:01 <roshi> #info Proposed Blocker, syslinux, NEW
20:44:03 <roshi> last one
20:44:35 <roshi> proposed, I mean
20:44:54 <adamw> same as the last one
20:44:56 <kalev> same thing as in previous, I think?
20:44:57 <kalev> yup
20:45:08 * satellit same problem?
20:45:15 <adamw> we're assuming it is
20:45:25 * nirik nods.
20:45:31 <adamw> i'll build the new syslinux and see if it fixes litd, if it does, i can post it in this bug and folks can see if it solves this one too
20:45:39 <adamw> (since i never seem to have much luck with luc at all)
20:45:39 <nirik> sounds good
20:45:51 <roshi> yeah
20:45:57 <roshi> punt again?
20:46:03 * kalev nods.
20:46:06 <satellit> +1
20:46:15 <roshi> proposed #agreed - 1263988 - Punt Final - There are some patches we'd like to take a look at before voting on this. Punting until the Blocker Review meeting on Monday (2015-10-19)
20:47:06 <nirik> ack
20:47:27 <kalev> ack
20:47:30 <satellit> ack
20:47:32 <jpigface> ack
20:47:34 <adamw> ack
20:48:04 <roshi> #agreed - 1263988 - Punt Final - There are some patches we'd like to take a look at before voting on this. Punting until the Blocker Review meeting on Monday (2015-10-19)
20:48:53 <kalev> before we go on to FE's, can I bring up the gnome 3.18.1 update?
20:49:01 <roshi> go through FE's or accepted blockers?
20:49:04 <roshi> sure kalev
20:49:17 * nirik has a silly bug to mention at the end as well (or whenever)
20:49:31 <kalev> right, so it's the case again, as somehow always happens, that gnome releases a bug fix update two days after fedora goes into the freeze ...
20:50:08 <kalev> and we're in a bad situation where we should either do a massive 0 day update or do a freeze exception for this
20:50:31 <nirik> IMHO if we are going to do a freeze exception we should do it sooner rather than later.
20:50:34 <kalev> so two bad choices, and I guess we get to choose the less bad
20:50:36 <kalev> yup
20:51:05 <kalev> I would personally lean towards a freeze exception, but if we do that, I'd love to see a TC with it this week to make sure it gets proper testing
20:51:15 <kalev> I'd definitely not want to pull this in late next week or something crazy like that
20:51:23 <roshi> yeah
20:51:28 <roshi> sooner rather than later for sure
20:51:28 <nirik> right
20:51:36 <kalev> the status with builds is that the last upstream release I was waiting for, gnome-shell-extensions, was just released 5 minutes ago
20:51:37 <adamw> kalev: is there an update for it?
20:51:39 <kalev> and is building for fedora
20:51:40 <adamw> ah, ic
20:51:48 <adamw> i'm pencilling in a TC for today
20:51:50 <kalev> so there should be an update in bodhi in 30 minutes or so
20:52:19 <adamw> i'm more or less OK with an FE, though it *is* a bit later than we've previously done it, and we do have fairly complete validation for GNOME in current TCs which would be a shame to lose
20:52:20 * nirik was planning to sign and push to updates-testing after it's submitted.
20:52:51 <adamw> so far we've had a good track record with these GNOME FEs but sod's law says one of 'em is going to bite us in the ass sooner or later
20:53:18 <nirik> proposal: do a tc today without, do another tc tomorrow with...
20:53:21 <kalev> I'll be alert these days and ready to jump on any regressions that shows up
20:53:38 <adamw> nirik: sounds like a plan
20:53:46 <kalev> sure, sounds good to me
20:53:52 * adamw throws another jpigface into the test furnace
20:54:07 <nirik> then we can check the one tomorrow and if it looks ok pull into stable/rc
20:54:14 <adamw> ok ok, i promise i'll do the tests for at least *one* of the TCs. :P
20:54:26 <kalev> nirik: sounds like a good plan to me
20:54:38 <nirik> and we wouldn't want releng to have a day without a tc. ;)
20:54:57 <kalev> I'll go file a FE for this
20:54:57 <adamw> you'd get bored
20:55:09 <adamw> rgr
20:55:28 <jpigface> adamw: you know, I'm always around for release validation testing
20:55:41 <adamw> jpigface: see, we're making sure you have lots of it, aren't we kind :)
20:55:55 <jpigface> :D
20:56:30 <roshi> jpigface doesn't know that asking for more is likely to get more than was originally thought
20:56:36 <roshi> :P
20:57:42 <jpigface> ahah :D
20:57:44 <nirik> so, on to FE's ? or do people want to see the amusing bug I was going to mention?
20:57:56 * adamw is always up for amusement
20:58:05 <roshi> I'm all for an amusing bug before FEs
20:58:07 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=1271445
20:58:08 <kalev> amusement first, of course!
20:58:24 <nirik> I have no way to test this. I actually don't have any machines with cdrom drives here that are on. ;)
20:59:10 <nirik> but if this happens in f23... it could be a problem... removing the media while you are using it.
20:59:30 <roshi> yeah...
20:59:37 <roshi> not sure we have a criteria for this though...
20:59:51 <nirik> or even what is responsible here?
21:00:10 <roshi> -1 blocker, since if you yank the USB out while using it you run into the same issue
21:00:13 <roshi> :p
21:00:44 <nirik> true indeed.
21:00:51 <adamw> heh, fun.
21:01:18 <roshi> tbh, I didn't know the drive got locked before
21:01:26 <satellit> tested in f23?
21:01:39 <roshi> I just thought, "Hey, I'm using that - probably shouldn't press that button."
21:01:52 <nirik> I am pretty sure it was in the past, but like I said, I haven't used cd/dvd's in ages...
21:02:12 <roshi> when I still had spare DVDs, I would burn them for testing
21:02:19 <roshi> ran out of them last release though...\
21:02:36 <nirik> I think long ago there used to be a --memory option to livecd boots to load everything into memory so you could eject the media.
21:02:54 <nirik> ie, boot a bunch of machines with the same cd... but I think that got dropped
21:03:50 <jpigface> I'm not sure about this one... it's like cutting the ethernet cable while downloading...
21:04:18 <roshi> or throwing your main on your fuse box
21:04:19 <nirik> well, just thought I would mention it. If folks want to test it on f23 and add comment, feel free.
21:04:40 <roshi> not to mention, if drive firmware doesn't support it anymore - we might not even be *able* to fix it
21:04:41 * satellit I have a 8.1 MacbookPro here with disk eject button should test...
21:04:51 <roshi> I'd take an FE for it though I guess
21:05:23 * adamw would need more details
21:05:31 <adamw> don't even know what's supposed to be implementing locking at what level
21:05:35 <roshi> yeah, I'd still want it tested
21:05:40 <satellit> k
21:06:03 <roshi> votes?
21:06:06 <nirik> right, its all a bit unknown at this point.
21:06:21 <nirik> the orig reporter was on 22 it seems like
21:06:42 <nirik> so I am 0 for anything now, but if people could test we could propose later or not.
21:06:59 <jpigface> I certainly am -1 for blocking. FE could be reasonable, but I'm not sure.
21:07:26 <jpigface> it's not what we call a normal usage...
21:07:57 <roshi> well, we'll wait for more info and move onto FEs
21:08:04 <roshi> that work?
21:08:16 <jpigface> roshi: +1
21:08:18 <adamw> sure
21:08:25 <roshi> got 7 proposed FEs
21:08:32 <roshi> #topic (1091300) Anaconda Support for Server Roles
21:08:32 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1091300
21:08:32 <roshi> #info Proposed Freeze Exceptions, Changes Tracking, ON_QA
21:08:33 <satellit> +1
21:09:06 <adamw> given the actual scope of the FE request, +1
21:09:47 * roshi voted in bug
21:09:48 <roshi> +1
21:09:50 <nirik> +1
21:10:10 <jpigface> +1 here too
21:10:26 <roshi> proposed #agreed - 1091300 - AcceptedFreezeException Final - It would be good to get a tested fix into Final for the release.
21:11:38 <adamw> ack
21:12:12 <jpigface> ack
21:12:16 <roshi> #agreed - 1091300 - AcceptedFreezeException Final - It would be good to get a tested fix into Final for the release.
21:12:19 <roshi> #topic (1192030) Workstation LiveISO refuses to boot on Hyper-V Generation 2 VM
21:12:22 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1192030
21:12:25 <roshi> #info Proposed Freeze Exceptions, livecd-tools, POST
21:13:42 <adamw> change seems fairly safe, though, god, dracut.
21:14:45 <nirik> well, the change is in livecd-tools right?
21:15:06 <nirik> +1 FE I have no idea how popular this is, but would be good to fix.
21:15:45 <roshi> wfm, though not familiar enough to know if the patch'll work or not
21:16:04 <adamw> nirik: yes, but it's to its iteraction with dracut
21:16:09 <adamw> roshi: count yourself lucky!
21:16:31 <roshi> proposed #agreed - 1192030 - AcceptedFreezeException - It would be good to get a tested fix included during freeze.
21:16:56 <adamw> ack
21:17:01 <jpigface> ack
21:17:23 <roshi> #agreed - 1192030 - AcceptedFreezeException - It would be good to get a tested fix included during freeze.
21:17:32 <roshi> #topic (1271231) mate-compiz f23 livecd can't use new updated f23 default wallpaper
21:17:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1271231
21:17:38 <roshi> #info Proposed Freeze Exceptions, mate-desktop, NEW
21:18:01 <roshi> +1
21:18:04 <roshi> simple and clean enough
21:18:09 * roshi loves these kinds of FEs
21:18:23 <kalev> +1
21:18:29 <jpigface> :O
21:18:52 <roshi> proposed #agreed - 1271231 - AcceptedFreezeException Final - It would be good for the MATE live to have the default F23 wallpaper.
21:18:56 <satellit> +1  non-blocking required to use default ?
21:19:08 <roshi> I don't think so
21:19:13 <kalev> ack
21:19:16 <roshi> but if they want to, no reason to stop them
21:19:18 <satellit> ack
21:19:19 <kalev> (3.18.1 builds are done, FE bug filed, putting the update together now)
21:19:25 <jpigface> ack
21:19:27 <roshi> #agreed - 1271231 - AcceptedFreezeException Final - It would be good for the MATE live to have the default F23 wallpaper.
21:19:37 <roshi> #topic (1212148) Review Request: python-pyeclib - Python interface to erasure codes
21:19:40 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1212148
21:19:42 <roshi> #info Proposed Freeze Exceptions, Package Review, MODIFIED
21:21:00 * nirik voted +1 in bug
21:21:15 <roshi> ok, so this is to keep openstack-swift in F23
21:21:20 <roshi> +1, sure
21:21:31 <jpigface> since it fixes a problem related to dependencies, I'm +1.
21:21:51 <adamw> yeah, ok
21:22:06 <adamw> +1
21:22:17 <roshi> proposed #agreed - 1212148 - AcceptedFreezeException Final - It would be good to get dep issues fixed for F23 packages and keep openstack-swift in F23.
21:22:41 <jpigface> ack
21:23:01 <kalev> ack
21:23:33 <roshi> #agreed - 1212148 - AcceptedFreezeException Final - It would be good to get dep issues fixed for F23 packages and keep openstack-swift in F23.
21:23:40 <roshi> #topic (1271949) python-fiat has broken dependencies in F23 tree
21:23:40 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1271949
21:23:41 <roshi> #info Proposed Freeze Exceptions, python-fiat, MODIFIED
21:24:03 <roshi> +1
21:24:16 <jpigface> same as above, +1
21:24:18 <adamw> +1
21:24:19 <nirik> +1 here too
21:24:21 <roshi> proposed #agreed - 1212148 - AcceptedFreezeException Final - It would be good to get dep issues fixed for F23 packages.
21:24:30 <jpigface> ack
21:24:40 <kalev> ack
21:24:42 <nirik> ack
21:24:46 <roshi> er, proposed #agreed - 1271949 - AcceptedFreezeException Final - It would be good to get dep issues fixed for F23 packages.
21:24:52 <roshi> wrong bug #
21:24:59 <roshi> #agreed - 1271949 - AcceptedFreezeException Final - It would be good to get dep issues fixed for F23 packages.
21:25:03 <adamw> ack
21:25:09 <roshi> #topic (1270663) Failure to install: systemd-219-13.fc22.x86_64 was supposed to be installed but is not!
21:25:12 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1270663
21:25:15 <roshi> #info Proposed Freeze Exceptions, rpm, NEW
21:26:04 <roshi> +1
21:27:27 <adamw> why does this need to be in the frozen package set?
21:27:31 <roshi> and it looks like it's already fixed
21:28:31 <roshi> aiui, getting this fixed removes a blocker for cockpit, which is in the set
21:29:31 <adamw> it says for cockpit *development*
21:30:10 <roshi> ah
21:30:12 <roshi> right
21:30:13 <nirik> also it sounds like it might already be fixed. ;) I'd punt for more testing...
21:30:13 * adamw pings stefw
21:31:15 <adamw> that update isn't in stable
21:31:21 <adamw> and obviously won't get there unless the bug gets an FE
21:32:35 <nirik> yeah.
21:34:03 * adamw still can't quite see a justification for it as an FE though
21:34:08 <adamw> proposal - punt and ask proposer for a justification?
21:34:17 <roshi> yeah, I thought it was blocking something in cockpit for F23
21:34:21 <roshi> +1
21:34:26 <jpigface> +1
21:35:11 <roshi> proposed #agreed - 1270663 - Punt Final - We need some form of justification for why this needs an FE to move forward.
21:35:35 <jpigface> ack
21:35:37 <kalev> ack
21:35:57 <roshi> #agreed - 1270663 - Punt Final - We need some form of justification for why this needs an FE to move forward.
21:36:00 <adamw> ack
21:36:04 <roshi> #topic (1270568) smb fails to start
21:36:05 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1270568
21:36:05 <roshi> #info Proposed Freeze Exceptions, samba, ON_QA
21:36:45 <nirik> is smb on any media?
21:36:51 * nirik wishes for a pdc
21:37:03 <kalev> I suspect it's on Workstation
21:37:05 * kalev checks.
21:37:09 <jpigface> nirik: I was about to ask the same question...
21:37:24 <roshi> can be fixed with a 0day though, right?
21:37:47 * roshi hasn't seen any services (aside from rngd) fail to start on fresh installs
21:37:52 <kalev> I don't fully understand the bug, is it that smb is totally busted or is it only busted for upgrades?
21:38:01 <kalev> if it's only for upgrades then 0day is just fine
21:38:02 <roshi> and if they're updating from f22, a 0day fixes this
21:38:03 <adamw> it's not in the workstation installer tree - https://dl.fedoraproject.org/pub/alt/stage/23_TC9/Workstation/x86_64/os/Packages/s/
21:38:31 <roshi> -1
21:38:35 <jpigface> then, there is no point in having it as FE. -1
21:38:38 <nirik> side note: we should probibly kill rngd sometime. ;)
21:39:32 <roshi> proposed #agreed - 1270568 - RejectedFreezeException Final - This does affect any of the release media and can be fixed with a 0-day update for upgrades from F22. No need for an FE.
21:39:34 <adamw> i think the rngd bug got mostly fixed at some point...
21:40:03 <adamw> hold on, gimme a minute to check comps and kickstarts
21:40:16 <kalev> it's definitely not in Workstation, I just checked livecd logs
21:40:25 <kalev> but it maybe be in Server, since it's in https://dl.fedoraproject.org/pub/alt/stage/23_TC9/Server/x86_64/os/Packages/s/
21:40:43 <adamw> it's in the server DVD, yeah
21:40:53 <adamw> fedora-installer-server.ks has @smb-server , it's in that group
21:40:59 <nirik> adamw: rngd got kinda pulled into the kernel. the pkg doesn't do anything anymore and should die (as far as I last looked)
21:41:01 <adamw> so if it fails OOTB it's worth an FE
21:41:02 * adamw testing
21:42:47 * adamw should really get used to using virt-install or something one of these days
21:43:20 * roshi just ripped the virt-install guts out of testcloud
21:45:06 <adamw> just installing samba
21:45:18 <adamw> roshi: well, i mean, anything other than manually reinstalling in virt-manager :P
21:45:54 <roshi> so, being able to start from a fresh install without having to reinstall?
21:46:03 <adamw> looks like it starts up fine.
21:46:05 <roshi> backing stores!
21:46:21 <adamw> so, seems like an update-only issue, -1
21:46:25 <kalev> -1
21:46:32 <nirik> you don't have the updates-testing one do you?
21:46:38 <nirik> but sure if it's just updates -1
21:46:42 <roshi> proposed #agreed - 1270568 - RejectedFreezeException Final - This does affect any of the release media and can be fixed with a 0-day update for upgrades from F22. No need for an FE.
21:46:51 <roshi> patch
21:47:01 <roshi> proposed #agreed - 1270568 - RejectedFreezeException Final - This doesn't affect any of the release media and can be fixed with a 0-day update for upgrades from F22. No need for an FE.
21:47:06 <roshi> s/does/doesn't/
21:47:21 <jpigface> ack
21:47:23 <adamw> ack
21:47:27 <adamw> nirik: no, i turend u-t off.
21:47:29 <kalev> ack
21:47:31 <roshi> #agreed - 1270568 - RejectedFreezeException Final - This doesn't affect any of the release media and can be fixed with a 0-day update for upgrades from F22. No need for an FE.
21:47:34 <nirik> k. just checking. ;)
21:47:35 <roshi> that's all the FEs
21:47:48 <kalev> I filed one new, but not sure if you guys want to vote on it today :)
21:47:52 <roshi> #topic Open Floor
21:48:16 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=1272249
21:48:16 <roshi> wait nope
21:48:18 <roshi> #topic (1272249) Include GNOME 3.18.1 in Fedora 23
21:48:18 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1272249
21:48:18 <roshi> #info Proposed Freeze Exceptions, distribution, MODIFIED
21:48:55 <roshi> +1
21:49:05 <roshi> I'd rather get this tested no instead of after release...
21:49:12 <jpigface> +1 for sure
21:49:15 <adamw> +1 subject to the plan we agreed earlier
21:49:23 <kalev> +1
21:49:24 <nirik> +1 yeah that ^
21:49:27 <satellit> +1
21:49:30 <adamw> we'll do a TC10 without it and a TC11 with and if it looks like there are any issues with TC11 we'll back it right back out again
21:49:32 <roshi> TC w/o it first, then another the following day with it?
21:49:39 <adamw> roshi: i can request 'em both today
21:49:44 <adamw> we'll see how fast dgilmore can spit them out :)
21:50:45 <roshi> proposed #agreed - 1272249 - AcceptedFreezeException Final - It would be good to get this tested before release. We'll cut one regular TC without this change, and another with it included. If this update causes issues we'll revert to the first TC created.
21:51:04 <roshi> is that clear enough?
21:52:45 <kalev> works for me
21:52:53 <nirik> sure.ack
21:52:56 <jpigface> ack
21:53:01 <roshi> #agreed - 1272249 - AcceptedFreezeException Final - It would be good to get this tested before release. We'll cut one regular TC without this change, and another with it included. If this update causes issues we'll revert to the first TC created.
21:53:07 <roshi> alright, that's it
21:53:11 <roshi> #topic Open Floor
21:53:14 <roshi> anything else?
21:53:20 <adamw> we could do accepted blockers, but i think i'm basically on top of 'em
21:53:29 * roshi has to depart
21:53:33 * nirik too
21:53:34 <roshi> if you want to, go for it
21:53:39 * kalev three
21:53:43 <adamw> well, i dunno what the story is with https://bugzilla.redhat.com/show_bug.cgi?id=1263677
21:53:54 <adamw> but everyone's leaving, so i guess i'll figure it out on my own
21:53:58 <adamw> *weeps, grabs whisky bottle*
21:54:23 <adamw> it's just gonna be me and jpigface and satellit and they've probably got some like, actual testing to do or something
21:54:37 <adamw> oh hey!
21:54:51 <adamw> oh no, never miond.
21:54:52 <jpigface> adamw: sorry, I'm going to bed hehe
21:54:54 <roshi> guess I'll set the fuse then :p
21:54:59 <roshi> 3...
21:55:07 <kalev> night guys
21:55:21 <roshi> night
21:55:23 <roshi> 2...
21:55:27 <roshi> thanks for coming!
21:55:31 <roshi> see you all monday :p
21:55:49 <roshi> 1...
21:55:53 <roshi> #endmeeting