16:01:09 <tflink> #startmeeting f18beta-blocker-review-5
16:01:09 <zodbot> Meeting started Wed Oct 24 16:01:09 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:09 <tflink> #meetingname f18beta-blocker-review-5
16:01:09 <tflink> #topic Roll Call
16:01:09 <zodbot> The meeting name has been set to 'f18beta-blocker-review-5'
16:01:22 * cmurf hears crickets
16:01:25 <adamw> morning
16:01:25 * satellit_e listening
16:02:29 <tflink> so that's how to get people to chime in - claim to hear crickets?
16:02:51 <tflink> I'll have to remember that one
16:02:57 <cmurf> i hear crickets are great at bug blockers
16:03:15 <tflink> aren't crickets bugs, though?
16:03:23 <cmurf> exactly!
16:03:24 <tflink> too many crickets to review!!!!
16:03:32 <jreznik> bugs? what are bugs?
16:04:06 <cmurf> unexpected anomaly?
16:04:40 <tflink> jreznik: you here for the review meeting?
16:04:50 * tflink is trying to figure out if we have enough people to get started
16:05:14 <tflink> the list actually doesn't look too bad today
16:05:20 <jreznik> tflink: yep a little bit tough today with many meetings...
16:05:28 <jreznik> tflink: yep, it looks good
16:05:29 * nirik chirps anoyingly behind a dresser.
16:05:30 <tflink> perhaps it's time to start sharpening the poking stick :-D
16:06:03 <tflink> anyhow, let's get this party started
16:06:14 <tflink> #topic Introduction
16:06:22 <tflink> Why are we here?
16:06:22 <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 nice-to-have bugs.
16:06:32 <tflink> #info We'll be following the process outlined at:
16:06:32 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:39 <tflink> #info The bugs up for review today are available at:
16:06:39 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:49 <tflink> #info The criteria for release blocking bugs can be found at:
16:06:49 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:06:49 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:06:49 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:07:02 <tflink> Up for review today are:
16:07:06 <tflink> #info 7 Proposed Blockers
16:07:06 <tflink> #info 8 Accepted Blockers
16:07:06 <tflink> #info 0 Proposed NTH
16:07:06 <tflink> #info 12 Accepted NTH
16:07:25 <tflink> any objections to starting with the proposed blockers?
16:07:37 <jreznik> go on!
16:07:40 <akshayvyas> nope
16:07:59 <tflink> #topic (868519) LUKS passphrase exposed in /root/anaconda-ks.cfg
16:07:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868519
16:07:59 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
16:07:59 <tflink> #info assigned to: anaconda-maint-list@redhat.com
16:08:06 <tflink> #undo
16:08:06 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x24eedad0>
16:08:38 <adamw> oh, hey.
16:08:44 <adamw> so i've just been talking to dcantrell about this.
16:09:00 <adamw> anaconda team still isn't convinced they want to fix it, but...
16:09:32 <adamw> so far as blocker status goes, this hits one of our areas of 'missed coverage', we don't really have anything explicit to cover security issues
16:10:16 <adamw> we could take it under the 'urgent severity issue in a critpath component' escape clause, though.
16:10:18 <nirik> I don't know that I would call it a beta blocker, but it should be fixed before final, IMHO...
16:10:30 <jreznik> definitely
16:10:43 <nirik> it is kinda icky. why don't they want to fix it?
16:11:00 <adamw> if i was going to draft a criterion it'd be something like 'all security issues that could not be addressed fully with an update must be resolved before final release' or something like that.
16:11:07 <adamw> nirik: on the theory that the kickstart ought to be a precise replica of the install
16:11:22 <adamw> the problem with obfuscation is that we have a mechanism whereby the root password in the kickstart can be obfuscated but still work
16:11:25 <adamw> we don't have anything like that for LUKS
16:11:48 <nirik> ah true.
16:12:00 <adamw> my position would be that there is no valid use case for re-using encryption passphrases and this _is_ a clear security risk, so we should just leave it empty
16:12:14 <adamw> but that's kinda orthogonal to the blocker question.
16:12:27 <nirik> right
16:13:11 <adamw> so as i see the options...if we use the escape clause we kinda have to take it for beta, or we can agree in principle to my vague draft and take it for final
16:13:18 <tflink> well, it isn't 100% orthagonal - it's not like this could be fixed with an update
16:13:33 <adamw> i mean the question of whether to fix it, not the criterion.
16:13:36 <tflink> I'm not convinced this is a beta blocker
16:13:45 <tflink> I'd be more for beta NTH and final blocker
16:14:18 <cmurf> yeah
16:14:20 <cmurf> it's a beta
16:14:23 <cmurf> they bite
16:14:41 <cmurf> i'm -1 blocker, and +1 NTH for beta
16:14:48 <adamw> yeah, that's about where i am
16:14:50 <cmurf> and strong +1 block for final
16:14:51 <adamw> nth for beta, final blocker
16:15:03 * nirik too also
16:15:12 <jreznik> same here
16:15:13 <adamw> but i'd like us to agree on the gist of the criterion to take it for final
16:15:16 <nirik> but if we don't fix it, we should note it in relnotes/common bugs or something.
16:15:21 <nirik> so people aren't surprised.
16:15:25 <adamw> or else we're getting back towards 'it's a blocker because we said so' territory
16:15:29 <jreznik> nirik: true
16:16:01 <tflink> proposed #agreed 868519 - RejectedBlocker (beta), AcceptedNTH (beta), AcceptedBlocker (final) - needs wording
16:16:01 <cmurf> did any security people look at this? i see no additional comments
16:16:20 <adamw> vincent danen is from the security team.
16:16:37 <adamw> tflink: could we first have a proposed #agreed for the gist of the new criterion?
16:16:53 <adamw> propose #agreed it's agreed in principle that security issues not fixable by an update must be resolved before final release
16:17:41 <cmurf> well….
16:17:52 <tflink> sorry, got distracted a bit
16:17:56 <cmurf> there are many qualifications for "security issues"
16:18:37 <tflink> yeah, security issues is a bit vague
16:18:56 <jreznik> but I don't think there's any more specific term...
16:19:34 <jreznik> and as fedora does not have any dedicated security people, we even can't say "reviewed by security team"
16:19:53 <adamw> cmurf: that's why i said in principle
16:20:01 <adamw> we can hack the details
16:20:11 <tflink> patch
16:21:22 * adamw waits with bated breath
16:21:49 <tflink> proposed #agreed in principle, all major security issues which can't be fixed by a security update must be fixed before final release
16:21:54 <tflink> #chair adamw
16:21:54 <zodbot> Current chairs: adamw tflink
16:22:04 <adamw> heh. okay
16:22:21 <adamw> we can always use one of the existing security rating indicators. there's enough of them.
16:22:24 <cmurf> i'm less ok with that wording
16:22:40 <tflink> cmurf: patch?
16:23:14 <Southern_Gentlem> all known security issues
16:23:14 <cmurf> commend 14, Vincent says the bug "isn't a huge security issue" so if that's interpreted as not major, then this bug wouldn't qualify as needing to be fixed for final
16:24:11 <cmurf> i think the original wording, with admitted vagueness "in principle" is ok for today's purposes but it should be revisited to be a little more qualifying
16:24:13 <tflink> all security issues seems a bit vague
16:24:26 <tflink> s/major/significant?
16:24:27 <cmurf> very true, until someone is bitten badly
16:24:32 <cmurf> only then do we have clarity
16:25:09 <cmurf> i think the obfuscation of user passwords should be high priority, that can't be stored plain text
16:25:27 <cmurf> even if the kickstart were on an an encrypted rootfs this is not a good thing
16:25:29 <akshayvyas> cmurf: +1
16:25:30 <tflink> so the only thing that you two will agree to is 'all'?
16:25:36 <adamw> i kinda see this as a bit more serious than vincent, if you think it through, the point of encryption is to safeguard against untrusted people with direct access to the data, so the fact there's no remote exploit or anything is kinda irrelevant
16:25:49 <adamw> and encrypting /home only is a pretty common use case
16:26:11 <adamw> i think a distro where you can encrypt /home without it really being _effective_, because anyone who got hold of the drive would have the passphrase in plain text, is kinda bad.
16:26:25 <cmurf> haha yes absolutely
16:26:53 <adamw> of course you can wipe the file, but you have to know.
16:27:00 <tflink> I can't think of any examples off the top of my head, but what qualifies as a security issue if we do say all?
16:27:15 <tflink> it sounds like we're generally agreed that this should be a blocker
16:27:24 <adamw> to a rough approximation, anything with the security keyword
16:27:24 <cmurf> the internet connection to a computer is a security issue, fyi
16:27:41 <adamw> well yes, the only secure computer is one you never turn on, we know
16:27:52 <adamw> tflink: yeah, i think we have enough to go with for now
16:28:01 <adamw> but i would like to take one of those proposed #agreeds
16:28:08 <adamw> so cmurf, you prefer the one without 'major'?
16:28:09 <cmurf> the first one
16:28:11 <cmurf> yes
16:28:15 <tflink> to the people who disagree with the wording: answer the damn question - will you agree to anything other than 'all security issues'?
16:28:16 <adamw> i'll propose that again then
16:28:36 <adamw> propose #agreed it's agreed in principle that security issues not fixable by an update must be resolved before final release
16:28:50 <cmurf> i'm fine with a committe of reasonable people making reasonable choices on demand, but adamw wants something in writing to point to
16:29:16 <cmurf> ack
16:29:21 <tflink> I still think that's too vague but it sounds like I'm pretty much the only one
16:29:29 <cmurf> it is too vague
16:29:37 <adamw> tflink: it's an agreement-in-principle, not a solid criterion i'm going to put in the list.
16:29:46 <tflink> not nak - i don't like it but I don't see the point in holding up the meeting more
16:29:49 <adamw> we'll draft it up and discuss it on list, but there's no need to hold up the meeting for it.
16:30:03 <cmurf> tflink: that's my position
16:30:07 <cmurf> exactly
16:30:18 <adamw> i just feel like we need a general basis to take the bug as a blocker, rather than just It Is So Written
16:30:30 <cmurf> i understand
16:30:44 <adamw> so i count two not-nacks =)
16:30:46 <adamw> anyone else?
16:31:12 <adamw> propose #agreed it's agreed in principle that security issues above a certain severity level (to be decided) not fixable by an update must be resolved before final release
16:31:15 <adamw> how's that?
16:31:45 <tflink> that's better but I have a feeling that we're going to catch flak for the new criterion :)
16:31:51 <tflink> ack - let's move on
16:32:01 <cmurf> i'm fine with that too, but it's putting someone on a hook very explicitly for deciding the clarity in the future
16:32:50 <adamw> tflink: well as i remember, this has come up before and we've always vaguely thought there needs to be some kind of security criterion.
16:32:58 <adamw> #agreed it's agreed in principle that security issues above a certain severity level (to be decided) not fixable by an update must be resolved before final release
16:34:06 <tflink> proposed #agreed 868519 - RejectedBlocker (beta), AcceptedNTH (beta), AcceptedBlocker (final) - This does not violate any F18 beta release criteria and is thus rejected as a blocker for F18. Following the agreement above, this is provisionally accepted as a blocker for F18 final and NTH for F18 beta.
16:34:10 <cmurf> ack, however for adamw and tflink's sake i'd say you're better off with the original one we acked
16:34:15 <adamw> ack
16:34:21 <cmurf> ack
16:34:24 <akshayvyas> ack
16:34:27 <tflink> #agreed 868519 - RejectedBlocker (beta), AcceptedNTH (beta), AcceptedBlocker (final) - This does not violate any F18 beta release criteria and is thus rejected as a blocker for F18. Following the agreement above, this is provisionally accepted as a blocker for F18 final and NTH for F18 beta.
16:34:39 <tflink> #topic (848764) default mediacheck on 18 Alpha RC2 discs does not work
16:34:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=848764
16:34:40 <tflink> #info Proposed Blocker, anaconda, POST
16:35:39 * tflink thinks this is final, not beta
16:36:00 <jreznik> sorry, I got disconnected and had a problem with reconnecting :(
16:36:09 <cmurf> +1 blocker (final)
16:36:26 <tflink> jreznik: no worries, we decided that you'll be on the hook for all security issues in F18 - you didn't miss much :-D
16:36:28 <adamw> yeah, -1 beta +1 final, per the criterion cited
16:36:38 <adamw> also you have to go get me a coffee.
16:37:16 * jreznik can do it but never ever drinked coffee, so it would be an experiement... should not drink coffee
16:37:45 <adamw> never drank coffee? how the hell did we hire him? :)
16:37:54 <tflink> proposed #agreed 848764 - RejectedBlocker (beta), AcceptedNTH (beta), AcceptedBlocker (Final) - This does not violate any criteria for F18 beta and thus is rejected as a blocker for beta. However, it does violate the following F18 final release criterion and thus is accepted as NTH for beta and blocker for final: "If there is an embedded checksum in the image, it must match. If there is a related UI element displayed after booting the image, it must work a
16:38:02 <tflink> is that too long?
16:38:04 <adamw> yep
16:38:11 <adamw> cut off at 'must work a'
16:39:07 <tflink> proposed #agreed 848764 - RejectedBlocker(beta), AcceptedNTH(beta), AcceptedBlocker(Final) - This doesn't violate any criteria for F18 beta and is rejected as a blocker. However, it does violate the following F18 final criterion and thus is accepted as NTH for beta and blocker for final: "If there is an embedded checksum in the image, it must match. If there is a related UI element displayed after booting the image, it must work and display the correct res
16:39:13 <tflink> I think that's enough?
16:39:18 <adamw> 'correct res'
16:39:22 <tflink> 3 chars
16:39:23 <adamw> so three more characters =)
16:39:35 <cmurf> remove "any"
16:39:36 <zodbot> Ticket notification - f18betanicetohave: [Bug 868519] LUKS passphrase exposed in /root/anaconda-ks.cfg <https://bugzilla.redhat.com/show_bug.cgi?id=868519>
16:39:53 <tflink> proposed #agreed 848764 - RejectedBlocker(beta), AcceptedNTH(beta), AcceptedBlocker(Final) - This doesn't violate any criteria for F18 beta and is rejected as a blocker. However, it does violate the following F18 final criterion and thus is accepted as beta NTH and final blocker: "If there is an embedded checksum in the image, it must match. If there is a related UI element displayed after booting the image, it must work and display the correct result"
16:40:35 <cmurf> ack
16:40:59 <akshayvyas> ack
16:41:47 <tflink> #agreed 848764 - RejectedBlocker(beta), AcceptedNTH(beta), AcceptedBlocker(Final) - This doesn't violate any criteria for F18 beta and is rejected as a blocker. However, it does violate the following F18 final criterion and thus is accepted as beta NTH and final blocker: "If there is an embedded checksum in the image, it must match. If there is a related UI element displayed after booting the image, it must work and display the correct result"
16:41:54 <tflink> #topic (858801) [zh_TW] Please add Chinese (Taiwan) language to language selection menu in anaconda
16:41:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=858801
16:41:59 <tflink> #info Proposed Blocker, anaconda, POST
16:43:49 <tflink> not sure this is beta
16:44:06 <tflink> the closest release criterion I'm seeing is for final: All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use
16:44:43 <adamw> well, this would be a 'conditional breakage' case i guess.
16:45:05 <adamw> that criterion applies to desktops specifically, doesn't really hit anaconda.
16:45:09 <tflink> being able to use the installer if you speak traditional chinese?
16:45:25 <cmurf> There should be a fallback for Taiwan? It's Standard Chinese.
16:45:26 <tflink> adamw: using the graphical installer is listed as a critical path action, though
16:45:42 <adamw> yeah. well, even then I think you could just pick Hong Kong and get by, or there'll be some other option for Traditional as cmurf suggests. but i don't really know for sure.
16:45:54 <adamw> tflink: it says 'critical path actions on release-blocking desktops', not just 'critical path actions'.
16:46:21 <adamw> i kinda feel like notablocker
16:46:37 <jreznik> nonblocker for me
16:46:39 <tflink> for me, it depends on whether there is another traditional chinese option
16:46:41 <cmurf> Is there a Standard Chinese option?
16:46:49 <cmurf> even if it says Hong Kong or whatever?
16:46:57 <tflink> if the only option is simplified, I'd say final blocker, beta nth
16:47:40 <adamw> TC6 only offers simplified
16:47:46 <adamw> only thing in the list is 'Chinese (China)'
16:47:46 <cmurf> Standard Chinese includes both Traditional and Simplified, so either one qualifies
16:47:57 <jreznik> the question is - do we consider english as fallback for other languages?
16:47:58 <cmurf> OK well surely that's Mandarin so fine
16:48:00 <tflink> then +1 beta nth, +1 final blocker
16:48:03 <zodbot> Ticket notification - f18betanicetohave: [Bug 848764] default mediacheck on 18 Alpha RC2 discs does not work <https://bugzilla.redhat.com/show_bug.cgi?id=848764>
16:48:07 <adamw> cmurf: written chinese is different from spoken.
16:48:14 <adamw> cmurf: in written there is Traditional and Simplified.
16:48:17 <tflink> cmurf: simplified chinese and traditional chinese are written differently
16:48:20 <adamw> in spoken there is Mandarin and Cantonese.
16:48:25 <cmurf> yes i know all of this
16:48:26 <adamw> tflink: even that's not quite right, there is no simple mapping.
16:48:49 <tflink> can be written differently
16:48:49 <adamw> Taiwan writes Traditional and speaks Mandarin. China writes Simplified and speaks Mandarin (mostly). HK writes Traditional and speaks Cantonese.
16:49:06 <adamw> obviously we're only concerned with the writing though, really.
16:49:13 <tflink> yeah, I was talking about written - the installer doesn't speak (that I know of)
16:49:18 <adamw> so aiui, anyone from TW or HK could use each other's options
16:49:38 <adamw> we'd need an actual chinesey person to tell for sure though, i guess. =)
16:49:41 <cmurf> I think it's a final blocker if you don't have both, but if you have one for beta it's fine
16:49:52 <adamw> yeah, shall we say not a beta blocker and punt the final question?
16:50:52 <tflink> I'm OK with not a beta blocker - beta NTH?
16:50:55 <adamw> sure
16:50:59 <cmurf> )
16:51:01 <cmurf> oops
16:51:02 <cmurf> 0
16:51:49 <akshayvyas> hey i cant see option of Chinese
16:51:58 <adamw> akshayvyas: it's way down the bottom
16:52:04 <adamw> akshayvyas: second-to-last on the list
16:52:14 <adamw> dunno why. I am not entirely sure how the ordering works. unicode?
16:52:15 <akshayvyas> yeah
16:52:30 <akshayvyas> just one not sure its simplified
16:52:37 <akshayvyas> or the traditional
16:52:39 <adamw> it'd be Simplified, as it's the China locale.
16:52:54 <adamw> tflink: proposal?
16:52:57 <tflink> proposed #agreed 858801 - RejectedBlocker (beta), AcceptedNTH (beta) - There are no translation requirements for beta and this is rejected as a blocker for beta. However, a tested patch would be accepted after beta freeze to add traditional chinese. Please re-propose as a final blocker for later review
16:53:02 <akshayvyas> ack
16:53:21 <jreznik> ack
16:53:42 <cmurf> ack
16:53:52 <tflink> #agreed 858801 - RejectedBlocker (beta), AcceptedNTH (beta) - There are no translation requirements for beta and this is rejected as a blocker for beta. However, a tested patch would be accepted after beta freeze to add traditional chinese. Please re-propose as a final blocker for later review
16:54:30 <tflink> #topic (862784) newUI custom partitioning does not allow formatting of an existing partition for use in the installed system
16:54:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862784
16:54:35 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:55:43 <adamw> so we still didn't nail down the partitioning criteria
16:55:48 <tflink> and we still don't have input on the partitioning criteria
16:55:50 <adamw> but i'm gonna go out on a limb and suggest this should not be covered
16:56:05 <cmurf> yeah
16:56:06 <adamw> i think for Beta we possibly want to cover re-use of /home without reformatting it, but i can't see a case for covering re-use beyond that
16:56:13 <cmurf> delete teh partition make a new one identical to it, format it
16:56:15 <cmurf> what's the big deal
16:56:18 <adamw> yeah, there's all sorts of workarounds
16:56:29 <zodbot> Ticket notification - f18betanicetohave: [Bug 858801] [zh_TW] Please add Chinese (Taiwan) language to language selection menu in anaconda <https://bugzilla.redhat.com/show_bug.cgi?id=858801>
16:57:14 <cmurf> looks like 18.20 has a reformat checkbox now
16:57:34 <adamw> yeah, it's changed, but we still theoretically have to decide on status. of course we could keep punting till it goes away :)
16:57:52 <cmurf> -1 beta blocker
16:57:56 <tflink> do we have an 18.20 build? last night's failed and it sounded like they were waiting until the end of the day to try again
16:58:16 <tflink> punt?
16:58:45 <cmurf> -1
16:59:08 <adamw> i'm okay with -1 or punt
16:59:13 <cmurf> 18.20 failed
16:59:41 <tflink> sounds like we're -1 blocker over all
16:59:56 * tflink doesn't have a strong opinion either way
17:00:25 <adamw> anyone else?
17:01:07 <tflink> proposed #agreed 862784 - RejectedBlocker (beta) - This doesn't violate any of the F18 beta release requirements, seems unlikely to hit any proposed revisions and has several reasonable workarounds.
17:01:18 <akshayvyas> ack
17:01:25 <cmurf> ack
17:02:10 <adamw> ack
17:02:13 <tflink> #agreed 862784 - RejectedBlocker (beta) - This doesn't violate any of the F18 beta release requirements, seems unlikely to hit any proposed revisions and has several reasonable workarounds.
17:02:22 <tflink> #topic (868777) fail to install the system use vnc
17:02:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868777
17:02:22 <tflink> #info Proposed Blocker, anaconda, NEW
17:03:00 <tflink> crap, I forgot to finish digging into this one
17:03:17 <tflink> I had problems with vnc w/ PXE and dhcp on i686
17:03:26 <tflink> haven't seen issues on x64, though
17:03:50 <adamw> hum, someone else said no issues with PXE
17:04:10 <tflink> under x64, I haven't seen any issues with vnc and PXE
17:04:14 <tflink> it was just i686
17:04:46 <tflink> i have no idea if it's the same bug, though
17:05:01 <tflink> nothing on the local screen, vnc session didn't start up
17:05:14 <cmurf> that would seem to be a blocking bug
17:05:15 <tflink> but I forgot to dig into it more and don't have access to that machine ATM
17:05:38 <tflink> I wouldn't be surprised if it was a different bug, though
17:05:54 <tflink> I'm ok with rejecting this - I'll repropose if I turn out to be wrong
17:06:14 <adamw> i'm okay with that or punt
17:06:43 <akshayvyas> i think punt is okay
17:06:45 <cmurf> so comment 4 makes me wonder if this is something else and vnc not coming up is a consequence
17:07:14 <tflink> proposed #agreed 868777 - RejectedBlocker (beta) - Since this seems to only affect VNC installs with media and dhcp, there are several workable workarounds and it was decided that this is not a blocker for f18 beta
17:07:23 <cmurf> ack
17:07:29 <akshayvyas> ack
17:07:58 <adamw> ack
17:08:08 <tflink> #agreed 868777 - RejectedBlocker (beta) - Since this seems to only affect VNC installs with media and dhcp, there are several workable workarounds and it was decided that this is not a blocker for f18 beta.
17:08:14 <tflink> #topic (869091) Gnome fails to install in TC6 Beta netinstall
17:08:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869091
17:08:14 <tflink> #info Proposed Blocker, distribution, NEW
17:09:19 <cmurf> uhoh
17:09:23 <tflink> punt?
17:09:31 <tflink> there is certainly not enough info to accept as a blocker
17:09:43 <tflink> I'm leaning more towards reject, though
17:10:03 <adamw> well
17:10:08 <adamw> i might lean towards CLOSED NOTABUG
17:10:13 <cmurf> yeah
17:10:16 <cmurf> exactly
17:10:17 <adamw> on the basis it seems to have been a transient error, can't be reproduced
17:10:26 <adamw> but rejecting as a blocker on that basis doesn't make any sense
17:10:36 <tflink> adamw: which is not mutually exclusive w/ rejecting :)
17:10:49 <tflink> I suppose you have a point
17:10:54 <adamw> tflink: no, but to me that isn't a logical ground for leaving the bug open but rejecting it as a blocker
17:10:55 <tflink> either way works for me
17:10:57 <adamw> either it's a valid bug or it isn't
17:11:04 * nirik notes beta freeze is being discussed by fesco in #fedora-meeting.
17:11:12 <adamw> if it's not valid, then it should be closed; if it's valid, then 'we don't think it's valid' doesn't make any sense as a reason for rejecting it :)
17:11:18 <tflink> pause for fesco meeting?
17:11:20 <adamw> sure
17:11:30 <cmurf> notabug
17:15:54 * adamw starts up a netinst test in the mean time
17:16:18 <akshayvyas> +1 NEEDINFO
17:24:18 * satellit TC 6 and DVD and netinstall x86_64 work fine for me
17:24:38 <adamw> satellit: default net install, of GNOME?
17:24:48 <satellit> yes
17:25:24 <satellit> see test page
17:25:46 <adamw> OK
17:25:57 <adamw> i'm running one ATM and the installed package count looks about right, 1175
17:26:10 <adamw> so i'm OK with just saying this does not appear to be reproducible, close it, re-open if dan can reproduce
17:26:20 <satellit> +1
17:28:44 <cmurf> +1
17:29:26 <adamw> propose #agreed 869091 does not seem to be reproducible by anyone else, others have run successful GNOME netinstalls with TC6, and the reporter has provided no data to diagnose the issue. Bug will be closed as WORKSFORME, reporter can re-open if he can reproduce and provide data
17:29:49 <tflink> ack
17:31:53 <akshayvyas> ack
17:34:10 <adamw> #agreed 869091 does not seem to be reproducible by anyone else, others have run successful GNOME netinstalls with TC6, and the reporter has provided no data to diagnose the issue. Bug will be closed as WORKSFORME, reporter can re-open if he can reproduce and provide data
17:34:37 <dreamreal> adamw: I put in TC6 with the netinstall in vbox, it worked for me
17:35:07 <adamw> so another data point, thanks
17:35:31 <cmurf> ack
17:53:14 <jreznik_> adamw: as I said, jskladan was already testing git bits, so he can retry the latest version and we are close to have a real package, so...
17:54:32 <adamw> yeah.
18:09:38 <tflink> #topic (867118) limit bugzilla summary to 255 chars
18:09:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=867118
18:09:39 <tflink> #info Proposed Blocker, libreport, MODIFIED
18:10:51 <tflink> and thus, it begins ...
18:10:55 <adamw> in general i'm pretty -1 on conditional libreport bugs
18:11:26 <adamw> i'm comfortable with a fairly strict interpretation of the criterion, so that only things which mean a _lot_ of automatic crash reports are going to fail get to be blockers
18:11:35 <adamw> given that i've never ever seen this happen, it seems like kind of a corner case.
18:11:41 <cmurf> it happend to me
18:11:44 <tflink> yeah, I'm pretty much in the same boat
18:12:03 <tflink> for final, maybe but for beta ... nth at most
18:12:13 <adamw> i'm +1 nth.
18:12:16 <cmurf> this bug prevents bugs from being filed because it's completely non-obvious why it's failing to file
18:12:31 <adamw> sure, it's just a question of how many we're going to lose.
18:12:36 <jmoskovc> that bug is fixed and update is already in bodhi...
18:12:43 <adamw> i think this one would fail the 'do we freeze for it on the last day' test
18:12:48 <adamw> er, 'slip'
18:12:53 <cmurf> absolutely not
18:12:57 <tflink> we're already freezing :)
18:13:03 <tflink> cmurf: then not a blocker, to be honest
18:13:08 <cmurf> if it's important to get autofiled bugs, this would get fixed with or without blocker
18:13:24 <cmurf> i'm -1 btw
18:13:34 <cmurf> i wouldn't even clutter nth with it
18:14:06 <akshayvyas> -1 blocker
18:14:34 <tflink> proposed #agreed 867118 - RejectedBlocker, AcceptedNTH - This doesn't seem to prevent enough bug reports to justify taking as a blocker. However, it could affect bug reporting in the installer and a well tested fix would be accepted past final.
18:14:44 <cmurf> ack
18:14:48 <akshayvyas> ack
18:15:12 <adamw> ack
18:15:16 <adamw> er
18:15:18 <adamw> patch
18:15:19 <adamw> past freeze
18:15:26 <tflink> oh, thanks
18:15:32 <tflink> proposed #agreed 867118 - RejectedBlocker, AcceptedNTH - This doesn't seem to prevent enough bug reports to justify taking as a blocker. However, it could affect bug reporting in the installer and a well tested fix would be accepted past freeze.
18:15:37 * tflink assumes that votes hold
18:15:44 <tflink> #agreed 867118 - RejectedBlocker, AcceptedNTH - This doesn't seem to prevent enough bug reports to justify taking as a blocker. However, it could affect bug reporting in the installer and a well tested fix would be accepted past freeze.
18:15:44 <cmurf> ack
18:15:55 <tflink> ok, that's all of the proposed blockers on my list
18:16:08 <tflink> there are no proposed NTH
18:16:13 <cmurf> wow
18:16:20 <cmurf> time for beta to be released
18:16:21 <cmurf> hha
18:16:23 <tflink> let's get through the accepted blockers quick so we can start poking at fedup
18:16:45 <adamw> sure
18:16:48 <tflink> #topic (863348) ValueError: Cannot remove non-leaf device 'vda2'
18:16:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863348
18:16:48 <tflink> #info Accepted Blocker, anaconda, POST
18:17:22 <adamw> we really need anaconda team to get off their asses on this one.
18:17:40 <cmurf> fixed?
18:18:03 <tflink> who knows
18:18:52 <cmurf> the lack of an up front "blow away disk" vs "use free space" vs "other" is… a difficult Ux
18:19:06 <adamw> out of scope
18:19:24 <tflink> we haven't seen new reports for a week now
18:19:32 <cmurf> it's the premise of this bug though
18:19:36 <tflink> we could just leave it for another week and close if there are no new reports
18:19:41 <cmurf> yep
18:19:53 <adamw> wait a sec
18:20:13 <adamw> cmurf: not really, the bug is for anaconda crashing when trying to remove partitions. nothing to do with the UI.
18:20:26 <adamw> okay, clumens just updated and said this was committed since 18.17
18:20:44 <adamw> so we should check it's fixed and close it
18:20:47 <zodbot> Ticket notification - f18betanicetohave: [Bug 867118] limit bugzilla summary to 255 chars <https://bugzilla.redhat.com/show_bug.cgi?id=867118>
18:21:03 <tflink> #info a fix for this was included in anaconda-18.17-1
18:21:15 <tflink> #info request re-testing and close as verified when fixed
18:21:26 <tflink> it should be in ON_QA, then, I suppose
18:22:04 <adamw> i'll deal with it
18:22:07 <adamw> in fact i already did
18:22:09 <tflink> anything else on this bug?
18:22:25 <adamw> nup
18:22:26 <cmurf> nope - but i thin it's squashed because i've done a few of these reclaims and no crashes
18:22:33 <tflink> #topic (866519) BIOS RAID is not shown on harddrive screen
18:22:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866519
18:22:33 <tflink> #info Accepted Blocker, anaconda, NEW
18:22:35 <cmurf> in fact since 18.18 i haven't had any crashes
18:22:39 <adamw> yeah, me too. but it'd be good to find a definite reproducer and check for sure.
18:23:07 <tflink> #info no movement on this since last reviewed 2 days ago
18:23:17 <adamw> pretty much in anaconda team's hands, i think.
18:24:02 <cmurf> hmm
18:24:05 <tflink> #info waiting for info and/or a fix from anaconda devs
18:24:19 <tflink> #topic (866115) ValueError: ('invalid size specification', '0 b')
18:24:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866115
18:24:20 <tflink> #info Accepted Blocker, anaconda, MODIFIED
18:24:32 <cmurf> so comment 20 is dlehman suggesting that partitionable md raid is not supported/supportable?
18:25:01 <tflink> cmurf: no, just that is likely related to the cause of the problem
18:25:07 <adamw> right, just defining the cause.
18:25:09 <cmurf> ok
18:26:17 <adamw> looks like this should be in 18.20, so just needs testing
18:26:23 <adamw> when we have a build of course
18:26:35 <tflink> #info fix for this should be in anaconda-18.20-1
18:26:53 <tflink> #info test when the new build is available, add reports to bug
18:27:09 <tflink> #topic (862613) ValueError: cannot initialize a disk that has partitions
18:27:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862613
18:27:10 <tflink> #info Accepted Blocker, anaconda, NEW
18:27:37 <tflink> I hit this with anaconda-18.91-1
18:27:45 <tflink> er, 18.19-1
18:28:02 <cmurf> ouch
18:28:21 <tflink> I added logs yesterday, waiting for requests for more info or a fix to test
18:28:30 <cmurf> i had high hopes for 18.19 i haven't hit this one
18:28:43 <tflink> #info doesn't appear to have been fixed yet
18:29:03 <tflink> I can hit this 100% of the time on a particular system if I don't clear the partitions first
18:29:17 <tflink> #info waiting for request for more information or a fix to test
18:29:49 <tflink> #topic (863451) AttributeError: 'DeviceFormat' object has no attribute 'peStart'
18:29:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863451
18:29:54 <tflink> #info Accepted Blocker, anaconda, NEW
18:30:24 <tflink> #info no movement on this since last week, still waiting for attention from anaconda devs
18:31:05 <tflink> not sure there is much more to say unless someone wants to take an action to poke anaconda devs
18:32:06 <tflink> moving on ...
18:32:20 <tflink> #topic (855526) f18a tc6 anaconda cannot connect to a protected wireless network
18:32:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855526
18:32:26 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
18:33:12 <adamw> seems we're kind of waiting to see whether anaconda folks want to split this into a new report
18:33:20 <adamw> but there obviously appear still to be issues with the wireless support
18:33:54 <tflink> #info this doesn't appear to be completely fixed yet
18:34:10 * kparal tips his hat
18:34:38 * adamw catches kparal's hat
18:34:46 <tflink> #info waiting to see how anaconda devs want to handle the bug - split it or keep it as one bug
18:35:41 <tflink> #topic (867071) NameError: global name 'anaconda' is not defined
18:35:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=867071
18:35:42 <tflink> #info Accepted Blocker, anaconda, MODIFIED
18:35:59 <tflink> it looks like this might have been fixed to the point where it's not a blocker anymore
18:36:09 <tflink> no new reports in a week
18:36:54 <tflink> if it's not fixed in a week, close it?
18:36:59 <adamw> should be fixed in at least 18.18
18:37:01 <tflink> any other thoughts
18:37:07 <adamw> so we can set ON_QA and ask for re-testing
18:37:19 <tflink> #info this should be fixed in the latest ananconda builds
18:37:25 <adamw> well
18:37:31 <adamw> i think we have enough tests of TC6 now just to close this
18:37:47 <tflink> c#25 makes we wonder if we can close it
18:37:56 <tflink> not a blocker anymore if we don't, though
18:37:56 <adamw> it's clearly been fixed in the code
18:38:07 <adamw> no-one's hitting it any more, and it seems like you hit it pretty easily when it was active
18:38:20 <adamw> i know i've done minimal installs of TC6, which is how you hit it...
18:38:28 <adamw> i say we just close it
18:38:31 <tflink> adamw: the release blocking effects of this bug are fixed, yes
18:38:46 <tflink> but according to c#25, there is still no anaconda global
18:38:55 <tflink> it just isn't causing the installation to fail any more
18:39:04 <tflink> either way, though
18:39:18 <tflink> #undo
18:39:18 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x14a834d0>
18:39:23 <adamw> um
18:39:30 <adamw> as i read comment #25, there isn't *meant* to be an anaconda global for fedora
18:39:48 <adamw> the anaconda global is used in rhel, and a commit from rhel was cherry-picked into fedora without it being changed, hence the problem
18:40:01 <tflink> #info this appears to have been fixed in recent anaconda builds and there have been no new reports on a bug that used to be easy to hit
18:40:01 <adamw> so as soon as that's corrected, i don't see that there's a bug any more
18:40:15 <tflink> ok
18:40:17 <adamw> i don't think we still have a bug for 'implement an anaconda global' or anything, i don't think that's the situation.
18:40:35 <tflink> #info this can be closed
18:41:08 <tflink> anything else on this bug?
18:41:38 <adamw> nope
18:41:43 <tflink> #topic (866486) Apper: cannot perform system update
18:41:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866486
18:41:43 <tflink> #info Accepted Blocker, apper, ASSIGNED
18:41:56 <tflink> it sounds like we have progress on this bug
18:42:03 <tflink> and that it is still not working for a default install
18:42:28 <adamw> yeah
18:42:28 <tflink> #info progress has been made on this - it works when updates are set to never but doesn't work for the default install
18:42:34 <adamw> maybe we need hughsie in on it, if the bug affects pkcon also
18:42:47 <weld> jreznik, hi, the ics files from http://jreznik.fedorapeople.org/schedules/f-18/ no longer contain events (just tasks), is that intentional or an error?
18:42:47 <tflink> #info dialoge between testers and devs is taking place, waiting for a new fix
18:42:51 <adamw> although it seems to depend on the setting of KDE's 'check for updates' function, as i read it
18:43:14 <adamw> i might check this and see if i can confirm Martin's results.
18:43:40 <kparal> I think Jan Sedlak saw it as well
18:44:23 <kparal> we can flag him with needinfo if needed
18:44:43 <tflink> #info more testing would be useful to confirm the findings stated in the bug
18:45:09 <tflink> anything else on this?
18:45:29 <adamw> can't think of anything
18:45:38 <tflink> well, that's all of the accepted blockers
18:45:43 <tflink> which means that it's time for ...
18:45:48 <tflink> #topic Open FLoor
18:45:51 <tflink> #undo
18:45:51 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x155dead0>
18:45:54 <tflink> #topic Open Floor
18:46:19 <tflink> Anything else that should be brought up?
18:47:03 <cmurf> nothing thinking of anything
18:47:09 <adamw> me either
18:47:22 <cmurf> security criteria *yawn*, partitioniong criteria *YAWN*
18:47:25 <tflink> ok, on to testing fedup
18:47:48 <tflink> #info the next blocker review meeting will be 2012-10-31 @ 16:00 UTC
18:47:49 <cmurf> heck i can barely type. it's not even 1pm.
18:47:58 <kparal> tflink: it works already?
18:48:03 <cmurf> haha
18:48:05 <cmurf> where is it?
18:48:07 <tflink> kparal: apparently we were supposed to be testing it already
18:48:16 <tflink> even though it's not packaged
18:48:23 <kparal> tflink: mkrizek tested it and it doesn't download vmlinuz+initrd, so grub menu doesn't work
18:48:25 <adamw> cmurf: in git.
18:48:30 <kparal> but it downloaded all rpms, that's fine
18:48:31 <tflink> don't get me started on this
18:48:59 <tflink> anyhow, fuse is set for [0,5] minutes
18:50:45 <tflink> thanks for coming, everyone
18:50:52 * tflink will send out minutes shortly
18:50:54 <tflink> #endmeeting