16:00:46 <pschindl> #startmeeting F20-blocker-review
16:00:46 <zodbot> Meeting started Wed Oct 23 16:00:46 2013 UTC.  The chair is pschindl. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:53 <pschindl> #meetingname F20-blocker-review
16:00:53 <zodbot> The meeting name has been set to 'f20-blocker-review'
16:00:58 <pschindl> #topic Introduction
16:01:02 <pschindl> Why are we here?
16:01:08 <pschindl> #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:13 <pschindl> #info We'll be following the process outlined at:
16:01:19 <kparal> pschindl: Roll call :)
16:01:23 <pschindl> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:01:25 <pschindl> #info The bugs up for review today are available at:
16:01:27 <pschindl> #link http://qa.fedoraproject.org/blockerbugs/current
16:01:29 <pschindl> #info The criteria for release blocking bugs can be found at:
16:01:31 <pschindl> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:01:33 <pschindl> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:01:35 <pschindl> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:01:42 <pschindl> Ehm
16:01:43 <kparal> bad links :)
16:01:48 <pschindl> ok :)
16:01:51 <kparal> pschindl: I fixed the wiki page, refresh
16:02:02 <tflink> you might want to wait for folks to show up first :)
16:02:09 * pwhalen is here
16:02:22 <kparal> pschindl: type #topic Roll call
16:02:23 <pschindl> ok, I'm quite nervous :)
16:02:27 <adamw> morning folks
16:02:30 <pschindl> #topic Roll call
16:02:40 * roshi is here
16:02:44 <kparal> pschindl: and #chair tflink adamw (just to be sure) :)
16:02:56 <pschindl> ok, so who else is here to watch this disaster? :)
16:03:05 * kparal watching closely
16:03:06 * jreznik is here, from meeting, to meeting :)
16:03:09 * mkrizek is here
16:03:10 <pschindl> #chair kparal adamw tflink
16:03:10 <zodbot> Current chairs: adamw kparal pschindl tflink
16:03:13 * satellit listening
16:03:48 <jvanek> kparal, uz
16:03:49 <tflink> yeah, always chair someone else
16:03:54 <jvanek> sorry alredy here ;)
16:04:02 <kparal> jvanek would like to propose that bug 1021844 is discussed early
16:04:07 <tflink> I remember the blocker meeting when I lost connection and had to find an admin to chair someone else :)
16:04:08 <jvanek> kparal,  thank you
16:04:24 <jvanek> actually I hope no objections will rise, it is well tested and delayed by serie of accidents
16:04:32 <kparal> jvanek: not yet, wait a bit
16:04:38 <jvanek> yy
16:05:52 <kparal> pschindl: I think you can continue with the boilerplate, feel free to paste it whole again
16:06:08 <pschindl> kparal: ok
16:06:14 <pschindl> #topic Introduction
16:06:21 <pschindl> Why are we here?
16:06:29 <pschindl> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:06:36 <pschindl> #info We'll be following the process outlined at:
16:06:41 <pschindl> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:43 <pschindl> #info The bugs up for review today are available at:
16:06:52 <pschindl> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:57 <pschindl> #info The criteria for release blocking bugs can be found at:
16:07:01 <pschindl> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
16:07:06 <pschindl> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
16:07:08 <pschindl> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
16:08:04 <tflink> roshi, adamw: are one of you doing secretarialization?
16:08:09 <pschindl> ok, so can we start?
16:08:24 <adamw> i can do it
16:08:27 <kparal> pschindl: paste the numbers of the blockers and stuff
16:08:39 <adamw> roshi: you keep an eye on test day :)
16:08:47 <pschindl> #info 6 Proposed Blockers
16:08:49 <pschindl> #info 8 Accepted Blockers
16:08:51 <pschindl> #info 4 Proposed Freeze Exceptions
16:08:53 <pschindl> #info 12 Accepted Freeze Exceptions
16:09:10 <roshi> you got it :)
16:09:21 <kparal> can we go with 1021844 while jvanek is around?
16:09:28 <kparal> please note it's just a FE
16:09:51 <adamw> ok by me
16:09:53 <pschindl> I'd like to make it first. Is someone against it?
16:10:05 <kparal> ok, let's go
16:10:11 <pschindl> #topic (1021844) java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc20 should go to beta
16:10:15 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021844
16:10:21 <pschindl> #info Proposed Freeze Exceptions, java-1.7.0-openjdk, MODIFIED
16:10:58 <jreznik> as a security update I don't have a big issue with that but do we want to do any chances for headless support or not?
16:11:40 <kparal> jreznik: headless rpm should be included in that update: http://koji.fedoraproject.org/koji/buildinfo?buildID=472057
16:11:43 <tflink> what security issues were fixed?
16:11:55 <kparal> jvanek: now you go :)
16:11:59 * Viking-Ice sails in
16:12:10 <jreznik> kparal: but to leverage headless support - so changes in other packages
16:12:13 <tflink> hrm, no arm
16:12:20 <kparal> I think I saw something about 50 security issues fixed, last week in the news?
16:12:34 <jvanek> kparal, jreznik  http://blog.fuseyism.com/index.php/2013/10/23/security-icedtea-2-4-3-released/ is bug list
16:12:45 <jreznik> or is it going to be just feature we don't want to do any changes to other packages now, as I know Java SIG are not very happy about that
16:12:52 <kparal> tflink: I see armv7hl in that koji build
16:12:56 <jvanek> kparal, jreznik  - but except this the main reason is headless jre and abrt connectro
16:13:14 <tflink> "Not arm arches got security updates."
16:13:20 <jvanek> tflink,  correct
16:13:21 <tflink> from update description
16:13:27 <jvanek> and will not get for loong time
16:13:37 <jvanek> we are stuck on arm src tarball
16:13:40 <jvanek> oracle broke JIT
16:13:51 <jvanek> they do not care about arm comaptibility
16:13:54 <jvanek> its pure our work
16:14:24 <jvanek> but headless jre and abrt is here ;)
16:14:42 <kparal> note, java si present on Lives, as a dependency of libreoffice
16:14:43 <tflink> do we want to make a big deal about parity between all the PA?
16:14:58 <kparal> tflink: clearly we can't fix the situation
16:15:11 <kparal> do we want to delay security fixes just because some arch is not included?
16:15:20 <jreznik> tflink: for java, I'd say not too much - it's really in a bad shape on arm as far as I know
16:15:23 <tflink> yeah, that's the other half of the question
16:15:58 <adamw> well, that's not really up to us, is it? we're just considering the FE-ness of the bug
16:16:01 <kparal> I'm +1 FE. security bugs got fixed, great. it can't break too much of our desktop
16:16:03 <jvanek> jreznik, we are doing our best :(
16:16:04 <tflink> would we delay security fixes for x86_64 if java was busted on i386?
16:16:14 <adamw> +1 for me too, be nice to check it doesn't bust firefox or LO
16:16:25 <pschindl> I'm +1 too
16:16:29 <Viking-Ice> +1 here as well
16:16:32 <jvanek> +- from me O:)
16:16:43 <mkrizek> +1
16:16:45 <pschindl> +-? :)
16:16:56 <jvanek> crap +1 :)
16:17:01 <tflink> +1 FE is fine with me as long as we get more testing before it's actually pulled in
16:17:01 <pschindl> ok, so, waaait for it.
16:17:11 <kparal> adamw: firefox plugin doesn't seem to be present on Live
16:17:12 <jvanek> thanx guys!
16:17:18 <roshi> +1
16:17:25 <jreznik> +1 FE (but no changes to support headless pls)
16:17:31 <jreznik> (in other packages)
16:17:31 <jvanek> kparal, icedtea-web was removed?
16:17:33 <jvanek> :(
16:17:44 <kparal> jvanek: it seems so. no complaints from my side
16:17:52 <jvanek> :(
16:18:14 <jvanek> live cd is used fro browsing web in inet cofees with m$ wins
16:18:20 <jvanek> icedtea-web will be missed here
16:18:30 <adamw> well, not our concern atm
16:18:34 <jreznik> well, let's move on
16:18:34 <jvanek> sure
16:18:35 <jvanek> sorry
16:18:40 <jvanek> thanx for aproving packages!
16:18:50 <pschindl> proposed #agreed 1021844 - AcceptedFreezeException - This is security update. New features are added and nothing should be broken by it.
16:18:56 <Viking-Ice> ack
16:18:56 <jreznik> jvanek: java is dying slowly in web client side...
16:19:02 <jreznik> (even KB killed it finally :D0
16:19:03 <jvanek> :(
16:19:06 <pschindl> I'm not good with words :)
16:19:16 <jvanek> thats good! (the KB ) :)
16:19:17 <kparal> ack
16:19:24 <roshi> ack
16:19:31 <mkrizek> ack
16:19:32 <pschindl> ack/nack/patch ?
16:19:37 <tflink> ack
16:19:43 <jreznik> ack
16:19:43 <pschindl> #agreed 1021844 - AcceptedFreezeException - This is security update. New features are added and nothing should be broken by it.
16:19:57 <pschindl> ok, so now lets move to the blockers.
16:19:58 <kparal> pschindl: don't worry, adamw will re-phrase it anyway in the bug report (at least that was my case:))
16:20:12 <pschindl> #topic (1021890) Removing thin LV results in exception
16:20:14 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021890
16:20:16 <pschindl> #info Proposed Blocker, anaconda, NEW
16:22:01 <adamw> boy, this thin provisioning stuff just slides right in without any problems, don't it?
16:22:02 <Viking-Ice> who proposed this as a blocker
16:22:19 <Viking-Ice> ( criteria missing ) but +1
16:22:30 <Viking-Ice> from me
16:22:48 <dlehman> +1 custom shouldn't crash
16:23:01 <mkrizek> Viking-Ice: criterion is listed in the bug
16:23:03 <mkrizek> +1
16:23:06 <pschindl> +1 from me too
16:23:19 <jreznik> +1
16:23:24 <pwhalen> +1
16:23:30 <kparal> +1
16:23:40 <tflink> Viking-Ice: looks like it was proposed @ creation time
16:23:42 <tflink> +1
16:23:55 <adamw> eh, i might be more FE on this. but sure, i can go with +1.
16:24:37 <jreznik> adamw: any reason?
16:24:39 <zbyszek> adamw: no need for FE, since the patch is there...
16:24:47 <pschindl> proposed #agreed 1021844 - AcceptedBlocker - This violates a Beta criterion "When using the custom partitioning flow, the installer must be able to:  Remove a planned storage volume from the planned layout "
16:25:21 <kparal> ack
16:25:22 <mkrizek> ack
16:25:22 <tflink> ack
16:25:29 <adamw> jreznik: well, it just doesn't seem that horrible, you more or less have to create a thinp layout then change your mind. but eh, sure.
16:25:30 <adamw> ack
16:25:41 <jreznik> ok, ack
16:25:48 <pwhalen> ack
16:26:06 <pschindl> #agreed 1021890 - AcceptedBlocker - This violates a Beta criterion "When using the custom partitioning flow, the installer must be able to:  Remove a planned storage volume from the planned layout "
16:26:28 <pschindl> #topic (1022206) ValueError: new btrfs subvols require a parent volume
16:26:30 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1022206
16:26:32 <pschindl> #info Proposed Blocker, anaconda, ASSIGNED
16:26:44 <dlehman> that criterion is mildly amusing given how complicated removing a volume can be
16:27:32 <dlehman> if someone wants to test a patch for 1022206 I can provide an updates image
16:27:48 <adamw> dlehman: i _do_ keep on asking for comments on criteria when they're proposed, but never seem to get 'em...
16:28:07 <kparal> dlehman: aren't you supposed to fix the blockers rather than report new ones? :-)
16:28:29 * kparal just joking
16:29:02 * kparal looking for kickstart criterion
16:29:16 <kparal> we have just delivery
16:29:24 <tflink> if I'm understanding here, btrfs volume creation fails if there are already btrfs vols on the disks @ the start of installation?
16:29:26 <adamw> kparal: i believe you were supposed to be writing it. ;)
16:29:34 <kparal> adamw: ah, that's right!
16:29:54 <adamw> until someone actually does get around to writing kickstart criteria, we're still on the 'we'll decide them case-by-case' policy, I guess.
16:30:14 <adamw> we COULD just say that as far as partitioning goes, the interactive criteria apply to kickstarts...
16:30:24 <kparal> dlehman: does it crash also with something else than btrfs?
16:31:01 <kparal> maybe this same situation can also be triggered by GUI installation?
16:31:06 <Viking-Ice> mkrizek, oh yeah it's there in #1
16:32:00 <kparal> oh, we also have this: "The installer must be able to complete a scripted installation which duplicates the default interactive installation as closely as possible. "
16:32:03 <kparal> which doesn't apply here
16:32:23 <adamw> no
16:32:37 <adamw> like i said, we can just call this one as we see it, we did decide that for kickstart bugs a couple of cycles back.
16:32:41 <adamw> i'm at least +1 FE
16:33:01 <adamw> and i do like cmurf's argument about how if we keep not caring about btrfs it'll never get any better, so i can see +1 blocker...
16:33:21 <kparal> he heard you
16:33:31 <tflink> :)
16:33:32 <adamw> tflink: it's a bit more specific than that, I think
16:33:37 <adamw> "which is a problem when you are removing a device with the same spec (label, in this case) as one you are creating"
16:33:47 <kparal> adamw: but with this approach maybe +1 Final blocker would be good enough?
16:33:50 * jreznik still does not get why we complicate our life with brtfs now, it's not default and never be :)
16:33:51 <Viking-Ice> +1 blocker
16:33:59 <adamw> so its btrfs volume creation fails if there's already a btrfs volume with the same name at the start of installation
16:34:02 * cmurf heard the ether say "btrfs" and then realized the time
16:34:07 <adamw> =)
16:34:29 <adamw> which is most likely to happen if you're doing a reinstall from a 'stock' kickstart, i guess.
16:35:44 <jreznik> kparal: yep, -1/+1 now, let's accept it as final one (maybe later)
16:36:00 <Viking-Ice> kickstart should work at beta time
16:36:14 <kparal> Viking-Ice: actually we don't have that criterion
16:36:28 <Viking-Ice> we are good at adding criteria in midst of the cycle
16:36:29 <kparal> I was supposed to pick some subset of commands that were supposed to work
16:36:31 <Viking-Ice> so let's just add one
16:36:39 <kparal> but never got to it
16:36:56 <adamw> Viking-Ice: the problem is defining 'kickstart should work'
16:37:07 <adamw> you can do just about anything at all with a kickstart, so it's in restricting the scope
16:37:17 <Viking-Ice> adamw, not really it should atleast work to the same extent as the ui does
16:37:21 <kparal> I agree that "part" would be probably in the must-work selection
16:37:24 <adamw> right, i suggested that earlier
16:37:30 <pschindl> I'm +1. This seems to me as the way of 'custom partitioning'
16:37:35 <adamw> " we COULD just say that as far as partitioning goes, the interactive criteria apply to kickstarts..."
16:37:45 <Viking-Ice> yep
16:37:48 <kparal> in that case it's +1
16:37:49 <cmurf> i'd defer to dlehman because this likely is a depencency for fixing other things
16:37:49 <adamw> would we consider this a blocker in interactive mode? (maybe it actually happens in interactive mode?)
16:38:03 <tflink> I think so
16:38:22 <kparal> dlehman seems to be AFK, but it's possible
16:38:28 <kparal> +1 and let's go
16:38:46 <Viking-Ice> to the pub ?
16:38:46 <kparal> (although we will never release this year this way)
16:38:49 <cmurf> if the dev wants it as a blocker I'd tend to give it
16:38:59 <cmurf> because that way, it gets more testing in beta
16:39:07 <cmurf> if it's rejected, it's going to go in final anyway
16:39:08 <Viking-Ice> kparal, after all those years you know we never release on time anyway
16:39:14 <kparal> cmurf: actually the act of proposing doesn't mean +1 blocker
16:39:14 <cmurf> yet not get as much testing (possibly)
16:39:51 <adamw> cmurf: you could say that about anything
16:39:54 <cmurf> yeah i came in a wee bit late so I'm probably partially in a conversation with myself
16:39:58 <kparal> pschindl: let's propose acceptedblocker
16:40:03 <dlehman> this is only pure kickstart
16:40:05 <adamw> i think there's enough +1s anyway
16:40:10 <pschindl> kparal: working on it
16:40:18 <dlehman> followup patch is ready to push
16:40:42 <cmurf> if it's ready it doesn't matter if its a block or FE does it?
16:41:01 <Viking-Ice> it matters upon tracking it
16:41:10 <pschindl> proposed #agreed 1022206 - AcceptedBlocker - This bug doesn't violate any criterion but is very close to the 'When using the custom partitioning flow, the installer must be able to: Remove existing storage volumes and Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes'
16:41:13 <Viking-Ice> ack
16:41:29 <adamw> cmurf: it does slightly, in that if it's only FE and the fix turns out to be bad, we can just back it out.
16:41:30 <adamw> ack
16:41:32 <kparal> ack
16:41:36 <pschindl> ack
16:41:40 <jreznik> ack
16:41:52 <pschindl> #agreed 1022206 - AcceptedBlocker - This bug doesn't violate any criterion but is very close to the 'When using the custom partitioning flow, the installer must be able to: Remove existing storage volumes and Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes'
16:41:55 <tflink> not crazy about the wording there, but close enough - ack
16:42:11 <adamw> i'll fix it in post
16:42:14 <adamw> :P
16:42:18 <pschindl> #topic (1008633) ValueError: invalid target size request
16:42:19 <tflink> there is no justification for why it's a blocker, yet doesn't violate any criteria
16:42:21 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008633
16:42:23 <pschindl> #info Proposed Blocker, anaconda, POST
16:42:26 <pschindl> adamw: Thanks a lot :)
16:42:27 <kparal> pschindl: I told you!
16:42:46 <dlehman> actually, the patch for 1022206 probably fixes several similar bugs lurking in other ks storage commands
16:42:55 <tflink> yeah, it always made me wonder why I tried so hard to get it right in meeting when I knew the wording wouldn't survive to ba :)
16:43:05 <tflink> bz
16:43:12 <Viking-Ice> +1
16:43:17 <roshi> +1
16:43:24 <kparal> +1
16:43:30 <adamw> tflink: the meeting summaries are easier to access
16:43:48 <tflink> +1
16:43:50 <jreznik> +1
16:43:52 <pwhalen> +1
16:44:04 <adamw> -1.
16:44:11 <adamw> this criterion does not apply to shrinking and is not supposed to.
16:44:12 <cmurf> so the NTFS resize crashes in custom? i only tested guided.
16:44:22 <kparal> adamw: I used custom part screen
16:44:23 <tflink> adamw: but it crashes
16:44:23 <adamw> once again, we only 'support' shrinking to a limited extent in final.
16:44:29 <adamw> eh
16:44:46 <adamw> still, apply the last-bug-at-go-no-go criterion
16:44:50 <adamw> it's easy to say +1 when it's POST, i know
16:44:51 <tflink> point
16:45:11 <tflink> -1/+1
16:45:14 <kparal> I'm firm +1. you open up custom part, click on partition and provide a different size without a unit. crash
16:45:17 <adamw> is it easy to delay the release for a week because you can crash the installer in custom part by trying a shrink? ehhh.
16:45:25 <adamw> kparal: yeah, i'm aware of what the bug is. ;)
16:45:30 <adamw> still, looks like i'm outvoted.
16:45:33 * jreznik is guilty of seeing POST the same way how red flag works for bull
16:45:50 <kparal> adamw: I could want to enlarge it as well
16:45:51 <adamw> but yeah, please try to imagine how you'd vote if there was *not* a patch. PSA over. ;)
16:45:57 <kparal> adamw: and reformat and use as root
16:45:59 <adamw> kparal: well, true.
16:46:00 * Viking-Ice *slurp* red bull *slurp*
16:46:30 <kparal> I'm not totally sure it would crash if I did all that actions at once, I didn't try that
16:46:41 <kparal> but my understanding was "no unit -> crash"
16:46:43 <jreznik> so I'm actually change my mind thinking about it -1/and question how invasive it's for FE
16:46:51 <kparal> maybe there's a different root cause
16:46:54 <Viking-Ice> I'm ack to the agreement proposal we are all waiting for ;)
16:46:54 <cmurf> i've been thinking that crashes after feature freeze should just be FE's rather than blockers unless there's also data corruption
16:47:12 <cmurf> for beta, obviously
16:47:27 <kparal> cmurf: never heard of that
16:47:44 <adamw> i'd be +1 FE if it came to that, the crash is pretty obnoxious
16:47:48 <cmurf> kparal: well it's not the current policy
16:47:49 * adamw sorry for causing trouble
16:47:57 <pschindl> ok so now it is 5 +1s and 2 -1 = +3. Does someone want to change his mind?
16:48:04 <kparal> :)
16:48:06 <cmurf> based on policy I'm +1 blocker
16:48:19 <cmurf> but I think the policy could stand modification, that crashes aren't that big of a deal in beta
16:48:26 <kparal> would you be +1 if it crashed for ext4 that you want to reuse as root?
16:49:11 <kparal> it just crashed for me for this use case ^^
16:49:30 <cmurf> kparal: possibly because even ext4 devs aren't so gung ho about it being shrunk
16:49:39 <kparal> click on ext4, provide size without unit, add mount point /, add reformat, click update -> crash
16:50:06 <kparal> cmurf: no, this is about anaconda not expecting user to provide value without a unit
16:50:30 <roshi> I'm +1 due to anaconda crashing
16:50:37 <pschindl> For me this really sounds like violation of mentioned criterion. +1 from me
16:50:40 <cmurf> kparal: i'd settle this bug, I'm having a totally hypothetical conversation that is way out of scope
16:51:08 <cmurf> it's a blocker based on policy that the installer shouldn't crash, pretty much ever, for any reason
16:51:26 <tflink> +3 total is enough to go ahead with proposal
16:51:28 <kparal> for invalid operations, which is providing a size without a unit
16:51:31 <pschindl> proposed #agreed 1008633 - AgreedBlocker - This bug violates criterion: "When using the custom partitioning flow, the installer must be able to:  Reject or disallow invalid disk and volume configurations without crashing."
16:51:37 <tflink> ack
16:51:44 <kparal> patch
16:51:47 <kparal> AcceptedBlocker
16:51:52 <cmurf> kparal: yes presumably if the installer shouldn't crash for invalid operations, it shouldn't crash for valid ones either
16:51:54 <pschindl> :)
16:51:56 <tflink> oh, I read right over that
16:52:00 <pschindl> kparal: thanks
16:52:02 <cmurf> ack
16:52:16 <pschindl> proposed #agreed 1008633 - AcceptedBlocker - This bug violates criterion: "When using the custom partitioning flow, the installer must be able to:  Reject or disallow invalid disk and volume configurations without crashing."
16:52:27 <kparal> ack
16:52:29 <pschindl> ack/nack/patch ?
16:52:33 <adamw> ack
16:52:34 <tflink> ack
16:52:36 <kparal> cmurf: that would be a long debate ;)
16:52:46 <roshi> ack
16:52:52 <pschindl> #agreed 1008633 - AcceptedBlocker - This bug violates criterion: "When using the custom partitioning flow, the installer must be able to:  Reject or disallow invalid disk and volume configurations without crashing."
16:53:03 <cmurf> kparal: not really because if it crashes for a valid operation, then it's guilty of not completing the will of the user, which violates a number of other criteria
16:53:03 <pschindl> #topic (1020111) devicetree.py:1294:addLV:ValueError: 'File descriptor 3 (/tmp/anaconda.log) leaked on lvm invocation. Parent PID 2234: /usr/bin/python' is not in list
16:53:05 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020111
16:53:07 <pschindl> #info Proposed Blocker, anaconda, ASSIGNED
16:53:33 <cmurf> this actually appears to be fixed
16:53:34 <cmurf> i think
16:53:41 <cmurf> DVD it's fixed
16:53:58 <cmurf> live desktop is uncertain because the updates.img is being downloaded still at the time of the crash
16:54:23 <adamw> heh, that sounds like a bug in itself
16:54:32 <adamw> anaconda shouldn't do anything else till the updates.img is downloaded and applied...
16:54:33 <dlehman> I don't think this is fixed anywhere it was ever broken
16:54:37 <kparal> dlehman: does comment 18 mean that the patch was applied on live?
16:54:48 <cmurf> ahh
16:54:49 <dlehman> right -- we don't grab update asynchronously
16:55:35 <kparal> so why it does crash for the first run and not for the second one?
16:55:35 <dlehman> no results from grep means the update is not applied in this case
16:55:55 <dlehman> some bug in liveinst or anaconda handling of updates, probably
16:55:59 * adamw not really clear at all what's going on in this bug
16:56:21 <dlehman> lvm decided to start spewing errors about leaked fds
16:57:26 <cmurf> specifically an existing LVM thin provision installation at the time the installer is launched
16:57:46 <adamw> does it happen in all cases or is it something specific about this one?
16:57:47 <cmurf> and i think this is only happening with live desktop
16:57:53 <dlehman> right -- thinp triggers the crash, but lvm is spewing that stuff regardless of thinp
16:57:57 <kparal> so, a successful previous installation means you can run the installer again, right?
16:58:06 <dlehman> agreed -- I'm not even seeing the lvm spew on non-live
16:58:27 <cmurf> hmm so this is some instablity inthe live environment itself?
16:58:40 <dlehman> so it is only preexisting thinp on live media
16:58:58 <dlehman> yeah, some config that's present in the live media but not in the conventional media
16:59:14 <cmurf> i wonder if this is related to the other LVM thinp problems I've found and we need to get the LVM folks to look at this
16:59:38 <dlehman> FWIW the fix has already been applied on master. it's pretty safe.
17:00:04 <cmurf> ahh ok good so then we can probably move on
17:00:09 <dlehman> like I said, I'm fairly certain that lvm will be complaining about leaked fds with normal lvm as well
17:00:16 <Viking-Ice> +1 FE
17:00:23 <Viking-Ice> and let's pull in that fix
17:00:32 <dlehman> right. if accepted as FE I'll just cherry-pick and move along
17:00:56 <dlehman> the patch stops us from leaking the fds, thus fixing the problem
17:01:37 <cmurf> well it's a crash so again policy suggests we block, not FE
17:01:39 <kparal> doesn't this violate " Remove existing storage volumes to free up space, at the user's direction "?
17:02:04 <tflink> and it's a crash on launch, no?
17:02:07 <kparal> yes
17:02:08 <cmurf> yes
17:02:11 <kparal> even that
17:02:14 <tflink> +1
17:02:15 <cmurf> so you can't do anything at all
17:02:27 <adamw> i was still waiting to hear if it affects all existing thinp or just some specific one, but eh
17:02:30 <adamw> at least +1 FE
17:02:31 <kparal> we might have a better criterion for crashes on launch
17:02:41 <cmurf> yes
17:02:51 <dlehman> adamw: it's probably dependent on the naming of the volumes, TBH
17:03:04 <adamw> ok
17:03:20 <adamw> kparal: there's a general catch-all criterion you can use
17:03:41 <adamw> "The installer must run when launched normally from the release-blocking images. "
17:03:47 <adamw> simple enough.
17:03:56 <adamw> this is a conditional breach of that.
17:04:00 <kparal> ok
17:04:06 <dlehman> seems like it'd make sense to have a criterion that the installer cannot crash on startup when run on its own (unmodified) product
17:04:11 <adamw> for crashes anywhere post-launch which we don't specifically cover, "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. " is the one to use
17:04:15 <adamw> dlehman: there is one. :)
17:04:33 <dlehman> so we could use that and move on
17:04:38 <cmurf> yes please
17:05:01 <adamw> ack ack ack
17:05:32 <pschindl> Ok. So any votes for blocker?
17:05:42 <kparal> pschindl: propose blocker please
17:05:50 <pschindl> proposed #agreed 1020111 - AcceptedBlocker - This bug violates criterion: "The installer must run when launched normally from the release-blocking images. "
17:06:02 <cmurf> +1
17:06:03 <kparal> ack
17:06:05 <Viking-Ice> ack
17:06:10 <tflink> ack
17:06:12 <roshi> ack
17:06:18 <cmurf> i thought we were voting
17:06:18 <roshi> +1 retro
17:06:22 <pschindl> #agreed 1020111 - AcceptedBlocker - This bug violates criterion: "The installer must run when launched normally from the release-blocking images. "
17:06:36 <pschindl> #topic (1020974) incorrectly treats a disk with partially corrupt GPT as having no partition at all
17:06:38 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020974
17:06:40 <pschindl> #info Proposed Blocker, anaconda, ASSIGNED
17:06:57 <tflink> pschindl: if you add qualifiers like "for systems with certain lvm setups" to the proposal, it's easier to follow in the minutes
17:07:55 <pschindl> tflink: I will try next time. Thank you.
17:08:18 <Viking-Ice> is this not accepted freeze exeption ?
17:08:28 <tflink> yeah, but we punted on blocker last week
17:09:24 <kparal> I'm OK with moving it to Final
17:09:42 <cmurf> yes i think we ought to officially make it a final blocker and leave it as freeze exception
17:09:45 <cmurf> for beta
17:10:14 <jreznik> ok
17:10:22 <cmurf> bcl was -1 blocker for beta on Monday's conversation
17:10:23 <adamw> i was hoping we'd have more people at this meeting
17:10:28 <adamw> at least we have dlehman this time
17:10:55 <cmurf> i'm on the fence, and i'm going to defer to a dev on this; it's a rather old bug, despite how not good it is
17:11:01 <cmurf> so it's not like the world has ended because of it
17:11:52 <bcl> hm?
17:12:19 <bcl> cmurf: thanks for doing the legwork on this.
17:12:45 <bcl> since it's been around so long I'm non-blockerish on it for beta
17:13:23 <Viking-Ice> should it not be opposit and we should fix it
17:13:30 <dlehman> does pyparted provide any way to use the backup table?
17:13:32 <Viking-Ice> but yeah final at least
17:13:56 <jreznik> yeah, if it's there for such long time, I'm not sure it's urgent fix but I mean - fix it this release (not to wait for another releases as it happens quite often ;-)
17:13:59 <adamw> dlehman: i think cmurf said parted itself acts sensibly, so presumably it should?
17:14:00 <cmurf> bcl: sure no problem
17:14:27 <cmurf> parted does, gdisk does, fdisk does not (separate bug filed on that and a new commit fixing it was put up today)
17:14:52 <dlehman> it is possible to easily call it "corrupt GPT disklabel" instead of "Unknown", but anything beyond that would require pyparted functionality
17:15:15 <bcl> well, we could also make the same argument we do for degraded raids. don't touch it.
17:15:16 <tflink> cmurf: I didn't think fdisk could handle gpt
17:15:39 <dlehman> yeah, I think we should maybe do a better job of calling it what it is, but leave the fixing to the user
17:16:06 <cmurf> tflink: it does now, not sure how recent, i think since whatever went into f19
17:16:07 <adamw> tflink: it grew support lately.
17:16:34 <tflink> cool, I've been using gdisk lately as I really don't like parted
17:16:36 <cmurf> tflink: and it's confusing because i can't figure out how to view the protective mbr or hybrid mbr's with fdisk anymore (major tangednt)
17:16:45 <cmurf> tflink gdisk is awesome
17:17:04 <tflink> it's saved my bacon a couple of times :)
17:17:04 <cmurf> anyway I'm still +1 FE beta, and +1 final blocker
17:17:22 <cmurf> and for beta blocker i'm a 0
17:17:22 <pschindl> proposed #agreed 1020974 - RejectedBlocker - Wrong handling of GPT is around for long time so no need to block beta. This bug will be proposed for Final Blocker and is already accepted as FE for Beta.
17:17:28 <adamw> ack
17:17:34 <cmurf> ack
17:17:36 <Viking-Ice> ack on what
17:17:40 <kparal> ack
17:17:47 <tflink> pschindl: using FE in proposals is not the best thing
17:17:48 <kparal> Viking-Ice: on proposed #agreed
17:17:52 <cmurf> i think we need to make it a blocker now rather than wait 3-4 weeks or whatever
17:17:56 <Viking-Ice> ack
17:18:00 <cmurf> why bother reviewing this again
17:18:06 <cmurf> we all have it in our brain now
17:18:14 <adamw> eh, i don't mind doing that. +1 final
17:18:16 <cmurf> you really want to read this bug again?
17:18:21 <tflink> yeah, same here
17:18:25 <tflink> +1 final blocker
17:18:30 <cmurf> +1 final blocker
17:18:36 <roshi> +1 Final
17:18:40 <Viking-Ice> the solution here based on bcl and dlehman is simply rename the error msg  call it "corrupt GPT disklabel" instead of "Unknown"
17:18:41 <kparal> +1, if it is technically doable by anaconda
17:18:48 <Viking-Ice> +1
17:18:58 <Viking-Ice> and make the end user take action to fix ti
17:19:02 <Viking-Ice> it I mean
17:19:02 <kparal> Viking-Ice: that might actually help as well
17:19:13 <kparal> better than nothing
17:20:17 <pschindl> ok, now I'm not sure, but:
17:20:20 <pschindl> proposed #agreed 1020974 - RejectedBetaBlocker AcceptedFinalBlocker - Wrong handling of GPT is around for long time so no need to block beta. This bug is acceptet as Final Blocker and is already accepted as Freeze Exception for Beta.
17:20:20 <cmurf> it's questionable handling to just flag it as corrupt and not use the GPT disk at all, but better than current behavior
17:20:22 <pschindl> ?
17:20:45 <adamw> i think that was just a side commnet.
17:20:46 <adamw> ack on that
17:20:56 <cmurf> ack
17:21:22 <kparal> ack
17:21:24 <tflink> pschindl: s/acceptet/accepted
17:21:32 <pschindl> any other ack/nack/patch
17:21:35 <Viking-Ice> acl
17:21:38 <Viking-Ice> mean ack
17:21:39 <pschindl> tflink: thanks :)
17:21:40 <roshi> ack
17:21:51 <cmurf> i'm not going to give birth to a bovine if the final result is to just flag such GPT disks and now allow them to be used
17:21:51 <tflink> but ack for everything else
17:21:59 <cmurf> not ideal, but…
17:22:10 <tflink> at least it tells the user that something's wrong
17:22:10 <cmurf> now = not
17:22:15 <pschindl> #agreed 1020974 - RejectedBetaBlocker AcceptedFinalBlocker - Wrong handling of GPT is around for long time so no need to block beta. This bug is accepted as Final Blocker and is already accepted as Freeze Exception for Beta.
17:22:31 <pschindl> and the last one proposed blocker:
17:22:38 <cmurf> tflink: yes although strictly speaking the UEFI spec requires that it get fixed
17:22:38 <pschindl> #topic (1005895) Upgrade to f20 fails because of deltarpms
17:22:40 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1005895
17:22:42 <pschindl> #info Proposed Blocker, fedup, MODIFIED
17:23:10 <cmurf> it's maybe one of the few sorta sane things about the UEFI spec
17:23:38 <cmurf> +1 block, +1 FE
17:23:42 <cmurf> oops
17:23:45 * adamw thought we'd agreed on this one last time
17:23:47 <cmurf> -1 block, +1 FE
17:24:12 <cmurf> yeah we were going to revisit block because we werent totally sure about whether --instrepo left out was a reasonable work around
17:24:15 <adamw> oh right
17:24:18 <Viking-Ice> +1
17:24:43 <kparal> it _seems_ that standard users won't be hit by this, because they don't use --instrepo
17:24:51 <kparal> but I can't vouch for that
17:25:10 <Viking-Ice> do you think the standard user upgrades?
17:25:13 <kparal> but I wouldn't make it a blocker for Beta
17:25:21 <tflink> -1 beta blocker: it won't hit normal users and the workaround isn't bad
17:25:23 <kparal> Viking-Ice: yes, just fedup --network 20
17:25:26 <pschindl> I'm more -1 blocker, +1 FE here.
17:25:41 <Viking-Ice> I'm with adamw on comment 4 here
17:25:56 <Viking-Ice> hence a la blocker
17:26:11 <cmurf> does user documention instruct the use of --instrepo ?
17:26:15 <adamw> Viking-Ice: i wasn't aware at that point that it doesn't happen if you don't pass --instrepo
17:26:17 <kparal> Viking-Ice: it seems that the criterion is not violated
17:26:20 <adamw> cmurf: end-user docs, no
17:26:24 <adamw> the test case does, I think
17:26:36 <jreznik> then it's clear -1 for me
17:26:37 <kparal> adamw: right
17:26:41 <adamw> i'm -1 if the instrepo thing is definite
17:26:44 <cmurf> ok so for users there is no work around needed, their instsructions should give them a working result
17:26:45 <adamw> +1 does not make any sense as it's an f19 bug
17:26:54 <adamw> er, FE does not make any sense
17:26:54 <cmurf> right
17:26:56 <Viking-Ice> if it does not violate the criteria then it's not a blocker or fe in any sense
17:26:59 <cmurf> that's true
17:27:04 <adamw> so just straight -1
17:27:09 <Viking-Ice> -1
17:27:09 <adamw> thanks for the clarification testing, kparal
17:27:10 <cmurf> i forgot that part
17:27:26 <pschindl> you are right, then I'm -1 too
17:28:29 <roshi> -1
17:28:49 <cmurf> i'm counting -5
17:28:50 <pschindl> proposed #agreed 1005895 - RejectedBlocker - This is bug in F19 fedup. To avoid this bug is enough to don't use --instrepo which is default for end users.
17:28:56 <cmurf> ack
17:29:02 <Viking-Ice> ack
17:29:05 <adamw> ack
17:29:22 <kparal> ack
17:29:33 <jreznik> ack
17:29:37 <pschindl> #agreed 1005895 - RejectedBlocker - This is bug in F19 fedup. To avoid this bug is enough to don't use --instrepo which is default for end users.
17:30:00 <pschindl> Ok. That's everything from proposed blockers. Let's move to the proposed FE.
17:30:12 <pschindl> #topic (1021907) simplify keyboard layout display: "English (English (US))" -> "English (US)" etc
17:30:14 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021907
17:30:16 <pschindl> #info Proposed Freeze Exceptions, anaconda, POST
17:31:26 * cmurf is amused by this bug
17:31:40 <adamw> it's down to xkb wackiness
17:31:43 <cmurf> I suggested this when the mockups appeared, in what, July or August?
17:31:43 <adamw> like everything else keyboard-ish
17:31:56 <Viking-Ice> was that not supposted to be fixed properly this release cycle
17:32:02 <Viking-Ice> or is it just like never ending story
17:32:04 <kparal> +1 FE
17:32:07 <Viking-Ice> 1+
17:32:11 <adamw> Viking-Ice: this is a cosmetic issue, not anything like what you're thinking of
17:32:14 <adamw> sorry, but -1 FE
17:32:19 <cmurf> yeah i'm with adamw
17:32:23 <adamw> this is pretty much textbook something that shouldn't be changed during freeze
17:32:27 <cmurf> i'm like, guys this should have been sorted out a LONG time ago
17:32:30 <adamw> right
17:32:35 <cmurf> -1 FE
17:32:36 <tflink> yeah, -1 FE
17:32:43 <pschindl> I'm -1 FE. It can wait after beta
17:32:48 <kparal> ok
17:32:52 <adamw> keyboard selection is vital and very fragile, and we really don't *need* this
17:32:53 <roshi> -1
17:32:57 <Viking-Ice> but people might cry their eyes out when they see this hence cannot finish installing
17:33:01 <jwb> i have a process question towards the end of the meeting if you guys have time
17:33:01 <adamw> Viking-Ice: :P
17:33:02 <Viking-Ice> yeah sure
17:33:04 <Viking-Ice> -1
17:33:07 <roshi> lol
17:33:13 <adamw> jwb: there's always time, in blocker review meetings...:P
17:33:26 <jwb> :)  i'll be patient.  please just ping me at the end?
17:33:27 <cmurf> trust me, i did cry when i saw the mockups and had a WTF moment of all the triplicate output
17:33:34 <adamw> jwb: roger
17:33:45 <adamw> i'm fine with putting this in post-beta when we can pick up the bits if it explodes, of course.
17:33:56 <cmurf> adamw agreed
17:34:42 <Viking-Ice> ack to the reject
17:34:45 <pschindl> proposed #agreed 1021907 - RejectedFreezeException - Keyboard layout names aren't so important to be pushed to beta.
17:35:19 <adamw> ack
17:35:22 <pschindl> I hope that it doesn't sound too much offensive.
17:35:29 <pschindl> ack/nack/patch?
17:35:41 <kparal> ack
17:35:44 <cmurf> ack
17:35:50 <tflink> ack
17:35:59 <pschindl> #agreed 1021907 - RejectedFreezeException - Keyboard layout names aren't so important to be pushed to beta.
17:36:00 <jreznik> ack
17:36:10 <pschindl> #topic (1005482) qtbase FTBFS on ppc/ppc64
17:36:12 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1005482
17:36:14 <pschindl> #info Proposed Freeze Exceptions, qt5-qtbase, ON_QA
17:36:28 <tflink> pschindl: it's terse but to the point. you could add something about it being too risky to take during freeze for something non-critical instead of not being important enough, though
17:36:47 <Viking-Ice> +1FE
17:37:40 <jreznik> +1 FE, it's just qt5, not used anywhere (so it could be broken but...)
17:37:46 <adamw> this seems like an odd process, but meh, +1.
17:38:01 <jreznik> adamw: yep
17:38:02 <tflink> yeah, I still don't understand why this is a blocker
17:38:14 <adamw> well i understand why they want it to go in now
17:38:14 <jreznik> tflink: fe
17:38:29 <adamw> i just don't understand why it *has* to be the case that things have to go stable in primary before they can be built for secondary...
17:38:31 <tflink> jreznik: i don't understand why this is a blocker for power
17:39:05 <jreznik> ah, and I'm not sure why there's that dep on other packages
17:39:05 * cmurf is confused as well
17:39:25 * tflink asked dwa to join
17:39:59 <cmurf> So the request is F20 release beta FE, and F20 PPC beta block, right?
17:40:23 <Viking-Ice> ack to the agreement
17:40:44 <adamw> cmurf: we don't handle secondary arch blockers.
17:40:48 <adamw> the request here is purely beta FE.
17:40:56 <cmurf> got it
17:41:15 <adamw> the *reason* we've been provided is that they desperately need to build this for PPC (secondary arch), and apparently they can't do that unless it's stable for primary.
17:41:38 <tflink> sure, but it's qt5. what's actually using qt5?
17:41:55 <tflink> on top of the bit about why it has to be stable for primary
17:42:23 <cmurf> if it's a PPC only change, why are we discussing it?
17:42:32 <cmurf> why does it affect the F20 momma release?
17:42:44 <tflink> that's what we're trying to figure out :)
17:42:46 <Viking-Ice> people hello!
17:42:48 <adamw> it's not PPC only. they want us to push it stable *for primary*. so they can build it for secondary.
17:42:51 <cmurf> comment 19: "This is a small/safe ppc-only change"
17:42:54 <adamw> anyhow, +1, whatever.
17:43:13 <adamw> cmurf: any rebuild of a package comes with some risk of borkage. but we don't need to care much about qt5 borking.
17:43:23 <pwhalen> +1
17:43:26 <cmurf> finefine +1 FE
17:43:30 <tflink> -1 - this is silly and I don't see a reason to push stuff without justification
17:44:00 <cmurf> i'm with tflink on the sentiment, honestly
17:44:16 <tflink> 11:43 < dwa> tflink: it doesn't have to be stable to be built but we sync tags with primary, so if it's not stable on  primary it doesn't get pushed to the mirrors on secondary
17:44:39 <dwa> that's dgilmore's policy, fyi ^^^
17:44:50 <Viking-Ice> shrug "This is a small/safe ppc-only change, little to no risk elsewhere.  With fix in hand, I thought this could be a no-brainer"
17:45:07 <jreznik> and how does it block poppler/libreoffice?
17:45:26 <adamw> dwa: when you say 'pushed to the mirrors', what do you mean? pushed to the 'stable' (fedora) repo? pushed to u-t? what?
17:45:35 <Viking-Ice> pschindl, throw in either agreed or rejected
17:45:48 <dwa> jreznik: it's a build requirement.
17:45:52 <cmurf> yeah maybe it should just be in updates-testing until it goes stable on primary
17:46:03 <dwa> adamw: all of the above.
17:46:19 <tflink> it has to be stable on primary before it gets u-t on power?
17:46:23 <adamw> jreznik: poppler has a qt5 sub-package
17:46:29 <adamw> which probably nothing at all uses, but eh
17:46:41 <dwa> adamw: if something is in updates-testing on primary, it's in updates-testing on secondary. We can't make it be stable on secondary but uupdates-testing on primary
17:46:50 <adamw> why do you need it to be stable?
17:46:57 <adamw> you can build against stuff in u-t, iirc.
17:47:10 <tflink> adamw: poppler is part of gnome - it's blocking their release, i iamgine
17:47:14 <tflink> er, used in gnome
17:47:28 <jreznik> adamw: wow, I wasn't aware poppler is so progressive
17:47:34 <tflink> so if poppler can't build due to a subpackage failure, they can't build stuff like a pdf reader
17:47:42 <jreznik> I got it now
17:47:45 <dwa> we can build since we force it in
17:48:16 <dwa> but user experience can potentially break if e.g. they don't have updates-testing enabled, a package isn't stable, but it's a dependency of something they want
17:48:40 * adamw still +1, let's just move on.
17:48:43 * Viking-Ice turns on highlander 2 which is about much waste of time discussing this
17:48:44 <cmurf> so it's a lesser of two evils vote
17:48:44 <tflink> +1
17:48:46 <cmurf> +1 FE
17:49:00 <cmurf> viking-ice no highlander 3
17:49:04 <jreznik> +1 FE
17:49:06 <pschindl> proposed #agreed 1005482 - AcceptedFreezeException - Not sure about wording. Please propose something :)
17:49:13 <Viking-Ice> finally ack!
17:49:14 <pschindl> -/-/patch ?
17:49:15 <tflink> on a side note, how many people have graphical DEs on a power box?
17:49:17 <pwhalen> ack
17:49:28 <cmurf> haha ack "not sure about wording"
17:49:48 <Viking-Ice> tflink, who has graphical DE's on server install <nobody>
17:49:49 <roshi> lol
17:49:56 <dwa> tflink: many more than I thought. I've proposed removing graphical DE requirements from our release criteria and have been soundly smacked by IBM
17:50:08 <tflink> proposed #agreed 1005482 - AcceptedFreezeException - This is effectively blocking builds of poppler and libreoffice on ppc and would be a blocker on PA. A tested fix would be considered past freeze.
17:50:16 <Viking-Ice> ack
17:50:23 <pschindl> ack
17:50:31 <pschindl> tflink: Thank you very much
17:50:35 <tflink> np
17:50:36 <adamw> ack
17:50:41 <jreznik> ack
17:50:43 <cmurf> dwa: that's interesting, I wonder if they're using someof this code in their image recognition software
17:50:43 <tflink> #agreed 1005482 - AcceptedFreezeException - This is effectively blocking builds of poppler and libreoffice on ppc and would be a blocker on PA. A tested fix would be considered past freeze.
17:50:48 <cmurf> ack
17:50:56 <pschindl> #topic (1019501) anaconda lock-up for some time when opening/closing modal dialogs
17:50:59 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1019501
17:51:01 <pschindl> #info Proposed Freeze Exceptions, xfce4-session, NEW
17:51:12 <kparal> pschindl: I closed that
17:51:37 <adamw> +1
17:52:14 <pschindl> And the dupe is already Beta Freeze Exception
17:52:34 <adamw> then we're fine
17:52:59 <pschindl> ok. Then that's all from proposed freeze exceptions :)
17:53:03 <pwhalen> I proposed a FE right before the meeting not sure if its coming up
17:53:35 <adamw> pwhalen: bug # ?
17:53:43 <pschindl> 1022604?
17:53:45 <tflink> 1022604, I think
17:53:46 <pwhalen> 1022604
17:53:47 <pwhalen> yes
17:54:05 <pwhalen> sorry for the late addition
17:54:19 <pschindl> #topic (1022604) Wandboard requires kernel-3.11.6-301.fc20 for working serial console in F20 Beta
17:54:21 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1022604
17:54:23 <pschindl> #info Proposed Freeze Exceptions, kernel, MODIFIED
17:54:29 <pwhalen> thanks
17:54:51 <adamw> +1
17:54:51 <pschindl> hopefully it won't take one hour :)
17:55:04 <pwhalen> this is fixed with this kernel build, I've tested on all arm platforms for any regression. the scope of the patch for the bbb was reduced
17:55:15 <pwhalen> +1
17:55:19 <tflink> did you all coordinate with kernel folks this time?
17:55:23 <Viking-Ice> ?
17:55:36 <Viking-Ice> how invasive is pulling a new kernel release going to be
17:55:49 <pwhalen> tflink, I coordinate with kylem, but no I havent discussed it with anyone else
17:56:51 <tflink> I'd rather find out about the scope of what all has change
17:57:00 <tflink> fwiw, that kernel seems to be running fine for me
17:57:22 <cmurf> two items
17:57:23 <cmurf> aarch64: add AFTER_LINK to $vdsold for debuginfo generation of the vdso.
17:57:29 <cmurf> Reduce scope of am335x-bone.patch, as it broke serial on Wandboard.
17:57:43 <cmurf> that's between -300 and -301
17:57:46 <tflink> does that mean that bbb console won't work anymore?
17:58:01 <pwhalen> Ive asked kyle to join us, perhaps jwb could comment?
17:58:27 <kylem> what's up?
17:58:28 <pwhalen> tflink, bbb is fine. all arm platforms were tested
17:59:04 <pwhalen> kylem, thanks for joining, we're wondering if there could be any issues on other arches with the 301 kernel
17:59:07 <pwhalen> or expected
17:59:18 <jwb> i don't suspect there will be
17:59:19 <tflink> stable fc20 is 3.11.6-300 right now
17:59:29 <kylem> it's unlikely -- other people run stuff out of updates-testing, so we'd have heard about it
17:59:57 <Viking-Ice> +1FE
17:59:59 <tflink> so according to the changelog, it's just the two arm changes
18:00:02 <tflink> +1 FE
18:00:17 <roshi> +1 FE
18:00:19 <pschindl> proposed #agreed 1022604 - AcceptedFreezeException - Pushing in kernel-3.11.6-301.fc20 will allow Wandboard to use serial console. Kernel team asured as that there aren't any regressions with new kernel.
18:00:23 <cmurf> ack
18:00:26 <pwhalen> ack
18:00:30 <Viking-Ice> ack
18:00:35 <cmurf> we're a week from a viable go-no/go, at least
18:00:41 <adamw> ack
18:00:44 <cmurf> we're going to end up with a  newer kernel than 301 i bet
18:00:53 <roshi> ack
18:00:59 <pschindl> #agreed 1022604 - AcceptedFreezeException - Pushing in kernel-3.11.6-301.fc20 will allow Wandboard to use serial console. Kernel team asured as that there aren't any regressions with new kernel.
18:01:04 <pwhalen> cmurf, agreed :)
18:01:28 <cmurf> should we have a raffel after feature freeze guessing the kernel version for ship?
18:01:33 <pschindl> That should be all from proposed whatever. Did I forgot something?
18:01:38 <cmurf> kernel devs are disqualified obviously
18:01:43 <cmurf> :P
18:01:46 <pwhalen> thanks pschindl
18:01:48 <pschindl> Or can we moved to the accepted bugs?
18:02:03 <Viking-Ice> should we pull in jwb at this time
18:02:06 <pschindl> pwhalen: I should look at list later then I did :)
18:02:18 <tflink> Viking-Ice: I thought we were waiting for open floor for that?
18:02:21 <Viking-Ice> will he be around after another hour
18:02:26 <jwb> yeah, i can wait
18:02:29 <Viking-Ice> ok
18:02:35 <adamw> ok, let's get through acceptedblockers then
18:02:39 <jwb> i can even ask offline, so please don't wait for me
18:02:42 <jwb> it isn't a big deal
18:02:47 <pschindl> #topic (1021258) requires user manually create biosboot when using guided partitioning
18:02:47 <cmurf> crack the whip
18:02:49 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021258
18:02:51 <pschindl> #info Accepted Blocker, anaconda, NEW
18:03:12 <cmurf> this appears to be fixed
18:03:55 <cmurf> tick tock
18:03:56 <cmurf> next
18:04:42 * cmurf 3D prints everyone a cup of coffee
18:04:43 <pschindl> But what's the status of that fix?
18:05:10 <cmurf> fair point, i expect it in 20.25.3
18:05:23 <cmurf> but maybe bcl can comment
18:05:36 <bcl> hm?
18:05:44 <bcl> got a fix.
18:05:54 <bcl> fallout from my bootloader shuffle.
18:06:09 <bcl> also fixes the uefi multiple ESP regression.
18:06:21 <cmurf> the /boot/efi part is working for me already in 20.25.2 without this but i have Apple EFi so it might behave differently
18:06:22 <pschindl> #info 1021258 is fixed. Fix should be in 20.25.3
18:06:29 <pschindl> anything else here?
18:06:39 <bcl> just trying to get all the ducks lined up so I can post stuff.
18:07:17 <cmurf> did we get a net split?
18:07:35 * adamw just went to do something else for a minute
18:07:42 <adamw> has now forgotten what it is
18:07:50 <adamw> what did I come in here for? who are you? why are you on my lawn?
18:07:53 * Viking-Ice goes for his shot of nikotine
18:08:14 <cmurf> adamw: so much for cracking the whip
18:08:26 <cmurf> i think we can move along to the next bug
18:08:36 <pschindl> #topic (986575) installer fails to apply lower bound to resize requests in custom spoke
18:08:38 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=986575
18:08:40 <pschindl> #info Accepted Blocker, anaconda, ASSIGNED
18:09:13 <cmurf> if i recall correctly dlehman said this was the tough one to fix
18:10:25 <pschindl> cmurf: so no progress here during last days?
18:10:28 <cmurf> nope, this one is the simple one
18:10:58 <cmurf> from 10-16 log iit's the simple fix
18:11:39 <adamw> bcl: dlehman: status?
18:12:00 <bcl> no idea
18:13:00 <cmurf> i'd move on, it's the simple one. the PITA one is the one we might want a better ETA on
18:13:48 <pschindl> ok. So who is volunteer for pushing dlehman about this one?
18:14:03 <jreznik> pschindl: me will try to :)
18:14:39 <cmurf> next
18:14:42 <pschindl> #action jreznik to ask dlehman for status of 986575
18:15:06 <pschindl> #info no visible progress on 986575
18:15:15 <pschindl> #topic (1016959) ValueError: Cannot remove non-leaf device 'btrfs.14'
18:15:18 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016959
18:15:20 <pschindl> #info Accepted Blocker, anaconda, NEW
18:15:23 <pschindl> jreznik: thanks :)
18:16:28 <cmurf> so this one falls into the unspoken category of whether we need a "technology preview" stamp for btrfs stuff or if we hold firm on maintaining parity in quality between it and say ext or xfs
18:17:09 <cmurf> in any case i'm not sure of the fix status, so the action and info are the same as the last one
18:17:20 <jreznik> cmurf: I'm still more inclined to technology preview, we don't have resource to keep parity in quality seems like
18:17:50 <Viking-Ice> why do you say that
18:18:04 <cmurf> we have lots of btrfs bugs that hold things up
18:18:25 <Viking-Ice> as well as lots of bugs in other places
18:18:25 <Viking-Ice> and
18:18:27 <cmurf> and because of that, some of them allowed to slip
18:18:29 <adamw> i'm not sure to what extent it's that we don't have resources to maintain it, and to what extent it's that it's a new thing we're still shaking bugs out of..
18:18:36 <adamw> we have a lot of bugs for thinp too, because that's another thing
18:18:39 <adamw> another new thing*
18:18:58 <cmurf> adamw: yes and i wonder if that should have been tech preview for f20 also, but that ship has sailed
18:18:59 <adamw> though, i suppose btrfs has now been in this state for quite a while
18:19:21 <tflink> cmurf: well, it was supposed to be a low-risk and drop in feature :)
18:19:35 * adamw sometimes wonder why we maintain what is apparently the world's most complex GUI partitioner in our installer as well, but that's also a sailin' ship.
18:19:35 <Viking-Ice> so what's the baseline you guys are deciding here
18:20:08 <Viking-Ice> last time I check josef was still with us still fixing bugs despite leaving RH
18:20:13 <adamw> i'm not sure if we're deciding anything complex or just having a moanfest
18:20:21 <adamw> er, concrete
18:20:25 <cmurf> moanfest
18:20:40 <cmurf> i think we need to schedule this for a separate conversation with some people including dlehman
18:20:52 <cmurf> and maybe josef or eric
18:20:56 <pschindl> cmurf: +1
18:21:01 <cmurf> eric sandeen
18:21:04 <Viking-Ice> we have to move forward at somepoint and if the installer offers btrfs as an install option then we support it
18:21:18 <Viking-Ice> to the extent we support things in the distro
18:21:32 <cmurf> we should have an official status for it rather than unofficial
18:21:44 <cmurf> that way we aren't arguing so much about what quality level to assess
18:21:44 <adamw> well, so far as our processes are concerned, we do.
18:21:49 <jreznik> ask fesco? they have meeting right now
18:21:53 <adamw> it's in the beta criteria.
18:22:04 <cmurf> well ok if it's equal to ext4 and xfs, then we have to block on all of this stuff until it gets fixed
18:22:16 <adamw> guided part "Complete an installation using any combination of disk configuration options it allows the user to select ", and custom part explicitly lists "btrfs volumes" alongside ext4 and lvm in various spots.
18:22:17 <cmurf> and i can't answer if that's really reasonable
18:22:19 <jreznik> I don't see any plans on taking brtfs now as default fs anytime soon...
18:22:31 <Viking-Ice> cmurf, the only one that can answer that is josef
18:22:37 <cmurf> or eric sandeen
18:22:43 <jreznik> adamw: I'm not arguing it's there
18:22:43 <cmurf> whoever is available
18:22:53 <Viking-Ice> dont think eric is involved in that
18:22:55 <adamw> if we wanted btrfs to be a tech preview, it'd probably be appropriate to do it the way we used to: hide it from anaconda with a kernel param.
18:22:55 <tflink> jreznik: after a certain point, that becomes circular logic, though. if we don't fix stuff, it'll never seem ready for default
18:22:57 <cmurf> he is
18:23:03 <adamw> but yeah, running ahead of oursewlves.
18:23:25 <cmurf> i just mean a status that makes it easier to FE things rather than block them
18:23:40 <cmurf> which then comes with its own baggage of bugs stacking up
18:23:49 <jreznik> tflink: yes but with plan to make it default, we can focus, not loosing a lot of time on something one day could be default or not (and focus on things we need now)... otherwise I'm fan of release early, fix early :)
18:23:59 <jreznik> cmurf: +1
18:24:15 <tflink> we have ~ 30 minutes left til the end of the meeting
18:24:22 <Viking-Ice> well regarding the installer if it's offered it means blockage
18:24:36 <cmurf> yeah, i'll work with adamw and anyone else to maybe propose something for fesco to answer our questions if that's the right away to do it
18:24:50 <pschindl> #info Nothing changed on 1016959 for a long time. This will need further discussion.
18:24:53 <Viking-Ice> regarding it being the default josef will push for that when he thinks it's ready
18:24:53 <cmurf> as for this bug, it's a blocker and we'll have to ask dlehman about it
18:25:10 <Viking-Ice> ( which is not now )
18:25:18 <cmurf> Viking-Ice: understood but xfs is not default but still has quality parity with ext4 if something doesn't work
18:25:41 <jreznik> Viking-Ice: you can offer it and warn about "technology preview"
18:25:43 <cmurf> Viking-Ice: so the question is do we block on btrfs for the same things not working as ext4 and xfs or lvm, etc. or do we cut the devs slack
18:25:45 <pschindl> let's move on and discuss after meeting.
18:25:56 <cmurf> pschindl: agreed
18:26:00 <Viking-Ice> sure
18:26:02 <pschindl> #topic (1012504) FSError: filesystem already exists
18:26:05 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012504
18:26:06 <jreznik> do we want to ask fesco now on brtfs plans?
18:26:06 <adamw> practically speaking, we really need at least an estimate from anaconda team on how long it's going to take to address all the outstanding blockers
18:26:07 <pschindl> #info Accepted Blocker, anaconda, ASSIGNED
18:26:27 <cmurf> adamw: that's the present question that matters, yes
18:26:29 <adamw> jreznik: i'd rather not lob a very vague 'we're worried about btrfs' bomb at fesco
18:26:29 <cmurf> here's another one
18:26:31 <Viking-Ice> jreznik, fesco dont have any plans until josef proposes it I would think
18:26:40 <adamw> jreznik: with our knowledge of how focused fesco meetings tend to be
18:26:53 * adamw tends to think of fesco as a small infant to be spoon fed very precise things in easily digestible packages
18:26:59 <cmurf> rofl
18:27:02 <jreznik> adamw: :D
18:27:25 <jreznik> it could end with brtfs default for f20, sure, move on
18:27:36 <adamw> if we just say 'hey, btrfs, what do you think?' they're likely to wind up with a proposal to move up the release five months and remove raid support, or something.
18:27:41 <jwb> jreznik, no it couldn't
18:27:43 <adamw> :P
18:28:04 <Viking-Ice> anywho
18:28:07 <Viking-Ice> NEXT
18:28:13 <cmurf> ok so the current bug is reproducible
18:28:24 <cmurf> it was marked as blocker but closed because it wasn't reproducible at that time
18:28:49 <cmurf> Reartes came up with reproduce steps, I've confirmed. So it's a blocker now, reopened.
18:29:31 <cmurf> gist is that you use the recommended btrfs layout (boot is on ext4) and you get an explosion when anaconda tries to reformat the newly created btrfs volume as ext4
18:30:23 <Viking-Ice> but there is no movement on this one right?
18:30:26 <cmurf> i posted a screencast, it's easily reproducible
18:30:28 <cmurf> no
18:30:39 <cmurf> so like the previous two, ask dlehman for update
18:30:39 <pschindl> ok another one which doesn't move on.
18:31:06 <pschindl> jreznik: Would you ask dlehman about all his blockers?
18:31:28 <Viking-Ice> add it to jreznik list ;)
18:31:28 <jreznik> pschindl: yeah, hope he won't kill me :)
18:31:41 <pschindl> #action jreznik to ask dlehman about status of all his none moving blockers.
18:31:42 <cmurf> just start the conversation with "about this btrfs stuff"
18:31:47 <pschindl> jreznik: thank you :)
18:32:14 <cmurf> wrap it all into one nice package with sparklers attached
18:32:26 <pschindl> #info There is no progress in 1012504 too.
18:32:45 <pschindl> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device
18:32:48 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495
18:32:50 <pschindl> #info Accepted Blocker, anaconda, ASSIGNED
18:33:09 <cmurf> bcl
18:33:15 <cmurf> mac efi fix?
18:35:22 <cmurf> a week ago it was in refinement, it's possible this is rolled into the biosboot fix from earlier
18:35:48 <tflink> possible, but the anaconda folks are usually pretty good about marking bugs as the code is submitted
18:35:53 <jreznik> he told me, he's going to take a look this week last time I talked to him early this week
18:35:58 <cmurf> i didn't hit this bug with unpatched 20.25.2-1 yesterday
18:37:03 <cmurf> hmmm
18:37:11 <pschindl> hmmm?
18:37:24 <cmurf> well if it hasn't been patched i'm not sure why i didn't run into the bug
18:37:54 <adamw> planetary alignment
18:37:55 <pschindl> cmurf: miracle? :)
18:38:45 <cmurf> i'm a bug magnet, so maybe my charge was off last time i tested
18:38:49 <jreznik> anyone to retest?
18:39:04 <jreznik> otherwise I'll ask bcl later/or anyone else to ping him later
18:39:12 <pschindl> jreznik: send me mac and I will gladly test it :)
18:39:18 <tflink> pschindl: you have a mac
18:39:27 <tflink> or did you guys get rid of the mini
18:39:56 <cmurf> ok with 20.25.2-1 i'm not getting this error that's all i can say
18:39:57 <pschindl> tflink: you are right. I can test it tomorrow
18:40:20 <bcl> cmurf: no progress
18:40:48 <tflink> are all of the other anaconda blockers assigned to dlehman?
18:40:56 <cmurf> bcl: yokay
18:41:04 <cmurf> tflink: yes, but not the current one
18:41:22 <pschindl> #info There is no progress in 1010495 since last meeting.
18:42:06 <tflink> no, 1008633 and 1021258 arent. 1022206 isn't assigned to anyone specific
18:42:37 <tflink> but 5/9 anaconda blockers are assigned to the same person
18:42:38 <tflink> oof
18:42:39 <jreznik> pschindl: please, try it tomorrow
18:43:09 <jreznik> tflink: yeah, that's what makes me afraid and in the area probably not many people can touch except him
18:43:10 <pschindl> #action pschindl to reproduce 1010495
18:44:10 <cmurf> pschindl: make sure the disk isn't empty as that doesn't trigger the bug
18:44:32 <tflink> let's keep moving, though. we only have 15 minutes left
18:44:45 <jreznik> maybe we should start thinking about documented workarounds for some of these bugs (if possible)
18:44:53 <pschindl> cmurf: thanks I will do my best :) (or I will pass it to another person :) )
18:45:09 <cmurf> pschindl: ping me if you have issues i know more about the issue than i want to
18:45:27 <pschindl> #topic (1000891) DVD is oversized (larger than 4.7 GB)
18:45:29 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891
18:45:31 <pschindl> #info Accepted Blocker, distribution, MODIFIED
18:45:32 <tflink> jreznik: that's a slippery slope if you're suggesting what I think you are
18:45:54 <cmurf> jreznik: yes for the Apple EFI bug, while not pretty, it is possible to document a workaround involving custom partitioning
18:45:57 <tflink> looks like we're still waiting on dgilmore here
18:46:39 <pschindl> #info We are waiting on dgilmore with 1000891
18:46:42 <adamw> dgilmore's on vacation in london
18:46:46 <adamw> i thought i'd noted that at some point
18:46:57 <kparal> when he returns?
18:46:57 <cmurf> oops
18:47:01 <adamw> we really probably need to get someone else to look at it, or else we're waiting for him to be back. of course, looks like we're slipping anyway.
18:48:01 <cmurf> ok next
18:48:02 <jreznik> adamw: I'll ask dmach again
18:48:25 <pschindl> #info and dgilmore is on vacation so we should find someone to fix it instead of him or wait for him
18:48:53 <pschindl> #topic (1013767) rootfs on thinp not found, startup failure
18:48:55 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013767
18:48:57 <pschindl> #info Accepted Blocker, dracut, ON_QA
18:49:34 <tflink> looks to need re-testing
18:49:45 <cmurf> works
18:49:55 <adamw> if re-testing is good, set VERIFIED?
18:50:31 <pschindl> So there is no regression (as mentioned in comment 34)?
18:50:33 <cmurf> it might be a good idea if someone verifies my verify
18:50:41 <cmurf> uncertain
18:50:47 <cmurf> i tested and could not reproduce that regression
18:51:02 <cmurf> bug then 034-19 appeared associated with the regression bug
18:51:22 <cmurf> so i think there may have been an edge case regression and 034-19 fixed it
18:51:48 <cmurf> bug=but
18:52:22 <pschindl> #info There is a fix which needs to be verified. Cmurf has already tested and hasn't found regression. 034-19 should fix regression and bug
18:52:32 <cmurf> good
18:52:43 <pschindl> #topic (1015234) F20 Beta TC1 ARM disk images unable to find root filesystem
18:52:46 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1015234
18:52:48 <pschindl> #info Accepted Blocker, dracut, ASSIGNED
18:53:11 <pwhalen> this is fixed..
18:53:33 <tflink> is it?
18:53:42 <tflink> c#22 makes is sound only half fixed
18:53:59 <cmurf> c22 sounds hardware related though
18:54:22 <pwhalen> the initial bug i filed. we're using dracut config generic as a work around. the resizing issue is being looked at, linked in the last comment
18:54:29 <tflink> the trimslice part, yes. but it also sounds like this is somewhat broken for mmc still
18:54:58 <pwhalen> the resize is broken on all mmc's, does nothing.
18:55:47 <adamw> still, 'resize does nothing' probably isn't a blocker?
18:56:27 <pwhalen> there is a valid work around using gparted on another system
18:56:42 <tflink> ok
18:56:50 <tflink> so, can be set to VERIFIED?
18:56:57 <pwhalen> but its being looked at, and should be fixed soon. I thought we could remove the modules and call it a day, they do nothing.
18:57:23 <pwhalen> sure, it was closed and reopened
18:57:37 <tflink> ok, cool.
18:57:39 <jreznik> so mark this one as verified and move to another bug that resize bg
18:57:48 * tflink notes that we have 3 minutes left to the 3 hour mark
18:58:01 <pwhalen> verified
18:58:22 <pschindl> #info The original problem has been fixed.
18:58:46 <pschindl> That's all from accepted blockers
18:59:15 * adamw can very quickly stick jwb's question and answer in
18:59:25 <adamw> question was 'why don't we do async voting in the blocker bug app or bugzilla?'
18:59:42 <tflink> I can answer that, if you'd like
18:59:43 <adamw> answer is 'we avoid voting in BZ where possible because people don't like the spam it generates; we'd like to do voting in the app but it needs to get written'
18:59:52 <adamw> i think i got the party line down :)(
18:59:57 <jwb> yep!  thanks for that
19:00:08 <tflink> yeah, martin has some very basic code for that feature but it's nowhere near ready for deployment
19:00:37 <cmurf> fyi i'm not seeing acceptedblocker 1013586 reviewed, did i miss it?
19:01:17 <tflink> cmurf: I don't see it on the list for beta
19:01:18 <cmurf> oh never mind
19:01:22 <cmurf> it was moved to final
19:01:38 <cmurf> someone fire cmurf
19:01:51 <kparal> .fire cmurf
19:01:52 <zodbot> adamw fires cmurf
19:02:03 <adamw> zzzzwha?
19:02:04 <adamw> :P
19:02:12 <cmurf> hey i asked for it
19:02:31 <pschindl> :)
19:03:33 <pschindl> Ok. We are here overtime. So we will let accepted freeze exceptions for another time.
19:04:07 <pschindl> I will try to go through them tomorrow.
19:04:13 <pschindl> For now.
19:04:59 <jreznik> thanks pschindl for leading it today
19:05:08 <pschindl> When will be next blocker bug meeting?
19:05:31 <pschindl> jreznik: I think I've lost my last hairs :)
19:05:31 <tflink> monday, if we slip
19:05:38 <pschindl> ok
19:05:39 <cmurf> if?
19:05:45 <jreznik> just a note - monday is bank holiday here
19:05:48 <tflink> it hasn't been decided yet
19:06:23 * cmurf thinks jesus will have to do a fish multiplying trick on some developers for it not to slip
19:06:24 * jreznik will be available
19:07:04 <pschindl> #info Next meeting time - 16:00 UTC on 28th October if we slip (and we probably will)
19:07:49 * pschindl won't be available because has to sing in choir on next Monday
19:08:20 <pschindl> does anyone has something to say before I will end this meeting?
19:08:34 <adamw> newp
19:09:10 <cmurf> tc6?
19:09:36 <cmurf> guess we need some anaconda/blivet updates to make that worthwhile
19:09:37 <pschindl> ok. So thank you all for coming and not throwing stones at me :)
19:09:45 <cmurf> why would we do that?
19:10:16 <tflink> pschindl: you're not counting the delay for how long it takes a stone to get to you from here :)
19:10:31 <tflink> remember to duck sometime next week :-P
19:10:32 <cmurf> this is a pyrotechnic group, you'd be ignited if anything
19:10:46 <tflink> stone/brimstone
19:10:53 <pschindl> tflink: you can send it by post, I will throw it on me myself :)
19:11:00 <roshi> haha
19:11:09 <cmurf> TC6?
19:11:44 <pschindl> cmurf: You are right, we have to wait for some anaconda updates to make it worthwhile.
19:11:59 <pschindl> let's move this discussion to #fedora-qa
19:12:04 <tflink> meh, that sounds like too much work. http://upload.wikimedia.org/wikipedia/commons/c/c9/Cuff_Hill_logan_stone_2.JPG
19:12:11 <pschindl> thanks for coming
19:12:20 <cmurf> that's not a stone!
19:12:34 <kparal> my sessions just restarted, great
19:12:46 <kparal> pschindl: thanks for leading
19:12:46 <tflink> stone/boulder ... whatever :)
19:12:53 <pschindl> #endmeeting