18:00:44 <notting> #startmeeting FESCO (2013-09-04)
18:00:44 <zodbot> Meeting started Wed Sep  4 18:00:44 2013 UTC.  The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:54 <notting> #meetingname fesco
18:00:54 <zodbot> The meeting name has been set to 'fesco'
18:00:54 <notting> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:00:54 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:54 <notting> #topic init process
18:01:00 <mmaslano> hi
18:01:05 <pjones> hello, party people.
18:01:07 <notting> hey everyone
18:01:17 <abadger1999> hola
18:01:38 <nirik> morning.
18:01:51 <sgallagh> Salutations
18:02:00 <mattdm> hello
18:02:10 <mattdm> sgallagh still no baby?
18:02:26 <sgallagh> mattdm: She's being shy, I guess
18:03:14 <t8m> hello
18:03:27 * notting looks. no mitr today?
18:04:12 <mmaslano> he's on vacation
18:04:23 <notting> ok. then that's everyone.
18:04:34 <notting> #topic #1115    guidance from FESCO on packagekit upstream policykit change
18:04:34 <notting> .fesco 1115
18:04:36 <zodbot> notting: #1115 (guidance from FESCO on packagekit upstream policykit change) – FESCo - https://fedorahosted.org/fesco/ticket/1115
18:05:07 <notting> mattdm: you were poking halfie and were going to close this out?
18:05:24 <mattdm> um.
18:05:47 <mattdm> in theory i suppose I was. in practice, I totally forgot to do that.
18:06:25 <notting> #info mattdm to close out per notes from last week's meeting
18:06:28 <notting> ok, moving on
18:06:28 * mattdm makes note to actually do it.
18:06:48 <notting> #topic #1136    F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary
18:06:49 <notting> .fesco 1136
18:06:50 <zodbot> notting: #1136 (F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary) – FESCo - https://fedorahosted.org/fesco/ticket/1136
18:07:14 <notting> there were concerns raised by QA that they didn't have any hardware that actually worked at alpha. has this been improved?
18:07:24 <nirik> bbb now boots, but no net I think...
18:07:25 <notting> tflink: ^^?
18:07:28 <tflink> yeah, there have been improvements and new info in the last few days
18:07:51 * tflink was not aware of the wandboard, is downloading tc3 for testing on bbb right now
18:07:59 <nirik> also, there is qa access to highbank socs if that helps... but install testing on them could be difficult to setup for non sysadmin types.
18:08:06 <tflink> s/few days/day
18:08:15 <jwb> tflink, er... bbb doesn't boot the fedora kernel, does it?
18:08:22 <pjones> tflink: so what you're saying is that there's progress but you don't yet know if the answer is actually "yes" that the problem has been resolved?
18:08:28 <tflink> jwb: supposedly that was fixed yesterday
18:08:38 <tflink> pjones: correct, I haven't verified it myself
18:08:38 <jwb> tflink, afaik, pbrobinson just added patches for that last night and there is no f20 kernel with them included
18:09:02 <tflink> i thought that 3.11.0-3.fc20 had the patches
18:09:07 <handsome_pirate> nirik:  That's been one of my concerns
18:09:41 <jwb> tflink, * Wed Sep  4 2013 Peter Robinson <pbrobinson@fedoraproject.org>
18:09:42 <jwb> - Add patch set to fix MMC on AM33xx
18:09:42 <jwb> - Add support for BeagleBone Black (very basic!)
18:09:42 <jwb> * Tue Sep 03 2013 Josh Boyer <jwboyer@fedoraproject.org> - 3.11.0-3
18:09:42 <jwb> - Add system_keyring patches back in
18:09:43 <pwhalen> we currently have highbank, qemu, wandboard working . Trimslice has a PCIe issue that prevents working ethernet. Wireless and usb adapters work
18:09:52 <jwb> tflink, clearly not.  i built 3.11.0-3 yesterday
18:10:03 <handsome_pirate> tflink:  I appear to be wrong about that, apologies
18:10:04 <notting> the implication from the ticket is that limited current support is due to bugs, not plans. is that actually the case?
18:10:16 <handsome_pirate> notting:  To an extent
18:10:34 <bconoboy> evidently trimslice PCIe issue is now cooked as well- kylem just updated #fedora-arm on it
18:10:52 <handsome_pirate> notting:  Some of it is plain on missing support in upstream kernel
18:10:59 <handsome_pirate> Note *some*
18:11:11 <handsome_pirate> That, however, ought to be fixed
18:11:24 <handsome_pirate> The rest is bug related, especially trimslice
18:11:29 <tflink> if there are people doing testing with reasonably common hw, I have fewer concerns for alpha
18:11:35 <handsome_pirate> kylem just reported that fixed as of five minutes ago
18:11:54 <jwb> which means there are no patches for it in the kernel, and no built kernel
18:11:58 <jwb> which means it needs to go in via bodhi now
18:12:03 * nirik can find time to test highbank if more testers on it are needed.
18:12:17 * nirik also has a bbb
18:12:18 <jwb> please be clear when you're describing things as fixed.
18:12:24 <pwhalen> nirik, believe I have highbank covered
18:12:35 <notting> highbank == calxeda server socs?
18:12:42 <bconoboy> notting: y
18:12:44 <pjones> handsome_pirate: you mean "a fix has been checked in", not "there's a kernel built", yes?
18:12:45 <handsome_pirate> nirik:  I could help test highbank if I had access.  Monday I should be on RH's internal network
18:12:54 <jwb> pjones, not even taht
18:13:00 <pjones> just "kylem has figured it out"?
18:13:11 <handsome_pirate> pjones:  That last is correct
18:13:16 <jwb> < kylem> alright, i think i fixed trimslice.
18:13:20 <pjones> yeah, that's really not the same as fixed.
18:13:26 <jwb> he further clarified as
18:13:30 <handsome_pirate> notting:  Indeed
18:13:32 <nirik> handsome_pirate: the tricky part in our setup is pxe booting setup needing access to pxe server, etc.
18:13:34 <jwb> < kylem> i'd like to point out that "i think" does not necessarily imply
18:13:37 <jwb> "is"
18:13:56 <handsome_pirate> nirik:  I'll ping you Monday or so
18:13:59 <bconoboy> what is the actual topic here?
18:14:04 <tflink> my understanding is that at THIS moment, the working platforms that we have builds for are: wandboard and highbank/caldexa
18:14:17 <tflink> bconoboy: concerns about lack of working HW @ alpha freeze
18:14:19 <handsome_pirate> tflink:  vexpress, too
18:14:21 <sgallagh> bconoboy: Is ARM in a sufficient state for Alpha freeze as a primary arch?
18:14:21 <jreznik> well, when we discussed it with tflink, we agreed that at least one other common hw working should be sufficient for alpha (+highbank)
18:14:28 <notting> in any case, i don't know that we want to triage individual bits of HW here. the question raised is (afaict) - is there a threshold of hardware support we expect for ARM as primary, and are we past it?
18:14:39 <handsome_pirate> sgallagh:  I think in another week, it would be
18:14:42 <jwb> notting, i'm mostly wanting FESCo to get accurate information
18:14:54 <sgallagh> handsome_pirate: And so, are you proposing a slip?
18:14:57 <jwb> because at least 2 boards that were identified as fixed aren't
18:15:02 <t8m> notting, that's really hard to say
18:15:23 <handsome_pirate> sgallagh:  We may be able to squeeze it all in
18:15:23 <bconoboy> individual boards should not cause a slip.
18:15:27 <jreznik> notting: as I said above - I'd say, for alpha, I think highbank + one common platform community has access to could be enough
18:15:30 <t8m> notting, I'd even say that this is a board decision of how much hardware must a primary arch support
18:15:32 <tflink> jreznik: yeah, I don't care so much about specific platforms as long as we have some common ones working
18:15:32 <handsome_pirate> sgallagh:  I don't think we'll need to slip
18:15:36 <pwhalen> tflink, trimslice is also working with ethernet adapter or wireless.
18:15:49 <jreznik> tflink: +1
18:15:50 <jwb> t8m, oh please no
18:16:01 <jwb> the Board has no place deciding that
18:16:02 <sgallagh> jreznik: Are we talking about making that an Alpha Release Criterion, then?
18:16:26 <notting> i defer to tflink and handsome_pirate as QA people, but we've historically only had very specific "this HW doesn't work" criteria, usually because the majority of x86 was table stakes - at least 90% of machines were always working, even if which 90% changed
18:16:35 <jreznik> sgallagh: or that fesco criterion if you say it's what's desired for alpha
18:16:58 <handsome_pirate> tflink:  What do you think?
18:17:06 * nirik is fine with it for alpha. Obviously we should targeted fix things we can as we go.
18:17:14 <handsome_pirate> tflink:  I believe the ARM guys may be able to slip it all in
18:17:25 <sgallagh> Proposal: Addition to the Alpha Release Criteria: "All primary architectures must run on at least one readily-available hardware platform"
18:17:27 <handsome_pirate> tflink:  It's not like we haven't fudged for x86 in the past
18:17:36 <tflink> handsome_pirate: I think I've been pretty clear about what I'm looking for, personally - at least one common board that is being tested
18:17:43 <sgallagh> With a better definition of "readily-available"
18:17:55 <handsome_pirate> tflink:  Wandaboard fits that
18:18:01 <handsome_pirate> tflink:  Actually, so does trimslice, since wireless works
18:18:11 * nirik nods.
18:18:12 <handsome_pirate> It's only wired ethernet on trimslice that is buggy
18:18:19 <notting> tflink: http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-blocking_images_must_boot points to the arm list of highbank, trimslice, panda, beagle, wand
18:18:54 <handsome_pirate> Beagle and Panda both have TI SoCs
18:18:55 <t8m> sgallagh, with some nice definition +1
18:19:15 <notting> sgallagh: ARM's already got a hw platform list in the criteria. see above.
18:19:18 <tflink> yeah, I think most of my concerns have been addressed in the ticket since yesterday
18:19:26 <tflink> immediate concerns, anyways
18:19:44 <sgallagh> notting: Yeah, I see that. Right now, that list looks destined to force an Alpha slip.
18:19:47 <tflink> as long as people who have wandboards (ie, not any fedora qa folks) are testing
18:19:56 <notting> tflink: do you have blocker bugs filed for the boards not working?
18:20:23 <tflink> notting: no, we keep being told that the ARM folks don't want to block on specific hw
18:20:35 <pjones> tflink: and yet the criteria lists specific hardware.
18:20:41 <tflink> yep
18:20:52 * tflink will file bugs and propose as blockers today
18:21:06 <nirik> well, beagle is the only one on the list thats not landed?
18:21:21 <handsome_pirate> nirik:  Aye
18:21:27 <bconoboy> I think panda is the primary broken board at this point.  We might want to drop support for it.  TI certainly has.
18:21:29 <frankieonuonga> sorry I am late guys..
18:21:49 <nirik> beagle and panda then
18:22:26 <notting> proposal: follow blocker process per alpha release criteria. if ARM team and QA want to renegotiate the release criteria, let them?
18:22:36 <pjones> notting: +1
18:22:38 <bconoboy> sounds good to me
18:22:41 <nirik> +1
18:23:02 <mmaslano> +1
18:23:19 <sgallagh> +1
18:24:10 <mattdm> +1
18:24:22 <abadger1999> +1
18:24:23 <t8m> +1
18:25:40 <notting> #agreed Follow blocker process per Alpha release criteria for ARM platfom issues. ARM team and QA can renegotiate release criteria if needed. (+:8, -:0, 0:0)
18:26:13 <notting> #topic #1148    F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller
18:26:13 <notting> .fesco 1148
18:26:15 <zodbot> notting: #1148 (F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller) – FESCo - https://fedorahosted.org/fesco/ticket/1148
18:27:59 <notting> jreznik: current status, other than what was in the ticket?
18:28:31 <jreznik> notting: what I provided in the ticket - in the change page, gnome-software is now built for f20
18:28:50 <jreznik> and see Scope section for DONE items
18:30:20 <notting> does this include the yumdb bits in the PK hawkey backend?
18:30:35 <sgallagh> notting: I'm willing to let that slide until beta, honestly.
18:30:53 <sgallagh> Alpha only needs to be testable. We can treat any issues with yumdb as a bug for now
18:31:16 * nirik too
18:31:36 <notting> so... what exactly happens with the version as currently packaged in the absence of the metadata (icons, appdata, etc.)?
18:31:43 <jreznik> at least, we have gnome-software imported to f20, so it should be possible to take a look on current status
18:32:04 <jreznik> notting: it will have limited functionality for now? I suppose so
18:33:36 <notting> ... ok. we could table this for another week if people want.
18:33:39 <abadger1999> jreznik: Question about the contingency plan -- are all of those things being kept up-to-date?  ie, if we need to revert to the yum backend, we can "just do it"?
18:33:50 <frankieonuonga> I think for now if we have both old way and this new way it will be fine...then by the time we are in beta we make sure most of the things are working.
18:35:07 <jreznik> abadger1999: I can recheck with mclasen
18:35:44 <notting> proposal: table for another week
18:35:50 <nirik> +1
18:36:03 <sgallagh> +1
18:36:06 <pjones> it does seem to be the obvious thing to do: +1
18:36:07 <mattdm> +1
18:36:14 <frankieonuonga> +1
18:36:25 <abadger1999> jreznik: is the hawkeye backend complete?
18:36:25 <t8m> +1
18:36:27 <jreznik> if you could summarize questions for app installer, I'm going to follow up with matthias (I can see two questions so far)
18:36:39 <mmaslano> +1
18:36:42 <jreznik> abadger1999: based on the page, it is
18:37:02 <sgallagh> abadger1999: When did this become the Avengers?
18:37:18 <abadger1999> and fesco question: does complete mean, "it's written" or" the packaing team's requirements have been fulfilled"?
18:37:40 * jreznik notes
18:38:01 <abadger1999> I meant that last one as a question for us to answer right now :-)
18:38:16 <pjones> abadger1999: "must be in a testable state" ;)
18:38:24 <mattdm> +1 pjones
18:38:43 <abadger1999> pjones: heh :-)  Is it testable that the QA team has committed to 100% compatibility testing?
18:39:26 <pjones> the answer here isn't any different than for any other feature, really.  it doesn't have to be perfect, but it can't be completely obvious that it's inadequate.
18:39:43 <notting> abadger1999: you ok with the revisit in one week?
18:39:47 <pjones> there's a lot of middle in between those.
18:40:14 <abadger1999> notting: yah, I think +1;  I think I'm just clarifying the quesetions that we want answered next week.
18:40:15 <jreznik> pjones: yep
18:40:42 <notting> #agreed revisit next week (+:8, -:0, 0:0)
18:40:49 <jreznik> abadger1999: that's what I need (to ask for)
18:41:31 <abadger1999> pjones: well... we kinda let the packaging team decide get a veto vote here -- so we need to make sure that their requirements are being met.
18:41:48 <abadger1999> or be renegoiated.
18:41:59 <notting> but we seem to have implied that it's ok if that doesn't land at the first moment
18:43:35 <abadger1999> Right .. But we haven't defined what parts do need to land.
18:44:11 <notting> true. i think that's part of the revisit next week?
18:44:35 <abadger1999> Is there part of it that we need to be more specific about?
18:45:40 <abadger1999> Like: Are we just asking, have you opened a dialog with QA?  Or are we asking, Does QA feel right that they can do 100% compat testing but not in time for alpha?
18:45:53 <abadger1999> Or something else :-)
18:45:57 <nirik> I don't think 100% compat is possible unless package team has a test suite.
18:46:16 <notting> nirik: so that expands to 'not obviously incompatible'?
18:46:17 <nirik> but I think qa could file any breakage they find.
18:46:22 <handsome_pirate> abadger1999:  What about us?
18:47:03 <abadger1999> nirik: if that's the case, then we'd probably want to have packaging team and app installer renegotiate -- ie the requirements packaging team is asking for are not going to be achievable.
18:47:10 <nirik> so I guess I'd say we deal with breakage (if any) based on severity and input frm packaging team?
18:47:27 * handsome_pirate is still wondering where QA fits in to this
18:47:31 <abadger1999> they either need to come to some new agreement or we might as well push the contingency plan button on the hawkey backend now.
18:47:47 <nirik> sure, we should/could ask that for next week?
18:47:48 <handsome_pirate> DNF?
18:47:51 <abadger1999> handsome_pirate: https://fedorahosted.org/fesco/ticket/1148#comment:28
18:48:01 <handsome_pirate> Could y'all give me a sec?
18:48:07 <abadger1999> handsome_pirate: his full compatibility must be thoroughly tested and signed off by Fedora QA before Beta Release of Fedora 20.
18:48:45 <abadger1999> nirik: yep, that would make things go faster :-)
18:49:37 <nirik> personally I think a sign off from qa that no regressions were noted would be enough... but I don't think qa has some yumdb test suite that can find any possible small problem...
18:49:40 <handsome_pirate> abadger1999:  Ouch
18:50:00 <handsome_pirate> nirik:  I'm leaning +1 to that
18:50:17 <nirik> I don't know if packaging team is ok with that tho. :)
18:50:17 <handsome_pirate> So, from a QA standpoint, we will need the following:
18:50:20 <abadger1999> nirik: dealing with breakage reported by the packaging team is not what they asked for.  Also,no noted regressions is also not what they asked for.
18:50:41 <handsome_pirate> A set of test cases against yum to benchmark against
18:50:42 <abadger1999> So yeah -- if we wantto change that, we need to make sure the packaging team is involved in the discussion, not just hte app install owners.
18:50:48 <nirik> abadger1999: we asked qa about this and they said they cannot ensure 100% compat... without some way to test that?
18:50:50 <handsome_pirate> A set of test cases for new PK
18:50:58 <handsome_pirate> And, how this is all going to change for DNF
18:51:30 <handsome_pirate> nirik:  Aye, we need a way to test for compat
18:51:48 <handsome_pirate> And that does not mean reading through the code to find the diffs
18:51:57 <handsome_pirate> We don't have time/people for that
18:52:35 <nirik> so, revisit next week, ask packaging folks about compat testing?
18:52:59 <frankieonuonga> nirik:too expensive to host both solutions through one release cycle then migrate things slowly?
18:52:59 <handsome_pirate> Also, make sure that test@fp.o is cced on that discussion
18:53:02 <notting> sounds good. jreznik - you ok with colelcting that info?
18:53:10 <jreznik> notting: sure
18:53:21 <handsome_pirate> frankieonuonga:  How do you mean?
18:53:29 <abadger1999> nirik: Okay -- so that sounds like, "ask the app installer and packaging team if either are willing to write the needed test cases.  If not, then does the packaging team see an alternative to the 100% compat testing or would they like to officially be against using the hawkey backend?"
18:53:41 <nirik> abadger1999: sounds fine to me.
18:53:50 <handsome_pirate> abadger1999:  Sounds fine here, too
18:54:01 <abadger1999> Works for me.
18:54:12 <frankieonuonga> handsome_pirate: support both ways of handling packages depending on the tool used..then as we go through to fedora 21 we slowly phase out the old way.
18:54:19 <nirik> frankieonuonga: well, yumdb is a single thing... the point of contention is both yum and gnome-software writing it and needing to do so in a compatible way
18:54:19 <abadger1999> jreznik: ^
18:54:33 <handsome_pirate> frankieonuonga:  What nirik just said
18:54:44 <notting> moving on to similar topics...
18:54:47 <notting> #topic #1164    F20 Changes - Progress on Changes Freeze
18:54:47 <notting> .fesco 1164
18:54:48 <zodbot> notting: #1164 (F20 Changes - Progress on Changes Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1164
18:55:53 <notting> i note jreznik's comment - "but no action needed at least for Alpha"
18:55:58 <notting> anyone want to disagree?
18:56:08 * nirik checks
18:56:25 <pjones> Well, there's a lot of stuff in assigned
18:56:40 <jreznik> pjones: it is, I tried to comment it as much as possible
18:56:54 <jreznik> contingency plans for system wide changes are Beta
18:57:05 <nirik> does the kernel team have any thoughts on bug 984718
18:57:13 <jreznik> for self contained, we can track progress now (and again, cut it at Beta time)
18:57:19 <notting> jwb: ^^^
18:57:20 <mattdm> jreznik i promise to actually update mine for _real_ this time.
18:57:27 <jreznik> mattdm: :)
18:57:43 <jwb> one sec
18:57:54 <sgallagh> .bz 984718
18:58:34 <abadger1999> .bug 984718
18:58:35 <jreznik> btw. I'd say - bz is quite useful for development tracking, especially with blocking tracker on real bugs
18:58:38 <zodbot> abadger1999: Bug 984718 Turn on 4.2 support for labeled nfs support - https://bugzilla.redhat.com/show_bug.cgi?id=984718
18:58:47 <sgallagh> abadger1999: Thanks. Bad command
18:59:15 <jwb> so... yeah.  nobody in the fedora team has seen this.
18:59:22 <jwb> and F20 has the config option on
18:59:23 <nirik> jwb: I feared as much
18:59:44 <handsome_pirate> mattdm:  Ping over in #fedora-qa right quick?
19:00:01 <pjones> vgoyal: how do you feel about our status on 998565 ?  Will it land in time for beta?
19:00:01 <jwb> but according to comment #7, that seems to be ok?
19:00:12 <sgallagh> jwb: What does that mean, exactly?
19:00:13 <pjones> (I guess I should have waited to ask that until jwb's question was finished)
19:00:16 <vgoyal> pjones: give me a sec
19:00:17 <sgallagh> It's built but no one is testing it?
19:00:31 <nirik> jwb: yeah. Don't need to address it now, just wanted to put it on your radar.
19:00:47 <jwb> sgallagh, basically.  having read the bug in 30 seconds, it means that userspace isn't updated to use this, so the kernel has the options on but nobody can use it
19:00:54 <vgoyal> pjones: i think i should be able to get this working by beta
19:01:01 <jwb> i'll CC myself and try and follow up in the bug
19:01:35 <sgallagh> vgoyal: If it's not working now, I think it's probably wiser to stick it in Rawhide and catch F21 instead.
19:01:42 <nirik> jwb: thanks!
19:01:51 <sgallagh> Changes have to be testable by Alpha in some meaningful way
19:02:08 <handsome_pirate> +1
19:02:15 <vgoyal> sgallagh: i think my patches should not break other things. I prefer that I atleast give beta time frame a shot and if things don't work till then, then this feature becomes a candidate for F21
19:03:03 <vgoyal> i have around 90% code ready in my machine. it is just rest of the 10% which needs to be sorted out
19:03:11 <abadger1999> .bug 998565
19:03:14 <vgoyal> esepcially w.r.t to signing
19:03:18 <zodbot> abadger1999: Bug 998565 Allow kdump on secureboot machines - https://bugzilla.redhat.com/show_bug.cgi?id=998565
19:03:38 <sgallagh> vgoyal: The problem is that no one will have time to test it between beta and final (and only blockers will go in after Beta)
19:03:59 <jreznik> sgallagh: it's not true (about blockers after beta)
19:04:12 <sgallagh> jreznik: Sorry, blockers and exceptions.
19:04:27 <vgoyal> sgallagh: who are we expecting to test between alpha and beta
19:04:35 <vgoyal> sgallagh: if it just developer testing, I will do that.
19:05:18 <jreznik> sgallagh: still not true - freeze is lifted between beta/final change deadline
19:05:27 <nirik> but not with the existing fedora bits tho right? since it's not fully landed?
19:05:32 <sgallagh> vgoyal: Alpha exists specifically to advertise the new functionality we want people to try out and help us sort out by Beta
19:05:48 <mjg59> vgoyal: Has the code been posted anywhere for review?
19:06:05 <nirik> vgoyal: is it just the one package needed?
19:06:05 <vgoyal> mjg59: no
19:06:16 <mjg59> vgoyal: So you want to land entirely unreviewed code after alpha?
19:06:24 <sgallagh> Proposal: Initiate the contingency plan for the NFS v4.2 Change and retarget for F21.
19:06:26 <vgoyal> mjg59: i am planning to post kernel patches today to fedora kernel mailing list
19:06:54 <nirik> sgallagh: I'd like to hear from feature owners, as it sounds like the config they need is in fact already enabled?
19:07:04 <vgoyal> mjg59: that code should not break other things and that's why i am hoping it is alright to land code after alpha
19:07:15 <sgallagh> nirik: vgoyal just said he's still planning to send out kernel patches for review
19:07:19 <mjg59> vgoyal: It's a huge security consideration
19:07:25 <nirik> sgallagh: this is two different things. ;)
19:07:34 <abadger1999> sgallagh: vgoyal is discussing kdump on secureboot machines
19:07:36 <mjg59> vgoyal: The thing it risks breaking is Fedora's valid signatures
19:07:54 <sgallagh> nirik: And as mjg59 points out, this has significant security impact. I for one am not comfortable landing that post-alpha
19:07:58 <vgoyal> mjg59: if there are major security concern with the pathces, I think it will be reasonable to not include it
19:08:03 <pjones> sgallagh: so unfortunately I screwed up and asked him while you and jwb were still discussing the nfs thing and now the fact that we've failed to enforce structure is becoming confusing.
19:08:36 <vgoyal> mjg59: are you referring to fedora's kernel signature?
19:08:40 <pjones> vgoyal: that's... sort of the problem with landing code late that has a security impact.
19:08:54 <sgallagh> pjones: Yes, I think I see where we're getting tripped up here. Whoops.
19:08:56 <pjones> vgoyal: it's important that there's sufficient time for it to be well examined before we ship it in a distro.
19:08:59 <mjg59> vgoyal: Yes
19:09:03 <pjones> sgallagh: yeah, totally my fault, sorry
19:09:13 <sgallagh> pjones: s'ok
19:09:40 <vgoyal> pjones: agreed. is it reasonable that I post code today and it be reviewed and if there are security concerns then it not be included
19:09:54 <vgoyal> pjones: my pathces are dependent on secure_modules() and keyring patches
19:10:02 <vgoyal> and these patches kind of stablized in kernel yesterday
19:10:06 <vgoyal> late evening
19:10:21 <pjones> jwb: mjg59: I guess that's a question for you (since I'm not a kernel maintainer for fedora)
19:10:54 * nirik would leave it up to kernel folks if they are comfortable pulling that kind of patchset in
19:11:04 <vgoyal> so if I can get one week, post the patches to fedora kernel mailing list, get feedback and if there are no major security concerns, can we get it committed then?
19:11:06 <jwb> vgoyal, you had them working against f19, right?  it just occurred to me that you could have posted that when you had it working
19:11:13 <jwb> is there a reason you didn't?
19:11:18 <vgoyal> jwb: yes i had them working for f19
19:11:35 <vgoyal> i think i should have posted it then. just that I started sorting out signing stuff in user space instead
19:12:10 <vgoyal> jwb: nothing particular. I just wanted to sort out user space signing using smart card and i got busy in that
19:12:17 <mjg59> nirik: I'm fine with it being a kernel decision, but I've little familiarity with the IMA subsystem so I'm certainly not going to be able to give positive feedback within a week
19:12:30 <jwb> vgoyal, aside from the kernel patches, what else is missing?
19:12:45 * nirik nods. It would also require a freeze exception to go in now...
19:12:48 <jwb> i don't believe this is just kernel related
19:12:49 <vgoyal> jwb: there are kexec-tools patches which compile it statically
19:13:12 <vgoyal> jwb: we need to include a new package ima-evm-utils and then there are more patches on top of it for signing using a daemon
19:13:33 <vgoyal> jwb: it is not but all the user space stuff should not break anythign else and should not be a security concern
19:14:02 <vgoyal> i think most important piece here is kernel patches and making sure that fundamentally they are not introducing any security hole
19:14:06 <pjones> So what you're saying is that *none* of this feature has landed yet?
19:14:18 <vgoyal> pjones: yes, none of it has landed yet
19:14:42 * abadger1999 would vote for contingency plan
19:14:44 <jwb> regardless of fesco's position, post the kernel patches so they can get reviewed
19:14:47 <jwb> please
19:15:03 <vgoyal> jwb: sure, i should have these posted by the end of day today
19:15:23 <abadger1999> jwb: +1 If nothing else, that gives a headstart on getting into the next release.
19:15:29 <mjg59> vgoyal: The security model is that there's an appropriately signed piece of userspace, right?
19:15:49 <vgoyal> yes, I extend root of trust to /sbin/kexec
19:15:56 <mjg59> vgoyal: So I think the userspace components are also pretty critical for carrying out a security review
19:16:21 <mjg59> vgoyal: Who does the kexec signing?
19:16:24 <vgoyal> mjg59: kexec-tools changes are not big. I just compile it statically
19:16:42 <mjg59> vgoyal: Yes, but the ima policy needs to exist, right?
19:16:45 <vgoyal> and there is small piece of code which recognizes that secureboot is enabled and verifies signature of bzImage
19:17:14 <vgoyal> mjg59: I use IMA subsystem by exporting some functions from it
19:17:14 <vgoyal> i as such don't load an IMA policy
19:17:31 <vgoyal> so I have modified keyctl() system call. So user space buffer can pass in a user buffer and signature and keyring and ask kernel to verify signature
19:17:40 <vgoyal> and keyctl() in turn calls in IMA function to do the job
19:17:49 <mjg59> Ok
19:17:55 <jwb> wait.. you modified a system call?
19:17:56 <mjg59> Who signs kexec?
19:17:58 * notting notes we're at 15 minutes for this feature alone
19:18:03 <vgoyal> so it is IMA code usage but not enabling IMA policy as such or loading any IMA policy
19:18:17 <vgoyal> ima-evm-utils
19:18:23 <mjg59> When?
19:18:35 <mjg59> Using which key?
19:18:38 <vgoyal> mjg59: when kexec-tools package is being built
19:18:56 <vgoyal> mjg59: i wanted to create an /sbin/kexec signing key (which in turn is signed by fedora CA key)
19:19:03 <mjg59> vgoyal: Where is this key kept?
19:19:28 <vgoyal> mjg59: I wanted it to be created in a smart card on fedora build server
19:19:32 <notting> jreznik: didn't patches punt web assets?
19:19:39 <mjg59> vgoyal: Have you spoken to infrastructure about this?
19:19:57 <mjg59> vgoyal: It sounds like you're asking for new build servers just to build kexec-tools
19:20:00 <vgoyal> mjg59: this build bit is yet to be made to work
19:20:03 <dgilmore> mjg59: not that I am aware of
19:20:05 <mjg59> vgoyal: …
19:20:28 <mjg59> vgoyal: Ok. I can certainly help review the kernel patches, but I don't see any way that this is going to be ready for F20.
19:20:29 <sgallagh> Is there a particular reason we're designing a new feature post-Alpha in a FESCo meeting?
19:20:37 <pjones> I'm starting to think this shouldn't have been considered a "self contained" change at all.
19:20:41 <vgoyal> mjg59: no, i have right now prepared code along the lines of pesign and I was hoping that same build server can be used for building and signing /sbin/kexec
19:20:52 <jreznik> notting: in https://fedorahosted.org/fesco/ticket/1147#comment:10 I can see "Given that it's past Change Freeze, and we're still eking out a cross-distro standard for the httpd paths that everyone is (un)happy with, I'm going to retarget that portion of this Change for Fedora 21. "
19:20:56 <notting> pjones: it's a system-wide one
19:20:58 <mjg59> vgoyal: But you haven't actually spoken to anyone involved in making that happen
19:20:58 <jreznik> so partially, yes
19:20:59 <pjones> but there are large parts of the Change filed that don't make that clear.
19:21:16 <pjones> notting: oh, my mistake.
19:21:29 <vgoyal> mjg59: yes, i have not. I was just stuck making code work on my local smart cards
19:21:36 <notting> proposal: move kdump-with-secureboot to F-21?
19:21:43 <t8m> notting, +1
19:21:43 <sgallagh> notting: +1
19:21:45 <notting> (just given the way this discussion is going)
19:21:48 <t8m> finally a proposal :D
19:21:53 <mmaslano> +1
19:21:55 <abadger1999> notting: +1
19:22:06 <nirik> notting: +1
19:22:15 <sgallagh> This clearly needs more time to get right
19:22:20 <mattdm> +1
19:22:32 <abadger1999> vgoyal: Also, please add the things discussed here that aren't already in the Plan to the Plan page.
19:22:47 <vgoyal> abadger1999: ok, will add more details to plan page
19:23:33 <mattdm> i have a thing to go to -- talk to y'all later
19:23:34 * vgoyal will atleast post patches for review, irrespective of the fact that they might not get in F20
19:23:53 <abadger1999> <nod>
19:23:56 <notting> #agreed retarget Kdump with Secure Boot for F-21 (+:8, -:0, 0:0)
19:24:02 <sgallagh> vgoyal: +1 (also +1 to the use of irrespective instead of *shudder* irregardless)
19:24:07 <vgoyal> thre are so many pieces that I was hoping we carry some of the pieces in F20
19:24:41 <pjones> Well, if you get your package additions reviewed and posted, there's no reason the packages themselves can't go in F20
19:24:54 <pjones> and then make the infra setup and enablement bits F21.
19:25:01 <pjones> which is really what the feature is
19:25:07 <vgoyal> pjones: ok, ima-evm-utils maintainer has fixed the issues, I will repost it for review
19:25:12 <notting> any other concerns on specific features at this point?
19:25:20 <sgallagh> BTW, no one else voted on my earlier proposal about NFS 4.2
19:25:35 <sgallagh> Proposal: Initiate the contingency plan for the NFS v4.2 Change and retarget for F21.
19:25:42 <t8m> sgallagh, +1
19:25:43 <nirik> sgallagh: -1
19:25:55 <abadger1999> sgallagh: -1;  can revisit next week
19:26:09 * notting is -1 on that for now too
19:26:27 * pjones thinks that's one we can punt to next week
19:26:37 <mmaslano> sgallagh: +1
19:27:06 * notting notes with -4, that can not pass
19:27:55 <t8m> next topic :D
19:28:04 <notting> ok
19:28:16 <notting> #topic #1168    Non responsive maintainer due to death.
19:28:16 <notting> .fesco 1168
19:28:17 <zodbot> notting: #1168 (Non responsive maintainer due to death.) – FESCo - https://fedorahosted.org/fesco/ticket/1168
19:28:41 <notting> given what was in the ticket so far
19:29:00 * nirik doesnt think we need a special case, but if people want one we could add one I guess.
19:29:10 <notting> proposal: no need to change policies for this - handle reasonably as it occurs with ticket to fesco and/or infra
19:29:15 <nirik> 1
19:29:16 <sgallagh> notting: +1
19:29:18 <nirik> +1 even
19:29:29 <mmaslano> nirik: we do not need special policy, but noting happened itself, soooo
19:29:54 <nirik> it did. It was on my list. I just hadn't gotten to it.
19:30:10 <abadger1999> notting: +1
19:30:11 <nirik> we have (now) a sop for departing sysadmins (for whatever reasons)
19:30:19 <pjones> notting: +1 (as I said in the ticket)
19:30:23 <mmaslano> nirik: ok, thanks
19:30:30 <nirik> of course that wouldn't handle the usual packager case, but we could handle that with a fesco ticket I would think...
19:31:25 <t8m> notting, +1
19:32:02 <notting> #agreed No need to change policies for this - handle reasonably if it occurs with ticket to fesco and/or infrastructure (+:6, -:0, 0:0)
19:32:45 <notting> #topic 1172 Handle retired packages that are not blocked
19:32:47 <notting> .fesco 1172
19:32:49 <zodbot> notting: #1172 (Handle retired packages that are not blocked) – FESCo - https://fedorahosted.org/fesco/ticket/1172
19:32:54 <notting> this was brought up on the list
19:33:33 <nirik> I think xine-lib got fixed?
19:33:42 <notting> tyll: your proposal is to block any retired packages that are not already blocked , and dependent packages shoud then be fixed?
19:34:10 * notting is +1 to that. if it's retired, we shouldn't be shipping them by accident
19:34:13 <tyll> notting: actually I hoped they would be fixed by now
19:34:32 <tyll> But since there is not much movement, I propose to block them now and see what happens then
19:34:38 <nirik> really most of those seem like they should be unretired and maintained by someone that needs them... but seems not.
19:34:42 <sgallagh> notting: Perhaps "either dependents should be fixed or someone needs to step up and maintain the required package"
19:35:02 <tyll> it is not really clear whether e.g. libgssglue is e.g. obsoleted by something else
19:35:02 * nirik is ok with blocking them... might get maintainers realizing they need them.
19:35:04 <t8m> notting, +1 to block
19:35:15 <sgallagh> I assume we mean block from F20+ and not retroactively?
19:35:24 <mmaslano> yes, +1 to blocking them
19:35:28 <tyll> yes, only f20+
19:35:34 <nirik> sgallagh: yeah, we don't block in stable releases.
19:36:01 <sgallagh> nirik: Right, but I thought I had heard rumblings to that effect as well, so I wanted to be clear.
19:36:12 <nirik> yeah, good plan.
19:36:40 <abadger1999> +1  to block
19:37:01 <sgallagh> Yes, +1 to block
19:37:06 <pjones> +1 to block them
19:37:56 <notting> #agreed Proposal in #1172 is accepted - retired packages should be blocked in rawhide/f20, and any issues then cleaned up. (+:6, -:0, 0:0)
19:38:06 <tyll> There might be more packages affected, because I do not have a full list of retired packages currently, can they be blocked then as well?
19:38:07 <notting> #undo
19:38:07 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x27081190>
19:38:11 <notting> #agreed Proposal in #1172 is accepted - retired packages should be blocked in rawhide/f20, and any issues then cleaned up. (+:7, -:0, 0:0)
19:38:30 <notting> tyll: it's a matter of consistency, so i'd say yes
19:38:46 * nirik nods
19:39:08 <sgallagh> +1
19:39:11 <t8m> I have to leave now
19:39:24 <abadger1999> tyll: yeah, send out the list of other packages but +1 to treating them the same.
19:39:49 <notting> tyll: you good to handle these?
19:39:59 <tyll> notting: yes, thank you
19:40:01 <abadger1999> tyll: If they haven't been announced before, probably want a time period after announcement for people to pick them up.
19:40:10 <dgilmore> tyll: thank you very much for your help with dealing with retired, FTBFS and orphaned packages
19:40:14 <tyll> abadger1999: yes, I will do it
19:40:18 <abadger1999> Cool.
19:40:37 <nirik> seconded. Thanks tyll!
19:40:56 <notting> woohoo, that's the full agenda
19:41:02 <notting> #topic next week's chair
19:41:08 <nirik> I had one ticket I filed after the agenda went out. ;(
19:41:09 <notting> any volunteers?
19:41:16 <notting> #undo
19:41:16 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x27a90e10>
19:41:16 <mmaslano> I can take it
19:41:22 <notting> nirik: want to bring it up?
19:41:24 <sgallagh> I almost certainly won't be around next week
19:41:37 <notting> #topic next week's chair
19:41:40 <nirik> we can, or punt to next week if people want.
19:41:46 <notting> #info mmaslano to chair next week's meeting
19:41:53 <notting> nirik: we've already lost two people from this meeting
19:41:56 <nirik> https://fedorahosted.org/fesco/ticket/1171
19:42:53 <sgallagh> notting: Keep it up, I'm sure we can lose more!
19:43:38 <notting> nirik: it's got a proposal, so vote in ticket?
19:43:46 <nirik> sure. if we can.
19:44:05 <mmaslano> nirik: sounds reasonable
19:44:09 <notting> #topic Open Floor
19:44:17 <notting> #info please vote on fesco ticket #1172 in the ticket
19:44:21 <notting> other items for open floor?
19:44:41 <sgallagh> 1171 or 1172?
19:44:57 * sgallagh notes that the info line doesn't match
19:45:05 <notting> #undo
19:45:05 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x269b1f50>
19:45:12 <notting> #info please vote on fesco ticket #1171 in the ticket
19:45:14 <notting> sgallagh: thx
19:45:45 <sgallagh> Sure, being pedantic is kind of my thing.
19:46:12 <notting> ok, if nothing else in two minutes, will end meeting
19:46:18 * nirik has nothing off hand
19:47:03 <mmaslano> good night
19:48:13 <notting> #endmeeting