16:00:53 <roshi> #startmeeting F22-blocker-review
16:00:53 <zodbot> Meeting started Mon May 18 16:00:53 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:53 <roshi> #meetingname F22-blocker-review
16:00:53 <zodbot> The meeting name has been set to 'f22-blocker-review'
16:00:54 <roshi> #topic Roll Call
16:00:59 * kparal is here
16:01:00 <roshi> who's around?
16:01:02 * roshi is here
16:01:11 <gbcox> Listening
16:01:15 * kalev is here
16:01:29 * satellit listening    have to leave early
16:01:31 <roshi> #chair kparal kalev
16:01:31 <zodbot> Current chairs: kalev kparal roshi
16:01:34 * pschindl is here
16:01:43 <roshi> sweet, got a good turnout :)
16:01:55 <roshi> onto the boilerplate!
16:01:58 <roshi> #topic Introduction
16:01:58 <roshi> Why are we here?
16:01:58 <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:02:02 <roshi> #info We'll be following the process outlined at:
16:02:05 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:02:07 <roshi> #info The bugs up for review today are available at:
16:02:10 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:02:12 <roshi> #info The criteria for release blocking bugs can be found at:
16:02:15 <roshi> #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria
16:02:18 <roshi> #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
16:02:21 <roshi> #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria
16:02:28 <roshi> looks like we have 9 proposed blockers and 4 proposed FEs
16:02:45 <kparal> so much fun
16:03:07 <roshi> :)
16:03:14 <roshi> #topic (1219264) Intel firmware RAID set does not appear in INSTALLATION DESTINATION in live installer
16:03:16 <kparal> pschindl: rock-paper-scissors for the secretary job?
16:03:17 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219264
16:03:20 <roshi> #info Proposed Blocker, anaconda, NEW
16:03:38 <pschindl> kparal: I can do it today.
16:03:45 <kparal> pschindl: great answer!
16:03:59 <kparal> thanks :)
16:04:19 <roshi> so, does that mean he won or lost rock paper scissors?
16:04:28 * danofsatx is present
16:04:54 <roshi> #chair danofsatx pschindl
16:04:54 <zodbot> Current chairs: danofsatx kalev kparal pschindl roshi
16:04:58 <danofsatx> he played.
16:07:01 <kparal> pschindl: our fwraid works fine, right?
16:07:06 <pschindl> -1 here. I haven't met it yet on firmware raid.
16:07:07 <roshi> from reading the comments on this one I guess I'm ok with a -1
16:07:18 <roshi> since it did the same thing for F21
16:07:34 <kparal> "as that reporter suggested, I tried recreating the RAID set and now both F21 and F22 lives see it"
16:07:36 <danofsatx> -1
16:07:38 <pschindl> I tried it with TC3 and it worked.
16:08:05 <roshi> the only issue with that is if you had data on the set and wanted to preserve it
16:08:13 <roshi> but netinst seems to work fine?
16:08:17 <danofsatx> TC3 and TC4 here. I didn't log in in the tracker, but it worked
16:08:35 <roshi> -1 then
16:08:45 <kalev> I think I'd be -1 blocker as well, given that it's not a regression from F21 and there's an easy enough workaround
16:08:53 <kparal> -1/+1 we don't know how to reproduce it and we don't have any further reports of this, but could be considered if devs manage to find and fix it
16:09:03 <kalev> could mark it as a +1 FE though, in case the Anaconda people come up with a fix
16:10:12 <pschindl> I'm not sure with FE. Is fix safe?
16:10:17 <gbcox> Just a question, does this condition get somehow marked in the release notes?
16:10:32 <roshi> proposed #agreed - 1219264 - RejectedBlocker AcceptedFreezeException - We haven't found clear reproduction steps, there's an easy workaround and more reports haven't shown up, so rejecting as a blocker. Accepted as an FE if the devs can make a sane fix for this.
16:11:13 <roshi> pschindl: I'd want to test it thoroughly, but any regression should show up early and be reverted easily
16:11:13 <kparal> pschindl: we'll consider the fix if it shows up
16:11:34 <pschindl> ok. ack
16:11:38 <kalev> ack
16:11:41 <kparal> pschindl: I would be wary about the fix as well
16:11:41 <kparal> ack
16:11:49 <roshi> #agreed - 1219264 - RejectedBlocker AcceptedFreezeException - We haven't found clear reproduction steps, there's an easy workaround and more reports haven't shown up, so rejecting as a blocker. Accepted as an FE if the devs can make a sane fix for this.
16:11:56 <roshi> #topic (1222262) liveinst in f22-kde-live-TC4 fails to start
16:11:56 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1222262
16:11:56 <roshi> #info Proposed Blocker, anaconda, POST
16:12:31 <roshi> -1
16:12:33 <roshi> GUI works
16:12:47 <roshi> afaik, we never supported a cmdline start of anaconda like that
16:12:50 <jreznik> as I commented in the bug -1 blocker, it works from GUI and that's the way how most people will use it and for CLI, there's simple workaround -> common bugs
16:12:53 <kalev> yep, -1 blocker since GUI is what I'd expect almost everybody to use
16:12:53 <danofsatx> -1
16:12:53 <kparal> roshi: the problem is you might need to use --updates
16:12:56 <roshi> if it worked, great - but the GUI was the default
16:13:05 <kparal> or some other arg
16:13:21 <roshi> right
16:13:35 * satellit_e liveinst is only way to install soas (not blocking)
16:13:38 <roshi> but we don't have a "installation has to work from cmdline in terminal" criteria
16:14:01 <jreznik> but +1 FE for soas if it makes Anaconda builds, patch seems to be ok
16:14:12 <roshi> that's the *only* way to install soas?
16:14:19 <kparal> I'm fine with -1/+1 and CommonBugs
16:14:21 <roshi> it's not an option in the netinst?
16:14:27 <satellit_e> yes in sugar-terminal app
16:14:28 <danofsatx> -1/+1
16:14:34 <kparal> if you need --updates, you'll probably also read about this one
16:14:46 <jreznik> although it's under review and question is other env vars should get the same treatment (and in that case I'd be less +1 FE)
16:15:43 <roshi> proposed #agreed - 1222262 - RejectedBlocker AcceptedFreezeException - This breakage isn't considered blocking since the GUI works for installation. A fix would be considered during freeze.
16:15:51 <satellit_e> +FE if it does not cause other problems
16:15:55 <kalev> ack
16:16:02 <jreznik> ack
16:16:07 <kparal> ack
16:16:08 <pschindl> ack
16:16:12 <roshi> #agreed - 1222262 - RejectedBlocker AcceptedFreezeException - This breakage isn't considered blocking since the GUI works for installation. A fix would be considered during freeze.
16:16:14 <kparal> pschindl: please add this one to CommonBugs
16:16:23 <danofsatx> ack
16:16:26 <roshi> #topic (1206961) Trackpad functionality has gone backward since fedora 21
16:16:28 * danofsatx needs to speed it up
16:16:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1206961
16:16:31 <roshi> #info Proposed Blocker, clutter, ON_QA
16:17:42 <pschindl> kparal: ok
16:17:57 <kalev> it's a long and winding ticket, but the short summary is that there's a bit of fallout in GNOME from switching to the libinput driver
16:18:18 <kalev> but there's an update available the fixes some of the most pressing issues on the GNOME side
16:19:06 <kalev> I'd be -1 blocker, but +1 FE, so that we can have a better out of the box trackpad support on the live media
16:19:06 <kparal> kalev: what does it fix?
16:19:36 <kalev> kparal: some trackpads weren't detected as trackpads and were basically unconfigurable
16:19:53 <pschindl> -1/+1 from me.
16:19:56 <kalev> two finger scrolling and tap to click didn't work
16:20:08 <kalev> and we didn't apply default settings from libinput properly
16:20:08 <roshi> -1/+1 for me as well
16:20:19 <roshi> people use tap to click? that always drove me nuts
16:20:22 <kparal> -1/+1
16:20:32 <jreznik> -1/+1
16:20:47 <kparal> roshi: I also can't stand it, but every general user I know uses it
16:21:05 <jreznik> roshi: first thing I have to change for all people I've ever installed Fedora...
16:21:17 <kparal> right, most people simply use it
16:21:30 <kparal> non-technical people, mostly
16:21:31 <jreznik> not simply use it, they do require it :)
16:21:37 <kparal> correct :)
16:21:39 <roshi> proposed #agreed - 1206961 - RejectedBlocker AcceptedFreezeException - This bug doesn't violate any Release Criteria, but it would be nice to get a fix in if one shows up.
16:21:42 * nirik is baffled by anyone not using it. ;)
16:21:43 <roshi> TIL :p
16:21:54 <kalev> ack
16:21:54 <jreznik> ack
16:21:56 <roshi> I usually give people a mouse when I install for them
16:22:04 <kparal> ack
16:22:06 <roshi> finally cleared out my stash of older mice :p
16:22:08 <danofsatx> ack
16:22:12 <pschindl> ack
16:22:49 <roshi> now, if the red dot mouse thing (what's that called, anyways?) stopped working I'd be all up in arms to get it fixed :p
16:23:00 <kalev> trackpoint!
16:23:02 <roshi> #agreed - 1206961 - RejectedBlocker AcceptedFreezeException - This bug doesn't violate any Release Criteria, but it would be nice to get a fix in if one shows up.
16:23:23 <roshi> so it does have a name... I love that thing. Hate not having it on some models
16:23:39 <roshi> #topic (1221920) release notes are missing on Workstation image
16:23:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1221920
16:23:39 <roshi> #info Proposed Blocker, distribution, NEW
16:24:15 <kparal> as it seems, we'll be amending our criteria not to require release notes on media
16:24:22 <kalev> -1 blocker, the Workstation WG deliberately removed it in F21
16:24:44 <kparal> I'll convert this into a QA ticket
16:24:52 <kparal> so -1
16:24:52 <roshi> thanks kparal
16:24:56 <roshi> -1 I guess
16:24:59 <danofsatx> -1
16:25:07 * roshi thought this was a clear +1 before he read the report though
16:25:50 <kparal> roshi: by the definition, yes
16:25:51 <jreznik> -1 blocker
16:25:57 <roshi> proposed #agreed - 1221920 - RejectedBlocker - This was an intentional change and also the state of F21. Criteria to be amended before F23.
16:26:00 <kparal> but the definition is about to change :)
16:26:08 <jreznik> ack
16:26:11 <kparal> ack
16:26:25 <kalev> ack
16:26:26 <danofsatx> ack
16:26:33 <pschindl> ack
16:26:59 <roshi> #agreed - 1221920 - RejectedBlocker - This was an intentional change and also the state of F21. Criteria to be amended before F23.
16:27:08 <roshi> #topic (1182635) Add PRIVACY_POLICY_URL to /etc/os-release
16:27:08 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1182635
16:27:08 <roshi> #info Proposed Blocker, fedora-release, NEW
16:27:51 <kalev> this one needs a matching change in gnome-initial-setup use the renamed url
16:28:28 <kalev> not a problem to change it in gnome-initial-setup, just saying it to make sure the two changes go out together :)
16:28:32 <kparal> if we fix os-release but not include a new build of g-i-s  (which is not ready yet), the "privacy policy" link from g-i-s will not work
16:29:08 <roshi> ah
16:29:11 * roshi is still reading
16:29:20 <kalev> it should be trivial to change it in gnome-initial-setup, for what it's worth
16:29:37 <kparal> I consulted with hadess and mclasen__, they say that os-release definitely needs to be fixed. I assume it means have g-i-s also fixed is preferred, but not strictly required
16:29:56 <kalev> it's definitely required, please don't take one fix without the other
16:30:13 <mclasen__> kalev: what g-i-s change do we need ? just about to roll an upstream release
16:30:21 <kparal> kalev: ok, in that case we need a matching build asap :)
16:30:27 <kalev> mclasen__: s/PRIVACY_POLICY/PRIVACY_POLICY_URL/ :)
16:31:25 <mclasen__> let me try a little harder - I'll make it so that both of these are tried
16:31:34 <kalev> ahh, even better!
16:31:58 <kparal> I'm definitely +1 FE here. not sure about blocker status, there's nothing violated
16:32:18 <kalev> same here, I would be -1 blocker, +1 FE
16:32:23 <roshi> -1/+1 for me
16:32:35 <roshi> there's not criteria cited and none that I can think of/find
16:33:39 <roshi> blocker votes?
16:33:42 <kparal> sounds reasonable
16:33:45 <kparal> -1/+1
16:33:46 <jreznik> yep, definitely +1 FE, but probably not blocker, so -1 blocker
16:33:51 <danofsatx> -1+1
16:33:56 <danofsatx> -1/+1
16:34:00 <jreznik> -1/+1 (for standard format)
16:34:02 <kalev> -1/+1
16:34:38 <pschindl> +1 to -1/+1 :)
16:34:46 <roshi> proposed #agreed - 1182635 - RejectedBlocker AcceptedFreezeException - This doesn't directly violate any criteria and thus, isn't blocking. However, it would be good to get these fixes in for g-i-s and /etc/os-release.
16:34:56 <danofsatx> ack
16:35:00 <pschindl> ack
16:35:01 <kalev> ack
16:35:08 <jreznik> ack
16:35:13 <kparal> ack
16:36:23 <roshi> #agreed - 1182635 - RejectedBlocker AcceptedFreezeException - This doesn't directly violate any criteria and thus, isn't blocking. However, it would be good to get these fixes in for g-i-s and /etc/os-release.
16:36:33 <roshi> #topic (1218787) gdm-wayland-session fails to present login screen after successful installation
16:36:36 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1218787
16:36:38 <roshi> #info Proposed Blocker, gdm, NEW
16:37:22 <kparal> this is the one about dual graphics cards
16:37:25 <kparal> in a mac
16:37:49 <kparal> after adam's call, we haven't seen many people saying they're affected
16:38:06 <kparal> mostly people said they were not
16:38:22 <kparal> so we might argue this is not widespread enough to warrant a blocker
16:39:28 <danofsatx> -1
16:39:45 <danofsatx> It appears to be Mac specific
16:40:37 <jreznik> danofsatx: and even people with similar Mac reported success
16:41:00 <mclasen__> kalev: gnome-initial-setup build underway now
16:41:02 <kparal> yeah, I think -1 with the current information
16:41:06 <jreznik> -1/-1 (as I don't think we can fix it in time)
16:41:06 <kalev> mclasen__: nice, thanks!
16:41:42 <roshi> thanks mclasen__ :)
16:43:12 <jreznik> let's move on, I'd have to leave in a few minutes :)
16:43:16 <mkolman> I can report that we tried it on our dual GPU mac we have in the office for testing
16:43:23 <mkolman> and it also showed the logins screen just fine
16:43:28 <roshi> proposed #agreed - 1218787 - RejectedBlocker - This bug doesn't appear often enough to warrant blocking release. If this bug starts to show up more often please repropose.
16:43:28 <mkolman> *login screen
16:43:38 <jreznik> thanks mkolman
16:43:43 <kalev> ack
16:43:44 <jreznik> ack
16:43:47 <roshi> I was typing jreznik :p
16:43:51 <roshi> just typing slow
16:43:54 <kparal> patch
16:43:59 <roshi> go of rit
16:44:02 <jreznik> roshi: I'm just too nervous :)
16:44:10 <roshi> lol, that was bad typing there
16:44:18 <roshi> go for it kparal :)
16:44:31 <kparal> roshi: probably "more commonly" than "more often". it's about different hardware, not different installation attempts
16:44:39 <kparal> if you understand me
16:44:56 <kparal> or "turns out it affects more different hardware"
16:45:29 <roshi> proposed #agreed - 1218787 - RejectedBlocker - This bug doesn't appear often enough to warrant blocking release. If this bug starts to show up on more platforms please repropose.
16:45:34 <kparal> ack
16:45:36 <roshi> something like thjat?
16:45:40 <kalev> ack
16:45:55 <roshi> my fingers don't seem to want to work...
16:45:55 <pschindl> ack
16:46:02 <roshi> #agreed - 1218787 - RejectedBlocker - This bug doesn't appear often enough to warrant blocking release. If this bug starts to show up on more platforms please repropose.
16:46:07 <jreznik> I'm not sure about "more platforms", original was a bit better, but...
16:46:54 <roshi> want to patch, or move to the next bug?
16:47:03 <roshi> I could just take the repropose bit out :p
16:47:19 <kparal> I think it's fine
16:47:23 * roshi says keep moving :)
16:47:34 <kalev> let's move on
16:47:34 <roshi> #topic (1222052) gnome-keyring is inaccessible for password-less users
16:47:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1222052
16:47:39 <roshi> #info Proposed Blocker, gnome-keyring, NEW
16:48:06 <kalev> looks like this one has a potential fix available that needs testing
16:48:16 <kparal> so, in a nutshell, gnome keyring doesn't work well if you set them passwordless
16:48:26 <kparal> it keeps the default password which is "gis"
16:48:34 <kparal> I tested a patch and it seems to fix it just fine
16:48:43 <kparal> once a new build is ready, it will be easier to test
16:48:55 <kparal> *them->users
16:49:23 <kparal> I'm concerned that having a passwordless user is quite more common that gnome devs believe
16:49:33 <mclasen__> kalev: was there a bug for the privacy policy thing ?
16:49:48 <kparal> especially in "my old mama" or "my girlfriend's account" scenario
16:49:48 <kalev> mclasen__: https://bugzilla.redhat.com/show_bug.cgi?id=1182635
16:50:15 <kparal> so I'd definitely vote at least +1 FE here
16:50:28 <roshi> I'm concerned passwordless users are even a *thing*
16:50:36 <kparal> I'd go as far as slip a week for this fix, even though everyone doesn't seem to agree
16:50:43 <roshi> -1/+1 I guess
16:50:53 <kalev> I'm definitely +1 FE as well, but leaning towards a -1 blocker
16:50:58 <roshi> I wouldn't want to slip for this
16:50:58 <kalev> -1/+1
16:51:08 <danofsatx> -1/-1
16:51:18 <roshi> in the "my old mama" scenario, just have her type password or something simple
16:51:40 <kparal> roshi: clearly your mama is different that the scenario mama :)
16:52:03 <kparal> I don't like the idea of shoving passwords down our users throat even if they don't want it
16:52:27 <kparal> but that's not relevant here
16:52:37 <roshi> yeah - but I don't think we block release on it
16:52:43 <danofsatx> In my wife's scenario, her password is something she can remember. She is required (by me) to have one, but I have to make it as simple/invisible for her as possible.
16:52:44 <kalev> could also leave the blocker decision for the next time, if it turns out that the FE fix doesn't work for some reason?
16:52:47 <kparal> well, I cited a criterion
16:53:04 <kalev> I'd be fine with punt/+1 as well
16:53:34 <roshi> well, it does *work* - you just have to provide a password
16:53:35 <kparal> I think people are mostly -1 blocker, so we can go ahead and vote it as such if you prefer
16:53:46 <roshi> it's confusing, for sure
16:53:50 <kparal> I just have a bit different opinion, but that's fine by me
16:54:12 <roshi> I'd take a fix in a heartbeat though
16:54:23 <kparal> roshi: you have to supply a password you don't know
16:54:24 <kalev> the fix is already building in koji
16:55:10 <sgallagh> As an aside: I'd like to make a general proposal for Freeze Exception bugs: We should never accept something for FE that doesn't have a fix identified at the time of the vote.
16:55:25 <kalev> sgallagh: yes, exactly what I've been saying all along!
16:55:57 <kparal> sgallagh: there are some reasons why we're not doing it like this. but I would discuss it during open floor
16:56:12 <kparal> in the past I proposed the same thing, actually
16:56:15 <sgallagh> /me has to go to the Council meeting now
16:56:21 <roshi> proposed #agreed - 1222052 - RejectedBlocker AcceptedFreezeException - This bug could easily cause confusion for users who don't set up a password for their accounts, but is not common enough to warrant blocking. The pending fix will be considerd during freeze.
16:56:28 <kalev> ack
16:56:31 <roshi> gl hf sgallagh - thanks for coming :)
16:56:32 <kparal> ack
16:56:42 <danofsatx> ack
16:56:48 <roshi> #agreed - 1222052 - RejectedBlocker AcceptedFreezeException - This bug could easily cause confusion for users who don't set up a password for their accounts, but is not common enough to warrant blocking. The pending fix will be considerd during freeze.
16:57:06 <roshi> #topic (1214474) Mouse capture issues when running in vmware
16:57:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1214474
16:57:06 <roshi> #info Proposed Blocker, kernel, NEW
17:00:05 <danofsatx> -1
17:00:32 <satellit_e> I have also seen this in VirtualBox and occasionaly in f22 bare metal anaconda liveinst installs
17:00:33 <nirik> -1/+1
17:01:03 <roshi> -1 and common bugs it
17:01:45 <kparal> -1 per Adam's and Hans's comments
17:01:50 <kalev> -1, seems like it can be fixed with an update later on
17:02:11 <roshi> we've got at least one FE vote, any others?
17:02:17 * roshi doesn't see the need for an FE
17:02:32 <kparal> it's not proposed as a FE, and I'm not sure about it, because the change doesn't seem to be simple
17:02:34 <danofsatx> -1/-1
17:02:36 <nirik> well, people might use the live media with vmware and hit it...
17:02:43 <nirik> but it's not a show stopper
17:02:46 <roshi> there are workarounds
17:02:51 <roshi> yeah
17:02:55 <nirik> sure, I can retract my vote.
17:03:07 * nirik also saw some discussion of this on the kernel list.
17:03:16 <roshi> or you can keep it - I was just wondering what your reasoning was :)
17:03:32 <nirik> well, mostly that live media would show it, but thinking more on it, meh...
17:03:39 <kalev> like sgallagh said earlier, it's best to vote on FE issues once there's an actual fix available to evaluate
17:03:47 <roshi> it'll get fixed at some point I think
17:04:01 <nirik> sure, but also accepting a FE doesn't mean we actually do anything...
17:04:16 <kalev> if the "fix" was making xorg run as root, I'd be -1; if the fix was a fixed vmmouse, I'd be +1
17:04:19 <nirik> it just means we have the option of taking the fix if we think it won't cause too much trouble
17:04:32 * kalev nods.
17:04:43 <nirik> anyhow, this wasn;t even proposed fe, so lets move on?
17:04:46 <roshi> proposed #agreed - 1214474 - RejectedBlocker - VMWare isn't a supported virtualization platform for Fedora. Rejected as a blocker. Please document the workaround in CommonBugs.
17:04:51 <nirik> ack
17:04:53 <kalev> ack
17:05:42 <kparal> ack
17:05:46 <roshi> #agreed - 1214474 - RejectedBlocker - VMWare isn't a supported virtualization platform for Fedora. Rejected as a blocker. Please document the workaround in CommonBugs.
17:06:03 <roshi> #topic (1222248) Need final Fedora 22 build of spin-kickstarts
17:06:03 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1222248
17:06:03 <roshi> #info Proposed Blocker, spin-kickstarts, NEW
17:06:12 <kparal> this is automatic +1 I believe
17:06:21 <nirik> yep. +1, but it's a bit of a weird one...
17:06:41 <nirik> because we can't build it until we know we are done, and it's not on any media so it can go stable after we are go. ;)
17:07:02 <kparal> processes!
17:07:10 <danofsatx> +1
17:07:15 <dgilmore> what nirik said
17:07:15 * satellit_e are tc-4 koji flattened .ks valid ==same?
17:07:26 <dgilmore> satellit_e: no
17:07:44 <dgilmore> satellit_e: the kickstarts we ship are not flattened
17:08:17 <kalev> I'd be +1 to a reworded, "Need a new F22 build of spin-kickstarts"
17:08:19 <roshi> yep +1
17:09:27 <roshi> proposed #agreed - 1222248 - AcceptedBlocker - This is a clear blocker.
17:09:32 <roshi> not sure what else to put there...
17:09:33 <roshi> lol
17:09:35 <kalev> ack
17:09:35 <nirik> ack
17:09:39 <dgilmore> ack
17:09:41 <satellit_e> ack
17:09:54 <roshi> #agreed - 1222248 - AcceptedBlocker - This is a clear blocker.
17:09:56 <kparal> ack
17:10:04 <roshi> right right, onto the FE's now :)
17:10:17 <roshi> #topic (1222352) F22 beta - Docker mounts /run on tmpfs
17:10:17 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1222352
17:10:17 <roshi> #info Proposed Freeze Exceptions, docker, NEW
17:10:49 * oddshocks pops in
17:11:27 * nirik reads
17:11:40 <roshi> +1 from me
17:11:40 <kparal> do we have docker on server or cloud install medium?
17:11:55 <roshi> not sure what you mean
17:11:58 <kparal> I just wonder if it can potentially break something
17:12:03 <roshi> it comes installed already on atomic
17:12:09 <nirik> kparal: don't think so, but it's on atomic...
17:12:12 <roshi> other editions are a dnf install
17:12:16 <kparal> ok
17:12:20 <nirik> but yeah, makes you wonder if it could just be fixed in an update.
17:12:22 <roshi> I don't see how this can break anything but docker
17:12:43 <kparal> and atomic is not blocking, right
17:12:47 <nirik> right
17:12:50 <kparal> so no harm done
17:12:50 <danofsatx> atomic isn't blocking, but cockpit offers seemless activation of Docker on Server.
17:13:04 <roshi> if atomic is a sping now doing it's own releases, it can be fixed with an update
17:13:06 <nirik> so I guess +1... but also sounds like the real fix is still being worked.
17:13:11 <danofsatx> but it is *not* installed by default.
17:13:15 <roshi> but it'd be nice to get a fix in, imo
17:13:41 <danofsatx> Cloud is blocking. We do not block on any container services - yet.
17:13:46 <kparal> +1
17:14:06 <dgilmore> I say it is a blocker, because the process to get updates done and out is dysfunctinal
17:14:09 <danofsatx> F23, maybe, but F22 is no beholden to Docker/Atomic/LXC/containerservicedujour
17:14:13 <dgilmore> and so its really not happening :(
17:14:16 * nirik is confused by 'seems to alleviate'...
17:14:40 <roshi> oddshocks: got something to add here?
17:14:51 <dgilmore> server has docker installed by default
17:14:55 <pschindl> +1
17:14:59 <dgilmore> because of cockpit
17:15:15 <oddshocks> Nothing from me, i don't think
17:15:54 <roshi> server has docker installed by default? I thought it just had the scaffolding for it - but you had to install it
17:16:02 <kparal> dgilmore: does this violate some server criteria then?
17:16:02 <dgilmore> roshi: nope
17:16:07 <danofsatx> that's what I thought, also.
17:16:07 <roshi> ah
17:16:13 * danofsatx is digging up a fresh install
17:16:18 <roshi> then it's a different question
17:16:18 <dgilmore> well let me rephfarse that
17:16:31 <dgilmore> let me learn to type and spell
17:16:47 <dgilmore> the Server installs I have all have docker installed
17:16:59 <dgilmore> I have not done anything special to get docker there
17:17:03 <dgilmore> I am not using it
17:17:26 <dgilmore> I do not know if this violates any Server criteria
17:18:14 <dgilmore> so my vote should be +1 FE, (strongly must be fixed, due to dysfunctinal docker base image update process, which would mean that it may not get fixed in GA
17:18:17 <dgilmore> )
17:18:35 <kalev> if dgilmore says +1, then I'm +1 FE as well :)
17:19:01 <kparal> dgilmore: in that bug I don't see anything related to image update process
17:19:09 <dgilmore> if there is Server criteria that it violates and should be considered a blocker, I am not aware of any
17:19:12 * danofsatx doesn't see Docker in latest F22/Cockpit interface.
17:19:13 <kparal> but I don't know anything about docker
17:19:52 <roshi> proposed #agreed - 1222352 - AcceptedFreezeException - Getting a fix in for docker would be great since it ships on the Server media.
17:20:11 <kalev> ack
17:20:11 <nirik> ack
17:20:22 <dgilmore> ack
17:20:29 <pschindl> ack
17:20:56 * danofsatx is still digging
17:21:08 * kparal is installing Server to check whether docker is there
17:21:14 <kparal> but we can carry on
17:21:23 <roshi> #agreed - 1222352 - AcceptedFreezeException - Getting a fix in for docker would be great since it ships on the Server media.
17:22:10 <danofsatx> there is no docker on my F22 server.
17:22:18 <danofsatx> then again, it was installed from Beta, I think....
17:22:28 * danofsatx goes to build a TC4 Server
17:23:45 <nirik> ack
17:23:56 <nirik> pesky arrow.
17:24:43 * kparal rebooting
17:25:45 <danofsatx> next one is a "Well, duh!" +1 ....
17:25:58 <roshi> any more acks?
17:25:59 <kparal> docker is installed
17:26:05 <kparal> ack
17:26:49 * danofsatx bangs his head on the desk
17:26:50 <roshi> eh, good thing it's acked, since I forgot the "proposed"
17:27:01 <roshi> easy there dan, what did your desk do to you?
17:27:04 <danofsatx> the server I checked was an x386 install
17:27:16 <danofsatx> x386 doesn't do docker
17:27:16 <roshi> #topic (1222162) firefox-38.0-4.fc22 should go stable to keep upgradepath clean
17:27:19 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1222162
17:27:22 <roshi> #info Proposed Freeze Exceptions, firefox, NEW
17:27:35 <danofsatx> +1
17:27:38 <kalev> I'll note two things
17:28:00 <kalev> 1) firefox-38.0-4.fc22 never made it to updates-testing, so it hasn't gotten a tons of testing
17:28:11 <kparal> this will affect live media
17:28:12 <kalev> 2) there's a newer 38.0.1 update on its way to updates-testing
17:28:53 <kparal> FF38 seems to work fine for me on F21, but I'm just stating that if we push this stable, it's going to affect lives
17:28:57 <kparal> even Lives
17:29:18 <dgilmore> we probably should push the latest version we can
17:29:38 <dgilmore> though it will be quickly outdated with security issues
17:30:32 <nirik> right. I'm +1 to the new one... if it can get some testing before we push it.
17:30:45 <kparal> even if we push 38.0, the upgradepath will break once 38.0.1 is out
17:30:51 <kparal> but +1 if it has some karma
17:30:53 <dgilmore> kparal: ?
17:31:03 <kalev> yes, same here: +1 to taking 38.0.1 it if it gets +3 karma before the next stable push
17:31:07 <roshi> +1 here
17:31:11 <nirik> well, once we release we are ok.
17:31:12 <dgilmore> you mean the upgrade path from f21 up?
17:31:18 <kparal> dgilmore: meaning if we push 38.0 info F22, but 38.0.1 into F21
17:31:22 <nirik> it's just in this time when we have no updates repo/pre-reelease
17:32:17 <dgilmore> kparal: thats quite unavoidable at this point in the cycle
17:32:40 <kparal> sure, just saying it's not really an argument why to push this stable
17:32:52 <kparal> if we want latest FF on Lives, that's a reason
17:33:12 <roshi> proposed #agreed - 1222162 - AcceptedFreezeException - It'd be good to keep a clean upgrade path.
17:33:13 <kparal> s/argument/reason
17:33:22 <dgilmore> kparal: my agument is to get the most security fixes possible
17:33:38 <kparal> I agree
17:33:39 <dgilmore> argument
17:33:40 <kparal> ack
17:33:42 <kalev> roshi: patch - which version are you taking, 38.0 or 38.0.1 ?
17:33:42 <nirik> ack
17:33:44 <dgilmore> ack
17:34:16 <kparal> kalev: I'd say whichever is tested at the moment we ask for a TC/RC
17:34:28 <kalev> fair enough, works for me
17:34:29 <pschindl> ack
17:34:29 <roshi> yeah
17:34:32 <kalev> ack then
17:34:33 <dgilmore> leave it up to roshi when he requests a compose
17:34:41 <nirik> 38.0.1 actually isn't a security update.
17:34:44 <nirik> (for once)
17:35:11 <roshi> #agreed - 1222162 - AcceptedFreezeException - It'd be good to keep a clean upgrade path.
17:35:23 <roshi> #topic (1221968) [abrt] gnome-software: g_hash_table_lookup_node(): gnome-software killed by SIGSEGV
17:35:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1221968
17:35:28 <roshi> #info Proposed Freeze Exceptions, gnome-software, ON_QA
17:36:06 <dgilmore> +1
17:36:10 <kalev> just a targeted fix for that one crash, nothing else changed
17:36:10 <nirik> sure, +1 FE, we already have an update in hand right?
17:36:13 <kalev> yep
17:36:16 <roshi> +1 for this
17:36:17 <oddshocks> +1 from me
17:36:21 <kparal> +1
17:36:21 <kalev> +1
17:36:22 <roshi> has a small footprint
17:37:07 <roshi> proposed #agreed - 1221968 - This fix has a small footprint and gets rid of a crash, please pull the fix in.
17:37:19 <kalev> ack
17:37:26 <kparal> ack
17:37:31 <dgilmore> ack
17:37:39 <nirik> ack
17:38:03 <roshi> #agreed - 1221968 - This fix has a small footprint and gets rid of a crash, please pull the fix in.
17:38:17 <roshi> #topic (1222134) Fix the default for gnome-shell's "Install pending software updates" checkbox
17:38:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1222134
17:38:22 <roshi> #info Proposed Freeze Exceptions, PackageKit, ON_QA
17:38:34 <kparal> oooh, this has made my day
17:38:44 <kparal> kalev: thanks for fixing this
17:38:50 <kalev> np!
17:38:54 <kalev> thanks for catching it
17:39:05 <kparal> I actually was convinced it was deliberate
17:39:22 <nirik> +1 FE, would be nice to fix
17:39:26 <roshi> +1
17:39:32 <kalev> +1 FE
17:39:33 <kparal> +1
17:39:56 <roshi> proposed #agreed - 1222134 - AcceptedFreezeException - It would be good to get this fix pulled in for F22.
17:40:15 <kalev> ack
17:40:18 <kparal> ack
17:40:41 <oddshocks> ack
17:41:27 <roshi> #agreed - 1222134 - AcceptedFreezeException - It would be good to get this fix pulled in for F22.
17:41:42 <roshi> ok, that's it for proposals
17:41:51 <roshi> I'd say we get back to testing stuff
17:42:01 <roshi> and I'll go ahead and poke where it's needed through the accepteds
17:42:05 <roshi> if that works for everyone
17:42:09 <kparal> wait
17:42:18 <kparal> roshi: I think we should go through accepted blockers
17:42:28 <kparal> it's the release week after all
17:42:58 <roshi> that was kinda the reasoning I was using for the "get back to testing" statement :p
17:43:03 <kparal> and agree whether we want to ask for a new TC, or wait for RC, or whatever, I think
17:43:04 <roshi> but sure, we can
17:43:24 <roshi> #info Moving onto reviewing accepted blockers
17:43:25 <roshi> #topic (1211746) ValueError: new size is too large
17:43:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1211746
17:43:26 <roshi> #info Accepted Blocker, anaconda, ASSIGNED
17:43:54 <kparal> this has a patch, needs to be tested, ideally asap
17:44:09 <jreznik_pp> There's updates img
17:44:21 <kparal> yeah, that's what I meant :)
17:44:35 <kparal> I can do it tomorrow morning, if someone can be faster, that would be great
17:44:41 <jreznik_pp> Patch is one stay away from testable update;-)
17:45:10 <roshi> good to know
17:45:11 <kparal> so that dlehman can trigger a new anaconda build
17:45:12 <jreznik_pp> Step, autocorrectin!
17:45:22 <kparal> this seems to be the last anaconda blocker
17:45:26 <jreznik_pp> Yep
17:45:33 <roshi> sweet
17:46:08 <nirik> hurray.
17:46:12 <kparal> #info needs testing asap
17:46:17 <kparal> next one?
17:46:29 <roshi> yep
17:46:40 <roshi> #topic (1221730) Fedora 22 final release notes required for GA
17:46:40 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1221730
17:46:40 <roshi> #info Accepted Blocker, fedora-release-notes, MODIFIED
17:47:18 <kparal> the new build is ready, nothing to do here I think
17:47:19 <roshi> looks like this one is good to go as well
17:47:21 <kparal> it has enough karma
17:47:26 <kparal> #info this is good to go
17:47:29 * nirik nods.
17:47:30 <roshi> #topic (1221726) Fedora-repos needs updating for f22 final
17:47:30 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1221726
17:47:30 <roshi> #info Accepted Blocker, fedora-repos, NEW
17:47:49 <jreznik_pp> It's usually updated for first RC
17:47:50 <kparal> dgilmore: any update for this?
17:47:53 <dgilmore> this is underway
17:47:56 <kparal> great
17:48:08 <roshi> sweet
17:48:08 <kparal> #info an update is underway
17:48:14 <dgilmore> kparal: it will be ready for RC1 along witha  needed fedora-release update
17:48:17 <nirik> we just need repos right? not release?
17:48:23 <dgilmore> nirik: both
17:48:28 <nirik> ah bummer, ok.
17:48:39 <kparal> these days I'm not sure which is which
17:48:46 <nirik> dgilmore: do you want to do generic-release too? or is someone handling that?
17:48:50 <dgilmore> lives rely on fedora-release beinga  whole number to detect if they are pre-release or final\
17:48:59 <kalev> fedora-release has a privacy url patch from sgallagh_afk too
17:49:00 <dgilmore> nirik: I will have to do it also
17:49:08 <jreznik_pp> kparal, same here when I was looking for F21 bug
17:49:18 * nirik nods.
17:49:23 <dgilmore> kalev: thats getting naked bceause other changes are needed and it was already underway
17:49:31 <dgilmore> but yes that will get fixed also
17:50:43 <kparal> next one?
17:50:44 <roshi> anything else or move to the next one?
17:50:45 <roshi> #topic (1209941) upgraded system does not reboot automatically, ctrl+alt+del is needed: Failed unmounting /sysroot/proc
17:50:48 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209941
17:50:51 <roshi> #info Accepted Blocker, fedup-dracut, NEW
17:50:56 <kparal> this is troubling me a bit
17:51:10 <nirik> oh, this is in fedup-dracut? so on the server/repo side?
17:51:18 <kparal> it seems so
17:51:45 * roshi reads
17:51:49 <kparal> but I'm not sure if we can fix it and test it by thursday. it needs to be fixed before a compose, so that new upgrade.img is generated, right?
17:52:54 <nirik> yep.
17:53:00 * kparal pinged wwoods
17:53:44 <kparal> no response, let's hope he commits it today
17:53:57 <kparal> and that the fix actually works
17:54:23 <kparal> if somebody can ping Will later in the day, that would be great
17:54:54 <roshi> I can do it
17:54:56 <jreznik_pp> We can just try to spin compose and try it
17:54:56 <kparal> #info patch proposed, but not clear whether it will fix it. needs a new build and a new compose
17:55:00 * roshi sets a reminder
17:55:09 <kparal> I think it can be somehow generated without doing the full compose
17:55:16 <kparal> Will will know
17:56:17 <nirik> there's a script in /usr/share/doc/fedup-dracut/makefeduprepo that should make a test instupdate repo
17:56:34 <roshi> I'll ping him this afternoon
17:56:42 <kparal> roshi: thanks
17:56:50 <kparal> next!
17:56:55 <kparal> :)
17:56:55 <roshi> #topic (1166650) [abrt] liveusb-creator: connection.py:651:call_blocking:DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
17:56:59 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1166650
17:57:02 <roshi> #info Accepted Blocker, liveusb-creator, ASSIGNED
17:57:07 <kparal> and this is the one we are likely to slip for
17:57:24 * nirik reads up
17:57:28 <kparal> I have tested lmacken's port to udisks2 and it seems to have plenty of issues
17:57:49 <kparal> honestly, I'd rather remove liveusb-creator from the recommended usb conversions methods and stop blocking on it
17:58:12 <kparal> it never worked really well and it seems to be getting worse
17:58:55 <nirik> yeah. With so many other/better ways...
17:59:10 <kparal> not that I want to bash on Luke's contributions, but it's just the way it is. he doesn't have too much time for this
17:59:44 <nirik> right, this was/is a side project.
18:00:01 <roshi> I'm kinda confused - why would we block release on an external tool not being able to write correctly?
18:00:06 <kparal> let me try to ping him
18:00:19 <kparal> roshi: you find the criterion in the mean time :)
18:00:31 <nirik> roshi: the critera says all supported ways of making a usb must work
18:00:37 <nirik> this is one of those supported listed ways
18:00:41 <roshi> yeah, I see that
18:00:51 <roshi> it just seems kinda, I dunno, backwards
18:01:16 <kparal> roshi: well, it's "our" tool, it's "Fedora LiveUSB Creator"
18:01:23 <kparal> so it kind of makes sense we want it to work
18:01:47 <kparal> but it's quite painful, every release
18:02:01 <roshi> yeah, we want it to work for sure
18:02:22 <roshi> but we're not releasing an image that's fine in and of itself because one method of writing it doesn't work atm
18:02:48 <roshi> nvm though, a discussion for another time :)
18:02:55 <kparal> roshi: you're right, this doesn't need to block the compose, just the final announcement
18:03:04 <kparal> it's enough if it is in 0-day updates
18:03:08 <nirik> sure, we can wait on it a bit more...
18:03:13 <roshi> ok
18:03:13 <kparal> but we don't really have a process for this
18:03:21 <nirik> but if this is it before release, I am ok with dropping it as supported.
18:03:25 <roshi> I can also try to ping luke about this later today
18:03:34 <roshi> same here
18:03:35 <kparal> no response from Luke
18:04:16 <kparal> roshi: please ask him what his thoughts are about this. if he's going to fix it in a few days, or whether he's fine with dropping it as an officially supported method, or something else
18:04:29 <roshi> will do
18:04:43 <roshi> that's all the accepted blockers
18:04:44 <kparal> I think the main use case of luc is the persistant overlay
18:04:47 <roshi> open floor?
18:04:55 <kparal> or maybe I'm confused with litd
18:05:04 <kparal> let me write an info
18:05:17 <kparal> #info this needs to be discussed with lmacken, roshi will try to ping him
18:05:21 <kparal> open floor
18:05:22 <nirik> so, we pulled in kde and gnome megaupdates to the last tc... did that go well? should we push them stable/use them for further rcs?
18:05:42 <kparal> #topic Open Floor
18:05:45 <kalev> gnome megaupdate seems good to go from what I can tell, haven't heard of any regressions here
18:05:47 <nirik> and there's a lot of pending fe's... might be good to push the simple/easy/done ones to stable. ;)
18:06:04 <kparal> nirik: I tested GNOME megaupdate and found no issues except that keyring we already voted on
18:06:16 <kalev> and that wasn't a regression
18:06:16 <nirik> cool.
18:06:17 <kparal> and that was not a regression
18:06:20 <nirik> how about kde?
18:06:31 <kparal> kde megaupdate wasn't pulled in I think
18:06:33 <kalev> was kde megaupdate actually pulled in?
18:06:42 * kparal checks
18:06:54 <jreznik_pp> I don't think so but...
18:07:07 <nirik> oh, perhaps not.
18:07:10 * nirik looks too
18:07:35 <kparal> https://fedorahosted.org/rel-eng/ticket/6166#comment:7
18:07:39 <kalev> we're also starting to get overlapping updates, would be good to push the older ones to stable
18:07:40 <kparal> no it wasn't
18:08:01 <kparal> I think the gnome megaupdate is good to go to stable
18:08:47 <nirik> there were some kde updates in there tho
18:09:12 <kalev> we could all do a fedora-easy-karma round and then roshi or something puts together a stable request?
18:09:26 <kalev> err, roshi or *someone* :)
18:09:31 <kalev> sorry!
18:09:43 <nirik> maven-wagon-webdav-jackrabbit would be good to go too...
18:09:59 <roshi> hehe
18:10:01 <kparal> now that's a cool name
18:10:06 <nirik> :)
18:10:23 <roshi> kalev: that sounds like a good idea
18:10:24 <nirik> there's a bunch of fe's in NEW... guess they should get ignored until they have some update.
18:10:30 <roshi> I'm still getting my head on straight
18:10:49 <roshi> for those of you that didn't know, I've been out of the office for a few weeks
18:11:10 <kparal> so, do we want to ask for another TC today, or wait until we're good to go for RC?
18:11:19 <roshi> but I'm back now :)
18:11:39 <kparal> I think that mostly depends on the anaconda fix. including the fedup fix would be great.
18:11:44 <roshi> I'll defer to you guys on that calll
18:11:51 <jreznik_pp> We can try ask for Anaconda and fedup build and try it in RC?
18:11:55 <roshi> and will put in the request when ready
18:11:59 <jreznik_pp> One option
18:12:10 <jreznik_pp> We can always spin another RC
18:12:11 <kparal> jreznik_pp: we first need to try that updates.img
18:12:21 <kparal> and wwoods needs to commit and push fedup-dracut fix
18:12:30 <jreznik_pp> Well, you can try it as part of RC
18:12:44 <jreznik_pp> As it's supposed to fix blocker
18:12:46 <kparal> the little things like fedora-repos should be prepared quickly
18:12:47 <jreznik_pp> But your call
18:13:07 <kparal> it's a possibility, right
18:13:13 <nirik> I think trying an rc1 later today sounds possible.
18:13:21 <nirik> if anaconda fix works out and we get a build.
18:13:23 <kparal> I think dlehman doesn't want to commit it unless at least someone tested it
18:13:33 <roshi> from what I've seen, I think a RC later today after I hear from will seems good
18:13:34 <kparal> but either way works
18:13:34 <nirik> which is completely fair. ;)
18:14:37 <nirik> roshi: note: if you request packages in a stable push and I push them today, they won't appear in the base repos until tomorrow morning's compose... so if we do a rc1 today also need to request those stable pushed things into the compose.
18:14:49 <roshi> so, updates testing and then I'll submit an RC request this afternoon
18:15:18 <roshi> I'll get my submission double checked before I put it in :)
18:15:23 <roshi> thanks for the heads up though
18:15:30 <kalev> stable push request and RC request are separate ticket, by the way
18:15:45 <kparal> roshi: yes, provided we have a new anaconda and ideally also fedup-dracut
18:16:08 <kparal> I actually think fedup-dracut fix is mandatory for RC
18:16:26 <nirik> yeah.
18:16:28 <kparal> because we're not going to fix it afterwards and overwrite the old files
18:16:34 <roshi> ok
18:16:38 <kparal> that wouldn't fly, because processes!
18:16:51 * nirik crosses fingers. A rc1 later today would be a good sign. ;)
18:16:56 <kparal> but I agree with them, not that I don't :)
18:17:37 <roshi> well, let's hope things get done and we can have an RC tomorrow :)
18:17:47 <kalev> awesome :)
18:17:54 <kparal> roshi: sorry for leaving it all up to you. if needed, ask tflink to help you
18:18:15 <roshi> no worries :)
18:18:19 <roshi> just glad the timing worked out
18:18:25 <roshi> oh, I will
18:18:39 <kparal> e.g. the anaconda fix
18:18:39 * tflink reads up to figure out what he should be helping with
18:18:41 <kparal> thanks
18:18:50 <kparal> tflink: everything, of course
18:18:50 <roshi> anyone have anything else?
18:18:57 <jreznik_pp> Thanks guys
18:18:59 <dgilmore> RC1 now please
18:19:01 <dgilmore> :)
18:19:03 <roshi> :D
18:19:08 <tflink> kparal: :-P
18:19:13 <jreznik_pp> I might chime in later today, no promises
18:19:31 <nirik> we also need fedora-release/fedora-repos. ;)
18:19:36 <jreznik_pp> Luboš plans after-party, dgilmore knows what does it mean...
18:19:54 <dgilmore> jreznik_pp: it means he will pike out early :P
18:22:01 <kparal> roshi: endmeeting?
18:22:39 * kparal goes offline, thanks everybody for joining
18:22:46 <jreznik_pp> Thanks kparal
18:23:57 <roshi> yep
18:24:02 <roshi> thanks folks!
18:24:07 <roshi> #endmeeting