15:59:17 <roshi> #startmeeting F21-blocker-review
15:59:18 <zodbot> Meeting started Wed Sep 24 15:59:17 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:18 <roshi> #meetingname F21-blocker-review
15:59:18 <zodbot> The meeting name has been set to 'f21-blocker-review'
15:59:18 <roshi> #topic Roll Call
15:59:26 <roshi> who's around for some blockery goodness?
15:59:36 * pschindl is here
15:59:47 * satellit listening
16:00:02 * jskladan lurks
16:00:18 * kparal is here
16:00:24 * tflink is around
16:00:36 <roshi> adamw you around?
16:00:44 <roshi> danofsatx-work might be busy
16:00:58 <roshi> #chair pschindl satellit jskladan kparal tflink
16:00:58 <zodbot> Current chairs: jskladan kparal pschindl roshi satellit tflink
16:01:23 <roshi> #topic Introduction
16:01:23 <roshi> Why are we here?
16:01:23 <roshi> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:01:27 <roshi> #info We'll be following the process outlined at:
16:01:29 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:01:32 <roshi> #info The bugs up for review today are available at:
16:01:34 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:01:37 <roshi> #info The criteria for release blocking bugs can be found at:
16:01:40 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
16:01:42 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
16:01:45 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria
16:01:52 <roshi> well, we've got 26 proposed blockers today :)
16:01:58 <jskladan> yaay
16:01:59 <roshi> everyone have their coffee handy?
16:02:22 <mattdm> hey everyone -- I know that's a lot of blockers, but if we could get one QA person to look at bash update for f19 as _higher_ priority... that'd be awesome
16:02:32 <danofsatx-work> somewhat here
16:02:33 <mattdm> https://admin.fedoraproject.org/updates/bash-4.2.47-2.fc19
16:03:46 * roshi pulls out his f19 machine
16:04:12 <roshi> alright, first blocker
16:04:14 <roshi> #topic (1114786) DeviceError: ('cannot replace active format', 'sda6')
16:04:17 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1114786
16:04:18 * jreznik has meeting conflict... again
16:04:20 <roshi> #info Proposed Blocker, anaconda, NEW
16:04:57 <adamw> ahoyhoy
16:05:01 <adamw> sorry, was getting coffee
16:05:12 <kparal> it should be possible to remove the swap partition
16:05:19 <kparal> I think it used to work
16:06:25 * kparal reads the rest of the comments
16:06:34 <roshi> reading comments as well
16:06:44 <adamw> the early stuff on this bug is completely incorrect, note
16:06:45 * roshi didn't get a chance to go through all the bugs before the meeting
16:06:53 <adamw> read to the end :)
16:07:04 <adamw> what i note in the last comment *may* be what's happening, but it's not entirely clear yet.
16:10:39 <roshi> +1
16:10:56 * bitlord just to say hello, I proposed one beta blocker, I'll wait it to come on topic
16:11:27 <roshi> sounds good bitlord
16:11:29 <kparal> whatever the root cause is, I think it used to work in the past, and we need to fix it. now the only question is whether we consider it a beta blocker
16:11:30 <pschindl> I'm +1. When using the guided partitioning flow, the installer must be able to: Remove existing storage volumes to free up space, at the user's direction
16:11:45 <adamw> "When using the custom partitioning flow, the installer must be able to: Assign mount points to existing storage volumes."
16:11:49 <adamw> is the criterion he cited
16:12:08 <roshi> it's also a conditional blocker of the custom partitioning IMO
16:12:25 <kparal> maybe more appropriate " Reject or disallow invalid disk and volume configurations without crashing. "
16:12:38 <roshi> that's what I was thinking
16:12:50 <kparal> even though this operation is probably a valid one
16:12:50 <adamw> i'm not sure i'm +1 yet
16:13:22 <kparal> so, this is only custom part, or does it crash also in guided part?
16:13:23 <adamw> i'd like to know for sure that it's the GPT swap partition id triggering this, and if so, how common that is
16:13:27 <roshi> what would it take for you to get there or totally not get there?
16:13:36 <adamw> see above
16:13:57 <adamw> i have a UEFI VM so i can probably check it out any time i stop pretending to be a developer :P
16:14:30 <kparal> adamw: stop pretending you are *not* a coder, that will be easier
16:14:42 <adamw> 'how common that is' could be the trickier question, i guess
16:15:13 <roshi> yeah
16:15:42 <kparal> I think we should try a default installation, then replace it completely, on both bios and uefi. then decide
16:16:28 <roshi> I'm fine with a punt for more info
16:17:32 <adamw> be good to wake the bug up, though
16:17:39 <adamw> it was prety active for a while then ground to a halt
16:17:55 <kparal> that asks for an action item to test it
16:19:12 <adamw> mattdm: bash update has 5 karma now, that's good right?
16:19:28 <mattdm> adamw: yep
16:19:43 <adamw> that's a goddamn terrible update notice. sigh.
16:19:53 <adamw> roshi's connection went down
16:19:54 <mattdm> adamw yeah. we have a magazine article too.
16:20:07 <adamw> #action adamw to look deeper into #1114786 causes
16:20:32 <adamw> propose #agreed #1114786 looks worrying, but we need more details on what circumstances trigger the bug - punt
16:20:48 <pschindl> ack
16:20:57 <kparal> ack
16:20:59 <jskladan> ack
16:21:16 <kparal> I can easily delete whole previous LVM, that works
16:21:28 <adamw> #agreed #1114786 looks worrying, but we need more details on what circumstances trigger the bug - punt
16:22:17 <pschindl> kparal: I guess that it doesn't happen with lvm, wasn't that mentioned that somewhere in comments?
16:22:23 <adamw> hold on while i read my own SOP to remember how to run these meetings :)
16:22:40 <kparal> pschindl: might be, I just verified
16:22:43 <adamw> #topic (1116659) unable to set mount point because the field is grayed out
16:22:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1116659
16:22:43 <adamw> #info Proposed Blocker, anaconda, NEW
16:22:57 <kparal> I think we don't have a secretary yet
16:23:09 * kparal is sure he will regret mentioning that
16:23:32 <adamw> kparal: a volunteer! I see a volunteer!
16:23:34 <adamw> hm, did we lose meetbot?
16:23:35 <kparal> where?
16:24:17 <kparal> yeah, it seems meetbot is stuck
16:24:17 <adamw> kparal: =)
16:24:31 <kparal> oh, the volunteer, I just found him
16:25:55 <adamw> hmm, not sure if we should wait for meetbot or carry on regardless
16:25:58 <adamw> the logs would be a mess
16:26:53 <dlehman> 1116659 looks like NOTABUG or WONTFIX to me
16:27:54 <adamw> dlehman: "I'm allowed to check the Reformat checkbox, and upon clicking Update Settings, I get a yellow banner at the bottom that says "Please enter a valid mountpoint.""
16:28:21 <dlehman> Once you activate the reformat checkbox you should be able to set a mountpoint.
16:28:28 <adamw> cmurf says no
16:28:34 <adamw> if i'm reading that comment right
16:28:41 <adamw> oh, i cut it off too soon
16:28:51 <adamw> "I'm allowed to check the Reformat checkbox, and upon clicking Update Settings, I get a yellow banner at the bottom that says "Please enter a valid mountpoint." Yet I can't do that."
16:29:00 <roshi_displaced> well, this will work in the meantime :-/
16:29:10 <adamw> roshi: zodbot seems to have died too :/
16:29:14 <adamw> we're a bit stuck without it
16:29:28 <adamw> #topic (1116659) unable to set mount point because the field is grayed out
16:29:30 <roshi_displaced> yeah
16:29:30 <dlehman> It's not clear if he tried after activating reformat.
16:29:33 * adamw tests him again
16:29:38 <adamw> dlehman: that's precisely what that line states.
16:29:40 <roshi_displaced> I'm getting fedmsgs for it
16:29:52 <dlehman> not precisely, no
16:30:03 <adamw> well, while we're waiting for zodbot it's easy enough to check.
16:30:37 <dlehman> that would indeed be a bug if activating reformat did not make the mountpoint editable (given a mountable fstype selection)
16:31:58 <bitlord> not sure about anaconda version, I mostly reinstall my system with just keeping /home, and reformat /,/boot (so that use case affects me?) (I use ext4 fs always), but it worked fine in tc7 (and some before), and rc1
16:31:58 <adamw> #topic (1116659) unable to set mount point because the field is grayed out
16:33:15 <kparal> I selected previous swap, toggled reformat, changed the type to ext4, and mount point became editable. but I need to provide the value before I hit Update Settings. if I hit it before, everything gets refreshed back to the current state (my changes are not remembered)
16:33:25 <adamw> threebean suggests restarting the meeting...hold onto your hats
16:33:29 <adamw> #endmeeting
16:33:39 <adamw> well, foo.
16:33:43 <adamw> oh. hah.
16:33:43 <dlehman> kparal: yeah, that's annoying but working as designed
16:33:49 <adamw> did roshi actually make me a chair?
16:33:57 <roshi_displaced> don't think so
16:33:59 <adamw> no, no he didn't.
16:34:07 <kparal> hah
16:34:07 <roshi_displaced> I'm not a chair right now either though
16:34:07 <adamw> so it'd be better if someone who *is* a chair took over, i'm thinking :)
16:34:08 <adamw> pschindl satellit jskladan kparal tflink
16:34:12 <kparal> #chair adamw
16:34:12 <zodbot> Current chairs: adamw jskladan kparal pschindl roshi satellit tflink
16:34:19 <adamw> whee
16:34:31 <adamw> #topic (1116659) unable to set mount point because the field is grayed out
16:34:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1116659
16:34:31 <adamw> #info Proposed Blocker, anaconda, NEW
16:34:35 <kparal> good idea, though :)
16:34:39 <adamw> oh fer pete's sake, that's got spaces in it.
16:34:39 <threebean> \ó/
16:34:48 <adamw> #topic (1116659) unable to set mount point because the field is grayed out
16:34:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1116659
16:34:48 <adamw> #info Proposed Blocker, anaconda, NEW
16:34:52 * roshi_displaced thought adamw had perma-chair in these things?
16:34:56 <adamw> Fedora QA is just killing it for professionalism these days
16:35:06 <adamw> yesterday both roshi and I managed to put our actual FAS passwords on fpaste
16:35:13 <adamw> \o/
16:35:21 <roshi_displaced> so much for forgetting about all that
16:35:39 <roshi_displaced> :p
16:36:09 <kparal> transparency foremost, right?
16:36:17 <roshi_displaced> yup
16:36:23 <adamw> we have nothing to hide!
16:36:36 <bitlord> :-)
16:36:38 <roshi_displaced> and we act like it!
16:36:42 <adamw> dlehman: i can confirm the bug
16:37:08 <adamw> wipefs -o (whatever) /dev/vda1 , rescan disks in custom part, choose the wiped disk, check 'Reformat', hit 'Update Settings', and 'Mount Point' is still grey
16:37:19 <adamw> s/wiped disk/wiped volume/
16:38:00 <dlehman> adamw: try: check reformat, (now try to set mountpoint), hit update settings
16:38:36 <adamw> well, you can't "try to set mount point", it's a greyed out text box. you can't meaningfully interact with it.
16:38:37 <dlehman> adamw: you have to set a mountpoint in the same edit you establish reformat to something mountable
16:38:56 <dlehman> okay, kparal seemed to have a different experience
16:39:02 <adamw> it doesn't go active when you check the box.
16:39:11 * adamw testing with alpha
16:39:13 <kparal> I didn't try unformatted partition
16:39:16 * kparal trying that now
16:40:31 <kparal> works for me :)
16:40:51 <adamw> kparal: er, really? are you sure you did it right?
16:40:59 <adamw> you have to pass an offset to wipefs to actually wipe it
16:41:08 <kparal> unformatted partition -> reformat -> mount point field gets enabled -> type something -> update settings
16:41:15 <kparal> I used gparted to create an unformatted partition
16:41:20 <dlehman> you can also do wipefs -a <device>
16:41:26 <kparal> maybe it's something about partition flags or something?
16:41:27 <adamw> hmm, not quite what i did
16:41:45 <adamw> could be
16:41:49 <adamw> what's your fdisk -l look like?
16:42:15 <dlehman> it's not supposed to depend on the previous contents of the device at all, you see
16:42:27 <adamw> it sounds like it depends on *something*, though...
16:42:30 <kparal> http://ur1.ca/i8i4t
16:42:39 <adamw> #chair roshi_displaced
16:42:39 <zodbot> Current chairs: adamw jskladan kparal pschindl roshi roshi_displaced satellit tflink
16:43:20 <kparal> but if two people can reproduce it, it confirms there is a problem somewhere
16:43:46 <adamw> dlehman: i'm seeing 'getFormat('Unknown)' returning DeviceFormat instance with object id (increments)' in the storage log
16:44:26 <dlehman> that sounds correct
16:44:36 <adamw> sometimes 'getFormat('None')'
16:44:57 <kparal> it still works for me, even if I use wipefs on an existing ext4
16:44:59 <adamw> i also see a 'registered action: [462] create format None on partition vda1 (id 303)'
16:45:05 <kparal> wipefs -a, to be exact
16:45:16 <adamw> kparal: what are you testing with *exactly*?
16:45:18 <dlehman> adamw: oh -- you didn't set the fstype to a mountable fs in between reformat and edit mountpoint, did you?
16:45:27 <kparal> but I think we're getting a bit too deep for the blocker bug meeting purposes?
16:45:45 <adamw> dlehman: i'm doing nothing but checking and unchecking the 'reformat' box and hitting "Update Settings"
16:45:51 <adamw> (and switching to alt-f2 to check the logs)
16:45:57 <adamw> not touching or clicking anything else.
16:45:59 <kparal> I'm checking reformat and selecting ext4
16:46:00 <adamw> kparal: true
16:46:01 <dlehman> the mountpoint entry is only active if the fstype can be mounted
16:46:11 <dlehman> because, you know...
16:46:22 <adamw> ah, i missed that dropdown...
16:46:25 <adamw> maybe cmurf did too.
16:46:35 <adamw> yeah, when you pick a filesystem it goes active.
16:47:02 <roshi> whee, and I'm back
16:47:03 <adamw> i guess File System could flip to whatever the current 'default' type is for this custom part instance, when reformatting such a volume? that's obviously not blocker stuff, though.
16:47:35 <adamw> so given mine and kparal's experience, i guess i'll say -1 blocker, assuming cmurf hit the same thing i did
16:47:43 <kparal> so -1, because it seems to be an oversight by the reporter
16:47:55 <kparal> re-propose if there's something more to it
16:47:59 <roshi> -1
16:48:06 <adamw> and we should speed up i guess ;)
16:48:09 * roshi writes proposed #agreed
16:48:22 <adamw> sorry for the impromptu debugging session, but at least it let us -1 a blocker...
16:48:59 <roshi> proposed #agreed - 1116659 - RejectedBlocker - This bug report seems to be an oversight by the reporter. If there's more to this bug please re-propose.
16:49:22 <kparal> ack
16:49:26 <adamw> ack
16:49:28 <jskladan> ack
16:49:36 <roshi> #agreed - 1116659 - RejectedBlocker - This bug report seems to be an oversight by the reporter. If there's more to this bug please re-propose.
16:49:39 <roshi> #topic (1128605) anconda crash when trying to custom  partitioning after do an automatically partitioning
16:49:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1128605
16:49:45 <roshi> #info Proposed Blocker, anaconda, NEW
16:50:44 <adamw> kparal: are you secretarializing or shall I?
16:50:50 <kparal> adamw: I am
16:51:28 <dlehman> looks like a duplicate of 1121383 (fixed on master)
16:51:29 <kparal> this is a bit old
16:51:56 <roshi> yeah
16:52:01 <roshi> looks stale to me
16:52:12 <kparal> dlehman: is it fixed in F21 as well?
16:52:32 <dlehman> you'll be evaluating my request for beta blocker on that bug shortly :)
16:53:35 <roshi> just confirmed with RC1
16:53:38 <roshi> x86
16:53:56 <kparal> ok, so either +1 or make it a duplicate of that second one
16:54:05 <roshi> reclaimed space with autopart, then clicked manual and crash
16:55:05 <dlehman> I'll close as duplicate if nobody objects
16:55:12 <roshi> proposed #agreed - 1128605 - Mark as Duplicate of 1121183
16:55:24 <adamw> ack
16:55:25 <jskladan> ack
16:56:05 <kparal> ack
16:56:18 <roshi> #agreed - 1128605 - Mark as Duplicate of 1121183
16:56:30 <roshi> let's do that bug next then since we're here
16:56:55 <roshi> any objections to that?
16:56:57 <roshi> #topic (1121383) ValueError: specified lv is not part of this vg
16:56:57 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1121383
16:56:57 <roshi> #info Proposed Blocker, python-blivet, POST
16:57:03 <roshi> didn't think so :p
16:58:06 <kparal> +1
16:58:13 <roshi> +1 as well
16:58:14 <kparal> too easy to hit
16:58:44 <jskladan> +1
16:58:54 <jreznik_> +1
17:00:32 <roshi> proposed #agreed - 1121383 - AcceptedBlocker - This bug is really easy to hit and violates Beta custom partitioning criteria.
17:00:35 <adamw> +1, seems traightfowrad
17:00:46 <adamw> i aturrgling tp typr
17:00:53 <dlehman> just needs cherry-picking from master -- there are a variety of ways to hit it, too
17:01:04 <roshi> ack/nack/patch?
17:01:42 <kparal> ack
17:01:47 <jskladan> ack
17:02:07 <adamw> ack
17:02:19 <roshi> #agreed - 1121383 - AcceptedBlocker - This bug is really easy to hit and violates Beta custom partitioning criteria.
17:02:27 <roshi> #topic (1129629) Anaconda doesn't recognize insufficient size of /boot partition
17:02:30 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1129629
17:02:32 <roshi> #info Proposed Blocker, anaconda, MODIFIED
17:03:11 <adamw> +1 for beta, on the second criterion
17:03:20 <adamw> shouldn't this be closed already though?
17:03:31 * adamw tests with alpha
17:04:13 <adamw> hmm, no. it doesn't seem fixed on 21 branch
17:04:19 <adamw> pyanaconda/storage_utils.py:    checkSizes = [('/usr', 250), ('/tmp', 50), ('/var', 384),
17:04:19 <adamw> pyanaconda/storage_utils.py-                  ('/home', 100), ('/boot', 75)]
17:05:34 <kparal> +1
17:05:38 <roshi> +1
17:06:00 <adamw> i just checked, custom part in Alpha let me create a 75MB /boot
17:06:18 <roshi> same here
17:06:51 <bitlord> also it should be considered not only for install, but later to be able to hold 3 kernel releases which is default on fedora (+initramfs ...)?
17:07:30 <bitlord> but that breaks users freedom to later remove keeping 3 different kernels as backup (actually 2, and one latest)
17:07:57 <bitlord> I'm just commenting, don't take this serious :D
17:08:05 <kparal> good points, though
17:08:17 <roshi> proposed #agreed - 1129629 - AcceptedBlocker - This bug is a clear violation of the Beta Custom partitioning criteria: "Reject or disallow invalid disk and volume configurations without crashing."
17:08:23 <adamw> anyway, let's ack it and set bug back to ASSIGNED for 21
17:08:26 <adamw> ack
17:08:58 <jreznik_> ack
17:09:41 <jskladan> ack
17:09:44 <roshi> #agreed - 1129629 - AcceptedBlocker - This bug is a clear violation of the Beta Custom partitioning criteria: "Reject or disallow invalid disk and volume configurations without crashing."
17:09:58 <roshi> #topic (1138967) UI won't permit adding new mountpoint to existing Btrfs, nor creation of a new filesystem to replace it
17:10:01 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1138967
17:10:04 <bitlord> just to tell why /boot space is important, if there is not enough after install it can break updates!
17:10:04 <roshi> #info Proposed Blocker, anaconda, NEW
17:10:29 <adamw> bitlord: we know :)
17:10:34 <bitlord> good! ;-)
17:11:23 <roshi> this seems to be fixed already?
17:11:31 <kparal> it seems to be resolved
17:11:55 <kparal> let's just close the bug then
17:12:08 <adamw> yeah
17:12:23 * kparal closing it
17:12:35 <roshi> moving on
17:12:46 <roshi> #topic (1141707) DeviceFactoryError: new size must of type Size
17:12:46 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1141707
17:12:47 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
17:13:35 <adamw> what's the story on this one dlehman?
17:14:01 <dlehman> I think you hit it anytime you delete an lv from a vg containing a thin pool
17:14:15 <dlehman> the fix is a one-liner already on master
17:14:29 <dlehman> literally s/0/Size(0)/
17:14:36 <adamw> d'oh
17:14:38 <dlehman> yeah
17:14:48 <adamw> yeah, i think that's blocker under the 'must be able to remove existing volumes' criterion
17:14:57 <roshi> +1 with that criterion
17:14:59 <dlehman> only happens in custom FWIW
17:15:04 <kparal> +1
17:15:11 * roshi likes voting on blockers that already have fixes
17:15:38 <adamw> +1
17:15:58 <roshi> proposed #agreed - 1141707 - AcceptedBlocker - This is a clear blocker violating the Beta criterion: "must be able to remove existing volumes."
17:16:05 <jskladan> ack
17:17:17 <kparal> ack
17:17:22 <pschindl> ack
17:17:23 <roshi> #agreed - 1141707 - AcceptedBlocker - This is a clear blocker violating the Beta criterion: "must be able to remove existing volumes."
17:17:43 <roshi> #topic (1142439) 'unable to allocate requested partition scheme' when adding biosboot partition
17:17:46 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1142439
17:17:49 <roshi> #info Proposed Blocker, anaconda, NEW
17:20:50 <roshi> +1, cmurphy is right I think about it needing to be able to create biosboot in custom partitioning
17:21:17 <adamw> hum
17:21:19 <adamw> i'm not so sure
17:21:21 <adamw> he said:
17:21:32 <adamw> oh, wait, no. never mind.
17:21:43 <adamw> he didn't specify an explicit / size, so when he adds other partitions / should shrink, i think
17:21:55 <adamw> dlehman: is that expected behaviour? i've forgotten.
17:21:55 <dlehman> nothing shrinks like that
17:22:18 <dlehman> once a device is shown in the ui its size is fixed
17:22:18 <adamw> ah, so the 'smart' allocation is one-time on create?
17:22:23 <dlehman> exactly
17:22:31 <adamw> ok, so basically anaconda made it as big as it could be and then he tried to add another one
17:22:41 <adamw> for some reason there's some spare space on the disk that anaconda can't use
17:22:43 <roshi> ah
17:22:51 <adamw> probably that could be considered a 'bug', but i'm not sure this merits blocker status as is
17:23:23 <adamw> although, c#5 seems different
17:23:24 <roshi> that makes sense
17:23:27 <adamw> guess we need more testing...
17:23:35 <adamw> to the VMmobile!
17:24:14 <adamw> oh, no, c#7 kinda confirms
17:25:30 <adamw> i'd say probably -1 as it's more or less intended behaviour and doesn't clearly hit a criterion, but it'd be nice to clean up the error and the display of unusable free space if possible
17:25:36 <dlehman> there is always space on disk anaconda cannot use due to alignment of partitions
17:26:02 <adamw> is it at all possible to detect and not show it?
17:26:24 <dlehman> yeah, I was just thinking about that yesterday
17:26:31 <adamw> i guess it's only likely to really cause problems in this particular case where you happen to need a very small partition, but i can certainly see why it would confuse a user
17:26:45 <adamw> "I need a 1MB partition, I've got 3MB free, why am I getting this weird error message?"
17:26:49 <dlehman> we could not include free regions whose size is less than the alignment grain size
17:27:02 <roshi> that could work well
17:27:10 <roshi> -1 blocker
17:27:12 <dlehman> old anaconda did that, in fact
17:27:15 <adamw> doesn't seem like a beta blocker anyway
17:27:17 <roshi> and FE doesn't matter at this point
17:27:31 <roshi> votes?
17:28:03 <adamw> i think the brno crowd hit the pub
17:28:34 <roshi> do brno pubs allow carry out beers?
17:28:40 <roshi> they should bring us back beers
17:28:54 <adamw> where's the flinkular one anyway?
17:28:54 <jreznik_> -1 blocker
17:28:54 <roshi> you're -1 too adamw right?
17:29:01 <jreznik_> everybody is moving to beer fest in nearby pub :)
17:29:12 * kparal was on the phone
17:29:26 <kparal> but we can call it a beer if you like
17:29:49 <adamw> roshi: yeah, i said so already didn't i?
17:29:54 <adamw> kparal: beerphone!
17:29:55 <roshi> proposed #agreed - 1142439 - RejectedBlocker - This bug doesn't really violate any criteria but would be good to fix the display of free space/.
17:30:00 <adamw> ack
17:30:09 <roshi> could be, wasn't in visible scroll back and I was too lazy to pg-up to see
17:30:13 <roshi> :p
17:30:42 <adamw> man, life's such a drag
17:31:02 <kparal> I haven't paid attention to this one, but I can add one ack if needed
17:31:26 <adamw> otherwise i'm going to have to try the false moustache routine again
17:31:30 <adamw> "le ack"
17:31:35 <kparal> ack
17:31:36 <roshi> well, if I pg-up, then I have to pg-dn later and it's just a whole big thing
17:31:53 <roshi> #agreed - 1142439 - RejectedBlocker - This bug doesn't really violate any criteria but would be good to fix the display of free space.
17:31:54 <jreznik_> ack
17:32:33 <roshi> #topic (1143849) trapped in a loop of "DISK ENCRYPTION PASSPHRASE" dialog when partitioning
17:32:36 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1143849
17:32:39 <roshi> #info Proposed Blocker, anaconda, NEW
17:34:39 <roshi> I don't see this
17:35:33 <adamw> may depend on exactly what you choose to encrypt?
17:35:36 <kparal> it seems to work for me now
17:35:38 <adamw> kparal: did you reproduce?
17:35:53 <kparal> didn't try at that time
17:36:02 <kparal> and can't repro now
17:37:02 <roshi> neither can i
17:37:30 <kparal> since we can't repro, I think we should do -1 and ask Tao to try again, and fill in more details if he can reproduce. repropose as a blocker potentially
17:38:04 <roshi> -1
17:39:00 <adamw> well, I just hit a different crash trying to reproduce it somehow...
17:39:02 <roshi> proposed #agreed - 1143849 - RejectedBlocker - We can't reproduce this bug. Please test again and repropose with reproduction steps if it persists.
17:39:10 <adamw> i'm OK with that, i'd also be ok with punt for data but either way
17:39:10 <adamw> ack
17:39:27 <jreznik_> ack
17:39:34 <kparal> punt is fine as well. but this reduces the queue :-P
17:39:43 <roshi> it's basically the same thing ^^ what kparal said
17:39:45 <kparal> ack
17:39:55 <roshi> #agreed - 1143849 - RejectedBlocker - We can't reproduce this bug. Please test again and repropose with reproduction steps if it persists.
17:39:57 <kparal> jskladan: pschindl: are you also on a beerphone?
17:40:29 <roshi> #topic (1143864) unable to do manual partitioning
17:40:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1143864
17:40:29 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
17:42:12 <jreznik_> seems to be fixed
17:42:51 <kparal> on master
17:42:58 <dlehman> right
17:43:00 <jreznik_> yep, sorry
17:43:27 <kparal> +1
17:43:27 <roshi> I get no problems with manual partitioning...
17:43:36 * adamw wouldn't know what a zRAM device was if it spilt its beerphone on him
17:43:40 <kparal> why it occurs only sometimes?
17:43:42 <adamw> which is probably why i've never reported this
17:43:46 <dlehman> you'd have to leave to the main hub then re-enter custom spoke
17:44:13 <adamw> huh. is that what I just hit, then?
17:44:53 <dlehman> he started with an uninitialized disk
17:45:01 <kparal> she
17:45:09 <dlehman> sorry :/
17:45:09 <adamw> dlehman: https://bugzilla.redhat.com/show_bug.cgi?id=1146186
17:45:26 <adamw> i just hit that in trying to reproduce the encryption candidate
17:45:37 <dlehman> all you have to do is enter custom with a single uninitialized disk and you'll repro
17:45:37 <adamw> is that the same thing? it did involve going to custom part twice
17:46:07 <dlehman> adamw: that's another dupe of 1121383
17:46:28 <adamw> ah, so it is.
17:46:33 <adamw> sorry, i'm a bit unfocused this morning.
17:47:02 <dlehman> you're not the only one
17:47:25 <roshi> so, mark as dupe and move on?
17:47:33 <adamw> no, no, it's *my* bug that's a dupe
17:47:48 <kparal> just +1 I think
17:47:48 <adamw> lili's is something else but dlehman says it's a bad one
17:47:52 <adamw> i'm happy to +1 on dlehman's assessment
17:47:59 <dlehman> it's real and it's fixed on master
17:48:03 <roshi> same here
17:48:04 <adamw> "<dlehman> all you have to do is enter custom with a single uninitialized disk and you'll repro"
17:48:07 <adamw> let me find a criterion
17:48:38 <roshi> +1
17:48:40 <jreznik_> +1
17:49:02 <adamw> "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:49:08 <adamw> (custom mode must)
17:49:11 <adamw> +1
17:49:21 * satellit custom std (ex4) for workstation live RC1 x86_64 in VB works here
17:49:42 <adamw> satellit: you have to enter it with an uninitialized disk, as dlehman said.
17:49:51 <roshi> proposed #agreed - 1146186 - AcceptedBlocker - This bug violates the Beta Custom partitioning criteria: "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..."
17:50:17 <kparal> it's not covered by the criteria, but it's close :-)
17:50:35 <kparal> ack
17:50:59 <jreznik_> ack
17:51:09 <roshi> #agreed - 1146186 - AcceptedBlocker - This bug violates the Beta Custom partitioning criteria: "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..."
17:51:40 <adamw> (or good enough for government work, i guess)
17:51:50 <adamw> oh, we could use the alpha one which says it has to be able to do a clean install to any disk
17:51:51 <adamw> whatever
17:52:21 <roshi> #undo
17:52:21 <zodbot> Removing item from minutes: AGREED by roshi at 17:51:09 : - 1146186 - AcceptedBlocker - This bug violates the Beta Custom partitioning criteria: "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..."
17:52:56 <kparal> nooo, I already updated the bug! :)
17:52:56 <roshi> patch #agreed - 1143864 - AcceptedBlocker - This bug violates the Beta Custom partitioning criteria: "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..."
17:53:09 <roshi> I had the wrong bz number in the agreed
17:53:13 <kparal> ah ok
17:53:18 <roshi> so you're good :)
17:53:21 <kparal> ack
17:53:26 <roshi> #agreed - 1143864 - AcceptedBlocker - This bug violates the Beta Custom partitioning criteria: "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..."
17:53:38 <roshi> #topic (1143972) Anaconda doesn't show correct amount of free space when using disk with mbr and three partitions already existings
17:53:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1143972
17:53:44 <roshi> #info Proposed Blocker, anaconda, NEW
17:54:12 <adamw> sounds like the thing we were just talking about...
17:54:18 <adamw> oh, no.
17:55:12 <adamw> dlehman: any thoughts on this one?
17:55:14 <roshi> yeah, this seems different
17:55:33 <adamw> oh, i think i can bet what it is
17:55:55 <adamw> storage wants to create /dev/sda4 as /boot , at which point the partition limit is hit
17:56:03 <adamw> so no way to create the rest of the partitions
17:56:13 <adamw> can /boot be an extended partition?
17:56:53 * roshi doesn't know
17:57:18 * dlehman was making a sandwich
17:58:05 <roshi> this meeting is making me hungry and thirsty
17:58:18 * roshi wants a beer and a sandwich now
17:58:42 <roshi> +1 blocker either way IMO
17:59:16 <adamw> yeah, i can give it a +1 for now
18:00:06 <kparal> it worked for me. but I didn't follow the disk sizes, I just created 3 empty partitions
18:00:07 <jreznik_> +1
18:00:54 <roshi> proposed #agreed - 1143972 - AcceptedBlocker - This bug violates the beta guided partitioning criteria: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation."
18:01:52 <kparal> ack. we can reevaluate later, if it's just some corner case
18:01:56 <dlehman> I don't think we force /boot to be on a primary partition, so I don't see how this bug could happen
18:03:32 <adamw> ack
18:03:51 <adamw> dlehman: well, if it turns out to be something weird or unreproducible flag it up and we'll re-evaluate
18:04:09 <adamw> dlehman: i wasn't necessarily thinking 'force', i was just thinking about what the default auto-partition behaviour does
18:04:34 <dlehman> yeah, I can't tell what's happening on that one yet
18:06:07 <roshi> #agreed - 1143972 - AcceptedBlocker - This bug violates the beta guided partitioning criteria: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation."
18:06:26 <roshi> #topic (1144520) autopart is always pre-selected upon entry to the storage spoke
18:06:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1144520
18:06:32 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
18:08:49 <kparal> is this a blocker material? maybe just FE?
18:09:26 <kparal> and we're not frozen yet
18:09:28 <roshi> doesn't repro for me with RC1
18:09:34 <roshi> -1 blocker methinks
18:10:04 <adamw> dlehman: is it just a label or does it change actual behaviour?
18:11:20 <dlehman> you have to override the default every visit
18:11:52 <dlehman> it changes behavior, but only if you don't fix it before clicking "Done"
18:12:17 <dlehman> I wouldn't call it a blocker, either. I just don't know how else to get permission to fix stuff.
18:12:26 <kparal> just commit? :)
18:12:39 <kparal> until we're in freeze, then request FreezeException
18:12:58 <roshi> with same anaconda version on the workstation live I don't see this
18:12:58 <kparal> or a blocker, of course
18:13:05 <adamw> kparal: anaconda has a team-specific policy about only fixing blocker and FE bugs after a certain time
18:13:07 <roshi> votes? seems we're all -1
18:13:13 <kparal> ah
18:13:15 <adamw> but we can't really mess with the blocker approval process for that
18:13:19 <adamw> seems to come up every release
18:13:32 <adamw> still, it could be a blocker for the kickstart case...
18:13:40 <adamw> i'd expect a kickstart that specifies custom part to, well, do custom part.
18:13:57 <dlehman> I haven't been paying attention to fedora for a while now -- I'm probably just not up-to-date on the procedures
18:14:00 <roshi> I thought it only changes if you click into the spoke
18:14:11 <adamw> oh, wait, i see it now
18:14:11 <adamw> yeah
18:14:14 <adamw> i was misreading
18:14:18 <adamw> so, -1 blocker for sure
18:14:19 <dlehman> adamw: it'll do your custom, but then if you re-enter the spoke it'll try to default to autopart
18:14:20 <roshi> so it *works*
18:14:38 <kparal> still I would expect anaconda to be configured according to my kickstart, if I click into that spoke
18:14:41 <dlehman> right. just sub-optimal default selection in UI.
18:14:44 <adamw> dlehman: we'll have to talk over the commit policy yet again in #anaconda , but we seem to do that merry-go-round every release..
18:15:06 <kparal> let's just call it FE for now
18:15:09 <roshi> proposed #agreed - 1144520 - RejectedBlocker - This bug is an oddity that doesn't actually violate a criteria but still works as intended if you don't enter the spoke.
18:15:09 <kparal> and give it +1
18:15:18 <adamw> see, i wouldn't really break a freeze for this
18:15:31 <roshi> it's annoying, but not broke aiui
18:15:47 <adamw> i understand the aim of the #anaconda thing and feel bad about kicking because it was meant to avoid breakage in the first place, which is what we want, but it's just fundamentally not what the blocker/FE process is *for*
18:16:20 <adamw> it's always going to lead to this kind of dissonance, because we're not making our decisions based on whether we think it's a good idea to apply the changes, so using the blocker/FE decisions to gate things outside of freezes is really not the best plan...
18:16:27 <kparal> ok, not a blocker, but from my POV ok to commit
18:16:30 <dlehman> adamw: no worries. I just wasn't paying attention.
18:17:09 <adamw> dlehman: so just for clarity, so far as Fedora-as-a-whole is concerned, there is no kind of restriction on committing something like this to anaconda right now, it does not need blocker or FE status or anything else.
18:17:52 <dlehman> I didn't really pay attention to alpha being released, so was unaware the freeze was lifted
18:17:55 <adamw> dlehman: ah, ok
18:18:04 <adamw> i thought that anaconda team policy had kicked in already or something
18:18:17 <adamw> freeze should be up and builds can go through fine till beta freeze, afaik
18:18:44 <roshi> votes then?
18:18:53 <roshi> well, ack/nack/patches
18:19:08 <adamw> -1/-1/ack
18:19:40 <kparal> ack
18:19:56 <roshi> #agreed - 1144520 - RejectedBlocker - This bug is an oddity that doesn't actually violate a criteria but still works as intended if you don't enter the spoke.
18:20:16 <roshi> #topic (1144560) installer tries to apply custom kickstart layout again when user visits storage spoke
18:20:19 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1144560
18:20:22 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
18:21:21 <dlehman> I'm gonna push this along with all the others later today, so you can skip if you want to save time
18:21:44 <roshi> +1 to that
18:21:49 <kparal> ok
18:21:58 <roshi> do we need an agreed on it?
18:22:20 <kparal> don't think so
18:22:40 <roshi> #topic (1146101) when boot partition have another systems and not enough space, the installer "succeed"  and break all previous iniramfs
18:22:43 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1146101
18:22:46 <roshi> #info Proposed Blocker, anaconda, NEW
18:24:13 <adamw> we should set 1144560's status one way or the other or iti'll just come up again
18:24:24 <adamw> but i don't mind if kparal wants to clean it up in post
18:25:08 <kparal> I'll do that
18:26:15 <roshi> good call
18:27:17 <adamw> so, https://bugzilla.redhat.com/show_bug.cgi?id=1074358 should probably be on the proposed list too...
18:27:59 <roshi> these seem pretty close to each other
18:28:07 <adamw> well, i was reading it as this bug contains a dupe of that one
18:28:16 <roshi> yeah
18:28:32 <kparal> are there more things combined?
18:28:32 <adamw> but also a different issue - anaconda doesn't check for re-use of an existing /boot without sufficient free space for a new install
18:28:39 <kparal> yes
18:28:55 <adamw> dlehman: what's your thought on these? the initramfs rewriting at least looks bad and should probably block
18:29:10 <adamw> (apparently we shipped f20 that way :( i meant to look into that whole 'linux16' thing but never got around to it...)
18:31:42 <roshi> is dual boots beta?
18:32:36 * dlehman isn't sure he understands
18:32:58 <adamw> oh goody, my NAS has bash on it. i'm sure the manufacturer's right on the update.,
18:33:02 <dlehman> what should we be doing with a preexisting /boot?
18:33:05 <roshi> meaning, do we have criteria for dual boot with older fedora on the beta list or the final list? (where the winders dual boot is)
18:33:09 <dlehman> we shouldn't even allow them IMO
18:33:21 <adamw> dlehman: the pre-existing /boot issue is that it doesn't check how much free space there is on the partition before trying to write to it
18:33:32 <adamw> i'm probably *more* concerned about the initramfs rewrite issue
18:33:41 <adamw> the pre-existing /boot is at least to some extent a 'doctor it hurts'
18:34:32 <dlehman> anaconda is rewriting the initramfs', right?
18:34:54 <roshi> rewriting of pre-existing installations reusing the /boot partition
18:35:16 <dlehman> because it expects the kernels/initramfs it finds to be those we just installed
18:36:18 <roshi> is dual booting even covered in the criteria? I don't see it anywhere but windows in Final
18:37:46 <roshi> I feel like there should be a criteria though
18:38:11 <roshi> but procedurally, if there's no criteria and it's only effecting other installs then I'd lean -1
18:38:34 <adamw> we have a long discussion about it on the list right now
18:39:01 <roshi> yeah, I remember
18:39:10 <adamw> dlehman: i'd guess it might be grub install that does it (rewrite initramfs)
18:39:12 <roshi> for the purposes of this meeting, what do we want to do though?
18:39:24 <adamw> the initramfs-rewrite doesn't seem related to the lack of space issue, i think it's some change to grub 2.02 or whatever
18:39:27 <adamw> so let's make this bug the 'pre-existing /boot' issue
18:39:49 <adamw> i think it's possibly too far into doctor-it-hurts territory to make a blocker...it's a custom part thing, and you're expected to know what you're doing to some extent in there
18:40:05 <adamw> there is that 'reject invalid configurations without crashing' hostage to fortune, but it doesn't quite match that description, i'd say
18:40:19 <roshi> I don't think it does
18:46:15 <roshi> well, we've got 13 minutes left
18:46:40 <adamw> how many bugs?
18:46:45 <roshi> 13 or so to go
18:46:49 <adamw> jeez
18:46:52 <roshi> yup
18:46:56 <adamw> so, i think i'm -1 on the /boot free space bug
18:47:14 <roshi> that's where I'm leaning (until we have dual boot criteria that is)
18:47:27 <roshi> so two -1s
18:47:43 * kparal is away for a short while, sorry
18:47:44 <roshi> tflink kparal pschindl dlehman : votes?
18:48:19 <dlehman> -1 on reusing /boot
18:49:31 <roshi> proposed #agreed - 1146101 - RejectedBlocker - This bug doesn't directly violate any criteria.
18:49:55 <roshi> not very specific, but I'm not 100% sure the best way to write the "don't try to reuse /boot"
18:51:08 <roshi> patches welcome
18:52:55 * kparal reads back
18:54:15 <tflink> assuming that I've read this all correctly, It'd be nice to have an error when initramfs writing fails but not sure this is a blocker
18:55:05 <roshi> for sure - for check partition size before even starting
18:55:10 <kparal> dual-boot issues are a different thing, but yes, we should see an error when there's not enough free space and the files were not created (properly or at all)
18:55:48 <kparal> probably not a Beta blocker though. it might be Final
18:56:14 <adamw> tflink: the initramfs thing i'd like to consider separately
18:56:21 <adamw> as #1074358
18:56:25 <adamw> i'll throw that on the proposed list
18:57:16 <roshi> sgtm
18:57:25 <roshi> well, we're at our allotted time
18:57:36 <kparal> ack
18:58:26 <tflink> so, the issue at hand is checking for available space in /boot when re-using the partition?
18:58:34 <tflink> I'm not clear on which issue we're voting on
18:59:28 <adamw> tflink: yeah
18:59:57 <tflink> again, it'd be nice but I don't think it clearly violates any criteria
19:00:11 <roshi> yeah
19:00:12 <tflink> -1
19:00:15 <tflink> ack
19:00:26 <roshi> so ack/nack/patch for this bug? 1146101
19:00:34 <roshi> that's enough for me :)
19:00:40 <pschindl> ack
19:00:43 <kparal> adamw: could you please secretarialize this one? I think you'll write the explanation better
19:00:51 <roshi> #agreed - 1146101 - RejectedBlocker - This bug doesn't directly violate any criteria.
19:01:21 <roshi> anybody have anything for open floor or just close up?
19:01:33 <adamw> kparal: OK
19:01:37 <kparal> thanks
19:01:53 <roshi> #info If you have spare cycles, go through the remaining blockers and vote before next meeting
19:01:54 <kparal> nothing here for open floor
19:02:33 * roshi sets the quantum fuze timer
19:04:33 <roshi> well, thanks for coming folks!
19:04:39 <roshi> #endmeeting