16:05:38 #startmeeting f19final-blocker-review-3 16:05:38 #meetingname f19final-blocker-review-3 16:05:38 #topic Roll Call 16:05:39 Meeting started Wed Jun 5 16:05:38 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:39 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:05:39 The meeting name has been set to 'f19final-blocker-review-3' 16:05:56 * brunowolff is here 16:07:35 #chair adamw kparal 16:07:35 Current chairs: adamw kparal tflink 16:07:37 * jreznik_ is here but needs a minute to refresh a bit 16:08:56 * nirik notes that freenode is splitting a lot, so zodbot might not be too happy at points. 16:09:39 funsies. 16:09:57 adamw fires tflink 16:11:18 * kparal here 16:12:43 did we lose tflink? 16:13:48 define lose 16:14:01 looks like we have enough people to get started 16:14:07 #topic Introduction 16:14:12 Why are we here? 16:14:12 #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 freeze exception bugs. 16:14:17 #info We'll be following the process outlined at: 16:14:17 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:14:22 #info The bugs up for review today are available at: 16:14:22 #link http://qa.fedoraproject.org/blockerbugs/current 16:14:27 #info The criteria for release blocking bugs can be found at: 16:14:27 #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria 16:14:29 #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria 16:14:32 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 16:14:35 #info Up for review today, we have: 16:14:47 #info 9 Proposed Blockers 16:14:47 #info 12 Accepted Blockers 16:14:47 #info 11 Proposed Freeze Exceptions 16:14:47 #info 14 Accepted Freeze Exceptions 16:16:00 if there are no objections, we'll get started with the proposed blockers 16:16:30 oh, any volunteers for secretarialization? 16:18:44 I guess I can do it after the meeting if nobody volunteers 16:18:48 #topic (971046) GError: Timeout was reached 16:18:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=971046 16:18:48 #info Proposed Blocker, anaconda, NEW 16:19:30 seems like a blocker to me, although it's unclear on cause really... 16:19:42 * adamw will secretarialize 16:19:45 sorry, call o' nature 16:19:47 some network issue. 16:19:49 adamw: thanks 16:19:57 do we want to go with the 'old' or 'new' criteria for today? did anyone get time to take a look at the new? 16:20:09 * tflink didn't realize that the new ones were up 16:20:11 sadly I didn't 16:20:21 two interfaces on the same net? hum. 16:20:30 but the changes description sounded reasonable 16:20:37 i wouldn't want to +1 this without some more info 16:20:45 i've used ks'es on http servers extensively without issue 16:21:01 it looks like they have eth0/eth1 on the same net with the same gateway, etc. 16:21:07 so it's likely confusing nm 16:21:10 * kparal is still opening bz 16:21:14 though not with final tc1 yet, admittedly 16:21:28 * nirik is ok with punt for more info. 16:21:28 tflink: i sent out a mail late last night 16:22:00 adamw: yeah, I just saw it 16:22:19 * adamw grabbing final tc1 images to check this 16:23:43 yeah, I bet this is due to the multiple network connections 16:24:05 * tflink wonders if one of them isn't working or if something ks related just can't handle multiple interfaces 16:24:20 well, two interfaces on the same net like that has never worked has it? 16:24:52 why not? 16:24:58 why wouldn't it work, rather 16:25:06 what interface does it use to talk to the gateway? 16:25:38 There are ways of specifying which interface to use. I don't know what the default would be. 16:26:01 are there use cases for this other than teaming? 16:26:04 arp would also be confused since the local machine has both, so each interface would say it could be used to talk to the other. 16:26:19 perhaps it works these days, but it never did in the past. ;) 16:27:12 so punt for more info? 16:28:11 re-test w/ one interface and get clarification on whether this config is valid 16:28:23 sure. 16:28:55 seems like a plan 16:29:59 proposed #agreed 971046 - We're not sure that this is a valid setup with multiple network interfaces on the same network and with the same gateway. Investigate whether or not this configuration is valid and supported, request re-testing with a single network interface 16:30:10 ack 16:30:14 ack 16:30:55 ack 16:31:09 Though even if it was supposed to be supported and it is the cause, it probably doesn't affect enough people to be a blocker. 16:31:10 #agreed 971046 - We're not sure that this is a valid setup with multiple network interfaces on the same network and with the same gateway. Investigate whether or not this configuration is valid and supported, request re-testing with a single network interface 16:31:26 #topic (965883) "Use network login..." button in user creation spoke entirely broken 16:31:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=965883 16:31:31 #info Proposed Blocker, anaconda, NEW 16:31:47 has there been enough bikeshedding on devel@ to come to a better conclusion here? 16:32:04 Based on the list discussion, I don't think this should be a blocker. 16:32:14 * nirik nods. seems not. 16:32:21 although if it doesn't work, perhaps it should just be removed? 16:33:07 the feeling I was getting was that it isn't really expected to work ATM and would likely take a while to get working 16:33:22 In that sense maybe there is a blocker action. Instead of making it work, make it go away or obvious that it doesn't work. 16:33:57 that makes sense to me 16:34:16 if it doesn't work and we know it doesn't work, there probably shouldn't be a button for it 16:34:24 yeah, i was hoping for a bit more volume of discussion, but so far it's suggesting -1. 16:34:43 adamw: -1 for removing the button or for making it work? 16:34:45 that's true, but i'm still not sure we should block final release if the non-functional button is still there on day T-2 16:34:55 -1 for 'making it work' as a blocker 16:35:59 so we can block on removing the button, FE on removing the button, reject as blocker or punt for more discussion on devel@ 16:36:47 if we do punt, I'd like to set a deadline for next week so that we don't keep re-visiting this 16:36:49 * jreznik would not block on removing the button, FE sure 16:37:16 My vote is FE on hiding the button unless there is criteria that says all visible buttons should work, in which case it is really should be a blocker. 16:37:52 if the button just doesn't do anything, I'm not as worried about it 16:39:30 yep, it does not look good but I'm definitely -1 to block on the button removal 16:39:46 and FE to make it actually do something would be even better :) 16:39:53 so ... thoughts on which option to take? 16:40:12 FE for fix-or-replace works for me. 16:41:34 proposed #agreed 965883 - RejectedBlocker AcceptedFreezeException - This doesn't violate any F19 release criteria and thus is rejected as a release blocking bug for F19 final. However, a tested fix to either hide/remove the button or make it work properly would be considered after freeze. 16:42:36 ack/nak/patch? 16:42:52 ack 16:43:25 ack 16:44:04 ack 16:44:15 acl 16:44:17 #agreed 965883 - RejectedBlocker AcceptedFreezeException - This doesn't violate any F19 release criteria and thus is rejected as a release blocking bug for F19 final. However, a tested fix to either hide/remove the button or make it work properly would be considered after freeze. 16:44:22 #topic (966761) storage configuration failed: Not enough free space on disks for automatic partitioning 16:44:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=966761 16:44:27 #info Proposed Blocker, anaconda, NEW 16:45:17 there hasn't been a whole lot of movement here since the last time we reviewed it 16:46:05 it's smelling like a blocker, though 16:46:19 assuming that it isn't isolated to this particular system, anyways 16:48:15 we can re-punt for now and see if we can get someone to reproduce it 16:48:23 again, for now anyways 16:50:25 I think we want to keep tracking this, so punting while waiting for more feedback sounds good. 16:50:43 does anyone have access to a system with multipath storage? 16:51:05 a system like that which they can test with? 16:51:28 even better, a PA system with multipath storage they can test installs with 16:51:55 anyhow, I'm going with punt due to the overwhelming number of opinions and thoughts 16:52:33 proposed #agreed 966761 - We still need more information on whether this is a common problem or isolated to a single system/setup - will revisit when there is more information available 16:52:51 punt for now, adding to my todo to ask RTT in the office if they have such configuraiton 16:53:00 ack 16:53:20 I imagine that the storage folks do, not sure if the systems are in beaker, though 16:54:10 #agreed 966761 - We still need more information on whether this is a common problem or isolated to a single system/setup - will revisit when there is more information available 16:54:14 #topic (966761) storage configuration failed: Not enough free space on disks for automatic partitioning 16:54:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=966761 16:54:20 #info Proposed Blocker, anaconda, NEW 16:55:09 #info still waiting for re-testing by reporter 16:55:35 #info will re-visit when more testing information is available 16:55:38 #topic (961500) After upgrade to Fedora 19 I can no longer use Gnome 16:55:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=961500 16:55:44 #info Proposed Blocker, gnome-session, ON_QA 16:58:07 huh, I wonder if my HP laptop would show this 16:58:09 definitely +1, this one's nasty 16:58:25 tflink: seems like HP laptops are one of the big affected constituencies indeed 16:58:29 soo, with the new kernel and gnome-bluetooth installed, the session doesn't start? 16:58:53 I haven't been using it much lately, so I could have just missed the updates that are causing problems 16:58:54 is it hw specific? 16:59:33 somewhat, but the impact's wide enough and bad enough that we'd definitely want it fixed 16:59:41 sounds like it is limited to specific bluetooth devices 16:59:49 kparal: with the new kernel *but not the new gnome-bluetooth* it fails 17:00:11 the new gnome-bluetooth fixes it 17:00:19 +1 blocker 17:00:39 yeah +1 17:00:56 "kernel 3.9 added some new RFKILL_TYPE enum types, but gnome-bluetooth's rfkill code only handles the older types" 17:01:13 i'm a little surprised it isn't considered a kernel API break, but meh. 17:01:24 proposed #agreed 961500 - AcceptedBlocker - Violates the following F19 alpha release criteria for some bluetooth hardware: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot." 17:01:45 ack 17:01:54 ack 17:03:53 ack 17:03:56 moustache ack 17:04:10 #agreed 961500 - AcceptedBlocker - Violates the following F19 alpha release criteria for some bluetooth hardware: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot." 17:04:22 #topic (960230) nss forgets about CAs intermittently (frequently after suspend) 17:04:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=960230 17:04:28 #info Proposed Blocker, p11-kit, MODIFIED 17:04:54 probably +1 on this, at least +1 FE 17:05:37 it's pretty sucky for the lives, yeah 17:05:46 and it doesn't seem to always need a suspend to trigger it 17:05:52 bit borderline, but i guess i'd lean +1 17:05:56 some of the guys were netsplitted 17:06:03 at least in my session 17:06:18 yeah, we lost half the people 17:06:38 * tflink fails to understand why one would ddos freenode 17:07:40 is that what's going on? that stinks. 17:07:44 I'm not sure about blocker status, +1 FE for sure 17:07:48 for the lulz, I guess 17:08:19 bad topic 17:08:57 I don't mind +1 blocker 17:09:03 adamw: yeah, there have been some messages from freenode admins talking about a ddos 17:09:14 the web browser behaves incorrectly 17:09:25 #topic (960230) nss forgets about CAs intermittently (frequently after suspend) 17:09:56 robatino was seeing the same changing back of topic in #fedora-qa yesterday 17:10:02 hopefully it doesn't keep happening 17:10:27 it sounds like we're more +1 than -1, though? 17:10:42 I agree that it's borderline - the workaround isn't bad 17:11:06 yeah, i'm not really that strongly on either side of the fence 17:11:12 * adamw sits on fence, chews grass straw 17:11:24 jreznik, brunowolff: thoughts? 17:11:41 it just seems like bad form to release something that could have troubles with our own web sites 17:11:41 ah, we are back together (listening to team meeting) 17:12:46 that's a good point, but with my 50% probability of successfull resume after suspend... 17:13:00 Sorry I thought I was on the wrong side of a net split and went for snacks. 17:13:16 brunowolff: you were for a bit but we got re-joined 17:13:37 jreznik: it doesn't seem limited to suspend 17:14:18 I guess I think if the issue just results in some popups, that seems more FE. But if this actual makes things fail I'd be more inclined to vote blocker. 17:14:52 jreznik: right, last time it happened to me wasn't immediately after a resume, i don't think 17:14:53 tflink: I hit it too - not sure what lead to it to be honest, I expect suspend - but I'm more FE, it's easy to workaround and I hope we will get fix 17:15:13 brunowolff: it depends on what you think of as fail - what would you do if your browser started saying that fp.o domains weren't trusted? 17:15:52 so we're OK with live media that could have this bug in it? 17:16:35 I have that happen with sites on a regular basis as I don't trust any of the CAs. I auth certs by site. 17:16:35 brunowolff: well it basically means https just doesn't work right. but the 'workaround' is simple enough - quit and restart 17:17:12 With the centralized cert stuff couldn't this affect more than web browsers? 17:17:34 if yum used https, it could cause problems with updates 17:17:35 well, given that the bug turns out to be in p11-kit, i guess it could affect anything that uses that. 17:17:36 tflink: if it would be only related to suspend, I'd be ok with that for live - how many people suspend live session, if suspend is not the only starter of the bug, I'm more "fix it" 17:18:44 conditional accept, then? 17:18:56 if it isn't just suspend, blocker. otherwise, FE? 17:19:24 tflink: I'd be ok with this condition 17:19:29 conditional 17:19:30 i think we're gilding the lily a bit given that an update's been submitted already 17:19:35 let's just pick something and move on 17:19:50 adamw: ok, fe, then? 17:19:52 * satellit_e default for lives should be screensaver off and no suspend 17:20:15 satellit_e: you wish 17:20:20 : ) 17:20:27 fe, sure. 17:20:33 adamw: depends if the update really fixes the issue :) 17:20:39 we can always throw blocker at it later if somehow the fix doesn't fix it and it turns out to be terrible. 17:20:40 but I'm ok with FE for now 17:21:13 proposed #agreed 960230 - RejectedBlocker AcceptedFreezeException - While this is a conditional violation of the F19 release criteria, we feel that suspending a livecd is an uncommon activity and thus, the issue isn't enough to justify blocking release. However, a tested fix would be considered after freeze. 17:22:42 ack/nak/patch? 17:22:53 we miss a third type of blocker - an update must be pushed stable before release 17:23:07 I'd vote for that 17:23:23 ack 17:23:26 ack 17:23:36 ack 17:23:36 kparal: not sure I understand what you're getting at 17:23:57 tflink: that it doesn't have to be fixed on the media, but the freshly installed system should not suffer by this 17:24:19 that would be ideal resolution of this bug 17:24:23 *my 17:24:42 hopefully, the update will fix the issue - we can revisit if it turns out to be a bigger problem 17:24:49 yep, move on 17:24:51 (freshly installed system including 0-day updates, I wanted to say) 17:25:01 How do you know if an update will be in stable by the release when we make the go live decision? 17:25:14 brunowolff: you just have to Make It So 17:25:18 brunowolff: in updates-testing with enough karma 17:25:25 or what adamw said 17:25:38 i wouldn't really support that kinda thing for the actual release we're testing, it's enough of a hack for the 'fix needed in previous release' case 17:26:01 #agreed 960230 - RejectedBlocker AcceptedFreezeException - While this is a conditional violation of the F19 release criteria, we feel that suspending a livecd is an uncommon activity and thus, the issue isn't enough to justify blocking release. However, a tested fix would be considered after freeze. 17:26:15 bah, I missed an ack that I was waiting for 17:26:17 But then the criteria would be about some condition at the point of the go live decision, not at the point of release. 17:26:23 #topic (968778) SELinux is preventing /usr/sbin/killall5 from using the 'sys_ptrace' capabilities. 17:26:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=968778 17:26:29 #info Proposed Blocker, selinux-policy, MODIFIED 17:27:32 proposed #agreed 968778 - AcceptedBlocker - Violates the following F19 final release criterion: " In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ" 17:27:39 ack 17:28:06 ack 17:28:53 ack 17:28:55 #agreed 968778 - AcceptedBlocker - Violates the following F19 final release criterion: " In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ" 17:29:02 #topic (965749) X's smart scheduler is crashy on ppc64 17:29:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=965749 17:29:03 #info Proposed Blocker, xorg-x11-server, ON_QA 17:30:27 -1/+1 17:30:47 proposed #agreed 965749 - RejectedBlocker AcceptedFreezeException - Bugs limited to secondary arch(es) are not release blocking bugs but can be FreezeExceptions. As this is a severe problem in multiple secondary arches, a tested fix would be considered after freeze/ 17:30:52 proposed #agreed 965749 - RejectedBlocker AcceptedFreezeException - Bugs limited to secondary arch(es) are not release blocking bugs but can be FreezeExceptions. As this is a severe problem in multiple secondary arches, a tested fix would be considered after freeze. 17:30:57 punctuation change 17:31:12 ack 17:31:13 ack 17:31:51 ack 17:31:59 #agreed 965749 - RejectedBlocker AcceptedFreezeException - Bugs limited to secondary arch(es) are not release blocking bugs but can be FreezeExceptions. As this is a severe problem in multiple secondary arches, a tested fix would be considered after freeze. 17:32:06 #topic (955236) [abrt] yum-3.4.3-83.fc20: cli.py:1945:removeGroups:AttributeError: 'InstalledGroup' object has no attribute 'groupid' 17:32:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=955236 17:32:11 #info Proposed Blocker, yum, MODIFIED 17:32:44 no comment from reporter(s) or dev 17:33:40 reject or punt again? 17:33:42 My opinion is that this is still just FE material. 17:34:11 i'm ok punting again - we only punted on monday 17:34:11 brunowolff: I think we were aiming for the safe side, looking for confirmation that the yum internals weren't corrupted when the failure occured 17:34:35 Oh yeah. I hadn't forgotten that part of the discussion. 17:34:56 #info still waiting for input from devs or reporters on whether there is yum corruption when the failure occurs 17:35:34 Though rebuilding the rpmdb isn't that hard, it isn't going to be known by most users. On the other hand very few people really want to remove groups. 17:35:51 proposed #agreed 955236 - Still waiting for input from devs and/or reporters, if there is no response by next week, will reject as a blocker if the update has not been pushed stable by then. 17:36:13 hrm, that could have been phrased better 17:36:19 oh well, it gets the point across 17:36:23 ack/nak/patch? 17:36:47 ack 17:36:51 ack 17:38:03 ack 17:38:05 #agreed 955236 - Still waiting for input from devs and/or reporters, if there is no response by next week, will reject as a blocker if the update has not been pushed stable by then. 17:38:16 OK, that's all of the proposed blockers on my list 17:38:27 moving on to the proposed FEs for anaconda 17:38:45 yay 17:38:51 since anaconda's special like that 17:39:07 #topic (963059) Anaconda on Fedora 19 doesn't have option for setup HOSTNAME and NETWORK layout 17:39:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=963059 17:39:13 #info Proposed Freeze Exceptions, anaconda, POST 17:39:31 +1 17:39:54 radek's been working on this for a bit 17:39:58 i've been following it 17:40:34 is this livecd only? 17:41:23 Do we really want to pull this in after the freeze? 17:41:48 brunowolff: we're playing anaconda's game of "we won't work on anything unless it's a FE or blocker" 17:43:23 so it's more of an abuse of the blocker/FE process than anything 17:43:28 yes 17:43:34 er, yes it's live only 17:43:40 Is this something we'd rather work on than other things that we'd want in before freeze? 17:43:51 so the problem is that on lives we don't show the network spoke on the basis you should use the 'host desktop' to configure the network 17:44:03 but the 'hostname' option, which is kind of an important one, is on the network spoke 17:44:19 it's kinda weird to tell people to set the hostname of their live session in order to set the hostname of the installed system, plus GNOME's hostname setting stuff sucks 17:44:42 this fix would a) let people set hostname for live installs and b) explain to them to use the host desktop's network configuration stuff to configure the network 17:44:49 it's really an improvement 17:44:57 +1 17:44:59 brunowolff: the patch is already written 17:45:56 proposed #agreed 963059 - AcceptedFreezeException - This is an improvement to the hostname and network configuration for live installs and a fix would be appreciated. 17:45:57 OK. If it comes in not too late it would be OK. 17:46:03 ack 17:46:10 #agreed 963059 - AcceptedFreezeException - This is an improvement to the hostname and network configuration for live installs and a fix would be appreciated. 17:46:24 #topic (965832) No password strength indicator for root password 17:46:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=965832 17:46:24 #info Proposed Freeze Exceptions, anaconda, MODIFIED 17:46:52 brunowolff: as tflink said, we're accommodating the anaconda devs here: they've decided they want anaconda to be 'frozen' all the way from beta release and they want us to evaluate anaconda FEs throughout that whole period 17:47:02 that's why we're making a special effort to cover anaconda FEs 17:47:27 adamw: you phrased it more nicely than I did, though :) 17:48:01 +1 17:48:19 yeah, +1, this will make things more robust if anything 17:48:28 having all the dialogs that do password entry do it the same way is a much better idea 17:48:35 Ah. It still seems weird that we would be controlling their work that way. 17:48:42 +1 17:48:43 +1 Fe 17:48:46 proposed #agreed 965832 - AcceptedFreezeException - Consistency in password evaluation during the install process is a good thing and a fix would be appreciated. 17:48:51 ack 17:50:15 brunowolff: welp, it's what they wanted, so hey. 17:51:29 ack 17:51:48 what else are we going to say? "no, we don't want anything between beta and final?" 17:52:08 * tflink assumes ack from adamw 17:52:14 #agreed 965832 - AcceptedFreezeException - Consistency in password evaluation during the install process is a good thing and a fix would be appreciated. 17:52:18 eh, i'd be prepared to -1 some things. if i was running anaconda team i'd just figure we should make the calls ourselves, but hey, i'm not. 17:52:30 oh, iswym. 17:53:23 it sounds like our choices are: 1) play the game or 2) no non-blocking or non-fe fixes in anaconda before f20 17:53:27 we chose 1) 17:53:31 anyhow, moving on 17:53:36 #topic (970077) DeviceSettingsNotFoundError: DeviceSettingsNotFoundError('wlp1s0',) (noipv6 + wiireless card -> crash) 17:53:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=970077 17:53:41 #info Proposed Freeze Exceptions, anaconda, POST 17:54:01 +1 FE if not too late. 17:54:04 bah, I skipped one 17:54:09 will go back after this one 17:54:31 Oops. I was assuming we were doing the next one. I may change my vote since we skipped. 17:58:18 +1 fe 17:58:30 maybe we should have a test case for that 17:58:56 we have quite a few missing test cases really 17:59:01 i'm going to work on that next cycle 17:59:31 proposed #agreed 970077 - AcceptedFreezeException - While installing with wireless isn't as common during pre-releases, it is something that will be important post-release. A tested fix would be considered after freeze. 17:59:37 ack 18:01:36 ack 18:03:14 #agreed 970077 - AcceptedFreezeException - While installing with wireless isn't as common during pre-releases, it is something that will be important post-release. A tested fix would be considered after freeze. 18:03:20 again, assuming ack from adam 18:03:32 ack 18:03:33 sorry 18:03:45 the other anaconda FE doesn't have a fix yet, do we want to go through it anyways? 18:04:45 let's take a look 18:04:59 ok, we;ve been skipping it so far 18:05:01 #topic (869364) Installation Destination screen is sometimes rendered not at full screen width 18:05:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=869364 18:05:07 #info Proposed Freeze Exceptions, anaconda, ASSIGNED 18:05:21 I think if we got a fix not too late into the freeze we'd want it. 18:06:12 It's also not clear of the partial fix got in yet. 18:06:43 If that does fix some cases, we may want that even if there isn't a real fix. 18:07:14 didn't we do this one on monday? eh. i'm still +1. it's a really obvious issue and can have practical consequences (it's really hard to work with a spoke squished into 25% of its intended size) 18:08:30 proposed #agreed 869364 - AcceptedFreezeException - While not a release blocking issue, it is difficult to work in a spoke that is squished into 25% of its intended size and a tested fix would be considered after freeze. 18:09:29 ack 18:10:17 ack 18:10:45 ack 18:10:52 #agreed 869364 - AcceptedFreezeException - While not a release blocking issue, it is difficult to work in a spoke that is squished into 25% of its intended size and a tested fix would be considered after freeze. 18:11:09 OK, that's all of the anaconda-proposed FEs on my list 18:11:27 moving on to the accepted blockers not ON_QA 18:12:31 any objections to also skipping the blocker we accepted on monday? 18:12:38 blockers 18:13:02 At least leave it til the end. 18:13:13 #topic (959677) IndexError: list index out of range 18:13:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=959677 18:13:13 #info Accepted Blocker, anaconda, ON_QA 18:13:19 skip 'em unless there's something obvious to discuss 18:13:23 ...ON_QA? 18:13:26 bah 18:13:30 #undo 18:13:30 Removing item from minutes: 18:13:32 #undo 18:13:32 Removing item from minutes: 18:13:34 #undo 18:13:34 Removing item from minutes: 18:13:41 #topic (968915) Anaconda locks user account instead of creating it password-less 18:13:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=968915 18:13:46 #info Accepted Blocker, anaconda, POST 18:13:52 not much to say here 18:14:04 #info fix will be in next anaconda build 18:14:42 ayup 18:14:47 #topic (964586) Anaconda does not isntall ntfs tools to allow OS-Prober to find windows partition and therefore creates no grub.cfg entry 18:14:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=964586 18:14:53 #info Accepted Blocker, anaconda, NEW 18:15:25 #info this has been confirmed with a minimal install alongside windows 18:15:38 #info devs are looking into it, nothing needed from us at this time 18:17:06 ah, here we go. my 'r' word comment 18:17:19 #topic (968951) g-i-s created user's accounts and settings are copied to new users created after g-i-s completes but before a reboot 18:17:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=968951 18:17:24 #info Accepted Blocker, gnome-initial-setup, NEW 18:17:42 #info upstream is aware of the issue, is discussing it 18:17:50 #link https://bugzilla.gnome.org/show_bug.cgi?id=701100 18:17:52 working on fixes, actually 18:17:59 we should probably have something soon 18:18:11 #info still waiting on a fix, nothing for us to do at this time 18:19:09 #topic (958426) 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB) 18:19:12 #link https://bugzilla.redhat.com/show_bug.cgi?id=958426 18:19:15 #info Accepted Blocker, LiveCD, ASSIGNED 18:19:30 #info this is an auto-blocker - there have been added packages since beta 18:20:01 #info it appears that parties responsible for the desktop spin are aware of the issue. we assume that they are working on a fix 18:20:24 #topic (968936) SIGSEGV of packagekit-offline-update.service during update 18:20:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=968936 18:20:29 #info Accepted Blocker, PackageKit, NEW 18:20:47 it looks like this might have gotten worse than we thought 18:21:18 right, i just couldn't get it to work at all 18:21:36 i recall mclasen mentioned in passing that he was asking hughsie to look at the PK blockers (this and the one for the online updater) 18:21:38 according to https://bugzilla.redhat.com/show_bug.cgi?id=968936#c , this might not be just another incarnation of 'gpg-keys-aren't-imported' 18:21:55 #info this appears to be more broken than we originally thought 18:22:07 #info devs are aware of the issue and are working on it 18:22:53 anything else to add? 18:23:18 that's about all I got 18:23:20 #topic (966795) DeviceCreateError: ('lvcreate failed for fedora_sharpie00/swap: running lvm lvcreate -L 6160m -n swap --config devices { filter=["r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|"] } fedora_sharpie00 failed', 'fedora_sharpie00-swap') 18:23:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=966795 18:23:27 #info Accepted Blocker, python-blivet, ASSIGNED 18:23:47 #info no movement on this in bug 18:24:06 i'll poke dlehman and make sure he remembers this one 18:25:39 it sounded like he knew what was wrong like 2 weeks ago 18:25:58 #info no known patch yet but it sounded like devs knew how to fix 18:26:27 #info will follow up with anaconda devs to see what is going on 18:26:53 and that would be the last accepted blocker for today unless someone thinks I shouldn't have skipped one that I did 18:27:07 * tflink skipped anything that was ON_QA or didn't seem worth discussing right now 18:27:30 either due to accepting on monday or to ongoing devel/triage activity 18:27:42 awesome 18:27:53 otherwise, it's time for ... 18:27:57 #topic Open Floor 18:28:11 Anything that should be covered today in-meeting? 18:29:37 not really... 18:29:48 oh, on that kickstart bug, hamzy says it happens even with just a single interface 18:29:54 so we should probably check that out and see if it's hitting us too 18:31:14 yeah, have there been any ks reports for TC1? 18:32:37 anyhow, I think it's time to set a fuse 18:35:43 ayup 18:36:25 Thanks for coming, everyone! 18:36:30 * tflink will send out minutes shortly 18:36:34 #endmeeting