16:01:10 <tflink> #startmeeting f20beta-blocker-review-1
16:01:10 <zodbot> Meeting started Wed Sep 25 16:01:10 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:10 <tflink> #meetingname f20beta-blocker-review-1
16:01:10 <tflink> #topic Roll Call
16:01:10 <zodbot> The meeting name has been set to 'f20beta-blocker-review-1'
16:01:31 * roshi is here
16:01:33 * pwhalen is here
16:01:36 <Cerlyn> I'm here
16:01:55 * mkrizek here
16:01:59 <tflink> time for fun!
16:02:04 * satellit listening
16:02:19 <adamw> ahoyhoy
16:02:27 * adamw sets phaser to FUN
16:03:05 * jreznik is around but listening to another meeting
16:03:09 <tflink> that was quick :)
16:03:19 <tflink> any volunteers for secretary duty?
16:03:46 <roshi> I got it
16:04:31 <tflink> OK, let's get started with some boilerplate
16:04:41 <tflink> Why are we here?
16:04:41 <tflink> 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:04:48 <tflink> We'll be following the process outlined at:
16:04:48 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:04:54 <tflink> The bugs up for review today is available at:
16:04:54 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:01 <tflink> The criteria for release blocking bugs can be found at:
16:05:01 <tflink> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
16:05:04 <tflink> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
16:05:10 <tflink> #info Up for review today, we have:
16:05:18 <tflink> #info 10 Proposed Blockers
16:05:18 <tflink> #info 3 Accepted Blockers
16:05:18 <tflink> #info 0 Proposed Freeze Exceptions
16:05:18 <tflink> #info 3 Accepted Freeze Exceptions
16:05:35 * kparal can't attend today, sorry
16:05:37 <tflink> if there are no objections, we'll get started with the proposed blockers
16:05:56 <tflink> #chair adamw kparal
16:05:56 <zodbot> Current chairs: adamw kparal tflink
16:06:10 <tflink> #topic (1009809) KeyError: 'name'
16:06:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009809
16:06:10 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:07:19 <adamw> looks like this affects nfs iso installs
16:08:03 <adamw> from the criteria notes: "The installer can handle two different types of NFS repository. It can either contain a package tree, as with HTTP and FTP repositories, or it can contain the DVD ISO image of the same release as the installer. For Beta, only one of these types must work - if one works and the other doesn't, that is OK. "
16:08:04 <tflink> yeah, sounds like a blocker - crashes right away
16:08:14 <tflink> oh, good point
16:08:17 <adamw> so, actually, not a blocker, per what we decided before
16:08:18 <tflink> does nfs repo work?
16:08:30 <fenris02> nfsiso blocks beta only?
16:08:45 <adamw> fenris02: no, beta is blocked only if nfs *and* nfsiso don't work
16:08:50 <fenris02> ah, ok
16:08:54 <fenris02> seems odd though
16:08:58 <adamw> tflink: it's not 100% clear from the reports but it looks like yes
16:09:00 <adamw> um, check the matrices?
16:09:18 <adamw> fenris02: there was a previous release where we had to make a go/no-go day call whether to ship beta with one broken but the other working, iirc
16:09:22 <adamw> and we decided to ship
16:09:53 <fenris02> metrics on how / what people install would be nifty at this point
16:10:28 <adamw> tflink: hum, looks like he didn't fill out pass or fail for regular nfs for alpha
16:10:39 <adamw> logic is that you can always turn nfs<->nfsiso
16:11:07 <adamw> nfs->nfsiso would be trickier, i guess
16:11:09 <tflink> I'm not even sure that it was tried
16:11:26 <tflink> punt, someone test with nfs?
16:12:19 <adamw> for now, sure
16:13:36 <tflink> proposed #agreed 1009809 - While this could be a blocker, it isn't clear if nfs repos are working yet and only one is required to work for beta. Will revisit when we have more data on nfs repos
16:13:56 <tflink> #topic (1010453) Anaconda uses btrfs when lvm is selected in text mode
16:13:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010453
16:14:01 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:14:24 <tflink> oh
16:14:27 <tflink> #undo
16:14:27 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2aed2c50>
16:14:28 <tflink> #undo
16:14:28 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2dd9e410>
16:14:30 <tflink> #undo
16:14:30 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x29015410>
16:14:49 <roshi> +1 for 1009809 punt
16:14:51 <tflink> paying attention ftw
16:14:57 <adamw> +1 punt
16:15:02 <adamw> ack
16:15:08 <mkrizek> ack
16:15:10 <roshi> ack
16:15:20 <tflink> #agreed 1009809 - While this could be a blocker, it isn't clear if nfs repos are working yet and only one is required to work for beta. Will revisit when we have more data on nfs repos
16:15:26 <tflink> #topic (1010453) Anaconda uses btrfs when lvm is selected in text mode
16:15:29 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010453
16:15:31 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:16:22 <pwhalen> I see there is a fix now, haven't tried it. did anyone else have time?
16:16:49 <adamw> well, we've got to get people to test btrfs *somehow*...:P
16:16:52 <adamw> +1, i guess
16:16:55 <tflink> i think it was just posted today
16:17:16 <Viking-Ice> that's a fun one technically not a blocker it does indeed deliver a filesystem just not the correct one ;)
16:17:19 <tflink> +1
16:17:22 <mkrizek> +1 blocker
16:17:33 <Viking-Ice> +1
16:17:33 <pwhalen> +1
16:17:35 <fenris02> +1 block.  anaconda should do what you selected
16:17:41 <roshi> +1
16:17:52 <Viking-Ice> fenris02, anaconda is getting smarter then the user ;)
16:17:57 * fenris02 chuckles
16:18:09 <tflink> proposed #agreed 1010453 - AcceptedBlocker - Violates the following F20 beta release criterion for lvm partitioning in text installs: "Complete an installation using any combination of disk configuration options it allows the user to select"
16:18:14 <Viking-Ice> ack
16:18:20 <roshi> ack
16:18:21 <pwhalen> ack
16:18:24 <mkrizek> ack
16:18:27 <adamw> ack
16:18:37 <fenris02> ack
16:18:54 <tflink> #agreed 1010453 - AcceptedBlocker - Violates the following F20 beta release criterion for lvm partitioning in text installs: "Complete an installation using any combination of disk configuration options it allows the user to select"
16:19:06 <tflink> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device
16:19:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495
16:19:12 <tflink> #info Proposed Blocker, anaconda, NEW
16:19:52 <spstarr_work> hello
16:19:52 <fenris02> doesnt that qualify for failing to install?  the user cannot boot ..
16:20:08 <Viking-Ice> vague hw support line
16:20:09 <Viking-Ice> +1
16:20:12 <Viking-Ice> FE
16:20:35 <adamw> bcl told me in IRC the other day this won't get fixed :/
16:20:44 <Viking-Ice> Apple HW is special
16:20:45 <tflink> fun
16:20:46 <adamw> required changes too messy for f20 at this point, he says
16:20:57 <adamw> it rather sucks to ship two releases in a row which don't work properly on macs
16:20:57 <fenris02> Viking-Ice, efi (not uefi)
16:21:10 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=1010495#c6
16:21:15 <spstarr_work> adamw: for 10009809 I can test this one tonight I use NFSISO a lot for testing
16:21:51 <Viking-Ice> adamw, well we block and delay for a fix to land
16:22:06 <Viking-Ice> ( if we care enough )
16:22:39 * spstarr_work is indifferent to 1010495 i cant test this and have no EFI systems
16:23:09 <Viking-Ice> anaconda could just error out sorry efi waterproof ;)
16:23:30 <adamw> i guess i'm -1 blocker as there's no sense in shipping f19 with it broken then blocking f20 for it, but it does suck
16:23:43 <adamw> 'i'm sorry, this is a mac, and like N-O. NO.'
16:23:52 <tflink> i thought we figured this out right before f19 shipped
16:24:04 <tflink> it was reported right before f19 shipped, I mean
16:24:10 <Viking-Ice> yeah I think so
16:24:55 <Viking-Ice> is bcl here to give us gestimated delay on release if we block on this
16:25:01 <adamw> hmm, that might have been a factor
16:25:51 <adamw> i'm also interested if the stuff from comment #12 onwards affects the question of shipping the fix in f20
16:26:07 <Viking-Ice> having users having to wait additional 6 months or more for $NEXT_RELEASE is worse then we slip for three weeks or what not
16:27:11 <adamw> Viking-Ice: for the users with the affected hardware, yup
16:27:22 <Viking-Ice> adamw, for the rest of the world as well
16:27:24 <adamw> so it's a tradeoff between affected and unaffected users
16:27:36 <Viking-Ice> it's not like we have ever released on time and we aren't about to start doing that now
16:27:55 <Viking-Ice> so not slipping would be out of character but shows we care ;)
16:27:56 <fenris02> considering we already punted +1 week
16:28:04 <tflink> Viking-Ice: and with that attitude, we'll never ship on time
16:28:19 <Viking-Ice> tflink, only if we never be ready
16:28:21 <tflink> so the question comes down to two things:
16:28:45 <adamw> looks like bcl isn't around (or is playing possum)
16:28:46 <fenris02> mac hw is funky, but is relatively common.
16:28:48 <tflink> 1) how long would it take to add needed functionality to support macs
16:29:10 <fenris02> can anyone else speak to the issue, or is bcl the one and only?
16:29:11 <tflink> 2) how many users would be affected by this and are we OK with two releases that won't work on apple HW
16:29:48 <Viking-Ice> I personally think one fine two releases user == gone
16:30:10 <adamw> there is a significant difference between 1 and 2 releases, yeah, with the maintenance cycle
16:30:23 <adamw> but if it's really that disruptive a change we have to take that into account
16:30:25 <tflink> especially if we end up delaying f21
16:31:04 <Viking-Ice> you mean if we get what would we do if we had time time
16:31:32 <bcl> adamw: I'd rather not block on mac stuff.
16:31:39 <tflink> Viking-Ice: yeah, that reminds me that I need to go check on what happened to that conversation
16:31:53 <bcl> I *may* have time to try out a label idea, I can do that w/o the new parted, but I may not.
16:32:03 <adamw> bcl: heh, we keep going around the roundabout on this one, then
16:32:06 <Viking-Ice> bcl,  what are we talking much delay here
16:32:10 <roshi> does anyone have even a guess as to the percentage of users on mac hw?
16:32:19 <tflink> not anymore
16:32:24 <adamw> i recall a few releases back we used to explicitly except Macs from the install criteria, then we changed that because it seemed like everyone agreed we should support them
16:32:30 <adamw> now we're going to put it back?
16:32:44 <adamw> roshi: usable stats on this kind of question is something we're really lacking :/
16:32:45 <bcl> I do actually dual boot mine, but once I've installed once I just fedup things.
16:32:53 <tflink> we used to have smolt but it died and census hasn't been deployed yet
16:32:54 * roshi takes a note of that
16:33:06 <Viking-Ice> delayed 2 releases and those users on apple hw gone
16:33:10 <jreznik> some guys were complaining on g+ how bad it is not to support macs but we only way we can support it - is to have people working on macs and have macs available...
16:33:21 <bcl> adamw: Ill not debate criteria, but IIRC that's because we thought it was working.
16:33:26 * satellit_e Virtualbox works on my macbook pro
16:33:38 <bcl> What we have here is it not working, and no solution pending ATM, just some ideas.
16:33:51 <adamw> you're meaning in a kind of 'structural' sense
16:33:53 <adamw> right?
16:34:03 <bcl> which is really stuff that should happen in that short time between releases that we have ;)
16:34:07 <adamw> it's not just a bug but a kind of incompatibility of approach...
16:34:17 <Viking-Ice> bcl, just throw wwoods at it he works well under pressure fueled by moonshine ( just look at fedup )
16:34:22 <bcl> right.
16:34:47 <bcl> our HFS+ ESP looks like a mac HFS+ boot disk, and we don't yet have a good way to tell the difference between them.
16:35:06 <bcl> on one hand that's good, because it shows up in the lists and boots with a nice icon.
16:35:16 <adamw> it's becoming more a policy question than anything :/
16:35:26 <bcl> On the other hand, IIRC the workaround is to just delete it and make a new one.
16:36:02 <tflink> would just making a new one every time work?
16:36:12 <bcl> It isn't really stopping you from installing, it just makes it more manual. and nothing has changed with regards to that from f19.
16:36:36 <bcl> tflink: then you end up with more than 1 which is something we fixed :)
16:36:37 <adamw> well, it makes it quite a *lot* more manual, really
16:36:55 <Viking-Ice> cant we detect delete make new one
16:37:03 <Viking-Ice> then
16:37:04 <tflink> bcl: true, but if it's a choice between not working and having a bunch of them, which is worse?
16:37:09 <adamw> the difference between 'i can use the guided path and everything works' and 'i have to know how to create an EFI-bootable layout with custom partitioning' is quite a big one
16:37:29 <Viking-Ice> yeah those are not waterproof steps
16:37:38 <bcl> I'll have to run through it again, but I think you can just delete it in the recover space dialog.
16:38:03 <tflink> wouldn't that run the risk of deleting the OSX loader as well?
16:38:12 <bcl> tflink: my memory is fuzzy, but having more wasn't good either.
16:38:24 <adamw> right, i don't see how OS X can still boot if you nuke its ESP during fedora installation.
16:38:27 <bcl> tflink: only if you pick the wrong one
16:38:39 <adamw> eh?
16:38:46 <adamw> how can os x still boot if you nuke its esp?
16:38:55 <bcl> adamw: you're not. you're nuking ours.
16:39:11 <bcl> OSX has its own. It is usually alot larger than ours.
16:39:12 <tflink> bcl: and since the issue at hand is telling the difference between the two, installation becomes a bit more like russian roulette :)
16:39:17 <adamw> um. my understanding of the bug is that it affects the case of simply taking a clean OS X box and trying to install fedora on top of it
16:39:25 <adamw> so what 'our' esp are you nuking? what am I missing?
16:39:28 <bcl> no
16:39:46 <bcl> this bug (unless I'm totally out to lunch) is when re-installing on top of a previous install.
16:39:49 <adamw> ah
16:39:56 <adamw> i may be missing that
16:40:03 <Viking-Ice> but if you are re-installing that should be fine no?
16:40:09 <bcl> AFAIK if you take a clean system with enough extra space (shrink OSX in OSX) it works fine.
16:40:09 <Viking-Ice> ( to nuke it that is )
16:40:11 <adamw> "Steps to Reproduce:
16:40:11 <adamw> 1. Computer contains either a default OS X installation, or a default Fedora 18 or 19 installation."
16:40:22 <bcl> take a look at the old bug that chris closed.
16:41:04 <adamw> the initial description of that bug talks about a case of a reinstall over an existing fedora install, yes, but i thought the issue had been found to be wider
16:41:06 <bcl> 1. OS X installed, and successful F18 or F19 system already instaled.
16:41:10 <bcl> was what it used to say.
16:41:26 <bcl> (no idea why he closed and duped that, it should have just stayed open)
16:42:16 <Viking-Ice> yeah and you usually close the newer bug dupe of the old one
16:42:17 <bcl> anyway, you guys decide if you want to block. I will at least re-visit it and make sure I understand it.
16:42:18 <adamw> right, but like i said, that's just the initial description
16:42:26 <adamw> later on it seems to change
16:42:33 <bcl> I *may* try adding a lable, etc. if I find the time.
16:42:38 <adamw> e.g. c#29: "So the bug is triggered merely by having any ESP on the disk."
16:42:55 <adamw> and presumably the more recent bug description ought to be more accurate than an older one, all else being equal
16:42:56 <bcl> rampant random speculation :)
16:43:04 <Viking-Ice> so let' s pull it in as an FE ( so we wont forget it  ) and see how it goes
16:43:18 <bcl> I don't trust any of it unless I test it myself.
16:44:17 <adamw> still, it's clear we're working from different assumptions
16:44:20 <tflink> votes?
16:44:27 <tflink> punt? FE?
16:44:29 <Viking-Ice> +1 FE
16:44:33 <bcl> adamw: right. need more facts :)
16:44:34 <tflink> run away?
16:44:46 <tflink> personally, I'm +1 to run away :)
16:44:48 <adamw> there's a significant difference between 'affects re-install over an existing fedora install, can be worked around by deleting the old fedora ESP' and 'affects any attempt to auto-partition alongside an existing EFI OS'
16:44:53 <adamw> +1 beer
16:45:00 <roshi> +1 beer too
16:45:05 <tflink> better than running away
16:45:14 * roshi would prefer bourbon though...
16:45:16 <adamw> +1 punt, ask cmurf to confirm once and for all which description is accurate
16:45:29 <adamw> if it's the more serious case, bcl, would you be open to re-considering blocker status?
16:45:32 * Viking-Ice goes out for a smoke while you guys drink beer
16:46:28 <roshi> +1 on the punt
16:46:28 <bcl> adamw: or someone less verbose.
16:46:38 <adamw> bcl: heh, us word fountains have gotta stick together
16:46:45 <bcl> If it blocks installing to a clean system I'm +1
16:46:50 <adamw> OK
16:46:55 <bcl> that used to work fine IIRC.
16:47:05 <tflink> proposed #agreed 1010495 - It's still not completely clear what is going on here and we need more information on the issue and any possible fixes. Will revisit when there is more available information
16:47:10 <adamw> there were definitely a couple of releases where it worked, yep.
16:47:20 <adamw> nack, make it a bit more specific?
16:48:06 <adamw> proposed #agreed 1010495 - there's a question as to whether this affects only systems with two existing ESPs, or any system with an existing EFI OS installation. We will establish this and re-visit the bug next time.
16:48:30 <tflink> ack
16:49:12 <roshi> ack
16:49:39 <adamw> #agreed 1010495 - there's a question as to whether this affects only systems with two existing ESPs, or any system with an existing EFI OS installation. We will establish this and re-visit the bug next time.
16:50:10 <tflink> #topic (908118) Rescue mode does not detect an encrypted Fedora installation
16:50:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=908118
16:50:15 <tflink> #info Proposed Blocker, anaconda, NEW
16:50:58 <adamw> "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria"
16:51:00 <adamw> seems pretty clear
16:51:06 <adamw> +1 per criteria
16:51:19 <tflink> +1
16:51:23 <mkrizek> +1
16:51:56 <tflink> proposed #agreed 908118 - AcceptedBlocker - Violates the following F20 beta criterion for systems with encrypted partitions: "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations."
16:52:09 <roshi> ack
16:52:12 <adamw> ack
16:52:14 <mkrizek> ack
16:52:36 <tflink> #agreed 908118 - AcceptedBlocker - Violates the following F20 beta criterion for systems with encrypted partitions: "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations."
16:52:41 <tflink> #topic (986575) installer fails to apply lower bound to resize requests in custom spoke
16:52:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=986575
16:52:46 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
16:53:53 <tflink> +1 per criterion: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing"
16:53:57 <adamw> yeah, +1
16:54:05 <mkrizek> +1
16:54:53 <tflink> proposed #agreed 986575 - AcceptedBlocker - Violates the following f20 beta criterion when setting partition sizes smaller than usable for installation: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing"
16:55:09 <adamw> ack
16:55:11 <mkrizek> ack
16:56:11 <spstarr_work> +1 and ack on that
16:56:33 <tflink> #agreed 986575 - AcceptedBlocker - Violates the following f20 beta criterion when setting partition sizes smaller than usable for installation: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing"
16:57:01 <tflink> #topic (1009278) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128)
16:57:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009278
16:57:07 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:57:36 <adamw> i feel +1 on this for beta, do we have a criterion?
16:57:48 <tflink> not sure, but I'm also +1
16:57:59 <Viking-Ice> +1
16:58:05 <tflink> 3 people have reported this in the last 2 days
16:58:11 <tflink> reported/duped
16:58:25 <spstarr_work> +1
16:58:31 <mkrizek> yeah +1
16:58:46 <adamw> we don't really have a good criterion for this that I can see
16:59:00 <spstarr_work> I did not hit this however not in RC3 even but that looks bad
16:59:01 <tflink> but as far as criteria go ... the closest I can think of is the alpha "must complete" crierion
16:59:07 <adamw> we can kinda fudge it under "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. ", yeah
16:59:19 <adamw> but it sucks to go too far towards using that as a catch-all, we should probably have something specific
16:59:31 <adamw> still, let's use it for now
16:59:32 <adamw> +1
16:59:33 <Viking-Ice> we need "we deemed it so" criteria
17:00:10 <tflink> this doesn't happen with the dedicated installer images, though
17:00:29 <tflink> just lives, IIRC
17:00:56 <adamw> Viking-Ice: that's more or less what we use this one as
17:01:12 <adamw> tflink: well it'll have to be 'violates this criterion in the case of XXX' anyway, so
17:01:35 <tflink> yeah, I was just looking again and hoping that there was something else
17:02:24 <tflink> proposed #agreed 1009278 - AcceptedBlocker - Violates the following F20 alpha criterion for liveinstalls with a non-default keyboard: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
17:02:33 <adamw> ack
17:02:39 <mkrizek> ack
17:03:52 <tflink> ack/nak/patch?
17:04:57 <tflink> Viking-Ice, roshi, spstarr_work: ack/nak/patch?
17:05:01 <Viking-Ice> ack
17:05:06 <tflink> #agreed 1009278 - AcceptedBlocker - Violates the following F20 alpha criterion for liveinstalls with a non-default keyboard: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
17:05:13 <tflink> #topic (1008965) mouse cursor sometimes disappears on login
17:05:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008965
17:05:13 <tflink> #info Proposed Blocker, gnome-settings-daemon, NEW
17:05:37 <adamw> not sure this really needs to block beta, though it is a pain
17:05:42 <Viking-Ice> is that a vm?
17:05:57 <tflink> I've seen this on bare metal
17:06:02 <Viking-Ice> ( I know about a bug that resets mouse speed when using a vm dont know if I reported it thou )
17:06:32 <Viking-Ice> I have actually seen this with rdesktop ( or similar bug ) on F18
17:06:33 <tflink> do we even have a criterion for this?
17:06:38 <Viking-Ice> +1 FE
17:06:57 <Viking-Ice> it's a nuance which you can live with
17:07:03 <Viking-Ice> in beta
17:07:23 <tflink> I'm on the fence, g-i-s is kinda crappy w/o a cursor
17:07:27 <jreznik> definitely +1 FE (so in this time more to push devels to take a look than the need for freeze exception)
17:07:45 <tflink> s/kinda/pretty/
17:08:22 <adamw> there's the 'kill g-s-d' workaround
17:08:29 <adamw> does that leave gsd dead or make it respawn, btw?
17:08:51 <spstarr_work> tflink: sorry, awk on previous bug
17:08:53 <spstarr_work> ack
17:09:16 <tflink> adamw: one would hope that it respawns
17:09:37 <adamw> is that a sneaky way of saying 'it should respawn', tflink? :)
17:09:44 <adamw> i spy someone trying to smuggle in an s word
17:10:16 <Viking-Ice> let's not dwell to long with this
17:10:37 <tflink> it's like saying heck instead of hell
17:10:39 <tflink> :)
17:10:40 <Viking-Ice> I'm pretty sure the guys will have fixed this for beta anyway
17:11:02 <adamw> Viking-Ice: that's the kind of thing that's bitten us in the ass before, but yeah, for now -1/+1
17:11:20 <roshi> has anyone tried the kparal patch?
17:11:58 <Viking-Ice> http://koji.fedoraproject.org/koji/taskinfo?taskID=5981871
17:12:04 <Viking-Ice> contains that patch
17:12:24 <adamw> not yet, didn't see it
17:12:57 <tflink> proposed #agreed 1008965 - RejectedBlocker AcceptedFreezeException - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a blocker for f20 beta. However, a tested fix would be considered past freeze.
17:13:02 <Viking-Ice> ack
17:13:34 <adamw> ack
17:13:36 <roshi> ack
17:14:01 <tflink> #agreed 1008965 - RejectedBlocker AcceptedFreezeException - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a blocker for f20 beta. However, a tested fix would be considered past freeze.
17:14:18 <tflink> #topic (1009132) updates-plugin-WARNING **: failed to download: The backend exited unexpectedly.
17:14:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009132
17:14:24 <tflink> #info Proposed Blocker, gnome-settings-daemon, ASSIGNED
17:14:59 <adamw> should be a blocker by the criteria
17:15:12 <Viking-Ice> yeah
17:15:14 <adamw> assuming it's reproducible and not a freak case
17:15:41 <tflink> bah, I haven't made the actual criteria changes yet
17:15:57 <Viking-Ice> make it so nr1
17:16:11 <tflink> so nr1?
17:16:42 <adamw> make it so, number one
17:16:48 <Viking-Ice> http://askmarcbarrett.com/wp-content/uploads/2012/12/star-trek-make-it-so-300x200.jpg
17:16:52 <tflink> oh, ok
17:16:59 <tflink> I thought that was some other abbreviations
17:17:57 <spstarr_work> that would sound like a blocker to me too
17:18:29 <spstarr_work> a user not able to perform updates *ever* is bad (if they don't use yum manually on cli)
17:18:55 <spstarr_work> workaroundable, possible if its broken package
17:20:23 <adamw> +1
17:20:27 * tflink is looking for the criteria change
17:20:51 <spstarr_work> +1
17:21:33 <tflink> proposed #agreed 1009132 - AcceptedBlocker - Violates the following F20 beta criterion for graphical updates on a gnome install: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops."
17:21:41 <Viking-Ice> ack
17:21:43 <jreznik> +1, we should sort it out by beta (with that whole g-s vs old pkg kit thing)
17:21:49 <jreznik> ack
17:21:51 <spstarr_work> ack
17:22:26 <adamw> ack
17:23:09 <roshi> ack
17:23:26 <tflink> #agreed 1009132 - AcceptedBlocker - Violates the following F20 beta criterion for graphical updates on a gnome install: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops."
17:23:44 <tflink> #topic (1004572) AttributeError: 'NoneType' object has no attribute 'id'
17:23:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1004572
17:23:50 <tflink> #info Proposed Blocker, python-blivet, ON_QA
17:24:20 <spstarr_work> +1
17:24:35 <roshi> adamw: do you want to update the wiki with the new criteria for 1009132?
17:25:28 <spstarr_work> Anaconda partition crashes are bad if we want Anaconda to be solid at partitioning
17:25:34 <adamw> roshi: i think it's on tflink's todo
17:25:39 <adamw> he proposed the change
17:25:50 <Viking-Ice> is this not fixed yet via traditional update?
17:26:15 <adamw> not pushed stable yet
17:26:15 <roshi> adamw: you proposed the change 18SEP on test@
17:26:22 <adamw> roshi: i did? oh, good for me
17:26:24 <adamw> then yes, i will :)
17:26:29 <roshi> :)
17:26:36 <adamw> now, what did I come in here for?
17:26:38 <tflink> I did?
17:26:41 <adamw> why are there kids on my lawn?
17:26:54 <adamw> this will likely be pushed stable soona nyhow, but +1
17:26:54 <Viking-Ice> because they did not find the mud?
17:27:01 <tflink> yeah +1
17:27:01 <Viking-Ice> +1
17:27:04 <roshi> +1
17:27:40 <mkrizek> +1
17:27:42 <adamw> if you want a criterion then "Assign mount points to existing storage volumes" in beta
17:27:52 <adamw> and/or "Complete an installation using any combination of disk configuration options it allows the user to select " for guided
17:28:45 <tflink> proposed #agreed 1004572 - AcceptedBlocker - Violates the follwing F20 beta release criterion: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
17:28:58 <tflink> is tha ttoo long?
17:29:08 <adamw> nope, works fine
17:29:19 <adamw> roshi: you could cite both criteria in the note if you want extra credit ;)
17:29:49 <tflink> ack/nak/patch?
17:29:51 <roshi> adamw: how many extra credits?
17:29:53 <roshi> ack
17:29:55 <spstarr_work> ack
17:30:46 <adamw> sixty three
17:30:59 <tflink> sixty three == ack ?
17:31:14 <roshi> Federation or Republic?
17:31:22 <spstarr_work> lol
17:31:50 * tflink dons moustache and says ... ack
17:31:53 <adamw> Imperial
17:31:59 <adamw> le ack
17:32:01 <tflink> #agreed 1004572 - AcceptedBlocker - Violates the follwing F20 beta release criterion: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
17:32:04 <Viking-Ice> ack
17:32:18 <tflink> #topic (1005506) TypeError: unsupported operand type(s) for +: 'long' and 'NoneType'
17:32:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1005506
17:32:24 <tflink> #info Proposed Blocker, python-blivet, MODIFIED
17:32:51 <Viking-Ice> +1
17:32:55 <spstarr_work> +1
17:32:58 <tflink> +1
17:33:25 <tflink> proposed #agreed 1005506 - AcceptedBlocker - Violates the following F20 beta release criterion: "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
17:33:29 <spstarr_work> partition code is gosh darn hard :(
17:33:30 <tflink> ack/nak/patch?
17:33:34 <spstarr_work> ack
17:33:42 <adamw> ack
17:33:43 <Viking-Ice> ack
17:33:46 <jreznik> ack
17:34:01 <tflink> #agreed 1005506 - AcceptedBlocker - Violates the following F20 beta release criterion: "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
17:34:40 <tflink> OK, that's all of the propose blockers on my list today
17:34:55 <adamw> yay
17:35:07 <spstarr_work> the partition ones worry me
17:35:18 <spstarr_work> and probably will until Anaconda handles all those cases :/
17:35:29 <tflink> on to the accepted freeze exceptions
17:35:34 <tflink> er, accepted blockers
17:36:00 <tflink> hrm, do we want to go over the oversize bugs?
17:36:05 <tflink> is anyone working on them?
17:36:32 <jreznik> not yet but I can start poking
17:36:38 <adamw> best get it done
17:36:49 <jreznik> notting is probably the first one to start with
17:36:57 <tflink> #topic (1000891) DVD is oversized (larger than 4.7 GB)
17:36:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891
17:36:57 <tflink> #info Accepted Blocker, distribution, NEW
17:37:04 <roshi> 1005506 seems to be a dupe of 1004572
17:37:13 <roshi> ...?
17:38:00 <tflink> not sure there's much to say
17:38:02 <tflink> here
17:38:02 <adamw> heh
17:38:16 <adamw> i meant get the poking done, not set a topic for the bug
17:38:18 <roshi> AcceptedBlocker++? Is that a thing?
17:38:21 <adamw> but sure, we need to poke notting
17:38:29 <adamw> double-plus accepted
17:38:36 <tflink> other than to prepare for the flamewar on devel@ on what can be accepted
17:38:48 <spstarr_work> i guess my new rubygem in Fedora 20 is the cause ;)
17:39:02 <Viking-Ice> we should just drop that dvd altogether
17:39:36 <Viking-Ice> and just use netinstall or sub-community's images ;)
17:40:14 * adamw leaves that one alone
17:40:32 <tflink> #info work on this process needs to be started soon
17:41:03 <tflink> #action adamw and/or jreznik to start pestering folks to get stuff removed from the dvd
17:41:34 <tflink> ok, assuming that I didn't miss any bugs, it would be time for:
17:41:38 <tflink> #topic Open Floor
17:41:48 <tflink> Anything else that needs to be brought up today?
17:41:59 <spstarr_work> Wayland testing possible ?
17:42:07 <Viking-Ice> not there yet
17:42:47 <Viking-Ice> well it's possible in theory
17:43:48 <spstarr_work> what is our most urgent testing needs now?
17:44:05 <Viking-Ice> those readying this and want to play with wayland in it's brokeness --> log in, drop to a VT and run "gnome-session --session=gnome-shell-wayland" <--
17:44:22 <adamw> nothing specifically urgent i don't think
17:44:22 <spstarr_work> i have class tonight and can allocate from 4:30pm-6:40pm QA cycles
17:44:29 <Viking-Ice> test matrix/test days
17:44:51 * tflink sets the fuse for (0,5] minutes
17:44:57 <adamw> be useful to run any un-done beta tests against alpha to catch blockers early
17:45:05 <Viking-Ice> tflink, make that a quantum fues
17:45:07 <Viking-Ice> mean fues
17:45:09 <spstarr_work> so, please let me know and I will do what I can remotely
17:45:10 <Viking-Ice> frack fuse
17:45:21 <spstarr_work> adamw: yes
17:45:35 * spstarr_work looksat list
17:45:43 * tflink resets the quantum fuse for (0,5] minutes
17:46:09 * Viking-Ice fires a fire arrow up in the air
17:46:12 <tflink> ok
17:46:16 <tflink> thanks for coming, everyone
17:46:22 * tflink will send out minutes shortly
17:46:48 <tflink> #info next f20 beta blocker review meeting will be 2013-10-02 @ 16:00 UTC
17:46:52 <tflink> #endmeeting