16:00:19 #startmeeting F24-blocker-review 16:00:19 Meeting started Mon May 23 16:00:19 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:19 The meeting name has been set to 'f24-blocker-review' 16:00:19 #meetingname F24-blocker-review 16:00:19 The meeting name has been set to 'f24-blocker-review' 16:00:19 #topic Roll Call 16:00:27 ahoyhoy, who's around for blocker review fun? 16:00:30 * kparal is here 16:00:34 * omiday is here 16:00:49 * omiday will mostly listen 16:01:18 * coremodule is here. 16:01:28 less listening! more voting! 16:01:32 well, i guess listening AND voting is okay. :P 16:01:42 okay okay :) 16:02:06 danofsatx: nirik: ping 16:02:20 we seem to be running with 0 pschindls 16:02:22 satellit: sgallagh: tflink: ping 16:02:28 * nirik is in another meeting, but what do you need? 16:02:36 the pschindl valve is on empty? oh noes! 16:02:46 nirik: it's a blocker meeting, what do we always need 16:02:55 * tflink can be around for 2 hours 16:03:02 +1 to block all the things! :0) 16:03:37 * adamw nails tflink to the floor 16:03:41 ok, that sounds like enough to move on with 16:03:46 #chair kparal tflink 16:03:46 Current chairs: adamw kparal tflink 16:03:52 who's gonna secretarialize? 16:03:57 adamw: I guess I'm here too 16:03:59 adamw, I'll do it. 16:04:06 But I apologize if I disappear randomly. 16:04:09 * adamw tapes sgallagh to the wall 16:04:11 *in advance 16:04:13 now no-one call the cops 16:04:20 #info coremodule to secretarialize 16:04:22 coremodule: thanks! 16:04:32 adamw, np 16:04:33 #topic Introduction 16:04:34 Why are we here? 16:04:34 #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:04:34 #info We'll be following the process outlined at: 16:04:34 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:04:35 #info The bugs up for review today are available at: 16:04:37 #link http://qa.fedoraproject.org/blockerbugs/current 16:04:39 #info The criteria for release blocking bugs can be found at: 16:04:41 #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria 16:04:43 #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria 16:04:45 #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria 16:04:47 wheeee, who doesn't love boilerplate 16:05:00 OK, here we go with proposed Final blockers 16:05:01 #topic (1337731) Live image compose fails with dnf 1.1.9 16:05:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=1337731 16:05:01 #info Proposed Blocker, anaconda, NEW 16:05:45 Hey, y'all, I'm probably going to be mostly spectating 16:06:03 All lives aren't building? Isn't that an auto-blocker? 16:06:52 the offending dnf is not stable yet 16:06:55 hi, pirate 16:07:01 so this isn't technically a blocker yet 16:07:15 but it's at +2 and i'm not reading igor as being particularly keen on holding it up... 16:07:16 ah 16:08:09 So I guess, conditional blocker? We vote +1 now and if DNF goes stable, it automatically promotes? 16:08:42 that, or we punt it for a week and see where we're at then... 16:08:51 Wouldn't this just mean we don't push dnf to stable? 16:09:45 The sea-dog makes a valid point. Should we just all negkarma the dnf update? 16:09:47 oh 16:10:26 sorry, that oh wasn't meant for this channel 16:10:39 sgallagh: that's an option. 16:10:55 sounds like the most simple option to me 16:10:59 i'd prefer it, but people are throwing +1s at the update and igor is all 'oh well someone else should fix it'. 16:11:02 so, i dunno. 16:11:19 So, I do think I agree with the reasoning of the dnf folks, it's a bit late in the release cycle to be doing this sort of change 16:13:07 anyhow, we need a discussion 16:13:13 so i kinda like sgallagh's idea of 'conditional blocker' 16:13:15 definitely not -1 either way 16:13:23 s/discussion/decision/ 16:13:24 works for me 16:13:31 would everyone be +1 if this update went stable? 16:13:37 +1 blocker if the dnf update goes stable 16:13:39 /me would 16:13:41 +1 16:13:50 * kparal nods 16:14:17 alright 16:14:18 adamw: I would be, yes 16:14:20 +1, yes. 16:14:32 adamw: I also just added -1 karma to the update 16:15:21 proposed #agreed 1337731 - conditional AcceptedBlocker (Final) - the dnf update is not yet stable, but there seems to be a possibility that it will be pushed stable. If it does go stable with no fix for this bug in any other component, this bug can be marked as an AcceptedBlocker due to obvious violation of criteria by preventing release-blocking images from composing 16:15:38 ack 16:15:52 ack 16:16:04 ack 16:16:09 #agreed 1337731 - conditional AcceptedBlocker (Final) - the dnf update is not yet stable, but there seems to be a possibility that it will be pushed stable. If it does go stable with no fix for this bug in any other component, this bug can be marked as an AcceptedBlocker due to obvious violation of criteria by preventing release-blocking images from composing 16:16:17 #topic (1336810) Calligra Words crashed when I opened a template. 16:16:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=1336810 16:16:17 #info Proposed Blocker, calligra, VERIFIED 16:17:08 +1 blocker 16:17:14 (looks like it'll be fixed soon, yay) 16:17:49 +1 16:18:26 Pedantic: are templates "basic functionality" for Calligra? 16:18:34 +1 16:18:41 sgallagh: I would say so 16:18:58 i'd say they're pretty basic for anything office-y 16:19:06 i think you have to pick a template when creating a new document, no? 16:19:13 aye 16:19:15 sgallagh: by default when you start it up it presents you with the template screen 16:19:17 /me has never used that tool 16:19:23 OK, then +1 blocker 16:19:32 +1 16:19:38 +1 16:20:13 proposed #agreed 1336810 - AcceptedBlocker (Final) - clear violation of cited 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:20:29 ack 16:20:32 ack 16:20:39 ack 16:20:47 ack 16:21:49 ack 16:22:12 #agreed 1336810 - AcceptedBlocker (Final) - clear violation of cited 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:22:22 #topic (1336879) dnf fails to respect conditional level in comps.xml 16:22:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=1336879 16:22:23 #info Proposed Blocker, dnf, NEW 16:22:26 oh whee, more comps fun 16:22:31 why have we not shot comps in the head y et 16:22:52 adamw: We have, but unfortunately it's not a Romero-style undead. 16:23:00 heh 16:23:05 someone pass me the wooden stake 16:23:33 adamw: Unfortunately, I think we're dealing with a lich. 16:23:40 no-one's cited a reason why this is a release blocker yet 16:23:49 though it sounds like it affects live image creation 16:24:10 is this the bug that prompted the fix that broke lives? 16:24:46 adamw: Yes, but the workaround is for the live images to just specify their dependencies explicitly. 16:25:22 tflink: no, i think that's a different one, about it not failing when a 'mandatory' package isn't present 16:25:32 I'm inclined to say -1 blocker and ask them to add the missing bits to spin-kickstarts for now 16:25:50 that seems reasonable... 16:25:58 (Or fix the bug, but not block on failing to do so) 16:26:11 I think this does not break compose but localization support? 16:26:24 kparal: the 'conditional' feature of comps is used for different reasons 16:26:31 g11n is one, but there are others 16:26:45 kparal: This is different from the weak deps 16:26:46 e.g. the one luya cites in the description 16:26:51 the bug says that KDE is affected 16:26:52 Which is a better solution than the comps one 16:27:40 I thought the end result of this bug that I won't have "Finnish Support" installed when I should have 16:27:41 As an aside, the effect of this bug is to actually reduce the number of things eligible to trigger the "default functionality" blocker criterion, so leaving it alone makes our jobs easier... 16:27:47 so some packages will not have Finnish help, etc 16:28:11 kparal: That may be true, but this isn't the mechanism that those packages are supposed to be using to achieve that anyway. 16:28:39 They're supposed to be using Supplements: langpack-fi 16:28:49 ok 16:29:22 i think i can go with sgallagh on this one, -1 16:29:26 (Now, whether the compose tools fully understand that is a different question; I think at the moment we're telling people to make sure they're all explicitly listed in the spin-kickstart) 16:29:42 And then they get picked up properly by DNF during install. 16:30:01 -1 blocker, +1 FE 16:31:31 I'm -1 FE as well, actually. 16:31:53 If we got to Freeze with this, I wouldn't break freeze to change how we process comps. Too risky. 16:31:56 proposed #agreed 1336879 - RejectedBlocker, AcceptedFreezeException (Final) - none of the known impacts of this appear to violate the release criteria, and any missing packages on deliverables can be resolved by adding them to spin-kickstarts until this bug is dealt with 16:32:04 hmm, point... 16:32:17 tflink: wdyt? 16:33:24 makes sense 16:33:25 -1 FE 16:34:14 proposed #agreed 1336879 - RejectedBlocker, RejectedFreezeException (Final) - none of the known impacts of this appear to violate the release criteria, and any missing packages on deliverables can be resolved by adding them to spin-kickstarts until this bug is dealt with. We also think changing this after freeze would be too dangerous for too little benefit 16:34:27 ack 16:34:34 ack 16:35:27 one more ack? 16:35:39 ack 16:35:49 ack 16:35:57 ack 16:36:00 #agreed 1336879 - RejectedBlocker, RejectedFreezeException (Final) - none of the known impacts of this appear to violate the release criteria, and any missing packages on deliverables can be resolved by adding them to spin-kickstarts until this bug is dealt with. We also think changing this after freeze would be too dangerous for too little benefit 16:36:06 * adamw drowns in flood of acks 16:36:13 #topic (1337336) gnome-software shows updates but "Restart & Install" button doesn't install them 16:36:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1337336 16:36:14 #info Proposed Blocker, gnome-software, NEW 16:36:44 * omiday throws a life vest 16:36:57 coremodule reproduced this consistently 16:37:02 FYI, Just retried this, had two other updates needed to be installed, SELinux and gnome-something and now it's working. It looks like when it only had the "OS Updates" as a selected update, it wouldn't trigger the update upon reboot, but now, with more updates, it's working. 16:37:13 I wanted to try as well, but at the moment gnome-software shows absolutely no updates for me 16:37:16 even though pkcon does 16:37:26 broken as usual 16:37:47 The two initial times I tried this, the only update on the list was "OS Updates". 16:37:55 hmm, okay 16:38:03 I have some available right now. 16:38:07 But 'dnf update' worked just fine to install it. 16:38:14 I can try if you want (but will need to disconnect for a few) 16:38:30 sgallagh: only 'OS Updates'? or others too? 16:38:48 LibreOffice, Empathy and others. 16:40:24 /me dnf updates the non-OS ones 16:40:41 as described, anyhow, I'd be +1 i think 16:41:43 I'm riding the fence here a little. 16:41:59 I mean, if the updates work when a desktop app is on the list, then sooner-or-later it's going to work. 16:42:31 well, yeah, but what if there's a security critical 0-day or something? and it's a pretty bad look if you go to do your first update and it fails. 16:43:19 Yeah, not disagreeing. 16:43:19 +1 as the behavior is inconsistent 16:43:38 I'm kind of +0.5 here. 16:44:10 Uploading a new log with the successful install now... 16:45:10 I'm also kinda +0.5, not sure this passes the "last blocker at go/no-go" test 16:45:17 then it needs more testing? 16:46:01 yeah, I'd punt and test more 16:46:32 +1 for punt w/ more testing 16:46:50 well i'm fine with punting in the hopes that it gets fixed and we don't have to care... 16:47:03 that would be closer to an ideal, yes :) 16:47:09 punt works for me 16:47:52 proposed #agreed 1337336 - punt (delay decision) - this is definitely a worrying bug but we want to be clear on the circumstances in which it does and does not occur before making a final decision 16:47:59 ack 16:48:20 ack 16:48:21 ack 16:48:38 #agreed 1337336 - punt (delay decision) - this is definitely a worrying bug but we want to be clear on the circumstances in which it does and does not occur before making a final decision 16:48:47 #topic (1338054) Fedora 24 keepassx has a lower version number it wants to upgrade a higher version package from Fedora 23 16:48:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1338054 16:48:47 #info Proposed Blocker, keepassx, NEW 16:49:08 is keepassx is any of the upgrade-blocking default package sets? 16:50:30 there does appear to be something of a mess here, though 16:50:44 there should be a reasonably easy way to figure that out, right? I don't know it 16:50:54 wasn't the update unpushed? 16:51:00 2.0.0-1.fc23 was pushed stable 16:51:12 the 0.4.4.1 update 16:51:22 er, 0.4.4-1 16:51:27 a revert to 0.4.4 was done in git and builds sent out for f22, f23 and f24 16:51:35 the reverts for f22 and f23 were pushed then unpushed 16:51:40 the revert for f24 has not been unpushed 16:51:42 #link https://fedorahosted.org/fesco/ticket/1569 16:51:44 it's not on Workstation 16:51:45 wat 16:51:48 * nb thouht limb was working on it 16:51:53 and was going to re-upgrade to 2? 16:51:58 so this is sure a big mess, but i don't know if it's a release blocker 16:52:03 It's being worked on and the approach is decided. 16:52:27 I'd definitely offer this a Freeze Exception. 16:52:28 keepassx isn't listed in comps at all afaics. 16:52:40 It's a nasty issue for anyone using keepassx 16:52:47 But -1 blocker 16:52:52 sgallagh: what's the point of giving it an FE? 16:52:58 -1 blocker 16:53:07 -1 here as well 16:53:09 adamw: Because if limb doesn't fix it by Freeze, I'm going to take over. 16:53:19 that's...not an answer? 16:53:32 +1 FE 16:53:39 Actually, good point. It doesn't need to be on the frozen set anywhere 16:53:49 well, i guess it means we can push a fix during freeze so people who do an upgrade during the freeze period but before we push 0-day updates get it. 16:53:55 I retract my FE request :-P 16:54:03 adamw, yeah 16:54:04 there is a small benefit to it actually, now i think about it. 16:54:10 OK, either way. 16:54:20 -1 blocker +1 FE 16:54:28 -1/+1 16:55:13 given that it breaks the app I'd give it a +1 FE too 16:55:13 proposed #agreed 1338054 - RejectedBlocker (Final) - this is definitely a mess but keepassx is not in any of the package sets cited in the criteria, so it does not qualify as a release blocker. It's accepted as a freeze exception issue as upgrades usually run with u-t disabled, so there is a benefit to pushing it stable between freeze date and 0-day update push date 16:55:38 ack 16:55:40 you should add AcceptedFreezeException(final) 16:55:41 ack 16:55:50 also as a workaround the user can always install f23 version 16:56:10 ack, but add AcceptedFreezeException to the #agreed 16:56:13 kparal: yep, sorry 16:56:22 proposed #agreed 1338054 - RejectedBlocker AcceptedFreezeException (Final) - this is definitely a mess but keepassx is not in any of the package sets cited in the criteria, so it does not qualify as a release blocker. It's accepted as a freeze exception issue as upgrades usually run with u-t disabled, so there is a benefit to pushing it stable between freeze date and 0-day update push date 16:56:25 ack 16:56:28 ack 16:56:28 ack 16:56:31 #agreed 1338054 - RejectedBlocker AcceptedFreezeException (Final) - this is definitely a mess but keepassx is not in any of the package sets cited in the criteria, so it does not qualify as a release blocker. It's accepted as a freeze exception issue as upgrades usually run with u-t disabled, so there is a benefit to pushing it stable between freeze date and 0-day update push date 16:56:46 coremodule: if you could add a quick note with a link to the fesco issue to lower the reporter's temperature, that'd be good 16:56:55 (the bug may also be a dupe, i guess, so check that) 16:57:05 #topic (1337582) Fails to start with "Cannot read MSR_ERROR_CONTROL from /dev/cpu/0/msr" when running in VM on Xeon E5-2450 host 16:57:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1337582 16:57:06 #info Proposed Blocker, mcelog, NEW 16:57:22 so, this is the bug that causes the 'services start' test to fail in openQA quite often 16:57:35 for context, we have rejected a similar issue for being too hardware-specific in the past: 16:57:58 https://bugzilla.redhat.com/show_bug.cgi?id=1274193 16:58:02 it if seriously decreases our test coverage, I think it's reasonable to block on it 16:58:12 we might even have it written like that somewhere 16:58:14 kparal: we can actually work around it in openqa quite well 16:58:15 adamw, sure thing. 16:58:29 kparal: garret has already written a diff for it 16:58:40 i actually nack'ed the diff on the basis that i'd rather we decide on whether the bug is a blocker or not first 16:58:48 if we think it's not a blocker, we can implement the openqa workaround 16:59:08 so the openqa test will 'soft pass' if only mcelog fails to start 16:59:55 All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present 16:59:59 so, is this the case? 17:00:02 not quite 17:00:04 well 17:00:07 it's not 100% clear 17:00:15 depends on how HW specific it is 17:00:47 i guess it may be related to the CPU emulation in qemu... 17:00:59 i was hoping to hear back from the mcelog packager /devs by now, honestly 17:01:03 is it just that generation of xeon? 17:01:06 dunno 17:01:16 all i know is it *does* happen on qa14 and does *not* happen on qa05/qa06/qa07 17:01:26 but that's exactly two CPUs we know the result for. :P 17:01:42 my inclination would be -1 or punt, i think 17:01:47 yeah 17:01:51 * kparal is for punting 17:01:54 i don't think it's quite blocker yet 17:01:57 +1 punt 17:02:16 this criterion is very suitable for rejecting 'conditional' blockers, the real idea of the criterion is to make sure we don't ship with a service that's completely broken enabled by default 17:02:28 so it kinda does have to be a very non-conditional bug to really count 17:03:29 adamw: you noted in the bug that it does start sometimes 17:03:39 omiday: it depends on the CPU. 17:04:16 proposed #agreed 1337582 - punt (delay decision) - we're inclined to think this is likely too hardware-specific to be a blocker, but we'd like to get some thoughts from mcelog packager/developers if possible, so delaying the decision to see if we hear from them 17:04:29 ack 17:04:37 ack 17:04:50 ack 17:05:26 you know, i'm wondering if it *ever* makes sense to run mcelog in a VM. but maybe best discussed in the bug. 17:05:29 #agreed 1337582 - punt (delay decision) - we're inclined to think this is likely too hardware-specific to be a blocker, but we'd like to get some thoughts from mcelog packager/developers if possible, so delaying the decision to see if we hear from them 17:05:44 #topic (1332266) systemd-logind does not verify if system has resume device defined when checking if can.hibernate or can.hybridsleep 17:05:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1332266 17:05:45 #info Proposed Blocker, systemd, ASSIGNED 17:05:56 oh yay. this bug. 17:05:58 * adamw drinks 17:06:08 my thoughts exactly 17:06:17 but it does sound like there has been some progress 17:06:30 c29 is very positive I think 17:06:41 we just need to give it go 17:06:48 and +1 FE if needed, after freeze 17:07:24 IIUIC, fedora will have a local patch for now which will improve logind autodetection and say hibernation is not available if resume= is not present 17:07:45 so there will be no misleading popups, and people can still enable resume quite easily 17:07:53 (nothing changed in that regard) 17:08:08 yeah, sounds good. 17:08:23 of course it would be nicer if the resume= was actually added correctly to all installs, but better than nothing 17:08:42 i still don't think i buy this as a blocker, personally 17:08:53 definitely +1 FE for sensible post-freeze changes 17:09:07 +1 FE here 17:09:17 do we want to avoid the blocker call? :) 17:11:05 * adamw plays limbo music 17:11:06 everybody duck! 17:11:10 +1 FE and still on the fence for blocking 17:11:11 c29 provides the fix/workaround - what criterion qualifies the bug as a blocker/FE? 17:11:30 closer to -1 than +1 on blocker 17:11:48 omiday: potential data loss, due to telling the user the system is going to be hibernated, and then not even attempting resume 17:12:04 on critical battery, that is 17:12:22 c29 patch prevents data logss 17:12:25 *loss 17:12:56 yes, but it's not in place yet 17:13:26 our job at these meetings is to decide whether bugs are blockers: unless a fix is completely in place and the bug report is closed, we should still amke the decision (or explicitly punt) 17:13:42 otherwise we can get an unfortunate case where we leave a bug alone because we think it's going to get fixed, then the fix never actually gets landed in time 17:13:45 -1 blocker 17:14:30 +1 blocker so we get the c29 patch in 17:14:33 so we have -2 blocker, +3 fe i think 17:14:41 omiday: we don't need to vote +1 blocker for the patch to land. 17:15:05 but if we take the bug as a blocker, f24 would not ship until it (or some other fix) did land. 17:15:05 ack thanks 17:15:23 if we don't take the bug as a blocker, we're saying it's OK for 24 to ship without the fix, if for some reason it doesn't get landed in time. 17:15:27 that's the difference. 17:15:27 * kparal is two minds about it 17:16:12 pick whichever mind has drunk the most 17:16:16 data loss...tells me we need the patch in so we can test before shipping it 17:16:44 adamw: let's go -1 blocker 17:18:28 proposed #agreed 1332266 - RejectedBlocker AcceptedFreezeException (Final) - we think the consequences of this are unfortunate but don't really constitute a violation of the criteria, the 'data loss' scenario is quite contrived and there is strong precedent to not considering suspend/hibernate issues as release-blocking. This is definitely significant enough to constitute a freeze exception issue, however 17:18:35 when are the FE patches made available? 17:18:43 ack 17:18:50 ack 17:19:33 omiday: FE means the fix can go stable during the freeze period. 17:19:48 the difference between 'FE' and 'blocker' is that we don't *block* the release if FEs are still outstanding at go/no-go time. 17:20:25 would an unresolved FE delay the final release? 17:20:29 no. 17:21:26 any other ack/nack/patch? 17:21:35 ack 17:22:50 I'd be frustrated to install the new release today, hibernate and wake up tomorrow with my session gone... I'm a 'patch' unless someone convinces me otherwise 17:22:59 #agreed 1332266 - RejectedBlocker AcceptedFreezeException (Final) - we think the consequences of this are unfortunate but don't really constitute a violation of the criteria, the 'data loss' scenario is quite contrived and there is strong precedent to not considering suspend/hibernate issues as release-blocking. This is definitely significant enough to constitute a freeze exception issue, however 17:23:08 omiday: the ack/nack/patch vote isn't a redux of the +1/-1 vote 17:23:21 it's only about whether the proposed #agreed accurately reflects everything we discussed 17:23:50 it was added because quite often the moderator would typo or miss something out from the #agreed, so it just adds a step for people to spot mistakes 17:24:09 it's not appropriate to vote 'nack' because you were on the minority side of the blocker/not-blocker vote 17:24:15 (or 'patch') 17:24:22 ok got it, thanks (again) 17:24:24 npnp :) 17:24:53 ok, so that's all the blockers 17:24:54 ack 17:25:00 er, proposed blockers 17:25:06 bah, misread 17:25:23 let's do a quick sweep through the accepted blockers and see where we're at... 17:25:27 #info moving on to accepted blockers 17:25:31 #topic (1318045) Incorrect keymap when decrypting encrypted partitions 17:25:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1318045 17:25:32 #info Accepted Blocker, anaconda, NEW 17:25:40 we probably need to upload more logs for this 17:25:53 we know basically what's going on, it's just a question of co-operative debugging to figure out the underlying causes 17:26:11 #info we need QA and anaconda team to work together and isolate the underlying causes here, more logs may be needed 17:26:22 any other notes? 17:26:27 * kparal agrees 17:28:07 #topic (1333998) After Russian install, console keymap is 'us', not 'ru' 17:28:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1333998 17:28:07 #info Accepted Blocker, anaconda, NEW 17:28:22 kinda similar story, we have a rough idea what's going on and need to isolate why and what the fix should be... 17:28:28 at least the relevant people are all involved i think 17:28:58 #info once again this one needs more investigation from both qa and anaconda side, might need to pin down last time it worked (if ever) 17:29:11 well...i'm pretty sure it worked sometime. 17:29:31 https://bugzilla.redhat.com/show_bug.cgi?id=1164492 17:29:32 grrr 17:31:06 alrighty, next one 17:31:13 #topic (1164492) Please drop libvirt 'default' network dependency for F24 GA, disrupts livecd networking 17:31:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1164492 17:31:13 #info Accepted Blocker, gnome-boxes, NEW 17:31:25 #info looks like this will get done soon, though there's ongoing discussion about how to fix the bug better 17:32:27 anything else? 17:33:36 alrighty 17:33:41 #topic (1320273) chainloading bootmgr.efi on UEFI results in error: out of memory 17:33:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1320273 17:33:42 #info Accepted Blocker, grub2, NEW 17:34:09 this one's a little worrying 17:34:18 i'll take an action to ping pjones and mjg59 about it 17:34:27 #info there has been no movement on this for some time 17:34:36 #action adamw to ping pjones and mjg59 about this bug 17:35:40 #topic (1293167) [abrt] kf5-kinit: qt_message_fatal(): kdeinit5 killed by SIGABRT 17:35:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1293167 17:35:41 #info Accepted Blocker, kf5-kinit, NEW 17:36:17 i'm wondering if we might want to re-evaluate this in light of https://bugzilla.redhat.com/show_bug.cgi?id=1293167#c23 ... 17:36:19 any thoughts? 17:36:57 * omiday reading... 17:38:49 it appears that we need to ping Rex 17:38:53 * kparal brb 17:39:35 everyone has it running but the most-important-user ;) 17:41:18 c15 confirmed the bug on Apr-3 - have there been any updates since then? 17:41:22 well, i guess we don't really have enough people to re-consider it at present, but we can keep an eye and think about it later... 17:41:26 omiday: yes. that's what i linked to. 17:41:42 omiday: what i linked to is a comment where rex said he asked on some mailing lists and most people who replied said it worked. 17:42:29 adamw: so is everyone on the list running the same stack as Rex and Giulio? If so, why did their tests fail? 17:43:02 I've got the KDE VM from calligrawords test - could give it a shot... 17:43:14 i dunno. i just work here. 17:43:22 okay, well, let's just #info it and move on 17:43:53 #info there hasn't been a lot of movement in terms of fixing this bug, but some further testing suggests it may not be as clearly reproducible as first thought, we may consider re-evaluating it later 17:44:01 #topic (1333106) Server deployment fails due to SELinux policy changes on current Fedora Rawhide and F24 (2016-05-21) 17:44:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=1333106 17:44:01 #info Accepted Blocker, selinux-policy, ASSIGNED 17:44:17 #info this one is being worked on by appropriate folks, and we're ready to re-test it when fixes are available 17:44:40 ok, that's all the accepted blockers... 17:45:14 #info that's all the accepted blockers, no need to do proposed FEs yet as we still have another meeting before freeze date 17:45:17 #topic Open floor 17:45:19 any other business? 17:46:26 when is the next meeting? 17:46:42 same time same place next week 17:47:29 the just so I understand how all this works: if I test https://bugzilla.redhat.com/show_bug.cgi?id=1293167 and it passes what's the process? 17:48:50 post a comment on the bug saying you tried it and it worked for you 17:49:22 adamw: ack 17:49:32 nothing else here 17:49:37 alrighty 17:49:41 i think we bored everyone else to death 17:49:45 thanks for sticking around =) 17:49:51 thanks for coming, everyone! 17:49:57 i'm off to lie around on the couch and watch tennis 17:50:08 adamw, No problemo! 17:50:12 raining? 17:50:22 lazy 17:50:45 #endmeeting