16:05:38 <tflink> #startmeeting f19final-blocker-review-3
16:05:38 <tflink> #meetingname f19final-blocker-review-3
16:05:38 <tflink> #topic Roll Call
16:05:39 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:39 <zodbot> The meeting name has been set to 'f19final-blocker-review-3'
16:05:56 * brunowolff is here
16:07:35 <tflink> #chair adamw kparal
16:07:35 <zodbot> 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 <adamw> funsies.
16:09:57 <zodbot> adamw fires tflink
16:11:18 * kparal here
16:12:43 <adamw> did we lose tflink?
16:13:48 <tflink> define lose
16:14:01 <tflink> looks like we have enough people to get started
16:14:07 <tflink> #topic Introduction
16:14:12 <tflink> Why are we here?
16:14:12 <tflink> #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 <tflink> #info We'll be following the process outlined at:
16:14:17 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:14:22 <tflink> #info The bugs up for review today are available at:
16:14:22 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:14:27 <tflink> #info The criteria for release blocking bugs can be found at:
16:14:27 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria
16:14:29 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
16:14:32 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:14:35 <tflink> #info Up for review today, we have:
16:14:47 <tflink> #info 9 Proposed Blockers
16:14:47 <tflink> #info 12 Accepted Blockers
16:14:47 <tflink> #info 11 Proposed Freeze Exceptions
16:14:47 <tflink> #info 14 Accepted Freeze Exceptions
16:16:00 <tflink> if there are no objections, we'll get started with the proposed blockers
16:16:30 <tflink> oh, any volunteers for secretarialization?
16:18:44 <tflink> I guess I can do it after the meeting if nobody volunteers
16:18:48 <tflink> #topic (971046) GError: Timeout was reached
16:18:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=971046
16:18:48 <tflink> #info Proposed Blocker, anaconda, NEW
16:19:30 <nirik> seems like a blocker to me, although it's unclear on cause really...
16:19:42 * adamw will secretarialize
16:19:45 <adamw> sorry, call o' nature
16:19:47 <nirik> some network issue.
16:19:49 <tflink> adamw: thanks
16:19:57 <adamw> 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 <kparal> sadly I didn't
16:20:21 <nirik> two interfaces on the same net? hum.
16:20:30 <kparal> but the changes description sounded reasonable
16:20:37 <adamw> i wouldn't want to +1 this without some more info
16:20:45 <adamw> i've used ks'es on http servers extensively without issue
16:21:01 <nirik> it looks like they have eth0/eth1 on the same net with the same gateway, etc.
16:21:07 <nirik> so it's likely confusing nm
16:21:10 * kparal is still opening bz
16:21:14 <adamw> though not with final tc1 yet, admittedly
16:21:28 * nirik is ok with punt for more info.
16:21:28 <adamw> tflink: i sent out a mail late last night
16:22:00 <tflink> adamw: yeah, I just saw it
16:22:19 * adamw grabbing final tc1 images to check this
16:23:43 <tflink> 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 <nirik> well, two interfaces on the same net like that has never worked has it?
16:24:52 <tflink> why not?
16:24:58 <tflink> why wouldn't it work, rather
16:25:06 <nirik> what interface does it use to talk to the gateway?
16:25:38 <brunowolff> There are ways of specifying which interface to use. I don't know what the default would be.
16:26:01 <tflink> are there use cases for this other than teaming?
16:26:04 <nirik> 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 <nirik> perhaps it works these days, but it never did in the past. ;)
16:27:12 <tflink> so punt for more info?
16:28:11 <tflink> re-test w/ one interface and get clarification on whether this config is valid
16:28:23 <nirik> sure.
16:28:55 <jreznik> seems like a plan
16:29:59 <tflink> 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 <adamw> ack
16:30:14 <brunowolff> ack
16:30:55 <kparal> ack
16:31:09 <brunowolff> 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 <tflink> #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 <tflink> #topic (965883) "Use network login..." button in user creation spoke entirely broken
16:31:28 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965883
16:31:31 <tflink> #info Proposed Blocker, anaconda, NEW
16:31:47 <tflink> has there been enough bikeshedding on devel@ to come to a better conclusion here?
16:32:04 <brunowolff> Based on the list discussion, I don't think this should be a blocker.
16:32:14 * nirik nods. seems not.
16:32:21 <nirik> although if it doesn't work, perhaps it should just be removed?
16:33:07 <tflink> 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 <brunowolff> 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 <tflink> that makes sense to me
16:34:16 <tflink> if it doesn't work and we know it doesn't work, there probably shouldn't be a button for it
16:34:24 <adamw> yeah, i was hoping for a bit more volume of discussion, but so far it's suggesting -1.
16:34:43 <tflink> adamw: -1 for removing the button or for making it work?
16:34:45 <adamw> 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 <adamw> -1 for 'making it work' as a blocker
16:35:59 <tflink> 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 <tflink> 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 <brunowolff> 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 <tflink> if the button just doesn't do anything, I'm not as worried about it
16:39:30 <jreznik> yep, it does not look good but I'm definitely -1 to block on the button removal
16:39:46 <jreznik> and FE to make it actually do something would be even better :)
16:39:53 <tflink> so ... thoughts on which option to take?
16:40:12 <adamw> FE for fix-or-replace works for me.
16:41:34 <tflink> 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 <tflink> ack/nak/patch?
16:42:52 <nirik> ack
16:43:25 <jreznik> ack
16:44:04 <kparal> ack
16:44:15 <adamw> acl
16:44:17 <tflink> #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 <tflink> #topic (966761) storage configuration failed: Not enough free space on disks for automatic partitioning
16:44:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966761
16:44:27 <tflink> #info Proposed Blocker, anaconda, NEW
16:45:17 <tflink> there hasn't been a whole lot of movement here since the last time we reviewed it
16:46:05 <tflink> it's smelling like a blocker, though
16:46:19 <tflink> assuming that it isn't isolated to this particular system, anyways
16:48:15 <tflink> we can re-punt for now and see if we can get someone to reproduce it
16:48:23 <tflink> again, for now anyways
16:50:25 <brunowolff> I think we want to keep tracking this, so punting while waiting for more feedback sounds good.
16:50:43 <tflink> does anyone have access to a system with multipath storage?
16:51:05 <tflink> a system like that which they can test with?
16:51:28 <tflink> even better, a PA system with multipath storage they can test installs with
16:51:55 <tflink> anyhow, I'm going with punt due to the overwhelming number of opinions and thoughts
16:52:33 <tflink> 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 <jreznik> punt for now, adding to my todo to ask RTT in the office if they have such configuraiton
16:53:00 <jreznik> ack
16:53:20 <tflink> I imagine that the storage folks do, not sure if the systems are in beaker, though
16:54:10 <tflink> #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 <tflink> #topic (966761) storage configuration failed: Not enough free space on disks for automatic partitioning
16:54:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966761
16:54:20 <tflink> #info Proposed Blocker, anaconda, NEW
16:55:09 <tflink> #info still waiting for re-testing by reporter
16:55:35 <tflink> #info will re-visit when more testing information is available
16:55:38 <tflink> #topic (961500) After upgrade to Fedora 19 I can no longer use Gnome
16:55:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=961500
16:55:44 <tflink> #info Proposed Blocker, gnome-session, ON_QA
16:58:07 <tflink> huh, I wonder if my HP laptop would show this
16:58:09 <adamw> definitely +1, this one's nasty
16:58:25 <adamw> tflink: seems like HP laptops are one of the big affected constituencies indeed
16:58:29 <kparal> soo, with the new kernel and gnome-bluetooth installed, the session doesn't start?
16:58:53 <tflink> I haven't been using it much lately, so I could have just missed the updates that are causing problems
16:58:54 <kparal> is it hw specific?
16:59:33 <adamw> somewhat, but the impact's wide enough and bad enough that we'd definitely want it fixed
16:59:41 <tflink> sounds like it is limited to specific bluetooth devices
16:59:49 <adamw> kparal: with the new kernel *but not the new gnome-bluetooth* it fails
17:00:11 <adamw> the new gnome-bluetooth fixes it
17:00:19 <kparal> +1 blocker
17:00:39 <tflink> yeah +1
17:00:56 <adamw> "kernel 3.9 added some new RFKILL_TYPE enum types, but gnome-bluetooth's rfkill code only handles the older types"
17:01:13 <adamw> i'm a little surprised it isn't considered a kernel API break, but meh.
17:01:24 <tflink> 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 <adamw> ack
17:01:54 <kparal> ack
17:03:53 <adamw> ack
17:03:56 <adamw> moustache ack
17:04:10 <tflink> #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 <tflink> #topic (960230) nss forgets about CAs intermittently (frequently after suspend)
17:04:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=960230
17:04:28 <tflink> #info Proposed Blocker, p11-kit, MODIFIED
17:04:54 <tflink> probably +1 on this, at least +1 FE
17:05:37 <adamw> it's pretty sucky for the lives, yeah
17:05:46 <adamw> and it doesn't seem to always need a suspend to trigger it
17:05:52 <adamw> bit borderline, but i guess i'd lean +1
17:05:56 <kparal> some of the guys were netsplitted
17:06:03 <kparal> at least in my session
17:06:18 <tflink> yeah, we lost half the people
17:06:38 * tflink fails to understand why one would ddos freenode
17:07:40 <adamw> is that what's going on? that stinks.
17:07:44 <kparal> I'm not sure about blocker status, +1 FE for sure
17:07:48 <adamw> for the lulz, I guess
17:08:19 <kparal> bad topic
17:08:57 <kparal> I don't mind +1 blocker
17:09:03 <tflink> adamw: yeah, there have been some messages from freenode admins talking about a ddos
17:09:14 <kparal> the web browser behaves incorrectly
17:09:25 <tflink> #topic (960230) nss forgets about CAs intermittently (frequently after suspend)
17:09:56 <tflink> robatino was seeing the same changing back of topic in #fedora-qa yesterday
17:10:02 <tflink> hopefully it doesn't keep happening
17:10:27 <tflink> it sounds like we're more +1 than -1, though?
17:10:42 <tflink> I agree that it's borderline - the workaround isn't bad
17:11:06 <adamw> 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 <tflink> jreznik, brunowolff: thoughts?
17:11:41 <tflink> it just seems like bad form to release something that could have troubles with our own web sites
17:11:41 <jreznik> ah, we are back together (listening to team meeting)
17:12:46 <jreznik> that's a good point, but with my 50% probability of successfull resume after suspend...
17:13:00 <brunowolff> Sorry I thought I was on the wrong side of a net split and went for snacks.
17:13:16 <tflink> brunowolff: you were for a bit but we got re-joined
17:13:37 <tflink> jreznik: it doesn't seem limited to suspend
17:14:18 <brunowolff> 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 <adamw> jreznik: right, last time it happened to me wasn't immediately after a resume, i don't think
17:14:53 <jreznik> 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 <tflink> 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 <tflink> so we're OK with live media that could have this bug in it?
17:16:35 <brunowolff> 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 <adamw> brunowolff: well it basically means https just doesn't work right. but the 'workaround' is simple enough - quit and restart
17:17:12 <brunowolff> With the centralized cert stuff couldn't this affect more than web browsers?
17:17:34 <tflink> if yum used https, it could cause problems with updates
17:17:35 <adamw> well, given that the bug turns out to be in p11-kit, i guess it could affect anything that uses that.
17:17:36 <jreznik> 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 <tflink> conditional accept, then?
17:18:56 <tflink> if it isn't just suspend, blocker. otherwise, FE?
17:19:24 <jreznik> tflink: I'd be ok with this condition
17:19:29 <jreznik> conditional
17:19:30 <adamw> i think we're gilding the lily a bit given that an update's been submitted already
17:19:35 <adamw> let's just pick something and move on
17:19:50 <tflink> adamw: ok, fe, then?
17:19:52 * satellit_e default for lives should be screensaver off and no suspend
17:20:15 <kparal> satellit_e: you wish
17:20:20 <satellit_e> : )
17:20:27 <adamw> fe, sure.
17:20:33 <jreznik> adamw: depends if the update really fixes the issue :)
17:20:39 <adamw> 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 <jreznik> but I'm ok with FE for now
17:21:13 <tflink> 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 <tflink> ack/nak/patch?
17:22:53 <kparal> we miss a third type of blocker - an update must be pushed stable before release
17:23:07 <kparal> I'd vote for that
17:23:23 <adamw> ack
17:23:26 <jreznik> ack
17:23:36 <kparal> ack
17:23:36 <tflink> kparal: not sure I understand what you're getting at
17:23:57 <kparal> 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 <kparal> that would be ideal resolution of this bug
17:24:23 <kparal> *my
17:24:42 <tflink> hopefully, the update will fix the issue - we can revisit if it turns out to be a bigger problem
17:24:49 <jreznik> yep, move on
17:24:51 <kparal> (freshly installed system including 0-day updates, I wanted to say)
17:25:01 <brunowolff> How do you know if an update will be in stable by the release when we make the go live decision?
17:25:14 <adamw> brunowolff: you just have to Make It So
17:25:18 <tflink> brunowolff: in updates-testing with enough karma
17:25:25 <tflink> or what adamw said
17:25:38 <adamw> 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 <tflink> #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 <tflink> bah, I missed an ack that I was waiting for
17:26:17 <brunowolff> 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 <tflink> #topic (968778) SELinux is preventing /usr/sbin/killall5 from using the 'sys_ptrace' capabilities.
17:26:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968778
17:26:29 <tflink> #info Proposed Blocker, selinux-policy, MODIFIED
17:27:32 <tflink> 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 <adamw> ack
17:28:06 <jreznik> ack
17:28:53 <brunowolff> ack
17:28:55 <tflink> #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 <tflink> #topic (965749) X's smart scheduler is crashy on ppc64
17:29:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965749
17:29:03 <tflink> #info Proposed Blocker, xorg-x11-server, ON_QA
17:30:27 <adamw> -1/+1
17:30:47 <tflink> 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 <tflink> 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 <tflink> punctuation change
17:31:12 <adamw> ack
17:31:13 <jreznik> ack
17:31:51 <brunowolff> ack
17:31:59 <tflink> #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 <tflink> #topic (955236) [abrt] yum-3.4.3-83.fc20: cli.py:1945:removeGroups:AttributeError: 'InstalledGroup' object has no attribute 'groupid'
17:32:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=955236
17:32:11 <tflink> #info Proposed Blocker, yum, MODIFIED
17:32:44 <tflink> no comment from reporter(s) or dev
17:33:40 <tflink> reject or punt again?
17:33:42 <brunowolff> My opinion is that this is still just FE material.
17:34:11 <adamw> i'm ok punting again - we only punted on monday
17:34:11 <tflink> 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 <brunowolff> Oh yeah. I hadn't forgotten that part of the discussion.
17:34:56 <tflink> #info still waiting for input from devs or reporters on whether there is yum corruption when the failure occurs
17:35:34 <brunowolff> 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 <tflink> 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 <tflink> hrm, that could have been phrased better
17:36:19 <tflink> oh well, it gets the point across
17:36:23 <tflink> ack/nak/patch?
17:36:47 <adamw> ack
17:36:51 <brunowolff> ack
17:38:03 <kparal> ack
17:38:05 <tflink> #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 <tflink> OK, that's all of the proposed blockers on my list
17:38:27 <tflink> moving on to the proposed FEs for anaconda
17:38:45 <adamw> yay
17:38:51 <tflink> since anaconda's special like that
17:39:07 <tflink> #topic (963059) Anaconda on Fedora 19 doesn't have option for setup HOSTNAME and NETWORK layout
17:39:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=963059
17:39:13 <tflink> #info Proposed Freeze Exceptions, anaconda, POST
17:39:31 <adamw> +1
17:39:54 <adamw> radek's been working on this for a bit
17:39:58 <adamw> i've been following it
17:40:34 <tflink> is this livecd only?
17:41:23 <brunowolff> Do we really want to pull this in after the freeze?
17:41:48 <tflink> brunowolff: we're playing anaconda's game of "we won't work on anything unless it's a FE or blocker"
17:43:23 <tflink> so it's more of an abuse of the blocker/FE process than anything
17:43:28 <adamw> yes
17:43:34 <adamw> er, yes it's live only
17:43:40 <brunowolff> Is this something we'd rather work on than other things that we'd want in before freeze?
17:43:51 <adamw> 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 <adamw> but the 'hostname' option, which is kind of an important one, is on the network spoke
17:44:19 <adamw> 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 <adamw> 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 <adamw> it's really an improvement
17:44:57 <tflink> +1
17:44:59 <adamw> brunowolff: the patch is already written
17:45:56 <tflink> 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 <brunowolff> OK. If it comes in not too late it would be OK.
17:46:03 <brunowolff> ack
17:46:10 <tflink> #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 <tflink> #topic (965832) No password strength indicator for root password
17:46:24 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965832
17:46:24 <tflink> #info Proposed Freeze Exceptions, anaconda, MODIFIED
17:46:52 <adamw> 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 <adamw> that's why we're making a special effort to cover anaconda FEs
17:47:27 <tflink> adamw: you phrased it more nicely than I did, though :)
17:48:01 <tflink> +1
17:48:19 <adamw> yeah, +1, this will make things more robust if anything
17:48:28 <adamw> having all the dialogs that do password entry do it the same way is a much better idea
17:48:35 <brunowolff> Ah. It still seems weird that we would be controlling their work that way.
17:48:42 <kparal> +1
17:48:43 <brunowolff> +1 Fe
17:48:46 <tflink> 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 <brunowolff> ack
17:50:15 <adamw> brunowolff: welp, it's what they wanted, so hey.
17:51:29 <kparal> ack
17:51:48 <tflink> 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 <tflink> #agreed 965832 - AcceptedFreezeException - Consistency in password evaluation during the install process is a good thing and a fix would be appreciated.
17:52:18 <adamw> 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 <adamw> oh, iswym.
17:53:23 <tflink> 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 <tflink> we chose 1)
17:53:31 <tflink> anyhow, moving on
17:53:36 <tflink> #topic (970077) DeviceSettingsNotFoundError: DeviceSettingsNotFoundError('wlp1s0',) (noipv6 + wiireless card -> crash)
17:53:39 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=970077
17:53:41 <tflink> #info Proposed Freeze Exceptions, anaconda, POST
17:54:01 <brunowolff> +1 FE if not too late.
17:54:04 <tflink> bah, I skipped one
17:54:09 <tflink> will go back after this one
17:54:31 <brunowolff> Oops. I was assuming we were doing the next one. I may change my vote since we skipped.
17:58:18 <kparal> +1 fe
17:58:30 <kparal> maybe we should have a test case for that
17:58:56 <adamw> we have quite a few missing test cases really
17:59:01 <adamw> i'm going to work on that next cycle
17:59:31 <tflink> 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 <brunowolff> ack
18:01:36 <kparal> ack
18:03:14 <tflink> #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 <tflink> again, assuming ack from adam
18:03:32 <adamw> ack
18:03:33 <adamw> sorry
18:03:45 <tflink> the other anaconda FE doesn't have a fix yet, do we want to go through it anyways?
18:04:45 <adamw> let's take a look
18:04:59 <tflink> ok, we;ve been skipping it so far
18:05:01 <tflink> #topic (869364) Installation Destination screen is sometimes rendered not at full screen width
18:05:05 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869364
18:05:07 <tflink> #info Proposed Freeze Exceptions, anaconda, ASSIGNED
18:05:21 <brunowolff> I think if we got a fix not too late into the freeze we'd want it.
18:06:12 <brunowolff> It's also not clear of the partial fix got in yet.
18:06:43 <brunowolff> If that does fix some cases, we may want that even if there isn't a real fix.
18:07:14 <adamw> 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 <tflink> 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 <adamw> ack
18:10:17 <kparal> ack
18:10:45 <brunowolff> ack
18:10:52 <tflink> #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 <tflink> OK, that's all of the anaconda-proposed FEs on my list
18:11:27 <tflink> moving on to the accepted blockers not ON_QA
18:12:31 <tflink> any objections to also skipping the blocker we accepted on monday?
18:12:38 <tflink> blockers
18:13:02 <brunowolff> At least leave it til the end.
18:13:13 <tflink> #topic (959677) IndexError: list index out of range
18:13:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=959677
18:13:13 <tflink> #info Accepted Blocker, anaconda, ON_QA
18:13:19 <adamw> skip 'em unless there's something obvious to discuss
18:13:23 <adamw> ...ON_QA?
18:13:26 <tflink> bah
18:13:30 <tflink> #undo
18:13:30 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x20498ad0>
18:13:32 <tflink> #undo
18:13:32 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x20498c90>
18:13:34 <tflink> #undo
18:13:34 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x20498110>
18:13:41 <tflink> #topic (968915) Anaconda locks user account instead of creating it password-less
18:13:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968915
18:13:46 <tflink> #info Accepted Blocker, anaconda, POST
18:13:52 <tflink> not much to say here
18:14:04 <tflink> #info fix will be in next anaconda build
18:14:42 <adamw> ayup
18:14:47 <tflink> #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 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=964586
18:14:53 <tflink> #info Accepted Blocker, anaconda, NEW
18:15:25 <tflink> #info this has been confirmed with a minimal install alongside windows
18:15:38 <tflink> #info devs are looking into it, nothing needed from us at this time
18:17:06 <kparal> ah, here we go. my 'r' word comment
18:17:19 <tflink> #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 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968951
18:17:24 <tflink> #info Accepted Blocker, gnome-initial-setup, NEW
18:17:42 <tflink> #info upstream is aware of the issue, is discussing it
18:17:50 <tflink> #link https://bugzilla.gnome.org/show_bug.cgi?id=701100
18:17:52 <adamw> working on fixes, actually
18:17:59 <adamw> we should probably have something soon
18:18:11 <tflink> #info still waiting on a fix, nothing for us to do at this time
18:19:09 <tflink> #topic (958426) 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB)
18:19:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=958426
18:19:15 <tflink> #info Accepted Blocker, LiveCD, ASSIGNED
18:19:30 <tflink> #info this is an auto-blocker - there have been added packages since beta
18:20:01 <tflink> #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 <tflink> #topic (968936) SIGSEGV of packagekit-offline-update.service during update
18:20:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968936
18:20:29 <tflink> #info Accepted Blocker, PackageKit, NEW
18:20:47 <tflink> it looks like this might have gotten worse than we thought
18:21:18 <adamw> right, i just couldn't get it to work at all
18:21:36 <adamw> 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 <tflink> 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 <tflink> #info this appears to be more broken than we originally thought
18:22:07 <tflink> #info devs are aware of the issue and are working on it
18:22:53 <tflink> anything else to add?
18:23:18 <adamw> that's about all I got
18:23:20 <tflink> #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 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966795
18:23:27 <tflink> #info Accepted Blocker, python-blivet, ASSIGNED
18:23:47 <tflink> #info no movement on this in bug
18:24:06 <adamw> i'll poke dlehman and make sure he remembers this one
18:25:39 <adamw> it sounded like he knew what was wrong like 2 weeks ago
18:25:58 <tflink> #info no known patch yet but it sounded like devs knew how to fix
18:26:27 <tflink> #info will follow up with anaconda devs to see what is going on
18:26:53 <tflink> 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 <tflink> either due to accepting on monday or to ongoing devel/triage activity
18:27:42 <adamw> awesome
18:27:53 <tflink> otherwise, it's time for ...
18:27:57 <tflink> #topic Open Floor
18:28:11 <tflink> Anything that should be covered today in-meeting?
18:29:37 <adamw> not really...
18:29:48 <adamw> oh, on that kickstart bug, hamzy says it happens even with just a single interface
18:29:54 <adamw> so we should probably check that out and see if it's hitting us too
18:31:14 <tflink> yeah, have there been any ks reports for TC1?
18:32:37 <tflink> anyhow, I think it's time to set a fuse
18:35:43 <adamw> ayup
18:36:25 <tflink> Thanks for coming, everyone!
18:36:30 * tflink will send out minutes shortly
18:36:34 <tflink> #endmeeting