17:01:20 <roshi> #startmeeting F20 Final Blocker Review
17:01:20 <zodbot> Meeting started Wed Nov 13 17:01:20 2013 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:29 <tflink> #fire roshi?
17:01:32 <tflink> :-D
17:01:38 <roshi> whenever I see # I think channel names
17:01:45 <tflink> roshi: you want to set meetingname, too
17:01:57 <tflink> numbers in the meeting name also help
17:02:15 <roshi> #meetingname F20 Final Blocker Review #1
17:02:15 <zodbot> The meeting name has been set to 'f20_final_blocker_review_#1'
17:02:17 <tflink> ie, using #startmeeting f20-final-blocker-review-1
17:02:30 * tflink isn't sure spaces render well for meetbot logs
17:02:35 <roshi> #undo
17:02:50 <roshi> #meetingname f20-final-blocker-review-1
17:02:50 <zodbot> The meeting name has been set to 'f20-final-blocker-review-1'
17:03:35 <roshi> #topic Roll Call
17:04:23 <adamw> tflink: you can use a fancy name for #startmeeting , that works fine.
17:04:43 <tflink> adamw: ok, I just used less-fancy-names to be safe
17:04:45 * roshi is here
17:04:52 * pwhalen is here
17:05:02 * tflink is present
17:05:20 * adamw is around
17:05:22 * kparal is late
17:05:38 <roshi> #chair kparal tflink
17:05:38 <zodbot> Current chairs: kparal roshi tflink
17:05:42 * kparal will be ready in 2 minutes
17:06:05 * jreznik is ready
17:06:23 <roshi> anyone have an issue giving kparal 2 minutes?
17:06:24 <jreznik> (with hard stop 1:30)
17:06:34 <kparal> roshi: don't wait on me :)
17:06:39 <kparal> go ahead
17:06:41 <roshi> kk
17:07:08 <roshi> #topic Introduction
17:07:11 <roshi> Why are we here?
17:07:33 <roshi> #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.
17:07:43 * adamw calls the philosophy sig
17:07:48 <roshi> #info We'll be following the process outlined at:
17:07:48 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:07:49 <roshi> #info The bugs up for review today are available at:
17:07:49 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
17:07:49 <roshi> #info The criteria for release blocking bugs can be found at:
17:07:49 <roshi> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
17:07:49 <roshi> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
17:07:50 <roshi> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
17:08:16 <roshi> Currently we have:
17:08:18 <roshi> #info 20 Proposed Blockers
17:08:18 <roshi> #info 2 Accepted Blockers
17:08:18 <roshi> #info 4 Proposed Freeze Exceptions
17:08:18 <roshi> #info 0 Accepted Freeze Exceptions
17:08:23 <tflink> oof
17:08:30 <tflink> 20 proposed?
17:08:43 <roshi> yep
17:08:45 <kparal> how convenient. I was just getting bored
17:08:51 <roshi> haha
17:09:01 <roshi> onto the proposed blockers!
17:09:03 * tflink runs away and goes back to writing code
17:09:07 <tflink> :)
17:09:12 <roshi> #topic (1028367) Invalid resize operation crashes
17:09:12 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1028367
17:09:12 <roshi> #info Proposed Blocker, anaconda, NEW
17:09:33 <roshi> any volunteers to secretarialize?
17:09:37 <tflink> did anyone continue the "what is a blocker" discussion with dlehman et. al?
17:09:58 <kparal> (inviting anaconda team could be a good idea too)
17:10:48 <jreznik> maybe skip resize related bugs now and work on the criteria first?
17:11:06 * adamw will secretarialize
17:11:30 <adamw> i think we have a reasonable handle on resize issues for final
17:12:01 <kparal> so which type of bugs do we want to exclude in particular? because this concrete issue is I think quite obvious violation of the criteria
17:12:55 <roshi> I agree with kparal
17:13:10 <roshi> but I don't see much issue with punting on some of them until next week
17:13:25 <kparal> lets decide to punt individually
17:13:39 <roshi> that was my thought exactly
17:13:42 <kparal> +1 here
17:14:11 <adamw> yeah, +1
17:14:23 <jreznik> +1, this is pretty clear one
17:14:24 <roshi> +1 to punt individually or to punt this bug?
17:14:29 <adamw> +1 blocker
17:14:31 <kparal> +1 blocker
17:14:37 <jreznik> +1 blocker
17:16:39 <roshi> proposed  #agreed 1028367 - AcceptedBlocker - This issue clearly violates the Final Release Criteria
17:16:46 <roshi> sorry I'm so slow
17:16:48 <roshi> :(
17:17:23 <adamw> patch
17:17:35 <adamw> it's much better to explain what it violates exactly
17:17:53 <roshi> proposed  #agreed 1028367 - AcceptedBlocker - This issue clearly violates the Final Release Criteria "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
17:18:12 <kparal> the one from comment 4 might be better
17:18:23 <kparal> but that's not that important
17:18:25 <adamw> proposed #agreed 1028367 - AcceptedBlocker - violates "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." in the context of resizes, which are blocker issues for Final
17:18:31 <adamw> yeah, that's not the right criterion.
17:18:40 <kparal> ack
17:18:51 <adamw> the layout in question isn't 'workable', but it should be correctly disallowed.
17:19:00 <jreznik> yep
17:19:07 <jreznik> ack
17:19:15 <roshi> ack
17:19:37 <roshi> I was just looking at final criteria - which doesn't have a resize criterion
17:19:56 <roshi> #agreed 1028367 - AcceptedBlocker - violates "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." in the context of resizes, which are blocker issues for Final
17:20:09 <adamw> roshi: yeah, it does: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
17:20:14 <adamw> but that doesn't quite apply here
17:20:37 * roshi obviously needs to be more familiar with all the release criterion
17:20:41 <roshi> :-/
17:20:43 <adamw> the 'reject or disallow' one is better; only problem is that we need to somehow clarify that we want to restrict its scope at beta time. eh, well.
17:20:52 <adamw> roshi: there will be a test later =)
17:20:52 <kparal> roshi: don't worry, only adamw knows them by heart
17:20:58 <roshi> onto the next?
17:21:01 <kparal> yes
17:21:05 <kparal> no
17:21:05 <roshi> #topic (1019502) disk image installation has issues with bootloader and initramfs
17:21:05 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1019502
17:21:05 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
17:21:15 <roshi> ?
17:21:15 <kparal> roshi: you had a comma before #accepted
17:21:21 <kparal> eh, #agreed
17:21:37 <kparal> so, now do triple #undo :)
17:21:42 <roshi> #agreed 1028367 - AcceptedBlocker - violates "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." in the context of resizes, which are blocker issues for Final
17:21:43 <kparal> then do #agreed
17:21:49 <kparal> or this way :)
17:21:50 <roshi> #undo
17:21:50 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x13b3a9d0>
17:21:55 <roshi> #undo
17:21:55 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x14262b90>
17:22:04 <roshi> #undo
17:22:04 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x12cf5d50>
17:22:10 <roshi> #undo
17:22:10 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x14262f10>
17:22:10 <kparal> 1 more to go
17:22:12 <kparal> yep
17:22:17 <kparal> now do #agreed
17:22:24 <roshi> #agreed 1028367 - AcceptedBlocker - violates "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." in the context of resizes, which are blocker issues for Final
17:22:32 <kparal> and now we can go to the next bug :)
17:22:38 <tflink> actually, you did it wrong :)
17:22:45 <roshi> welcome to the amateur-hour :)
17:22:47 <kparal> it seems OK to me
17:22:48 <tflink> there was a space before the first #agreed
17:22:54 <kparal> ugh
17:23:00 <tflink> so you just undid the topic from the previous bug
17:23:17 <kparal> tflink: no, it's OK
17:23:21 <tflink> yeah, I was wrong
17:23:22 <roshi> I #agreed again before that
17:23:27 <tflink> missed that part
17:23:29 <kparal> it should be fine now
17:23:33 <roshi> so now we're good to go on
17:23:58 <roshi> #topic (1019502) disk image installation has issues with bootloader and initramfs
17:23:58 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1019502
17:23:58 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
17:24:55 * jreznik agrees with adamw in comment #4
17:25:03 <kparal> what is "Installation to an image file"?
17:25:05 <adamw> i'm not sure we really explicitly support this, not sure if we need to
17:25:54 <tflink> cloud?
17:26:03 * tflink doesn't know how they're currently building images
17:26:25 <adamw> i don't think this way
17:26:29 <bcl> livemedia-creator can use this.
17:26:39 <kparal> so that you create a file, mount it as a virtual drive, and run anaconda on it?
17:26:43 <bcl> I don't think it's a blocker though. and he has patches.
17:26:46 <adamw> oh, bcl's here
17:27:04 <bcl> kparal: just point anaconda to an image file.
17:27:10 <adamw> as per the reproducer steps
17:27:22 <adamw> presumably you can pass inst.image at the cmdline too?
17:27:30 <kparal> that's cool, we can test anaconda outside of VM?
17:27:41 <bcl> adamw: no
17:27:51 <bcl> err, maybe, but it isn't used like that.
17:27:52 <adamw> well i guess i can'
17:27:55 <adamw> t have nice things.
17:27:57 <bcl> you run anaconda from a cmdline.
17:28:32 <kparal> so, is cloud SIG blocked on this or something?
17:29:00 <tflink> cloud was a guess on my part, I suspect they're using something different though
17:30:00 <kparal> unless something important is blocked, I guess -1 blocker, because probably it's not used much (I've never heard of it before)
17:30:13 <roshi> I'm seeing -1?
17:30:21 <adamw> yeah, -1 unless this blocks cloud image building, which i don't think it does
17:30:39 <kparal> ask to repropose if there is a serious use case
17:30:54 * adamw checking with dgilmore
17:30:56 <jreznik> bcl: do you know if cloud guys use livemedia-creator for cloud images? /me is reading the feature and it's mentioned there
17:31:11 <jreznik> trying to read https://fedoraproject.org/wiki/Features/FirstClassCloudImages
17:31:45 <bcl> I don't think fedora is using it yet.
17:32:02 <bcl> but matt would know better than me.
17:32:04 <jreznik> but for now, I'd be ok with -1/+1 and recheck if it blocks cloud images but looking on bug creation and as we have cloud images...
17:32:22 <adamw> yeah.
17:32:33 <adamw> don't know if i'm even +1 FE, really.
17:32:34 <bcl> basically, it has fixes, they've been tested, etc. they should be included.
17:33:10 <kparal> bcl: they can be included until freeze freely
17:34:07 <roshi> is there a point in talking about FE's when we're not frozen?
17:34:39 <adamw> roshi: sure, because at some point we will be frozen. saves doing it later.
17:34:51 <adamw> but not worth agonizing over.
17:34:53 <roshi> ok
17:35:03 <adamw> bcl: we're not frozen for final, things don't need FE to get in at present.
17:35:18 <roshi> any other votes? tflink kparal?
17:35:39 <kparal> -1 blocker, no FE vote (not proposed)
17:35:57 <kparal> let's vote on FE if proposed
17:36:09 <roshi> makes sense
17:36:22 <jreznik> ok
17:36:26 <roshi> proposed #agreed 1019502 - RejectedBlocker - No release criteria are violated by this bug. Please re-propose as a blocker if this blocks building cloud images.
17:36:40 <roshi> writing these things is harder than I thought it would be
17:37:03 <kparal> :)
17:37:08 <adamw> ack
17:37:11 <adamw> you get the hang of it :)
17:37:11 <kparal> ack
17:37:46 <roshi> :)
17:38:01 <roshi> I think I've forgotten to vote
17:38:03 <roshi> -1, ack
17:38:12 <roshi> #agreed 1019502 - RejectedBlocker - No release criteria are violated by this bug. Please re-propose as a blocker if this blocks building cloud images.
17:38:30 <roshi> #topic (1027947) ValueError: new size same as old size
17:38:30 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027947
17:38:30 <roshi> #info Proposed Blocker, anaconda, POST
17:39:59 <kparal> same as the first bug, +1 blocker
17:40:15 <roshi> +1 with comment 16
17:41:23 <adamw> i guess +1
17:41:29 <jreznik> the same sort of bug, +1 blocker
17:42:01 <jreznik> maybe it would be worth checking this fix with the first one bug
17:43:11 <roshi> proposed #agreed 1027947 - AcceptedBlocker - This clearly violates the Final release criteria: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
17:44:09 <adamw> nope, it still doesn't :)
17:44:15 <adamw> at least as I read it
17:44:33 <adamw> the bug is that it attempts a resize operation at all, really, when the volume is returned to its original size.
17:44:55 <kparal> the criteria should be the same as in the first bug
17:44:59 <adamw> which, hum, makes the criterion a little tricky, but probably the first one you proposed for the first bug (the 'valid layout' one)
17:45:11 <adamw> kparal: nope, because it's not an 'invalid operation' (afaik)
17:46:57 <kparal> adamw: the first operation was invalid
17:47:02 <roshi> hrm, now I'm not so sure
17:47:03 <kparal> adamw: it crashed after the second
17:47:15 <kparal> which is not important, it crashed
17:47:28 <kparal> "130 GB on my 20 GB disk"
17:47:29 <adamw> true
17:47:46 <kparal> the first operation should have been rejected
17:47:53 <adamw> but you might be able to hit this if the first resize operation was valid
17:47:53 <kparal> wasn't, and caused a crash in a while
17:48:07 <kparal> adamw: well, we don't know that
17:48:09 <adamw> the crash, to me, is related to changing the size back to the original size, not initially setting it larger than the disk
17:48:23 <kparal> ok, I had the other idea
17:48:24 <adamw> we don't know it for sure, but the error rather suggests it
17:48:25 <adamw> "ValueError: new size same as old size"
17:48:50 <kparal> let's just pick one criterion
17:48:51 <roshi> I read the crash as being: anaconda sets wrong value - when going to reset the value it reads the wrong value and crashes
17:48:52 <adamw> so i'd say "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
17:49:10 <roshi> it read to me as "Reject or disallow invalid disk and volume configurations without crashing. "
17:49:12 <jreznik> just let's use one, we agreed it's blocker
17:50:34 <roshi> proposed #agreed 1027947 - AcceptedBlocker - This clearly violates the Final release criteria: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
17:50:38 <kparal> ack
17:50:40 <adamw> ack
17:50:57 <jreznik> ack
17:51:21 <roshi> #agreed 1027947 - AcceptedBlocker - This clearly violates the Final release criteria: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
17:51:48 <roshi> #topic (1028110) LVMError: lvresize failed for root: running lvm lvresize --force -L 8712m fedora/root failed
17:51:48 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1028110
17:51:48 <roshi> #info Proposed Blocker, anaconda, NEW
17:52:58 <kparal> +1 blocker
17:53:08 <kparal> no rocket science here, just reuse and resize root partition
17:53:09 <adamw> now, THIS one is the resize criterion :P
17:53:10 <adamw> +1
17:53:53 <adamw> it tries to resize it to 8GB, per program.log
17:54:02 <kparal> adamw: actually I might argue that anaconda successfully attempted to resize and only the resize command failed. but I rather expect anaconda's fault here - invalid arguments or something
17:54:10 <roshi> +1
17:54:15 <adamw> kparal: it tries to resize to 8GB
17:54:20 <adamw> and fails because that's the same as the existing size
17:54:28 <kparal> maybe resize fails if you resize to the exactly same value?
17:54:36 <adamw> hence, it clearly isn't "correctly attempt[ing] the requested operation"
17:54:39 <kparal> that would be a bit weird though
17:54:47 <adamw> kparal: read program.log
17:55:01 <adamw> 12:59:04,123 INFO program: Running... lvm lvresize --force -L 8712m fedora/root
17:55:01 <adamw> 12:59:04,146 INFO program:   New size (2178 extents) matches existing size (2178 extents)
17:55:01 <adamw> 12:59:04,147 INFO program:   Run `lvresize --help' for more information.
17:55:01 <adamw> 12:59:04,147 DEBUG program: Return code: 3
17:55:05 <kparal> yeah, I'm just surprised that lvresize behaves like that
17:55:09 <adamw> why?
17:55:19 <adamw> would you expect it to actually do something and return a 'success' return code? i'd think that'd be odd
17:55:23 <kparal> it should end with exit 0
17:55:36 <adamw> i don't see why
17:55:41 <kparal> you want 8 GB, it's 8 GB, everything set
17:55:48 <kparal> nevermind, it's a bug anyway
17:55:52 <adamw> yeah
17:55:55 <roshi> proposed #agreed 1028110 - AcceptedBlocker - This bug clearly violates the Final Release Criterion: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
17:55:57 <kparal> let anaconda developers deal with that
17:56:02 <adamw> let's not get too far into the weeds
17:56:04 <adamw> but just to clarify
17:56:08 <adamw> you *really* asked for 6GB, right?
17:56:19 <kparal> adamw: yeah, so I assume it's caused by the bug linked
17:56:26 <adamw> ok, then ack.
17:56:28 <jreznik> ack
17:56:32 <kparal> ack
17:56:41 <roshi> #agreed 1028110 - AcceptedBlocker - This bug clearly violates the Final Release Criterion: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
17:57:00 <roshi> #topic (1027965) CreateException: Can't have a partition outside the disk!
17:57:00 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027965
17:57:00 <roshi> #info Proposed Blocker, anaconda, NEW
17:57:46 <kparal> +1 blocker
17:57:52 <kparal> same story again
17:57:59 <kparal> this time for standard partitions
17:58:10 <jreznik> +1 blocker
17:58:16 <roshi> +1
17:59:01 <adamw> yeah, correctly reject invalid operations
17:59:02 <adamw> +1
17:59:17 <roshi> proposed #agreed 1028110 - AcceptedBlocker - This bug violates the Beta release criteria: "Reject or disallow invalid disk and volume configurations without crashing."
17:59:25 <jreznik> ack
17:59:45 <kparal> ack
17:59:52 <adamw> ack
17:59:57 <roshi> #agreed 1028110 - AcceptedBlocker - This bug violates the Beta release criteria: "Reject or disallow invalid disk and volume configurations without crashing."
18:00:11 <roshi> #topic (1008732) LUKSError: luks device not configured
18:00:11 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008732
18:00:11 <roshi> #info Proposed Blocker, anaconda, NEW
18:01:21 <adamw> like dlehman i'm somewhat confused by this one
18:01:25 <adamw> not clear exactly what's going on
18:01:49 <kparal> it seems to happen when you reuse some previous encrypted installation, in some cases
18:01:59 <kparal> _encrypted_ is the key
18:03:17 <roshi> odd, comment 16 says this was already accepted for final
18:03:18 <kparal> I'll try to reproduce tomorrow. and flagellate Petr for not responding
18:03:38 <adamw> roshi: oh, maybe we missed tagging it
18:03:49 <adamw> but still, i'd actually like a bit more clarity on the reproducer before +1ing it...
18:03:58 <kparal> roshi: yeah it was, by looking into the meeting log
18:04:24 * roshi thought I set it as an AcceptedBlocker and just changed the tracking bug
18:04:25 <kparal> I'd like to try to reproduce with Final TC1. where is it?
18:04:37 <adamw> not built yet
18:04:43 <roshi> dgilmore said he would get to it today or tomorrow
18:04:53 <kparal> alright, I'll stick to Beta
18:05:29 <roshi> #info 1028110 was already discussed and voted as a final blocker.
18:05:33 <roshi> moving on
18:05:43 <kparal> so will we fix the tags?
18:06:10 <kparal> already enough people reproduced it to have it as Final I think
18:06:22 <kparal> if we are unable to reproduce, we just de-nominate it
18:06:22 <roshi> someone want to #action and fix the tags?
18:06:25 <adamw> i guess for now
18:06:27 <adamw> i'll do it
18:06:31 <roshi> (is this the right way to go about it?)
18:06:34 <adamw> oh
18:06:37 <adamw> the whiteboard is typo'ed
18:06:40 <adamw> AccptedBlocker
18:06:51 <roshi> .fire roshi
18:06:51 <zodbot> adamw fires roshi
18:07:12 <roshi> do I need to do an action item or just move on
18:07:22 <adamw> move on
18:07:33 <roshi> ok
18:07:37 <roshi> #topic (1016425) [abrt] colord-1.1.2-1.fc20: cd_icc_lcms2_error_cb: Process /usr/libexec/colord was killed by signal 11 (SIGSEGV)
18:07:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016425
18:07:37 <roshi> #info Proposed Blocker, colord, ASSIGNED
18:08:30 <kparal> I see this very often
18:08:46 <kparal> but I wonder whether I reported it from my work system or from Live
18:09:34 <adamw> don't think i've seen this one
18:09:42 <adamw> looks like it's trying to process a particular profile maybe?
18:09:59 <kparal> can we somehow discovered whether it has been reported from Live?
18:10:16 <kparal> otherwise it does not violate the criterion I guess
18:10:17 <roshi> I haven't seen this one either
18:11:41 <roshi> punt and verify?
18:12:16 <kparal> ok, it was my installed system
18:12:20 <kparal> I matched the journal
18:12:24 <adamw> the criterion covers running live, during install, and first boot post-intsall.
18:12:37 <kparal> so, this was not Live nor first boot -> not a blocker
18:12:50 <kparal> I guess
18:12:55 <adamw> unless someone can consistently report seeing it in one of those cases, yeah
18:13:32 <kparal> probably an error on my part
18:13:45 <roshi> -1
18:13:48 <kparal> -1
18:13:52 <adamw> -1
18:13:54 <roshi> with the caveat adamw had
18:14:05 <kparal> if I see it with Live, I'll raise it up again
18:14:21 <kparal> sorry for confusion
18:14:25 <jreznik> -1
18:15:06 <roshi> proposed #agreed 1016425 - RejectedBlocker - This bug does not violate the criterion because it doesn't happen on Live media or directly after first-boot. Please re-propose if this is seem on Live media.
18:15:50 <kparal> *seen
18:15:52 <kparal> ack
18:16:00 <roshi> proposed #agreed 1016425 - RejectedBlocker - This bug does not violate the criterion because it doesn't happen on Live media or directly after first-boot. Please re-propose if this is seen on Live media.
18:16:19 <roshi> spell check doesn't seem to check my intent or grammar
18:16:23 <roshi> :-/
18:16:38 <roshi> ack/nack/patch?
18:16:42 <adamw> ack
18:16:54 <kparal> ack
18:17:03 <jreznik> ack
18:17:10 <roshi> #agreed 1016425 - RejectedBlocker - This bug does not violate the criterion because it doesn't happen on Live media or directly after first-boot. Please re-propose if this is seen on Live media.
18:17:24 <roshi> #topic (1029790) dracut cannot handle encrypted partitions with a key file on the root file system
18:17:24 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1029790
18:17:24 <roshi> #info Proposed Blocker, dracut, NEW
18:19:46 <kparal> so, harald should add whether this is going to be fixed or working as intended
18:19:54 <roshi> how common is the setup used in that bug?
18:20:13 <kparal> not that common I think
18:21:42 <roshi> is someone asking harald?
18:21:43 <kparal> pinged harald
18:21:49 <roshi> ok :)
18:21:52 <kparal> on #fedora-devel
18:22:42 <roshi> thanks kparal
18:23:53 <roshi> then we've gotta keep moving
18:24:11 <jreznik> punt?
18:24:12 <roshi> 12 more proposed, by my count and we're through half our time
18:24:30 <adamw> punt for harald
18:24:53 <roshi> #info Need more information on this bug before we can vote
18:25:33 <roshi> proposed #agreed 1029790 - Punt - Need more information from Harald regarding the nature of this bug. Will discuss next meeting.
18:25:38 <kparal> ack
18:25:40 <roshi> or do we not need that?
18:25:41 <adamw> ack
18:25:54 <jreznik> ack
18:26:43 <roshi> #agreed 1029790 - Punt - Need more information from Harald regarding the nature of this bug. Will discuss next meeting 2013-11-20.
18:27:03 <roshi> sorry, I suppose it's bad form to alter text on the #agreed
18:27:11 <adamw> .fire roshi
18:27:12 <zodbot> adamw fires roshi
18:27:13 <roshi> just thought the date would be helpful in the minutes
18:27:28 <kparal> the next meeting might be on monday
18:27:38 <kparal> but I guess it's not that probable
18:27:43 <kparal> we're not in rush yet
18:27:55 <roshi> #topic (1025908) unable to unlock LUKS encrypted device from Live-Desktop
18:27:55 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1025908
18:27:55 <roshi> #info Proposed Blocker, gnome-disk-utility, NEW
18:28:19 <roshi> I can undo and take the date out
18:28:31 <roshi> man, I'm just causing all kinds of problems :p
18:28:38 <adamw> no it's fine
18:28:54 <adamw> seems like cmurf couldn't reproduce this 100%
18:29:16 <adamw> perhaps we need more people to try reproducing it
18:29:34 <kparal> he says 100%
18:29:42 <adamw> "Reboot, go straight to gnome-disk-utility, it works! It's a Heisenbug!"
18:29:43 <kparal> er, always
18:29:55 <kparal> ahh
18:30:10 <kparal> ok, need to re-test
18:30:16 <kparal> punt now
18:30:38 <adamw> yeah, ask cmurf to re-test and see if others can try it too
18:30:41 <roshi> +1 punt?
18:30:44 <adamw> anyone want to volunteer? :)
18:31:00 <kparal> I'll ask politely one of our interns tomorrow
18:31:12 <jreznik> :)
18:31:15 <roshi> I can take a crack at it as well
18:31:28 <roshi> votes?
18:32:01 <roshi> #info More people need to try to reproduce. Kparal to find volunteers
18:32:02 * adamw hands kparal the whip
18:32:04 <adamw> +1 punt
18:33:19 <roshi> proposed #agreed 1025908 - Punt - Need more information to vote. kparal to find volunteers to attempt to reproduce this bug - will re-visit next meeting.
18:33:29 <jreznik> ack
18:33:41 <adamw> ack
18:33:48 <kparal> ack
18:34:04 <roshi> #agreed 1025908 - Punt - Need more information to vote. kparal to find volunteers to attempt to reproduce this bug - will re-visit next meeting.
18:34:08 <roshi> #topic (1008965) mouse cursor sometimes disappears on login
18:34:08 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008965
18:34:08 <roshi> #info Proposed Blocker, gnome-settings-daemon, NEW
18:34:33 <kparal> the problem is that I no longer see it that often :/
18:34:40 <kparal> but I still see it sometimes
18:34:53 <adamw> yeah, i was still seeing it in beta testing
18:34:53 <kparal> very inconvenient
18:35:02 <roshi> I see it now and again
18:35:08 <adamw> it does seem kinda crappy to release with it
18:35:09 <roshi> after a locked screen
18:35:16 <roshi> in gnome and gdm
18:35:21 <kparal> I see it only after login
18:35:29 * jreznik is not gnome user, never seen this (even that mentioned kde issue)
18:35:31 <roshi> haven't seen it in any other wm though
18:35:41 * roshi uses i3
18:36:05 <roshi> but yeah, switching tty's fixes it
18:36:09 <kparal> this should be definitely +1 blocker. I'm just afraid if we're able to fix it
18:36:28 <kparal> it seems to be a hard nut to crack
18:36:39 * roshi looks for the relevant criteria
18:37:10 <jreznik> kparal: seems like there's an xorg build to try
18:37:17 <kparal> a new one?
18:37:20 <kparal> I tried all the old ones
18:37:21 <adamw> i'd say 'boot to a usable desktop', conditionally (alpha criterion)
18:37:21 <roshi> application or panel functionality?
18:37:31 <roshi> well, it's usable
18:37:38 <kparal> not for many people
18:37:41 <roshi> mouseover effects work and you can click on things
18:37:52 <kparal> happy web browsing :)
18:38:06 <roshi> it's just, your cursor gains the power of invisibility and doesn't know how to control it yet
18:38:59 <zbyszek> FWIW, I had this with 100% reproducibility in a VM until very recently, and updating to beta it's fixed.
18:39:03 <adamw> i'd say it's not really usable.
18:39:35 <kparal> if this happens very rarely by the release time, we can raise the blocker status
18:39:45 <kparal> but currently it's happening too much, I think
18:39:53 <roshi> well, not usable in the same sense that not using X/Wayland and just using the terminal isn't "usable"
18:40:26 <roshi> I'm only a +1 due to how visible this issue would be
18:40:34 <roshi> and because it's final
18:41:54 <roshi> kparal - I use pentadactyl, so no mouse doesn't really bother me while browsing :p
18:41:57 <roshi> any other votes?
18:41:58 <adamw> right, i'm +1 for now
18:42:09 <kparal> even Fedora has users who are not able to navigate without a mouse
18:42:12 <kparal> +1
18:42:40 <kparal> roshi: I know, I read your blog. I might try that once I have some free time
18:42:50 <roshi> wait, someone reads that?
18:43:32 <kparal> roshi: as long as someone reads your blog, we don't need to fire you ;)
18:43:33 <roshi> :p
18:43:47 <roshi> adamw where was that criterion?
18:43:54 <adamw> alpha
18:43:58 <roshi> my thanks to you kparal, then :)
18:44:06 <kparal> of course, provided that adamw hadn't fired all of us already
18:44:12 <kparal> which he did, many times over
18:44:18 <adamw> https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
18:44:23 <adamw> "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. "
18:44:39 <roshi> sheesh you're fast
18:44:47 <roshi> I'd just found it
18:44:57 <kparal> I would say "this conditionally breaks all required use cases for graphical desktop and its applications"
18:45:04 <adamw> well, it helps when you wrote it all :P
18:45:28 <roshi> proposed #agreed 1008965 - AcceptedBlocker - This bug violates the Alpha Release Criteria: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
18:45:37 <roshi> I suppose that would help
18:46:06 <kparal> I don't think that this one is violated, but I don't mind too much
18:46:08 <roshi> eh - the "possible" in there bugs me, but it's true to the spirit of the bug
18:46:20 <adamw> it's a conditional violation, worth noting
18:46:23 <adamw> or do it kparal's way
18:48:06 <roshi> proposed #agreed 1008965 - AcceptedBlocker - This bug conditionally violates all use cases for required graphical desktop and applications.
18:48:07 <adamw> don't waste too much time on it
18:48:10 <adamw> ack
18:48:15 <roshi> I think that's clean enough
18:48:25 <kparal> ack
18:48:43 <roshi> can I ack what I wrote?
18:48:47 <roshi> ack
18:48:49 <kparal> sure
18:48:54 <roshi> #agreed 1008965 - AcceptedBlocker - This bug conditionally violates all use cases for required graphical desktop and applications.
18:49:10 <roshi> #topic (1010704) Grub2 does not specify root for windows entries where uefi partition
18:49:10 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010704
18:49:10 <roshi> #info Proposed Blocker, grub2, NEW
18:49:38 <kparal> so, this is a dupe
18:49:40 * kparal looking
18:50:08 <kparal> of 873207
18:50:43 <kparal> we saved the day for F19, and it's broken again for F20
18:51:00 <kparal> because os-prober output is incompatible with grub
18:51:41 <kparal> the problem is that our grub maintainers are dead
18:51:48 <kparal> or something similar
18:51:59 <adamw> dead, pjones
18:52:01 <adamw> it's such a fine line
18:52:08 * roshi hopes they're not *dead*
18:52:35 <kparal> rejected blocker for F19
18:52:40 <kparal> you can still boot using UEFI
18:52:42 <roshi> so what do we do with this then? It looks like the bug it;s a dupe of was rejected
18:52:47 <kparal> however
18:53:06 <kparal> I encountered several user complaints on forum directly because of this
18:53:20 <kparal> the users are unable to boot windows, because they don't know uefi boot menu exists
18:53:32 <kparal> so they install fedora and windows is _gone_
18:53:53 <kparal> win8 preinstalled are becoming really common. therefore uefi
18:54:00 <roshi> CommonBugs?
18:54:12 <kparal> we can, but won't help them much
18:54:19 <kparal> we already did for F19
18:54:53 <kparal> I believe the fix in grub is not that difficult. at least with 873207 only a simple fix was required
18:54:57 <kparal> but was never done
18:55:07 <adamw> hi pjones
18:55:09 <pjones> I would say: uh, no?
18:55:10 <kparal> hello
18:55:39 <adamw> pjones: 'no' on the basis we're not actually trying to have entries for other OSes on the grub menu, or 'no' on the basis we want to but it's not a serious problem if it's broken?
18:55:51 * adamw still not sure what the status is there
18:55:57 <pjones> we've never made more than a 'best effort' promise on that sort of thing, I don't think
18:56:15 <kparal> it was almost working in F19. we just needed grub to understand new os-prober output
18:56:37 <pjones> and especially on UEFI, where you don't actually need grub to do dual booting, there's no strong need
18:56:47 <adamw> pjones: we have the specific criterion for dual boot with windows, but as noted in the bug it was written really only considering the BIOS case
18:57:07 <adamw> so i can propose an amendment to make it clear we only cover BIOS in that criterion and we can -1 on that basis?
18:57:09 <pjones> And also, you know, this is open source, and nobody has submitted a patch for it, and I'm not going to work on it between now and final.
18:57:15 <kparal> pjones: unfortunately many users don't know uefi boot menu, and therefore windows simply disappeared for them after they installed fedora
18:57:35 <pjones> kparal: I'm not going to be held hostage by what users do and don't know, to be perfectly frank.
18:58:34 <adamw> proposal: criterion "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." to be amended to read "The installer must be able to install into free space alongside an existing clean Windows installation and, when performing a BIOS (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora."
18:58:38 <roshi> I've never known a distro to attempt to support the windows dual boot thing - I've always got the impression that it was up to the user to figure out, though some distros make it easier (like ubuntu's wubi)
18:58:47 <adamw> roshi: on BIOS? we've all always done it
18:59:01 <pjones> not always successfully, but in general, yes ;)
18:59:04 <adamw> at least, any distro with leanings towards being a 'mainstream user distro' has
18:59:26 <adamw> but for UEFI, it's much less established
18:59:27 <kparal> if grub maintainers don't want to support it, it's meaningless to have it in criteria
18:59:39 <roshi> as an end user I just always got the impression that it *could* work, but your setup is yours to troubleshoot, etc
18:59:50 <kparal> but it's sad, because from what I see a lot of users really struggle with this
18:59:52 <roshi> not saying that's how it is or should be
19:00:08 <pjones> kparal: I'm okay with moving towards supporting it, but that means making it work and /then/ calling it supported, not the other way around.
19:00:24 <adamw> so, votes on the criterion amendment?
19:00:26 <kparal> I understand
19:00:30 <roshi> +1
19:00:38 <roshi> #chair adamw
19:00:38 <zodbot> Current chairs: adamw kparal roshi tflink
19:00:46 <pjones> right now we've got a whopping track record of 0 releases in a row where it works, so it's a bit too unstable to consider supporting it just yet
19:00:46 <kparal> +1 per pjones's comments
19:01:06 <pjones> adamw: I'm +1 fwiw.
19:01:28 <kparal> it actually worked for F19 (until the os-prober update arrived)
19:02:05 <kparal> IIRC the os-prober update added support for multiple ESPs and grub never learned the new syntax
19:02:14 <pjones> 1 in a row!
19:02:22 <pjones> o_O
19:02:23 <roshi> proposed #agreed Criteria - Amendment - "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." to be amended to read "The installer must be able to install into free space alongside an existing clean Windows installation and, when
19:02:23 <roshi> performing a BIOS (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora."
19:02:35 * pjones wonders how multiple ESPs is supposed to work, since that's not a thing the standard supports.
19:03:06 <roshi> or should that just be an #info adamw ?
19:03:09 <pjones> but anyway, I'm going to go back to my other meeting now.  thanks for the ping, adamw.
19:03:15 <roshi> thanks pjones
19:03:20 <kparal> pjones: I might have confused something, I don't understand this well. but the new output printed out the partition name (this information was not present before)
19:03:24 <adamw> we can make it an action
19:03:32 <roshi> #undo
19:03:32 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x153608d0>
19:03:39 <adamw> er
19:03:43 <roshi> whoops
19:03:47 <roshi> #redo
19:03:54 <adamw> .fire roshi
19:03:54 <zodbot> adamw fires roshi
19:03:57 <roshi> well, worth a try
19:03:58 <kparal> :)
19:04:15 <roshi> #info Proposed Blocker, grub2, NEW
19:04:23 <kparal> interesting, the latest action was #chair
19:04:24 <roshi> there, it's back in it's rightful place
19:04:36 <roshi> yeah, but it removed info
19:04:55 <kparal> so, should I say ack?
19:04:57 <kparal> or what?
19:05:08 <kparal> -1 blocker per new criteria
19:05:14 <roshi> writing it out as an #action
19:05:16 <kparal> if they are active already
19:05:29 <adamw> chairs aren't logged
19:05:40 <adamw> roshi: i actually meant it's fine as a #agreed
19:05:47 <adamw> then you can #action me to do it
19:05:53 <adamw> then we can #agreed reject the bug
19:06:14 <adamw> kparal: #chair actions aren't minuted so there's nothing to "#undo"
19:06:29 <roshi> #agreed Criteria - Amendment - "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." to be amended to read "The installer must be able to install into free space alongside an existing clean Windows installation and, when performing a BIOS
19:06:29 <roshi> (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora."
19:06:37 <roshi> dang it
19:06:39 <roshi> #undo
19:06:39 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x14634090>
19:06:55 <kparal> you won't fit that
19:06:58 <kparal> doesn't matter
19:07:04 <roshi> #agreed Criteria - Amendment - "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." to be amended to read "The installer must be able to install into free space alongside an existing clean Windows installation and, when performing a BIOS
19:07:04 <roshi> (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora."
19:07:16 <adamw> just say "#agreed Windows dual-boot criterion to be amended to read..."
19:07:22 * roshi didn't think he had a newline there
19:07:26 <roshi> #undo
19:07:26 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x12cf5bd0>
19:07:41 <kparal> the IRC line has max length
19:08:30 <roshi> proposed #agreed Criteria - Amendment - Windows dual-boot criterion to be amended to read: "The installer must be able to install into free space alongside an existing clean Windows installation and, when performing a BIOS (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora."
19:08:35 <kparal> ack
19:09:16 <roshi> ack
19:09:26 <roshi> adamw?
19:09:55 <adamw> ack
19:09:57 <roshi> #agreed Criteria - Amendment - Windows dual-boot criterion to be amended to read: "The installer must be able to install into free space alongside an existing clean Windows installation and, when performing a BIOS (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora."
19:10:13 <roshi> #action adamw to update criteria.
19:10:34 <roshi> votes on blockery-ness of 1010704?
19:10:39 <adamw> -1
19:10:41 <roshi> -1 with new criterion
19:11:21 <kparal> -1
19:12:06 <roshi> proposed #agreed 1010704 - RejectedBlocker - This bug does not violate dual boot criterion because this is a UEFI installation and not a BIOS installation.
19:12:22 <kparal> ack
19:13:04 <adamw> ack
19:13:16 <roshi> ack
19:13:22 <roshi> #agreed 1010704 - RejectedBlocker - This bug does not violate dual boot criterion because this is a UEFI installation and not a BIOS installation.
19:13:35 <roshi> #topic (864198) grubby fatal error updating grub.cfg when /boot is btrfs
19:13:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=864198
19:13:35 <roshi> #info Proposed Blocker, grubby, ASSIGNED
19:14:36 <kparal> tldr for me?
19:15:07 <roshi> grubby doesn't update initrd correctly after a kernel update
19:16:09 <adamw> seems mike got a slightly different result
19:16:14 <adamw> er, roshi
19:16:23 <roshi> I answer to both - usually
19:16:50 <kparal> hum
19:17:10 <kparal> it's time to put btrfs where it belongs - to technical preview section
19:17:20 <kparal> but currently we seem to claim to support it, so...
19:17:45 <kparal> it could be fixed with an update, probably. but it might be a bit risky
19:17:46 <adamw> could be fixed post-release in theory, i suppose
19:17:49 <adamw> yteah
19:18:02 <kparal> also, you can claim it's a security bug
19:18:17 <roshi> yeah - since it makes you think you have a new kernel
19:18:17 <kparal> no new kernels will be booted
19:18:29 <roshi> I doubt all users check the see which version of the kernel they load
19:18:39 * roshi didn't for a long time
19:18:45 <kparal> roshi: those with btrfs might do :)
19:18:53 <roshi> true kparal
19:18:56 <roshi> lol
19:19:09 <kparal> so yeah, probably +1 here
19:19:27 <kparal> I'd really love to move btrfs and thinp to less-supported state, but I guess it's too late for that now
19:19:28 <adamw> criterion?
19:19:40 <jreznik> kparal: is it too late?
19:19:50 <kparal> adamw: maybe the security one?
19:19:51 <roshi> The installed system must be able to download and install updates with the default console package manager.
19:20:07 <adamw> that seems reasonable
19:20:15 <kparal> jreznik: well, we already support it for several releases. it might be weird to downgrade the support level?
19:20:19 <adamw> the update isn't really properly installe
19:20:20 <adamw> d
19:20:43 <roshi> and it doesn't *tell* you (at least for my run) it didn't finish
19:20:47 <roshi> +1
19:20:53 <jreznik> kparal: we "supported" it... best effort
19:21:11 <adamw> +1 on that criterionb
19:21:19 <kparal> jreznik: well, our QA criteria don't say anything like that ;)
19:22:06 <roshi> proposed #agreed 864198 - AcceptedBlocker - This bug violates the Alpha updates criterion: "The installed system must be able to download and install updates with the default console package manager."
19:22:15 <roshi> should I make a note about the potential security issue?
19:22:40 <adamw> i can do it in secretary
19:22:43 <kparal> ack
19:23:09 <roshi> ack
19:24:12 <adamw> ack
19:24:21 <roshi> #agreed 864198 - AcceptedBlocker - This bug violates the Alpha updates criterion: "The installed system must be able to download and install updates with the default console package manager."
19:24:33 <roshi> #topic (1009828) UEFI boot menu doesn't contain safe graphics mode
19:24:34 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009828
19:24:34 <roshi> #info Proposed Blocker, LiveCD, NEW
19:25:19 <kparal> do we have ajax around
19:25:19 <kparal> ?
19:25:54 * adamw pings ajax and airlied
19:26:11 <kparal> I have to warn you, if we are serious about UEFI fallback driver, there are several more bugs to be proposed
19:26:22 <kparal> currently it's a mess
19:26:52 <ajax> what's to discuss?
19:26:53 * adamw is probably -1, but good to have input from ajax
19:27:09 <roshi> .bug 1009828
19:27:13 <zodbot> roshi: Bug 1009828 UEFI boot menu doesn't contain safe graphics mode - https://bugzilla.redhat.com/show_bug.cgi?id=1009828
19:27:20 <kparal> ajax: how confident are we that we can provide working fallback graphics mode on UEFI?
19:27:21 <roshi> ^^ there ajax
19:27:28 <ajax> kparal: it's trivial.  it already works.
19:27:44 <kparal> ajax: are there frequent problems with certain hardware?
19:27:46 <adamw> whether we ought to be fixing up the bootloader menus to offer fallback graphics for UEFI, or modifying the criterion
19:27:49 <ajax> no.
19:27:54 <ajax> here's the thing
19:27:58 <adamw> kparal: what are the problems you mentioned?
19:28:03 * kparal searching
19:28:14 <ajax> if you're using uefi, the "fallback" is actually something you _always hit_
19:28:28 <ajax> the kernel initially drives the console with efifb
19:28:32 <adamw> kparal: and does the 'safe graphics mode' for the dvd/netinst in UEFI mode actually give you something sane?
19:28:35 <ajax> and you hand off from that to an accelerated driver
19:28:36 * adamw would guess 'no'
19:28:48 <ajax> so 'nomodeset' will just leave you on efifb instead
19:28:53 <adamw> hrm
19:28:57 <ajax> and efifb does _less work_ than vesa does
19:29:02 <adamw> so actually the dvd/netinst one might be working already
19:29:06 <kparal> I can't find the bug reports, but from what I remember, some of our UEFI machines couldn't boot with xdriver=vesa, some of them could
19:29:08 <ajax> because it's literally just reusing the graphics mode it was handed from grub
19:29:19 <ajax> xdriver=vesa is wrong
19:29:30 <adamw> is anything actually honoring xdriver= any more?
19:29:31 <ajax> it was only ever a hint to anaconda anyway
19:29:35 <adamw> i thought we determined it wasn't.
19:29:49 <ajax> neither the kernel nor the X server cares what xdriver= is set to
19:29:52 <adamw> ajax: so bottom line, 'fallback' mode for UEFI would simply be 'nomodeset' ?
19:29:55 <kparal> ajax: so the fallback line for UEFI only adds nomodeset, no other change is needed?
19:30:05 <ajax> adamw: fallback mode for _everything_ should simply be nomodeset
19:30:18 <ajax> uefi or otherwise
19:30:37 <kparal> time to adjust our test cases
19:30:47 <adamw> ajax: is qxl KMS yet?
19:30:48 <kparal> and syslinux boot menus on all media :)
19:31:05 <adamw> though i suppose fallback mode in VMs has never made a lot of sense
19:31:38 <ajax> appears to be
19:31:39 <ajax> dmt:~% modinfo qxl | grep mode
19:31:39 <ajax> parm:           modeset:Disable/Enable modesetting (int)
19:31:39 <ajax> dmt:~% uname -a
19:31:40 <ajax> Linux dmt 3.11.7-300.fc20.x86_64 #1 SMP Mon Nov 4 15:07:39 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
19:31:47 <adamw> so the 'todo' here would be to drop the use of xdriver= , drop any code for it that's left in anaconda, and add a 'fallback graphics' entry to the UEFI live boot menu
19:31:57 <roshi> votes?
19:32:08 <kparal> uefi is getting more and more common
19:32:11 <roshi> that doesn't seem to invasive
19:32:14 <kparal> I think we should fix this
19:32:30 <roshi> what criteria?
19:32:37 <adamw> it seems reasonable to require fallback capability, but then there's an  'easy' workaround of editing in 'nomodeset' yourself and we've never done it yet (pjones' "0 releases where it  works" objection)
19:32:49 <ajax> i still wish "fallback graphics" was a check box at boot time instead of a whole other boot option
19:32:51 <adamw> roshi: the criterion is obvious, cited in bug description
19:32:55 <kparal> roshi: https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_image_boot_behavior
19:32:58 <jreznik> kparal: does it have to be fixed for F20 so late or coordinate the change for the next Fedora?
19:32:59 <ajax> but i'm not about to hack on grub's ui
19:33:08 <adamw> ajax: yeah, i don't think grub has that capability.
19:33:30 <adamw> yeah, i might still be -1 blocker on this, though if we can organize things fast enough to get it fixed that'd be great
19:33:33 <kparal> I know that ubuntu had checkboxes like that. don't know what they used
19:33:42 <adamw> i could actually probably fix this myself
19:33:56 <adamw> though the live image bootloader is kinda painful to fiddle with
19:34:24 <kparal> adamw: if you're -1, we should exclude UEFI with the criteria
19:34:28 <kparal> *from
19:34:37 <roshi> yeah
19:34:43 <adamw> for f19 i think we just waived the bug somehow
19:35:01 <kparal> but I think we should leave it in and enforce it
19:35:10 <adamw> eh, i can go with that
19:35:15 <kparal> if that doesn't work for certain configuration, we can waive that as hardware specific
19:35:20 <kparal> similar to all other hw bugs
19:35:51 <kparal> at least having the option is better than having none
19:36:13 <roshi> -1 blocker
19:36:26 <kparal> I was actually arguing for +1 blocker :)
19:36:52 <adamw> yeah, i can go with kparal's +1
19:37:14 <jreznik> for me it's too late, if we wanted this, we should start a bit earlier
19:37:35 <kparal> not that I reported it yesterday
19:37:43 <jreznik> especially bug bouncing every single milestone
19:37:55 <roshi> I can see either way
19:38:05 <roshi> my vote was a -.5
19:38:07 <roshi> lol
19:38:23 <jreznik> kparal: that's something we should improve - put these edge bugs on some sort of list and follow them even after rejected as blocker/try to solve them
19:38:25 <adamw> jreznik: it's actually a pretty trivial change
19:38:27 <roshi> I'm fine with a +1 it seems easy enough
19:38:44 * adamw just has to figure out how the hell the UEFI menu is defined
19:38:55 <kparal> adamw: look at dvd
19:39:05 <adamw> kparal: it's done completely differnetly in live images
19:39:10 <adamw> there's just no comparison
19:39:22 <roshi> proposed #agreed 1009828 - AcceptedBlocker - This bug violates the Alpha Release Criterion: "The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer
19:39:22 <roshi> or desktop and attempting to use the generic driver."
19:39:29 <adamw> ack
19:39:32 <kparal> ack
19:39:38 <roshi> ack
19:39:51 <roshi> #agreed 1009828 - AcceptedBlocker - This bug violates the Alpha Release Criterion: "The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or
19:39:51 <roshi> desktop and attempting to use the generic driver."
19:40:17 <roshi> #topic (1027682) DeviceError: ('Cannot destroy non-leaf device', 'fedora_dhcp-29-193-root')
19:40:17 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027682
19:40:17 <roshi> #info Proposed Blocker, python-blivet, POST
19:40:38 <roshi> only 6 more after this :)
19:40:45 <adamw> 20 mintues left
19:40:56 <adamw> we don't have to get them all today, i guess
19:41:12 * jreznik should leave now...
19:42:02 <kparal> this is the same reproducer as for one of the previous bugs (8 GB -> 6 GB), just with Encrypted checkbox enabled
19:42:15 <kparal> comment 16
19:42:19 <roshi> yeah
19:42:27 <roshi> another resize issue
19:43:01 <kparal> already patched, so I'm not making it up just for the purposes of this meeting :-)
19:43:16 <roshi> +1
19:43:16 <roshi> ?
19:43:18 <kparal> +1
19:43:54 <adamw> +1
19:43:57 <jreznik> +1
19:44:07 <roshi> proposed #agreed 1027682 - AcceptedBlocker - This bug violates the Alpha Release Custom Partitioning Criterion: "Reject or disallow invalid disk and volume configurations without crashing."
19:44:35 <kparal> ack
19:44:37 <roshi> ack
19:44:41 <adamw> ack
19:44:47 <roshi> #agreed 1027682 - AcceptedBlocker - This bug violates the Alpha Release Custom Partitioning Criterion: "Reject or disallow invalid disk and volume configurations without crashing."
19:45:01 <kparal> the criterion maybe wasn't the best fit, but whatever
19:45:02 <roshi> #topic (1027714) Re-using LVM partitions makes them non-resizable in certain cases
19:45:02 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027714
19:45:02 <roshi> #info Proposed Blocker, python-blivet, POST
19:45:23 <kparal> see the video
19:46:41 <adamw> this doesn't seem to meet any criteria
19:46:54 <adamw> arguably the installer shouldn't be disallowing the operation, but there's no blocking issue here that I see
19:47:07 <kparal> The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration.  ?
19:47:27 <kparal> or Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.
19:47:37 <adamw> "offered in a default installer configuration"
19:47:39 <roshi> but it does create and install, from satellit_e's comment
19:47:41 <adamw> it's not offering it.
19:47:48 <roshi> point adamw
19:48:05 <adamw> and there's no resize operation attempted, because the resize mechanism isn't invoked.
19:48:11 <kparal> well, in certain situations you simply can't resize
19:48:28 <adamw> right. that's a limitation, but it doesn't violate any criteria, and i don't see a pressing reason to invent a new one really
19:48:28 <kparal> I think it's not quite OK
19:48:32 <kparal> I'm not sure about a blocker
19:48:45 <adamw> it seems like it's a bug, sure. but i don't see a need to block f20 release...
19:48:51 <kparal> alright
19:49:04 <roshi> -1 blocker
19:50:05 <adamw> -1
19:52:09 <roshi> kparal?
19:52:14 <roshi> votes?
19:52:23 <kparal> yeah, -1
19:52:29 <roshi> proposed #agreed 1027714 - RejectedBlocker - This bug doesn't directly violate any criterion.
19:53:33 <kparal> ack
19:53:38 <roshi> ack
19:53:45 <adamw> ack
19:53:49 <roshi> #agreed 1027714 - RejectedBlocker - This bug doesn't directly violate any criterion.
19:54:08 <roshi> #topic (1020393) Scrolling in firefox seems extremely slow in qemu when spice is used but it seems fast with vnc
19:54:08 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020393
19:54:08 <roshi> #info Proposed Blocker, spice, NEW
19:54:54 <adamw> can't say i've noticed this myself
19:55:12 <adamw> though i do have a bug where screen refreshes in GNOME are a bit slow in VMs sometimes - like half the screen seesm to 'slide in' from somewhere
19:55:17 <adamw> anyway, doesn't seem like a blocker isse
19:55:22 <roshi> I haven't seen this either
19:55:52 <kparal> spice is really slow for me. but not a blocker
19:56:03 <roshi> -1 blocker
19:56:07 <kparal> adamw: yes, I see that as well
19:56:17 <roshi> it seems kinda annoying, but that's about it
19:57:19 <roshi> votes?
19:57:52 <kparal> -1
19:58:22 <roshi> proposed #agreed 1020393 - RejectedBlocker - While annoying, slowness while viewing a VM via spice does not violate any criteria.
19:58:37 <roshi> assuming adamw's comment that it wasn't a blocker issue was a -1
19:58:59 <adamw> ack
19:59:04 <roshi> ack
19:59:31 <kparal> ack
19:59:35 <roshi> #agreed 1020393 - RejectedBlocker - While annoying, slowness while viewing a VM via spice does not violate any criteria.
19:59:58 <roshi> do we have time for more?
20:00:01 * roshi will be here
20:00:05 <roshi> or can, rather
20:00:13 * roshi is getting hungry
20:00:21 <roshi> 4 left
20:00:33 <kparal> let's end now
20:00:39 <adamw> stop now, do the rest later
20:00:43 <roshi> ok
20:00:59 <adamw> we can do another meeting tomorrow maybe, since we're kinda on a tight schedule for final we might not want to wait till next week
20:01:16 <roshi> ok, I can send out an email about it
20:01:23 <roshi> maybe get more people here
20:01:33 <kparal> roshi: please add it to fedocal as well
20:01:43 <roshi> ok, will do
20:02:03 <roshi> unless there's something else, I'm ending the meeting
20:02:27 <kparal> thanks for leading
20:02:46 <roshi> no problem - sorry for the rough patches :)
20:03:06 <roshi> I can lead the next one too unless someone wants it
20:03:26 <roshi> #action roshi to email about another meeting and add it to fedocal
20:03:50 <kparal> I might be able to take it
20:03:55 <roshi> #info meeting ended before all proposed blockers were discussed
20:03:55 <kparal> let's discuss tomorrow before the meeting
20:03:59 <roshi> sounds good
20:04:03 <roshi> #endmeeting