16:01:14 <adamw> #startmeeting Fedora QA meeting
16:01:14 <zodbot> Meeting started Mon Jan  7 16:01:14 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:17 <adamw> #meetingname fedora-qa
16:01:17 <zodbot> The meeting name has been set to 'fedora-qa'
16:01:20 <adamw> #topic roll call
16:01:54 * Martix .
16:01:57 * tflink is present
16:01:57 * jskladan tips his hat
16:02:03 * kparal tips jskladan's hat
16:02:59 * jreznik is here
16:03:10 * nirik is lurking
16:03:27 <jreznik> (but has to leave earlier today... will be back later, real life...)
16:03:51 * maxamillion is here
16:04:07 * vhumpa lurking
16:04:16 <maxamillion> actually ... that's a fib, going to refill my coffee cup then I'll actually be here
16:04:51 <adamw> morning everyone
16:04:54 * satellit listening
16:05:09 <adamw> #topic previous meeting follow-up
16:06:23 <adamw> so I see one action item from the last meeting way back on 12-17
16:06:30 <adamw> "viking-ice to let docs team know about advanced storage for release notes"
16:06:34 <adamw> do we have a viking?
16:07:37 <tflink> he was around earlier
16:08:30 <adamw> lemme check docs archive
16:09:27 <adamw> i don't see anything in the archive, so we'd better check back with him alter
16:09:47 <adamw> #info "viking-ice to let docs team know about advanced storage for release notes" - viking-ice isn't around and we don't see anything in the docs@ archives, better check in with him later
16:09:57 <adamw> alrighty, onto the main course
16:10:11 <adamw> #topic Fedora 18 Final status and blocker review
16:10:23 <adamw> let's just go straight into blocker review, if tflink's ready?
16:10:30 <adamw> #chair tflink kparal maxamillion
16:10:30 <zodbot> Current chairs: adamw kparal maxamillion tflink
16:10:57 <tflink> yep
16:10:58 <jreznik> if we could go top important to less imporant way - I have to leave in 30 minutes today :(
16:11:03 <maxamillion> oh jeebus, why am I a chair?
16:11:21 <tflink> maxamillion: you're leading the blocker review today - didn't anyone tell you?
16:11:25 <tflink> :-D
16:11:32 <adamw> maxamillion: mainly because I like typing maxamillion
16:11:33 <maxamillion> no .. :X
16:11:41 <adamw> and throwing chairs
16:11:44 <maxamillion> adamw: awww, something about that feels kind
16:12:13 <tflink> jreznik: define top issues - the list that adamw started in #anaconda?
16:12:20 <jreznik> tflink: yep
16:12:41 * jreznik has sent similar list before :)
16:12:46 <adamw> let's knock off the obvious blocker first
16:12:54 <tflink> OK, these are going to be quite out of order compared to the webapp then
16:12:57 <tflink> #topic (892621) Anaconda FC18-TC4 does not present BIOS RAID as available storage
16:13:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892621
16:13:02 <tflink> #info Proposed Blocker, anaconda, NEW
16:13:11 <tflink> jreznik: you did? I don't remember seeing that email
16:13:58 <jreznik> tflink: #anaconda earlier today, doesn't matter right now :)
16:14:31 <jreznik> Jes raised it today
16:14:32 <adamw> seems like an obvious +1, sadly
16:14:44 <adamw> wish i'd tested earlier and caught this at tc4, but was too busy with other bugs :(
16:14:46 <jreznik> seems like regression between tc3 and tc4
16:15:09 <jreznik> well it's pretty serious one, I have to say +1 blocker
16:15:13 <adamw> my only caveat is we only have jes' case, but for now, +1
16:15:30 <tflink> proposed #agreed 892621 - AcceptedBlocker - Violates the following F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
16:15:41 <jreznik> adamw: you caught it too, aren't you?
16:15:41 <Martix> ack
16:16:06 <adamw> jreznik: no, i haven't tested yet
16:16:23 <adamw> jreznik: i have to do bios raid testing on my main desktop so it's kind of a pain and stops me being able to do much else while i'm doing it
16:16:28 <adamw> ack
16:16:40 <kparal> ack
16:16:44 <jreznik> adamw: I see I wish, sorry
16:16:45 <jreznik> ack
16:16:47 <tflink> #agreed 892621 - AcceptedBlocker - Violates the following F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
16:16:59 <tflink> #topic (892494) deleting existing LV doesn't free space to allow creation of new LV
16:17:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892494
16:17:04 <tflink> #info Proposed Blocker, anaconda, NEW
16:17:31 <adamw> i'm fairly sure this is essentially the same bug as https://bugzilla.redhat.com/show_bug.cgi?id=892269
16:17:48 <adamw> doesn't really matter whether you shrink or delete an existing LV, the problem is with 'free space' calculation inside a container
16:18:14 <kparal> might be a dupe. your repro was too difficult, mine was simple :)
16:18:14 <jreznik> looks like
16:18:36 <jreznik> but with same result and same issue behind
16:18:49 <kparal> I think it doesn't matter much, anaconda guys can dupe if necessary
16:19:31 <adamw> kparal: reducing the size of an LV is about as easy as deleting it, really. just change the size in the 'properties' bit.
16:19:48 <kparal> do we want to know it now?
16:19:49 <tflink> sounds like we're +1, though?
16:19:52 <adamw> kparal: can you confirm they're dupes with the test i mentioned? create the new LV with a specific size and check it works?
16:20:06 <kparal> adamw: I can, sure. right now?
16:20:21 <adamw> it'd help.
16:20:26 <adamw> i guess i can too.
16:20:36 * kparal starting VM
16:20:39 <adamw> tflink: for me this is right on the blocker/nth fence
16:20:51 <adamw> you *can* deal with it by specifying a size
16:20:59 <adamw> it does suck pretty bad though
16:21:27 <kparal> adamw: so should I resize the existing LV, or delete the existing one and create a new one?
16:21:50 <adamw> kparal: don't bother, i just confirmed it. they're dupes.
16:21:57 <kparal> right now I have the existing layout - /boot and LV / + LV swap
16:23:18 <adamw> kparal: if you try shrinking / instead of deleting it, you'll see it behaves just the same as in your video
16:23:32 <adamw> no 'free space' is created, and if you create a new LV and don't specify a size, it'll come up as 900kB
16:23:47 <adamw> but if you specify a size, it'll 'work'
16:23:52 <kparal> I deleted / and created a new one with 5 GB. it succeeded, even though I had 1 MB of free space supposedly
16:23:57 * Viking-Ice here
16:24:20 <adamw> right.
16:24:38 <adamw> exactly the same behaviour. i've marked this as a dupe of 892269 and edited the summary slightly.
16:24:44 <kparal> that's really stupid bug
16:25:26 <jreznik> it is
16:25:38 <adamw> yeah. like i said i'm right on the edge of blocker/nth.
16:25:41 <kparal> you have to count the remaining size in hand
16:26:40 <adamw> in the long run we probably need anaconda to track 'unpartitioned space' and 'free space within each existing container' separately, i think
16:26:53 <kparal> new interface!
16:26:53 <adamw> a single 'free space' counter doesn't really do the job
16:27:01 <kparal> NewNewUI
16:27:04 <Martix> yeah!
16:27:05 <adamw> =)
16:27:21 <jreznik> nooo, please! it's not a joke!
16:27:23 <adamw> morning viking, dan
16:27:27 <dan408> hi
16:27:31 <jreznik> well, so where we are with this one?
16:27:32 <dan408> im not really here
16:27:35 <dan408> im just lurking
16:27:35 <Martix> jreznik: are you sure?
16:27:38 <adamw> for f18 there should be some kind of workaround possible, i guess
16:27:43 <adamw> jreznik: no-one but me seems to be voting
16:27:53 <dan408> adamw: i vote +1 for all
16:27:55 <kparal> if it wasn't January already, I'd be clearly +1
16:27:56 <Martix> +1 blocker
16:28:00 <tflink> +1
16:28:04 <kparal> I'm not so sure now
16:28:11 * jreznik is with kparal
16:28:17 * Viking-Ice points adamw to https://bugzilla.redhat.com/show_bug.cgi?id=885808#c1
16:28:20 <dan408> which bug are you all discussing?
16:28:25 <tflink> dan408: see topic
16:28:27 <Martix> make your minds :-)
16:28:38 <Martix> dan408: see topic
16:29:00 <Martix> tflink: I read slower then I type
16:29:01 <kparal> jreznik: there can be only one vote fuzzificator here
16:29:18 <adamw> tflink: actually can you change topic to 892269?
16:29:18 <kparal> and that's me
16:29:33 <adamw> since i duped this one off
16:29:56 * nirik reads up on it.
16:29:58 <dan408> the whole custom partitioning thing needs to be reworked
16:30:08 <tflink> #info 892394 has been marked as a duplicate of 892269 which is also proposed as a blocker. Moving discussion to that bug
16:30:21 <tflink> #topic (892269) Free space calculation interferes with creation and resizing of LV within existing VG after shrinking existing LV
16:30:24 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892269
16:30:27 <tflink> #info Proposed Blocker, anaconda, NEW
16:30:29 <Martix> let ask somebody from Anaconda, if they know how to fix it soon
16:30:38 <kparal> nirik: I have a nice shiny video in 892394
16:30:40 <adamw> dan408: yeah, that's not happening for f18. let's keep the discussion practical.
16:30:51 <dan408> no i mean
16:31:06 <dan408> there are 3 bugs on partitioning, dont you think they might be somewhat related?
16:31:07 <nirik> I'm -1 blocker, +1 NTH/commonbugs/releasenote.
16:31:17 <Martix> adamw: I didn't see planned Anaconda features for F19, do you?
16:31:27 <tflink> sounds like we're +3/-3
16:31:30 <kparal> I'm +0
16:31:36 <tflink> +3/-2
16:31:45 * jreznik is weak -1 to make it harder
16:31:49 <Viking-Ice> +1
16:31:54 <tflink> +4/-1.5
16:31:57 <kparal> :D
16:31:58 <Martix> come on :-D
16:32:00 <dan408> +1 blocker
16:32:02 <jreznik> but would like to hear more from anaconda
16:32:06 <tflink> +5/-1.5
16:32:10 <Martix> jreznik: +1
16:32:13 <adamw> <dlehman> for the lvm thing any potential fix would probably need pretty wide testing
16:32:38 <tflink> so we get down to practicality
16:32:59 <kparal> adamw: that means we can't have it as NTH either, if we refuse it as a blocker on that ground
16:33:00 <tflink> we could do a smoke build with an anaconda scratch build or updates.img
16:33:05 <adamw> kparal: yeah, pretty much
16:33:14 <adamw> well, we could accept it as nth but not take the fix. :)
16:33:41 <jreznik> what would be the definition of wide testing?
16:33:51 <jreznik> go through the lvm test cases?
16:33:54 <Martix> adamw: so why we are discussing it?
16:33:55 <tflink> if the  only reason we wouldn't take it as a blocker is the time until fix or risk, lets take it as a blocker for now and re-evaluate when we have a more concrete idea of the actual risk for more slippage
16:34:05 <kparal> does that mean "have kparal play with it for an hour"?
16:34:08 <adamw> <dlehman> basically don't cap specified max for new mountpoints based on free space
16:34:08 <adamw> no, definitely not going to try to make free space calculation any more complex at this point
16:34:08 <adamw> <adamw> that wouldn't solve the 'user doesn't enter a size' case, would it?
16:34:08 <adamw> <dlehman> it would not
16:34:08 <adamw> <adamw> well, i suppose they could edit the size, at least
16:34:09 <adamw> and that sounds like a worryingly impactful change.
16:34:10 <Martix> tflink: +1
16:34:14 <adamw> Martix: we have to decide on blocker status.
16:34:44 <Viking-Ice> we already have
16:34:49 <Viking-Ice> based on my account it's an blocker
16:34:55 <jreznik> tflink: if we take it now, how difficult would it be to convince qa to fudge :)
16:34:56 <tflink> unless votes change, yes
16:35:07 <adamw> please do take into account the quotes from dlehman.
16:35:20 <adamw> i am changing to -1 on that basis as i think the proposed 'fix' is problematic and just as likely to cause worse problems.
16:35:23 <tflink> jreznik: depends on the actual risk
16:35:33 <adamw> if dlehman thinks that's the best 'fix' possible i'd rather just document the problem.
16:35:34 <nirik> what criteria are the folks voting +1 going by?
16:35:36 <dan408> adamw: thats why I said what i did earlier
16:35:42 <kparal> adamw: what would dlehman vote?
16:35:44 * jreznik is not happy with this bug, but what dlehman said is quite horrifying...
16:35:49 <dan408> kparal: wwjd?
16:36:00 <kparal> dan408: ?
16:36:02 <dan408> nm
16:36:08 <tflink> yeah, I'm also not convinced this is a good idea - +1 in principle but not sure it's worth it
16:36:24 <dan408> there are what 3 custom partitioning bugs that are proposed blocking right?
16:36:24 <tflink> nirik: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
16:36:37 <adamw> dan408: there are basically two bugs.
16:36:37 <tflink> dan408: 2 now, there was a dupe
16:36:51 <adamw> this one, and one to do with multiple-device btrfs containers. they're not related.
16:36:52 <nirik> seems like a streach... since you can get a workable layout
16:36:57 <dan408> adamw: you're missing one
16:36:58 <Viking-Ice> nirik, If anaconda is not ready for release it's not ready for release and we should delay if it breaks our already existing criteria
16:37:04 <dan408> .bug 875291
16:37:07 <zodbot> dan408: Bug 875291 custom partitioning loses focus - https://bugzilla.redhat.com/show_bug.cgi?id=875291
16:37:10 <tflink> nirik: that criterion implies the ability to resize. there are beta criterion that specify resizability
16:37:11 <Viking-Ice> nirik, sad but true
16:37:22 <dan408> 3
16:37:26 <nirik> Viking-Ice: yes, I was asking what specific critera.
16:37:40 <Martix> *ding* 20 minutes passed for this bug
16:37:42 <dan408> i say group them together and try and get them fixed this week if possible
16:37:42 <tflink> actually, I'm wrong. resize-ability isn't specifically called out
16:38:01 <adamw> yeah, resizing is not key to the bug.
16:38:05 <adamw> it affects deleting LVs too.
16:38:07 * kparal recommends to watch #anaconda
16:38:22 <dan408> kparal: one day
16:38:38 <kparal> dan408: I mean right now
16:38:40 <adamw> Viking-Ice: at some point we have to take practicalities into consideration. we can't start ripping up the custom part code for f18 now. if the only practical 'fix' is a band-aid which doesn't really fix the problem and could easily create other problems, i do not think we should poke it.
16:38:58 * jreznik is now more -1/document and has to leave, will be watching discussion from cell phone, sorry
16:39:06 <nirik> It doesn't crash right? just gives you the too small space to install ?
16:39:13 <dan408> kparal: okay.
16:39:16 <Viking-Ice> adamw, I full well understand the risk at poking at it
16:39:16 <adamw> yeah, it doesn't crash
16:39:26 <adamw> you do at least have the opportunity to keep trying till you hit on the method that works
16:39:28 <tflink> either way, I'm -1 NTH - this is too much risk for an NTH bug
16:39:36 <kparal> nirik: but if you don't know about it, you might not be able to create your partitions
16:39:46 <adamw> i like the idea of voting +1/-1, but i follow your reasoning :)
16:39:57 * nirik is still +1 NTH, if the fix somehow proves simple we could take it.
16:40:28 <Viking-Ice> I'm still +1/-1 and we either block or not based on the risk
16:40:49 <Martix> I withdraw my vote
16:40:50 <tflink> same here, we can re-evaluate blocker status later if need be
16:41:15 <kparal> dlehman went silent. I think we should go -1 blocker, and evaluate nth vote based on the patch, if available
16:41:17 <tflink> I've lost track of the votes, though. Can people re-state their votes?
16:41:31 <Viking-Ice> +1
16:41:37 <tflink> +1/-1
16:41:37 <adamw> -1
16:41:37 <Martix> let's discuss it on next mtg after Anaconda devs reevaluate benefits/risks
16:41:46 <adamw> Martix: we really don't have that much time.
16:41:51 <Viking-Ice> yup
16:41:55 <jreznik_n9> -1
16:42:13 <tflink> +2/-2 total so far
16:42:14 <Viking-Ice> adamw, well jes bug kinda is a blocker no ;)
16:42:18 <adamw> i may change to +1 if a more useful plausible fix showed up.
16:42:33 <adamw> Viking-Ice: sure, dlehman already has a fix for that, though.
16:42:34 <Martix> #needinfo
16:42:36 <tflink> so punt or re-propose if a different fix showed up?
16:42:51 <adamw> we
16:42:52 <Viking-Ice> just count the votes
16:42:54 <adamw> we're missing a few votes
16:42:56 <tflink> I don't like the idea of punting
16:42:59 <dan408> punt, but i'd like to say these 3 bugs should be grouped together
16:43:00 <tflink> I restarted the count
16:43:05 <kparal> -1 blocker, nth after patch available
16:43:05 <tflink> it got too complicated
16:43:08 <nirik> -1/+1
16:43:14 <tflink> +2/-4
16:43:27 <tflink> +2/-4 blocker, +2/-2 NTH
16:43:34 <dan408> +1
16:43:39 * maxamillion is torn
16:43:39 <tflink> +3/-4 blocker, +2/-2 NTH
16:44:10 * tflink sets timer for 2 minutes on votes - we need to move on
16:44:19 <jreznik_n9> pls count dlehman too
16:44:26 <tflink> he voted?
16:44:30 <kparal> jreznik_n9: he didn't vote
16:44:41 <Martix> -1 blocker/+1 NTH
16:44:45 <Viking-Ice> jreznik_ 9 can he vote
16:44:46 <tflink> kparal: he did in #anaconda
16:44:59 <adamw> <dlehman> weak -1 blocker, +1 NTH
16:45:00 <jreznik_n9> he voted
16:45:00 <tflink> +3/-6 blocker, +4/-2 NTH
16:45:15 <Viking-Ice> maintainers can only provide input not vote on their own bugs
16:45:16 <Martix> tflink: propose
16:45:20 <Viking-Ice> that's just stupit
16:45:27 <Viking-Ice> if they could
16:45:31 <adamw> why is it stupid?
16:45:43 <kparal> the maintainers have the best understanding of the risk
16:45:50 <kparal> it's completely valid
16:45:58 <adamw> it's not like they're going to vote -1 just to save themselves work.
16:45:58 <Viking-Ice> yes their input their vote no
16:46:04 <Martix> stick to the topic please
16:46:41 <Martix> keep this for open floor :-)
16:46:47 <tflink> proposed #agreed 892269 - RejectedBlocker AcceptedNTH - While this is a blocker in principle, the currently proposed fix was judged too risky to take this late in the release process. A tested fix would be considered past freeze if a less risky fix is proposed
16:46:53 <tflink> ack/nak/patch?
16:46:55 <dan408> im off to $dayjob, will try to get on from there
16:46:59 <Martix> ack
16:47:05 <jreznik_n9> ack
16:47:12 <kparal> ack
16:47:12 <Viking-Ice> hold on hows the count here
16:47:13 <adamw> ack
16:47:19 <adamw> <tflink> +3/-6 blocker, +4/-2 NTH
16:47:20 * nirik isn't sure that it actually meets any critera, but ok.
16:47:22 <Viking-Ice> dont we have -6 nth ?
16:47:34 <adamw> even if you don't count dlehman's vote, still majority for -1/+1.
16:47:34 <tflink> we do?
16:48:15 <Viking-Ice> tflink, this split count got me confused are we +4
16:48:17 <Viking-Ice> nth
16:48:22 <Viking-Ice> +3 blocker
16:48:26 <kparal> the counts are correct
16:48:47 <Viking-Ice> ack if nth
16:48:58 <kparal> green light, let's move
16:49:04 * jreznik_n9 is more 0 nth and smoke testing, if we have time
16:49:12 <tflink> #info Blocker Votes: (+1) tflink, Viking-Ice, dan408 (-1) adamw, dlehman, kparal, jreznik, nirik, Martix
16:50:28 <tflink> #info NTH Votes: (+1) nirik, adamw, jreznik, Martix, dlehman (-1) tflink, Viking-Ice
16:50:34 <tflink> did I screw up anyones votes?
16:50:51 <adamw> i didn't vote on NTH.
16:50:56 <Viking-Ice> yeah I though that
16:51:08 <tflink> #undo
16:51:08 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2a8a0d50>
16:51:23 * kparal is practically +1 nth
16:51:30 <tflink> #info NTH Votes: (+1) nirik, jreznik, Martix, dlehman, kparal (-1) tflink, Viking-Ice
16:51:30 <kparal> because we don't need to accept the fix
16:51:31 <Viking-Ice> it would be better to not pull this in as an nth from my pov instead of risk pulling it in if people are not going for blocker
16:51:51 <tflink> #agreed 892269 - RejectedBlocker AcceptedNTH - While this is a blocker in principle, the currently proposed fix was judged too risky to take this late in the release process. A tested fix would be considered past freeze if a less risky fix is proposed
16:52:19 <tflink> #topic (892188) anaconda in manual partitioning cannot 'reformat' previous / if previous /home is a subvol on the same btrfs partition
16:52:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892188
16:52:24 <tflink> #info Proposed Blocker, anaconda, NEW
16:53:11 <adamw> this is basically notabug, i think. definitely -1/-1.
16:53:16 <Viking-Ice> -1/-1
16:53:31 <tflink> -3/-2 from the bug
16:53:58 <jreznik_n9> -1/-1
16:54:02 <adamw> cmurf's comments are useful here - it kinda helps to understand how btrfs subvols work (which i really didn't until reading cmurf's notes)
16:55:23 <tflink> proposed #agreed 892188 - RejectedBlocker RejectedNTH - This is not a regression from F17 and it is possible to workaround by formatting outside the installer. Risk/reward ratio judged not enough to take a fix this late as NTH.
16:55:27 * nirik waits for bugzilla.
16:55:29 * Viking-Ice thought we did not "officially" support btrfs in anaconda in general
16:55:34 <adamw> patch
16:55:44 <adamw> it's not really about 'working around' it, it's just that this isn't a thing you should really do anyway.
16:55:49 <Martix> isnt this regression?
16:55:57 <adamw> Martix: as f17 had no btrfs UI at all, by definition, no.
16:55:58 <Viking-Ice> adamw, is that kinda notabug then?
16:56:11 <Martix> adamw: meant from previous tc
16:56:12 <adamw> Viking-Ice: cmurf and I think so but it'd be best to get confirmation from anaconda team before closing.
16:56:27 <adamw> Martix: the comment means 'from f17', not 'from previous tc'
16:56:33 <tflink> proposed #agreed 892188 - RejectedBlocker RejectedNTH - This is not a regression from F17 and this isn't something that you should be doing inside the installer anyways - reformatting of btrfs subvols should be done outside anaconda. Risk/reward ratio judged not enough to take a fix this late as NTH.
16:56:35 <Martix> ok
16:57:28 <adamw> still not really right. it doesn't make a lot of sense to reformat a btrfs subvol, given what it is. you just create and destroy them.
16:57:37 <adamw> well, anyway
16:57:38 <adamw> it's close enough
16:57:40 <adamw> ack
16:57:42 <kparal> ack
16:57:54 <Viking-Ice> ack
16:58:03 <Martix> ack
16:58:20 <tflink> #agreed 892188 - RejectedBlocker RejectedNTH - This is not a regression from F17 and this isn't something that you should be doing inside the installer anyways - reformatting of btrfs subvols should be done outside anaconda. Risk/reward ratio judged not enough to take a fix this late as NTH.
16:58:41 <tflink> I think those are all of the proposed blockers highlighted
16:58:57 <tflink> I assume that the idea is to finish going through the rest of them?
16:59:04 * tflink wasn't clear from before
16:59:04 <adamw> we should, yeah
16:59:32 <tflink> #topic (892669) slow NIC and local kickstart -> anaconda crash
16:59:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892669
16:59:32 <tflink> #info Proposed Blocker, anaconda, NEW
16:59:50 * adamw not really sure on this one.
17:00:22 <Viking-Ice> -1/-1
17:00:31 <nirik> do we know what cards this would affect?
17:00:32 <Viking-Ice> I think this is highly unlikely scenario
17:00:47 <kparal> I just want to point out that we have a machine with slow NIC in our office, and it's brand new desktop with latest AMD processor and state of the art UEFI motherboard
17:00:49 <tflink> -1/+1 - seems too much of a corner case to block over right now
17:00:56 <kparal> so it's not that unlikely
17:01:05 <nirik> kparal: whats the net card/driver out of curiosity?
17:01:16 <Viking-Ice> kparal, I somehow picture nic from the last century
17:01:26 <Viking-Ice> swinging to -1/+1
17:01:30 <kparal> nirik: I can't tell you right now
17:01:36 <tflink> I was more referring to the odds of having both local ks on media w/o packages, slow nic
17:01:37 * nirik wonders if it's a bnx2.
17:01:57 <adamw> 'slow NIC' seems weirdly non-specific. is this not just as likely to be to do with the connection setup or router?
17:02:11 <tflink> workaround: put packages on same local disk
17:02:12 <adamw> it sounds like we really mean 'slow network setup'.
17:02:25 <kparal> adamw: no, all our machines are on the same LAN. I think it's really slow NIC
17:02:36 <kparal> the link address is very slow to appear
17:02:41 <adamw> well in YOUR case yes
17:02:45 <adamw> but the general bug...
17:02:54 <adamw> tflink: that doesn't seem hugely unlikely.
17:02:57 <kparal> the similar VNC bug was about usb NIC
17:03:10 <adamw> tflink: why wouldn't you write a kickstart locally that uses remote packages? that's what i do every time i test anything to do with kickstarts...
17:03:23 <adamw> oh, hm, well, i suppose
17:03:42 <nirik> anyhow, I guess I would lean toward -1/+1 barring info that the problem is widespread.
17:03:43 <kparal> of course the workaround is to server the kickstart over the net
17:03:54 <adamw> yeah, thinking about the use cases for really _local_ kickstart / remote packages, -1/+1
17:03:54 <kparal> then the net is active by the time it reaches anaconda
17:04:04 <kparal> I'm also -1/+1
17:04:07 <Martix> -1/+1
17:04:37 <Martix> fix it as NTH or document it
17:05:36 <tflink> proposed #agreed 892669 - RejectedBlocker AcceptedNTH - The combination of install media w/ embedded ks, no packages and slow network startup is too much of a corner case to block release over. However, a tested fix would be considered for pulling before release.
17:05:36 <adamw> man, the commonbugs for f18 is going to break records
17:05:39 <adamw> ack
17:05:53 <Viking-Ice> aaaccckkkk
17:06:05 <kparal> ack
17:06:11 <tflink> proposed #agreed 892669 - RejectedBlocker AcceptedNTH - The combination of install media w/ embedded ks, no packages and slow network startup is too much of a corner case to block release over since reasonable workarounds exist (add packages to media, use remote ks). However, a tested fix would be considered for pulling before release.
17:06:24 <kparal> adamw: we're just better at documenting :)
17:06:58 * tflink assumes that the acks didn't change w/ edit
17:07:03 <tflink> #agreed 892669 - RejectedBlocker AcceptedNTH - The combination of install media w/ embedded ks, no packages and slow network startup is too much of a corner case to block release over since reasonable workarounds exist (add packages to media, use remote ks). However, a tested fix would be considered for pulling before release.
17:07:10 <Martix> ack
17:07:12 <tflink> #topic (892046) IndexError: list index out of range
17:07:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892046
17:07:12 <tflink> #info Proposed Blocker, anaconda, NEW
17:07:18 <Viking-Ice> kparal, we wish in truth we have double amount of issues this release cycle ;(
17:07:38 <tflink> it might be more than double if you're counting proposed blocker/nth bugs
17:08:21 <Viking-Ice> that's another btrfs/crash related one
17:08:31 <adamw> this specific one i'm -1/+1 on
17:08:38 <adamw> well, -1/weak +1...
17:08:53 <tflink> is this about the btrfs subvol size or booting from btrfs?
17:08:57 <adamw> i'm _reasonably_ sure this crash happens if you con anaconda somehow into creating a btrfs volume that's way too small
17:09:16 <Viking-Ice> at this point in time anaconda should not be crashing
17:09:18 <adamw> in other words, if you hit this crash, you're probably doing something you didn't want to be doing anyway
17:09:23 <Viking-Ice> it should just handle it gracefully
17:09:29 <adamw> yeah, that's never ever happened.
17:09:47 <Viking-Ice> anaconda handling something gracefully true that ;)
17:09:50 <tflink> -1/+1
17:09:54 <Martix> btrfs volumes smaller than 8 GB are problematic
17:09:58 <Martix> -1/+1
17:10:16 <Viking-Ice> -1/+1
17:10:46 <adamw> oh, hum, looks like my description was wrong
17:10:51 <adamw> sorry, i missed https://bugzilla.redhat.com/show_bug.cgi?id=892046#c17
17:11:00 <adamw> people may want to read that and re-vote, but i'm still -1/+1 i think
17:11:21 <Viking-Ice> well I'm more leaning towards +1/+1
17:12:04 <tflink> proposed #agreed 892046 - RejectedBlocker AcceptedNTH - This only occurs when doing something that you probably don't want to do in custom partitioning (in this case, creating btrfs subvols smaller than the minimum size) so it isn't enough to be a blocker. However, a tested fix would be considered for inclusion before release.
17:12:17 <adamw> yeah...it puts me closer to a +1. we're kinda hitting imponderables at this point (how many people are going to be installing over an existing btrfs install)
17:12:38 <nirik> isn't there a 'no crashing' critera?
17:12:47 <Viking-Ice> yes there is
17:12:48 <tflink> yeah, from beta
17:12:56 <Viking-Ice> and this hit's that
17:13:10 <kparal> actually there is no no crashing criterion for valid use cases, just for invalid ones :)
17:13:14 <tflink> "Rejecting obviously invalid operations without crashing"
17:13:18 <nirik> "The installer's custom partitioning mode must be capable of the following:"
17:13:19 <nirik> yeah
17:14:02 <Viking-Ice> "If I do not enter a capacity value, I don't get a crash."
17:14:11 * nirik is a weak +1/+1 I guess. Perhaps a fix would be to remove the size options from btrfs subvolumes? perhaps thats not too invasive?
17:14:48 <Martix> https://btrfs.wiki.kernel.org/index.php/FAQ#if_your_device_is_small
17:14:54 <adamw> remember, we weren't happy with those criteria and i was supposed to rewrite them, which i never got around to
17:14:58 <adamw> but yeah, this does kind of hit that.
17:15:31 <tflink> it sounds like we're more -1 blocker overall, though
17:16:06 <Martix> btrfs deal badly with volumes under <4GB, document it or add some limit
17:16:15 * tflink is not strongly -1, though
17:16:16 * adamw asking anaconda team for input
17:16:24 <adamw> Martix: no, this doesn't appear to be about (or not only about) size
17:16:27 <Martix> -1/+1
17:16:35 <adamw> see https://bugzilla.redhat.com/show_bug.cgi?id=892046#c17
17:17:05 <nirik> it's trying to specify a size on a btrfs subvolume...
17:17:08 <nirik> which... makes no sense.
17:17:15 <Martix> adamw: he is right
17:17:22 <rbergeron> does it crash if it has a reasonably sized volume specified?
17:17:44 <nirik> if you leave the size blank it does not crash
17:17:45 <rbergeron> (despite it not maing sense)
17:17:58 <adamw> nirik: it's not *just* that though
17:18:01 <nirik> my understanding is any value in there would cause a crash...
17:18:10 <Martix> nirik: ok
17:18:13 <adamw> nirik: as if you're creating a new layout from scratch, and you create multiple btrfs mount points and specify a size each time, it doesn't crash
17:18:19 <rbergeron> yeah, i saw, i just suspect that  a lot of human behavior is to "fill in a box with a size if it asks for one"
17:18:25 <nirik> adamw: true.
17:18:32 <adamw> instead it applies the value you enter as the size of the volume
17:18:33 <nirik> it's only in the reuse case.
17:18:37 <Martix> document it, or better grey it out for subvolumes
17:18:38 <adamw> which is also kind of wacky, but at least not a crash
17:19:00 * nirik is more weakly blocker then...
17:19:00 <adamw> i'm not 100% sure we have this one entirely nailed down, which doesn't help evaluate it :/
17:19:37 <tflink> continue with proposed #agreed and re-rpropose as blocker if something changes?
17:20:21 <adamw> the agreed needs patching anyway as this doesn't seem to be to do with smallness
17:20:43 <nirik> tflink: I'd be ok with that.
17:20:49 <adamw> brb, gotta go get a package from downstairs
17:20:59 <maxamillion> .... never fails, $dayjob gets insanely busy during this meeting ... the universe just doesn't like me to participate :/
17:21:29 <tflink> proposed #agreed 892046 - RejectedBlocker AcceptedNTH - This only occurs when doing something that you probably don't want to do in custom partitioning (in this case, specifying size for a btrfs subvol instead of a quota) so it isn't enough to be a blocker. However, a tested fix would be considered for inclusion before release.
17:21:37 <tflink> did I understand correctly?
17:21:58 <Martix> ack
17:22:31 <Viking-Ice> ack
17:23:14 <rbergeron> ack
17:23:20 <nirik> sure, ack
17:23:31 <tflink> #agreed 892046 - RejectedBlocker AcceptedNTH - This only occurs when doing something that you probably don't want to do in custom partitioning (in this case, specifying size for a btrfs subvol instead of a quota) so it isn't enough to be a blocker. However, a tested fix would be considered for inclusion before release.
17:23:50 * tflink is skipping the proposed blockers that are already accepted NTH and VERIFIED
17:23:59 <adamw> ack for now
17:24:09 <tflink> #topic (892196) Anaconda cannot create new subvols on an existing multi-disk btrfs volume (works for single-disk btrfs volumes)
17:24:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892196
17:24:14 <tflink> #info Proposed Blocker, anaconda, NEW
17:24:50 <Viking-Ice> tflink, you are following http://qa.fedoraproject.org/blockerbugs/milestone/18/final/bug list right ?
17:25:03 <Viking-Ice> did we not forget  	892621
17:25:13 <tflink> Viking-Ice: kind of, there was a request to change the order up
17:25:33 <Viking-Ice> from whom and to what benefit
17:25:45 <tflink> Viking-Ice: we did that one first
17:25:45 <Viking-Ice> and by order up you mean what exactly ?
17:25:58 <tflink> do the highest priority ones first
17:26:32 <adamw> so this kinda sucks for existing multi-disk btrfs volumes, but it's existing multidisk btrfs volumes.
17:26:42 <adamw> i'm not sure we want to block on that at this point.
17:26:45 <Viking-Ice> ? and who determines that priority
17:27:04 <Martix> Viking-Ice: ~chair
17:27:14 <Martix> adamw: +1 NTH
17:27:38 <Viking-Ice> in anycase the list there and how it's presented to participants needs to be the one and the same ( and in the same order )
17:27:57 <tflink> Viking-Ice: there were no objections to changing the order at the time, it seemed to be the most obvious blocker at this point (judgement call)
17:28:17 <adamw> can we just discuss the bug?
17:28:21 <tflink> yeah, I'm thinking -1/+1 as well
17:28:23 <Viking-Ice> yeah sure
17:28:38 <Viking-Ice> -1/+1
17:29:45 <tflink> proposed #agreed 892196 - RejectedBlocker AcceptedNTH - This is rather nasty for people who have multi-disk btrfs volumes but it seems like too much of a corner case to block release over. However, a tested fix would be considered for inclusion before release.
17:29:57 <adamw> ack
17:29:59 <nirik> ack
17:30:09 <kparal> ack
17:30:12 <tflink> #agreed 892196 - RejectedBlocker AcceptedNTH - This is rather nasty for people who have multi-disk btrfs volumes but it seems like too much of a corner case to block release over. However, a tested fix would be considered for inclusion before release.
17:30:18 <Martix> ack
17:30:26 <tflink> #topic (875291) custom partitioning loses focus
17:30:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875291
17:30:26 <tflink> #info Proposed Blocker, anaconda, NEW
17:31:05 <kparal> I have reported the dupe here, and it's damn easy to hit
17:31:41 <Viking-Ice> +1 nth
17:31:46 <adamw> at least nth
17:31:54 <adamw> i think this is the one dlehman was planning to work around somehow right?
17:32:17 <jreznik_n9> and fixable, only worst user exp
17:32:21 <kparal> basically you enter custom partitioning twice and you are likely to find everything "stuck"
17:32:29 <jreznik_n9> adamw, clumens
17:32:29 <kparal> very likely
17:32:30 <adamw> how ugly is the 'fix'?
17:32:37 <adamw> guess i can try it.
17:32:43 <tflink> I think it's more of a graphical thing
17:32:49 <tflink> the ugliness, I mean
17:32:50 <adamw> i meant ugly as in, well, ugly.
17:32:54 <adamw> graphically.
17:32:55 <tflink> ah, nvm then
17:33:03 <jreznik_n9> better than non working
17:33:07 <kparal> adamw: create some partitions and then go back to hub and back to custom mode
17:33:07 <Viking-Ice> jreznik_n9, I dont think we need to concern ourselfs with Anaconda user experience it's horrible as is and it wont get any better
17:33:11 <tflink> definitely +1 NTH, slight +1 blocker
17:33:24 <Viking-Ice> jreznik_n9, we should just focus on breakage instead
17:33:39 <Viking-Ice> I'm slight +1 blocker as well
17:33:43 <jreznik_n9> Viking-Ice, agreed
17:33:50 <jreznik_n9> on breakage
17:35:08 <Viking-Ice> jreznik_n9, the amount of reports against anaconda gives a clear indication of the user experience people have with it ( I'm not talking about poorly designed UI here )
17:35:29 <kparal> +1 blocker
17:36:08 * kparal trying the updates.img
17:36:10 <Martix> Viking-Ice: we can revisit Anaconda UX during F19 prealpha :-)
17:36:16 <tflink> thoughts on criterion?
17:36:28 <Viking-Ice> counting +3 blocker here
17:36:30 <adamw> i'm not sure it really hits criteria, hence -1 blocker narrowly
17:36:48 <adamw> if anyone can come up with a criteria fudge though, go for it :)
17:36:51 <adamw> +1 nth for sure
17:36:55 <Martix> -1 blocker/+1 NTH
17:37:11 <tflink> adamw: I think that's splitting hairs - it could prevent install unless the user is aware of the bug
17:37:31 <tflink> "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:37:31 <Southern_Gentlem> tflink, then document it
17:37:42 <Martix> we can document it, but I hope that new updates.img fixed that
17:37:56 <Viking-Ice> good enough criteria for me
17:37:57 <Martix> *fixes
17:38:20 <tflink> the "fudge" being: partitioning can't be completed if the window loses focus
17:38:37 <kparal> the update.img seems to work
17:38:40 <adamw> tflink: really? aren't they just gonna try again till it works?
17:38:52 <adamw> nothing irreversible has happened at this point and it's not a showstopper, they could just reboot and try again
17:38:59 <tflink> point
17:39:02 <adamw> i'm still -1, but i won't fight a +1.
17:39:17 <tflink> I'm about the opposite - slightly +1, but won't fight a -1
17:39:25 <Viking-Ice> me to
17:39:30 <Martix> we have *fix*
17:39:31 <jreznik_n9> -1/+1 nth and strong nth
17:39:32 <Viking-Ice> in anycase it seems to be fixed
17:39:32 * nirik is slight -1, +1
17:39:41 <tflink> ok, sounds like -1 overall
17:39:43 <Viking-Ice> fine nth let's pull in the fix
17:39:44 <tflink> slightly
17:40:02 <Martix> Viking-Ice: I was writing the same
17:40:26 <adamw> well, there is still a difference: if it's NTH, and the fix causes other problems, we can just pull the fix and release
17:40:32 <adamw> if it's blocker, we'd be committed to 'fixing the fix'
17:40:47 <tflink> proposed #agreed 875291 - RejectedBlocker AcceptedNTH - While this does cause problems during installation, it doesn't do any irreversable changes to the system and thus, is not a blocker for F18 final. However, a tested fix would be considered for inclusion before release.
17:41:01 <jreznik_n9> ack
17:41:02 <Viking-Ice> ack
17:41:02 <kparal> ack
17:41:09 <tflink> #agreed 875291 - RejectedBlocker AcceptedNTH - While this does cause problems during installation, it doesn't do any irreversable changes to the system and thus, is not a blocker for F18 final. However, a tested fix would be considered for inclusion before release.
17:41:18 <tflink> OK, that's all the proposed blockers that I see on my list
17:41:22 <adamw> ack (for the record)
17:41:29 <Martix> ack
17:41:35 <nirik> ack
17:42:17 <kparal> ack
17:42:23 <tflink> ?
17:42:26 <kparal> heh
17:42:34 <Martix> finaly all #agreed :-)
17:43:01 <tflink> are there any NTH that need to be discussed today? I haven't read through the list today
17:43:34 <Viking-Ice> do we walk through these *DE trackers ?
17:43:55 <tflink> Viking-Ice: not sure what you mean, the bugs blocking the trackers are pulled in
17:44:10 <tflink> the trackers themselves are not supposed to show up on the list but that's a bug in the blockerbug webapp
17:44:24 <Viking-Ice> tflink, ah that's what was confusing me
17:44:32 <adamw> yeah, we just ignore them
17:44:35 <Viking-Ice> both the kde and xfce trackers are there
17:44:36 <Martix> ok, another blockerbug againts blockerbug app :-D
17:44:45 <adamw> once we have an RC that's acceptable and no bugs block the tracker, we can close the tracker
17:45:18 <tflink> I see 1 NTH that seems worth discussing
17:45:25 <adamw> shoot, then
17:45:50 <tflink> #topic (892120) Click on Cancel in confirm dialog for Quit on network setting, rebooting system
17:45:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=892120
17:45:55 <tflink> #info Proposed NTH, anaconda, POST
17:46:41 <Viking-Ice> +1 nth
17:46:51 <Martix> we have patch
17:46:52 <kparal> trivial fix probably
17:47:02 <kparal> +1 nth
17:47:11 <Martix> +1 nth
17:47:48 <adamw> +1 so long as the fix is really safe
17:47:54 * adamw readdy adverse to tinkering at this point
17:48:14 <tflink> proposed #agreed 892120 - AcceptedNTH - This shouldn't happen, can't be fixed with an update post-release and sounds like a reasonable, low-risk fix. Once tested, it would be considered for inclusion before release.
17:48:26 <Martix> ack
17:48:28 <kparal> ack
17:48:49 <Viking-Ice> ack
17:48:54 <adamw> ack
17:48:58 <tflink> #agreed 892120 - AcceptedNTH - This shouldn't happen, can't be fixed with an update post-release and sounds like a reasonable, low-risk fix. Once tested, it would be considered for inclusion before release.
17:49:16 <tflink> another one that I'm pretty sure is -1 nth but is worth discussing in case I'm missing something
17:49:20 <tflink> #topic (886685) grub2 fails to boot when /boot partition is lvm on multipath device
17:49:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886685
17:49:25 <tflink> #info Proposed NTH, grub2, ON_QA
17:49:34 <tflink> as much as I think ppc needs this, I'm -1 NTH
17:49:43 <tflink> don't want to be mucking around with grub this late
17:49:50 <adamw> ppc is a secondary arch build so they can pull it themselves, i believe
17:49:56 <adamw> they aren't committed to the frozen package set
17:50:20 <adamw> at this late stage, -1, no fiddling with grub2.
17:50:30 <tflink> oh, was this pulled into the list due to a tracker?
17:50:32 <Southern_Gentlem> -1
17:50:34 <Viking-Ice> -1
17:50:39 <tflink> nope, it was proposed nth
17:50:56 <adamw> this doesn't look at all ppc-specific, but it is multipath-specific. i think.
17:50:56 * rbergeron suspects lots of cluster folks do this as well ... can see if she can get someone from that land to pipe in
17:51:12 <adamw> rbergeron: they'd probably be fine installing from network repos, right?
17:51:41 <tflink> proposed #agreed 886685 - RejectedNTH - This seems to mostly affect ppc which can pull in pkgs outside the PA blocker process. This is too risky to pull in as NTH for F18 and thus, rejected as NTH.
17:51:43 <Viking-Ice> rbergeron, does not change the fact that at this point touching anything that touches grub2 is ill adviced ;)
17:51:46 <rbergeron> adamw: yes
17:51:46 <Viking-Ice> ack
17:51:48 <tflink> proposed #agreed 886685 - RejectedNTH - This seems to mostly affect ppc which can pull in pkgs outside the PA blocker process. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH.
17:51:54 <rbergeron> Viking-Ice: I know it ;)
17:52:03 <tflink> s/for F18/for F18 this late/
17:52:05 <adamw> patch, i don't see anything ppc-specific.
17:52:05 <jreznik_n9> ack
17:52:06 <tflink> was the change
17:52:13 <adamw> i'd talk about multipath not ppc.
17:52:35 <adamw> well
17:52:42 <adamw> oh, actually, maybe it is
17:52:52 <adamw> 'ieee1275' seems to be OpenFirmware, which is a ppc64 thang, i guess.
17:53:41 <tflink> proposed #agreed 886685 - RejectedNTH - This only affects multipath installs which aren't believed to be incredibly common on primary arch (more common on ppc). Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH.
17:53:52 <tflink> proposed #agreed 886685 - RejectedNTH - This only affects multipath installs which aren't believed to be incredibly common on primary arch (more common on ppc). Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical for PA. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH.
17:54:02 <tflink> better?
17:54:04 <adamw> sorry, i'm confusing things
17:54:04 <adamw> no
17:54:09 <adamw> lemme try
17:54:39 <tflink> I'd argue that it may not be ppc-specific but the reports are all ppc
17:54:57 <rbergeron> yeah, that's not clear to me
17:55:02 <tflink> I'm not sure how many people are using /boot on multipath outside ppc
17:55:02 <adamw> proposed #agreed 866685 RejectedNTH - this only affects installs to LVM-on-multipath on OpenFirmware systems. OpenFirmware is mostly used on ppc64 systems, very rarely on i386/x86_64, though it is theoretically possible. Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical for PA. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH.
17:55:32 <adamw> tflink: i don't see why it'd be particularly ppc people who use /boot on multipath. there's nothing specific to ppc about multipath. *but*, now i look at the patch, it seems to touch only hte OpenFirmware code in grub2, hence the above.
17:55:50 <tflink> yeah, I just looked at the patch
17:55:58 <tflink> this fix is openfirmware specific
17:56:22 <tflink> adamw: IIRC, most x86 systems don't use multipath for local storage (raid or not)
17:56:41 <Viking-Ice> ?
17:56:51 <tflink> am I wrong?
17:57:00 <Viking-Ice> *cough* plethora of servers do *cough*
17:57:19 <adamw> tflink: well i mean define 'most'
17:57:33 <adamw> of course 'most' don't, but it's a perfectly valid config, isn't it? most x86 systems don't use multipath for anything at all.
17:57:45 <tflink> Viking-Ice: for local storage?
17:58:05 <tflink> local/internal raid
17:58:22 <Viking-Ice> yes
17:58:28 <tflink> I'm not talking about remote storage - I know that most servers use mp for remote storage
17:58:46 <tflink> huh, chalk that up to my experience being mostly with HP servers I guess
17:58:49 <Viking-Ice> oh then I'm misunderstanding
17:59:18 <tflink> either way, we're getting off topic
17:59:25 <tflink> ack
17:59:27 <adamw> tflink: yeah, even if you're right, i think my agreed stands
17:59:30 <Viking-Ice> ack
18:00:25 <tflink> adamw: it's easier if you do the #agreed - I'd rather not have to copy and re-format
18:00:32 <adamw> #agreed 866685 RejectedNTH - this only affects installs to LVM-on-multipath on OpenFirmware systems. OpenFirmware is mostly used on ppc64 systems, very rarely on i386/x86_64, though it is theoretically possible. Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical for PA. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH.
18:00:58 * rbergeron belatedly acks
18:01:10 <tflink> any other NTHs?
18:02:52 <tflink> I take that as a no - I think we're done with blocker review for the day, then
18:03:01 <Viking-Ice> have we been through 892269 alraedy
18:03:23 <tflink> Viking-Ice: yes but it hasn't been updated yet
18:03:32 <tflink> acceptedNTH and rejectedblocker IIRC
18:03:36 * tflink checks logs
18:03:42 <Viking-Ice> tflink, ok
18:04:07 <Viking-Ice> adamw, did you check the comment in the bug I ping you with when I joined the meeting
18:04:09 <adamw> okay
18:04:15 <adamw> Viking-Ice: sorry, i think i missed that. what was it?
18:04:56 <Viking-Ice> "I've added a note on this pointing users to kickstart files, and the kickstart documentation in the Installation Guide. Thanks, Jóhann."
18:05:08 <adamw> was that about your action item from earlier?
18:05:08 <Viking-Ice> just an update to my task
18:05:11 <adamw> ah ok, cool
18:05:15 <adamw> i'll update that in open floor
18:05:20 <adamw> poke me if i forget
18:05:31 <adamw> #topic Fedora 18 Final status / planning
18:05:37 <adamw> so outside of blocker review, any thoughts on f18 status?
18:05:51 <tflink> Viking-Ice: actually, you voted on 892269, no? The discussion blended in to 892494 and the transition wasn't incredibly obvious
18:06:12 <tflink> I have one item that could either be final planning or open floor
18:06:41 <adamw> may as well fire it now
18:07:16 <tflink> when should documentation be updated - I'm going to be updating FedUp documentation today and if I write it for final, people following it now won't get expected results
18:07:30 <tflink> I'm talking about the main wiki page, not the testing docs
18:07:35 <adamw> maybe hold it as a draft until the day or two before release?
18:07:39 <Viking-Ice> tflink, I sometime loose track half in dayjob half in meeting
18:07:46 <tflink> http://fedoraproject.org/wiki/FedUp
18:08:18 <tflink> Viking-Ice: no worries, just offering an explanation on why it might have been missed
18:09:42 <tflink> I suppose that works for me - hold off on updating the release-dependant stuff until a day or two before release
18:09:59 <Viking-Ice> yeah that might be best
18:10:18 <adamw> have it as a draft in your personal space or whatever
18:10:24 <adamw> so you can just copy/paste it in, a day or two before release
18:10:42 <tflink> yep, that'll work
18:10:54 <tflink> I'll update the testing docs first, then merge the changes in
18:11:16 <tflink> part of this is deduping some information but I digress
18:12:55 <tflink> the only other thing I'd like to mention is to be careful about the URL if/when testing fedup
18:13:05 <adamw> what's the good word?
18:13:10 <tflink> the URL in the test case was wrong until an hour or two ago
18:13:51 <tflink> then again, it was wrong when initially authored, so I'm not sure how many people have run through it
18:14:13 <adamw> what's the good URL?
18:14:56 <tflink> http://dl.fedoraproject.org/pub/fedora/linux/development/18/<arch>/os/
18:15:08 <tflink> where <arch> is either i386 or x86_64
18:15:27 <adamw> that's for --instrepo ?
18:15:32 <tflink> yep
18:15:57 <adamw> #info use --instrepo http://dl.fedoraproject.org/pub/fedora/linux/development/18/<arch>/os for testing fedup
18:16:25 <tflink> if there is any question about what the latest version is, ask me
18:17:03 <tflink> the process of getting the upgrade.img updated isn't 100% straight forward but I don't expect any changes before release
18:17:56 <kparal> tflink: what are the news about fedup gui?
18:18:34 <kparal> the last time I checked, the GUI disappeared from the fedora package
18:18:54 <tflink> it'll be after F18
18:19:03 <tflink> fesco decided that it wasn't a release-blocking issue
18:19:06 <adamw> okay, so i guess our plan now is to try and knock out an RC2 and get it tested today
18:19:07 <kparal> ok
18:19:11 <adamw> anyone have any other f18-specific concerns
18:19:23 <tflink> other than getting it out the door? :-P
18:19:27 <adamw> jreznik_n9: when is go/no-go scheduled again?
18:19:59 <tflink> the only thing on my mind would be to make sure that the blocker review meeting isn't scheduled for the same time or after go/no-go
18:21:05 <Viking-Ice> we should not be releasing F18 with Anaconda and Fedup in this shape but meh I give up trying to get some common sense into people
18:21:46 <adamw> according to the schedule page right now, it's wednesday at 1700 est
18:21:58 <adamw> so i guess if we want to do antoher blocker review outside of that, tomorrow or wed morning
18:21:59 <tflink> so a couple hours after blocker review
18:22:13 <tflink> er, the time we usually use for blocker review
18:22:46 <tflink> I'm thinking play it by ear until then. plan for the normal time on wednesday, move it to tomorrow if it seems needed
18:22:59 <adamw> okay
18:23:13 <adamw> #info next blocker review currently scheduled for wednesday, may move up to tomorrow if needed (more blockers emerge today)
18:23:50 <adamw> time to get crackin', I guess
18:23:53 <adamw> #topic open floor
18:24:42 <adamw> #info follow-up: "viking-ice to let docs team know about advanced storage for release notes" - this was done, install guide points advanced storage users to kickstart
18:26:05 * Viking-Ice turns the lighter on and light the fuse muhahaha
18:26:06 <adamw> anything else for open floor?
18:26:15 <adamw> my god, that was the wrong fuse
18:26:20 <adamw> that's the one connected to the bomb under canonical HQ
18:26:35 <tflink> nothing from me
18:27:06 <Viking-Ice> adamw, try calling for help using the triple U phone
18:27:28 <adamw> Viking-Ice: let's see...progress bar...looks like it'll complete the call some time in 2018
18:28:38 <Viking-Ice> we will all be using flying hoverboards by that time ;)
18:28:40 <adamw> okey dokey, looks like it's time to get on with f18 testin'
18:28:44 <adamw> thanks for coming everyone!
18:29:37 <adamw> #endmeeting