16:01:32 <tflink> #startmeeting f20alpha-blocker-review-3
16:01:32 <zodbot> Meeting started Wed Sep  4 16:01:32 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:32 <tflink> #meetingname f20alpha-blocker-review-3
16:01:32 <zodbot> The meeting name has been set to 'f20alpha-blocker-review-3'
16:01:32 <tflink> #topic Roll Call
16:01:57 * jreznik is here
16:02:00 * satellit_e listening
16:02:11 * pwhalen is here
16:03:54 * pschindl is here
16:03:56 * tflink waits a few more minutes to see if we get a couple more people
16:04:13 <tflink> any volunteers for secretary duty?
16:07:03 * tflink takes that as a no
16:07:31 <tflink> well, lets get this party started. I guess I'll do secretarialization post-meeting
16:08:21 * kparal arrives late
16:08:32 <tflink> #topic Introduction
16:08:36 <tflink> #chair kparal
16:08:36 <zodbot> Current chairs: kparal tflink
16:08:44 <tflink> Why are we here?
16:08:44 <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:08:51 <tflink> #info We'll be following the process outlined at:
16:08:51 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:58 <tflink> #info The bugs up for review today are available at:
16:08:59 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:05 <tflink> #info Up for review today, we have:
16:09:12 <tflink> #info 8 Proposed Blockers
16:09:12 <tflink> #info 5 Accepted Blockers
16:09:12 <tflink> #info 0 Proposed Freeze Exceptions
16:09:12 <tflink> #info 3 Accepted Freeze Exceptions
16:09:29 <tflink> if there are no objections, we'll start with the proposed blockers
16:10:10 <tflink> #topic (1000703) TypeError: not enough arguments for format string
16:10:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000703
16:10:15 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:11:07 <kparal> am I the secretary today, or was there another volunteer?
16:11:52 <tflink> kparal: no other volunteer, if you could take care of it, I'd appreciate that
16:12:05 <tflink> so, this sounds like "custom partitioning screen is broken" to me
16:12:19 <kparal> tflink: ok
16:13:02 <tflink> this isn't really an alpha blocker
16:13:09 <tflink> but it would be nice if it didn't crash right away
16:13:44 <Viking-Ice> hmm weren't all installer crashes blockers?
16:13:55 <kparal> Viking-Ice: no
16:14:19 <Viking-Ice> ( as in visible/hard crashes )
16:14:44 <tflink> not at alpha, I don't think
16:14:46 * kparal failed to find appropriate criterion, Alpha speaks about guided part only
16:15:10 <kparal> -1 blocker +1 fe
16:15:11 <Viking-Ice> -1/+1
16:15:23 <tflink> that sounds more like final
16:15:27 <tflink> but -1/+1
16:15:48 <jreznik> -1/+1 as looking on criteria
16:16:25 <tflink> proposed #agreed 1000703 - RejectedBlocker AcceptedFreezeException - This doesn't violate any F20 alpha release critera and thus does not qualify as a release blocking bug. However, a tested fix would be considered past freeze.
16:16:51 <Viking-Ice> ack
16:17:00 <kparal> btw, custom part is Beta?
16:17:02 <kparal> ack
16:17:28 <jreznik> kparal: right, beta http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Custom_partitioning
16:17:31 <jreznik> ack
16:17:59 <tflink> do we want to take it as a beta blocker, then?
16:18:09 <kparal> I'll just re-propose
16:18:16 <kparal> it's already modified anyway
16:18:16 <tflink> k, thanks
16:18:22 <tflink> #agreed 1000703 - RejectedBlocker AcceptedFreezeException - This doesn't violate any F20 alpha release critera and thus does not qualify as a release blocking bug. However, a tested fix would be considered past freeze.
16:18:34 <tflink> #topic (1002811) Anaconda is unable to handle dependcy problems without crashing
16:18:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1002811
16:18:40 <tflink> #info Proposed Blocker, anaconda, NEW
16:19:20 <tflink> -1/-1 this is a "feature" request
16:21:12 <tflink> other thoughts?
16:21:31 <Viking-Ice> we still need info on which package manager the installer is using dnf/yum/what ever the desktop team is working on and what gnome 3 upstream is also working on
16:21:33 <kparal> so the bug report is about the firefox bug?
16:21:42 <jreznik> well, I expect for "final" release we would have all dependencies issues fixed, right
16:21:59 <Viking-Ice> dependency should be fixed at alpha
16:22:14 <tflink> no, that's just what steve was hitting when attempting to test
16:22:16 * spstarr_work is here
16:22:19 <spstarr_work> just... working :)
16:22:28 <kparal> actually if we can test this in "testing transaction" phase, I don't believe the installer should fail after adjusting the partitions
16:22:31 <tflink> this is a request to get anaconda to ignore dep problems w/o stopping install
16:22:50 <kparal> there's stress on _after_
16:22:51 <jreznik> so it's not blocking alpha if it crashes as there should not be any issue at all - so really, it's feature request
16:23:09 <jreznik> hmm, after...
16:23:22 <kparal> jreznik: I think the firefox deps are not broken, it's just not installable
16:23:28 <kparal> due to script failures
16:23:34 <tflink> yeah, the pkg install just fails
16:23:44 <kparal> so I don't know whether we cover that by other Alpha criteria
16:23:54 <kparal> but maybe that's just beauracracy
16:23:59 <tflink> this isn't the firefox issue
16:24:04 * kparal never knows how to spell that word
16:24:10 * tflink neither
16:24:14 <Viking-Ice> this is dep problem right
16:24:34 <tflink> this is about anaconda not continuing the install if it hits transaction problems during install
16:24:53 <kparal> "There must be no errors in any package on the release-blocking images which cause the package to fail to install. "
16:24:57 <Viking-Ice> yeah well that's feature as you mentioned -1/-1
16:25:00 <kparal> actually this cover it well
16:25:07 <tflink> not really
16:25:22 <tflink> this isn't about an error in any package, it's about how anaconda handles the error
16:25:53 <tflink> the mention of 1003691 is an anecdote explaining why farther testing couldn't be done
16:26:08 <kparal> so it's possible to continue with the transaction, and anaconda chooses to exit?
16:26:26 <tflink> not as sure about that
16:26:38 <Viking-Ice> I dont think that's possible
16:27:05 <Viking-Ice> as in to "ignore" problem package and "proceed" with install
16:27:26 <tflink> even if it is possible, is it really desirable?
16:27:41 <Viking-Ice> yup
16:27:43 <kparal> ok. I think the bug is missing a lot of information. it says "anaconda is crashing" but doesn't provide any log files. we don't know if it just prints out an error before install, or during install, or anything. also, we cover a lot of package problems with other criteria
16:28:07 <Viking-Ice> well we have 2x -1/-1
16:28:09 <kparal> so, let's say "add more info or rejected"
16:28:10 <Viking-Ice> already
16:28:17 <tflink> it's a feature request to change anaconda's behavior
16:28:37 * tflink only saw 1 vote
16:28:43 <tflink> oh, i see the second
16:29:44 <tflink> proposed #agreed 1002811 - RejectedBlocker RejectedFreezeException - This doesn't violate any F20 alpha release criterion and is a request for anaconda behavior change and thus doesn't qualify as a release blocking bug for F20 alpha.
16:29:48 <kparal> I'm -1 on the basis that we can cover the breakage by other criteria. I don't think that anaconda should crash during the installation because of broken package, if it can test it in advance. but that wouldn't be Alpha blocker, probably
16:29:51 <tflink> ack/nak/patch?
16:30:21 <Viking-Ice> ack
16:30:29 <pschindl> ack
16:30:44 <kparal> I'll add a comment
16:30:45 <kparal> ack
16:30:46 <tflink> #agreed 1002811 - RejectedBlocker RejectedFreezeException - This doesn't violate any F20 alpha release criterion and is a request for anaconda behavior change and thus doesn't qualify as a release blocking bug for F20 alpha.
16:31:10 <tflink> kparal: yeah, the actual breakage (where it exists) would be covered by other criteria
16:31:28 <tflink> not sure we want to take something like this as a blocker w/o talking w/ anaconda devs first
16:31:39 <tflink> #topic (1003229) TC2 Net installer fails with Error 256
16:31:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1003229
16:31:40 <tflink> #info Proposed Blocker, anaconda, NEW
16:32:04 * tflink couldn't reproduce the issue, is pretty sure it's a mirroring problem
16:32:05 <tflink> -1/-1
16:33:10 <kparal> hmm, I wonder whether it can be connected to 1003637
16:33:11 <Viking-Ice> Anaconda should better handle that but yeah -1/-1
16:33:31 * jreznik is back
16:33:56 <kparal> -1 because there are no logs
16:34:10 <jreznik> it's strange feeling to see all bugs starting with 1
16:34:32 <Viking-Ice> <shrug> the anaconda team should have triage this and put it into needinfo status
16:34:35 <tflink> kparal: it's not an anaconda issue
16:35:01 <jreznik> no mirrors to try...
16:35:01 <tflink> I'm 90% sure this is a mirror problem - I've hit it more than once and found a broken mirror to be the cause
16:35:02 <kparal> tflink: no, but I suspect some yum changes
16:35:44 <tflink> yeah, dgilmore has been having all kinds of fun with yum and f20 composes
16:35:54 <tflink> I see -2
16:36:20 * jreznik is -1 but would be nice to try to get opinion from yum guys
16:36:25 <Viking-Ice> do we have any info if the anaconda team is planing on changing the package management ( yum vs dnf ) they use ?
16:36:45 <tflink> proposed #agreed 1003229 - RejectedBlocker - This appears to be a mirror issue and does not violate any F20 alpha release criteria, thus rejected as a release blocking bug for f20 alpha.
16:36:55 <tflink> this _isn't_ a yum/dnf bug
16:37:03 <Viking-Ice> ack
16:37:19 <kparal> anaconda _is_ still using yum, doesn't it?
16:37:23 <tflink> the error message is a bit weird, sure but why should we expect yum to deal with a busted mirror
16:37:30 <kparal> ack
16:37:49 <Viking-Ice> kparal, I would think they would not switch unless we make an "official" switch
16:38:16 <tflink> moar ack/nak/patch?
16:38:32 <jreznik> ack
16:38:34 <tflink> #agreed 1003229 - RejectedBlocker - This appears to be a mirror issue and does not violate any F20 alpha release criteria, thus rejected as a release blocking bug for f20 alpha.
16:38:42 <tflink> #topic (994180) Boot-time LUKS passphrase input *always* defaults to en-us
16:38:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=994180
16:38:48 <tflink> #info Proposed Blocker, anaconda, NEW
16:38:51 * Martix is here
16:38:53 <dgilmore> anaconda has the start of dnf support
16:39:15 <Viking-Ice> in other words broken implementation
16:39:16 <jreznik> dgilmore: but not used by default I suppose
16:39:48 <Viking-Ice> we need to get this cleared up from the anaconda team
16:39:55 <dgilmore> jreznik: not yet
16:40:00 <Viking-Ice> seriously they will no be shipping both methods
16:40:25 <Viking-Ice> that would be plain stupid
16:40:39 <tflink> Martix: welcome to the party
16:40:57 <kparal> so, lbrabec tested this one thoroughly
16:41:08 <kparal> and I'm +1 blocker
16:41:22 <tflink> it sounds like the source of the issue has been found but there is a bit of disagreement on how to fix it
16:41:25 <kparal> it's very simply. if you encrypt your disk with non-us letters, you have no way of decrypting it
16:41:37 <tflink> but live only, no?
16:41:38 <Viking-Ice> +1
16:41:43 <tflink> or am I reading too fast
16:41:45 <Martix> kparal: I can confirm this bug
16:41:47 <kparal> if you use only ascii characters, you can work around by typing as with us keyboard
16:42:44 <kparal> tflink: lbrabec tested with Live only, I guess. I'm not sure if it affects also DVD, but I expect so
16:43:04 <kparal> anaconda simply doesn't regenerate initramfs after providing values to /etc/vconsole and others
16:43:23 <kparal> so it should not be affected by Live/nonLive environment
16:44:07 <Viking-Ice> anaconda does not due that ( which causes many bugs )
16:44:11 <Viking-Ice> it should
16:44:14 <kparal> Vratislav Podzimek doesn't like generating initramfs for the second time, but that's a technical argument between him and Harald
16:44:26 <Viking-Ice> not really
16:44:32 <Viking-Ice> it should period
16:44:47 <kparal> for the purposes of this discussion that's not important
16:44:49 <Viking-Ice> Vratislav just has to suck it up and accept that fact
16:44:53 <jreznik> and it ended up with hostonly bashing...
16:45:23 <Martix> +1 blocker, go on
16:45:33 <kparal> the impact is that all people encrypting disk with non-ascii chars don't have any easy workaround
16:46:06 <kparal> which violates the criterion sufficiently, I believe
16:46:16 <tflink> proposed #agreed 994180 - AcceptedBlocker - Violates the following F20 alpha release criterion for systems with a non-us keyboard and encrypted disks: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
16:46:22 <Viking-Ice> ack
16:46:30 <kparal> patch
16:46:37 <kparal> "In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s)."
16:46:44 <kparal> that's better criterion, no?
16:46:48 <Viking-Ice> ah yeas
16:46:51 <jreznik> it is
16:46:57 <tflink> no, it's not a criterion
16:47:10 <tflink> it's a qualifier to the criterion, in my mind
16:47:31 <kparal> alright, I'll just append it :)
16:47:33 <kparal> ack
16:47:53 <tflink> yeah, I don't know why I spend time formatting these proposals, they get changed when in bugzilla anyways
16:48:49 <Martix> ack
16:48:50 <kparal> the criterion applies is a bit weird
16:48:52 <tflink> moar ack/nak/patch? or is everyone waiting for a change in proposal?
16:48:53 <kparal> *applied
16:48:53 <pschindl> ack
16:49:00 <tflink> kparal: applies?
16:49:14 <kparal> you know, firstboot tool != encrypted disks
16:49:41 <kparal> but that's not really important
16:49:47 <tflink> firstboot tool is used as an indication of a successful install
16:50:00 <kparal> ok ok
16:50:04 <tflink> you can't get to that milestone of initial boot if you can't unlock the disk
16:50:08 <Viking-Ice> potato potato
16:50:09 <kparal> let's accept :)
16:50:20 <tflink> #agreed 994180 - AcceptedBlocker - Violates the following F20 alpha release criterion for systems with a non-us keyboard and encrypted disks: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
16:50:34 <tflink> #topic (1004323) Apper: "You have failed to provide correct authentication." while checking/installing updates
16:50:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1004323
16:50:39 <Viking-Ice> let's move on decided blocker is still an blocker regardless how it's phrased
16:50:40 <tflink> #info Proposed Blocker, apper, NEW
16:51:07 <tflink> +1
16:51:18 <Viking-Ice> is apper our default graphical package manager
16:51:20 <Viking-Ice> ;)
16:51:24 <tflink> for kde, yes
16:51:33 <Viking-Ice> kde aint default ;)
16:51:36 <Viking-Ice> but yeah +1
16:51:44 <tflink> but is a release blocking desktop
16:52:30 <kparal> is this gpg keys problem?
16:52:50 <tflink> proposed #agreed 1004323 - AcceptedBlocker - Violates the following F20 alpha release criterion for KDE: "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops."
16:52:56 <Viking-Ice> ack
16:52:56 <tflink> doesn't sound like it to me
16:53:01 <kparal> ack
16:53:29 <pschindl> ack
16:53:38 <jreznik> ack
16:53:40 <tflink> #agreed 1004323 - AcceptedBlocker - Violates the following F20 alpha release criterion for KDE: "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops."
16:53:45 <tflink> #topic (1003691) firefox pretrans scriptlet issues
16:53:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1003691
16:53:46 <tflink> #info Proposed Blocker, firefox, ON_QA
16:53:51 <tflink> +1
16:54:04 <tflink> There must be no errors in any package on the release-blocking images which cause the package to fail to install.
16:54:47 <tflink> proposed #agreed 1003691 - AcceptedBlocker - Violates the following F20 alpha release criterion for firefox, which is part of the default gnome install: "There must be no errors in any package on the release-blocking images which cause the package to fail to install."
16:55:22 <Viking-Ice> +1
16:55:29 <kparal> ack
16:55:34 <Viking-Ice> kinda autoblocker
16:55:35 <Viking-Ice> -ack
16:55:37 <jreznik> ack
16:55:38 <Viking-Ice> mean ack
16:55:48 <tflink> #agreed 1003691 - AcceptedBlocker - Violates the following F20 alpha release criterion for firefox, which is part of the default gnome install: "There must be no errors in any package on the release-blocking images which cause the package to fail to install."
16:55:50 * jreznik is moving to another meeting, will be back soon
16:56:04 <tflink> #topic (1002737) initial-setup-graphical.service does not run - TypeError: Argument 1 does not allow None as a value
16:56:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1002737
16:56:09 <tflink> #info Proposed Blocker, initial-setup, NEW
16:56:57 <Viking-Ice> +1
16:56:59 * tflink glares at pwhalen for not including a violated criterion even though this one is rather obvious
16:57:01 <pwhalen> this one prevents initial-setup from running on arm images with desktop
16:57:24 <pwhalen> tflink, sorry, will do going forward
16:57:26 <tflink> "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."?
16:57:37 <kparal> pwhalen: does minimal image include initial-setup as well?
16:57:49 * kparal just curious
16:57:50 <pwhalen> it includes a text version, which runs..
16:57:54 <kparal> ok
16:58:00 <tflink> +1
16:58:05 <kparal> +1
16:58:06 <pwhalen> there is initial-setup-{graphical,text}
16:58:10 <pwhalen> +1
16:58:36 <tflink> proposed #agreed 1002737 - AcceptedBlocker - Violates the following F20 alpha release criterion for ARM images with a graphical desktop: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
16:58:40 <Viking-Ice> ack
16:58:43 <pwhalen> ack
16:58:44 <kparal> ack
16:58:52 <tflink> #agreed 1002737 - AcceptedBlocker - Violates the following F20 alpha release criterion for ARM images with a graphical desktop: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
16:59:07 <tflink> #topic (985569) libuser wrongly sets "date of last password change" shadow field to 0 on systems without an rtc
16:59:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=985569
16:59:13 <tflink> #info Proposed Blocker, libuser, ASSIGNED
16:59:40 <pwhalen> this bug is on the text version, there is also a patch that has been proposed but not actioned
17:00:06 <tflink> the consequence is that a user would have to reset their password after initial login, right>
17:00:09 <tflink> ?
17:00:22 <Viking-Ice> -1/+1
17:00:28 <pwhalen> right.. and they dont if they have an rtc/network
17:01:08 <tflink> -1 blocker, +.5 on FE - depends on how quickly the fix showed up
17:01:21 <tflink> which ends up being -1/+1, I suppose
17:01:27 <tflink> we don't have to take the fix
17:01:32 <Viking-Ice> right
17:01:33 <pwhalen> sorry, I'll link to criteria in the future on these - this one should likely be FE
17:01:34 <tflink> other votes?
17:01:53 <kparal> -1/+1
17:02:06 <Viking-Ice> for the first it's alpha users having to re-set their password is least of their worries ;)
17:02:33 <tflink> how many arm platforms don't have rtc?
17:02:38 <pwhalen> and.. its only if the network was missing, I'd agree
17:02:42 <pwhalen> tflink, most
17:02:44 <Viking-Ice> and any of the pre-release stuff are throw away installs anyway
17:03:24 <tflink> proposed #agreed 985569 - RejectedBlocker AcceptedFreezeException - This doesn't violate any of the F20 alpha release criteria and thus is rejected as a release blocking bug for alpha. However, a tested fix would be considered past freeze.
17:03:28 <Viking-Ice> ack
17:03:36 <kparal> ack
17:03:37 <pwhalen> ack
17:03:44 <tflink> #agreed 985569 - RejectedBlocker AcceptedFreezeException - This doesn't violate any of the F20 alpha release criteria and thus is rejected as a release blocking bug for alpha. However, a tested fix would be considered past freeze.
17:03:51 <tflink> ok, that's all of the proposed blockers on my list
17:03:55 <tflink> on to the proposed FE
17:04:10 <tflink> oh, there aren't any
17:04:17 <Viking-Ice> QUANTUM FUSE!
17:04:19 <tflink> on to the accepted blockers, then :)
17:04:38 * tflink skips MODIFIED bugs
17:04:41 <Viking-Ice> tflink, no need to review accepted blockers I think this early in the cycle
17:04:49 * satellit_e https://bugzilla.redhat.com/show_bug.cgi?id=1004421  not yet  listed
17:05:03 <Viking-Ice> ( we should do so just before we plan releasing alpha )
17:05:08 <tflink> satellit: you proposed it as a beta FE
17:05:14 <satellit_e> oops
17:05:50 <tflink> Viking-Ice: I disagree on accepted blockers, I'd rather catch issues that are stagnating now rather than just before go/no-go
17:05:51 <Viking-Ice> +1 fe
17:06:20 <jreznik> tflink: yep, I tried some decent pinging today on a few
17:06:48 <Viking-Ice> tflink, stagnating might == to people working on the solution
17:06:56 <tflink> #topic (1004421) f20 SoaS TC3 uses gdm which defaults to gnome. Autologon starts gnome with no chance to choose sugar-desktop
17:06:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1004421
17:07:02 <tflink> #info Proposed Freeze Exception, sugar, NEW
17:07:05 <tflink> +1 FE
17:07:23 <tflink> would be a blocker for a release-blocking DE, therefore FE for sugar
17:07:43 <Viking-Ice> well that switch is coming a bit late
17:08:14 <tflink> proposed #agreed 1004421 - AcceptedFreezeException - This prevents SoaS from booting properly and would be a blocker for a release blocking DE, therefore accepted as a FE for F20 alpha.
17:08:19 <Viking-Ice> that runner request in a perfect pony world should have arrived when we branched
17:08:20 <Viking-Ice> ack
17:08:31 <pschindl> ack
17:08:59 <tflink> ack/nak/patch?
17:09:19 <kparal> ack
17:09:44 <tflink> #agreed 1004421 - AcceptedFreezeException - This prevents SoaS from booting properly and would be a blocker for a release blocking DE, therefore accepted as a FE for F20 alpha.
17:10:11 <tflink> of the accepted blockers, the only one whose status I'm not clear on is 1002055
17:10:36 <tflink> 1000715, 1001081 are waiting on TC3
17:10:49 <tflink> 1002055 is waiting on gnome update
17:10:54 * spstarr_work is going to wait for TC4 unless TC3 fixes anaconda 32bit boot issues or other serious ones im blocked for major testing
17:11:00 <tflink> 1000889 has a patch, should be in next anaconda build
17:11:52 <kparal> #topic Accepted blockers
17:11:52 <tflink> I don't see any accepted blockers that need attention right now
17:12:03 <tflink> #info 1000715, 1001081 are waiting on TC3
17:12:14 <tflink> #info 1002055 is waiting on gnome update
17:12:26 <tflink> #info 1000889 has a patch, should be in next anaconda build
17:12:48 <tflink> it looks like 1000927 is being worked on, nothing needed from us at the moment
17:13:24 <Martix> btw Anaconda in 20130903 nightly build is broken, after I "Accept" my fate", screen becomes white
17:13:42 <Martix> in virt-manager
17:13:56 <tflink> oh, fun - i wonder if TC3 will be DOA
17:13:59 <kparal> Martix: 32bit?
17:14:02 <tflink> we'll find out shortly
17:14:04 <Martix> kparal: 64
17:14:11 <kparal> hmm
17:14:29 <Martix> from PXE
17:14:31 <tflink> any objections to skipping review of accepted blockers for today?
17:14:44 <handsome_pirate> lol
17:14:48 <tflink> Martix: that kinda sounds like an issue spstarr_work was chasing down?
17:14:48 <Viking-Ice> nope
17:14:50 <handsome_pirate> I come in to see y'all wrapping up
17:14:51 <kparal> tflink: no
17:15:16 <tflink> #agreed no more review of accepted blockers is needed today, all seem to be progressing well
17:15:22 <tflink> #topic Open Floor
17:15:36 <tflink> Any other topics which should be brought up now?
17:15:37 <kalev> < tflink> 1002055 is waiting on gnome update
17:15:48 <tflink> kalev: ?
17:15:54 <kalev> this is actually done and made it to F20 last night, right before the freeze
17:16:14 <Martix> tflink: do you have link in bugzilla?
17:16:18 <tflink> kalev: i thought those builds were being done in a side tag?
17:16:21 <kalev> unfortunately, TC3 is based on yesterday's F20 compose, so it would be great if you could request one more TC
17:16:34 <kalev> tflink: yeah, but we finished up before the freeze and merged them back in.
17:16:39 <tflink> sweetness
17:16:56 <tflink> yeah, I expect to request a new TC soon
17:17:02 <kalev> cool
17:17:08 <tflink> thanks for the update
17:17:18 <handsome_pirate> new tc *ought* to boot on Beagle Bone Black
17:17:29 <tflink> handsome_pirate: post TC3?
17:17:30 <kparal> handsome_pirate: great news
17:17:52 <tflink> we should probably build a smoke livecd to test the x32 gnome issue, though
17:18:02 <tflink> since it'll be a day or so before TC4 is requested/built
17:18:15 <tflink> #info F20 Alpha TC3 should be landing shortly, will need testing
17:18:56 <tflink> #info next blocker review meeting will be 2013-09-11 @ 16:00 UTC unless another meeting is needed on 2013-09-09
17:19:08 <handsome_pirate> tflink:  Aye, post TC3
17:19:20 <handsome_pirate> tflink:  It depends on if the latest kernel build gets in
17:19:25 <tflink> if there's nothing else, I'm setting the non-deterministic fuse for [0,5] minutes
17:19:35 <handsome_pirate> 3.11.0-3
17:19:38 <tflink> handsome_pirate: dgilmore pulled in a new kernel update to TC3
17:19:51 <handsome_pirate> Okay, that should have it
17:19:55 <tflink> you guys are just trying to make me look bad for raising an issue with fesco :)
17:20:08 <Martix> kparal: tflink also 20130831 build hits white screen, fyi TC2 doesn't
17:20:20 * Viking-Ice turns on that quantum fuse that changes non-deterministic fuse to be even more non-deterministic
17:20:41 <Martix> I'm affraid, TC3 will have some issue
17:20:45 <Martix> *same
17:20:59 <tflink> Martix: yeah, we'll see if TC3 is also affected but I suspect you're right
17:21:33 <tflink> anyhow, we have multiple fuses which could go off any time :)
17:21:38 <tflink> thanks for coming everyone!
17:21:43 * tflink will send out minutes shortly
17:21:46 <tflink> #endmeeting