17:00:19 <kparal> #startmeeting F20-blocker-review
17:00:19 <zodbot> Meeting started Wed Dec 11 17:00:19 2013 UTC.  The chair is kparal. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:19 <kparal> #meetingname F20-blocker-review
17:00:19 <kparal> #topic Roll Call
17:00:19 <zodbot> The meeting name has been set to 'f20-blocker-review'
17:00:23 <kparal> hello there
17:00:28 <kparal> who's available?
17:00:38 <kparal> #chair roshi adamw pschindl
17:00:38 <zodbot> Current chairs: adamw kparal pschindl roshi
17:00:53 * pschindl is here
17:00:54 <adamw> ahoyhoy
17:00:56 * roshi is here
17:00:59 * mkrizek is here
17:01:03 * greenlion_ is here
17:01:07 * Viking-Ice here
17:01:14 <kparal> roshi volunteered to do secretary work
17:01:27 <roshi> that I did
17:01:30 * nirik is here
17:02:22 <kparal> note: I'll move the order of some anaconda bugs because dlehman can stay for only 30 minutes
17:03:18 <kparal> ok, lets go
17:03:21 * jreznik is semihere
17:03:25 <kparal> #topic Introduction
17:03:25 <kparal> Why are we here?
17:03:25 <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.
17:03:25 <kparal> #info We'll be following the process outlined at:
17:03:25 <kparal> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:03:27 <kparal> #info The bugs up for review today are available at:
17:03:29 <kparal> #link http://qa.fedoraproject.org/blockerbugs/current
17:03:33 <kparal> #info The criteria for release blocking bugs can be found at:
17:03:35 <kparal> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
17:03:37 <kparal> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
17:03:39 <kparal> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
17:03:41 <kparal> today we have
17:03:43 <kparal> #info 10 Proposed Blockers
17:03:45 <kparal> #info 8 Accepted Blockers
17:03:47 <kparal> #info 2 Proposed Freeze Exceptions
17:03:49 <kparal> #info 12 Accepted Freeze Exceptions
17:03:51 <kparal> let's start with
17:03:53 <kparal> ============================================================
17:03:55 <kparal> Proposed Blockers
17:03:57 <kparal> ============================================================
17:03:59 <kparal> #topic (1008732) LUKSError: luks device not configured
17:04:03 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008732
17:04:05 <kparal> #info Proposed Blocker, anaconda, NEW
17:04:19 <Viking-Ice> #Team
17:04:19 <Viking-Ice> 
17:04:19 <Viking-Ice> <sigh> 8 new Anaconda bugs proposed as release blocker
17:04:30 <kparal> read from c34
17:04:52 <kparal> rejected blocker once, but greenlion found way to reproduce reliably
17:04:58 <greenlion> even from c37
17:05:22 <Viking-Ice> +1
17:06:09 * nirik reads up
17:06:14 <kparal> it is not likely for people to trigger this often. but it's not even totally unlikely
17:06:49 <adamw> so, what's the criteria violation here?
17:06:50 <cmurf> i'm +1 FE
17:06:55 <kparal> also c29 mentions a "normal" use case
17:07:02 <cmurf> deferring to anaconda team on whether to fix
17:07:09 <greenlion> I guess almost any refresh action with luks partition will trigger it
17:07:21 <kparal> adamw: fails to remove a partition, probably
17:07:27 <Viking-Ice> I dont think its normal for people to encrypt then decide not to encrypt
17:07:34 <kparal> dlehman: what do you think about this?
17:07:34 <Viking-Ice> or what to encrypt in custom
17:07:39 * nirik thinks this is pretty fringe
17:07:44 <cmurf> but i want to know more about what's happening in case this extends to other use cases
17:07:52 <dlehman> doesn't feel like a blocker to me. FE seems reasonable.
17:08:03 <nirik> -1/+1 for me
17:08:13 <adamw> the 'refresh disks' button did feel like a big 'Cause Problems' button when we first put it in, to me, but meh
17:08:27 <roshi> -1 / +1
17:08:30 <cmurf> me2
17:08:31 <kparal> I have to say I used nautilus to open LUKS to do some stuff and then reinstall in the past
17:08:33 <Viking-Ice> adamw, yeah confusing point
17:08:41 <kparal> (that would be c29 use case)
17:09:16 <adamw> -1, FE would depend whether we're slipping or not
17:09:41 <Viking-Ice> "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." [2]
17:09:48 <adamw> not a clear criteria violation, given our release cycle and the size of anaconda we can't really block every release on every complex crasher we find
17:09:50 <Viking-Ice> was the criteria cited last time
17:09:59 <roshi> at the least it could be made a common bugs - since the workaround is to have your mind made up when you start, right?
17:10:04 <Viking-Ice> adamw, I hardly call this complex
17:10:09 <kparal> roshi: definitely common bugs, yes
17:10:27 <adamw> or just reboot and try again
17:10:29 <cmurf> this is not a default installer configuration
17:10:41 <Viking-Ice> if anaconda does not hard crash I think it would be fine but..
17:10:55 <Viking-Ice> cmurf, what do you mean not default install
17:11:03 <kparal> it's unfortunate the crash occurs during installation, not before
17:11:12 <Viking-Ice> cmurf, if you can do it then one can argue it's default
17:11:22 <cmurf> the cited criteria says "in a default installer configuration"
17:11:47 <roshi> I thought "default" was just clicking "Next" and filling out user info
17:11:49 <cmurf> manual partitioning isn't the default
17:11:57 <Viking-Ice> cmurf, and refrences https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Disk_layouts
17:12:09 <greenlion> we have also " Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions "
17:12:25 * adamw still -1
17:12:39 <dlehman> Viking-Ice: that's ridiculous. if the criterion is "if you can do it" don't call it "default"
17:12:42 <adamw> cmurf: 'default installer configuration' just means the filesystem/container options it gives you when you boot normally
17:13:03 <Viking-Ice> cmurf, it's the criteria that was agreed upon last time
17:13:03 <adamw> the point of that wording is to not cover something that's hidden behind an experimental option, like btrfs used to be
17:13:17 <adamw> i wouldn't say the 'default installer configuration' bit is relevant here at all.
17:13:57 <Viking-Ice> dlehman, I said one can argue
17:14:01 <adamw> pretend it says "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered". is it able to? yes it is. does it crash if you do it a particular roundabout way? yes. do we consider that sufficient to violate the criterion? ehh. i don't, -1.
17:14:09 <nirik> how about we just vote and move on instead of arguing? ;)
17:14:11 <greenlion> adamw, in what case this bug should be hit to be a blocker in your vision?
17:14:41 <kparal> I see 3x -1 and 1x +1
17:14:46 <adamw> greenlion: without using the 'refresh disks' button. or if it happened to anyone who ever hit that button, maybe, not just people with an existing encrypted LVM layout.
17:15:00 <cmurf> or data loss which i don't think is the case
17:15:13 <kparal> cmurf: it alters the layout before crashing
17:15:23 <adamw> greenlion: and to be honest, i think slavish adherence to the partitioning criteria is a mistake - even though i'm the criteria guy - because they suck. we've tried writing them three times and they've sucked every time. next time someone else should draft it.
17:15:24 <Viking-Ice> adamw, I'm pretty sure users expect to be able to use the refresh button since it's available for them to click on
17:15:24 <cmurf> really?
17:15:28 <cmurf> ok hold on
17:15:40 <adamw> Viking-Ice: people expect a lot of things. =)
17:15:46 <adamw> okay, is anyone changing their minds, or can we move on?
17:15:49 <cmurf> my recollection is that it crashed figuring out what to do, and no actions were being taken yet
17:15:49 <kparal> cmurf: yes, it crashes at the beginning of installing, so probably it already wiped some partitions
17:15:50 <adamw> we've been on this bug for 10 minutes
17:15:50 <Viking-Ice> adamw, if users can they do ;)
17:15:59 <kparal> proposed #agreed 1008732 - RejectedBlocker - This is a fringe use case that might not hit many users. We will add it to CommonBugs and warn users they should not change the state of partitions (unlock them) before starting the installer, or do the same use the Rescan button.
17:16:00 <cmurf> kparal: are we sure?
17:16:03 <Viking-Ice> ack
17:16:07 <kparal> cmurf: of course not
17:16:08 <adamw> kparal: it wouldn't be wiping any you cared about keeping, though.
17:16:08 * jreznik is here
17:16:10 <nirik> kparal: do we want to +1 FE?
17:16:13 <adamw> ack
17:16:14 <greenlion> ack
17:16:25 * jreznik is re-reading
17:16:41 <kparal> proposed #agreed 1008732 - RejectedBlocker AcceptedFreezeException - This is a fringe use case that might not hit many users. We will add it to CommonBugs and warn users they should not change the state of partitions (unlock them) before starting the installer, or do the same use the Rescan button. Timely patch will be considered.
17:16:48 <Viking-Ice> ack
17:16:51 <nirik> ack
17:16:54 <roshi> ack
17:17:01 <adamw> ack, sure, if 'timely' means 'if we slip'.
17:17:04 <greenlion> ack
17:17:06 <kparal> :P
17:17:11 <kparal> #agreed 1008732 - RejectedBlocker AcceptedFreezeException - This is a fringe use case that might not hit many users. We will add it to CommonBugs and warn users they should not change the state of partitions (unlock them) before starting the installer, or do the same use the Rescan button. Timely patch will be considered.
17:17:12 <adamw> nothing FE can be 'timely' if we're going for a hero run today.
17:17:24 <cmurf> hero run
17:17:27 <kparal> #topic (1040352) Cannot change a standard partition's size, then return it to the original size
17:17:28 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040352
17:17:28 <kparal> #info Proposed Blocker, anaconda, NEW
17:17:28 <nirik> adamw: right, but it could be if we don't
17:17:32 <adamw> yeah.
17:18:10 <kparal> this one is workaroundable if you hit Reset All button and lose all your changes
17:18:22 <kparal> otherwise you can't reset the standard partition size value back to original
17:18:30 <nirik> kinda gross, but it is a workaround...
17:18:38 <cmurf> setting /boot size has been flaky for a while
17:18:40 <adamw> or just, you know, be okay with it being 1MB different in size or something
17:18:51 <adamw> cmurf: doesn't matter where the partition's going to be mounted, i don't think
17:19:04 <kparal> adamw: I think the assumption from the user is that the partition won't get touched if they set the size back
17:19:04 <adamw> the bug of this kind we took as a blocker was a *crasher*
17:19:11 <cmurf> it does all sorts of strange things, i have another bug on this on btrfs where changing 500MB /boot to btrfs caused the whole btrfs volume to snap to 2GB
17:19:12 <greenlion> kparal, and we suggest to not click refresh in other cases...
17:19:23 <kparal> greenlion: rescan, not refresh
17:19:31 <greenlion> as, yes, rescan
17:19:42 <Viking-Ice> and the /boot for uefi seems to be broken as well
17:19:43 <adamw> so yeah, this sucks, does it block the release of fedora? meh. -1.
17:19:47 <adamw> Viking-Ice: ?
17:19:48 <dlehman> cmurf: that's specific to btrfs
17:19:51 <nirik> -1/+1 from me too.
17:19:54 <danofsatx> sorry I'm late guys
17:19:59 <jreznik> yeah, we took it as blocker because it was crashers, if not anymore, then -1
17:20:00 <dlehman> cmurf: and /boot on btrfs is no longer allowed, so...
17:20:06 <Viking-Ice> adamw, what do you mean uefi
17:20:23 <adamw> Viking-Ice: yeah, i was asking for details on the uefi thing
17:20:26 <Viking-Ice> yes the uefi partitioning layout for /boot is wrong it works but it's wrong
17:20:34 <adamw> how do you mean 'wrong'?
17:20:37 <cmurf> wrong?
17:20:45 <adamw> eh, sidetrack, unless it's a release blocker
17:20:46 <greenlion> users might be tossing partition sizes few times until they get sizes they want to
17:21:17 <roshi> -1
17:21:19 <richard_> partitions seem to be OK since I let the installer do the work
17:21:20 <Viking-Ice> adamw, http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
17:21:26 <dlehman> FWIW I have a trivial patch that fixes this immediate problem. I cannot guarantee it will not cause some other regression.
17:21:33 <Viking-Ice> +1 FE
17:21:38 <kparal> proposed #agreed 1040352 - RejectedBlocker AcceptedFreezeException - This is inconvenient, but can be easily worked around by hitting Reset All. A patch will be considered.
17:21:38 <cmurf> -1FE -1 blocker
17:21:42 <cmurf> no more regressions please
17:21:43 <dlehman> Viking-Ice: we make no attempt to adhere to that spec
17:21:48 <adamw> okay, if you go to custom, decide you want to resize something, then change your mind, you're a bit stuck unless you start over. at this point i'm kinda -1 on all these 'if you start out doing it wrong then do it different' bugs, it feels like there are so many of them possible that it's futile to keep slipping a week to throw in emergency patches for one or two
17:22:02 <adamw> which might be breaking other cases, for all the time we have to test
17:22:02 <cmurf> FE=fragility encourager
17:22:07 <jreznik> adamw: +1
17:22:20 <nirik> kparal: ack
17:22:31 <pschindl> ack
17:22:36 <greenlion> -1 blocker/+1 FE
17:22:38 <Viking-Ice> adamw, rush pushing things out the door
17:22:38 <greenlion> ack
17:22:42 <adamw> i found breakage caused by two of the hero patches from yesterday (unless i tested wrong), so we may be at jlaska's point of no return with these things
17:22:56 <adamw> ack
17:23:02 <kparal> #agreed 1040352 - RejectedBlocker AcceptedFreezeException - This is inconvenient, but can be easily worked around by hitting Reset All. A patch will be considered.
17:23:02 <Viking-Ice> ack
17:23:02 <cmurf> this is the problem with making these sorts of bugs non-blocking at beta, is that by the time we get to final we want to be more conservative to avoid regressions and slip.
17:23:16 <kparal> roshi: please also add common bugs to all of this
17:23:23 <adamw> kparal +1
17:23:25 <kparal> #topic (1040413) Cannot change a logical volume's size twice, then return it to the original size
17:23:25 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040413
17:23:25 <kparal> #info Proposed Blocker, anaconda, NEW
17:23:29 <Viking-Ice> cmurf, we should not be dealing with installer bugs after beta
17:23:40 <roshi> yep
17:23:42 <kparal> this is the same, but for lvm, and it breaks only after you resize twice
17:23:55 <greenlion> cmurf, but if you do block beta on these bugs wouldn't you still waiting for it?..
17:23:59 <dlehman> agreed, but we need to be able to slow the rate of development of the installer to make that possible.
17:24:04 <adamw> so, obviously -1 as it's more involved than the last.
17:24:06 <jreznik> so it's even less important than the previous one...
17:24:09 <Viking-Ice> -1
17:24:09 <jreznik> -1
17:24:12 <nirik> -1
17:24:20 <kparal> FE votes the same?
17:24:21 <nirik> well, -1/+1 from me...
17:24:24 <dlehman> there's another trivial patch for this one
17:24:28 <kparal> ok
17:24:30 <greenlion> -1/+1
17:24:31 <adamw> -1 FE for this one
17:24:32 <kparal> proposed #agreed 1040413 - RejectedBlocker AcceptedFreezeException - This is inconvenient, but can be easily worked around by hitting Reset All. A patch will be considered.
17:24:34 <kparal> ah
17:24:37 <adamw> ack, since i'm ouitvoted
17:24:43 <Viking-Ice> ack
17:24:46 <cmurf> i'm still -1 FE
17:24:48 <nirik> ack
17:24:49 <pschindl> ack
17:24:51 <greenlion> ack
17:24:55 <kparal> should we redo FE vote?
17:25:07 <cmurf> yes
17:25:14 <kparal> let's vote again on FE
17:25:20 <richard_> FE?
17:25:24 <Viking-Ice> if the point is to push out the release regardless what's the point of this meeting?
17:25:38 <kparal> I'm +1 FE since we already added +1 FE to the previous once
17:25:43 <Viking-Ice> make sense
17:25:45 <adamw> 0
17:25:52 <dlehman> -1/-1 (I think this is not worth _any_ chance of a regression or delay.)
17:25:56 <cmurf> richard_ FE=fragility encouragement (a.k.a. freeze exception)
17:25:59 <cmurf> -1 FE
17:25:59 <nirik> +1 FE
17:26:03 <jreznik> this is more edge case than that previous one
17:26:06 <jreznik> -1 FE
17:26:22 <adamw> okay, changing to -1
17:26:22 <greenlion> +1 FE
17:26:25 <kparal> funny numbers, always results in zero sum :)
17:26:32 <richard_> ah! thanks cmurf!
17:27:02 <pschindl> -1 FE
17:27:05 <adamw> leave it undecided and move on? blocker status is the key
17:27:06 <kparal> it seems we can't agree, so I skip the vote, it was not nominated (how clever of me)
17:27:19 <kparal> proposed #agreed 1040413 - RejectedBlocker - This is inconvenient, but can be easily worked around by hitting Reset All.
17:27:26 * nirik shrugs. we can revisit I guess later if needed.
17:27:27 <cmurf> i'm counting FE fails
17:27:28 <jreznik> ack
17:27:28 <nirik> ack
17:27:31 <pschindl> ack
17:27:34 <Viking-Ice> ack
17:27:37 <greenlion> ack
17:27:39 <kparal> #agreed 1040413 - RejectedBlocker - This is inconvenient, but can be easily worked around by hitting Reset All.
17:27:40 <roshi> ack, will add CommonBugs tag
17:27:52 <kparal> roshi: thanks
17:27:53 <kparal> #topic (1040422) Standard partitions can't be enlarged
17:27:53 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040422
17:27:53 <kparal> #info Proposed Blocker, anaconda, NEW
17:28:06 <greenlion> -1 doesn't seem to be a bug in first place
17:28:11 <kparal> I would welcome some more testing to this one, I reported it today
17:28:22 <adamw> um. i think this is user error
17:28:23 <kparal> dlehman: is that intentional behavior or a bug?
17:28:32 * nirik reads up
17:28:33 <kparal> adamw: it can be UI error, not user error
17:28:37 <dlehman> I'd need to see evidence that there is available free space immediately following the partition you're trying to enlarge.
17:28:41 <adamw> if you do a normal layout, your disk will have /boot , then the partition for the LV, then the free space
17:28:48 <adamw> you can't enlarge /boot into the free space
17:28:49 <greenlion> in default configuration /boot is first partition - no free space to enlarge
17:28:58 <dlehman> right
17:29:06 <Viking-Ice> +1
17:29:06 <adamw> okay, we don't show the lozenge diagram of the disk any more so this isn't particularly clear, but we can't run around changing the UI at this point
17:29:07 <kparal> the UI fails to inform the user properly if the resize can't be attempted. I see "Free space: 1.5GB"
17:29:14 <adamw> so what are you proposing?
17:29:15 <Viking-Ice> this looks like a very valid usecase
17:29:17 <mkolman> yeah, I don't thing we want to move possible multi TB partitions
17:29:18 <adamw> we delay the release until...
17:29:22 <greenlion> that's UI problem...
17:29:28 <Viking-Ice> adamw, wtf adan
17:29:33 <adamw> we can completely redesign the custom part UI to indicate the physical location of partitions?
17:29:37 <adamw> Viking-Ice: what's the practical fix?
17:29:49 <Viking-Ice> if that's the attitude then call of this meeting now
17:29:54 <adamw> Viking-Ice: seriously
17:29:59 <adamw> if we accept this as a blocker, what's the next step?
17:30:00 <kparal> I don't propose to redesign the UI, I just don't know whether this is a bug or not
17:30:07 <dlehman> The UI's behavior is to attempt to achieve the requested size and come as close as possible. If the max possible size for sda1 is 500MB then that's all there is to work with.
17:30:10 <greenlion> and that seem we don't have "user must not be puzzled" criteria...
17:30:12 <kparal> I found it today with the rest of the issues, so I reported it
17:30:18 <nirik> error dialog saying 'cannot resize because it's not contigious'?
17:30:35 <dlehman> yeah, wth? we cannot be beholden to every possible user delusion or misconception.
17:30:37 <kparal> it's definitely a problem, that's what I say
17:30:38 <adamw> that sounds like the best we could do without a ui rewrite
17:30:52 <greenlion> UI rewrite? again?
17:30:59 <adamw> dlehman: well, i'd say this is a case of the UI not being correctly designed to match reality, but that's not something we can fix post-beta as a blocker emergency
17:31:17 <adamw> (the UI is designed as if all 'free space' were equal, this is still not true)
17:31:31 <cmurf> or the logic needs to put a bigger /boot somewhere else where there is enough space
17:31:32 <nirik> anyhow, I'm -1 blocker.
17:31:38 <Viking-Ice> +1
17:31:41 <Viking-Ice> blocker
17:31:41 <cmurf> but in either case i'm -1/-1
17:31:42 <adamw> i think we only considered the design in the context of creating new partitions, not enlarging existing
17:31:46 <Viking-Ice> expected user behaviour
17:32:09 <Viking-Ice> is to be able to enlarge as well as shring
17:32:12 <Viking-Ice> mean shrink
17:32:18 <adamw> -1, it's a problem but there is no plausible change to a post-beta OS we could make to make this significantly better. we really ought to have spotted it earlier, though.
17:32:24 <cmurf> it is unpleasant but we'd block for weeks on this to get a ui to show the user what's going on
17:32:29 <dlehman> we talked about some more graphical (literally) UIs for custom, but it would have taken another year or two
17:32:47 <Viking-Ice> cmurf, we can just as well block now as well after the bloody release
17:32:54 <Viking-Ice> in next cycle
17:33:09 <cmurf> Viking-Ice: ok so it's not weeks it's months to years
17:33:22 <cmurf> ergo, the answer is no
17:33:31 <dlehman> the notion of blocking because the user has no understanding of disk partitions and we haven't drawn them a damned picture is asinine
17:33:39 <cmurf> haha
17:34:02 <kparal> dlehman: the purpose of the new UI is that user doesn't have to understand partitioning, no?
17:34:09 <Viking-Ice> dlehman, if you give an end user the possibility to shrink you must realize he might want to expand as well
17:34:18 <kparal> he even can't, with no graphic representation
17:34:22 <dlehman> kparal: yes, but they still cannot have a pony.
17:34:23 <nirik> and in many sane cases, they can
17:34:23 <cmurf> this is the road of graphical installers, the expectations will get higher because they make installing OS's seem easy and magical
17:34:25 <kparal> proposed #agreed 1040422 - RejectedBlocker - This is probably a UI issue failing to inform the user properly what can and what cannot be achieved. It's not possible to redesign UI to fix this in a short time. If this really affects real cases where there is enough contiguous space for resize, please propose again.
17:34:32 <Viking-Ice> ack
17:34:35 <jreznik> ack
17:34:38 <adamw> ack
17:34:40 <greenlion> ack
17:34:42 <nirik> ack
17:34:45 <kparal> #agreed 1040422 - RejectedBlocker - This is probably a UI issue failing to inform the user properly what can and what cannot be achieved. It's not possible to redesign UI to fix this in a short time. If this really affects real cases where there is enough contiguous space for resize, please propose again.
17:34:55 <kparal> #topic (1040438) LV partitions can't be enlarged
17:34:55 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040438
17:34:55 <kparal> #info Proposed Blocker, anaconda, NEW
17:34:58 <kparal> and the same for LVM
17:35:05 <greenlion> -1 same
17:35:08 <kparal> (the same disk layout, btw)
17:35:09 <Viking-Ice> someone talk about a gnome installer appearing sooner rather then later which is going to be fun for us ;)
17:35:20 * adamw looks at yak farm prices
17:35:26 <kparal> can't enlarge anything at all, even when I have "free space"
17:35:29 <dlehman> We only support enlarging LVs if there is free space in the VG. We do not do a cascading resize of pv then vg then lv
17:35:42 <cmurf> adamw: hey yak poo burns you know? so you can sell yak logs!
17:35:53 <adamw> oh man, the gnome installer would be a dream to QA. it probably can only install one layout to a disk of exactly 500GB. if you don't have one you have to go out and buy one. i'm sold
17:35:56 <Viking-Ice> shgurg
17:36:09 <Viking-Ice> adamw, yeah sounds like less buggy ;)
17:36:14 <Viking-Ice> and more userfriendly
17:36:15 <greenlion> new PV could be made on free space...
17:36:17 <jreznik> adamw: yep, not supported, not intended, just one button "install"
17:36:26 <greenlion> jreznik, +1
17:36:31 <cmurf> -1/-1
17:36:34 <dlehman> greenlion: it could, but we've never had time to make it work.
17:36:40 <nirik> -1 blocker
17:36:51 <kparal> proposed #agreed 1040438 - RejectedBlocker - This is probably a UI issue failing to inform the user properly what can and what cannot be achieved. Anaconda doesn't support LV resize when there is no free space in the VG. Will be added to CommonBugs.
17:36:54 <adamw> this feels kinda like the last one, it's an inherent limitation of the design, not a bug we can find a reasonable fix for at this point
17:36:55 <greenlion> dlehman, yes, and users probably not want it to
17:36:55 <Viking-Ice> ack
17:36:56 <adamw> -1
17:37:00 <adamw> ack
17:37:02 <greenlion> ack
17:37:05 <nirik> ack
17:37:08 <jreznik> ack
17:37:22 <kparal> #agreed 1040438 - RejectedBlocker - This is probably a UI issue failing to inform the user properly what can and what cannot be achieved. Anaconda doesn't support LV resize when there is no free space in the VG. Will be added to CommonBugs.
17:37:35 <kparal> #topic (1040445) resize attempts ignored for LVs already scheduled for reformat
17:37:35 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040445
17:37:35 <kparal> #info Proposed Blocker, anaconda, NEW
17:37:50 <Viking-Ice> the same right
17:37:56 * nirik reads
17:37:57 <kparal> no
17:37:59 <cmurf> no
17:38:12 <adamw> this is about behaviour changing after you assign a mount point to an existing partition
17:38:17 <adamw> the resize stuff just mysteriously stops working
17:38:18 <kparal> when you mount some partition, you can't even downsize it
17:38:28 <adamw> does it work again if you un-assign the mountpoint?
17:38:30 <adamw> if so we can document it
17:38:37 <Viking-Ice> oh sorry still on the old bug
17:38:38 <kparal> adamw: I haven't tried that
17:38:44 <kparal> but I can in a minute
17:39:03 <Viking-Ice> this is very valid for custom as it seems
17:39:05 <adamw> though at this point when i say 'document' i mean 'tell people "look, if you want to resize stuff, probably best just do it before you start"'
17:39:17 <kparal> (outside of anaconda)
17:39:23 <adamw> still, we did specifically limit the 'resize' criterion to be quite specific
17:39:26 <greenlion> adamw, maybe tell users "don't use custom partitioning" right away?..
17:39:29 <mkolman> BTW, I'll note there is a thesis topic available for Anaconda storage layout visualization - but no one has applied for it just yet (a few asked, but no one applied in the end)
17:40:14 <adamw> anyone who does apply should probably be sent for a psychiatric evaluation immediately
17:40:21 <dlehman> We had some really nice ideas during design of current/new UI, but it would have required a ton of custom GTK widgets.
17:40:21 <kparal> adamw: mount point can't be unassigned. that might be yet another bug
17:40:32 <Viking-Ice> great just fracking great
17:40:36 <adamw> did anyone test this thing?
17:40:43 <adamw> i mean, i know i spent the last six months drinking, anyone else?
17:40:50 <kparal> who ever unassignes mount points?
17:40:50 <nirik> kparal: if you don't select mount point at all can you resize then?
17:40:53 <Viking-Ice> I assume everyone still want's to push to release
17:41:00 <kparal> nirik: yes
17:41:04 <adamw> nirik: yeah, it works fine till you set a mount point
17:41:05 <kparal> downsize at least
17:41:08 * nirik is still trying to determine the scope of this bug.
17:41:14 * greenlion thinks he saw something like this
17:41:32 <Viking-Ice> cant we just document only default install path works this release cycle anything outside that and it sucks to be you ;)
17:41:37 <kparal> but Reset All comes to the rescue
17:41:37 <cmurf> it's difficult imagining much contribution to an installer specific custom partitioner rather than a general purpose utility
17:41:47 <adamw> Viking-Ice: the thing is, a lot of these bugs probably exist in 19 too
17:41:48 <nirik> so, you could reboot and resize the next go I guess...
17:41:54 <kparal> the workaround is to Reset All
17:42:09 <Viking-Ice> adamw, so you are saying they should exist in 21 and 22 as well?
17:42:15 <cmurf> -1/-1
17:42:16 <adamw> which is a great workaround so long as you don't have an existing encrypted LVM...:P
17:42:19 <Viking-Ice> valid workaround
17:42:21 <Viking-Ice> -1
17:42:27 <greenlion> kparal, or reboot and start from scratch...
17:42:29 <kparal> adamw: those bugs come full circle, don't they?
17:42:37 <adamw> but yeah, -1, various ways to avoid this and we don't want to block very hard on resizing anyway
17:42:37 <Viking-Ice> lol
17:42:47 <nirik> -1
17:43:10 <jreznik> Viking-Ice: I think we really should start tracking rejected blockers and potential edge spots better... as it's coming over and over :(
17:43:11 <greenlion> -1/+1
17:43:12 <jreznik> -1
17:43:16 <kparal> FE votes?
17:43:20 <dlehman> let's just cancel f20. in f21 we will disable custom storage configuration. problem(s) solved.
17:43:27 <nirik> -1/+1
17:43:37 <kparal> dlehman: you said I can't have my pony
17:43:43 <dlehman> haha
17:43:51 <dlehman> that's _my_ pony
17:43:54 <cmurf> dlehman: i actually support that
17:43:57 <nirik> dlehman: we could start making 'Fedora(tm) hardware' that has a known specific config and comes pre-installed. ;)
17:44:11 <dlehman> heh
17:44:14 <cmurf> hey the big boys get away with it
17:44:16 <jreznik> nirik: even that's not as easy as it sounds :)
17:44:29 <cmurf> "you shall install only this way or that way, that is all"
17:44:30 <nirik> I'm sure.
17:44:32 <adamw> dlehman: hell, we can match the 'market leader' if we put in a button that runs gparted!
17:44:43 <Viking-Ice> I just hope the dvd dies in F21
17:44:47 <kparal> I see 2x +1 FE and 1x -1 FE
17:44:48 <Viking-Ice> that's my pony
17:44:56 <cmurf> -1 FE
17:45:06 <adamw> -everything
17:45:13 * adamw holds up big sign with NO painted on it
17:45:14 <nirik> adamw: so negative. ;)
17:45:15 <Viking-Ice> that seems to be the theme
17:45:16 <cmurf> that's -3 FE
17:45:17 <Viking-Ice> -1
17:45:22 <Viking-Ice> FE
17:45:26 <cmurf> now -4 FE
17:45:35 <kparal> proposed #agreed 1040445 - RejectedBlocker RejectedFreezeException - This is inconvenient, but can be worked around using the Reset All button, or resized in advance before assigning a mount point. Will be added to CommonBugs.
17:45:35 <jreznik> -1 FE
17:45:44 <dlehman> kparal: did you file a bug about scheduling a resize of an lv, then marking it for reformat, then setting it back to its original size causing a crash?
17:45:47 <Viking-Ice> ack
17:45:50 <jreznik> ack
17:45:55 <cmurf> ack
17:45:55 <kparal> dlehman: I could not reproduce that
17:45:58 <adamw> kparal: yeah, we thought that was actually the worst of the ones you hit
17:46:03 <adamw> oh, if it's not reproducible that's good...
17:46:17 <adamw> wait, if you can't resize after marking for format, how did you ever hit that?
17:46:19 <kparal> I actually hit it once, but couldn't again
17:46:19 <dlehman> I hit it yesterday.
17:46:25 <roshi> ack
17:46:28 <kparal> #agreed 1040445 - RejectedBlocker RejectedFreezeException - This is inconvenient, but can be worked around using the Reset All button, or resized in advance before assigning a mount point. Will be added to CommonBugs.
17:46:37 <cmurf> adamw: i had one of those from monday i can't reproduce so i marked it closed/insufificient data. no point spending time on it.
17:46:38 <dlehman> adamw: I may have had other fixes in place.
17:47:32 <kparal> this is the crash I received: https://bugzilla.redhat.com/show_bug.cgi?id=1039503
17:47:40 <kparal> if anyone else have seen it, we can propose it
17:47:44 <kparal> but I can't reproduce it
17:47:57 <cmurf> i've actually been hitting very few crashes
17:48:02 <cmurf> almost none
17:48:11 <bcl> ship it.
17:48:13 <adamw> =)
17:48:15 <cmurf> exactly
17:48:16 <Viking-Ice> lol
17:48:19 <bcl> if cmurf can't crash it..
17:48:19 <kparal> alright, let's move
17:48:29 <kparal> #topic (1039491) "ValueError: new size same as old size" if you set a volume to 'Shrink' but do not change its size, in Reclaim Space
17:48:29 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039491
17:48:29 <kparal> #info Proposed Blocker, anaconda, POST
17:48:41 <cmurf> no kidding
17:48:46 <adamw> okay, this one's a crasher, and it's not as complex as a lot of the others
17:48:53 <adamw> so i'm more open to turning the sign around
17:49:00 <kparal> c18 is descriptive I think
17:49:01 <cmurf> pre-beta it was like a bug magnetism course
17:49:02 <adamw> (it has 'reluctant yes' written on it in very small letters)
17:49:26 <Viking-Ice> +1
17:49:28 <kparal> adamw: actually this one is safer than the previous ones, because this one crashes before starting the installation
17:49:46 <adamw> eh, i don't place as much emphasis on that distinction as you do
17:49:50 <cmurf> and it crashes doing something almost no one would do
17:49:57 <kparal> the previous bugs wiped your partitions first
17:49:58 <nirik> no one sane anyhow.
17:49:59 <cmurf> which is choose to shrink but then not move the slider
17:50:11 <cmurf> it's like - ok you deserve the crash
17:50:21 <Viking-Ice> users should never find them in situation where they exiting partitions get wipe and then the installer crashes
17:50:23 <nirik> how intrusive is the fix?
17:50:32 <adamw> that's v. similar to the 'resize, then change back to the original value' bugs in 'user intent' i guess
17:50:34 <cmurf> no partitions get wiped with this bug
17:50:40 <kparal> Viking-Ice: that's my thinking
17:50:50 <adamw> except in this case they changed their minds faster, or just forgot to actually shrink anything
17:50:51 * Viking-Ice brings fourth introsometer
17:50:54 <greenlion> some people see installer gui 2 times a year and they want to click some buttons and explore it...
17:51:05 <cmurf> greenlion: absolutely
17:51:24 <adamw> there is a consideration related to the fix here
17:51:36 <Viking-Ice> greenlion, users having to do installation 2 a year is  a bug in itself ;)
17:51:37 <adamw> oh, no, that was a different one, never mind me
17:51:40 <greenlion> it's only testers who know what is "safe path" is in it...
17:52:04 <cmurf> for the fix, how difficult is it to do a "if the slider isn't moved, ignore the fact the shrink button was clicked at all"
17:52:28 <nirik> I guess I am a weak -1/+1... it seems like a thing most people won't do, and if they do, they can just re-run and not do that next time... sure it would be good to fix...
17:52:40 <greenlion> cmurf, the fix is like that as I see from patch
17:52:40 <kparal> mkolman: do you know some technical details here? how intrusive is the patch?
17:52:51 <bcl> there's a patch on the list. It's pretty simple.
17:52:52 <cmurf> -1/+1
17:52:58 <mkolman> kparal: looked quite simple
17:53:01 <Viking-Ice> +1
17:53:25 <cmurf> -1 blocker / +1 Fragility Express
17:53:48 <adamw> i can be -1. i have no problem with no. :P
17:53:48 <kparal> I'd normally give +1 here, but since we rejected much more serious ones (in my view) just a short time ago, I can go -1/+1 quite fine
17:53:52 <mkolman> cmurf: that's basically what it does - if the size is the same, it skips the resize action
17:54:01 <cmurf> brilliaint
17:54:10 <kparal> adamw: your standards left you again, I see
17:54:13 <adamw> cmurf: i was thinking of a different bug with that comment - there's another shrink bug for which the 'fix' introduces other issues
17:54:13 <cmurf> except i'm having spelling problems apparently
17:54:19 <adamw> we're probably going to hit that soon
17:54:20 <adamw> kparal: yup.
17:54:28 <Viking-Ice> <shrug>
17:54:32 <cmurf> i will give that a southpark F minus
17:54:36 <Viking-Ice> it's push the release regardless
17:54:40 <Viking-Ice> time
17:54:51 <cmurf> no! ship it!
17:55:03 <Viking-Ice> right
17:55:10 * cmurf produces unicorns one after another
17:55:12 <kparal> proposed #agreed 1039491 - RejectedBlocker AcceptedFreezeException - This is inconvenient, but quite unlikely to hit. It also doesn't present any user data loss. A patch will be considered.
17:55:21 <adamw> ack
17:55:22 <Viking-Ice> ack
17:55:25 <cmurf> ack
17:55:30 <greenlion> ack
17:55:32 <jreznik> ack
17:55:33 <nirik> ack
17:55:33 <kparal> #agreed 1039491 - RejectedBlocker AcceptedFreezeException - This is inconvenient, but quite unlikely to hit. It also doesn't present any user data loss. A patch will be considered.
17:55:54 <adamw> Viking-Ice: for me it's 'we either ship more or less what we have, or slip for at least three weeks to take a kind of random bunch of small patches which might make more things worse than better'
17:55:56 <kparal> #topic (1040012) SizeNotPositiveError: spec= param must be >=0
17:55:57 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040012
17:55:57 <kparal> #info Proposed Blocker, anaconda, POST
17:56:13 <cmurf> adamw: exactlyl
17:56:15 <kparal> we seem to be in a deny mood today
17:56:22 * cmurf for sure is
17:56:33 <adamw> Viking-Ice: i mean, there's _so much_ to storage, and at this point we're kind of running around blind inside it, knocking on bits and finding problems - we don't know what all else there is in there, and it's kinda late to be finding out
17:56:35 <kparal> I'm +1 here
17:56:40 <greenlion> +1 blocker
17:56:43 <Viking-Ice> +1
17:56:45 <kparal> if you create certain partition sizes, anaconda crashes
17:56:52 <kparal> like 500MB instead of 500MiB
17:56:57 <cmurf> wait another one of these
17:57:13 <kparal> this time it is not alignment issue from what I heard
17:57:21 <adamw> kparal: according to Disks, it actually creates a disk of size 500,000,256 bytes. no idea how significant it is, but there iti s.
17:57:35 <adamw> anyhow, this one is a genuine case you can hit, so closer to +1
17:57:36 <cmurf> oh and it is a regression
17:57:40 <bcl> floats are evil. vpodzime has a patch for this.
17:57:41 <cmurf> c19
17:57:41 <adamw> but it's also the one where the fix brings its own issue
17:57:50 <cmurf> what's the issue?
17:57:52 <kparal> yeah, vpodzime said gnome-disks is weird. but the size is valid
17:58:00 <nirik> well, it didn't happen in f19...
17:58:01 <adamw> cmurf: c#20
17:58:06 <greenlion> bcl, why not measure partition in bytes?
17:58:10 <kparal> and we don't know which tools and which partition sized might be affected
17:58:11 <jreznik> how much actually do we want to support out of anaconda created disks layouts?
17:58:15 <cmurf> oh god
17:58:31 <adamw> so then there's a fix for *that*, but it's quite a large one: just quit caring about fractions of MB at all
17:58:33 <nirik> adamw: that was before the last updates img/fix tho right?
17:58:39 <adamw> round everything off to single MB
17:58:42 <cmurf> *sigh*
17:58:51 * nirik grumbles.
17:58:52 <adamw> which is great, but is kind of a big change for late
17:58:58 <adamw> note the comment on the patch
17:59:00 <cmurf> yes i suggested single MB and no fractions a year ago
17:59:13 <mkolman> adamw: that's basically what the fix from vpodzime does
17:59:14 <cmurf> but also late for f20 so i'd say no thanks to that
17:59:21 <adamw> https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-December/007768.html
17:59:27 <greenlion> and it for sure rounds it to greater value which makes it oversize...
17:59:34 <adamw> "These two patches should fix two bugs, one F20 blocker and one proposed F20
17:59:35 <adamw> blocker. I've asked QA to give those patches a lot of testing because I
17:59:35 <adamw> understand especially PATCH 1/2 may cause some unexpected issues."
17:59:42 <cmurf> well it seems that the fix is easy, but produces a bigger bug than the original
17:59:42 <dlehman> greenlion: I'm watching a patch to track all sizes in bytes collect dust while I attend the all-year-long fedora flailfest
17:59:52 <adamw> greenlion: right, that's the kind of thing i'm worried we'd run into
18:00:00 <adamw> so, we have three choices:
18:00:01 <adamw> 1) reject
18:00:16 <adamw> 2) take the fix for the initial issue and live with the crasher I found (which you won't hit unless you do something a bit odd)
18:00:17 <greenlion> hm, they are using int() so it rounds to lower actually
18:00:24 <adamw> 3) take both fixes, cross fingerts
18:00:52 <cmurf> ughh
18:00:57 <nirik> 4) fix gnome-disks post release? meh, probibly not
18:00:58 <cmurf> ick, ick, triple ick
18:01:02 <adamw> bcl: dlehman: wdyt? i'm kinda thinking 2).
18:01:18 <kparal> adamw: your crash appears during installation?
18:01:20 <roshi> 2 sounds reasonable I think
18:01:29 <adamw> nirik: you could plausibly create a disk like this with just about any utility. fdisk can do it.
18:01:38 <nirik> yeah, I suppose so. ;(
18:01:39 <greenlion> adamw, what is your crasher?
18:01:42 <adamw> kparal: yeah
18:01:55 <adamw> greenlion: see comment #20
18:02:11 <kparal> and  c21
18:02:24 * greenlion is already a bit lost in all those anaconda bugs
18:02:25 <adamw> you have to have an affected disk, then choose to shrink it, and then actually drag the slider upwards very slightly.
18:02:28 <bcl> adamw: I defer to vpodzime. Anything that kills off floats is a plus in my book.
18:02:36 <bcl> even if there is fallout.
18:02:47 <adamw> bcl: i like it in principle, but if vpodzime is worried that it might break stuff, i'm kinda thinking f21...
18:03:20 <bcl> if it's hard to hit then yes.
18:03:29 <kparal> just a note, vpodzime's updates.img was tested today by several of our people on several bugs, found no problems
18:03:38 <kparal> of course that doesn't mean much
18:03:39 <cmurf> that's the simple fix
18:03:40 <cmurf> ?
18:03:50 <kparal> because as you can see, we do a sloppy job as a QA :)
18:04:09 <cmurf> we poke things with a stick and see if they meow
18:04:12 <kparal> cmurf: I think that's the proper fix, 3)
18:04:27 <cmurf> oh boy
18:04:28 <adamw> it sounds like it from vpodzime's messages, i haven't looked inside it yet
18:04:43 <adamw> well, shall we vote on blocker status and then discuss which fix to take later?
18:04:43 * nirik is in favor of 2...
18:04:58 <kparal> mkolman: the updates.img from vpodzime contains both fixes, right?
18:05:02 <nirik> but if 3 is looking ok, we could try it I guess
18:05:04 <Viking-Ice> did we vote already
18:05:08 <kparal> Viking-Ice: a bit
18:05:09 <adamw> i'm reluctant +1 on the blocker, it's a bit too likely to be hit to just throw it out
18:05:16 * greenlion is for taking both fixes
18:05:22 * jreznik is more in reject mood looking on what we rejected already
18:05:24 <kparal> Viking-Ice: you did
18:05:24 <mkolman> kparal: yeah, I think so
18:05:30 <cmurf> +1 on the simple fix
18:05:39 <Viking-Ice> kparal, and you as well as greenlion
18:05:43 <cmurf> 0 on the bigger one to fix the simple fix's crasher
18:05:44 <nirik> I guess a weak +1
18:05:45 <adamw> jreznik: it is significantly easier to hit than the ones we've rejected
18:06:09 <adamw> jreznik: it doesn't require you to go into custom or change your mind about anything, you hit it on a perfectly normal action - try and resize a partition - if that partition happens to be a 'weird' size. and it's a crasher.
18:06:24 <kparal> what version are we voting for? 2) or 3) ?
18:06:29 <adamw> we're voting on whether the bug is a blocker
18:06:35 <adamw> which fix to take isn't strictly a part of that
18:06:40 <cmurf> oh
18:06:41 <nirik> right.
18:06:41 <kparal> ok
18:06:45 <kparal> proposed #agreed 1040012 - AcceptedBlocker - Violates the criterion "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.". In this case anaconda crashes for certain partition sizes.
18:06:54 <nirik> ack
18:06:56 <adamw> reluctant ack
18:06:57 <cmurf> ack
18:06:57 <roshi> ack
18:06:57 <greenlion> ack
18:07:02 <kparal> adamw: counts as well
18:07:04 <kparal> #agreed 1040012 - AcceptedBlocker - Violates the criterion "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.". In this case anaconda crashes for certain partition sizes.
18:07:27 <kparal> #topic (1025072) libstdc++/58800 (the bug, not the fix) just got backported to Fedora 19 and 20
18:07:27 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1025072
18:07:27 <kparal> #info Proposed Blocker, gcc, NEW
18:07:38 <adamw> hold up
18:07:39 <cmurf> well wait
18:07:47 <adamw> can we look at the one unaddressed anaconda accepted blocker while we have anaconda folks?
18:07:48 <adamw> if we still do?
18:07:53 <cmurf> so it's a blocker which means the simple fix must happen
18:07:53 <Viking-Ice> he bug, not the fix lol
18:07:54 <kparal> sure
18:08:03 <kparal> #undo
18:08:03 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xe6f2510>
18:08:06 <kparal> #undo
18:08:06 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0xe6f23d0>
18:08:08 <cmurf> and then the bigger fix for c20 is at best an FE
18:08:08 <kparal> #undo
18:08:09 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xe0e6810>
18:08:22 <kparal> adamw: bug number?
18:08:27 <adamw> 1039292
18:08:42 <kparal> #topic (1039292) Assigning partition to disk with not enough free space causes custom partition interface to become unusable
18:08:42 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039292
18:08:42 <kparal> #info Accepted Blocker, anaconda, NEW
18:09:03 <kparal> please note this is already accepted
18:09:04 <dlehman> I just tested a fix for this one. I think I can honestly say it has zero risk.
18:09:20 <Viking-Ice> adamw, this one already is accepted blocker
18:09:45 <kparal> Viking-Ice: yes, but dlehman must leave soon
18:09:59 <Viking-Ice> oh ok
18:10:17 <greenlion> dlehman, it doesn't fix #c8 there?
18:10:19 <kparal> #info dlehman has a fix for this one, with 'zero risk'
18:10:35 <adamw> yeah, just wanted to do an out-of-order acceptedblocker review while anaconda devs were here
18:10:40 <adamw> to check on the status of it
18:10:44 <kparal> 'zero risk' should be added to the list of forbidden words, I think
18:10:44 <adamw> we have a fix for it? awesome
18:10:55 <adamw> kparal: did you see mjg59's twitter yesterday? 'five word tech horrors'
18:10:59 <cmurf> back to yak farm shopping
18:11:01 <kparal> not yet
18:11:02 <adamw> i contributed 'it probably can't break anything'
18:11:08 <dlehman> greenlion: unrelated. they end up being luks-$UUID anyway.
18:11:24 <kparal> oh, twitter. I don't have it
18:11:29 <adamw> so if we have a fix for this, then i think that's all that needs to be said, right?
18:11:34 <nirik> hurray
18:11:38 <adamw> just need to put it into the hero anaconda build that'll show up today
18:11:39 <greenlion> dlehman, new ones are shown like 'luks-vdaN'...
18:11:42 <adamw> then find out it explodes and slip again
18:11:46 <nirik> yep.
18:12:05 <kparal> let's continue with the proposed blockers
18:12:12 <dlehman> greenlion: right, because the order of operations varies from autopart to custom.
18:12:34 <kparal> can we?
18:12:45 <adamw> sure, i think so
18:12:45 <cmurf> yes
18:12:47 <kparal> #topic (1025072) libstdc++/58800 (the bug, not the fix) just got backported to Fedora 19 and 20
18:12:47 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1025072
18:12:47 <kparal> #info Proposed Blocker, gcc, NEW
18:13:05 <kparal> c11+ is new
18:13:25 <nirik> yeah.
18:14:03 <kparal> so, libreoffice is on default media
18:14:05 <nirik> -1/-1, fix in updates.
18:14:24 <adamw> given c#14 and c#15 and the general absence of shit exploding all over the place, yeah, -1
18:14:27 <Viking-Ice> -1
18:14:32 <cmurf> -1/-1
18:14:36 <jreznik> -1/-1
18:14:36 <adamw> if LO on the lives was crashing all the time that'd be one thing, but it doesn't seem to be
18:15:03 <greenlion> -1
18:15:03 <cmurf> impact with fan averted
18:15:28 <kparal> proposed #agreed 1025072 - RejectedBlocker - No critical packages are affected. The affected packages don't seem to be crashing frequently. Will be fixed in updates.
18:15:32 <Viking-Ice> ack
18:15:38 <greenlion> ack
18:15:38 <cmurf> ack
18:15:56 <jreznik> ack
18:16:01 <nirik> aack
18:16:06 <kparal> #agreed 1025072 - RejectedBlocker - No critical packages are affected. The affected packages don't seem to be crashing frequently. Will be fixed in updates.
18:16:11 <kparal> #topic (1021749) Review Request: php-symfony - PHP framework for web projects
18:16:11 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021749
18:16:11 <kparal> #info Proposed Blocker, Package Review, ON_QA
18:16:29 <Viking-Ice> +1 FE I dont understand this one was proposed as a blockerf
18:16:30 <adamw> does anyone know the timeline here?
18:16:40 <adamw> Viking-Ice: if it would cause broken deps on the DVD that'd be autoblocker
18:16:48 <adamw> but i'm not sure what all of php is on the dvd
18:16:55 <kparal> can somebody summarize?
18:17:05 <adamw> kparal: a package that various php packages depend on was retired during freeze
18:17:16 <adamw> it's supposed to be replaced by this one, but this one can't go stable with the freeze in place
18:17:24 <Viking-Ice> it's a fuckup that's what it is late fuckup
18:17:31 <Viking-Ice> I guess due to things being stuck in review
18:17:33 <RemiFedora> Hi
18:17:39 <nirik> RemiFedora: can you sum up for folks?
18:17:47 <adamw> Viking-Ice: it's basically because of the holes in the freeze
18:17:53 <RemiFedora> for symfnony ?
18:17:55 <adamw> Viking-Ice: you shouldn't be able to retire stuff in freeze without some kind of manual override
18:17:57 <adamw> RemiFedora: yeah, thanks
18:18:17 <RemiFedora> php-symfony-* obsoletes php-symfony2-* packages
18:18:27 <Viking-Ice> adamw, orphaning retiring etc should be done before alpha
18:18:47 <RemiFedora> php-symfony2-* habe benn retired and php-symfony-* are not yet in stable
18:18:53 <Viking-Ice> but yeah broken process
18:19:22 <kparal> RemiFedora: does it break any important packages on DVD?
18:19:24 <RemiFedora> broken process, probably, but now we have broken deps, and we should fix tis
18:19:25 <adamw> RemiFedora: do we have a list of what deps are broken?
18:19:31 <adamw> kparal: it's not just 'important', it's 'any'
18:19:36 <adamw> if it breaks any, we need the bug as a blocker
18:19:37 <kparal> right, any packages
18:19:39 <adamw> if it doesn't, it can be FE
18:19:40 <RemiFedora> Mostly PHPUnit, which is used by tons of packahe on %check
18:20:05 <nirik> but that could be fixed as a 0 day update, no?
18:20:14 <adamw> http://fpaste.org/60889/38678601/
18:20:15 <cmurf> what about yanking the things that need the deps?
18:20:27 <cmurf> is that one thing or a pile of things?
18:20:30 <adamw> there's no real harm to taking this is if it doesn't hit the deliverables
18:20:38 <adamw> so i'm +1 FE anyway, but blocker status depends on whether it hits the dvd
18:20:39 <Viking-Ice> it should not
18:20:47 <adamw> http://fpaste.org/60889/38678601/ is php* on the DVD
18:20:49 <kparal> I don't see PHPUnit on DVD
18:21:29 <cmurf> is that a case sensitive ls?
18:21:33 <kparal> wouldn't we know the broken deps already with TC5?
18:21:42 <RemiFedora> package name is php-phpunit-PHPUnit
18:21:42 <adamw> cmurf: just 'ls php*'
18:21:54 <adamw> kparal: i wasn't sure of the timeline
18:21:55 <cmurf> isn't the thing being looked for PHPUnit?
18:21:59 <adamw> do we have a date for the retirement?
18:22:26 <adamw> cmurf: see remi: "php-phpunit-PHPUnit'
18:22:46 <cmurf> yeah i don't see it in either case
18:22:48 <kparal> the problem was reported on 12-06
18:23:02 <RemiFedora> I receive broken dep mail on 12-06
18:23:05 <kparal> TC5 is from 12-05
18:23:38 <nirik> yeah, it was after rc5
18:23:40 <nirik> tc5
18:23:40 * ignatenkobrain is here
18:23:46 <ignatenkobrain> hi all
18:23:56 <ignatenkobrain> forget about bb review today
18:25:31 <adamw> bb?
18:25:35 <nirik> it was dec 4th actually.
18:25:37 <adamw> oh, blocker bug
18:25:46 <jreznik> so in this case we probably need this (if it's on dvd), right?
18:25:59 <adamw> just means we can't say TC5 proves it's okay
18:26:06 <kparal> jreznik: we don't know whether some of the affected packages are on DVD
18:26:08 <nirik> right.
18:26:15 <adamw> let's just call it FE, pull it into RC1, and move the hell on
18:26:22 <Viking-Ice> right
18:26:23 <roshi> ^^ +1
18:26:26 <cmurf> +1
18:26:27 <greenlion> +1
18:26:28 <kparal> we can run repoclosure on current repos and compare the php packages list
18:26:30 <adamw> let's see, if we want some process hackery
18:26:41 * nirik runs one
18:26:51 <adamw> agree that the bug's a blocker if any of the packages are on the DVD, FE if not, and we'll figure things out on BZ if need be
18:27:16 <cmurf> sounds gooder
18:27:17 <nirik> +1
18:27:22 <kparal> proposed #agreed 1021749 - RejectedBlocker AcceptedFreezeException - This causes some broken dependencies and can be fixed with a new package. It seems no affected packages are available on DVD. If there are, please re-propose as a blocker.
18:27:27 <roshi> wfm
18:27:30 <roshi> ack
18:27:37 <cmurf> ack
18:27:48 <adamw> we have daily repoclosures, btw. http://fpaste.org/60891/67864571/ is the list from 1211.
18:27:53 <jreznik> so maybe write it in the proposal, it could be auto blocked than
18:27:58 <adamw> right, nack
18:28:03 <adamw> make it acceptedfe, blocker status undetermined
18:28:24 <adamw> it can be made an auto-blocker without further discussion if we determine it'd affect dvd compose
18:28:34 <kparal> proposed #agreed 1021749 - AcceptedFreezeException - This causes some broken dependencies and can be fixed with a new package. It seems no affected packages are available on DVD. If there are, this can be automatically accepted as a blocker.
18:28:41 <cmurf> ack
18:28:56 <greenlion> ack
18:28:56 <adamw> propose #agreed 1021749 - AcceptedFreezeException - this is at least FE. blocker status depends on whether it affects any package on the DVD; we will determine and update status after the meeting
18:29:00 <adamw> ...or ack to kparal's
18:29:01 <adamw> either way
18:29:02 <nirik> ack
18:29:12 <kparal> ack
18:29:19 <jreznik> ack (any)
18:29:20 <Viking-Ice> ack
18:29:23 <kparal> #agreed 1021749 - AcceptedFreezeException - this is at least FE. blocker status depends on whether it affects any package on the DVD; we will determine and update status after the meeting
18:29:42 <nirik> http://paste.fedoraproject.org/60892/13867865/
18:29:43 <kparal> that's all of proposed blockers
18:29:45 <nirik> (repoclosure)
18:29:51 <cmurf> wow
18:30:04 <cmurf> 5 minute break for pansies?
18:30:41 <adamw> .fire cmurf
18:30:44 <zodbot> adamw fires cmurf
18:30:44 * cmurf goes to get a cáfe
18:30:45 <kparal> cmurf: feel free to have a break, no sweat :) we'll go to the 1 proposed FE
18:30:56 <roshi> lol
18:30:57 <kparal> ============================================================
18:30:57 <kparal> Proposed Freeze Exceptions
18:30:57 <kparal> ============================================================
18:30:58 <cmurf> oh i can live for one
18:31:07 <kparal> #topic (1040536) cloud kickstart: switch order of console kernel command line params to make log show up in openstack.
18:31:07 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040536
18:31:07 <kparal> #info Proposed Freeze Exceptions, spin-kickstarts, NEW
18:31:20 <Viking-Ice> +1 FE
18:31:34 <cmurf> +1
18:31:39 <nirik> sure, +1
18:31:45 <adamw> +1
18:31:48 <ignatenkobrain> +1 FE
18:31:49 <greenlion> +1
18:31:51 <pschindl> +1
18:31:52 <adamw> is this a retroactive one? :)
18:32:06 <roshi> +1
18:32:21 <nirik> adamw: no?
18:32:32 <nirik> it was applied on master, but not f20 branch that I saw.
18:32:41 <adamw> ah, ok
18:32:46 <adamw> thought someone mentioned it had gone to f20
18:32:55 <jreznik> +1 FE
18:32:55 <kparal> proposed #agreed 1040536 - AcceptedFreezeException - This improves situation for cloud deployments and presents no risk to other products.
18:32:58 <adamw> so we'd need to apply it and do a new s-k quickly to go in rc1
18:32:58 * nirik looks to make sure.
18:33:01 <roshi> ack
18:33:04 <adamw> ack
18:33:04 <pschindl> ack
18:33:04 <brunowolff> I think Matthew has a few more changes since the last group.
18:33:19 <kparal> #agreed 1040536 - AcceptedFreezeException - This improves situation for cloud deployments and presents no risk to other products.
18:33:25 <nirik> nope, don't see it on f20
18:33:28 <adamw> ok
18:33:44 <adamw> can someone volunteer to look after getting it committed and a new s-k built?
18:33:48 <kparal> ready for accepted blockers or fainting already?
18:34:11 <ignatenkobrain> kparal: sure! =)
18:34:26 <ignatenkobrain> kparal: all time ready !~
18:34:29 <jreznik> let's ping mattdm
18:34:31 <Viking-Ice> is there any ab we need to worry about?
18:34:31 <brunowolff> I can do the new build after Matthew cherry-picks the changes into the f20 branch.
18:34:39 <adamw> fuck it, i can do that now
18:34:41 <jreznik> brunowolff: thanks
18:34:48 <nirik> does it include the live key import commit?
18:34:54 <nirik> we had another fe on that one right?
18:35:00 <adamw> Viking-Ice: i think i'm on top of them all, but in the interests of raptor proofing / sanity checking let's go through any anyone wants to discuss
18:35:00 <jreznik> adamw: so you'll do it or should I ping him?
18:35:01 <Viking-Ice> no
18:35:11 <kparal> nirik: the only other proposed FE was the php stuff
18:35:16 <Viking-Ice> mean no with nirik fe
18:35:19 <adamw> the key thing's already accepted fge
18:35:20 <brunowolff> The live key import might have been the changes he did a couple of days ago.
18:35:21 <adamw> fe
18:35:24 <nirik> kparal: it was accepted before.
18:35:52 <greenlion> I have a question about accepted blocker 1038969
18:36:07 <ignatenkobrain> .fire greenlion
18:36:07 <zodbot> adamw fires greenlion
18:36:07 <brunowolff> After that change I asked him to get a bug entered for changes while in freeze and he seems to be playing nice now that he knows.
18:36:12 <RemiFedora> I think the security team would like to propose php 5.5.7 for F20... but probably not yet done... and probably to late.
18:36:15 <kparal> greenlion: will come to that. do you need to discuss it ASAP?
18:36:39 <cmurf> adamw needs coffee
18:36:51 <greenlion> kparal, nope, could be on usual schedule
18:36:53 <cmurf> or maybe a scone with honey
18:36:59 <cmurf> firing people left and right
18:37:04 <adamw> pushed the cloud kickstart thing
18:37:05 <kparal> seems we're ready for the truly awesome and interesting part
18:37:08 <kparal> ============================================================
18:37:09 <kparal> Accepted Blockers
18:37:09 <kparal> ============================================================
18:37:14 <adamw> if we want to fix the GPG key import let's do that now before s-k gets built
18:37:23 <adamw> nirik: can you push either your fix or kalev's?
18:37:36 * kparal waiting until this is sorted out
18:37:50 * Viking-Ice goes out for a "fresh air"
18:38:00 <adamw> nirik: you'll also want to fix matt's GPG import commit for the cloud kickstart as he copied the broken version
18:38:33 <nirik> adamw: I don't feel strongly about which fix to use...
18:38:47 <nirik> you prefer the wildcard?
18:40:17 <adamw> nirik: that was my instinct, but i have no idea why anyone trusts me
18:40:21 <adamw> toss a goddamn coin
18:40:38 <nirik> or you can make whichever change you want since you are in there already for this last one? ;)
18:40:58 <brunowolff> Let me know when you are ready for s-k to be rebuilt. Matt already started committing his changes and should be ready very soon.
18:42:32 <adamw> brunowolff: i already committed the one we just signed off on.
18:42:44 <adamw> let's discuss this in -releng and move on here
18:42:49 <kparal> ok
18:42:49 <nirik> ok
18:42:53 <kparal> #topic (1038847) SizeNotPositiveError: spec= param must be >=0 - "1" as size of encrypted partition
18:42:53 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1038847
18:42:53 <kparal> #info Accepted Blocker, anaconda, POST
18:43:02 <brunowolff> OK. I forgot that the author stays the same when cherry-picking.
18:43:41 <brunowolff> I still need to wait for the GPG import fix you were just discussing?
18:44:00 <adamw> so i think vpodzime's test image has an improved version of dlehman's fix
18:44:11 <adamw> brunowolff: yes, can you join #fedora-releng so we can sync up there
18:44:15 <nirik> brunowolff: yeah, lets figure that out in releng
18:44:32 <adamw> i really ought to just look at what's in the updates.img.
18:45:30 <kparal> is that the same updates.img as for the partition sizes bug?
18:45:36 * kparal checking
18:45:44 <adamw> i think he threw all his fixes together in one image, yeah
18:45:49 <adamw> i believe what the updates.img contains is https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-December/007766.html
18:46:26 <ignatenkobrain> greenlion's bug :D
18:46:38 <ignatenkobrain> he too much tested anaconda
18:46:40 <greenlion> ignatenkobrain, anaconda's bug, not mine! :)
18:47:08 <kparal> it's the same one
18:47:08 <adamw> so feedback from jan looks good
18:47:19 <adamw> i'll verify here too before we go for the big build
18:47:25 <ignatenkobrain> Spherical anaconda in vacuum
18:47:30 <adamw> =)
18:47:31 <kparal> but this is tricky, if we require only the simple fix for 1040012, then we need to verify again
18:47:38 <kparal> with a different updates.img
18:47:45 <adamw> the two shouldn't be related
18:47:51 <adamw> (five word tech horrors)
18:48:09 <kparal> right
18:48:42 <cmurf> i want to see a blog on this five word tech horror biz
18:48:44 <adamw> OK, confirmed, the patch i linked is definitely what's in http://vpodzime.fedorapeople.org/f20_blockers_updates.img
18:48:51 <kparal> #info seems to be fixed, it would be great to have more verification. the updates.img is the same as for 1040012, therefore containing contentious fixes
18:48:55 <adamw> so that's what we're looking at including, and initial testing is good. not sure what else to say
18:49:23 <kparal> move on?
18:49:26 <jreznik> yep
18:49:27 <Viking-Ice> right
18:49:28 <adamw> if people could run installs with http://vpodzime.fedorapeople.org/f20_blockers_updates.img against all kinds of disks (esp. different sized disks and partitions) and check 'reclaim space' it'd be helpful
18:49:46 <kparal> #info if people could run installs with http://vpodzime.fedorapeople.org/f20_blockers_updates.img against all kinds of disks (esp. different sized disks and partitions) and check 'reclaim space' it'd be helpful
18:49:56 <kparal> #topic (1039292) Assigning partition to disk with not enough free space causes custom partition interface to become unusable
18:49:56 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039292
18:49:56 <kparal> #info Accepted Blocker, anaconda, NEW
18:50:29 <kparal> oh, we already did this one
18:50:29 <greenlion> we looked at this one already
18:50:43 <kparal> #topic (1024223) fedup 19->20 failed with DVD iso upgrade
18:50:43 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1024223
18:50:43 <kparal> #info Accepted Blocker, fedup-dracut, ASSIGNED
18:51:04 <adamw> kparal: new proposed FE after this one, https://bugzilla.redhat.com/show_bug.cgi?id=1020112
18:51:17 <adamw> so i've reproduced this and tested the fixes and it looks good
18:51:21 <adamw> further confirmation welcome
18:51:31 <kparal> adamw: should we do it right now or after accepted blockers section?
18:51:35 <adamw> requires us to pull the newer fedup-dracut into rc1 and build the upgrade.img with it, then a fix to f19's fedup
18:51:39 <Viking-Ice> lol "
18:51:39 <Viking-Ice> Would be nice if f20 ppc images could boot."
18:51:41 <adamw> kparal: after this bug
18:51:48 <Viking-Ice> +1 FE
18:52:15 <kparal> #info seems to be fixed, we need a new fedup for F19 and pull newer fedup-dracut to RC1
18:52:47 <kparal> @@ now a new proposed FE @@
18:53:08 <kparal> #topic (1020112)  Fedora 20 alpha DVD is not recognized as bootable disk on Apple G5
18:53:11 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020112
18:53:25 <cmurf> do it now
18:53:29 <cmurf> +1 FE
18:53:32 <adamw> +1 FE, bcl says the fix only affects ppc paths inside lorax so should be safe and there's an obvious benefit
18:53:32 <jreznik> looking on what bcl wrote in anaconda, +1 FE
18:53:36 <roshi> +1
18:53:39 <greenlion> +1 FE
18:53:44 <adamw> does the fix only affect ppc path?
18:53:44 <adamw> <bcl> yep.
18:53:44 <adamw> <adamw> okay
18:53:44 <adamw> <bcl> just the lorax template and ppc mapping file.
18:53:48 <ignatenkobrain> +1 FE
18:54:03 * nirik thought apple ppc hw was specifically disclaimed
18:54:41 <adamw> nirik: that was back when ppc was primary arch, i think
18:55:01 <nirik> don't think so... back then it was supported.
18:55:06 <kparal> too long for me to read
18:55:21 <kparal> proposed #agreed 1020112 - AcceptedFreezeException - This improves situation for Apple G5
18:55:27 <ignatenkobrain> ack
18:55:27 <greenlion> ack
18:55:28 <jreznik> ack
18:55:44 <nirik> doesn't really say, but ok, sure.
18:55:47 <Viking-Ice> ack
18:56:10 <kparal> #agreed 1020112 - AcceptedFreezeException - This improves situation for Apple G5
18:56:39 <kparal> back to accepted blockers
18:56:41 <kparal> #topic (1000893) Desktop Live is oversized (larger than 1 GB)
18:56:41 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000893
18:56:41 <kparal> #info Accepted Blocker, LiveCD, MODIFIED
18:57:36 <jreznik> seems it *should* be good but you know, s-word
18:57:39 <adamw> i did a test build with all blocker/fe fixes as of yesterday plus the smaller LO build, it got back under size
18:57:52 <adamw> so yeah, all we can really do is fire RC1 with the LO update and cross all digits
18:58:09 <greenlion> why do we care slight bigger image size if we don't slight different units in anaconda? :)
18:58:15 <Viking-Ice> ah the glorification of should
18:58:17 <Viking-Ice> lol
18:58:20 <adamw> =)
18:58:29 <adamw> greenlion: because we're very, very bad at what we do
18:58:35 <adamw> never lose sight of this
18:58:45 <kparal> #info adamw did a test build, we should be under limit
18:58:52 <ignatenkobrain> only hardcore only dual-dvd size :D
18:59:03 <kparal> #topic (1026860) lvm2: services specified with SYSTEMD_WANTS are not started for some LVM volumes
18:59:03 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1026860
18:59:03 <kparal> #info Accepted Blocker, lvm2, MODIFIED
18:59:12 <Viking-Ice> kill that releng dvd that's what I say
18:59:21 <jreznik> so I spent some time today with Peter on this one...
18:59:49 <Viking-Ice> this relates to the one they have to have synced update right
18:59:53 <kparal> jreznik: a summary please?
19:00:08 <cmurf> uh oh this is starting off really good, like a serious come to jesus talk is about to happen
19:00:46 <cmurf> haha we're going to get a massive summary or really bad news with a pause this long!
19:00:54 <Viking-Ice> cmurf, self biography for christmas
19:00:57 <jreznik> so there are two possibilites I'd say - go against lennart's wish and pick that fix in systemd - a bit more tested or we have a new lvm2 build
19:01:03 <adamw> sorry, i was just doing something else
19:01:10 <adamw> jreznik: i don't think it's against lennart's wishes
19:01:17 <adamw> but we're kinda reading tea leaves
19:01:20 <Viking-Ice> I want to pull in that double fix ont he dvd
19:01:23 <Viking-Ice> mean the
19:01:36 <adamw> the way i was reading it is that lennart's happy to go with the workaround for release, then replace it with the 'proper fix' on update
19:01:38 <Viking-Ice> as opposed to push it via updated
19:01:45 <cmurf> i would do that
19:01:49 <jreznik> adamw: even that lvm build is still not proper fix
19:01:54 <cmurf> is the new lvm2 build tested?
19:02:05 <adamw> at this late point i'd hate to go with the 'proper fix' and find it busts something...but of course there are risks to changing the approach post-release too
19:02:07 <cmurf> i'm finding lvm2 this release is just really really testy
19:02:07 <jreznik> but peter don't want to risk proper fix now
19:02:26 <Viking-Ice> cmurf, you rather want to push unested update to a GA release?
19:02:35 <cmurf> no i don't
19:02:46 <cmurf> what we have is tested even if it has some problems
19:02:56 <jreznik> and yes, he's a bit worried about that proper fix as an update but less than for release
19:03:10 <cmurf> an untested new build of lvm2 (?) is not a good idea even if it fixes things, it's unknown what it breaks
19:03:22 <cmurf> and like i said lvm has been finicky this whole release cycle
19:03:29 <Viking-Ice> cmurf, and what do you think happens when we push it via update
19:03:47 <adamw> Viking-Ice: at least in that case you can roll back to the release versions...
19:03:48 <Viking-Ice> it's better we test now and include at install time then push the update after GA release
19:03:48 <cmurf> marvin the martian blows up earth?
19:03:54 <adamw> and it gets to go through bodhi
19:04:00 <cmurf> at least we can revert, and it's not on ISOs
19:04:03 <kparal> #info there is an older systemd fix (which was reverted later) and a newer lvm build. the current approach is probably to use systemd fix in a release and push lvm build to updates
19:04:13 <jreznik> Viking-Ice: we don't have proper fix now, so...
19:04:30 <cmurf> no proper fix, not enough time to test, go-no/go is tomorrow, etc
19:04:30 <adamw> i would be in favour of sticking with the systemd workaround for final at this point, we have enough moving parts to try and sign off on release tomorrow
19:04:43 <Viking-Ice> jreznik, so what what we release like that, what are we canonical ?
19:04:55 <cmurf> this goose is squirming and squawking to lay her golden egg
19:05:17 <jreznik> adamw: I'm ok with that, we have both options in case of anything got busted more
19:05:33 <cmurf> copper egg maybe
19:05:55 <kparal> should we move on?
19:06:00 <Viking-Ice> why
19:06:03 <cmurf> yes
19:06:09 <adamw> Viking-Ice: what is there to add?
19:06:17 <Viking-Ice> pull in the right fix
19:06:23 <cmurf> there isn't one yet
19:06:38 <kparal> Viking-Ice: iiuic that is just a temporary fix anyway
19:06:58 <Viking-Ice> Fixed In Version|systemd-208-9.fc20          |lvm2-2.02.103-4.fc20
19:07:02 <jreznik> actually it should be easy to get right one, just it's touching more places and devs are not ok with it
19:07:06 <Viking-Ice> that's not the proper fix?
19:07:09 <jreznik> Viking-Ice: no
19:07:16 <kparal> not the proper-proper one :)
19:07:18 * adamw would be happier with clear information from the devs
19:07:30 <adamw> but in the absence of that, taking the path of changing less stuff seems appropriate
19:07:35 <jreznik> adamw: what's clear for you? I can look into my memory
19:07:52 <adamw> jreznik: clear call as to whether they think it's safer to take the systemd workaround or the current lvm2 'fix'
19:07:53 <cmurf> it sounds like a revert for systemd and then not updating lvm2 for release, and then both get updated after release
19:08:03 <adamw> cmurf: no, there's no reversion
19:08:24 <cmurf> sorry not revert, i meant the minor temp fix
19:08:25 <jreznik> adamw: for this, I really don't have answer, sorry :(
19:08:36 <adamw> jreznik: all i got when i asked was 'they should be equivalent', which doesn't help a lot
19:08:54 <Viking-Ice> equally broken I guess ;)
19:08:56 <cmurf> take the path of least resistance
19:08:56 <jreznik> that's my understanding
19:09:23 <adamw> right, in the absence of a particularly convincing reason to change course, i guess we'll just put systemd 208-9 in RC1.
19:09:35 * kparal nods and moves on
19:09:35 <adamw> if that blows up on us, viking-ice can say he told me so =)
19:09:45 <cmurf> i've been running it without issues for almost a week
19:09:50 <cmurf> 208-9 that is
19:09:53 <Viking-Ice> mostly worried about murphy fucking up the connected update
19:09:57 <Viking-Ice> after GA
19:10:00 <cmurf> actually it might need karma
19:10:14 <adamw> it's already pushed stable
19:10:22 <adamw> it's been a while since tc5, lots of stuff went stable since
19:10:23 <cmurf> oh nevermind then
19:10:25 <kparal> #topic (1038969) DeviceCreateError: ('lvcreate failed for fedora/swap: running lvm lvcreate -L 819m -n swap fedora failed', 'fedora-swap')
19:10:25 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1038969
19:10:25 <kparal> #info Accepted Blocker, python-blivet, POST
19:10:32 <adamw> i kept holding out for rc1 to do a new build, and it never quite happened...
19:10:33 <cmurf> oh ick this one
19:10:37 <Viking-Ice> there are all kinds ways where f update/upgrade go wrong
19:10:41 <greenlion> here I have a question...
19:10:58 <cmurf> looks like it's fixed?
19:11:06 <Viking-Ice> c16
19:11:07 <Viking-Ice> right
19:11:12 <kparal> #info seems to be fixed, more verification would be handy
19:11:13 <greenlion> in fix they also change semantics of how 'encrypted' checkbox does works
19:11:16 <Viking-Ice> mean 17
19:11:30 <greenlion> i.e. disallowing it on already encrypted container
19:11:34 <adamw> greenlion: that was actually a separate patch, but it looks sane to me.
19:11:44 <kparal> greenlion: I actually filed an RFE for it a few weeks back
19:11:53 <adamw> i don't mind that getting trojanned in, as it seems to only reduce the risk of borkiness.
19:12:03 <adamw> what could possibly go wrong
19:12:14 <greenlion> so it a separate feature and does it need FE?
19:12:27 <adamw> this is the point where we turn a blind eye.
19:12:33 <kparal> adamw: you memorized the whole set of forbidden QA phrases, right?
19:12:40 <Viking-Ice> container vs container
19:12:41 <adamw> kparal: they're pinned to my monitor
19:13:01 <greenlion> adamw, like ... upgrading from previous fedora release where that was possible
19:13:16 <Viking-Ice> that's a regression
19:13:20 <adamw> greenlion: shouldn't be relevant, they only patched *anaconda* behaviour
19:13:21 <greenlion> or managing/resizing partitions from previous installation
19:13:48 <adamw> oh, i see. still don't think it's going to make that any worse, but who the hell knows
19:13:50 <greenlion> ok, reinstalling on top of previous installation...
19:14:03 <greenlion> and opening luks :)
19:14:03 <adamw> i've got to talk to bcl after this meeting and try to straighten out what exactly we're putting in the next anaconda build
19:14:08 <cmurf> upgrading encrypted = fedup
19:14:10 <adamw> that's already scheduled
19:14:11 <kparal> it might have unintended consequences if you reinstall encrypted VG with encrypted LV
19:14:21 <kparal> but hey, it never worked properly anyway :)
19:14:24 <adamw> let's face it, chances are high that's already broken
19:14:25 <adamw> ...yeah :)
19:14:36 <adamw> feel free to go test it, if you like.
19:14:38 <cmurf> encrypted LV on encrypted PV should be disallowed
19:14:41 <greenlion> oh well
19:14:47 <cmurf> talk about a huge performance hit on non AES-NI hardware
19:14:47 <adamw> cmurf: that's what the patch we're discussing effectively does
19:15:00 <adamw> cmurf: the question is whether the change might make anaconda worse at handling *existing cases* of it
19:15:06 <adamw> and i'm currently attempting to care
19:15:10 <cmurf> haah
19:15:11 <adamw> ECAREFAIL
19:15:15 <cmurf> ok
19:15:17 <kparal> #topic (1035536) Final spin-kickstarts build required for Fedora 20 GA
19:15:17 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035536
19:15:17 <kparal> #info Accepted Blocker, spin-kickstarts, MODIFIED
19:15:19 <cmurf> yeah
19:15:37 <adamw> okay, we're on this one. we pushed the two desired s-k FE changes and bruno's building a new s-k.
19:15:37 <nirik> brunowolff is on it. ;)
19:15:51 <kparal> #info the new build needs karma
19:16:04 <kparal> oh, there will be a new one then?
19:16:07 <adamw> yes
19:16:08 <kparal> #undo
19:16:08 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xeff1910>
19:16:19 <kparal> #info there will be a new build soon and it will need testing and karma
19:16:23 <adamw> if we have everything right, RC1 will build from ce61f186bb2c5b6ba998c59434fac64a4b3dcb81
19:16:42 <adamw> the way to karma this would be simply to satisfy yourself the spin-kickstarts package matches that git commit from f20 branch of s-k git
19:16:56 <adamw> i have once caught a case where the build was done wrong, so, you know, do actually check it.
19:17:18 <adamw> (i usually install the s-k package, check out s-k git at the appropriate commit, and run some diffs.)
19:18:23 <kparal> do you want to discuss some specific accepted FEs?
19:18:41 <adamw> that's all the blockers?
19:18:43 <kparal> yes
19:19:00 <adamw> has anyone tested https://admin.fedoraproject.org/updates/FEDORA-2013-23185 ?
19:19:08 <adamw> the bug for it is accepted FE, but 0 karma scares me a bit
19:19:20 <adamw> other than that it's all anaconda stuff
19:19:23 <kparal> ============================================================
19:19:23 <kparal> Accepted Freeze Exceptions
19:19:23 <kparal> ============================================================
19:19:34 <Viking-Ice> Add a comment >>
19:19:34 <Viking-Ice> Bodhi Version: 0.9.7.4 -- Server: app01
19:19:34 <Viking-Ice> Copyright © 2007-2011 Red Hat, Inc. and others.
19:19:34 <Viking-Ice> Licensed under the GNU General Public License v2 or later.
19:19:35 <Viking-Ice> The Fedora Project is maintained and driven by the community and sponsored by Red Hat.
19:19:35 <Viking-Ice> This is a community maintained site. Red Hat is not responsible for content.
19:19:37 <Viking-Ice> [ Legal, Trademark Guidelines, Source Code ]
19:19:40 <Viking-Ice> that kinda narrows it down
19:19:42 <kparal> #info https://admin.fedoraproject.org/updates/FEDORA-2013-23185 needs testing
19:19:47 <Viking-Ice> frack copy paste fail
19:19:57 <adamw> as in, within the next hour or two...
19:20:11 <kparal> I don't have bluetooth to test with
19:20:14 * roshi has nothing with bt
19:20:41 * jreznik is looking
19:21:04 <kparal> heh, I could try to connect two laptops. is it supported? :)
19:21:19 <adamw> oh hai, found another resize crasher
19:21:23 <adamw> this shit really just doesn't work...
19:21:31 <kparal> adamw: reproducible?
19:21:32 <adamw> kparal: you could at least pair them, i think
19:21:45 <jreznik> I'm going to try it, give me a sec
19:21:46 <adamw> kparal: dunno, it's the weird-500MB-partition test with the latest updates.img, try and resize it to smallest possible size
19:21:58 <greenlion> adamw, disable resize at all?)
19:21:58 <kparal> :/
19:22:09 <Viking-Ice> adamw, right let's ship with completely failed resizing in the installer
19:22:15 <Viking-Ice> which adds way to much to /
19:22:21 <Viking-Ice> of people hd
19:22:24 <Viking-Ice> sizes
19:22:44 <adamw> Viking-Ice: we've done it for two releases, why stop now?!
19:22:46 <cmurf> no, disable Manual Partitioning, then ship
19:22:54 <adamw> cmurf: this one's in Reclaim Space
19:23:06 <cmurf> oops
19:23:16 <Viking-Ice> and the resize plot thickens
19:23:30 <cmurf> well i'm increasingly opposed to resize
19:23:46 <cmurf> anaconda says it can shrink things it doesn't know can be shrunk
19:23:48 <Viking-Ice> yes yes we all know that let's just kill anaconda
19:23:56 <Viking-Ice> no more bugs and endless time for QA ;)
19:23:56 <cmurf> if it's an unrecognized format, it assumes it can shrink it
19:23:58 <cmurf> which seems bad
19:24:17 <jreznik> seems like bluez is still crashing...
19:24:18 <adamw> everyone hates resize, everyone hates us more if we drop it
19:24:19 <cmurf> it should only offer resize UI when the resize can be assured data will be retained
19:24:34 <adamw> that's basically impossible
19:24:45 <adamw> we can't guarantee the output of whatever tool we call to do the resize
19:24:48 <adamw> anyhow
19:24:48 <Viking-Ice> bluez singing the blues
19:25:10 <jreznik> heh, no - bad bluez
19:25:21 <cmurf> that's not what i mean, i mean even offering the ui in the installer when it has no idea what it's looking at
19:25:36 <cmurf> some bug in an underlying tool is a different matter
19:26:10 <kparal> adamw: I reproduced your crash
19:26:21 * adamw talking to anaconda bout it
19:26:27 <kparal> #topic Open Floor
19:26:33 <adamw> cmurf: sure
19:26:51 <adamw> Viking-Ice: hey, this 'fuck anaconda' approach sure is liberating, isn't it :)
19:26:53 <Viking-Ice> cmurf, anaconda used to show end users if they had two hard disk the wwid of the disk not master or slave so people had 50%/50% chances of wiping their backup drive if the drive was of same manufactorer or model
19:27:02 <cmurf> not ok
19:27:04 <Viking-Ice> that's anaconda ui design for you
19:27:05 <adamw> yeah, we've sucked for years
19:27:21 <adamw> and the old dialog about 'hey, we don't understand what's on this disk, would you like us to delete it?' worded as confusingly as possible
19:27:27 <adamw> that was mizmo's favourite
19:27:35 <cmurf> e.g. i have a bug, not blocker because there's no data loss, where the UI shows that encrypted Apple Core Storage partitions are resizable
19:27:43 <Viking-Ice> well we need to do something about the anaconda it's development cycle is not panning out for us
19:27:46 <cmurf> and it's because the underlying format isn't known
19:28:01 <cmurf> unknown format = no format = resizable
19:28:10 <cmurf> not good logic IMO
19:28:37 <Viking-Ice> I think we should just keep will drunk and move to the next level with fedup no more installing ;)
19:28:39 <cmurf> only recognized formats should have UI for resize. if it's not recognized, then the user must be required to delete and recreate only, not resize
19:29:05 <cmurf> Viking-Ice: good idea
19:29:21 * cmurf buys first round
19:29:44 <Viking-Ice> cmurf, you need to go in the woods for that proper moonshine
19:29:50 <Viking-Ice> cant get it in a bar
19:30:02 <kparal> so, anything else to discuss?
19:30:13 <cmurf> are we done with the lists?
19:30:17 <kparal> it seems that adamw tries to forget about 1040650
19:30:21 <kparal> yes, we're done
19:30:34 <cmurf> he's chatting to anaconda team i think still
19:30:42 <kparal> yes
19:30:46 <Viking-Ice> <sigh> off meeting chatting
19:30:48 <Viking-Ice> no no
19:31:03 <cmurf> so lets just get a summary from that for the record then we're done
19:31:09 <kparal> <adamw> let's just pretend it never happened
19:31:12 <kparal> let's have it on record
19:31:16 <kparal> so that we can fire him later
19:31:28 <cmurf> i think he needs sugar
19:31:30 <adamw> I DENY EVERYTHING
19:31:31 <Viking-Ice> fire-ing him is letting him off easy
19:31:42 <Viking-Ice> triage transifex for 5 cycles
19:31:47 <Viking-Ice> now that's proper punishment
19:31:47 <adamw> can you prove i haven't been hacked by the NSA?
19:31:57 <Viking-Ice> penetrated by the nsa no
19:31:57 <cmurf> adamw: yes
19:32:05 <roshi> can't prove that you aren't them either
19:32:17 <adamw> cmurf: go ahead!
19:32:19 <kparal> ok guys, thanks for coming
19:32:36 <adamw> cmurf: pay no attention to the drones circling above your home.
19:32:38 * kparal detonates this meeting in a minute
19:32:42 <Viking-Ice> are we still forgetting about that bug
19:32:51 <adamw> Viking-Ice: well, i'm not proposing it as anything.
19:33:15 <Viking-Ice> why not
19:33:21 <cmurf> adamw: i'm just being goofy, obviously we have all been hacked because to do what they say their mandate is, they have to know everything in order to prevent nothing. something like that.
19:33:22 <roshi> so could we get around blockers by just not proposing them?
19:33:32 * roshi thinks maybe we could use that in the future :P
19:33:35 <Viking-Ice> apparently so
19:33:54 <Viking-Ice> Well I'm proposing it as a blocker then
19:33:55 <cmurf> roshi: that's my policy after beta ;-)
19:34:13 <roshi> lol
19:34:20 <kparal> we should probably discuss that
19:34:30 <adamw> sigh. fine.
19:34:43 <jreznik> so with bluedevil, it no longer crashes but I'm unable to pair
19:34:51 <kparal> #topic 1040650 - ValueError: invalid target size request
19:34:58 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1040650
19:35:20 <adamw> so if i'm still clinging to my quality hat, i guess it's kinda hard to -1 this
19:35:26 <Viking-Ice> right
19:35:26 <kparal> it seems we can no longer shrink to minimal size with the patch
19:35:32 <adamw> it's a resize request. anaconda doesn't try it properly.
19:35:38 <adamw> kparal: no, it's broken without the patch too.
19:35:55 <kparal> adamw: just for this 'weird' partition or for any?
19:35:58 <adamw> if we fix it on top of the patch, it actually ought to be safer than without the patch
19:36:03 <adamw> kparal: not sure about the non-patch case
19:36:11 <kparal> I think with this patch it will crash on any
19:36:17 <adamw> the patch case will be broken almost always, i think, because it rounds the min size down
19:36:20 <kparal> shrunk to minimal size
19:36:27 <kparal> yes
19:36:28 <adamw> but we may be able to fix it
19:36:40 <cmurf> which is the worse behavior, with or without the patch?
19:36:41 <kparal> yes, if we at least +1 FE it
19:36:43 <roshi> shouldn't we default to roundin gup?
19:36:53 <Viking-Ice> "Proposing as a final blocker, per beta criterion: ""Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing.", with resize issues acceptable as Final blocker."
19:36:57 <roshi> that would ensure you never try to over-allocate
19:37:06 <Viking-Ice> it violates that blocking criteria right
19:37:10 <greenlion> looks like +1 blocker for 1040650
19:37:21 <roshi> make sense to me
19:37:28 <Viking-Ice> +1 blocker
19:37:30 <cmurf> gray area
19:37:36 <cmurf> is it actualy invalid?
19:37:43 <nirik> adamw: why did you go and test more... silly person! :)
19:37:45 <Viking-Ice> cmurf, what's gray about it violating the criteria
19:37:46 <cmurf> or is the installer UI fussy?
19:37:51 <kparal> cmurf: it shrinks to smaller size than supported
19:38:02 <kparal> it rounds down the size
19:38:04 <Viking-Ice> and then crashes
19:38:05 <cmurf> so the UI is allowing an invalid size
19:38:11 <cmurf> then the installer crashes
19:38:19 <nirik> ugly.
19:38:27 <cmurf> do i have that correct?
19:38:27 <roshi> size should always round up
19:38:39 <nirik> so, it should let you resize to 1MB?
19:38:52 <greenlion> roshi, then you will have something oversize...
19:39:02 <kparal> nirik: to whatever the filesystem supports
19:39:04 <cmurf> roshi: maybe on shrink it should, but not catagorically because we've had bugs where it rounds up LV's and then they're too big for the space left in a VG and we get a crash
19:39:05 <kparal> there are always some metadata
19:39:24 <kparal> resize2fs can actually tell you that
19:39:32 <roshi> if it rounds up, then it would throw an error saying there wasn't enough space, right?
19:39:34 <roshi> oh
19:39:50 <cmurf> the file system guys are all a bit skeptical of resizing too  you know
19:39:52 <greenlion> resize should be like bounded to fs min/max size
19:39:54 * roshi was thinking all perfect-world and whatnot
19:39:55 <kparal> <dlehman> min size should always round up. max size should always round down. that should be fairly safe.
19:39:55 <nirik> in reality anyone doing this would just re-run and not be so silly? or is there some valid case for 'super small partition' ?
19:40:16 <cmurf> kparal dlehman: that's a good policy
19:40:26 <kparal> nirik: but he won't know the cause
19:40:56 <kparal> it's not like the error message is super descriptive
19:40:56 <cmurf> nirik: no and i think one could argue less than 500MB might be a bad idea to the point it's a bug in resize2fs
19:40:59 <cmurf> or any resizer
19:41:05 <nirik> I suppose, unless they report the crash and look at the bug.
19:41:11 * greenlion wonders why anaconda reuses gparted or gnome-disks code for doing such things...
19:41:17 <greenlion> not reuses*
19:41:29 <cmurf> greenlion: it uses pyparted which uses parted which is what gparted uses
19:41:35 <cmurf> hence gparted
19:41:40 <cmurf> graphical parted
19:42:02 <cmurf> i don't know what gnome-disks is using off hand
19:42:03 <kparal> are we mostly +1?
19:42:08 <greenlion> but console parted does not allow resize currently, or does it?
19:42:15 <nirik> well, I'm definitely +1FE... blocker, not sure... it seems an odd case again... not something most people would do, or if they did they would rerun and not do that again.
19:42:20 <Viking-Ice> kparal, I would think so it's odd to be -1 on this one
19:42:23 <cmurf> +1 FE
19:42:35 <Viking-Ice> ficures
19:42:48 * jreznik is with nirik
19:42:58 <kparal> the crash occurs during installation
19:43:07 <kparal> so some partitions may already be wiped
19:43:17 <kparal> just saying
19:43:19 <Viking-Ice> seriously guys if that's the attitude with blocker bug we should just stop doing these meetings
19:43:20 <cmurf> it's very obviously violating the criteria so it ought to be a blocker based on the criteria text HOWEVER
19:43:32 <nirik> but they were going to be anyhow, since they were, you know, planning to install?
19:43:33 <Viking-Ice> if the plan is to push the release out the door no matter what
19:43:42 <kparal> I'm +1
19:43:44 <cmurf> Viking-Ice: at a certain point yes
19:43:55 <cmurf> short of explosions
19:43:58 <nirik> that is not my "plan". I am just discussing each bug as I feel. Feel free to disagree with me.
19:44:05 <kparal> adamw: do we still have you?
19:44:14 <adamw> sorry, was chatting with someone else
19:44:33 <cmurf> this is still bug 1040650?
19:44:34 <kparal> we need some votes
19:44:37 <kparal> cmurf: yes
19:44:39 <cmurf> it's scrolled way up off the screen
19:45:05 <adamw> i find it hard to be -1 on this unless anaconda tell us it's structurally impossible to fix reasonably
19:45:11 <cmurf> strictly speaking we ought to be +1 blocker on the merits, but realistically +1 FE is more practical because this is sort of an edge case to click shrink and then slide it all the way down to minimum
19:45:16 <cmurf> esp when minimum is what, 15MB?
19:45:18 <cmurf> that's just nuts
19:45:23 <Viking-Ice> <sigh>
19:45:29 <roshi> +1
19:45:32 <kparal> actually, doesn't this affect 50% full partitions?
19:45:42 <kparal> 20GB partitions, 10GB occupied
19:45:45 <cmurf> oh shiitake
19:45:49 <Viking-Ice> yes
19:45:51 <kparal> shrink to minimum, i.e. to 10GB
19:45:59 <cmurf> ok
19:46:00 <kparal> and it will crash
19:46:03 <cmurf> wel then that's a +1 blocker
19:46:08 <Viking-Ice> thank you!
19:46:12 <kparal> since it's going to be a half megabyte under the limit
19:46:15 <nirik> that wasn't clear from the bug to me at least
19:46:21 <cmurf> me neither
19:46:28 <kparal> I'm just assuming
19:46:30 <cmurf> i thought we were talking about ridiculously small shrinks
19:46:33 <kparal> it's rounding down, always
19:46:36 <cmurf> got it
19:46:41 <kparal> but it seems logical
19:46:45 <nirik> it would be good to know that for sure.
19:46:46 <nirik> :)
19:46:47 <cmurf> yes
19:46:51 <adamw> yeah, i don't think the size of the disk being resized or the minimum size itself actually matters, the rounding's the issue
19:46:56 <nirik> but if thats the case I would be +1
19:47:02 <cmurf> exactly knowing matters
19:47:12 <kparal> should I test? I can do it in 3 minutes
19:47:16 <adamw> resizing to absolute minimum seems like it's unusual as it means you can't put anything more on the resize partition (in which case why are you keeping it?), but i'm sure someone has a plausible reason for it
19:47:18 <cmurf> yes sir that would be great
19:47:19 <adamw> kparal: yeah, might be nice
19:47:23 <nirik> sure.
19:47:25 <adamw> remember to use the updates image
19:47:39 <greenlion> and "weird" partition size
19:47:41 <cmurf> adamw: yeah i think it practically makes teh resized volume useless or nearly so
19:47:41 * nirik turns on the elevator music.
19:47:47 <cmurf> muzak!
19:48:16 <Viking-Ice> adamw, I dont think it's unusual you look at what the installer says is the minimum rezisie option and resize to that
19:48:40 <cmurf> i don't know about that
19:48:46 <adamw> Viking-Ice: but then what do you do with that volume? it's only really useful if you want to keep it around for reference but never ever put any more data on it
19:48:51 <cmurf> but then i'm skeptical of resizes
19:48:51 <adamw> which i guess happens, but isn't terribly common
19:48:56 <adamw> still, i'm still +1 at this point
19:49:05 <Viking-Ice> that's +4 -3
19:49:08 <Viking-Ice> for blocker
19:49:19 <cmurf> i'm +1 contingent on any minimum amount set causing a crash
19:49:39 <Viking-Ice> so let's accept it then as a blocker and move on
19:49:48 <cmurf> we have nothing else
19:49:52 <Viking-Ice> or rather #end-meeting
19:49:53 * greenlion still +1 for blocker
19:49:55 <cmurf> waiting for kparal
19:50:11 <Viking-Ice> to do what exactly
19:50:26 <adamw> he's checking it affects other scenarios
19:50:28 <cmurf> if it doesn't crash on minimum when minimum is ~1GB
19:50:33 <roshi> there are some contingent votes
19:50:40 <kparal> in the reclaim dialog, the minimum displayed is 359.7MB, but I can drag the slider only to 360MB
19:50:45 <Viking-Ice> only 2 by my account
19:50:45 <cmurf> if it only crashes on ridiciulously small minimums, pff i'll be -1/+1
19:50:53 <adamw> let's try a few different cases
19:50:58 <kparal> and resizing worked well
19:51:03 <cmurf> so no crash?
19:51:09 <kparal> not this time
19:51:17 <cmurf> ok so we have an x factor here
19:51:23 <roshi> want to vote conditional blocker if it can be reproduced for minimums < 1GB?
19:51:30 <Viking-Ice> and here we go again...
19:51:31 <cmurf> good idea
19:51:41 <cmurf> except >
19:51:43 <cmurf> not <
19:52:00 <cmurf> if crash greater than 1GB, then block
19:52:02 <roshi> +1 FE if it is less than 1GB +1 Blocker if greater?
19:52:08 <cmurf> right
19:52:10 <roshi> details cmurf, details
19:52:16 <cmurf> and i'm open to the amount
19:52:22 <cmurf> 500MB might be reasonable ??
19:52:25 <roshi> I think that's a reasonable compromise
19:52:27 <cmurf> but not less than that
19:52:27 <Viking-Ice> I'm +1 blocker regardless
19:52:38 * greenlion is with Viking-Ice
19:52:52 <kparal> I don't think that partition sizes matter. I think it matters whether this happens with not-just-empty partitions, resized to minimum
19:52:56 <Viking-Ice> we had +4 vs +3 earlier
19:53:00 <roshi> I lean +1 on it
19:53:08 <Viking-Ice> mean +4 vs -3 earlier
19:53:19 * roshi was just trying to come to some sort of actionable compromise
19:53:44 <Viking-Ice> kparal, what's your vote
19:53:54 <kparal> +1
19:54:03 <cmurf> i think there are enough votes for blocking then no matter what
19:54:04 <Viking-Ice> there we have it
19:54:12 <Viking-Ice> time for accept and end
19:54:15 <cmurf> yep
19:54:16 <roshi> yep
19:54:37 <kparal> a sec
19:55:00 <cmurf> just realize there's almost no chance of this getting fixed by go/no-go
19:55:04 * Viking-Ice goes dancing with nirik elevator music
19:55:11 <roshi> yeah
19:55:18 <roshi> but what can you do?
19:55:21 <cmurf> right
19:55:27 <kparal> tried once again, it worked again. with non-empty partitions it seems to work OK
19:55:30 <cmurf> wel the blocker board has to be cleared to get an RC right?
19:55:33 <kparal> but we can't be sure
19:55:36 <roshi> yeh
19:55:40 <jreznik> cmurf: yep
19:55:42 <roshi> it does cmurf
19:55:50 <nirik> so, it's only on empty partitions?
19:55:52 <cmurf> i really think the conditional blocker should be considered but…
19:56:09 <Viking-Ice> the votes are already in
19:56:11 <cmurf> i know
19:56:17 <cmurf> i like to argue i'm contrary
19:56:26 * nirik wonders why everyone is in such a hurry. :(
19:56:32 <adamw> cmurf: accepted blockers have to be addressed
19:56:52 <Viking-Ice> shit happens with anaconda is more then everything else apparently
19:57:03 <cmurf> adamw: and we need an RC before go/no-go
19:57:08 <adamw> yes
19:57:10 <kparal> proposed #agreed 1040650 - AcceptedBlocker - We're worried that this happens not only for empty partitions, but also for somewhat filled parttions shrunk to minimal size, which violates "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." If the developers are certain this is not true, the status can be re-evaluated.
19:57:13 <Viking-Ice> ack
19:57:16 <cmurf> how much lee way on RC testing do we have for a go?
19:57:19 <adamw> ack
19:57:19 <kparal> Viking-Ice: couldn't have read that
19:57:21 <cmurf> ack
19:57:28 <nirik> ok, ack
19:57:29 <adamw> kparal: can you play with it some more while i try and pull together a patch set?
19:57:35 <Viking-Ice> kparal, what do you mean ?
19:57:35 <kparal> adamw: sure
19:57:43 <kparal> Viking-Ice: you were too fast
19:57:43 <greenlion> ack
19:57:46 <Viking-Ice> <kparal> proposed #agreed 1040650 - AcceptedBlocker - We're worried that this happens not only for empty partitions, but also for somewhat filled parttions shrunk to minimal size, which violates "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." If the developers are certain this is not true, the status can be re-evaluated.
19:57:46 <Viking-Ice> <Viking-Ice> ack
19:57:47 <nirik> cmurf: lee way in what sense?
19:57:53 <adamw> cmurf: we need to get as much done as possible esp. in the installer matrix, rc1 is quite different from tc5
19:57:56 <jreznik> ack
19:57:58 <kparal> #agreed 1040650 - AcceptedBlocker - We're worried that this happens not only for empty partitions, but also for somewhat filled parttions shrunk to minimal size, which violates "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." If the developers are certain this is not true, the status can be re-evaluated.
19:58:00 <Viking-Ice> kparal, or your latency to slow
19:58:05 <cmurf> kparal: he read "acceptedblocker" only haha
19:58:11 <kparal> I know
19:58:15 <kparal> :)
19:58:42 <cmurf> nirk adamw: i understand i mean go/no-go is tomorrow about midday so at what time must an RC appear by for a go to happen?
19:58:52 <adamw> jreznik: for my reference, do we have any chance to do a one-day slip for final or is it 'tomorrow's meeting or bust'?
19:58:52 <greenlion> probably need to remove 1021749 from blocker tracker?
19:59:05 <adamw> cmurf: asap. i'm going to try and get one built asap.
19:59:09 <cmurf> adamw: that's my question
19:59:24 <cmurf> do we have a one day slip possibility
19:59:30 <adamw> greenlion: it's intentionally in undetermined state.
19:59:36 <greenlion> ah, ok
19:59:48 <jreznik> adamw: in case we would be in somehow shipable state, I'd be ok with repeated Fri Go/No-Go
19:59:56 <jreznik> and I expect nirik and dgilmore would be too
19:59:58 <kparal> I received AVC on install, that's a blocker :)
20:00:14 <Viking-Ice> <sigh> that's autoblocker
20:00:21 <adamw> someone please tape kparal to the wall
20:00:26 <Viking-Ice> both of you
20:00:28 <cmurf> so yeah i have a bunch of avc messages also on every install i idn't realize that was blocking
20:00:31 <adamw> oh
20:00:31 <jreznik> kparal: you're not suppose to touch installer!
20:00:42 <cmurf> but the installs succeed so...
20:00:45 <adamw> if this is in the DVD and you don't get a popup noptification we're fine
20:00:46 <jreznik> so bust? see you in Jan? :)
20:00:55 <adamw> it's only things that produce a visible notification we care about
20:01:00 <cmurf> got it
20:01:16 <greenlion> kparal, test it on live!
20:01:21 <adamw> TAPE TAPE TAPE
20:01:27 <Viking-Ice> adamw, I guess that depends on what exactly triggers the avc
20:01:32 <cmurf> stick a finger in it!
20:01:43 <adamw> Viking-Ice: anaconda isn't remotely selinux safe, we've known that for years
20:01:50 <adamw> that's why selinux is set permissive while anaconda's running
20:02:02 <kparal> it was on live
20:02:07 <kparal> selinux is just on live
20:02:12 <Viking-Ice> adamw, oh I just knew anaconda isn't remotely safe for anything
20:02:15 <adamw> kparal: did you actually get an AVC popup?
20:02:15 <Viking-Ice> lol
20:02:18 <kparal> adamw: yes
20:02:22 <adamw> sigh. doing what?
20:02:29 <kparal> nothing, finishing installation
20:02:33 <cmurf> mmmm selinux must be on DVD also in order to set the labels correctly during install
20:02:40 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=1040444
20:02:44 <kparal> what a lovely bug number
20:02:48 <cmurf> cosmic ray
20:02:51 <cmurf> transient
20:02:56 <Viking-Ice> I've seen sexier numbers
20:02:57 <cmurf> just look away son
20:03:11 <kparal> seem I'm not the only one
20:03:25 <kparal> might be the updates.img used
20:03:43 <kparal> jsedlak also used it today, even though I don't know whether for that installation
20:04:00 <greenlion> kparal, did you change hostname in network config during that?
20:04:05 <kparal> greenlion: no
20:04:11 <adamw> is it reproducible?
20:04:15 <kparal> it's the "after installation" phase
20:04:25 <cmurf> hmm
20:04:31 <Viking-Ice> adamw, 2 have hit it so far so I would say yes
20:04:39 * adamw tests
20:04:55 <nirik> huh, but only today?
20:04:59 <jreznik> but why it happened today? maybe it's really connected to updates.img
20:05:00 <cmurf> 2 is not a scientific sample
20:05:03 <adamw> the 'possible duplicate' is from f19 last month
20:05:42 <kparal> don't create a user during the installation, I didn't do that
20:05:53 <kparal> maybe it is related
20:06:02 <kparal> just when anaconda waits for it
20:06:04 <cmurf> i will try this with the updates img and live and try to break it
20:06:09 <cmurf> i emit cosmic rays
20:06:30 <kparal> we're over time limit today, but I guess this time it is allowed
20:06:33 <cmurf> but first i have to get a hair cut
20:06:40 * jreznik has to run now, moving IRC to the phone
20:06:44 <cmurf> i'll report on #fedora-qa
20:06:47 * greenlion guesses it depends on moon phase
20:08:56 <adamw> well, shit, i see it too. what the freaking fuck.
20:09:07 <kparal> adamw: have you used the updates.img?
20:09:09 <adamw> yeah
20:09:11 <adamw> trying without
20:09:18 <kparal> I didn't and I don't see it
20:09:18 <cmurf> it def does not happen without
20:09:26 <kparal> so it's the updates.img
20:09:30 <Viking-Ice> so 3 have seen it
20:09:39 <cmurf> awooga dan walsh
20:09:42 <kparal> it might not happen when the patches are included
20:09:50 <kparal> maybe this always happens if you use any updates.img
20:09:51 <cmurf> or undo the patch
20:10:01 <Viking-Ice> it's calling hostname
20:10:02 <cmurf> kparal oh crap don't say that out loud!
20:11:40 <roshi> or type it in silence!
20:12:13 <nirik> which updates.img are you using?
20:12:27 <cmurf> http://vpodzime.fedorapeople.org/f20_blockers_updates.img
20:12:45 <cmurf> i've used quite a few updates images and they weren't causing avc denials
20:12:53 <adamw> oh, 'happens when you use an updates.img' sounds plausible, since it affects network stuff..
20:13:01 <cmurf> but i don't think i've used an updates.img since systemd 208-8 came out
20:13:21 <adamw> kparal: you could try running an install with one of the smaller updates.img's i built last night and posted in various bugs?
20:13:43 <kparal> adamw: can you give me a link?
20:13:50 <cmurf> kparal: default install triggers this?
20:13:59 <kparal> cmurf: Live default
20:14:13 <Viking-Ice> so it's an blocker let's accept it and move on
20:14:23 <adamw> kparal: /var/www/html/extras/updates-1040012.img maybe
20:14:31 <adamw> Viking-Ice: not if it only happens if you use an updates.img
20:14:37 <adamw> bit hard to be sure about that, though
20:14:48 <Viking-Ice> Let Dan  take care of it
20:15:24 <jreznik> so accept it conditionally - if it happens without updates.img -> blocker?
20:15:24 <Viking-Ice> we can un-blocking it's ones in a full moon when very one sock and a boot on your left foot kind of thing
20:16:01 <adamw> conditional accept sounds ok to me
20:16:04 <nirik> we could close out this meeting I guess and vote in bug as more info shows up... or wait.
20:16:20 <adamw> well
20:16:26 <adamw> actually, can we punt, for procedural reasons?
20:16:36 <cmurf> yes
20:16:36 <adamw> the best way to check if it happens without an updates.img or not is just to build RC1 and see
20:16:44 <adamw> but if it's accepted as a blocker, technically, i can't do that
20:16:51 <cmurf> true
20:16:59 <adamw> so it works best to leave it proposed and set it accepted if we build RC1 and it turns out to affect it
20:17:04 <Viking-Ice> well we need to file it as an blocker and punt
20:17:14 <adamw> yeah, propose as a blocker and punt seems the best approach
20:17:15 <Viking-Ice> ( so we keep it on the radar )
20:17:19 <jreznik> yep
20:17:37 <adamw> actually maybe i can do a smoke test live with the new anaconda when it's built and we check with that
20:17:37 <kparal> adamw: that is not a link. can't google that file
20:17:45 <adamw> kparal: oh haha, forgot to edit
20:17:55 <cmurf> adamw: yeah that's faster to just do a smoke test live
20:17:55 <adamw> http://www.happyassassin.net/extras/updates-1040012.img
20:18:17 * jreznik thinks everyone here would have a nice yaks farm soon :)
20:18:27 <cmurf> i found two
20:18:41 <Viking-Ice> this release cycle has been sunshine and rainbows compared to F18
20:19:03 <cmurf> true
20:19:11 <cmurf> almost to post-install
20:19:45 <jreznik> Viking-Ice: after F19 it looks like F18 again, we just forgot real F18
20:19:57 <adamw> Viking-Ice: hah, triaging transifex is sunshine and rainbows compared to f18
20:20:21 <kparal> adamw: testing
20:20:50 <Viking-Ice> sooo are we getting closer to end-meeting or does someone else have something up his sleeve
20:20:54 <adamw> confirming kparal's results so far, happens with the updates.img, not with tc5 and no updates.img
20:21:10 <cmurf> which updates.img
20:21:12 <cmurf> any?
20:21:14 <greenlion> just punt it :)
20:21:27 <cmurf> or just vpodzime's?
20:21:32 <Viking-Ice> avc are autoblockers and if the root cause is found...
20:21:49 <greenlion> Viking-Ice, avc with updates.img is not, I guess
20:22:00 <adamw> cmurf: so far i only tried vpodzime's, kparal is trying another
20:22:22 <Viking-Ice> Dan probably has fixed this since we have started discussing he has 6th sense about these things
20:22:33 <Viking-Ice> greenlion, network install/updated install
20:22:42 <adamw> Viking-Ice: it's an autoblocker if it always happens, i'm fine wiht -1 if it only happens when using an updates.img on live.
20:22:43 <Viking-Ice> are affected right
20:22:47 <cmurf> well it also implicates systemd and are we not going to have 208-9 in RC1?
20:22:52 <nirik> "Notifications that only happen on unusual configurations are excluded"
20:22:54 <greenlion> and if it will be confirmed on RC1 it could be auto-blocked on its own without meeting, I think
20:22:58 <adamw> yeah, rc1 would be 208-9
20:23:03 <adamw> greenlion: indeed
20:23:06 <Viking-Ice> adamw, what are the usecases for updates.img on live
20:23:07 <cmurf> roll a smoke
20:23:26 <adamw> Viking-Ice: same as updates.img anywhere, but since this is a 'polish criterion' as long as the install still works it doesn't seem like an issue
20:23:27 <Viking-Ice> and how common are they ( do we think )
20:23:46 <adamw> not that common, you only use updates.img if you need to get something fixed, and at that point we probably already lost from a 'polish' perspective
20:23:53 <Viking-Ice> kik
20:23:54 <Viking-Ice> lol
20:23:55 <cmurf> with vpodzime's udpates.img i get the avc notification as well on live
20:23:57 <adamw> (since you found a bug and had to be directed to an updates.img , most likely)
20:23:59 <cmurf> without it i don't
20:24:05 <cmurf> it occurs when the initramfs is being generated
20:24:19 <adamw> cmurf: the thing we're testing now is if some *other* updates.img causes it, to try and determine whether it's the changes in the updates.img causing it, or just the fact of using one
20:24:20 <greenlion> probably extracting update.img messes up with selinux labels?
20:24:40 <cmurf> adamw: i know, i'm just behind
20:24:51 <Viking-Ice> so we are back at punt?
20:25:10 <cmurf> it is not an autoblocker but propose as blocker to track and then punt
20:25:24 <cmurf> need to see if another updates.img causes it
20:25:32 <Viking-Ice> every time we go in circles a kitten dies and someones beer goes flat
20:25:38 * greenlion is with cmurf
20:25:40 <Viking-Ice> and I hate drinking flat beer
20:25:52 <greenlion> cmurf, try empty?
20:26:01 <cmurf> what is the native language that phrase is said in?
20:26:02 <adamw> just #info what we agreed already and let's go
20:26:09 <Viking-Ice> right
20:26:22 <cmurf> kthxkbai
20:27:30 <kparal> adamw: no avc with your updates.img
20:27:37 <kparal> which is kinda bad news
20:27:43 <kparal> I guess
20:28:15 <greenlion> kde 'heisenbug' was 'fixed', right?
20:28:29 <Viking-Ice> must hang on for #info and #end-meeting
20:28:36 <roshi> lol
20:28:36 <adamw> kde bug, yeah
20:28:43 <adamw> kparal: oh dear, yeah, that is bad news
20:28:54 <adamw> so what of the changes in that updates.img could possibly be causing this? it seems odd
20:29:07 <Viking-Ice> punt and figure otu
20:29:10 <roshi> so, #ndmeeting and discuss in #fedora-qa?
20:29:11 <Viking-Ice> think all flat beer
20:29:13 <adamw> sure
20:29:16 <kparal> #endmeeting