16:01:36 <adamw> #startmeeting f20beta-blocker-review-4.5
16:01:36 <zodbot> Meeting started Mon Oct 21 16:01:36 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:42 <adamw> #meetingname f20beta-blocker-review-4.5
16:01:42 <zodbot> The meeting name has been set to 'f20beta-blocker-review-4.5'
16:01:48 <adamw> #topic Roll call
16:01:55 * nirik is lurking
16:01:56 <adamw> who's around for this impromptu bit of blocker review?
16:01:59 * satellit listening
16:02:40 * tflink is around
16:02:40 * cmurf is around
16:02:47 * kparal here
16:02:51 * sgallagh waves
16:02:52 * masta waves
16:02:55 <masta> Howdy folks
16:03:00 * pwhalen is here
16:03:27 * roshi is here
16:03:34 <adamw> thanks for the good turnout, folks
16:03:36 <adamw> really helps
16:03:45 <cmurf> wow almost more than "official" blocker meetings
16:03:54 <cmurf> what a monday
16:03:59 <adamw> heh
16:06:03 <adamw> OK, boilerplate time!
16:06:14 <adamw> #topic Introduction
16:06:14 <adamw> Why are we here?
16:06:14 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:06:14 <adamw> #info We'll be following the process outlined at:
16:06:28 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:28 <adamw> #info The bugs up for review today are available at:
16:06:28 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:28 <adamw> #info The criteria for release blocking bugs can be found at:
16:06:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
16:06:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
16:06:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
16:07:50 <adamw> #info 4 Proposed Blockers
16:07:50 <adamw> #info 10 Accepted Blockers
16:07:50 <adamw> #info 6 Proposed Freeze Exceptions
16:07:50 <adamw> #info 11 Accepted Freeze Exceptions
16:08:09 <adamw> OK, starting in with the proposed blockers...
16:08:28 <adamw> we definitely need to do proposed blockers, we should cherry pick one or two proposed FEs, we probably don't need to do accepted blocker follow-up today
16:08:51 <adamw> #topic (1020974) incorrectly treats a disk with partially corrupt GPT as having no partition at all
16:08:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020974
16:08:51 <adamw> #info Proposed Blocker, anaconda, NEW
16:09:04 <tflink> this is a rehash of part of 1019541
16:09:11 <tflink> I think, anyways
16:09:12 <adamw> well, cmurf does not exactly agree
16:09:15 <kparal> invite dlehman?
16:09:16 <tflink> _part_
16:09:19 <tflink> not all
16:09:25 <adamw> kparal: yeah
16:10:10 * adamw invited anaconda folks
16:10:15 <cmurf> well the spec doesn't agree
16:10:20 <cmurf> a GPT disk has two partition tables
16:10:24 <cmurf> possibly three
16:10:31 <sgallagh> Do the release criteria specify that we have to be installable on damaged hardware/filesystems?
16:10:32 <cmurf> 2 out of three say it's valid GPT disk
16:10:51 <sgallagh> That seems to me like a valid FE, but if your disk is broken, you're already kind of up a creek
16:10:58 <tflink> cmurf: how does the spec not agree? it's the same issue
16:11:00 <cmurf> it isn't broken
16:11:08 <cmurf> not not the same  issue
16:11:15 <tflink> yes, it is
16:11:16 <adamw> sgallagh: yeah, that was sort of my initial take
16:11:39 <cmurf> tflink: what did parted say about your disks?
16:11:51 <cmurf> tflink: my recollection is that it wouldn't use them at all, showed no partitions
16:12:05 <adamw> sgallagh: but then, the system of having a master and backup GPT exists for a reason
16:12:10 <cmurf> tflink: in my case parted says the backup GPT is damaged, and that it was using the primary, and then shows me my data
16:12:10 <tflink> they aren't dupes, no.
16:12:15 <adamw> and is clearly part of the spec, as cmurf pasted
16:12:17 <tflink> 1019541 had 2 parts
16:12:24 <tflink> this is the first part
16:12:31 <adamw> bcl: we're on 1020974 currently
16:12:43 <masta> if the backup is damaged it should be restored to the end of the storage volume, and ignored.
16:13:07 <sgallagh> Even still, while I agree it's a serious issue, I'm not sure it's a *blocker* unless it's much more common to hit than I would expect.
16:13:31 <cmurf> it's actually common for backup GPTs to get damaged because there's still weird ancient junk in the world not aware of GPTs
16:13:42 <bcl> cmurf: have you tried it with commit 68350333
16:13:43 <masta> agree with cmurf
16:13:55 <cmurf> we can't have programs saying disks with valid primary GPTs are blank
16:13:58 <bcl> that's the fix for tflink's blank disk problem
16:14:23 <cmurf> bcl: i haven't, i've been waiting for 20.26.1-1 to appear to test
16:14:31 <adamw> TC5 had 20.25.1
16:15:18 <bcl> well, my opinion on it being a beta blocker is no.
16:15:44 <adamw> bcl: presumably the fixed-in should be 20.25.2 not 20.26.1, as a sidebar...
16:15:49 <cmurf> then we need to change beta criteria
16:15:50 <adamw> unless you're re-branching beta or something
16:16:07 <adamw> cmurf: or vote against bcl's opinion :P
16:16:20 <bcl> oh, did I flub the fixedin?
16:16:24 <cmurf> fair enough
16:16:32 <adamw> bcl: for 1019541 at least
16:16:35 <tflink> I'm still not convinced this is common enough to block beta over
16:16:48 <adamw> tflink: i'm not sure how common it needs to be honestly
16:16:55 <adamw> i have to say i'm inclining to cmurf's view
16:17:02 <cmurf> commonality has nothing to do with this
16:17:06 <cmurf> it's a violation of the uefi spec
16:17:15 <adamw> showing a disk containing data and with a valid partition table as completely empty is a pretty major thing
16:17:35 <cmurf> it's an invitation to major data loss
16:17:37 <tflink> and it's beta
16:17:59 <cmurf> i do a lot of commercial beta testing and i would flip my shit if a beta behaved this way
16:18:02 <bcl> how about someone test it with the patch and report back.
16:18:11 <bcl> I *think* it will fix this one too.
16:18:20 <adamw> bcl: an updates.img would help with that
16:18:21 * cmurf is happy to test
16:18:24 <bcl> instead of spending the rest of the morning arguing.
16:18:27 <adamw> bit hard to test a build that doesn't exist :P
16:18:30 <sgallagh> Between the spec cmurf posted and the strict reading of the criteria, I'm going to go with +1 blocker, myself
16:18:40 <bcl> adamw: yeah, I can make one against TC5.
16:19:31 <adamw> proposed #agreed this is a very tough call, and if it turns out that the 1019541 fix fixes it, we can happily dodge making that tough call. so for now the evaluation is postponed until we check whether that fix also fixes this bug
16:19:47 <tflink> ack
16:19:52 <masta> cool
16:20:20 * sgallagh abstains
16:20:37 <kparal> ack
16:20:37 <pwhalen> ack
16:21:48 <adamw> yay, fudge
16:21:50 <adamw> #agreed this is a very tough call, and if it turns out that the 1019541 fix fixes it, we can happily dodge making that tough call. so for now the evaluation is postponed until we check whether that fix also fixes this bug
16:22:42 <adamw> #topic (1005895) Upgrade to f20 fails because of deltarpms
16:22:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1005895
16:22:43 <adamw> #info Proposed Blocker, fedup, MODIFIED
16:22:54 <adamw> oh, does someone want to secretarialize?
16:23:16 * roshi will
16:23:23 <adamw> thanks roshi!
16:23:27 <adamw> #info roshi will secretarialize
16:23:33 <adamw> i'm gonna get that word in the OED.
16:24:10 <adamw> from a quick glance looks like this is an f19-side fix
16:24:21 <adamw> so it'd be a 'special blocker', i.e., doesn't block composes (which we really need to set a process for)
16:24:41 <adamw> does look like it ought to be one, though.
16:24:46 <cmurf> +1 blocker it needs to work
16:24:59 <tflink> +1
16:25:09 <adamw> for anyone not familiar with this precedent - we have hit this case several times, where a bug is clearly a blocker for an F(N) release but actually needs to get fixed in F(N-1)
16:25:41 <adamw> what we do in this case, usually, is accept the bug as a blocker but on the understanding that this means it needs to be fixed in F(N-1) by release date of the F(N) milestone in question, rather than blocking F(N) composes
16:26:00 <adamw> so, that's what we'd be doing here: asking wwoods to make sure an F19 update with this fix gets issued by the time F20 Beta goes out.
16:26:40 <kparal> I think I reported a duplicate some time ago: https://bugzilla.redhat.com/show_bug.cgi?id=1017205
16:27:22 <kparal> the workaround might be to not use --instrepo
16:27:39 <adamw> wwoods already posted a fix
16:27:45 <adamw> so that shouldn't really be a problem
16:27:51 <adamw> any more votes? /me is +1
16:27:56 <kparal> I was just referring to "workaround isn't obvious"
16:28:15 <kparal> actually the users won't use --instrepo
16:28:24 <cmurf> i count +3
16:28:24 <kparal> so if it doesn't crash without it, it's not a blocker
16:29:06 <cmurf> hmm interesting
16:29:55 <sgallagh> If it only happens on non-standard installs (instrepo), I'm inclined to say -1 blocker +1 FE
16:30:19 <sgallagh> (of course, FE is meaningless in this situation...)
16:30:42 <adamw> don't we have to use --instrepo at present?
16:30:48 <kparal> which means I'll have to finally re-test that bug tomorrow, it seems
16:31:04 <kparal> adamw: it redirects to Alpha repo at the moment, and will redirect to Beta repo after Beta release
16:31:08 <kparal> without --instrepo
16:31:17 <adamw> ok
16:31:19 <kparal> we use --instrepo to use a newer upgrade.img
16:31:32 <adamw> why would it not be a problem if we don't use --instrepo though?
16:31:47 <adamw> as i read the bug, the problem is just the thing with presto changing from a plugin to part of yum
16:31:51 <adamw> i'm not seeing the relevance of instrepo
16:32:16 <kparal> but the error looks the same as in my bug report. and in my case, when I avoided --instrepo, everything worked
16:32:23 <kparal> and crashed only with --instrepo
16:32:26 <adamw> odd
16:32:29 <kparal> no idea why
16:32:44 <adamw> well, it's not life-threateningly important either way, and we have the fix, so...let's not waste too much time
16:32:50 <kparal> it seems I'll have to retest it tomorrow
16:32:58 <kparal> so punt and discuss on wednesday
16:33:16 <kparal> I'll verify whether the bug reports are the same
16:33:40 <adamw> proposed #agreed this is accepted as a 'special blocker' (does not block F20 beta composes) due to violation of https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Upgrade_requirements : "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed."
16:33:52 <adamw> hum, punt might be better
16:33:55 <adamw> let's go with that
16:34:40 <adamw> proposed #agreed as it is not clear whether this is actually a dupe of kparal's https://bugzilla.redhat.com/show_bug.cgi?id=1017205 and only affects fedup runs with --instrepo, we will discuss this again at the next meeting after kparal has evaluated it
16:34:48 <kparal> ack
16:34:51 <tflink> ack
16:35:13 <roshi> ack
16:35:14 <sgallagh> ack
16:35:23 <adamw> #agreed as it is not clear whether this is actually a dupe of kparal's https://bugzilla.redhat.com/show_bug.cgi?id=1017205 and only affects fedup runs with --instrepo, we will discuss this again at the next meeting after kparal has evaluated it
16:35:41 <adamw> #topic (1021258) requires user manually create biosboot when using guided partitioning
16:35:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021258
16:35:42 <adamw> #info Proposed Blocker, python-blivet, NEW
16:36:28 <adamw> cmurf: presumably something you're missing here is *BIOS* install to a disk with existing GPT?
16:36:35 <adamw> (i.e. this does not affect UEFI installs)
16:36:55 <tflink> that's how I'm reading it, too
16:36:59 <cmurf> ?
16:37:13 <sgallagh> Seems like a pretty clear blocker to me.
16:37:23 <adamw> yeah, that's a sidebar, it does seem like a by-the-numbers blocker
16:37:24 <cmurf> it is a BIOS install to a disk with a valid GPT
16:37:26 <adamw> cmurf: sure
16:37:32 <cmurf> umm?
16:37:35 <adamw> cmurf: it's just that the report doesn't actually explicitly specify that anywhere
16:37:59 <cmurf> ok seems superflulous since biosboot only applies to BIOS not UEFI
16:38:03 <kparal> +1 blocker
16:38:10 <adamw> cmurf: sure, just for clarity
16:38:13 <adamw> i'm +1 per the criteria
16:38:15 <tflink> +1
16:38:18 <roshi> +1
16:38:44 <cmurf> i think it's a regression somewhere because i know this used to work, i just don't know when it last worked
16:39:20 <cmurf> i plan an RFE that anaconda just create that which is needed regardless of Guided or Manual partitioning rather than complaining that the user create it
16:39:32 <cmurf> sorta off topic
16:39:57 <adamw> yeah, a little
16:40:33 <adamw> proposed #agreed 1021258 is accepted as a blocker per Alpha criterion "When using the guided partitioning flow, the installer must be able to cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation."
16:40:47 <kparal> ack
16:40:49 <cmurf> ack
16:40:53 <roshi> ack
16:41:04 <adamw> #agreed 1021258 is accepted as a blocker per Alpha criterion "When using the guided partitioning flow, the installer must be able to cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation."
16:41:15 <sgallagh> ack (obviously)
16:41:23 <adamw> #topic (1021110) u-boot.imx does not start extlinux automatically
16:41:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021110
16:41:23 <adamw> #info Proposed Blocker, uboot-tools, MODIFIED
16:41:31 <adamw> so, this is a bit ARM-y
16:41:38 <adamw> not entirely sure of the significance
16:42:04 <masta> the boot bits was delayed a bit, we wanted this to go in before now...
16:42:14 <masta> (delayed upstream)
16:42:16 <adamw> it doesn't read like a screamingly obvious blocker to me, is there subtlety to this beyond what's in the description?
16:42:20 <pwhalen> right now the uboot used on the wandboard is delayed until user input
16:42:28 <masta> very nice to have, and we have tested it works
16:42:30 <adamw> does it affect quad as well as dual?
16:42:44 <pwhalen> this fixes it, I would say FE?
16:42:45 <adamw> yeah, it sounds more FE than blocker
16:42:49 <pwhalen> I have tested quad
16:43:09 <pwhalen> but, I am not sure if the other platforms have been tested, in the process of doing that
16:43:37 <adamw> so it sounds like this is more of an inconvenience than a showstopper
16:43:42 <pwhalen> yes
16:43:51 <adamw> how invasive is the fix for this? is there a possibility it could stuff other arm platforms?
16:44:09 <adamw> a/include/configs/wandboard.h
16:44:11 <adamw> i guess not.
16:44:19 <adamw> (looking at the patch - https://bugzilla.redhat.com/attachment.cgi?id=813990 )
16:44:20 <roshi> sorry, the previous vote for 1022158 violates beta criterion, not alpha
16:44:31 <adamw> roshi: really? thought that criterion was an alpha one.
16:44:37 * roshi didn't know if you wanted to change it for the minutes
16:44:42 <adamw> eh, probably not significant enough
16:45:06 <roshi> I can't find the adamw quote you used on the alpha page
16:45:08 <adamw> so anyway, since this change looks like it's tightly restricted to a wandboard-specific code path and has been tested, I'd be -1 blocker / +1 freeze exception
16:45:11 <masta> adamw: we have good confidence in the patch, not to invasive... more trivial
16:45:11 <adamw> roshi: fair enough
16:45:40 <tflink> -1/+1
16:45:45 <pwhalen> adamw, there was an update to final 2013.10 release as well, but I dont expect any regression
16:46:01 <adamw> that's...unfortunate
16:46:12 <adamw> pwhalen: we never *expect* regressions. :P
16:46:25 <adamw> still, if it explodes stuff we can back it out
16:46:29 <pwhalen> yea, was going to add a witty remark after i said that
16:46:41 <pwhalen> we were using the rc4 previous
16:46:52 <sgallagh> adamw: Speak for yourself. I expect them often and am rarely disappointed.
16:47:17 <pwhalen> i am -1/+1 myself , will also test the other platforms
16:48:14 <cmurf> -1block/+1FE
16:48:41 <roshi> -1/+1
16:49:28 <adamw> sgallagh: heh :P
16:49:51 * sgallagh has to depart in ten minutes for another meeting
16:50:34 <adamw> proposed #agreed 1021110 is rejected as a blocker issue as it does not appear to be serious enough to merit that status, but accepted as a freeze exception issue as it will improve the experience on wandboard systems and looks to be a safe fix
16:50:50 <adamw> sgallagh: understood, this is the last blocker, i'll try to pull out the most important proposed FEs first
16:51:10 <pwhalen> ack
16:51:17 <sgallagh> ack
16:51:53 <adamw> #agreed 1021110 is rejected as a blocker issue as it does not appear to be serious enough to merit that status, but accepted as a freeze exception issue as it will improve the experience on wandboard systems and looks to be a safe fix
16:52:05 <tflink> ack
16:52:09 <adamw> OK, moving onto proposed freeze exception bugs that it looks like we have a reason to discuss
16:52:14 <cmurf> before moving onto FE's, .bug 1020974 is not fixed by the attached updates.img
16:52:15 <adamw> #topic (1020973) upower statuses often incorrect
16:52:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020973
16:52:15 <adamw> #info Proposed Freeze Exceptions, upower, ON_QA
16:52:30 <adamw> so this can make the power management experience with f20 a bit...interesting...and the fix looks pretty solid
16:52:58 <adamw> if you've been noticing f20 doing odd things on laptops with lid closes, external monitor connections and stuff, this may well be part of the reason
16:53:05 * adamw is +1
16:53:17 <tflink> +1
16:53:21 <sgallagh> +1
16:53:37 <kparal> +1
16:53:45 * satellit I did this to my 3.10.1 f20 x86_64 and now power setting does not turn off screen....
16:53:57 <adamw> satellit: what do you mean by that?
16:54:38 <satellit> I used to set power to 1 minute and screen would turn off now it does not....have not tested further just commenting
16:55:14 <satellit> I have cinnamon and mate plus sugar here also
16:55:24 <kparal> adamw: I just proposed 1021511
16:55:41 <adamw> satellit: ok, we can check that
16:55:47 <satellit> : )
16:56:16 <adamw> proposed #agreed 1020973 is accepted as a freeze exception issue as it can cause confusing and potentially problematic behaviour with power management
16:56:28 <adamw> kparal: thanks for the note
16:57:39 <kparal> ack
16:58:09 <roshi> +1 and ack
16:58:27 <cmurf> ack
16:58:35 <adamw> #agreed 1020973 is accepted as a freeze exception issue as it can cause confusing and potentially problematic behaviour with power management
16:58:54 * satellit have to go afk....
16:58:55 * sgallagh departs
16:58:57 <adamw> let's take kamil's as it's significant
16:58:59 <adamw> thanks folks
16:59:18 <adamw> #topic (1021511) Lightbox implementation kills performance on LiveCDs (XFCE completely unusable in VM)
16:59:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021511
16:59:37 <adamw> #info Proposed Freeze Exception, anaconda, NEW
16:59:42 <kparal> in a nutshell, I can't install XFCE in a VM with a single CPU assigned. it's possible with 2 CPUs, if you don't try to reclaim space
16:59:50 <adamw> this is the bug a few people have mentioned where the installer performs abysmally/unusably on certain desktops
16:59:57 <nirik> yeah, it's really bad. ;(
17:00:22 <kparal> on a bare metal, it's possible to reclaim partitions, but you need to be really patient
17:00:23 <adamw> trying to recall who else has mentioned this, but anyway, it seems pretty established
17:00:38 <adamw> definitely +1 FE for me, effectively a showstopper for non-blocking desktops
17:00:48 <tflink> +1 FE
17:00:53 <kparal> +1 FE
17:00:54 <cmurf> +1FE
17:01:38 <mkolman> BTW, we know about it and are investigating the issue
17:01:39 <roshi> +1
17:01:51 <adamw> proposed #accepted 1021511 is accepted as a freeze exception issue, as it's effectively a showstopper for installation with non-blocker desktop live images
17:01:55 <adamw> er
17:01:59 <adamw> proposed #agreed 1021511 is accepted as a freeze exception issue, as it's effectively a showstopper for installation with non-blocker desktop live images
17:02:01 <kparal> mkolman: welcome and thanks :)
17:02:20 <mkolman> current theory is that it is related to using a compositor because it works fine if running without it
17:02:23 <kparal> ack
17:02:31 <mkolman> kparal: hi :)
17:02:40 <cmurf> ack
17:02:46 <roshi> ack
17:02:49 <tflink> ack
17:03:00 <adamw> #agreed 1021511 is accepted as a freeze exception issue, as it's effectively a showstopper for installation with non-blocker desktop live images
17:03:01 <adamw> #agreed 1021511 is accepted as a freeze exception issue, as it's effectively a showstopper for installation with non-blocker desktop live images
17:03:24 <adamw> #topic (1020867) kickstart --noformat swap not added to /etc/fstab
17:03:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020867
17:03:24 <adamw> #info Proposed Freeze Exceptions, anaconda, MODIFIED
17:04:00 <adamw> looks like anaconda team actually pushed this onto the stable branch already, bad bad!
17:04:13 <adamw> from the description, AIUI, i'm OK with this as an FE, +1...
17:04:41 <cmurf> yes
17:04:52 <tflink> yeah +1 retrospectively :)
17:05:36 * kparal shrugs... already pushed
17:05:49 <kparal> +1 FE
17:06:03 <roshi> +1
17:06:44 <adamw> proposed #agreed 1020867 is accepted as a freeze exception issue as it could cause unwanted behaviour for some configurations and previously used to behave correctly, anaconda team, please try to avoid pushing things to the frozen branch that aren't FE/blocker fixes
17:07:02 <roshi> ack
17:07:55 <cmurf> ack
17:08:48 <kparal> ack
17:09:06 <tflink> ack
17:09:19 <adamw> #agreed 1020867 is accepted as a freeze exception issue as it could cause unwanted behaviour for some configurations and previously used to behave correctly, anaconda team, please try to avoid pushing things to the frozen branch that aren't FE/blocker fixes
17:09:55 * adamw will keep running through fe's since we're all here, there's 4 more
17:10:02 <adamw> #topic (1014304) Online account selection dialog is empty and 'Cancel' button doesn't work
17:10:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1014304
17:10:03 <adamw> #info Proposed Freeze Exceptions, gnome-initial-setup, NEW
17:10:49 <kparal> +1
17:11:15 <tflink> +1 - it looks bad
17:11:16 <roshi> +1
17:11:20 <adamw> yeah, can be fixed with a post-release update for network installs but not live installs, is a pretty obvious lacking feature
17:11:26 <adamw> +1 with some testing
17:11:31 <adamw> maybe not TOO late though
17:12:09 <cmurf> +1 FE it seems like a fix is not that risky
17:12:51 <adamw> proposed #agreed 1014304 is accepted as a freeze exception issue as it's a clearly missing function in a commonly-encountered element that cannot be fully addressed with an updatre
17:12:56 <adamw> proposed #agreed 1014304 is accepted as a freeze exception issue as it's a clearly missing function in a commonly-encountered element that cannot be fully addressed with an update
17:13:02 <cmurf> ack
17:13:08 <roshi> ack
17:13:20 <kparal> ack
17:13:27 <tflink> ack
17:14:30 <adamw> #agreed 1014304 is accepted as a freeze exception issue as it's a clearly missing function in a commonly-encountered element that cannot be fully addressed with an update
17:14:35 <adamw> #topic (1019073) Focus is getting removed from the target window
17:14:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1019073
17:14:35 <adamw> #info Proposed Freeze Exceptions, mutter, NEW
17:15:47 <adamw> seems like a problem for OSK users and GNOME
17:15:53 <kparal> +1 fe
17:15:57 <roshi> +1 FE
17:16:01 <tflink> +1 FE
17:16:04 <adamw> hrm,
17:16:08 <adamw> the upstream change looks...complex
17:16:11 <adamw> https://git.gnome.org/browse/gnome-shell/commit/?id=93dc7a51c0e70a6ff5a03c3fd8ebba39d5a13978
17:16:24 <adamw> i am not hugely jazzed about poking shell that much, this late
17:16:46 <adamw> and the changes are clearly not particularly restricted, it's not like you'll only hit them if you use an OSKL
17:16:59 <adamw> otoh, a11y is important...hrm
17:17:03 <tflink> adamw: isn't that the change which _caused_ this bug?
17:17:04 <tflink> not the fix
17:17:09 <adamw> oh right
17:17:12 <adamw> well caught
17:17:35 <adamw> goddamnit, now i can't get to b.g.o
17:17:38 <cmurf> well the fix does point out that it's been a problem so they're reworking the logic
17:17:39 <adamw> anyone have a copy of the real fix?
17:17:53 <kparal> adamw: https://status.gnome.org/
17:17:54 <roshi> gnome bz has been funky all morning
17:17:55 <tflink> bugzilla.gnome.org seems to be down
17:17:57 <kparal> adamw: all day down
17:18:06 <adamw> right, but if anyone has the actual patch handy...
17:18:54 <tflink> not seeing it in upstream mutter git
17:19:17 <adamw> i guess i'm +1 on principle, but we should check the fix before going with it
17:20:03 <cmurf> i'm not finding it
17:20:13 <tflink> probably attached to the gnome bug
17:20:20 <cmurf> this is in gnome-shell proper? i don't see anything like this in git
17:20:28 <tflink> it would be in mutter
17:20:34 <adamw> downstream bug's assigned to mutter
17:20:42 <kparal> adamw: we reserve that right always, don't we?
17:20:58 <adamw> kparal: sure, but when it's particularly pertinent it's worth discussing it explicitly
17:21:40 <adamw> hum. do we actually ship an OSK out of the box in any way?
17:21:51 <adamw> if you have to install it from a repo, then there's limited point in making this FE
17:21:55 <tflink> yeah, on gnome we do
17:22:08 <tflink> not sure about other DEs
17:22:14 <adamw> the bug is GNOME-specific anyway
17:22:19 <tflink> you can enable it from gdm, IIRC
17:22:31 <tflink> or from shell
17:23:35 * adamw is not seeing it at all on a live image he just built
17:23:52 <adamw> oh, just found it
17:23:56 <tflink> under universal access?
17:23:58 <kparal> yep
17:24:13 <adamw> that one works without the ifx, though
17:24:18 <adamw> so this is just for using a non-standing OSK with gnome?
17:24:38 <tflink> sounds like
17:24:49 <tflink> if they're not installed by default, -1 FE
17:24:53 <adamw> i'm kinda -1 on that
17:25:01 <adamw> anyone else confirm GNOME's own OSK is working OK?
17:25:08 <tflink> yeah, works for me
17:25:15 <roshi> works for me
17:25:19 <tflink> installed and updated F20
17:25:21 <adamw> ok, i'm going -1
17:25:31 <adamw> anyone else want to change votes?
17:25:38 <tflink> -1
17:25:41 <kparal> works for me
17:25:43 <kparal> -1
17:25:50 <adamw> hum, juhp is somehow desktoip team affiliated
17:26:37 <kparal> what is the default keyboard name?
17:26:41 <adamw> sorry to keep bouncing around :)
17:26:45 <adamw> kparal: no idea, it may be baked into the shell
17:26:58 * adamw asking juhp why the bug was nominated, if he's around
17:28:23 <adamw> guess he isn't
17:28:29 <adamw> we can always re-discuss on wednesday  if they come back
17:29:01 <adamw> proposed #agreed 1019073 is rejected as a freeze exception bug, as it does not seem to affect GNOME's own OSK, and others would have to be installed from repositories anyway so this can be fixed with an update
17:29:10 <kparal> ack
17:29:25 <roshi> Ack
17:29:42 <cmurf> ack
17:29:44 <adamw> #agreed 1019073 is rejected as a freeze exception bug, as it does not seem to affect GNOME's own OSK, and others would have to be installed from repositories anyway so this can be fixed with an update
17:29:50 <adamw> #topic (1005482) qtbase FTBFS on ppc/ppc64
17:29:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1005482
17:29:51 <adamw> #info Proposed Freeze Exceptions, qt5-qtbase, ON_QA
17:30:23 <adamw> don't see why this needs a freeze exception
17:30:37 <tflink> qt on ppc?
17:30:45 * adamw pings rdieter
17:30:49 <tflink> wait, good point. there are no lives for ppc
17:30:49 <adamw> "unblocks builds for dependant packages (including poppler->libreoffice) for ppc"
17:31:02 <adamw> tflink: besides, it's qt *5*
17:31:09 <adamw> which afaik is the upcoming unstable branch that nothing really uses.
17:31:13 <tflink> well, poppler is used in lots of places
17:31:24 <adamw> oh, poppler uses it?
17:31:30 <adamw> oh right.
17:31:40 <tflink> i thought that poppler was gtk
17:31:45 <adamw> me too...seems odd
17:31:49 <tflink> or toolkit agnostic
17:31:53 <adamw> oh, maybe it has an optional subpackage or something
17:32:08 <adamw> poppler-qt5
17:32:09 <adamw> sigh
17:32:35 <tflink> this is sounding more -1 to me, unless we're missing something
17:32:44 <adamw> yeah, with the ppc angle
17:33:01 <adamw> i'm not sure if there's some reason they want it sorted for beta for PPC or if it's just inconveniencing them because of the freeze or something
17:33:15 * adamw siding with -1 without a more reasoned explanation
17:34:43 <cmurf> yeah if this is a way to move to rebase to 5.2 i'd say no it's after freeze
17:34:44 <adamw> doesn't look like rdieter is around
17:34:46 <cmurf> it's not just one bug fix
17:34:52 <adamw> we could reject or punt to wed, i guess
17:35:46 <tflink> either works for me
17:36:02 <tflink> I'd say reject with request to re-propose if we're misunderstanding
17:36:05 <adamw> proposed #agreed it is not clear why we would want to take 1005482 through the freeze; we will request a clearer explanation and discuss this again at the next meeting
17:36:10 <adamw> heh, went the other way :P
17:36:11 <cmurf> that's what i was going to say
17:36:16 <adamw> i can switch it if you like
17:36:22 <adamw> just seems less bureaucracy this way
17:36:29 <cmurf> reject, re-propose if there's a more compelling explanation
17:36:33 * tflink doesn't care all that much
17:36:38 <tflink> ack
17:36:45 <tflink> same end effect
17:36:46 <cmurf> i will ack this in any case
17:36:50 <roshi> ack
17:36:59 <adamw> #agreed it is not clear why we would want to take 1005482 through the freeze; we will request a clearer explanation and discuss this again at the next meeting
17:37:01 <adamw> OK, last one
17:37:04 <tflink> was just thinking it could be less review if we rejectedc
17:37:05 <adamw> #topic (1020545) Some Activities fail to run correctly in F-20 beta
17:37:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020545
17:37:05 <adamw> #info Proposed Freeze Exceptions, sugar, NEW
17:37:17 <tflink> +1
17:37:27 <adamw> oh, roshi - when the agreed status is like that, you know it's the secretary's job to request the necessary clarification?
17:37:38 <adamw> +1
17:37:42 <tflink> would be a blocker for sugar, fe
17:37:47 <roshi> nope - but I do now
17:37:54 <adamw> looks like the update should be edited to say it fixes this, too - i didn't realize there's actually a fix...
17:37:56 <adamw> roshi :)
17:38:55 <adamw> any more votes?
17:39:20 <cmurf> +1 FE seems low risk, best to have it in beta for more testing
17:40:10 <roshi> +1 FE, since there's a fix already
17:40:46 * cmurf is curious about this "fedora blocker bugs application"
17:41:10 <kparal> cmurf: https://qa.fedoraproject.org/blockerbugs/
17:41:15 <adamw> cmurf: https://qa.fedoraproject.org/blockerbugs/propose_bug
17:41:38 <adamw> proposed #agreed 1020545 is accepted as a freeze exception issue as a significant issue in a non-blocking desktop that can't be fixed with an update
17:41:55 <roshi> ack
17:42:24 <cmurf> ooh a lightbulb goes on
17:43:39 * cmurf doesn't see the propose bug link on the blockerbugs home page
17:44:06 <adamw> i do...
17:44:11 <adamw> any more acks?
17:44:26 <tflink> ack
17:44:34 <tflink> sorry, got distracted
17:44:41 <cmurf> ack
17:44:55 <tflink> cmurf: all the way to the right after fedora 20 final
17:44:58 <adamw> #agreed 1020545 is accepted as a freeze exception issue as a significant issue in a non-blocking desktop that can't be fixed with an update
17:45:08 <cmurf> i have nothing after fedora 20 final
17:45:17 <adamw> does anyone see any accepted blockers that could profit from discussion by those present right now?
17:45:24 <cmurf> yes i do
17:45:34 <cmurf> .bug 1020974
17:45:38 <zodbot> cmurf: Bug 1020974 incorrectly treats a disk with partially corrupt GPT as having no partition at all - https://bugzilla.redhat.com/show_bug.cgi?id=1020974
17:45:38 <cmurf> this is not fixed by updates.img
17:46:02 <cmurf> OH i'm skipping ahead
17:46:04 <cmurf> nevermind
17:46:18 <cmurf> this is not accepted (yet)
17:46:36 <adamw> oh, but we were waiting on your results of testing
17:46:45 <cmurf> comment 10
17:46:46 <tflink> he posted a comment
17:47:03 <adamw> so i guess we get to discuss the blocker status of it again :(
17:47:05 <tflink> cmurf: did you grab logs as well?
17:47:12 <cmurf> i did
17:47:29 <cmurf> i can post new ones references c10
17:47:33 <cmurf> referencing
17:47:41 <cmurf> yea/nea ?
17:47:42 <adamw> yes, please do
17:47:47 <cmurf> okeydokey
17:47:53 <adamw> #topic (1020974) incorrectly treats a disk with partially corrupt GPT as having no partition at all
17:47:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020974
17:47:53 <adamw> #info Proposed Blocker, anaconda, NEW
17:47:57 <adamw> so, let's go back to it...
17:48:09 <adamw> i gotta say, i still feel pretty +1. it's not a good thing to be doing.
17:48:24 <cmurf> +1 although i'm biased
17:48:25 <tflink> sure, but I'm not convinced this is common enough to be blocking beta over
17:48:41 <tflink> it's not that hard to fix the disks
17:48:54 <adamw> tflink: as i said earlier, i really don't think commonness is a strong factor when it comes to a bug which is this significant when experienced
17:49:03 <adamw> tflink: and how are you supposed to know what's causing the problem?
17:49:11 <tflink> commonbugs?
17:49:13 <adamw> there is very little connection between cause and symptom
17:49:27 <tflink> busted disks -> improper display
17:49:27 <adamw> y'know, i like writing that thing, but i'm not under many illusions as to how many people read it =)
17:49:38 <adamw> the disk is not 'busted' in any reasonably normal sense of the word
17:49:47 <adamw> its primary partition table is intact and correct
17:49:49 <cmurf> tflink: there is NO WARNING the disks need fixing
17:49:53 <tflink> not-100%-ok-disks -> improper display
17:49:54 <cmurf> the user has no idea
17:49:57 <adamw> the user experience in most context is likely to be 'everything works normally'
17:50:16 <adamw> then they run the fedora installer and suddenly their disk is considered to be entirely empty. that's not good.
17:50:35 <tflink> so we're planning for users who are installing beta on a system without 100%-working disks, data that they don't have backed up and no knowledge of their partition layout?
17:50:44 <cmurf> plus it busts the criteria that say i can keep existing, or choose to remove specfiic partitions
17:50:46 <cmurf> i can't do that
17:51:02 <adamw> tflink: well that's one way of looking at it :P
17:51:12 <cmurf> that is not one way of looking at it
17:51:15 <cmurf> it's hyperbole
17:51:31 <tflink> how so?
17:51:32 <cmurf> how many people know the exact state of both GPTs?
17:51:33 <adamw> how about this
17:51:34 <cmurf> rare
17:51:37 <adamw> we can't really decide this at the meeting
17:51:42 <cmurf> you assume it's fine unless something says otherwise
17:51:43 <adamw> given the people still remaining
17:51:52 <cmurf> it's a clear violation of the uefi spec and beta criteria as they're written
17:52:03 <tflink> we aren't violating the uefi spec
17:52:08 <tflink> er, implementing
17:52:09 <cmurf> yes we are
17:52:13 <cmurf> violation
17:52:14 <adamw> i think we can probably agree on +1 FE: shall we vote that, and push blocker to wednesday/thursday?
17:52:23 <cmurf> the disk is NOT blank
17:52:28 <cmurf> the installer says it's blank
17:52:31 <adamw> tflink: i'm fairly sure that as a partitioning tool which operates on GPT disks, we ought to be implementing the relevant specification.
17:52:36 <tflink> sure, I'm not arguing that this isn't a bug
17:53:00 <cmurf> and parted shows the partitions, recognizes and warns of the corrupt backup GPT
17:53:03 * kparal wouldn't block Beta on this
17:53:06 <tflink> I'm arguing that just because something isn't working, it isn't automatically a release blocking issue
17:53:06 <cmurf> so does fdisk
17:53:09 <cmurf> so does gdisk
17:53:20 <cmurf> well then change the criteria
17:53:21 <adamw> so with the people present at the meeting we're +2/-2. i think we could really do with perspective outside of QA
17:53:28 <adamw> how about the above proposal?
17:53:41 <cmurf> the present criteria are clearly not met
17:53:44 <tflink> cmurf: why? the criteria are worded such that corner cases aren't always blockers
17:54:04 <adamw> tflink: to be fair, i really need to find a better way of expressing that.
17:54:04 <kparal> adamw: ack
17:54:13 <cmurf> it's not a corner case unless you ignore the uefi spec saying the valid primary GPT is still to be treated as valid
17:54:13 <adamw> for the record, can people vote on FE?
17:54:20 <kparal> +1 FE
17:54:23 <adamw> +1 FE
17:54:26 <cmurf> +1 FE
17:54:27 <tflink> +0 FE
17:54:41 <tflink> eh, +1 as long as the fix is reviewed
17:54:53 <tflink> I dislike mucking with partitioning in late freeze without blocker
17:55:00 <pwhalen> +1 FE
17:55:43 <adamw> proposed #agreed 1020974 is accepted as a freeze exception issue as a severe and potentially dangerous misbehaviour of the installer in a fairly unusual condition. agreement cannot be reached on blocker status, will be discussed again at the next meeting.
17:55:51 <cmurf> yes well better freeze now than do nothing until we're in final
17:55:52 <kparal> ack
17:55:55 <cmurf> ack
17:56:04 <tflink> ack
17:56:08 <adamw> #agreed 1020974 is accepted as a freeze exception issue as a severe and potentially dangerous misbehaviour of the installer in a fairly unusual condition. agreement cannot be reached on blocker status, will be discussed again at the next meeting.
17:56:10 <adamw> OK
17:56:42 <adamw> anything else, folks?
17:57:15 <kparal> nothing from me
17:57:30 <roshi> nada
17:57:36 <cmurf> non
17:57:37 <tflink> nope
17:57:42 <roshi> secretarial stuff is done as well
17:58:24 <adamw> alrighty, thanks for coming folks
17:58:29 <adamw> see you wednesday for round #5
17:58:34 <adamw> #endmeeting