16:02:18 <roshi> #startmeeting F22-blocker-review
16:02:18 <zodbot> Meeting started Mon Mar 23 16:02:18 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:18 <roshi> #meetingname F22-blocker-review
16:02:18 <zodbot> The meeting name has been set to 'f22-blocker-review'
16:02:19 <roshi> #topic Roll Call
16:02:27 <roshi> who's around for some blocker goodness?
16:02:30 * jreznik is here
16:02:53 * kinokoio is here
16:02:55 <adamw> ahoyhoy
16:03:08 * kparal is here instead of pschindl
16:03:25 <roshi> #chair adamw jreznik kinokoio kparal
16:03:25 <zodbot> Current chairs: adamw jreznik kinokoio kparal roshi
16:03:35 <roshi> #topic Introduction
16:03:36 <roshi> Why are we here?
16:03:36 <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:03:39 <roshi> #info We'll be following the process outlined at:
16:03:42 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:45 <roshi> #info The bugs up for review today are available at:
16:03:47 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:49 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:52 <roshi> #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria
16:03:55 <roshi> #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
16:03:58 <roshi> #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria
16:04:01 <roshi> we currently have 7/1 proposed blockers for beta/final
16:05:00 <roshi> onto the beta proposals!
16:05:17 <roshi> #topic (1160917) fedora-release-(product) conflicts when installing environment groups which specify a different product to the currently-installed one
16:05:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1160917
16:05:23 <roshi> #info Proposed Blocker, distribution, NEW
16:07:34 <kparal> this is blocking because of transitive dependecy, I assume
16:07:51 * jreznik is reading
16:07:52 <kparal> through multiple levels
16:08:38 <adamw> boils down to https://bugzilla.redhat.com/show_bug.cgi?id=1204739
16:08:43 <kparal> https://bugzilla.redhat.com/showdependencytree.cgi?id=1160917&hide_resolved=1
16:09:16 <adamw> i'm happy with 1204739 as a blocker, not quite sure if it really makes sense to propagate that all the way up the tree..
16:10:01 <kinokoio> doesn't look like a bug
16:11:29 <kparal> shouldn't we discuss the actually proposed bug instead of its dependency?
16:12:08 <kinokoio> This is from F21: http://fpaste.org/201546/27127103/
16:12:15 <adamw> kparal: yeah, i think that makes sense.
16:12:45 * kushal is here
16:12:54 <roshi> am I just missing the criteria for 1160917?
16:13:38 <jreznik> roshi: as it leads to that second bug, I'd say it's cockpit that doesn't work, so this bug is -1 blocker then?
16:13:52 <roshi> that's what I'm thinking
16:14:04 <roshi> I see no criteria listed in the bug and can't think of one it violates
16:14:38 <adamw> it's just there through the dependencies, isn't it?
16:14:38 <roshi> though, I could see discussion as to if we want it codified somewhere that we want to allow other DE's to be installed alongside a Workstation or KDE install
16:14:44 <adamw> the bug isn't explicitly nominated as a blocker.
16:14:45 <kparal> roshi: that's because it's not even proposed :)
16:14:50 <roshi> which I would say we do
16:14:57 <adamw> we don't review dependent blockers like this, we review the one that's actually proposed.
16:15:53 * roshi thought only proposed blockers showed up on the blocker bugs list
16:15:56 <kparal> this might be an RFE for the blocker bug app to show only actually proposed blockers and not their deps
16:15:59 <roshi> which is why I was confused, I guess
16:16:27 <adamw> roshi: i've been asking tflink for a while to get dependencies in there, maybe he did it
16:16:41 <adamw> anyway, there's clearly no 'BetaBlocker' in the list of bugs tha 1160917 blocks
16:16:48 <roshi> -1 on this, but +1 1204739
16:16:50 <kparal> it might be reasonable to show in deps in the accepted blockers section
16:16:54 <kparal> *the deps
16:17:27 <sgallagh> /me appears
16:17:33 <roshi> welcome sgallagh ;)
16:17:57 <sgallagh> /me reads the scrollback
16:18:11 <kinokoio> wasn't it thinked that fedora-release-nonproduct to be used to distinguish the Fedora official releases from "custom" Fedoras?
16:18:14 <roshi> if this wasn't proposed, I say we ignore it for this meeting and move on to one that's actually proposed
16:18:26 <kinokoio> +1 1204739
16:18:37 <kparal> roshi: yep
16:18:45 <roshi> that was the plan kinokoio
16:18:47 <roshi> aiui
16:18:52 <kparal> let's just change #topic
16:19:33 <roshi> #info This bug (1160917) wasn't actually proposed as a blocker, skipping
16:19:36 <roshi> #topic (1204739) Installing Fedora Server netinst ends up with blocked Cockpit port
16:19:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1204739
16:19:40 <roshi> +1
16:19:43 <roshi> #info Proposed Blocker, fedora-release, ASSIGNED
16:19:43 <sgallagh> kinokoio: With the new fedora-release changes that we're missing, fedora-release-nonproduct actually goes away
16:19:45 <kparal> +1
16:19:54 <sgallagh> No special package is needed to denote "non-product"
16:20:11 <roshi> who wants to secretarialize?
16:20:24 <sgallagh> This one at least is a clear blocker IMHO, regardless of how we fix it.
16:20:34 <roshi> yeah
16:20:43 <sgallagh> It'll be kind of difficult to roll back, so the best solution would be to just get the fedora-release change in
16:20:57 * adamw will secretarialize if no-one else does
16:21:09 <adamw> +1 to this one, again
16:21:12 * danofsatx is here, but in $dayjob meetings - can't really contribute :(
16:21:14 <sgallagh> This was supposed to stay in updates-testing until the fedora-release package landed, but we forgot to turn off autokarma :(
16:21:24 <sgallagh> +1 (for the count)
16:21:38 <jreznik> +1
16:21:51 <kinokoio> well, then +1 to 1160917
16:22:02 <roshi> proposed #agreed - 1204739 - AcceptedBlocker Beta - This bug is a clear violation of the criterion: "After system installation without explicit firewall configuration, the system firewall must be active on all non-loopback interfaces. The only ports which may be open to incoming traffic are port 22 (ssh), port 9090 (Cockpit web interface)"
16:22:42 <sgallagh> FWIW, I truncated that criteria. I don't know if we care.
16:22:59 <sgallagh> Also, I'd like to propose that we adjust s/may/must/ in the criteria.
16:23:08 <roshi> I don't care, it gets the point accross
16:23:48 <adamw> nack on s/may/must/, it changes the meaning in a way i don't think you want.
16:24:00 <adamw> 'the only ports which must be open' implies that others may be open and that's fine.
16:24:15 <sgallagh> adamw: Sorry, that was a bad way to phrase it.
16:24:16 <adamw> 'the only ports which may be open' means that no others may be open, which is a crucial part of the meaning.
16:24:28 <adamw> also, the '
16:24:39 <sgallagh> I meant "The following ports must be open unless the firewall was expressly adjusted during installation: <blah>"
16:24:50 <adamw> yeah, that sounds better, but let's do it on list
16:24:53 <sgallagh> ok
16:25:15 <sgallagh> Then ack
16:25:35 <roshi> so do I need to change the proposed #agreed
16:25:36 <roshi> ?
16:25:49 <sgallagh> roshi: My ack was for the current proposal
16:26:07 <roshi> kk
16:26:10 <adamw> the proposal is fine
16:27:18 <roshi> ack/nack/patches?
16:27:23 * kparal is confused
16:27:24 <kparal> ack
16:27:32 <jreznik> ack
16:27:34 <roshi> #agreed - 1204739 - AcceptedBlocker Beta - This bug is a clear violation of the criterion: "After system installation without explicit firewall configuration, the system firewall must be active on all non-loopback interfaces. The only ports which may be open to incoming traffic are port 22 (ssh), port 9090 (Cockpit web interface)"
16:27:44 <roshi> least I wasn't the only one kparal :P
16:27:59 <roshi> #topic (864198) grubby fatal error updating grub.cfg when /boot is btrfs
16:28:02 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=864198
16:28:04 <roshi> #info Proposed Blocker, grubby, ASSIGNED
16:28:49 <kparal> sigh, that's a long bug
16:29:03 <roshi> yup
16:29:06 <roshi> reading now
16:29:15 <roshi> started back in 2012
16:29:16 <adamw> it's a mess
16:29:38 <adamw> basically the problem is that putting /boot on a btrfs subvol does not work
16:29:45 <adamw> at various times we have disallowed this in anaconda
16:29:55 <adamw> i actually thought we'd done that again for f22 now, but i can't decode cmurf's last two comments at all
16:30:49 <roshi> the way I read it: if you installed /boot on btrfs when we allowed it in anaconda, doing a fedup now will bork your install
16:31:16 <adamw> https://github.com/rhinstaller/anaconda/pull/41 is the recent pr for this
16:31:17 <roshi> using a definition of "read" that's really accomodating, that is :p
16:31:50 <adamw> roshi: i don't think fedup has anything to do with it, we're talking 'update' simply in the sense of installing a new kernel
16:32:05 <adamw> oh, i see, you're on c#78
16:32:10 <roshi> oh
16:32:12 <adamw> sigh, he's always putting more goddamn stuff in these bugs
16:32:21 <roshi> c78 mentions fedup
16:32:24 <sgallagh> Right, so that making it in was apparently a mistake. And if you happened to be fool enough to install F21 with /boot on btrfs, now you're stuck.
16:32:30 <kparal> so the original decision should be valid - this is a blocker a needs either to be fixed or disallowed again. wdyt?
16:33:06 <sgallagh> I'm honestly inclined to punt this to Common Bugs and +1 FE. I don't think this is blocker-worthy.
16:33:34 <sgallagh> It was a bug that they were allowed to install that way in the first place.
16:33:50 <kparal> we should keep in mind that many people might not expect this and set up their layout incorrectly
16:34:14 <adamw> i'm inclined to ask cmurf to clarify what exactly he is proposing.
16:34:19 <adamw> i *think* i know, but i'd like to be sure.
16:34:31 <jreznik> makes sense
16:34:37 <roshi> I'll agree that it was a bug to let it go once and not again, and that's something we've got to consider when looking at this
16:34:46 <roshi> since it might have been us that let people into the situation
16:34:51 <adamw> also, it looks like for f22 we're actually allowing /boot-on-btrfs, not disallowing it: the PR changed completely while it was being reviewed, from 'disallow it' to 'fix the bug'
16:34:58 <sgallagh> Correct me if I'm wrong, but it would only be possible to be in this situation by manual effort?
16:35:08 <adamw> sgallagh: what do you mean by 'manual effort'?
16:35:10 * jreznik wishes there will be magic button to clear up mess in bug
16:35:23 <sgallagh> adamw: Making a conscious effort to have /boot-on-btrfs
16:35:29 <sgallagh> It wasn't autopart doing it, right?
16:35:41 <adamw> no, but we hardly say 'unless you use autopart we don't care about you'.
16:35:52 <adamw> it's a perfectly accessible choice from custom part.
16:36:53 <sgallagh> adamw: That wasn't my point. I was just trying to gauge how often this might have happened.
16:37:00 <adamw> k. hard to tell.
16:37:20 <roshi> I'm more inclined to fix the bug since we might have been the gateway to hitting this
16:37:29 <roshi> with the allow/don't allow stuff
16:37:38 <roshi> regardless of how common it is
16:37:52 <roshi> not sure how firm I am on that, since I don't know the scope of the fix that well
16:38:23 * roshi takes notes of another time useful metrics would have been just that
16:39:01 <adamw> again, i'm proposing we punt and ask precisely what is the current aspect of this bug cmurf wants fixed as a blocker.
16:39:16 <roshi> sgtm
16:39:20 <roshi> votes on punt?
16:39:22 <roshi> +1
16:39:23 <jreznik> punt
16:40:14 <kinokoio> +1
16:40:15 <sgallagh> punt +1
16:40:34 <kparal> ok with punt
16:40:37 <roshi> proposed #agreed - 864198 - Punt - We're going to delay making a decision on this bug until it can be clarified by the reporter as to what exactly is desired.
16:40:52 <kparal> ack
16:42:05 <adamw> ack
16:42:14 <roshi> #agreed - 864198 - Punt - We're going to delay making a decision on this bug until it can be clarified by the reporter as to what exactly is desired.
16:42:17 <roshi> #topic (1204612) eth0 is going missing in the cloud images
16:42:18 <kushal> got disconnected.
16:42:19 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1204612
16:42:22 <roshi> #info Proposed Blocker, initscripts, NEW
16:42:35 <roshi> no worries - you're back in time for your bug
16:42:42 <kushal> yeah, as it seems :)
16:43:08 <roshi> +1 blocker
16:43:16 <roshi> no networking is a DOA cloud image
16:44:10 <roshi> All release-blocking images must boot in their supported configurations.
16:44:13 <kinokoio> +1
16:44:15 <kparal> it would be nice if someone verified, but yes, it seems to be +1
16:44:20 <roshi> I've seen it
16:44:22 <kparal> *reproduced
16:44:24 <kparal> ok
16:44:24 <adamw> +1 then...
16:44:33 <sgallagh> +1
16:44:40 <roshi> kushal: and I saw this for a while and tried to pin down that it was before he submitted it
16:45:10 <roshi> proposed #agreed - 1204612 - AcceptedBlocker Beta - This bug violates the alpha criterion: "All release-blocking images must boot in their supported configurations."
16:45:31 <nirik> cloud images are using network?
16:46:07 <adamw> we usually use the 'install updates' criterion as a proxy for network issues
16:46:17 <adamw> the image does *boot*, right?
16:46:36 <roshi> if you have access to the machine that it's running on
16:46:38 <kushal> adamw, it boots, but no network means we can not access it at all.
16:46:52 <roshi> but that wouldn't be visible to someone trying it on AWS/Openstack
16:47:04 <roshi> for all intents and purposes it doesn't boot
16:47:06 <kushal> roshi, +1
16:47:18 <adamw> eh, however you want to slice it
16:47:18 <Corey84> .fasinfo corey84
16:47:19 <zodbot> Corey84: User: corey84, Name: Corey84, email: sheldon.corey@gmail.com, Creation: 2014-11-28, IRC Nick: corey84-, Timezone: US/Eastern, Locale: en, GPG key ID: 02D670FD  1C9129B1 , Status: active
16:47:22 <zodbot> Corey84: Unapproved Groups: marketing
16:47:23 <Corey84> (uber late)
16:47:25 <zodbot> Corey84: Approved Groups: fi-apprentice cla_fpca cla_done
16:47:31 <roshi> a cloud image w/o networking might as well be a bricked phone, that's less good at being a paperweight than a bricked phone
16:47:32 <adamw> "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles. "
16:47:52 <roshi> for cloud, "possible" is pretty fluid
16:47:56 * nirik notes vnc should be working on our clouds now...
16:48:13 <roshi> for this case, it's not possible for the majority of cloud users
16:48:28 <roshi> I can change the criteria to the network proxy
16:48:28 <kparal> ack
16:48:33 <roshi> doesn't matter to me, really
16:48:37 <roshi> the end result is the same
16:48:48 <adamw> oh, just toss a three-sided coin
16:49:02 <roshi> I rolled 18
16:49:52 <roshi> proposed #agreed - 1204612 - AcceptedBlocker Beta - This bug violates the alpha criterion: "The installed system must be able to download and install updates with the default console package manager."
16:50:12 <kparal> ack
16:50:18 <adamw> ack
16:50:19 <sgallagh> ack
16:50:24 <jreznik> ack
16:50:26 <roshi> #agreed - 1204612 - AcceptedBlocker Beta - This bug violates the alpha criterion: "The installed system must be able to download and install updates with the default console package manager."
16:50:27 <kinokoio> ack
16:50:36 <roshi> #topic (1201897) SIGSEGV in libedit call in installer
16:50:36 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1201897
16:50:37 <roshi> #info Proposed Blocker, libedit, NEW
16:52:17 <adamw> this seems to be pretty showstopping for tc4.
16:52:23 <adamw> no idea why it's just cropping up now, but hey.
16:52:30 <kparal> does it take down whole anaconda?
16:52:35 * danofsatx is done with $dayjob duties
16:52:38 <danofsatx> +1
16:52:47 <roshi> welcome danofsatx
16:53:20 <kinokoio> +1
16:53:25 <adamw> kparal: yeah, anaconda crashes.
16:53:25 <roshi> +1
16:53:38 <jreznik> +1
16:53:42 <kparal> if you can reproduce it, +1
16:53:53 <adamw> kparal: i'm not on the VPN, but i'd expect most of the coconut jobs for TC4 failed, and if you look at the video you just see the screen blank out shortly after it hits the hub
16:54:11 <adamw> kparal: see all the failed TC4 tests at https://openqa.happyassassin.net/tests :)
16:54:18 <adamw> (also reproduced in a manual run)
16:54:28 <kparal> great, automation pays off :)
16:54:39 <roshi> proposed #agreed - 1201897 - AcceptedBlocker - This bug is a clear violation of the following criterion: "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
16:54:45 <adamw> actually i spent like an hour trying to figure out what openQA was doing wrong before i realized it had actually hit a bug. :P
16:54:47 <sgallagh> +1 and ack
16:55:39 <adamw> huh, i dunno why openQA decided https://openqa.happyassassin.net/tests/2793 had passed. i'd better check that.
16:55:47 <danofsatx> ack
16:56:12 <adamw> could be mediakit_iso_size being set to 'important', i really don't grok those flags, they seem awkward as hell.
16:58:43 <roshi> #agreed - 1201897 - AcceptedBlocker - This bug is a clear violation of the following criterion: "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
16:58:59 <roshi> #topic (1204031) 22 Beta TC3 install images do not bring up network (unless updates image or kickstart used)
16:59:02 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1204031
16:59:05 <roshi> #info Proposed Blocker, lorax, ON_QA
17:01:08 <kinokoio> TC3 or TC4?
17:01:10 <adamw> TC3
17:01:16 <adamw> this was fixed in TC4, we got the previous bug in exchange
17:01:28 <kparal> +1
17:01:39 <adamw> +1 blocker for this one, we need to keep tracking all the blockers till we get an image with none of them and push an update stable...
17:01:48 <kinokoio> +1
17:01:49 <roshi> +1
17:01:51 <sgallagh> +1
17:02:14 <danofsatx> +1
17:02:16 <jreznik> +1
17:02:52 <roshi> proposed #agreed - 1204031 - AcceptedBlocker - This bug is a clear violation of the following criterion: "When using a release-blocking dedicated installer image, the installer must be able to use either HTTP or FTP repositories (or both) as package sources. Release-blocking network install images must default to a valid publicly-accessible package source."
17:03:29 <kparal> ack
17:03:58 <jreznik> ack
17:04:10 <danofsatx> ack
17:04:13 <roshi> #agreed - 1204031 - AcceptedBlocker - This bug is a clear violation of the following criterion: "When using a release-blocking dedicated installer image, the installer must be able to use either HTTP or FTP repositories (or both) as package sources. Release-blocking network install images must default to a valid publicly-accessible package source."
17:04:21 <kinokoio> ack
17:04:33 <roshi> last proposal for beta
17:04:34 <roshi> #topic (1201120) DeviceTreeError: could not find parent for subvol
17:04:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1201120
17:04:40 <roshi> #info Proposed Blocker, python-blivet, ASSIGNED
17:05:39 <danofsatx> ummm.... +.5 ?
17:06:22 <kparal> seems legit
17:06:28 <Corey84> this blivet stuff is not just btrfs
17:06:33 <adamw> seems to break install on certain existing btrfs layouts
17:06:39 <adamw> Corey84: this particular bug is entirely btrfs specific.
17:06:39 <kparal> yes
17:06:44 <Corey84> I can confirm it hits on the tree for luks and none luks
17:06:50 <adamw> Corey84: no, this bug does not.
17:07:12 <Corey84> its across all of blivet tho not JUST btrfs
17:07:12 <adamw> it is in btrfs-specific code, you cannot possibly hit it without having a btrfs volume.
17:07:22 <kparal> but I'm not sure this is really fit for Beta
17:07:25 <adamw> Corey84: then it's a different bug. blivet is a large component, there isn't just one possible bug in it.
17:07:28 <kparal> seems to be a bit far-fetched for Beta
17:07:41 <adamw> kparal: i don't think the 'lots of docker snapshots' bit is at all important
17:07:51 <adamw> it's basically an issue of volume enumeration order iirc
17:08:17 <adamw> so might be a bit unpredictable as to exactly when it happens, but could potentially happen to any btrfs layout i guess?
17:08:20 <kparal> it seems to be relevant to how you name your volumes
17:09:16 <kparal> +1 from me, I'm just not sure about the milestone
17:09:20 <Corey84> if its like the lvm /luks one which a quick glance at  ticket confirms its on pre-existing volumes
17:09:39 <Corey84> as if it checks if it did it sees it didnt and fails
17:09:47 <Corey84> +1
17:10:33 <kinokoio> +1, should not be happening
17:10:56 <roshi> seems like a blocker to me
17:10:58 <roshi> +1
17:11:42 <roshi> proposed #agreed - 1201120 - AcceptedBlocker Beta - This bug violates the following criterion: "When using the custom partitioning flow, the installer must be able to: Correctly interpret ... btrfs volumes."
17:12:05 <Corey84> ack
17:12:14 <kinokoio> ack
17:12:40 <Corey84> kinokoio,  this is not yours but same  essential issue (btrfs tho)
17:12:49 <danofsatx> ack
17:13:26 <kparal> ack
17:14:04 <roshi> #agreed - 1201120 - AcceptedBlocker Beta - This bug violates the following criterion: "When using the custom partitioning flow, the installer must be able to: Correctly interpret ... btrfs volumes."
17:14:07 <adamw> ack for now, i can see arguing with it if it turns out to be rare and hard to fix
17:14:14 <adamw> whoops, i need to quit multitasking :)
17:14:31 <roshi> lol
17:14:32 <roshi> #topic (1204408) local variable 'app' referenced before assignment
17:14:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1204408
17:14:37 <roshi> #info Proposed Blocker, gnome-abrt, NEW
17:15:37 <danofsatx> +1
17:15:41 <kinokoio> +1
17:15:45 <danofsatx> seems pretty cut and dry to me
17:15:55 <roshi> +1
17:15:58 <roshi> same here
17:16:03 <Corey84> not a big gnome guy but seems b/w  +1
17:16:07 <kparal> +1
17:16:12 <danofsatx> also, an easy fix (for even me)
17:16:42 <roshi> proposed #agreed - 1204408 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
17:16:47 <adamw> god, what kind of amateur does this (except me twice every day)
17:16:54 <danofsatx> ack
17:16:58 <kparal> ack
17:17:02 <adamw> ack
17:17:21 <Corey84> ack
17:17:22 <roshi> #agreed - 1204408 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
17:17:34 <roshi> adamw: if it's any consolation, me too :p
17:17:44 <roshi> #topic Open Floor
17:17:50 <roshi> anyone have anything for open floor?
17:18:42 * roshi sets the fuse...
17:18:46 <kinokoio> Just reported one
17:18:52 * danofsatx meanders back out the door
17:19:01 * adamw blows hurriedly on the fuse
17:19:15 <kinokoio> https://bugzilla.redhat.com/show_bug.cgi?id=1204883
17:19:16 * roshi pulls the fuse out, tossing it to adamw
17:19:25 <Corey84> it was the luks one i meantioned kinokoio  one sec for link
17:19:42 <kinokoio> another one
17:19:44 <Corey84> https://bugzilla.redhat.com/show_bug.cgi?id=1204546
17:19:52 <Corey84> there ^  no yours  kinokoio
17:20:15 <roshi> which of these is proposed?
17:20:16 <Corey84> this is what i was saying earlier during the btrfs stuff  roshi
17:20:55 <kinokoio> 1204546
17:21:20 <danofsatx> oh, so you're saying that if the drive *is* encrypted, attempting to create new unencrypted breaks anaconda?>
17:21:25 <Corey84> which is a dup even roshi  its been a ride this blivet  stuff :(
17:21:55 <roshi> so it seems
17:22:01 <roshi> #chair Corey84
17:22:01 <zodbot> Current chairs: Corey84 adamw jreznik kinokoio kparal roshi
17:22:12 <roshi> Corey84: you want to do a topic and link for this?
17:22:18 <Corey84> NO  if pre-existing  anaconda (moreover  blivet) blows up and Assumes you are 1) tombing   or  2)  attempts to regen them
17:22:53 <Corey84> not sure of the cmds i leave that stuff to the pros
17:23:00 <roshi> #topic (1204546) LUKSError: luks device not configured
17:23:03 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1204546
17:23:25 * Corey84 notes to  read up more on meetbot  cmds  later
17:23:51 <Corey84> blivet has also thrown FormatCreate errors on the same  premise
17:24:22 <Corey84> line 178  or there abouts  of  /blivet/format/luks.py   is the cuplrit
17:24:36 <Corey84> for those that git checkout blivet
17:24:44 <adamw> this doesn't look like a dupe of any existing bug to me
17:25:00 <adamw> so what exactly are the steps to reproduce this?
17:25:15 <Corey84> kinokoio,  still have those screenshots  ?
17:25:24 <adamw> set up an install with an encrypted LV, then change your mind and unencrypt it?
17:25:33 <adamw> does it have to be an *existing* encrypted LV?
17:25:39 <Corey84> NO encrypted VG or PV
17:25:46 <kinokoio> must be in the logs
17:25:48 <Corey84> then pre-built  LVs
17:26:04 <Corey84> mine are deep atm  can look tho if oyu can't find
17:26:26 <kinokoio> due to a problem I erased my /home partition
17:26:28 * adamw not sure he understands exactly how you hit this.
17:26:33 <kinokoio> so I lost all
17:26:54 <kinokoio> I have an lvm pv inside an luks partition
17:26:56 <roshi> oof
17:27:04 <Corey84> http://ur1.ca/jyuje  <~  the offending code in blivet
17:27:22 <adamw> Corey84: pointing at code doesn't help us understand how to actually reproduce the bug.
17:27:38 <kinokoio> Say you have an encrypted partition
17:27:39 <roshi> I'm still not sure what's happening with this one
17:27:40 <adamw> there is clearly some kind of bug because anaconda is crashing, but to decide whether it's a blocker, the important thing we need to know is how you actually encounter the bug.
17:27:42 <Corey84> adamw,  create a cryptsetup luksFormat  PV
17:27:51 <Corey84> add a few LVs inside that
17:29:11 <adamw> OK
17:29:28 <kinokoio> should have added them to the bug
17:29:34 <Corey84> then attempt to reformat fs and mount as usual  it attempts to encrypt the  LVs ("tombing" ) them  which blivet seems ill equipped to handle  or throws a FormatCreate error  (as  it can't poll the  cryptsetup params)
17:30:01 <adamw> ah, so anaconda actually decides itself to try and encrypt the LVs?
17:30:05 <Corey84> worst case I will throw a VM or on a spare disk and update kinokoio 's ticket   with more adamw
17:30:20 <roshi> that'd be good
17:30:37 <Corey84> correct  it ASSUMES  the PV /VG and LVs are ALL crypt'd
17:30:45 <roshi> if you can put repro steps in the bug, we can verify it and vote in bug?
17:31:39 <Corey84> and unchecking "encrypt"  without recycling the spoke   blows  errors (   the one in bz  or createFormat  or even some crap on __init__.py ---can't remember the exact throw on that one atm)
17:31:45 <kinokoio> give me about 15min
17:31:50 <roshi> kk
17:31:52 <kinokoio> and ill make the screenshots
17:32:12 * roshi refills his coffee
17:32:27 <Corey84> roshi,  I'll also do the same ATTEMPTing to highlight ALL three i jsut mentioned (using my  sheldon.corey@gmail.com bz  acct as a tag)
17:32:37 <adamw> kinokoio: a step-by-step description instead of or in addition to screenshots might be better
17:32:45 <adamw> it can be slightly tricky to follow the scenario from screenshots alone
17:32:52 <adamw> thanks for the data folks
17:32:52 <Corey84> kinokoio,  i'll see if i can grab your  screengrabs from last night too and add
17:33:24 <Corey84> adamw,  the anaconda folks (some of them ) seem to think this is a edge case
17:33:40 <adamw> it's also best to separate the reports clearly. any case which results in a different python exception - LUKSError , FSError etc - should be initially filed and described separately
17:33:50 <Corey84> so fyi may be some upfront friction I've mentioned this in #anaconda AT LEAST twice
17:33:54 <adamw> Corey84: i think we'd all benefit from clearer explanation of exactly how to encounter the bug
17:33:59 <adamw> bug(s)
17:34:20 <Corey84> adamw,  i'll get on adding or DUP'ing the bug today /tonight
17:34:53 <roshi> so, punt for now and discuss in bug or next monday once we have repro steps?
17:35:05 <adamw> yeah
17:35:31 <adamw> Corey84: kinokoio: please ensure each bug you think may be a blocker is filed separately and has clear reproduction steps, and then nominate it as a blocker
17:35:40 <adamw> makes it much easier to have a clear discussion that way :)
17:35:48 <kinokoio> alright
17:35:51 <adamw> thanks!
17:35:54 <roshi> #agreed  - 1204546 - Punt - We'll delay deliberation on this bug until there's more documentation and discuss either in bug or at the next meeting
17:36:08 <roshi> #topic Open Floor
17:36:09 <danofsatx> we're still here?
17:36:10 <kinokoio> I'll reproduce it from virtualbox
17:36:13 * roshi sets fuse
17:36:15 <roshi> 3...
17:36:24 <Corey84> +1 needinfo  punt
17:36:30 <roshi> yeah danofsatx - we're *always* here
17:36:40 <roshi> you can check out of blocker meetings, but you can never leave
17:37:10 <Corey84> that hotel california not -blocker-review  or are they the same damn matrix
17:37:46 <Corey84> 2....
17:37:53 <adamw> blocker meetings take place in the hotel california's charming Cedarwood Suite
17:38:06 <kinokoio> +1
17:38:13 <Corey84> lol
17:38:26 <Corey84> fire in the hole  .....?
17:38:29 <roshi> comes with complimentary steely knives
17:38:49 <roshi> thanks for coming folks!
17:38:51 <roshi> #endmeeting