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