16:05:24 <tflink> #startmeeting f18beta-blocker-review-3
16:05:24 <zodbot> Meeting started Wed Oct 10 16:05:24 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:24 <tflink> #meetingname f18beta-blocker-review-3
16:05:24 <zodbot> The meeting name has been set to 'f18beta-blocker-review-3'
16:05:28 <tflink> #topic Roll Call
16:05:49 <adamw> morning
16:06:21 * kparal waves
16:06:40 <kparal> pschindl is waiting for his train home, he will come late
16:08:21 <tflink> late? That's unacceptable!
16:08:42 <kparal> jreznik_: perhaps around and ready for a qa meeting?
16:09:12 <kparal> Viking-Ice is around I assume
16:10:01 <akshayvyas> Viking-Ice: ping ping
16:10:40 <kparal> so... we have 3, maybe 4 people with akshayvyas ?
16:10:53 <akshayvyas> yeah
16:10:54 <tflink> yeah, enough to get started
16:10:58 <Viking-Ice> sorry half in half at Caused by: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name
16:11:07 * Viking-Ice in debug mode
16:11:18 <adamw> clearly, what you need is more objects.
16:11:28 <kparal> :))
16:11:30 <adamw> i'm helping! i'm helping!
16:12:11 <tflink> #topic Introduction
16:12:20 <tflink> Why are we here?
16:12:20 <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:12:28 <tflink> #info We'll be following the process outlined at:
16:12:28 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:12:35 <tflink> #info The bugs up for review today are available at:
16:12:35 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:43 <tflink> #info The criteria for release blocking bugs can be found at:
16:12:43 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:12:43 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:12:43 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:12:54 * kparal expected the answer to the meaning of life...
16:13:15 <tflink> kparal: reviewing blocker bugs, what else did you think the meaning of life could be?
16:13:23 <tflink> Up for review today are:
16:13:26 <adamw> qa is the meaning of life.
16:13:29 <tflink> #info 28 Proposed Blockers
16:13:29 <tflink> #info 10 Accepted Blockers
16:13:29 <tflink> #info 5 Proposed NTH
16:13:29 <tflink> #info 8 Accepted NTH
16:13:33 <kparal> tflink: ah, now I finally understand
16:13:56 <tflink> Any objections to capping the time of this meeting @ 3 hours?
16:14:04 <kparal> none
16:14:53 <tflink> anything not finished today will be done tomorrow - same time, same place
16:15:02 <adamw> ok here
16:15:06 <adamw> 28 proposed blockers? holy moley.
16:15:23 <tflink> hence the suspicion that we won't get through everything in 3 hours
16:16:11 <tflink> #info This meeting will be stopped at 3 hours - any remaining blocker bugs to review will be done tomorrow at a second gathering of reviewers
16:17:04 <tflink> any objections to starting with the proposed blockers?
16:17:12 <kparal> let's go
16:17:14 <akshayvyas> nope
16:17:26 <tflink> #chair adamw kparal
16:17:26 <zodbot> Current chairs: adamw kparal tflink
16:17:30 <tflink> #topic (847831) kickstart boot fails with %include file generated by %pre
16:17:30 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847831
16:17:30 <tflink> #info Proposed Blocker, ASSIGNED
16:17:55 <tflink> ah, this is the one I was supposed to try to reproduce
16:18:40 * tflink forgot to get to that :-/
16:18:59 <adamw> well now we at least know it's something to do with cobbler. orion thinks it'll affect cobbler deployments, which is obviously a concern
16:20:04 * jreznik is here, sorry for being late...
16:20:05 <tflink> have we gotten any farther on figuring out what parts of ks are going to be supported for F18?
16:20:52 <adamw> not really.
16:21:02 <adamw> i wish anaconda folks would turn up more for these meetings...
16:21:44 <kparal> the current criterion says the kickstart generated from default installation must work. as for ideal state for F18 Final, everything defined in kickstart should work correctly. it's hard to update anaconda afterwards (just updates.img, and doesn't have to work always)
16:22:01 <kparal> but I don't think we have such criterion currently, do we?
16:22:04 * kparal checks
16:22:19 <jreznik> makes sense to support everything default installation supports
16:22:23 <adamw> as i wrote in the bug, the general idea is we were going to review proposed kickstart blockers on a case-by-case basis and extend the criteria if we thought it necessary
16:22:34 <adamw> since no-one seemed to really have a plan for what should be in the kickstart criteria
16:22:56 <tflink> kparal: I don't read it quite that way - it says that ks should be able to replicate what's done in the interactive installer
16:23:34 <tflink> I'd still like to figure out if it's just cobbler or all %include
16:23:40 <kparal> see adam's comment 20, third paragrap
16:23:41 <kparal> h
16:24:34 <adamw> the idea of the current criterion is that you do a straight-through all-defaults interactive install, take the ks generated, feed it back into anaconda, and it should work.
16:24:36 <tflink> ah, I forgot about that
16:24:50 <adamw> that's all it covers. but the express idea was that we would extend the criteria based on 'case law' (proposed blockers).
16:24:50 <kparal> because we haven't tested it, why don't we ask Orion to try it for us?
16:25:21 * kparal tries basic ks now
16:25:46 * Viking-Ice aha java code not like / in o=
16:25:48 <adamw> given how this bug is described i doubt it would affect that test. there's no %include in %pre.
16:25:49 <Viking-Ice> back
16:27:19 <tflink> so we're pretty much in the same place we were last week?
16:27:33 <kparal> yes
16:27:33 <tflink> someone needs to poke at this and not forget to do so?
16:27:44 <tflink> not that I would ever forget to do that ...
16:27:46 * kparal notes his inst.ks= argument was ignored, weird
16:27:59 <adamw> we should give it to tflink, he never forgets stuff.
16:28:36 <tflink> exactly :-D
16:28:45 * jreznik forgets stuff but can help to poke people :)
16:29:21 <tflink> so punt for more testing?
16:29:44 <Viking-Ice> yup
16:29:44 <kparal> yes. I have just found out that inst.ks is completely ignored, at least in my attempt
16:29:46 <adamw> yeah.
16:30:16 <adamw> kparal: are you sure it was ignored, or is it just that it's not a completely interactive ks and you have to do some things manually still?
16:30:28 <kparal> hmm
16:30:37 <adamw> kparal: the installer-generated kickstart has always had partitioning commented out, so not fully interactive (currently in f18 it doesn't seem to write the partitioning stuff even commented-out)
16:30:39 <adamw> erf
16:30:43 <adamw> fully *unattended*
16:30:44 <kparal> I'll work on that
16:31:00 <kparal> it was unattended for F17
16:31:30 <adamw> not until you uncommented the partitioning lines..
16:31:34 <tflink> proposed #agreed 847831 - This still needs more testing, will revisit when there is more understanding of what parts of kickstart are affected here
16:31:38 <adamw> ack
16:31:41 <kparal> ack
16:31:43 <Viking-Ice> ack and I in anycase I think our criteria is good
16:31:48 <akshayvyas> ack
16:31:54 <jreznik> ack
16:31:57 <tflink> #agreed 847831 - This still needs more testing, will revisit when there is more understanding of what parts of kickstart are affected here
16:32:03 <kparal> let's also ask Orion to help us with generic ks testing
16:32:03 <tflink> #topic (856362) KeyError: 'la-latin1'
16:32:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856362
16:32:03 <tflink> #info Proposed Blocker, POST
16:32:19 <tflink> kparal: that probably wouldn't hurt
16:32:47 <kparal> this is preupgrade bug
16:32:47 <adamw> still can't decide on this one as we still don't have the upgrade tool.
16:32:52 <adamw> punt it again.
16:32:58 <kparal> agreed
16:33:07 <Viking-Ice> agreed
16:33:35 <tflink> proposed #agreed 856362 - This is an upgrade issue and we still can't confirm whether or not the new tools is affected by it. Will revisit after we have a testable upgrade tool
16:33:35 <jreznik> ok
16:33:45 * tflink wonders whether preupgrade should be retired in F17
16:34:04 <jreznik> tflink: if it does not correctly upgrade -> yes, it should be
16:34:16 <Viking-Ice> ack
16:34:20 <tflink> I bet we're going to get plenty of reports of preupgrade not working otherwise
16:34:27 <kparal> ack
16:34:41 <jreznik> tflink: actually, people already started complaining
16:35:04 <tflink> #agreed 856362 - This is an upgrade issue and we still can't confirm whether or not the new tools is affected by it. Will revisit after we have a testable upgrade tool
16:35:35 <tflink> has the documentation for upgrade been adjusted yet to say that preupgrade no longer works?
16:36:15 <jreznik> I bet no, I'll take an action on this
16:36:35 <tflink> yeah, doesn't look like it has been updated
16:37:23 <adamw> well, the docs are really meant to cover stable releases, so careful how you word it - preupgrade's still The Way for our current stable release.
16:37:57 <Viking-Ice> brb
16:37:59 <tflink> I still think that a warning that preupgrade won't work for F18 might be a good idea
16:38:27 <adamw> sure, just make it clear
16:38:28 <tflink> not sure there is a point in doing too much documentation before we actually have the tool
16:38:32 <adamw> next bug!
16:38:34 <akshayvyas> preupgrade is suppose to work, we r in beta now
16:38:47 <jreznik> akshayvyas: preupgrade is retired tool
16:38:58 <tflink> akshayvyas: upgrade is supposed to work by the time beta is released, yes. preupgrade as a tool is due to be retired
16:39:02 <zodbot> Ticket notification - f18betanicetohave: [Bug 865031] Black screen when booting on iMac12,2 (27" 2011 model) <https://bugzilla.redhat.com/show_bug.cgi?id=865031>
16:39:09 <akshayvyas> oh ohk
16:39:19 <tflink> are we sure this is only a preupgrade issue?
16:39:38 <tflink> see c#28
16:40:52 <adamw> tflink: going around the merry-go-round again, no it isn't, but that appears to be the only case we care about.
16:41:23 <kparal> I think it is related to 858591
16:41:34 <kparal> it will probably appear again with the new tool as well
16:41:42 <kparal> but let's skip now
16:41:49 <kparal> we don't really know
16:41:53 <tflink> ok, works for me
16:42:32 <tflink> any objections to skipping preupgrade bugs today?
16:42:41 <kparal> +1 to that
16:42:55 <adamw> yeah
16:42:59 <akshayvyas> +1
16:43:04 <tflink> #topic (862006) NameError: global name 'size_func_kwargs' is not defined
16:43:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862006
16:43:04 <tflink> #info Proposed Blocker, POST
16:44:13 <tflink> did we get a resolution to the whole 'is LVM supported' question?
16:45:38 <kparal> we could argue that LVM might not be supported, but then the option should be removed and it should not crash
16:45:41 <adamw> er. it looks like we didn't really do anything about that. sigh. so much to do...
16:45:55 <tflink> I'm starting an action list from the meeting
16:46:03 <jreznik> tflink: +1
16:46:15 <tflink> I'm not volunteering to do it all, just trying to keep track of all the stuff that needs to get done
16:46:20 * jreznik is writing down action items on the paper where he should poke around
16:46:57 <adamw> we didn't set a #action for this one last week
16:47:01 <jreznik> tflink: and as always, I'm here to help and it would be great to have such action item list... so could we use #action more in the meeting?
16:47:07 <adamw> i poked #anaconda during the meeting but probably never got a reply and forgot about it
16:47:08 <kparal> pschindl: welcome!
16:47:20 <adamw> so yeah, we should track action items and set them.
16:47:30 <tflink> any volunteers for this one?
16:47:44 <tflink> or can we do generic action items?
16:48:04 <adamw> i'll take it
16:48:04 * pschindl was delayed by our excelent czech railways
16:48:58 <adamw> #action adamw to discuss with anaconda team whether LVM ought to be release blocking and make a proposal to the list (re 862006)
16:49:06 <tflink> adamw: you beat me to it
16:49:14 <adamw> i win the prize
16:49:22 <tflink> yeah, the action item :)
16:49:22 <Viking-Ice> lwn ought to be release blocking
16:49:26 <Viking-Ice> anaconda does not decide that
16:49:38 <jreznik> adamw: wouldn't be better to collect everything we need from anaconda in one place? than just having separate action items?
16:50:03 <adamw> Viking-Ice: i'd want to have their input, doesn't mean they decide anything.
16:50:05 <Viking-Ice> it was the default partitioning layout and until all release that had it as such have gone EOL we can remove that criteria
16:50:18 <tflink> proposed #agreed 862006 - We still need to figure out whether LVM is considered a release blocking 'filesystem' will revisit once that question is answered
16:50:30 <adamw> ack
16:50:33 <Viking-Ice> nack we just decide that here and now
16:50:37 <tflink> jreznik: we can collect all of the action items after the meeting, I think
16:50:54 <tflink> since meetbot makes a list @ the end of the minutes
16:50:56 <jreznik> yep, let's do that this way
16:51:10 <jreznik> well previous action items should be readded
16:51:23 <tflink> I have those written down elsewhere
16:51:35 <tflink> we can formalize them in open floor or just add them afterwards
16:51:46 <jreznik> ok, let's continue with review
16:52:09 <tflink> we have 1 ack and 1 nak
16:52:55 <jreznik> ack
16:52:56 * tflink is waiting for more
16:53:01 <akshayvyas> ack
16:53:03 <jreznik> sorry, I didn't realized that...
16:53:28 <kparal> ack
16:53:33 <tflink> 4 ack, 1 nak
16:53:36 <Viking-Ice> we can just decide this ourself no need to run to anaconda or fesco or whom else
16:53:59 <kparal> Viking-Ice: why can't dictate this, we have no position to do so
16:54:16 <jreznik> Viking-Ice: if engineers decide not to continue with LVM, it does not make sense for QA to have it in release criteria and test it
16:54:36 <adamw> well, i think it's pretty clear there'll be LVM support in anaconda.
16:54:37 <adamw> hum
16:54:39 <adamw> i have an idea
16:54:41 <kparal> of course the change should be blessed by fesco in this case, I assume
16:54:44 <Viking-Ice> really who does it's up to us to make the criteria and I propose we agree that LVM is a a release blocker until all GA release that had it as an default have been EOL then we remove the criteria
16:54:55 <adamw> how about this
16:55:02 <adamw> change this line in Beta criteria: "Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
16:55:04 <adamw> to this:
16:55:18 <Viking-Ice> and we agree that the bug is a blocker
16:55:25 <adamw> "Creating, destroying and assigning mount points to partitions of any specified size using all offered filesystem types"
16:55:47 <adamw> if anaconda doesn't want to support something, don't offer it, or hide it behind a parameter like it did for btrfs.
16:56:00 <adamw> offered filesystems ought to work - as kparal said earlier, if it's available it really shouldn't fail.
16:56:06 <tflink> I think that not supporting at least the removal of LVM for F18 is really bad form
16:56:07 <Viking-Ice> agreed
16:56:20 <cmurf> adamw i agree
16:56:32 <kparal> adamw: good idea
16:56:40 <jreznik> ok
16:56:49 <adamw> tflink: wdyt?
16:56:50 <tflink> -1 on adamw's proposal
16:56:54 <adamw> aww.
16:57:00 <tflink> but I seem to be outvoted
16:57:05 <adamw> reasoning?
16:57:09 <cmurf> LVM + btrfs makes no sense anyway
16:57:16 <tflink> LVM has been the default for how long?
16:57:24 <adamw> since fedora core 3.
16:57:27 <kparal> adamw: I think tflink wants to say LVM removal should be supported always
16:57:34 <kparal> which makes sense as well
16:57:39 <adamw> ah
16:57:48 <tflink> kparal: no, not always but at least until the last fedora with LVM as default has gone EOL
16:57:49 <kparal> so the 'offered types' would apply just to creating
16:57:57 <cmurf> Is LVM being considered a filesystem type?
16:58:05 <tflink> I don't think so, no
16:58:05 <adamw> well, we do actually need to split up creating/destroying/assigning mount points for another reason.
16:58:09 <kparal> *creating and assigning
16:58:17 <adamw> cmurf: i was considering it one, yeah.
16:58:30 <adamw> we could say 'filesystem types and volume management systems', but meh.
16:58:38 <tflink> I don't object to not supporting the creation of LVM for f18+ even though I use LVM a lot
16:58:52 <adamw> in newui custom part, LVM is just an option in the filesystem list
16:59:05 <tflink> I object to the installer not getting along with the default 'filesystem' from the previous release
16:59:06 <adamw> tflink: well my point is if we decide we don't want to support it, it shouldn't be offered.
16:59:15 <tflink> to be created, sure
16:59:17 <Viking-Ice> tflink, as do I
16:59:17 <cmurf> adamw: I think it's a Device Type
16:59:48 <adamw> it sounds like maybe we do need to do this outside the meeting
16:59:50 <Viking-Ice> adamw, has a point there
16:59:50 <adamw> this is taking a lot of time
17:00:00 <tflink> works for me
17:00:14 <tflink> #info discussion on LVM related criteria will be continued outside the meeting
17:00:22 <adamw> tflink: i believe that split would be plausible, btw. anaconda can destroy a partition of a type it doesn't offer to create.
17:00:49 <Viking-Ice> I think we can just agree on adamws proposal which should cover lvm
17:01:15 <adamw> we could agree in principle that we're *at least* going to require creation of offered types to work, in which case we can take this as a blocker.
17:01:26 <adamw> i guess that'd square the circle? it sounds like no-one really objected to that, or did you not like it tflink?
17:01:50 <tflink> I'm fine with that, I think I was confusing bugs
17:01:58 <adamw> okay, so
17:02:01 <tflink> if it's offered, it should work
17:02:08 <Viking-Ice> yup
17:02:16 * kparal nods
17:02:36 <tflink> are we changing the criteria, then?
17:02:37 <cmurf> adamw: I don't think the blocker criteria at this point should bind the anaconda team to functionality outside the ui. If offered, it should work. If it doesn't work come final TC's then those options need to be removed if they are a hurt me button.
17:02:53 <adamw> propose #agreed 862006 - we agreed in principle that the criteria should be adjusted to require creation of all offered filesystem types to work at beta, therefore as LVM is offered, this bug is accepted as a blocker
17:03:08 <adamw> cmurf: i think by 'offered' we've been assuming 'offered in the UI'
17:03:09 <Viking-Ice> ack
17:03:09 <tflink> ack
17:03:11 <kparal> ack
17:03:19 <akshayvyas> ack
17:03:20 <cmurf> adamw: i agree
17:03:21 <adamw> that's another thing to clarify in the final wording
17:03:42 <adamw> cmurf: so...er, sorry to be dense, do you have a problem with the plan or not? :)
17:03:59 <cmurf> i agree with the proposal
17:04:05 <pschindl> ack
17:04:36 <adamw> yay
17:04:41 <adamw> #agreed 862006 - we agreed in principle that the criteria should be adjusted to require creation of all offered filesystem types to work at beta, therefore as LVM is offered, this bug is accepted as a blocker
17:04:52 <cmurf> so that's a delayed and cryptic ack
17:05:09 <tflink> #action propose revision to partitioning criterion such that all partition types offered in the UI should work
17:05:29 * tflink didn't know that there was a 'call for help' option in meetbot
17:05:45 <tflink> anyhow, let's move on
17:05:53 <tflink> #topic (862801) Anaconda hangs when 'Configuring installed system'
17:05:54 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862801
17:05:54 <tflink> #info Proposed Blocker, NEW
17:06:14 <kparal> finally some easy bug
17:06:16 <kparal> blocker +1
17:06:26 <pschindl> +1
17:06:29 <Viking-Ice> +1
17:06:47 <tflink> criterion?
17:07:11 <tflink> "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"?
17:07:18 <kparal> good one
17:07:27 <kparal> it doesn't complete
17:07:32 <kparal> usually on bare metal
17:07:54 <tflink> proposed #agreed 862801 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
17:08:02 <akshayvyas> ack
17:08:03 <pschindl> ack
17:08:04 <Viking-Ice> ack
17:08:11 <tflink> #agreed 862801 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
17:08:22 <tflink> #topic (860430) RFE: dual boot support in newui
17:08:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860430
17:08:23 <tflink> #info Proposed Blocker, ON_QA
17:08:33 <Viking-Ice> we might want to rephrase that criteria to be "fully complete" for the next release cycle
17:08:57 <Viking-Ice> nack
17:09:04 * satellit_e it does work on power off reboot
17:09:09 <Viking-Ice> +1 blocker -1 nth
17:09:19 <tflink> Viking-Ice: nak for the last bug?
17:09:31 <Viking-Ice> for the dual boot
17:10:02 <Viking-Ice> nack = -1 blocker -1 nth
17:10:05 <cmurf> i am against blocker
17:10:06 <cmurf> -1
17:10:21 <Viking-Ice> my +1 there was a mistake
17:10:31 <cmurf> +1 nth
17:11:15 <kparal> well selecting the correct disk for bootloader installation is quite important I believe
17:11:19 <cmurf> reason: grub2 devs don't recommend the use of block lists; therefore a dependency on something not recommended should not cause blocking.
17:11:39 <cmurf> kparal: correct WHOLE disk yes
17:12:04 <Viking-Ice> officially supporting dual booting in any shape or form is a mistake and doing so we are opening pandoras box
17:12:08 <kparal> cmurf: I might be confused, I believed that's what the bug was about
17:12:26 * adamw on phone, sorry
17:12:28 <cmurf> kparal: almost certainly i'm confused
17:13:00 <cmurf> kparal: yeah this is about presenting UI for installing grub to a particular whole disk rather than assuming it goes on the disk containing /boot
17:13:35 <kparal> that's at least +1 NTH to me
17:13:48 <tflink> I think I'm OK with blocker on this as long as we limit it to 'should be able to choose which disk gets the bootloader'
17:13:48 <cmurf> yeah
17:14:08 <akshayvyas> tflink: +1
17:14:20 <cmurf> the problem with installing grub to the disk containing /boot is that it steps on a pre-existing bootloader, potentially
17:14:24 <tflink> I'm not +1 blocker on the entirety of 'should be able to dual boot'
17:14:39 <cmurf> but what blocker criteria does stepping on a prior bootloader violate?
17:15:16 <cmurf> tflink: esp considering that grub2 can maintain the dual-bootability of the system
17:15:49 <Viking-Ice> I'm fine +1 "should be able to choose which disk gets the bootloader"
17:15:53 <kparal> I'm not sure of the full scope of this bug, but I'm +1 to tflink's proposal
17:16:12 <cmurf> my preference would be to have a "no bootloader" option in anaconda, rather than being compelled to choose some other disk. what if you don't have another disk?
17:16:29 <cmurf> isn't it true something lik 80% of the fedora installations are single disk installs?
17:16:44 <cmurf> i.e. there are no other drives present?
17:17:04 <tflink> I don't see any alpha or beta criteria that back up my +1 blocker, though
17:17:35 <cmurf> tflink: right that's why i'm -1 blocker, +1 nth
17:17:58 <kparal> if you have broken bios, you might need to select a different disk
17:18:00 <Viking-Ice> well if it fails to select and correctly install the boot loader on hw with 2 or more disks then it should hit the standar criteria "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
17:18:13 <kparal> that would be a showstopper and might guarantee +1 blocker
17:18:24 * adamw back
17:18:41 <cmurf> kparal: I don't see how a 3rd party vendor's buggy BIOS commits a bug as blocker to bail out the vendor.
17:18:46 <tflink> adamw: did you finish your research on how this could be a beta blocker?
17:18:46 <Viking-Ice> kparal, given previous examples no not really ( some hw bugs we dismiss like the graphical cards )
17:19:44 <tflink> I'm definitely +1 NTH due to the current final criterion for dual-boot
17:20:31 <adamw> i didn't unfortunately
17:20:41 <tflink> what about " The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
17:20:45 <adamw> the blocker scope of this is 'pick target disk', yeah, not 'allow to install to partition'
17:20:58 <cmurf> tflink: well final release criteria 10 expresses exactly what i've been saying for a while which is newui doesn't have an option to NOT install a bootloader
17:21:01 <adamw> hmm, it wasn't entirely meant for this but it kinda works
17:21:16 <tflink> it's too much of a stretch to include the bootloader as a partition
17:21:26 <adamw> yeah, i think we're all agreed on that.
17:21:44 <tflink> s/it's too much/it's not too much/
17:21:52 <cmurf> the bootloader stage 2 (core.img) is in effect its own partition
17:22:17 <cmurf> at least on BIOS hardware
17:22:36 <tflink> EFI even more so, no?
17:23:08 * jreznik thinks we should set max time constraint for a bug otherwise it's going to be loong meeting...
17:23:09 <zodbot> Ticket notification - f18betablocker: [Bug 865048] kickstarted install can't autopart disk <https://bugzilla.redhat.com/show_bug.cgi?id=865048>
17:23:15 <tflink> jreznik: we already did
17:23:21 <cmurf> tflink: no it's a file like any other kind of file, within the file system
17:23:23 <tflink> nvm, I read that too quickly
17:23:30 <tflink> that's an interesting idea, though
17:23:34 <adamw> cmurf: i don't think you're helping to clarify anything here.
17:23:38 <Viking-Ice> jreznik, wont help
17:23:43 <cmurf> tflink: for BIOS, it's either in the MBR gap, an implied partition; or it's in BIOS Boot on GPT disks, an explicit partition
17:23:45 <Viking-Ice> the most time is getting ack from people
17:23:48 <adamw> reading the bootloader as a 'partition' for the purposes of the criteria seems rather baroque.
17:24:07 <tflink> so, we sound pretty much agreed on +1 NTH
17:24:08 <adamw> and not what they were written for.
17:24:16 <tflink> true
17:24:34 <tflink> so we eitehr propose criteria changes or -1 blocker, saving it for final
17:24:35 <adamw> i agreed last week to unpropose this if i couldn't come up with a criterion this week, so...i guess make it nth and go on
17:24:49 <adamw> that's okay for me, it should get in anyways.
17:24:51 <cmurf> adamw: grub being shoved into the MBR gap *is* baroque
17:25:10 <Viking-Ice> +1 nth
17:25:15 <jreznik> ok +1 nth
17:25:16 * kparal says let's do +1 nth and go on
17:26:21 <cmurf> still +1 nth
17:26:23 <tflink> proposed #agreed 860430 - RejectedBlocker (Beta), AcceptedNTH - While this does not clearly violate any F18 alpha or beta release criteria, it does hit the following F18 final release criteria and an early fix wouldn't be turned down "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootlo
17:26:30 <tflink> that's too long, isn't it
17:26:34 <jreznik> yep
17:27:13 <tflink> proposed #agreed 860430 - RejectedBlocker (Beta), AcceptedNTH - While this does not clearly violate any F18 alpha or beta release criteria, it does hit the dual-boot release criterion for F18 final and a tested fix would be considered past freeze.
17:27:24 <adamw> acceptedblocker (final)
17:27:43 <tflink> proposed #agreed 860430 - RejectedBlocker (Beta), AcceptedNTH (beta), AcceptedBlocker (final) - While this does not clearly violate any F18 alpha or beta release criteria, it does hit the dual-boot release criterion for F18 final and a tested fix would be considered past freeze.
17:27:44 <kparal> yes, let's accept for final right away
17:28:04 <kparal> ack
17:28:06 <Viking-Ice> ack
17:28:08 <cmurf> "or leave the Windows bootloader untouched and working" #10 final release criteria is a problem for newui
17:28:09 <akshayvyas> ack
17:28:15 <cmurf> ack
17:28:25 <jreznik> ack
17:28:29 <pschindl> ack
17:28:36 <tflink> #agreed 860430 - RejectedBlocker (Beta), AcceptedNTH (beta), AcceptedBlocker (final) - While this does not clearly violate any F18 alpha or beta release criteria, it does hit the dual-boot release criterion for F18 final and a tested fix would be considered past freeze.
17:28:48 <tflink> #topic (858591) anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8
17:28:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=858591
17:28:54 <tflink> #info Proposed Blocker, VERIFIED
17:30:07 <kparal> this is causing mayhem throughout the system
17:30:18 <kparal> various programs crash due to invalid locale
17:30:23 <adamw> yeah, this is clearly +1 blocker now
17:30:31 <adamw> the firstboot crash is the most obvious basis
17:30:49 <Viking-Ice> +1 blocker
17:30:52 <adamw> see https://bugzilla.redhat.com/show_bug.cgi?id=858591#c51
17:30:52 <kparal> I wanted to repropose as blocker as well, but adamw beat me to it
17:30:53 <jreznik> +1 blocker
17:30:55 <kparal> +1 blocker
17:31:04 <akshayvyas> +1 blocker
17:31:15 <pschindl> +1
17:31:58 <tflink> so, "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct passphrase is
17:32:05 <tflink> shortened, though
17:32:07 <adamw> yup, the dreaded long one.
17:32:28 <akshayvyas> "yum update Failed to set locale, defaulting to C"i am getting this when i try to update
17:33:14 <akshayvyas> well it updates bt yum fails to set locale
17:33:37 <tflink> proposed #agreed 858591 - AcceptedBlocker - Violates the following F18 alpha release criterion for a non-insignificant number of locales: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account"
17:33:44 <tflink> I think that's just short enough
17:33:55 <kparal> yep
17:34:08 <tflink> ack/nak/patch?
17:34:09 <kparal> ack
17:34:11 <jreznik> ack
17:34:13 <akshayvyas> ack
17:34:15 <Viking-Ice> ack
17:34:24 <tflink> #agreed 858591 - AcceptedBlocker - Violates the following F18 alpha release criterion for a non-insignificant number of locales: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account"
17:34:36 <Viking-Ice> thou that criteria should be moved to beta
17:34:46 <Viking-Ice> as in the locale part
17:34:47 <tflink> #topic (862784) error: rpmdb open failed
17:34:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862784
17:34:47 <tflink> #info Proposed Blocker, NEW
17:35:37 <tflink> we didn't get around to a new partitioning proposal, did we?
17:36:56 <Viking-Ice> well I kinda think it's should be in the beta criteria
17:37:31 <Viking-Ice> default paritioning scheme for alpha the reuse that partition scheme to test in beta
17:37:41 <Viking-Ice> s/the/then
17:38:03 <adamw> no, not yet, this was what i was referring to earlier when i said we needed to split up the 'create, destroy and assign' wording
17:38:27 <zodbot> Ticket notification - f18betanicetohave: [Bug 860430] RFE: dual boot support in newui <https://bugzilla.redhat.com/show_bug.cgi?id=860430>
17:38:38 <adamw> i'm broadly in the 'only require re-use of /home at beta' camp
17:39:06 <tflink> #action propose partitioning criterion rewording such that partitions other than /home are not required to be re-usable at beta
17:39:34 <tflink> note that we can either change the action, and certainly don't have to accept the rewording
17:39:56 <adamw> #undo
17:39:56 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x244dd150>
17:39:58 <tflink> but I'm also +1 to 'only require /home reuse at beta'
17:40:05 <adamw> #action adamw propose partitioning criterion rewording such that partitions other than /home are not required to be re-usable at beta
17:40:15 <Viking-Ice> require re-use of /home is kinda and fresh install with upgrade and belongs with upgrade
17:40:16 <cmurf> +1 as well
17:40:17 <tflink> if you want it, go for it :)
17:40:33 <adamw> Viking-Ice: either way, it's beta
17:40:43 <tflink> adamw: I think that #actions work w/o assigning it to someone
17:40:53 <adamw> sure, but i wanted it assigned to me :)
17:40:55 <cmurf> however it seems like Cantrell prefers stricter requirements for alpha, with diminishing strictness by the time we get to final?
17:40:57 <kparal> I'm just afraid custom partitioning will be a disaster, because it won't be available at Beta
17:41:05 <Viking-Ice> adamw, I think we should support re-using the default partitioning scheme
17:41:13 <Viking-Ice> at beta as well
17:41:34 <tflink> either way, it sounds like a discussion for the list instead of here?
17:41:40 <adamw> i think anaconda team considers re-use of any populated partition other than /home to be a bad idea and expressly not supported
17:41:51 <adamw> 're-using' empty partitions is more of a grey area
17:42:13 <kparal> what about reusing with reformatting?
17:42:13 <adamw> some people seem to want to pre-create partitions with their favourite tools
17:42:15 <Viking-Ice> nope it's not so only /home camper I am now
17:42:37 <kparal> adamw: and there will be much more of them, when they see custom partitioning in anaconda
17:42:57 <cmurf> kparal: yep
17:43:10 <tflink> proposed #agreed 862784 - While this does potentially violate F18 beta release criteria, that was not the spirit in which they were written. Will revisit after discussion on test@ regarding rewording the partitioning release criteria.
17:43:13 <kparal> at least reuse with reformat would be great
17:43:35 <jreznik> kparal: yep
17:43:43 <cmurf> kparal: yeah and Windows and Mac OS installers allow this without reformatting, so it's something a lot of users are used to expecting
17:43:59 <kparal> anyway, ack to tim's proposal
17:44:08 <jreznik> ack
17:44:08 <cmurf> ack
17:44:13 <adamw> yeah, we don't have a clear consensus so ack
17:44:17 <Viking-Ice> ack
17:44:21 <tflink> #agreed 862784 - While this does potentially violate F18 beta release criteria, that was not the spirit in which they were written. Will revisit after discussion on test@ regarding rewording the partitioning release criteria.
17:44:41 <tflink> #topic (855560) F18 Live Alpha : nVidia GeForce 8600M GT, graphic driver (nouveau): very poor performance (vesa is fluid)
17:44:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855560
17:44:46 <tflink> #info Proposed Blocker, NEW
17:45:11 <tflink> no movement since last week
17:46:01 <tflink> unpropose as blocker unless there is more testing?
17:46:14 <cmurf> agree
17:46:35 <adamw> yeah, this doesn't seem to be piling up reports and i haven't seen anyone mentioning it on list or forums
17:46:45 <Viking-Ice> acj
17:46:49 <Viking-Ice> mean ack
17:46:49 <adamw> i'd say reject without prejudice
17:47:36 <jreznik> ok
17:47:42 <akshayvyas> -1 blocker +1 nth
17:48:03 <tflink> proposed #agreed 855560 - RejectedBlocker - There seem to be no new reporters and the existing reporters aren't retesting. Therefore, we conclude that this isn't a big enough problem to accept as a blocker for F18 beta.
17:48:18 <kparal> ack
17:48:21 <akshayvyas> ack
17:48:36 <Viking-Ice> ack
17:48:41 <tflink> #agreed 855560 - RejectedBlocker - There seem to be no new reporters and the existing reporters aren't retesting. Therefore, we conclude that this isn't a big enough problem to accept as a blocker for F18 beta.
17:48:50 <tflink> #topic (745202) gnome-shell does not display correctly with NV3x adapters - multicolor corruption of panel, Shell-style menus and text [nvfx]
17:48:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=745202
17:48:56 <tflink> #info Proposed Blocker, NEW
17:49:41 <kparal> I tested this with NV43, and everything worked, but I understand it is a different chipset family :-)
17:50:50 <Viking-Ice> great
17:51:00 <Viking-Ice> how common is this hw
17:51:01 <kparal> the fallback mode works, so that's a good thing?
17:51:27 <kparal> I don't really want to read the previous 100 comments :)
17:51:34 <tflink> isn't fallback supposed to die at some point?
17:51:41 <Viking-Ice> it boils down to mesa
17:51:43 <kparal> seems not yet
17:51:58 <Viking-Ice> and if I can recall correctly 9.x was not supposed to be in final?
17:52:07 <kparal> if NV3x doesn't work under Gnome Shell, but fallback mode kicks in, it seems OK to me
17:52:20 <jreznik> same for me
17:52:26 <tflink> it would be nice if it went to llvmpipe instead but I don't think that's a blocker
17:52:49 <jreznik> tflink: or even better
17:52:50 <Viking-Ice> not a blocker
17:52:55 <jreznik> -1 blocker
17:53:07 <adamw> yeah, with the info we got, this seems clearly not a blocker
17:53:16 <Viking-Ice> I get total darkness and we did no block that he gets fallback and consider himself lucky
17:53:24 <adamw> the blacklist is the 'fix' for blocker status here, and the blacklist is still working.
17:53:28 <Viking-Ice> can consider
17:53:44 <adamw> Viking-Ice: this one was a blocker because it affects a whole generation of nvidia hardware, but as long as the blacklist's still working, we're fine.
17:54:10 <tflink> proposed #agreed 745202 - RejectedBlocker - Affected systems still boot into fallback mode and the HW blacklist seems to still be appropriate with current versions of mesa 9.x. Since fallback mode still functions, this is rejected as a blocker for F18 beta
17:54:19 <Viking-Ice> ack
17:54:22 <akshayvyas> ack
17:54:45 <kparal> ack
17:55:14 <tflink> #agreed 745202 - RejectedBlocker - Affected systems still boot into fallback mode and the HW blacklist seems to still be appropriate with current versions of mesa 9.x. Since fallback mode still functions, this is rejected as a blocker for F18 beta
17:55:24 <tflink> #topic (844167) Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64
17:55:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=844167
17:55:29 <tflink> #info Proposed Blocker, MODIFIED
17:56:08 <tflink> oh yeah, this is an upgrade issu
17:56:10 <adamw> god, i am going to shoot this bug so hard in the head.
17:56:28 <adamw> anyhoo, we're still waiting on the new upgrade tool.
17:56:40 <adamw> so still pending.
17:56:42 <tflink> adamw: until it poops rainbows and vomits sparkles?
17:57:03 * tflink is going to undo the topic change and move on to the next bug
17:57:07 <tflink> #undo
17:57:07 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2d1d0990>
17:57:08 <tflink> #undo
17:57:08 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2678d310>
17:57:10 <tflink> #undo
17:57:10 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2678d790>
17:57:12 <adamw> tflink: precisely
17:57:24 <tflink> #topic (864204) AttributeError: 'YumConf' object has no attribute '_repos_persistdir'
17:57:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864204
17:57:30 <tflink> #info Proposed Blocker, NEW
17:58:19 <Viking-Ice> ugh abrt
17:58:51 * tflink wants a stick for beating those who propose blockers w/o justification
17:59:16 <adamw> also, he didn't say what image he booted.
17:59:22 <kparal> we're QA, we have to come up with justification
17:59:23 <tflink> I'm tempted to reject on the grounds that we have no idea what's going on here
17:59:23 <adamw> which is important in this context
17:59:32 <adamw> at least punt on that grounds.
17:59:42 <tflink> I think this is beta tc2
17:59:43 <adamw> i just tried booting the dvd and quickly switching to nearest mirror, it didn't crash
17:59:50 <adamw> 18.12 is tc2, yeah.
17:59:55 <adamw> but i mean, dvd, netinst...
18:00:00 <kparal> 10 users are CCed
18:00:05 <kparal> that means it happens often
18:00:08 <Viking-Ice> bug 672588 reveals perhaps more the underlying problem
18:00:14 <tflink> then either punt or reject
18:00:27 <kparal> oh, the CC come from Blocks field
18:00:38 <kparal> nvm
18:00:47 <adamw> and clumens added some ccs
18:00:51 <kparal> yep
18:00:57 <adamw> presumably for people he thought could help diagnose the issue, not people who were affected by it
18:01:13 <kparal> yes, they were not added by abrt
18:01:14 <tflink> thoughts on punt vs reject?
18:01:16 <kparal> so single-man issue
18:01:25 <Viking-Ice> reject
18:01:28 <kparal> ask him to reproduce if he can, otherwise reject
18:01:36 <kparal> unless it happens for someone else as well
18:01:39 <cmurf> it sounds like anaconda is yacking in certain instances when it's not finding  a mirror?
18:02:15 <kparal> punt now, reject if we can't reproduce and nobody else stumbles upon it
18:02:17 <cmurf> I would ask "is this reproducible if so how"
18:02:27 <Viking-Ice> be too fast :)
18:02:51 <tflink> proposed #agreed 864204 - There is not enough information on the image used or exactly what went wrong here. Ask for more information from the reporter - if there is nothing new @ the next review meeting, this will be rejected as a blocker.
18:03:01 <akshayvyas> ack
18:03:02 <Viking-Ice> ack
18:03:05 <cmurf> ack
18:03:09 <tflink> #agreed 864204 - There is not enough information on the image used or exactly what went wrong here. Ask for more information from the reporter - if there is nothing new @ the next review meeting, this will be rejected as a blocker.
18:03:22 <tflink> #topic (862971) ValueError: Cannot remove extended partition sda4.  Logical partitions present.
18:03:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862971
18:03:28 <tflink> #info Proposed Blocker, ON_QA
18:04:15 <kparal> +1 blocker
18:04:19 <tflink> +1 blocker
18:04:26 <cmurf> +1
18:04:27 <kparal> happens often when reclaiming space
18:04:41 <kparal> probably just for some partition configurations
18:04:49 <cmurf> i'm seeing variations on this; same cause but different crash reports
18:04:51 <tflink> sounds like when you have extended partitions
18:05:11 <cmurf> this one is extended partitions, i have one filed for corrupt ext4 partition
18:05:31 <tflink> proposed #agreed 862971 - AcceptedBlocker - Violates the following F18 beta release criterion for systems using extended partitions: "The installer's custom partitioning mode must be capable of the following: ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
18:05:34 <cmurf> in any case anaconda should be able to remove a partition, most likely; but certainly shouldn't crash if it can't.
18:05:37 <cmurf> ack
18:05:37 <Viking-Ice> ack
18:05:55 <adamw> ack
18:05:58 <tflink> #agreed 862971 - AcceptedBlocker - Violates the following F18 beta release criterion for systems using extended partitions: "The installer's custom partitioning mode must be capable of the following: ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
18:06:04 <tflink> #topic (863451) AttributeError: 'DeviceFormat' object has no attribute 'peStart'
18:06:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863451
18:06:09 <tflink> #info Proposed Blocker, NEW
18:06:57 <kparal> seems he's able to reproduce it reliably
18:07:03 <tflink> is this LVM?
18:07:09 <cmurf> no
18:07:33 <kparal> you just let anaconda create the whole layout in the advanced view
18:07:35 <kparal> I suppose
18:07:36 <Viking-Ice> what the hell is partition template
18:07:43 <cmurf> he clicks on the blue "link" in manual partitioning to automatically partition, then goes to the UNKNOWN partisions section to nuke individual partitions
18:07:47 <tflink> pv.size - pv.format.peStart?
18:07:55 <adamw> i think this is in custom partitioning
18:07:56 <cmurf> this area is pretty flaky i've been getting a lot of crashes
18:07:56 <kparal> cmurf: correct, I believe
18:08:03 <adamw> where it shows existing disks as part of other OS installations
18:08:13 <adamw> ones that don't seem to be part of another OS get shown under an 'UNKNOWN' group
18:08:22 <adamw> and deleting the last entry in that 'UNKNOWN' group causes the crash. i think that's it.
18:08:38 <kparal> so deleting should work, we have it in criteria
18:09:04 <cmurf> adamw: i think so and i think this is related to a bug i filed last night although the trace is totally different
18:09:05 <adamw> should be reproducible
18:09:11 <adamw> i'd be +1 blocker on that basis
18:09:31 <kparal> +1 blocker
18:09:40 <adamw> call of nature, brb
18:09:55 <cmurf> 864771 may be a duplicate of this bug
18:10:23 <Viking-Ice> blocker
18:10:34 <tflink> I'd be interested in seeing what his setup looked like - it sounds like a VM in the logs
18:10:47 <cmurf> tflink: as it is in my case
18:11:24 <Viking-Ice> vm " INFO kernel:[   16.368907] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null)"
18:11:29 <tflink> yes, the system did have LVM, BTW
18:11:50 <tflink> this is probably still a blocker, though
18:12:21 <cmurf> tflink: yes either criteria 10 subpart says even if it's an invalid partition that the installer shouldn't crash
18:12:22 <Viking-Ice> we have three acks for blocker
18:13:11 <cmurf> ahh but if the release criteria do not support the logic of blocking, then acks are invalid ;-)
18:13:45 <tflink> proposed #agreed 863451 - AcceptedBlocker - Violates the following F18 beta release criteria for the removal of LVM partitions: "The installer's custom partitioning mode must be capable of the following: ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
18:13:56 <adamw> ack
18:13:58 <akshayvyas> ack
18:13:59 <Viking-Ice> ack
18:14:05 <kparal> ack
18:14:06 <tflink> #agreed 863451 - AcceptedBlocker - Violates the following F18 beta release criteria for the removal of LVM partitions: "The installer's custom partitioning mode must be capable of the following: ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
18:14:19 <cmurf> tflink: if you want to kill two birds with one stone 864771 is likely the same bug
18:14:36 <cmurf> could a.) make it blocker b.) make a reference that it may be a dupe of 863451
18:15:07 <tflink> we can cross that bridge once we get there, i think. it's coming up
18:15:09 <cmurf> or just note it as a possible dupe that has additional information
18:15:20 <Viking-Ice> you can do it https://www.youtube.com/watch?v=VZ2HcRl4wSk
18:15:45 <Viking-Ice> cmurf, and yes we can and yes we will
18:16:01 <tflink> #topic (863582) KeyError: 'payload'
18:16:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863582
18:16:01 <tflink> #info Proposed Blocker, ON_QA
18:16:06 <tflink> #undo
18:16:06 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x274edc50>
18:16:09 <tflink> #undo
18:16:09 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2d1d0690>
18:16:15 <tflink> #undo
18:16:15 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x1c45dd90>
18:16:25 <tflink> #agreed 863451 - AcceptedBlocker - Violates the following F18 beta release criteria for the removal of LVM partitions: "The installer's custom partitioning mode must be capable of the following: ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
18:16:33 <tflink> #topic (863582) KeyError: 'payload'
18:16:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863582
18:16:34 <tflink> #info Proposed Blocker, ON_QA
18:16:45 <adamw> clum: https://bugzilla.redhat.com/show_bug.cgi?id=865066
18:16:46 <tflink> meetbot doesn't accept spaces!
18:16:56 <adamw> grr
18:17:15 <tflink> yeah, I was mad about it, too :)
18:17:41 <tflink> +1 blocker
18:18:02 <kparal> +!
18:18:03 <kparal> +1
18:18:06 <cmurf> i thought this had been fixed
18:18:07 <Viking-Ice> +1
18:18:23 <kparal> doesn't really matter, we can still accept it
18:18:28 <kparal> we are not sure it has been fixed
18:18:39 <jreznik> +1
18:19:00 <cmurf> ok. although i was hitting this bug in alpha but i'm not in any of the betas.
18:19:01 <tflink> proposed #agreed 863582 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
18:19:07 <cmurf> ack
18:19:22 <adamw> ack
18:19:28 <kparal> ack
18:19:32 <tflink> #agreed 863582 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
18:19:44 <tflink> #topic (853508) nfsiso source for stage2 does not work
18:19:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=853508
18:19:44 <tflink> #info Proposed Blocker, ASSIGNED
18:20:44 <kparal> this should be a blocker according to current criteria
18:21:00 <tflink> it should?
18:21:05 <kparal> It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run.
18:21:17 <kparal> The installer must be able to use the HTTP, FTP and NFS remote package source options
18:21:23 <Viking-Ice> ack
18:21:29 <kparal> and as adamw says, we always assumed NFS==NFSISO
18:22:12 <tflink> this seems like a rather obscure area to block on
18:22:22 <kparal> I don't see why obscure
18:22:26 <tflink> according to the bug, nfs/nfs iso works
18:22:28 <tflink> pxe works
18:22:30 <cmurf> NFS+PXE=??
18:22:33 <adamw> nfs iso doesn't work
18:22:39 <adamw> according to anaconda team
18:22:42 <tflink> it's just the combination of pxe+nfsiso that doesn't work, no?
18:22:47 <adamw> no
18:22:49 <adamw> nfs iso doesn't work at all
18:22:54 <tflink> then +1 blocker
18:22:58 <adamw> according to anaconda team it's not trivial to fix
18:23:11 <kparal> the criterion says explicitly it must work with PXE
18:23:11 <adamw> and they are of the opinion we should not block on it, we should only require either NFS or NFS ISO
18:23:28 <kparal> so we should discuss criterion change
18:23:31 <adamw> on the basis you can always do one or the other
18:23:36 <adamw> the criterion does not actually state nfsiso.
18:23:47 <adamw> we've always cited it when taking nfsiso blockers, but it really doesn't say that.
18:23:51 <kparal> actually in my case, I need nfsiso and I can't do nfs
18:23:55 <kparal> in our office
18:24:03 <kparal> I have nowhere to explode the DVD tree
18:24:03 <adamw> why can't you loop mount the ISO on the nfs server?
18:24:11 <kparal> I don't have root access to it
18:24:14 <adamw> ah, hm
18:24:17 <adamw> that's an interesting case
18:24:36 <kparal> we mirror fedora-alt, but that's it
18:24:47 <kparal> and I create PXE with Branched boot items
18:25:02 <kparal> but that's just my use case
18:25:23 <Viking-Ice> blocker or not ?
18:25:28 <Viking-Ice> I'm +1 blocker
18:25:31 <adamw> i asked jlk to drop by
18:25:38 <jlk> already here
18:25:38 <cmurf> i'm -1 blocker because the release requirements don't explicitly say NFS + PXE
18:25:38 <adamw> he's the guy who was dealing with nfs iso being broken
18:25:54 <kparal> cmurf: they do, read it once again please
18:25:55 <adamw> cmurf: yes it does.
18:25:55 <jlk> right, so this is a bit of a mess
18:26:10 <jlk> it's broken only if you attempt to get stage2 from an iso mounted on an NFS share
18:26:16 <adamw> cmurf: that's very clear, the question is whether we ought to require both nfs and nfsiso to work, or whether just one is enough.
18:26:31 <jlk> so the work arounds are plentiful
18:26:36 <adamw> jlk: so kparal cited a case where he does need nfsiso, nfs won't work
18:26:43 <kparal> I can use http though
18:26:53 <adamw> true
18:26:56 <kparal> I just wanted to say nfs and nfsiso are not equivalent in all cases
18:26:57 <jlk> in that situation, you can put a LiveOS/ folder in your nfsiso dir correct?
18:27:13 <adamw> oh right, there's that workaround too
18:27:29 <jlk> I haven't verified, but I believe if LiveOS/ exists in the nfsiso dir, dracut will use that and not attempt to move the mounts around
18:27:30 <adamw> it works if you create a LiveOS/ folder and put squashfs.img in it, right jlk?
18:27:36 <adamw> or just create the folder?
18:27:50 <jlk> sorry, yes, you put squashfs.img in it too
18:27:57 <kparal> actually that again requires me to have access somewhere where I won't get it
18:28:18 <kparal> but if nfsiso is so difficult, I don't mind explicitly move it to Final
18:28:33 <kparal> we had troubles with it also for F17 cycle
18:28:35 <adamw> my instinct is either/or is okay for beta
18:28:49 <tflink> yeah, that works for me
18:28:51 <adamw> other votes?
18:29:08 <tflink> I'm not sure we have enough people affected by this to justify blocking release for it, to be honest
18:29:11 <kparal> adamw: nfs or nfsiso for Beta, nfs and nfsiso for Final?
18:29:11 <tflink> but I could be wrong
18:29:22 <adamw> kparal: yeah
18:29:29 <jlk> you can point to a stage2 on http and still use nfsiso as the repo
18:29:31 <kparal> adamw: I'm OK with that
18:29:33 <adamw> or even more liberal, but at least that liberal
18:29:55 <adamw> remote sourcing in general seems like an area where there's fifty zillion ways to do it, and as long as enough of them work...
18:29:58 <digimer> One of my tickets went from "New" to "Post"... may a n00b ask what that means? no comment was added to the ticket.
18:30:11 <adamw> digimer: for anaconda, POST means a patch has been submitted to the anaconda patches ml for discussion
18:30:26 <digimer> oh, awesome. thanks adamw
18:30:31 <tflink> so do we punt until criteria changes have gone through or reject pending those changes?
18:30:32 <adamw> it then gets reviewed on the list, and if it's accepted, it'll get committed to git and the bug set to MODIFIED
18:30:42 <adamw> then when there's an anaconda build that includes the patch, it'll go to ON_QA
18:30:55 <adamw> if we're all agreed on the criterion idea we can reject
18:31:00 <adamw> did we lose viking-ice?
18:31:10 <kparal> but let's make sure the criteria gets changed after the meeting
18:31:16 <digimer> adamw: ah, thank you
18:31:16 <adamw> yeah, needs an action item
18:31:22 <jlk> as a side note, I really want to hook up a git hook that will do that POST->MODIFIED shuffle for us on git push
18:31:24 * digimer is new to this. :)
18:32:01 <adamw> can someone else take this #action? my todo list is huge
18:32:12 <tflink> proposed #agreed - The nfs package source criterion should be modified such that _either_ nfs or nfsiso should work @ beta
18:32:21 <adamw> ack
18:32:22 <adamw> er
18:32:23 <adamw> patch
18:32:25 <cmurf> ack
18:32:32 * kparal doesn't feel like creating 'any/all' criteria
18:32:36 <adamw> proposed #agreed - The nfs package source criterion should be modified such that _either_ nfs or nfsiso should work @ beta, with that agreement, 853508 is rejected as a blocker
18:32:45 <adamw> kparal: 'either/both' :)
18:33:04 <kparal> ack
18:33:06 <adamw> kparal: it's not so tricky for this case since we just have two specific methods to consider, not a fuzzy list of variable length.
18:33:08 <tflink> um, I was purposely separating the criteria change and the blocker acceptance
18:33:13 <adamw> tflink: oh, sorry
18:33:15 <adamw> didn't realize
18:33:20 <adamw> in that case ack
18:33:51 <kparal> adamw: actually it requires to tweak " The installer must be able to use the HTTP, FTP and NFS remote package source options " sentence
18:33:53 <tflink> so, no volunteers for the nfs/nfsiso criterion change?
18:34:03 <kparal> gimme an action
18:34:04 <adamw> kparal: yeah, but the tweak isn't too hard
18:34:37 <tflink> #action kparal to propose changing the NFS remote package source criterion to require _either_ nfs or nfsiso to work @ beta
18:35:02 * kparal would love to use mathematical parentheses in common language sentences
18:35:03 <tflink> now that we're all discombobulated ...
18:35:17 <tflink> proposed #agreed - The nfs package source criterion should be modified such that _either_ nfs or nfsiso should work @ beta
18:35:28 <tflink> a rejectedblocker proposal will come next
18:35:40 <Viking-Ice> adamw, I just went outside smoking while this was being discussed
18:35:43 <tflink> ack/nak/patch?
18:35:47 <tflink> I see one ack
18:35:52 <adamw> Viking-Ice: you okay with the change?
18:35:53 <adamw> ack
18:36:07 <nanonyme> kparal, what's preventing you from using parentheses? :)
18:36:15 <Viking-Ice> ack
18:36:16 * kparal loves the word "discombobulated"
18:36:16 <kparal> ack
18:36:32 <tflink> #agreed - The nfs package source criterion should be modified such that _either_ nfs or nfsiso should work @ beta
18:36:44 <kparal> nanonyme: and && or || symbols, that would be nice :)
18:37:17 <tflink> proposed #agreed 853508 - RejectedBlocker (Beta) - Due to the accepted criterion change above (xx:36) and the fact that nfs does function as a remote package source, this is rejected as a blocker for F18 beta
18:37:41 <kparal> accept for final?
18:37:45 <cmurf> ack
18:37:59 <tflink> kparal: I'd say repropose once the criteria changes have gone through
18:38:05 <kparal> ack
18:38:28 <tflink> it sounds like this could be enough of a mess to drop nfsiso for f18, to be honest
18:38:31 <tflink> but I could be wrong
18:38:46 <tflink> to justify dropping, anyways
18:38:49 <kparal> I just don't want to let it disappear from the list, so let's just repropose for final right away
18:38:59 <Viking-Ice> ack
18:39:02 <adamw> ack
18:39:03 <tflink> kparal: go for it :)
18:39:13 <tflink> #agreed 853508 - RejectedBlocker (Beta) - Due to the accepted criterion change above (xx:36) and the fact that nfs does function as a remote package source, this is rejected as a blocker for F18 beta
18:39:15 <adamw> kparal: i'll re-propose for final when i do the bug note
18:39:29 <tflink> #topic (863348) ValueError: Cannot remove non-leaf device 'vda2'
18:39:29 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863348
18:39:29 <tflink> #info Proposed Blocker, POST
18:40:36 <Viking-Ice> "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
18:40:57 <kparal> this is clear +1 blocker, IMO
18:41:03 <Viking-Ice> yup
18:41:09 <akshayvyas> +1 blocker
18:41:10 <tflink> yeah, +1 blocker
18:41:13 <cmurf> +1
18:41:38 <tflink> proposed #agreed 863348 - AcceptedBlocker - Violates the following F18 alpha release criterion: " The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
18:41:45 <adamw> ack
18:41:53 <cmurf> ack
18:42:59 <tflink> ack/nak/patch?
18:43:04 <akshayvyas> ack
18:43:06 <tflink> thanks
18:43:09 <tflink> #agreed 863348 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
18:43:15 <tflink> #topic (864771) KeyError: PartitionDevice instance (0x7f0f28b016d0)
18:43:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864771
18:43:15 <tflink> #info Proposed Blocker, NEW
18:44:40 <tflink> I wonder why it's trying to grow a partition
18:45:04 <cmurf> *shrug*
18:45:18 <tflink> either way, I think this is OK as a blocker
18:45:27 <tflink> at a minimum, it would be nice if it didn't crash
18:45:35 <Viking-Ice> yup
18:46:02 * adamw reads
18:46:24 <cmurf> i think to be blocker the messag is "it must not crash" even if the partition can't be removed, although i can't think of a reason why even a corrupt file system would inhibit removal of a partition
18:46:51 <adamw> cmurf: can you reproduce this each time just by trying to delete the invalidly-formatted partition?
18:47:14 <cmurf> adamw: yes
18:47:24 <adamw> ok, then yeah, +1 blocker on the grounds you cited
18:47:25 <tflink> proposed #agreed 864771 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ... Rejecting obviously invalid operations without crashing"
18:47:31 <adamw> ack
18:47:38 <cmurf> ack
18:47:39 <kparal> ack
18:47:51 <tflink> #agreed 864771 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ... Rejecting obviously invalid operations without crashing"
18:48:05 * adamw notes we have 13 minutes left
18:48:30 <tflink> how close do we want to cut it?
18:48:39 <cmurf> one more bug
18:48:42 <cmurf> ?
18:48:55 <tflink> we have 10 proposed blockers left
18:49:04 <tflink> works for me
18:49:09 <tflink> #topic (863886) anaconda does not install firstboot
18:49:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863886
18:49:09 <tflink> #info Proposed Blocker, MODIFIED
18:49:13 <kparal> today we are approaching light speed in blocker review
18:49:25 <adamw> hey, we can get two more. cos this is obvious +1.
18:49:40 <adamw> try and install KDE from the DVD, get no firstboot, blocker.
18:49:48 <kparal> yep, +1
18:50:03 <tflink> +1
18:50:06 <cmurf> +1
18:50:10 <Viking-Ice> +1
18:51:05 <tflink> proposed #agreed 863886 - AcceptedBlocker - Violates the following F18 alpha release criterion: "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mod
18:51:11 <tflink> shortening
18:51:16 <adamw> ack in advance
18:51:33 <kparal> ack
18:51:34 <tflink> proposed #agreed 863886 - AcceptedBlocker - Violates the following F18 alpha release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode."
18:51:49 <Viking-Ice> ack
18:51:50 <tflink> more ack/nak/patch?
18:51:53 <kparal> ack
18:51:55 <cmurf> ack
18:51:55 <tflink> #agreed 863886 - AcceptedBlocker - Violates the following F18 alpha release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode."
18:52:01 <kparal> want more ack? I can ack more
18:52:18 <kparal> close it for today?
18:52:34 <jreznik> sorry, /me is on fedora board mtg right now...
18:52:37 <kparal> pretty successful run I think
18:52:47 <adamw> one more
18:52:51 <adamw> let's do one more!
18:53:09 <kparal> is that an addiction?
18:53:15 <tflink> kparal: http://blogs.mcall.com/.a/6a00d8341c4fe353ef0133edb5de38970b-800wi
18:53:18 <tflink> ACK!
18:53:25 <cmurf> sounds like fear of withdrawal
18:53:38 <kparal> tflink: nice, that looks like me after a long meeting :)
18:53:38 <adamw> i can quit any time i want to, man
18:53:44 <adamw> ahaha
18:53:55 <tflink> I'm fine either way
18:53:55 <Viking-Ice> that thing needs coffee stat!
18:54:04 <cmurf> or apprehension for what's coming instead
18:54:19 * tflink wants one of these: http://www.etsy.com/listing/93860534/bloom-county-bill-the-cat-and-opus-1991
18:54:19 <Viking-Ice> let's get that one more then close ( 3 hour mark )
18:55:15 <tflink> #topic (864058) anaconda main menu not visible in F18 Beta TC2 KDE Live
18:55:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864058
18:55:16 <tflink> #info Proposed Blocker, NEW
18:55:59 <tflink> so you can't install from kde live post alpha tc5?
18:56:53 <kparal> nice blocker
18:57:13 <tflink> how did we release alpha w/ non working install from KDE live?
18:57:19 <cmurf> i was just about to ask this
18:57:34 <adamw> eh? i don't think this affected alpha.
18:57:37 <adamw> i'm pretty sure i tested it.
18:58:03 <adamw> "It was visible in Alpha TC5" doesn't mean 'the bug was present', it means 'anaconda was visible' :)
18:58:18 <kparal> and "I was unable to start anaconda in Alpha TC6" doesn't mean the bug was present
18:58:21 <Viking-Ice> this is also tc not rc
18:58:22 <cmurf> i'm reading "the last visible was Alpha TC6"
18:58:32 <tflink> satellit_e: can you elaborate on your comment - https://bugzilla.redhat.com/show_bug.cgi?id=864058#c11
18:58:35 <adamw> i have the alpha kde live here, i'll check.
18:58:37 <kparal> jan sedlak forgot to test Alpha RCs
18:58:40 <adamw> anyhow, +1 blocker assuming it's as described.
18:58:48 <kparal> the usual problem with alphanumeric ordering
18:58:50 <Viking-Ice> yup
18:58:54 <Viking-Ice> +1 blocker
18:58:57 <kparal> which I'm complaining about for a long time
18:58:58 <cmurf> +1
18:59:06 <kparal> blocker +1
18:59:11 <tflink> were you able to install from kde live beta tc3?
18:59:17 <tflink> ok
19:00:20 <adamw> OK, alpha kde live was okay
19:00:36 <adamw> i have it running here, anaconda launches and the main hub is visible.
19:00:44 <adamw> i was sure i did test it, but thought i'd better check =)
19:00:50 <tflink> proposed #agreed 864058 - AcceptedBlocker - Violates the following F18 alpha release criterion for the KDE spin: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
19:01:00 <kparal> ack
19:01:03 <adamw> ack
19:01:14 <Martix> ack
19:01:16 <tflink> #agreed 864058 - AcceptedBlocker - Violates the following F18 alpha release criterion for the KDE spin: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
19:01:27 <tflink> ok, we're over 3 hours
19:02:07 <tflink> #topic Open Floor
19:02:18 <tflink> #info stopping at the 3 hour mark, will continue tomorrow
19:02:25 <tflink> #undo
19:02:25 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2c3fdb50>
19:02:31 <cmurf> what about this LVM business?
19:02:47 <tflink> #info stopping at the 3 hour mark, will continue on 2012-10-11 @ 16:00 UTC with the remainder of the bugs not covered today
19:03:38 <adamw> cmurf: it's going on list.
19:03:45 <cmurf> gotcha
19:03:48 <adamw> but we agreed in principle that LVM fail is blocker, basically.
19:04:00 <tflink> anything else that should be brought up now?
19:04:05 <adamw> i guess i'll spend the afternoon on a whole bunch of criteria tweaks.
19:04:14 <tflink> that sounds like fun :-/
19:05:03 <tflink> if there's nothing else, I'm setting the fuse for [0,5] minutes
19:05:55 <adamw> ah, schrodinger's fuse
19:06:08 <tflink> eh? The fuse exists
19:06:18 <adamw> but we don't know how long it is
19:06:23 <tflink> whether you look in the box of explosives or not
19:06:51 <tflink> here, look in the box :)
19:07:20 <tflink> anyhow ...
19:07:33 * tflink will send out minutes and announcement for tomorrow's meeting shortly
19:07:38 <tflink> Thanks for coming, everyone!
19:07:42 <tflink> #endmeeting