16:02:28 <kparal> #startmeeting f20beta-blocker-review-4
16:02:28 <zodbot> Meeting started Wed Oct 16 16:02:28 2013 UTC.  The chair is kparal. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:34 <kparal> #meetingname f20beta-blocker-review-4
16:02:34 <zodbot> The meeting name has been set to 'f20beta-blocker-review-4'
16:02:39 <kparal> #topic Roll Call
16:02:43 <kparal> who's there?
16:02:47 * pwhalen is here
16:02:48 * roshi is here
16:02:49 <kparal> (knock knock)
16:03:05 * mkrizek is here
16:03:12 <tflink> bananna!
16:03:48 <kparal> #chair tflink adamw
16:03:48 <zodbot> Current chairs: adamw kparal tflink
16:04:27 <adamw> kparal: i, er, already started the meeting and chaired you...
16:04:28 * jreznik is here
16:04:29 <jwb> i'm here for kernel stuffs
16:04:35 <adamw> oh no i didn;t
16:04:39 <adamw> i'm really an idiot
16:04:50 * jreznik is now a bit confused
16:05:00 <jreznik> maybe too many meetings in a row today...
16:05:08 <kparal> or too many beers, that happens :P
16:05:10 * satellit listening
16:05:25 * adamw started the meeting in the wrong channel
16:05:31 <adamw> no, can't blame any beers
16:05:32 <kparal> heheh
16:05:45 <roshi> lol
16:05:58 <kparal> ok, I count 8 people or so
16:06:02 <kparal> let's start
16:06:02 <adamw> kparal: you go ahead, i'll do secretarialization
16:06:03 <narekb> satellit, your other nick... is it online now?
16:06:12 <satellit> yes
16:06:19 <kparal> #topic Introduction
16:06:19 <kparal> Why are we here?
16:06:19 <kparal> #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:19 <kparal> #info We'll be following the process outlined at:
16:06:19 <kparal> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:21 <narekb> for someone who knows russian it's lol-worthy
16:06:22 <kparal> #info The bugs up for review today are available at:
16:06:23 <kparal> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:28 <kparal> hmm
16:06:34 <kparal> #topic Introduction
16:06:45 <kparal> Why are we here?
16:06:45 <kparal> #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:45 <kparal> #info We'll be following the process outlined at:
16:06:45 <kparal> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:45 <kparal> #info The bugs up for review today are available at:
16:06:46 <kparal> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:53 <kparal> #info The criteria for release blocking bugs can be found at:
16:07:03 <kparal> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
16:07:15 <kparal> #info Up for review today, we have:
16:07:22 <kparal> #info 4 Proposed Blockers
16:07:23 <kparal> #info 8 Accepted Blockers
16:07:23 <kparal> #info 5 Proposed Freeze Exceptions
16:07:23 <kparal> #info 3 Accepted Freeze Exceptions
16:07:45 <kparal> bear with me, I'm new to this, I'm gonna be a bit slower :)
16:07:51 <kparal> ok, let's go with the proposed blockers
16:08:09 <kparal> #topic (1017435) Anaconda uses LVM when Standard Partition is selected in text mode
16:08:10 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1017435
16:08:10 <kparal> #info Proposed Blocker, anaconda, MODIFIED
16:09:08 <pwhalen> I confirmed this on arm and x86, not sure if anyone else has run into it
16:09:15 <adamw> +1, seems fairly straightforward as described
16:09:18 * adamw has not verified though
16:09:29 <mkrizek> +1 blocker
16:09:30 <kparal> +1 by the description
16:09:31 <tflink> +1
16:09:32 <pwhalen> +1
16:10:19 <roshi> +1
16:10:43 <kparal> proposed #agreed 1013586 - AcceptedBlocker - Violates the following F20 beta release criterion for text mode and standard partitions: "When using the guided partitioning flow, the installer must be able to:  Complete an installation using any combination of disk configuration options it allows the user to select "
16:10:48 <adamw> ack
16:10:50 <pwhalen> ack
16:10:53 <tflink> ack
16:10:54 <mkrizek> ack
16:11:01 <kparal> how do I know if the text is cropped or not?
16:11:08 <kparal> ack
16:11:13 <kparal> #agreed 1013586 - AcceptedBlocker - Violates the following F20 beta release criterion for text mode and standard partitions: "When using the guided partitioning flow, the installer must be able to:  Complete an installation using any combination of disk configuration options it allows the user to select "
16:11:27 <tflink> kparal: i just started getting a feel for it and hoped that someone would tell me if it was too long
16:11:34 <kparal> #topic (1017977) FormatDestroyError: error wiping old signatures from /dev/vda2: 1
16:11:34 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1017977
16:11:34 <kparal> #info Proposed Blocker, anaconda, NEW
16:13:06 <tflink> the exact cause of this seems a bit unclear
16:13:13 <kparal> it's not really clear whether the reported adjusted the partitions while anaconda was running
16:13:19 <kparal> *reporter
16:13:26 <pwhalen> agreed, steps to reproduce would be better
16:13:27 <kparal> that would explain the error
16:13:53 <adamw> yeah, given the reporter's latest comments I'd at least want a clean reproducer of this
16:14:39 <kparal> so, we can wait or reject it
16:15:19 <adamw> they're kinda equivalent - either reject with 'but re-propose with a clean reproducer' or 'wait then reject next week'
16:15:22 <adamw> eh, either works for me
16:15:50 <pwhalen> -1 blocker until someone can reproduce, or clearer steps given.
16:15:51 <kparal> since no one else saw the same error (at least we have no indication) and the reporter hasn't provided clear steps (and might even not reproduce it again since he deleted the VM), I think rejection is better
16:16:02 <adamw> fair enough
16:16:05 <jreznik> yep, reject for now
16:16:21 <roshi> so, do we +1 for reject or -1 for reject?
16:16:52 <mkrizek> -1 blocker
16:16:53 <adamw> roshi: er, make it clear in your statement :)
16:16:59 <adamw> "-1 blocker" means reject
16:17:06 <roshi> adamw: ok. -1 blocker
16:17:16 * roshi was being slightly facetious
16:17:44 <kparal> proposed #agreed 1017977 - RejectedBlocker - This is rejected as a blocker until someone else can also reproduce the issue or the reporter can provide us with a clear steps that would help us reproduce the issue.
16:17:53 <tflink> -1 and ask for clear reproducer if re-proposed
16:17:55 <tflink> ack
16:18:01 <mkrizek> ack
16:18:12 <pwhalen> ack
16:18:15 <adamw> ack
16:18:24 <kparal> ack
16:18:30 <kparal> #agreed 1017977 - RejectedBlocker - This is rejected as a blocker until someone else can also reproduce the issue or the reporter can provide us with a clear steps that would help us reproduce the issue.
16:18:42 <kparal> #topic (1019541) unknown install shows up as entire disks instead of mount points of selected disks
16:18:42 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1019541
16:18:42 <kparal> #info Proposed Blocker, anaconda, NEW
16:19:19 <leigh123linux> kparal: is 1019405 going to be reviewed today?
16:19:32 <tflink> not sure if this is a blocker anymore
16:19:41 <kparal> leigh123linux: I don't see it on my list
16:19:44 <tflink> the main issue for me turned out to be corrupted backup gpt tables
16:19:52 <leigh123linux> kparal: Thank you
16:20:11 <kparal> leigh123linux: it's proposed as Final blocker, not Beta
16:20:34 <tflink> I just wasn't sure if the other things in c#8 were severe enough to warrent blocker status
16:20:59 <tflink> strange failure mode, though :)
16:21:11 <pwhalen> -1 blocker, issue seems resolved and hw specific
16:21:30 <pwhalen> tflink, have you tried a second time since?
16:22:08 <tflink> yes, the install I mentioned in c#9 finished
16:22:21 <pwhalen> right, but duplicate the success?
16:22:25 <kparal> so what's wrong on having corrupt _backup_ gpt tables?
16:22:41 <tflink> but I don't pretend to understand the stuff about bootloader selection and __init__
16:22:49 * adamw is not totally sure about 3), that _could_ be a problem
16:22:54 <tflink> kparal: I htink that blivet was choking on the corrupt backup table
16:23:15 * adamw trying to think how you could enter custom part without a valid bootloader target device but leave with one...it seems plausible, esp. in a UEFI config?
16:23:22 <Viking-Ice> wow I looked that blocker list yesterday and we only had one ;(
16:24:02 * adamw pinged dlehman
16:24:06 <kparal> what is the bootloader target device exactly?
16:24:25 <adamw> it's where the bootloader binary goes.
16:24:37 <kparal> so the area before first partition?
16:24:40 <adamw> thanks dlehman
16:24:44 <adamw> kparal: for a BIOS install, yeah.
16:24:46 <tflink> kparal: with bios, yes
16:24:52 <kparal> and uefi partition for uefi
16:24:52 <tflink> with uefi, it's the EFI system partition
16:24:54 <kparal> got it
16:24:55 <adamw> but it's rather different for a UEFI install. I think, for a UEFI install, that would be the ESP.
16:25:05 <adamw> dlehman: we're not sure how important issue 3) from your c#8 note is
16:25:16 <adamw> dlehman: I was thinking it could be a major problem for UEFI custom part installs? or am I wrong?
16:25:23 <dlehman> the most important, I'd say
16:25:25 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1019541#c8
16:25:37 <kparal> so if I don't have ESP and boot in UEFI mode, the custom part won't work for me?
16:25:45 <adamw> i was thinking that might be it, but IMBW
16:25:55 <dlehman> it means the disk selection is lost every time someone enters the custom spoke without a valid bootloader stage1 device already present
16:26:12 <adamw> so the scenario kparal mentions could be a problem, for instance?
16:26:44 <kparal> ok, so on UEFI machine with 3 clean disks, I select only one, then enter custom part and see all 3 of them, right? intentionally by anaconda design
16:26:47 <dlehman> yes. it won't generally be problematic on BIOS because a disk w/ disklabel is a suitable stage1 there
16:26:51 <adamw> right
16:26:55 <adamw> so it's rare that there won't be one
16:27:06 <adamw> kparal: i think 'disk selection getting lost' == 'installer blows up'
16:27:07 <tflink> brand new install on a uefi machine
16:27:08 <dlehman> kparal: no -- if you only select one that's all you should see in custom
16:27:22 <tflink> adamw: it wasn't crashing for me last night
16:27:28 <adamw> huh
16:27:32 <adamw> "treat the absence    of a suitable stage1 bootloader device as a fatal error"
16:27:38 <kparal> dlehman: what it exactly 'disk selection getting lost' means?
16:27:59 <dlehman> it means if you select a subset of your disks anaconda acts as though you selected them all
16:28:06 * jwb steps away for a sec
16:28:27 <adamw> okay
16:28:31 <adamw> so not fatal, but not behaving as intended
16:28:32 <kparal> dlehman: in my example I just mentioned with 3 clean disks, there's no ESP and you said I'd see just a single disk (that I selected)
16:28:44 <adamw> kparal: i think he means that is the *intended* behaviour
16:28:52 <adamw> but this bug means it would actually show *all* of them
16:28:55 <adamw> right?
16:29:04 <dlehman> kparal: are you asking about the consequences of this bug or when things are working correctly?
16:29:21 <kparal> I'm not clear what behavior is intended and what is current
16:29:31 <dlehman> by design you should only see the disks you selected, period. UEFI doesn't matter. disk contents don't matter.
16:29:36 <roshi> I'm pretty sure that's what the bug is adamw
16:29:41 <kparal> ok, I get it now
16:29:47 <dlehman> due to this bug disk selection does _nothing_
16:30:13 <dlehman> adamw: you have it right
16:30:16 <kparal> ok, now let's discuss whether it is a blocker
16:30:18 <tflink> why are the entire disks shown on the custom partitioning screen, though?
16:30:34 <tflink> shouldn't it show nothing if there were no valid devices detected?
16:30:35 <dlehman> because parted rejected their disklabels and therefore no partitions were seen on them
16:30:45 <adamw> OK
16:30:49 <dlehman> empty disk with no formatting is what they look like to us
16:30:55 <dlehman> so that's what you see
16:31:07 <adamw> so the worst possible consequence is that you see all your disks in custom part. for a beta, that doesn't seem critical to me, and doesn't infringe any criteria directly that i see
16:31:11 <tflink> sure, but shouldn't that show up as no existing volumes?
16:31:16 <adamw> probably FE-worthy
16:31:20 <tflink> instead of the various disks?
16:31:28 <adamw> tflink: it knows the *disks* exist
16:31:35 <adamw> tflink: but it thinks they have no valid *partition tables*
16:31:42 <adamw> it could quite easily create some for you, though. so it doesn't hide the disks.
16:31:45 <adamw> right, dlehman?
16:31:46 <tflink> I understand that
16:31:53 <tflink> that's not my question
16:31:54 <dlehman> right. unpartitioned disks can contain filesystem, lvm pv, &c
16:32:21 <adamw> tflink: it doesn't seem related to the blocker discussion anyhow....
16:32:22 <dlehman> normally we would create a new disklabel on them since they were selected, and _that_ would lead to an empty view in custom
16:32:32 <adamw> can we now focus on whether the issue is significant enough to block the beta release?
16:32:42 <adamw> ah, ic
16:32:45 <tflink> my question is that in the situation where no valid partition table exists, why is custom partitioning showing me the disks which are not relevant to custom partitioning
16:32:49 <tflink> ?
16:32:51 <dlehman> but the fallout from the bootloader error mishandling is that we throw out the scheduled actions to reinitialize the disks
16:32:52 <adamw> fair enough
16:33:06 <tflink> ok, I understand now
16:33:45 <dlehman> tflink: FWIW if you try to delete one of the disks it should disappear because we handle that by making a disklabel on it
16:33:47 <adamw> dlehman: any consequences of the bug that you're aware of severe enough that it might merit blocker status?
16:34:00 <dlehman> hmm
16:34:05 <adamw> (for beta)
16:34:21 <tflink> dlehman: does that change the disk content or just queue an action to create the label?
16:34:27 <dlehman> the latter
16:34:47 <tflink> ok, cool. good to know
16:34:49 <dlehman> adamw: it might be nice to see what it looks like with valid disklabels
16:35:05 <dlehman> peel away a few layers of doodoo
16:35:27 <adamw> so, same scenario, but correct disk labels? how did that look, tflink? did you try it?
16:35:58 <tflink> nope, I just fixed the disk labels and redid the install
16:36:07 <tflink> those disks did have efi system partitions on them
16:36:37 <dlehman> so then you didn't hit the error and also custom looked normal?
16:36:56 <tflink> yep
16:37:03 <adamw> ah, so we haven't tried the 'clean empty disk' scenario yet
16:37:11 <tflink> correct
16:37:15 <adamw> given current understanding i'd be -1/+1, but maybe we should test a bit more
16:37:25 <tflink> yeah, sounds like a plan to me
16:37:28 <dlehman> or, better yet, non-empty disks but without valid ESP
16:37:51 <adamw> OK, so say a valid BIOS install of Fedora or something humdrum like that, booted in EFI mode?
16:37:58 <tflink> like booting EFI with a disk that has a valid BIOS install?
16:38:03 <adamw> GREAT MINDS
16:38:04 <tflink> bah, too slow
16:38:20 <dlehman> I suspect you'll hit the error but will land in custom with things looking normal except that any uninitialized disks will appear as they did for you earlier and users will have to figure out that "delete" is how to initialize them
16:38:28 <adamw> OK
16:38:42 <adamw> do we want to do a conditional vote, or punt this?
16:39:03 <tflink> I'd say just -1/+1 for now and re-propose if it ends up being a bigger problem than we think
16:39:09 <adamw> go/no-go is 10-24 so ideally we'd want to be definitive asap
16:39:17 <adamw> definitely be nice to have this fixed soon
16:39:32 <tflink> as is, I can't see this blocking beta
16:39:35 <kparal> do I understand correctly that there's no data loss if I don't manually adjust anything on those disks?
16:39:44 <adamw> yeah, -1/+1 is still my instinct
16:39:50 <tflink> yeah, there's no data loss as long as you don't start the install
16:40:05 <tflink> the corruption on my disks was already there before I started the install
16:40:05 <kparal> and after that?
16:40:30 <tflink> it'll do what you tell it - if you start an install that deletes and re-creates partitions ... that would delete stuff
16:41:01 <kparal> but if I don't touch those disks that I haven't selected (but they have appeared), no harm is done to them
16:41:04 <tflink> so it is possible that a user could throw out their data because it appears that partitions have disappeared
16:41:45 <kparal> tflink: I thought that happened only with invalid part tables
16:42:27 <tflink> kparal: stuff not showing up correctly? I think that's the "no valid stage 1" symptom
16:42:46 <adamw> no
16:42:46 <kparal> right, that's what I though we were mostly voting on
16:43:23 <adamw> aiui, the 'no valid stage1' symptom is that disk selection becomes irrelevant - all disks would be visible even if you had not selected some
16:43:43 <tflink> but it also gets rid of some init, no?
16:43:43 <adamw> the 'not showing up correctly' symptom is associated with the invalid partition labels AND the 'no valid stage1' bug...
16:43:47 <tflink> oh
16:44:04 <kparal> aha
16:44:09 <adamw> so you'd only get that if you had invalid disk labels (partition tables). aiui, again. tricky issue to follow. :P
16:44:22 <adamw> but i think verifying that is why dlehman wanted us to test a 'valid disk contents but no ESP' case.
16:44:31 <kparal> should I recommend this to be proposed for Final?
16:44:44 <adamw> probably
16:45:27 <adamw> ok, how about this
16:45:56 <dlehman> tflink: you have the qa touch, clearly -- that was a real mess
16:46:08 <adamw> let's do a conditional vote on the assumption that you only see the 'incorrect' display of disk contents if you have invalid disk labels
16:46:10 <dlehman> remind me to never let you near any of my systems
16:46:18 <adamw> dlehman: the feared 'rust thumb' :P
16:46:24 <jreznik> :D
16:46:28 <roshi> haha
16:46:30 <adamw> on that conditional, i'd be -1/+1
16:46:53 <adamw> if that turns out not to be true, we can re-vote either next week or in-bug
16:46:53 <roshi> ^^ +1
16:47:22 <kparal> proposed #agreed 1017977 - RejectedBlocker - This is rejected as a blocker because there doesn't seem to be data loss risk involved, unless in a very specific circumstances where users can reformat their disks in error. Please re-propose for Final. If disks turn out to be displayed incorrectly even with valid partition labels, we will reconsider this for Beta.
16:47:23 * jreznik is not sure he can vote on this one, trusts adamw
16:47:24 <tflink> dlehman: that's what we're here for :-D I strive to have kparal's skills with getting stuff to break :)
16:47:41 <kparal> god, writing these statements is hard
16:47:49 <tflink> :-D
16:47:52 <adamw> kparal: ain't it? :) that looks good to me
16:47:58 <tflink> what about FE?
16:48:00 <adamw> ack
16:48:02 <adamw> oh yeah
16:48:08 <kparal> ok, FE vote?
16:48:13 <tflink> + FE
16:48:13 <adamw> add AcceptedFE if it fits
16:48:14 <adamw> +1 FE
16:48:20 <tflink> +1 FE, rather
16:48:22 <adamw> (that was the '+1' bit of my '-1/+1')
16:48:36 <roshi> +1 fe
16:48:47 <kparal> proposed #agreed 1017977 - RejectedBlocker AcceptedFreezeException - This is rejected as a blocker because there doesn't seem to be data loss risk involved, unless in a very specific circumstances where users can reformat their disks in error. Please re-propose for Final. If disks turn out to be displayed incorrectly even with valid partition labels, we will reconsider this for Beta. Accepted as a Beta FE.
16:48:59 <tflink> is someone doing the secretarialization?
16:49:13 <roshi> I think adamw said he was - if not I can
16:49:14 <jreznik> do we need that "Accepted as Beta FE" thing?
16:49:22 * adamw is already doing it
16:49:27 <kparal> I can remove it
16:49:32 <adamw> yeah, it's redundant
16:49:39 <kparal> proposed #agreed 1017977 - RejectedBlocker AcceptedFreezeException - This is rejected as a blocker because there doesn't seem to be data loss risk involved, unless in a very specific circumstances where users can reformat their disks in error. Please re-propose for Final. If disks turn out to be displayed incorrectly even with valid partition labels, we will reconsider this for Beta.
16:49:40 <adamw> ack with that change
16:49:58 <roshi> ack
16:50:03 <tflink> close enough. ack
16:50:03 <kparal> it can be tweaked during secretarialization anyway
16:50:06 <jreznik> ack
16:50:08 <kparal> ack
16:50:24 <Viking-Ice> -ack
16:50:25 <tflink> do we want to #action someone on the testing?
16:50:36 <kparal> tflink: do I hear a volunteer?
16:51:01 <tflink> I can do it, sure
16:51:01 <kparal> let's pick.... pschindl, he's not here! :)
16:51:19 <kparal> #action tflink to test 1019541 with valid partition tables
16:51:19 <tflink> but I was actually thinking of voluteering roshi or one of you folks
16:51:26 <tflink> since roshi has my efi test machine
16:51:38 <kparal> we can reproduce this on our UEFI machine
16:51:48 <kparal> ok, I'll ask our interns tomorrow
16:51:50 <kparal> #undo
16:51:50 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x12946ad0>
16:51:58 <roshi> this is true I suppose :)
16:52:08 <tflink> well, I've already tested with valid partition tables and it works
16:52:18 <kparal> #action kparal to test 1019541 with valid partition tables
16:52:50 <tflink> the test we want is a disk with a previoud BIOS install and no ESP booted with UEFI
16:52:55 <tflink> previous
16:53:10 <kparal> #undo
16:53:10 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x10d24890>
16:53:27 <kparal> #action kparal to test or delegate 1019541 with valid partition tables and previous BIOS install and no ESP booted with UEFI
16:53:41 <kparal> so much fun, this chairing
16:53:42 <tflink> the question being if the lack of ESP causes any unexpected issues
16:53:58 <kparal> what are we waiting for? ... oh, me!
16:54:08 <kparal> #topic (1019500) device factories need to set a default name if empty name given for defined device
16:54:08 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1019500
16:54:08 <kparal> #info Proposed Blocker, python-blivet, ASSIGNED
16:55:24 <tflink> seems pretty straight-forward to me
16:55:35 <kparal> if I don't name the array, installation crashes?
16:55:46 <tflink> the only question I have is how easy is this to hit?
16:56:06 <adamw> dlehman: i tried to provide an accurate summary in https://bugzilla.redhat.com/show_bug.cgi?id=1019541#c10 , please advise if it contains any factual errors so far as you know :) thanks for the help
16:56:20 <kparal> does somebody have a screenshot or something? I have no idea how you name an array
16:56:29 <kparal> do you need to delete some pre-generated name or something?
16:56:44 <Viking-Ice> yup this is a straight forward one
16:57:26 <dlehman> kparal: yeah, pretty much. there's a little "name" text entry that the user can clear out.
16:57:30 <tflink> is it only in certain cases where a pre-existing array isn't named or named properly?
16:57:36 <tflink> nvm
16:57:46 <kparal> dlehman: is it filled out by default?
16:58:10 <kparal> in that case I think I'd be fine with Final blocker
16:58:24 <kparal> not something that many people would do
16:58:35 <tflink> kparal: I can see this hitting the "rejecting invalid operation" criterion
16:58:55 <tflink> in that case
16:59:32 <kparal> oh, you're right
16:59:37 <adamw> this isn't really an invalid operation, though
16:59:50 <kparal> it's invalid to have no name, IIUIC
16:59:57 <adamw> yeah...kinda a fine distinction :)
17:00:03 <adamw> instead of 'rejecting' it the idea is to give it a default name
17:00:24 <kparal> "Reject or disallow"
17:00:39 <dlehman> kparal: I'm not totally sure if it got cleared by us, but I think the user did it.
17:01:54 <kparal> are we generally +1 blocker then?
17:02:12 <tflink> yeah, +1
17:02:29 <roshi> +1
17:02:52 <adamw> sure +1
17:02:54 <kparal> proposed #agreed 1019500 - AcceptedBlocker - Violates the following F20 beta release criterion for RAID installs with unnamed array: "When using the guided partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing."
17:03:07 <Viking-Ice> acl
17:03:09 <Viking-Ice> mean ack
17:03:27 <roshi> ack
17:03:37 <tflink> kparal: isn't that "when using the custom partitioning flow"?
17:03:57 <kparal> ah
17:04:03 <adamw> right, good catch
17:04:23 <kparal> different criterion then?
17:04:33 <kparal> I really dislike that we don't have anything similar for custom part
17:04:41 <tflink> just s/guided/custom/
17:05:03 <tflink> the same sub-criterion is there but this situation isn't guided
17:05:03 <kparal> but that's not how the criterion sounds :)
17:05:18 <kparal> proposed #agreed 1019500 - AcceptedBlocker - Violates the following F20 beta release criterion for RAID installs with unnamed array: "When using the custom partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing."
17:05:23 <tflink> ack
17:05:52 <adamw> ack
17:05:58 <jreznik> ack
17:06:00 <kparal> oh, it's actually there for custom part as well. kparal was blind
17:06:01 <roshi> ack
17:06:07 <kparal> ack
17:06:12 <kparal> #agreed 1019500 - AcceptedBlocker - Violates the following F20 beta release criterion for RAID installs with unnamed array: "When using the custom partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing."
17:06:27 <kparal> that's all of the proposed blockers!
17:06:44 <kparal> let's continue with proposed FE
17:06:57 <kparal> after a commercial break
17:07:02 <kparal> TEST FEDORA!
17:07:09 <kparal> break over
17:07:12 <kparal> #topic (1016801) "Don't install the latest software updates" box is unchecked by default, can't be checked permanently
17:07:13 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016801
17:07:13 <kparal> #info Proposed Freeze Exceptions, anaconda, ASSIGNED
17:07:23 * tflink is compelled by the not-so-subliminal messaging to test fedora
17:08:00 <kparal> tflink: the subliminal message was "buy hotdogs with mustard"
17:08:45 <roshi> can you buy hotdogs that already have the mustard?
17:08:57 <roshi> that would be awesome
17:08:59 <tflink> sure, from a hot dog stand :)
17:09:14 <roshi> where is a hotdog stand?
17:09:18 <roshi> :p
17:09:32 <tflink> in a larger city or at a sporting event
17:09:47 <adamw> mmmm mustard
17:09:59 <tflink> we digress, though
17:10:11 <kparal> +1 FE
17:10:38 <roshi> +1
17:10:45 <tflink> +1 FE
17:10:57 <Viking-Ice> regular bug
17:10:59 <adamw> +1
17:11:03 <Viking-Ice> -1/-1
17:11:20 <Viking-Ice> atleast I'm not going to risk slippage for that one
17:11:20 * satellit DVD in VirtualBox does not retain checkbox on re-entering spoke Beta TC4 just tested
17:12:20 * kparal tries to come up with a reasoning
17:12:50 <tflink> its an offered option during install that isn't working
17:12:52 * satellit_RPi but it may work if you do not re-enter spoke?
17:13:02 <tflink> while not a blocker, it can't be fixed with a post-release update
17:13:56 <Viking-Ice> adamw, seems you have fiddled with that code how risky is it to pull in a fix?
17:14:07 <kparal> proposed #agreed 1016801 - AcceptedFreezeException - Updates download checkbox might be an important feature for some people and doesn't present large risk. It can't be fixed post-release. A fix would be considered as a freeze exception.
17:14:25 <tflink> ack
17:15:11 <roshi> ack
17:15:14 <mkrizek> ack
17:16:20 <adamw> Viking-Ice: i didn't really fiddle with the code, just submitted a bug report, iirc
17:16:21 <adamw> ack
17:16:38 <kparal> #agreed 1016801 - AcceptedFreezeException - Updates download checkbox might be an important feature for some people and doesn't present large risk. It can't be fixed post-release. A fix would be considered as a freeze exception.
17:16:48 <kparal> #topic (1016566) Installing a package silently fails if the GPG key for the yum repo is not installed
17:16:48 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016566
17:16:48 <kparal> #info Proposed Freeze Exceptions, gnome-software, ASSIGNED
17:16:51 <tflink> adamw: I suspect he's accusing you of having a double standard for how risky a fix might be
17:17:34 <Viking-Ice> tflink, I see you are playing that game now
17:17:46 <tflink> Viking-Ice: ?
17:18:05 <tflink> if I read that wrong, I apologize
17:18:16 <kparal> so where is our criterion "package installation must work"?
17:18:28 <kparal> I don't see it in Final
17:18:42 <adamw> tflink: he asked me a question, so I don't think that was the right reaing
17:18:55 <adamw> kparal: it is not in there. and that's actually intentional.
17:19:02 <kparal> adamw: how so?
17:19:03 <adamw> though...it's kind of arguable.
17:19:10 <adamw> kparal: simple: we chose not to require it to work.
17:19:20 <adamw> we require *updates* to work. so theoretically, you update to the state where package installs work.\
17:19:33 <kparal> we're fine with release fedora _final_ with broken yum?
17:19:38 <kparal> *releasing
17:19:39 <adamw> in theory, yes.
17:19:49 <tflink> technically, you can fix this with an update
17:19:50 <kparal> I'm not fine with that. for Beta, ok, maybe
17:19:52 <adamw> well, where 'broken' is 'package install fails but doesn't damage any data'.
17:20:05 <adamw> this has not, to my knowledge, ever been 'tested in production', so to speak
17:20:20 <jwb> i don't want to speak out of place, but sometimes documenting common sense doesn't really help anything.
17:20:21 <tflink> not sure I like the idea of releasing without the ability to install software w/ default method, though
17:20:48 <kparal> ok, so my question is, can we _update_ using gnome-software without the gpg key installed?
17:21:09 <tflink> I suspect not if install doesn't work but we'd need to test that
17:21:28 <kparal> that would be a blocker
17:21:51 <adamw> jwb: trying to run a release process based on 'common sense' tends to work out remarkably badly, which is why we try to write it all down
17:22:02 <tflink> either way, +1 FE for beta
17:22:10 <adamw> there is a line somewhere, but it's rather more to the 'write it down' side than you might think
17:22:19 <tflink> but we're not mindless zombies that can't do anything if it's not codified, either :)
17:22:21 <adamw> yeah, anyway, it's a no-brainer +1 FE
17:22:22 <jwb> adamw, i will defer to your experience there
17:22:28 <kparal> is there some volunteer to test whether updating works?
17:22:48 <adamw> kparal: it's already been done, see the matrix
17:23:06 <adamw> well, i think i've tested update via the notification, which does an offline update currently
17:23:22 <adamw> i don't know if the logic in GNOME is hooked up to do an online update if an offline one isn't required is hooked up yet...
17:23:37 <kparal> so the update using gnome-software uses offline update?
17:23:47 <kparal> and that works even without a key?
17:24:33 <adamw> in my test it did
17:24:36 * satellit_RPi offline update of gnome3 f20 is very disruptive freezes laptop for 30 sec+ with no indication  then 30 min upgrade on reboot   did it last night
17:24:45 <adamw> satellit: irrelevant.
17:24:55 <satellit_RPi> ok  It did work
17:25:04 <adamw> kparal: the thing is, i think gnome's intended design is that it may do either online or offline, depending on the packages that need updating
17:25:08 <adamw> but i don't know if that is hooked up yet
17:25:24 <kparal> adamw: ok, I justed wanted to ask specifically about the missing gpg key
17:25:26 <adamw> if it's theoretically possible that gnome-software might do an online update, i don't know if we've tested that yet
17:25:31 <kparal> if you have tested that, that's great
17:26:06 <adamw> i'm fairly sure we've checked offline updates with gpg key missing, though probably worth doing again (OOTB DVD install would test that, IIRC)
17:26:59 <kparal> proposed #agreed 1016566 - AcceptedFreezeException - Installing software using gnome-software is an important feature and we will consider this fix even after freeze. If anyone finds out that update (not install) is not working with a missing gpg key, please re-propose for Beta.
17:27:01 <adamw> anyhow...for now we should probably just vote FE and move on...
17:27:01 <adamw> ack
17:27:09 <adamw> er
17:27:10 <adamw> patch
17:27:22 <adamw> proposed #agreed 1016566 - AcceptedFreezeException - Installing software using gnome-software is an important feature and we will consider this fix even after freeze. If anyone finds out that update (not install) is not working with a missing gpg key, please propose this as a blocker bug.
17:27:29 <adamw> (it's not a 're-proposal')
17:27:38 <kparal> right
17:27:47 <kparal> ack
17:27:48 <tflink> ack to adamw's proposal
17:27:55 <roshi> ack ^^
17:28:18 <kparal> #agreed 1016566 - AcceptedFreezeException - Installing software using gnome-software is an important feature and we will consider this fix even after freeze. If anyone finds out that update (not install) is not working with a missing gpg key, please propose this as a blocker bug.
17:28:27 <kparal> #topic (1011714) btrfs scrub finds csum corruption after btrfs balance
17:28:27 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1011714
17:28:27 <kparal> #info Proposed Freeze Exceptions, kernel, POST
17:29:22 <kparal> jwb: I think you were waiting for this one?
17:29:37 <kparal> (thanks by the way for coming)
17:29:40 <jwb> i was waiting to see if you guys had questions, yeah
17:29:58 <jwb> i'm happy to add the patch.  i updated the bug a bit ago based on the request from last week
17:30:30 <jwb> as far as i know, you're only going to hit this if you run btrfs balance
17:31:42 <kparal> this can get documented in Beta release notes and accepted as a FE
17:32:36 <jwb> that's fine.  i can get the patch added today
17:32:53 * adamw is +1 for taking this quite early, so we can do some further testing with btrfs installs and back it out if it turns out to be a bad idea
17:32:56 <adamw> wouldn't want to take it later
17:32:57 <kparal> jwb: do you think it's safe to include it without waiting until it's stable?
17:33:12 <jreznik> adamw: +1 to taking it early
17:33:16 <adamw> kparal: it's not *intrinsically* a problem to run ahead of upstream's processes
17:33:33 <jwb> yeah, it seems pretty safe
17:33:36 <kparal> ok, I was thinking about some other risks related to btrfs
17:33:42 <adamw> (i.e. it's not any *more* dangerous than doing this with any package which doesn't have strict upstream processes)
17:33:42 <kparal> alright
17:33:45 <jwb> josef is one of the main btrfs developers
17:34:02 <jwb> i kind of implicitly trust him to not screw things up horribly
17:34:11 <kparal> adamw: was that +1 to blocker or +1 FE?
17:34:23 <jwb> fwiw, i don't think it should be blocker
17:34:24 <adamw> it's proposed as an FE, right?
17:34:28 <adamw> i'm voting as it's proposed.
17:34:34 <kparal> ah, sorry
17:34:38 <kparal> right
17:34:55 <roshi> +1 FE
17:35:05 <tflink> +1 FE
17:35:22 <jwb> i think suse already added this as well
17:35:44 <kparal> proposed #agreed 1011714 - AcceptedFreezeException - We would like to avoid data corruption on btrfs. A patch is ready and seems to be safe. We will consider it past freeze.
17:36:28 <roshi> ack
17:36:29 <tflink> ack
17:36:30 <jreznik> ack
17:36:45 <adamw> ack
17:36:50 <kparal> #agreed 1011714 - AcceptedFreezeException - We would like to avoid data corruption on btrfs. A patch is ready and seems to be safe. We will consider it past freeze.
17:37:01 <kparal> btw are we past freeze already? /me doesn't know
17:37:08 <tflink> yes, started yesterday
17:37:10 <jwb> yeah, freeze was yesterday
17:37:14 <kparal> the announcements never hit test-announce it seems
17:37:15 <kparal> ok
17:37:19 <jreznik> kparal: yes, it was announced
17:37:36 <kparal> #topic (1017683) Invalid UID in persistent keyring name
17:37:36 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1017683
17:37:36 <kparal> #info Proposed Freeze Exceptions, kernel, MODIFIED
17:37:49 <adamw> i think the announce is sent to devel-announce
17:37:56 <jreznik> kparal: https://lists.fedoraproject.org/pipermail/devel-announce/2013-October/001253.html
17:37:59 <jreznik> adamw: yep, it is
17:38:14 <kparal> yeah, I don't read that every day, my fault
17:38:16 <adamw> cc to test-announce might be nice
17:38:28 * kparal suggested that a few times in the past
17:38:31 <jwb> this one is already built and filed.  simo and sgallagh were all happy with it.  it basically just builds something into the kernel that was a module before.
17:39:37 <adamw> "Without this kernel patch, users relying on Kerberos for authentication and SSO will intermittently receive failures and errors (notably with misleading error messages)" - that's fairly bad
17:39:41 <adamw> +1 for sure
17:39:54 <adamw> arguably even a blocker
17:40:10 <kparal> +1 FE
17:40:13 <jreznik> +1 FE
17:40:22 <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" for krb auth. but definitely FE.
17:40:29 <jwb> to be clear, there is no patch.
17:40:30 <tflink> +1 FE
17:40:51 <roshi> +1 FE
17:41:35 <adamw> it's a kernel config change, right?
17:41:36 <kparal> proposed #agreed 1017683 - AcceptedFreezeException - This is a serious issue for Kerberos and SSO users. A fix would be considered past freeze.
17:41:55 <adamw> patch
17:42:07 <adamw> proposed #agreed 1017683 - AcceptedFreezeException - This is a serious issue for Kerberos users. A fix would be considered past freeze.
17:42:16 <adamw> "Kerberos and SSO users" doesn't really...make sense.
17:42:21 <tflink> ack
17:42:22 <jwb> adamw, yes, a config change
17:42:26 <adamw> jwb: roger.
17:42:30 <roshi> ack
17:43:03 <kparal> ack
17:43:15 <kparal> most probably because I don't know what SSO means :)
17:43:17 <jwb> basically, dhowells wrote code to allow big keys to be stored in the kernel.  the module isn't loaded by default and isn't auto-loaded.  libkrb5 (or whatever) was modified to use this to solve some issue i don't remember
17:43:34 <jwb> and since the module doesn't auto-load, weird shit happens
17:43:41 <adamw> kparal: single sign-on. you use kerberos to *do* single sign-on, it's not like kerberos and SSO are alternate, parallel systems.
17:43:58 <jwb> making the module auto-load was the first approach, but that lead into requiring selinux-policy updates that weren't really viable
17:44:05 <kparal> #agreed 1017683 - AcceptedFreezeException - This is a serious issue for Kerberos users. A fix would be considered past freeze.
17:44:05 <jwb> so we just changed the config
17:44:11 <adamw> jwb: seems sane.
17:44:25 <jwb> and then i sent a patch later to make it impossible to build big_keys as a module, because it's useless in that form
17:44:30 <jwb> but the patch isn't required
17:45:05 <kparal> thanks for info
17:45:09 <kparal> can I change the topic?
17:45:17 <jwb> absolutely
17:45:23 <kparal> #topic (1012141) [abrt] pulseaudio-4.0-4.gita89ca.fc20: core_free: Process /usr/bin/pulseaudio was killed by signal 6 (SIGABRT)
17:45:23 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012141
17:45:23 <kparal> #info Proposed Freeze Exceptions, pulseaudio, NEW
17:45:45 <tflink> is this the one that abrt picks up all the time in vms?
17:46:17 <adamw> yup
17:46:30 <tflink> +1 FE
17:46:35 <adamw> i'd be +1 FE for a relatively early and safe fix
17:46:41 <adamw> might be a bit of a question if it was the final RC
17:46:42 <roshi> +1 FE
17:46:50 <tflink> adamw: agreed
17:47:02 <kparal> can it be worse? it crashes...
17:47:07 <kparal> +1 FE
17:47:12 <jreznik> yep, for soon and safe fix +1 FE
17:47:26 <tflink> it's annoying and rather visable but not a show-stopper
17:47:34 <tflink> not for beta, anways
17:48:23 <kparal> proposed #agreed 1012141 - AcceptedFreezeException - This is a visible and annoying crash. An early and safe fix would be considered past freeze.
17:48:27 <adamw> kparal: i think it reloads and works after crashing
17:48:34 <adamw> so if the fix made it stop working...:)
17:48:38 <adamw> (or eat babies, etc)
17:48:47 <adamw> ack
17:48:50 * kparal is against eating babies
17:48:55 <kparal> raw, at least
17:49:05 <kparal> ack
17:49:46 * tflink is now concerned on a number of levels
17:50:13 <kparal> tflink: what do you mean
17:50:28 <tflink> kparal: that you'd know the difference between raw and not-raw babies
17:50:31 <tflink> mostly
17:50:58 <kparal> the latter ones are crunchy
17:51:15 <kparal> ack?
17:51:18 <tflink> o_O
17:51:19 <tflink> ack
17:51:27 <kparal> #agreed 1012141 - AcceptedFreezeException - This is a visible and annoying crash. An early and safe fix would be considered past freeze.
17:51:58 <kparal> and that's all of Proposed Freeze Exceptions!
17:52:13 <kparal> do you want to discuss Accepted Blockers?
17:53:00 <jreznik> yep pls, at least quick overview
17:53:13 * kparal has to admin he usually sleeps through that part, so he doesn't really know what happens in this section
17:53:13 <tflink> yeah, we probably should
17:53:17 <kparal> *admit
17:53:38 <kparal> let's go then
17:53:39 <kparal> #topic (1016959) ValueError: Cannot remove non-leaf device 'btrfs.14'
17:53:39 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016959
17:53:39 <kparal> #info Accepted Blocker, anaconda, NEW
17:53:39 <tflink> mostly just reviewing the bugs, listing out #infos with status and #actions if needed
17:53:59 <adamw> kparal: we basically see if anything's needed to move forward on each bug, and if it's still actually correct for it to be open
17:54:40 <kparal> I think this is waiting for developers action
17:55:12 <kparal> #info this is waiting for developers action
17:55:15 <adamw> yeah, it seems to be
17:55:28 <adamw> dlehman: do you have any status update here?
17:57:16 <dlehman> adamw: not really. there are two fairly big btrfs bugs and that's one of them. the other is nested subvols, which we don't handle well at all.
17:57:53 <dlehman> but I am pretty covered up with other things that are more important than btrfs hand-holding.
17:58:23 <adamw> would you expect that you'll have time to deal with them before go/no-go? or are we looking at a slip if we keep these as blockers?
17:58:43 <dlehman> when's go/no-go?
17:58:50 <tflink> 24th, I think
17:59:17 <dlehman> there's a pretty good chance I can at least take a close look before then
17:59:33 <dlehman> I expect this one to be quite a bit simpler than the other
17:59:40 <tflink> yeah, the 24th
17:59:58 <adamw> OK.
17:59:59 <jreznik> or the question is how important are brtfs bugs are at all...
18:00:18 <adamw> well, we offer it fairly prominently and keep going on about how we want to make it default, so pretty important
18:00:29 <adamw> but i don't want to start a bikeshed here, just keep tabs on status
18:01:06 <kparal> moving on?
18:01:34 <tflink> unless you want to make a not about the possibility of a fix before go/no-go
18:02:20 <kparal> #info We don't know whether this is going to be fixed before go/no-go, dlehman is busy with other bugs
18:02:46 <kparal> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device
18:02:46 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495
18:02:46 <kparal> #info Accepted Blocker, anaconda, ASSIGNED
18:03:17 <adamw> i know bcl was wokring on this, last i heard was my most recent comment
18:04:20 <kparal> #info the current patch is incomplete and we're waiting for bcl to refine the patch and submit it
18:04:42 <kparal> anything to add?
18:05:11 * kparal takes that as a no
18:05:17 <kparal> #topic (986575) installer fails to apply lower bound to resize requests in custom spoke
18:05:17 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=986575
18:05:17 <kparal> #info Accepted Blocker, anaconda, ASSIGNED
18:05:46 * adamw will probably alert fesco that we're a bit worried about getting all blockers fixed on time in their meeting
18:06:14 <tflink> might be a good time shortly
18:06:14 <adamw> dlehman: i'm assuming this one's a fairly simple fix?
18:06:44 <kparal> comment 12 suggests that
18:06:53 <dlehman> yes. I just need to clear off my "desk" a bit.
18:07:14 <adamw> ok. so if you're going to 'miss' on anything it'll probably be one of the more complex ones.
18:07:42 <kparal> #info this is a fairly simple fix, but it hasn't be implemented yet. waiting on developers
18:08:22 * kparal moves on
18:08:42 <kparal> #topic (1013586) SizeNotPositiveError: spec= param must be >=0
18:08:42 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013586
18:08:42 <kparal> #info Accepted Blocker, anaconda, NEW
18:09:37 <kparal> dlehman: have you had time to look at the reproducer video and try that on your own?
18:10:11 <kparal> I can also supply a disk image if you want, but it seemed a bit unnecessary to me, given how easy is to create one
18:10:25 <dlehman> haven't had time to try it
18:10:44 <dlehman> I'm expecting this one to be a real pain in the ass, FWIW
18:10:47 <kparal> ok, feel free to ping me for more info if you need it
18:11:09 <dlehman> ie: the fix will touch lots of moving parts
18:11:11 <kparal> dlehman: do you think it's a bug in blivet or some of the tools you use for detection?
18:11:50 <dlehman> kparal: I think it's a bug in blivet and possibly also anaconda.
18:12:27 <kparal> #info this is still waiting for developer action. the fix is expected to be invasive and affect many parts of the installer
18:12:42 <adamw> this one seemed pretty borderline to me when i read it over after the last meeting
18:12:53 <adamw> unless there's something other than gnome-disks that creates partitions like this
18:12:59 <kparal> adamw: gdisk
18:13:17 <adamw> not by defualt though right?
18:13:20 <adamw> it uses some padding doesn't it?
18:13:41 <kparal> adamw: by default it creates the same layout as gnome-disks
18:13:47 <kparal> adamw: i.e. it adds no padding
18:13:55 <adamw> hm.
18:13:57 <kparal> opposite from what gparted does
18:15:03 <kparal> it starts to sound like we will be slipping
18:15:13 <dlehman> basically, we need to make sure minimum fs size and any resize target size is stored as an integer.
18:15:35 <adamw> dlehman: do you think this makes sense as a beta blocker? any sense we made the wrong call?
18:15:38 <dlehman> (this is my guess)
18:15:43 <dlehman> hmm
18:16:07 <dlehman> so you get this crash just visiting the resize dialog with this pre-existing layout?
18:16:27 <kparal> dlehman: by clicking on Shrink
18:17:20 <kparal> I don't know what happens if you e.g. have more partitions and one of them is "bad" (not padded well enough). and you try to resize a different one
18:17:46 <kparal> in this bug report it is the simplest case, a single partition covering the whole disk
18:18:42 <kparal> I can't even say whether I can delete that partition, instead of shrinking. I'd have to try that
18:18:54 <kparal> (if we're looking for weakening the blocker)
18:19:13 <dlehman> that's a good question. the bug is definitely occurring in the resize dialog
18:19:59 <dlehman> generally I think it's a blocker unless there's a way to say that shrink isn't in the criteria and it only happens when you try to shrink stuff.
18:20:55 <adamw> i know we're fairly light on shrink, but we're tough on crashes
18:20:57 * adamw reads through
18:21:06 <kparal> if we removed shrinking from the criteria, I think anaconda should be displaying big fat warning "This can eat your computer" during shrink operation
18:21:23 <adamw> beta says "Remove existing storage volumes to free up space, at the user's direction"
18:21:30 <adamw> that is explicitly worded *not* to include shrinking
18:21:43 <kparal> adamw: we used "Complete an installation using any combination of disk configuration options it allows the user to select" when accepting it
18:22:05 <adamw> that was intended to be about the stuff on the IO screen ,really, seems to be being interpreted more widely, though.
18:22:22 <adamw> what we have for shrinking is this, in final:
18:22:23 <adamw> " Storage volume resize
18:22:23 <adamw> Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. "
18:22:28 <kparal> shrinking is not explicitly included anywhere, even in Final
18:22:34 <adamw> yes it is ^^
18:22:40 <adamw> that was added quite recently
18:22:57 <adamw> prior to that, the intent was that shrinking was explicitly not release blocking at all
18:23:07 <adamw> the intent was to add it, in a limited way, for final
18:23:25 <adamw> so if we start interpreting the 'any combination of disk configuration options' criterion to cover shrinking, we're kinda conflicting with ourselves
18:23:25 <kparal> so, do you think we should move this to Final?
18:23:27 <jreznik> so can we move this one to final?
18:23:39 <adamw> given the way we went about drafting the criteria so far, i'd say yeah
18:23:56 <adamw> but if people really believe shrinking should be beta-blocking...
18:24:02 <adamw> does the bug cause data loss?
18:24:07 <kparal> adamw: no
18:24:18 <dlehman> the question is, at least in part, "will it crash just from clicking around in the dialog trying to decide what to do?"
18:24:26 <kparal> I don't really say shrinking should be Beta, I just haven't noticed it's explicit in Final
18:24:47 <kparal> dlehman: probably, for some people
18:25:14 <jreznik> but it's still beta...
18:25:17 <kparal> I'd be OK with moving to Final
18:25:29 <kparal> tflink: mkrizek: thoughts?
18:25:50 <adamw> the thread for the criterion we added for final is https://lists.fedoraproject.org/pipermail/test/2013-July/116762.html , fwiw
18:25:51 <tflink> crashing is bad but if there's no data loss, it's less of a huge deal for beta
18:26:05 <kparal> I agree with tflink
18:26:23 <adamw> yeah, my interpretation would be to move it to final
18:26:25 <tflink> I'm ok with moving to final with beta fe
18:26:44 <tflink> if there's a fix in time, we can discuss whether it's too big to be pulling in for beta
18:26:44 <mkrizek> +1 to move to final
18:27:11 <jreznik> +1 if fix will be available and not as intrusive as dlehman thinks it will be, then beta FE
18:28:06 <kparal> dlehman: thoughts on Beta FE?
18:28:30 <kparal> does it even make sense to vote on that? will you have time for that? and interest to push it into Beta?
18:29:17 <dlehman> don't see it happening for beta
18:29:21 <kparal> dlehman: let's do it as tflink says - if the patch is ready, please propose as Beta FE
18:29:35 <dlehman> sounds right to me
18:29:37 <kparal> proposed #agreed 1013586 - AcceptedBlocker - We move this blocker from Beta to Final, because we have an explicit shrinking criterion there, as it was originally intended: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
18:30:04 <tflink> do you want to add the bit about proposing as beta FE if a fix materializes
18:30:07 <tflink> ?
18:30:25 <adamw> ack either way
18:30:26 <kparal> proposed #agreed 1013586 - AcceptedBlocker - We move this blocker from Beta to Final, because we have an explicit shrinking criterion there, as it was originally intended: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.". If the fix is ready in time, please propose as Beta FE.
18:30:39 <tflink> ack
18:30:44 <kparal> should I avoid using "FE" abbreviation?
18:30:44 <jreznik> ack
18:30:59 <kparal> ack
18:31:06 <kparal> #agreed 1013586 - AcceptedBlocker - We move this blocker from Beta to Final, because we have an explicit shrinking criterion there, as it was originally intended: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.". If the fix is ready in time, please propose as Beta FE.
18:31:19 <kparal> #topic (1000891) DVD is oversized (larger than 4.7 GB)
18:31:19 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891
18:31:19 <kparal> #info Accepted Blocker, distribution, MODIFIED
18:32:11 <kparal> so, pungi bug?
18:32:43 <tflink> sounds like
18:33:06 <adamw> kparal: i try to avoid using the abbreviation where I can, but it's not forbidden :)
18:33:22 <kparal> #info this seems to be a pungi bug, waiting for dgilmore
18:33:51 <jreznik> caused by langpacks patch by dmach and he told me dgilmore applied it in a bad way but that's what I heard...
18:34:35 <kparal> anything to add, anyone?
18:35:12 <kparal> #topic (1015234) F20 Beta TC1 ARM disk images unable to find root filesystem
18:35:12 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1015234
18:35:12 <kparal> #info Accepted Blocker, dracut, ASSIGNED
18:35:46 <tflink> I suspect this has been fixed?
18:35:49 <kparal> lot of activity since last time
18:35:56 <adamw> i don't think it's exactly fixed
18:35:59 <adamw> it was worked around for TC2
18:36:12 <adamw> a patch was posted that was supposed to actually fix it, but IIRC someone said it was insufficient
18:36:19 <tflink> ah
18:36:34 <adamw> we should probably ask for some clarity on exactly what the intended 'long term fix' is and whether it's what we have at present
18:38:05 <kparal> action for anyone?
18:38:21 <adamw> i'll do it (aprt of secretarialization)
18:38:59 <kparal> #info discussion is still ongoing as how to fix this properly. it's not clear whether this is fixed with the latest compose. it would be a good idea to ask the reporter to retest
18:39:25 <kparal> #action adamw to ask Harald and Dennis about bug 1015234
18:39:47 * kparal about to move on
18:39:51 <adamw> go for it
18:39:54 <kparal> #topic (1013767) rootfs on thinp not found, startup failure
18:39:55 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013767
18:39:55 <kparal> #info Accepted Blocker, dracut, NEW
18:41:18 <kparal> it seems the developers are working on this
18:41:30 <adamw> yeah
18:41:33 <adamw> not much to be done
18:41:38 <tflink> there is a proposed patch, as well
18:41:55 <kparal> a first half
18:42:08 <kparal> #info the developers are working on this, nothing to do from QA perspective
18:42:14 <jreznik> yep, I tried to ping them and move things forward
18:42:26 * kparal about to move on
18:42:42 <kparal> #topic (1013800) devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool
18:42:42 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013800
18:42:42 <kparal> #info Accepted Blocker, python-blivet, ASSIGNED
18:43:13 <adamw> more thinp fun
18:43:24 <kparal> do I imagine that, or cmurphy loves complicated disk setups?
18:43:43 <adamw> dlehman: did you get anywhere on this?
18:43:58 <adamw> kparal: it sure seems to be his specialty
18:44:01 <adamw> good thing SOMEONE does it :P
18:44:14 <kparal> right
18:44:36 <dlehman> adamw: I have a patch for it. it's been reviewed and all.
18:44:57 <kparal> #info patch is ready for this one. dlehman needs to submit it
18:44:58 <adamw> coolbeans
18:45:08 <adamw> so bug should be in POST i guess?
18:45:31 <dlehman> yeah, I'm probably going to push it today
18:45:42 <adamw> ok, updated
18:45:46 <kparal> this was the last one of Accepted Blockers
18:45:52 <dlehman> if I can untangle this mess of cloned bugs, flags, and blocker bugs
18:45:54 <tflink> nice
18:45:56 <kparal> want to go for Accepted Freeze Exceptions?
18:46:01 <kparal> we have 15 minutes
18:46:01 <adamw> dlehman: fun stuff :|
18:46:08 * adamw wants to go for dinner
18:46:13 <adamw> acceptedfe discussion isn't really necessary
18:46:19 <adamw> if they get fixed, they get fixed
18:46:33 <kparal> that means....
18:46:34 <adamw> unless there's one with a fix we want to debate the inclusion of in TC5, I guess. but i don't think so.
18:46:38 <kparal> #topic Open Discussion <your bugs here>
18:46:45 <kparal> anything else?
18:47:00 <tflink> nothing from me
18:47:01 <adamw> yeah, the only modified ones are the two kernel ones we already discussed
18:47:12 <adamw> newp, except that i will try and kick in to the fesco meeting that we're slightly worried by teh blocker load
18:47:37 <kparal> thanks
18:47:39 <adamw> holy ass-covering, batman
18:48:16 <kparal> btw this chairing stuff is awful, one can't sleep properly throughout the meeting
18:48:37 <kparal> thanks for coming!
18:48:41 <kparal> #endmeeting