18:00:44 #startmeeting FESCO (2013-09-04) 18:00:44 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:54 #meetingname fesco 18:00:54 The meeting name has been set to 'fesco' 18:00:54 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:00:54 Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:54 #topic init process 18:01:00 hi 18:01:05 hello, party people. 18:01:07 hey everyone 18:01:17 hola 18:01:38 morning. 18:01:51 Salutations 18:02:00 hello 18:02:10 sgallagh still no baby? 18:02:26 mattdm: She's being shy, I guess 18:03:14 hello 18:03:27 * notting looks. no mitr today? 18:04:12 he's on vacation 18:04:23 ok. then that's everyone. 18:04:34 #topic #1115 guidance from FESCO on packagekit upstream policykit change 18:04:34 .fesco 1115 18:04:36 notting: #1115 (guidance from FESCO on packagekit upstream policykit change) – FESCo - https://fedorahosted.org/fesco/ticket/1115 18:05:07 mattdm: you were poking halfie and were going to close this out? 18:05:24 um. 18:05:47 in theory i suppose I was. in practice, I totally forgot to do that. 18:06:25 #info mattdm to close out per notes from last week's meeting 18:06:28 ok, moving on 18:06:28 * mattdm makes note to actually do it. 18:06:48 #topic #1136 F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary 18:06:49 .fesco 1136 18:06:50 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 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 bbb now boots, but no net I think... 18:07:25 tflink: ^^? 18:07:28 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 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 s/few days/day 18:08:15 tflink, er... bbb doesn't boot the fedora kernel, does it? 18:08:22 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 jwb: supposedly that was fixed yesterday 18:08:38 pjones: correct, I haven't verified it myself 18:08:38 tflink, afaik, pbrobinson just added patches for that last night and there is no f20 kernel with them included 18:09:02 i thought that 3.11.0-3.fc20 had the patches 18:09:07 nirik: That's been one of my concerns 18:09:41 tflink, * Wed Sep 4 2013 Peter Robinson 18:09:42 - Add patch set to fix MMC on AM33xx 18:09:42 - Add support for BeagleBone Black (very basic!) 18:09:42 * Tue Sep 03 2013 Josh Boyer - 3.11.0-3 18:09:42 - Add system_keyring patches back in 18:09:43 we currently have highbank, qemu, wandboard working . Trimslice has a PCIe issue that prevents working ethernet. Wireless and usb adapters work 18:09:52 tflink, clearly not. i built 3.11.0-3 yesterday 18:10:03 tflink: I appear to be wrong about that, apologies 18:10:04 the implication from the ticket is that limited current support is due to bugs, not plans. is that actually the case? 18:10:16 notting: To an extent 18:10:34 evidently trimslice PCIe issue is now cooked as well- kylem just updated #fedora-arm on it 18:10:52 notting: Some of it is plain on missing support in upstream kernel 18:10:59 Note *some* 18:11:11 That, however, ought to be fixed 18:11:24 The rest is bug related, especially trimslice 18:11:29 if there are people doing testing with reasonably common hw, I have fewer concerns for alpha 18:11:35 kylem just reported that fixed as of five minutes ago 18:11:54 which means there are no patches for it in the kernel, and no built kernel 18:11:58 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 please be clear when you're describing things as fixed. 18:12:24 nirik, believe I have highbank covered 18:12:35 highbank == calxeda server socs? 18:12:42 notting: y 18:12:44 handsome_pirate: you mean "a fix has been checked in", not "there's a kernel built", yes? 18:12:45 nirik: I could help test highbank if I had access. Monday I should be on RH's internal network 18:12:54 pjones, not even taht 18:13:00 just "kylem has figured it out"? 18:13:11 pjones: That last is correct 18:13:16 < kylem> alright, i think i fixed trimslice. 18:13:20 yeah, that's really not the same as fixed. 18:13:26 he further clarified as 18:13:30 notting: Indeed 18:13:32 handsome_pirate: the tricky part in our setup is pxe booting setup needing access to pxe server, etc. 18:13:34 < kylem> i'd like to point out that "i think" does not necessarily imply 18:13:37 "is" 18:13:56 nirik: I'll ping you Monday or so 18:13:59 what is the actual topic here? 18:14:04 my understanding is that at THIS moment, the working platforms that we have builds for are: wandboard and highbank/caldexa 18:14:17 bconoboy: concerns about lack of working HW @ alpha freeze 18:14:19 tflink: vexpress, too 18:14:21 bconoboy: Is ARM in a sufficient state for Alpha freeze as a primary arch? 18:14:21 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 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 sgallagh: I think in another week, it would be 18:14:42 notting, i'm mostly wanting FESCo to get accurate information 18:14:54 handsome_pirate: And so, are you proposing a slip? 18:14:57 because at least 2 boards that were identified as fixed aren't 18:15:02 notting, that's really hard to say 18:15:23 sgallagh: We may be able to squeeze it all in 18:15:23 individual boards should not cause a slip. 18:15:27 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 notting, I'd even say that this is a board decision of how much hardware must a primary arch support 18:15:32 jreznik: yeah, I don't care so much about specific platforms as long as we have some common ones working 18:15:32 sgallagh: I don't think we'll need to slip 18:15:36 tflink, trimslice is also working with ethernet adapter or wireless. 18:15:49 tflink: +1 18:15:50 t8m, oh please no 18:16:01 the Board has no place deciding that 18:16:02 jreznik: Are we talking about making that an Alpha Release Criterion, then? 18:16:26 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 sgallagh: or that fesco criterion if you say it's what's desired for alpha 18:16:58 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 tflink: I believe the ARM guys may be able to slip it all in 18:17:25 Proposal: Addition to the Alpha Release Criteria: "All primary architectures must run on at least one readily-available hardware platform" 18:17:27 tflink: It's not like we haven't fudged for x86 in the past 18:17:36 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 With a better definition of "readily-available" 18:17:55 tflink: Wandaboard fits that 18:18:01 tflink: Actually, so does trimslice, since wireless works 18:18:11 * nirik nods. 18:18:12 It's only wired ethernet on trimslice that is buggy 18:18:19 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 Beagle and Panda both have TI SoCs 18:18:55 sgallagh, with some nice definition +1 18:19:15 sgallagh: ARM's already got a hw platform list in the criteria. see above. 18:19:18 yeah, I think most of my concerns have been addressed in the ticket since yesterday 18:19:26 immediate concerns, anyways 18:19:44 notting: Yeah, I see that. Right now, that list looks destined to force an Alpha slip. 18:19:47 as long as people who have wandboards (ie, not any fedora qa folks) are testing 18:19:56 tflink: do you have blocker bugs filed for the boards not working? 18:20:23 notting: no, we keep being told that the ARM folks don't want to block on specific hw 18:20:35 tflink: and yet the criteria lists specific hardware. 18:20:41 yep 18:20:52 * tflink will file bugs and propose as blockers today 18:21:06 well, beagle is the only one on the list thats not landed? 18:21:21 nirik: Aye 18:21:27 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 sorry I am late guys.. 18:21:49 beagle and panda then 18:22:26 proposal: follow blocker process per alpha release criteria. if ARM team and QA want to renegotiate the release criteria, let them? 18:22:36 notting: +1 18:22:38 sounds good to me 18:22:41 +1 18:23:02 +1 18:23:19 +1 18:24:10 +1 18:24:22 +1 18:24:23 +1 18:25:40 #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 #topic #1148 F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller 18:26:13 .fesco 1148 18:26:15 notting: #1148 (F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller) – FESCo - https://fedorahosted.org/fesco/ticket/1148 18:27:59 jreznik: current status, other than what was in the ticket? 18:28:31 notting: what I provided in the ticket - in the change page, gnome-software is now built for f20 18:28:50 and see Scope section for DONE items 18:30:20 does this include the yumdb bits in the PK hawkey backend? 18:30:35 notting: I'm willing to let that slide until beta, honestly. 18:30:53 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 so... what exactly happens with the version as currently packaged in the absence of the metadata (icons, appdata, etc.)? 18:31:43 at least, we have gnome-software imported to f20, so it should be possible to take a look on current status 18:32:04 notting: it will have limited functionality for now? I suppose so 18:33:36 ... ok. we could table this for another week if people want. 18:33:39 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 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 abadger1999: I can recheck with mclasen 18:35:44 proposal: table for another week 18:35:50 +1 18:36:03 +1 18:36:06 it does seem to be the obvious thing to do: +1 18:36:07 +1 18:36:14 +1 18:36:25 jreznik: is the hawkeye backend complete? 18:36:25 +1 18:36:27 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 +1 18:36:42 abadger1999: based on the page, it is 18:37:02 abadger1999: When did this become the Avengers? 18:37:18 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 I meant that last one as a question for us to answer right now :-) 18:38:16 abadger1999: "must be in a testable state" ;) 18:38:24 +1 pjones 18:38:43 pjones: heh :-) Is it testable that the QA team has committed to 100% compatibility testing? 18:39:26 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 abadger1999: you ok with the revisit in one week? 18:39:47 there's a lot of middle in between those. 18:40:14 notting: yah, I think +1; I think I'm just clarifying the quesetions that we want answered next week. 18:40:15 pjones: yep 18:40:42 #agreed revisit next week (+:8, -:0, 0:0) 18:40:49 abadger1999: that's what I need (to ask for) 18:41:31 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 or be renegoiated. 18:41:59 but we seem to have implied that it's ok if that doesn't land at the first moment 18:43:35 Right .. But we haven't defined what parts do need to land. 18:44:11 true. i think that's part of the revisit next week? 18:44:35 Is there part of it that we need to be more specific about? 18:45:40 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 Or something else :-) 18:45:57 I don't think 100% compat is possible unless package team has a test suite. 18:46:16 nirik: so that expands to 'not obviously incompatible'? 18:46:17 but I think qa could file any breakage they find. 18:46:22 abadger1999: What about us? 18:47:03 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 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 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 sure, we should/could ask that for next week? 18:47:48 DNF? 18:47:51 handsome_pirate: https://fedorahosted.org/fesco/ticket/1148#comment:28 18:48:01 Could y'all give me a sec? 18:48:07 handsome_pirate: his full compatibility must be thoroughly tested and signed off by Fedora QA before Beta Release of Fedora 20. 18:48:45 nirik: yep, that would make things go faster :-) 18:49:37 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 abadger1999: Ouch 18:50:00 nirik: I'm leaning +1 to that 18:50:17 I don't know if packaging team is ok with that tho. :) 18:50:17 So, from a QA standpoint, we will need the following: 18:50:20 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 A set of test cases against yum to benchmark against 18:50:42 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 abadger1999: we asked qa about this and they said they cannot ensure 100% compat... without some way to test that? 18:50:50 A set of test cases for new PK 18:50:58 And, how this is all going to change for DNF 18:51:30 nirik: Aye, we need a way to test for compat 18:51:48 And that does not mean reading through the code to find the diffs 18:51:57 We don't have time/people for that 18:52:35 so, revisit next week, ask packaging folks about compat testing? 18:52:59 nirik:too expensive to host both solutions through one release cycle then migrate things slowly? 18:52:59 Also, make sure that test@fp.o is cced on that discussion 18:53:02 sounds good. jreznik - you ok with colelcting that info? 18:53:10 notting: sure 18:53:21 frankieonuonga: How do you mean? 18:53:29 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 abadger1999: sounds fine to me. 18:53:50 abadger1999: Sounds fine here, too 18:54:01 Works for me. 18:54:12 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 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 jreznik: ^ 18:54:33 frankieonuonga: What nirik just said 18:54:44 moving on to similar topics... 18:54:47 #topic #1164 F20 Changes - Progress on Changes Freeze 18:54:47 .fesco 1164 18:54:48 notting: #1164 (F20 Changes - Progress on Changes Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1164 18:55:53 i note jreznik's comment - "but no action needed at least for Alpha" 18:55:58 anyone want to disagree? 18:56:08 * nirik checks 18:56:25 Well, there's a lot of stuff in assigned 18:56:40 pjones: it is, I tried to comment it as much as possible 18:56:54 contingency plans for system wide changes are Beta 18:57:05 does the kernel team have any thoughts on bug 984718 18:57:13 for self contained, we can track progress now (and again, cut it at Beta time) 18:57:19 jwb: ^^^ 18:57:20 jreznik i promise to actually update mine for _real_ this time. 18:57:27 mattdm: :) 18:57:43 one sec 18:57:54 .bz 984718 18:58:34 .bug 984718 18:58:35 btw. I'd say - bz is quite useful for development tracking, especially with blocking tracker on real bugs 18:58:38 abadger1999: Bug 984718 Turn on 4.2 support for labeled nfs support - https://bugzilla.redhat.com/show_bug.cgi?id=984718 18:58:47 abadger1999: Thanks. Bad command 18:59:15 so... yeah. nobody in the fedora team has seen this. 18:59:22 and F20 has the config option on 18:59:23 jwb: I feared as much 18:59:44 mattdm: Ping over in #fedora-qa right quick? 19:00:01 vgoyal: how do you feel about our status on 998565 ? Will it land in time for beta? 19:00:01 but according to comment #7, that seems to be ok? 19:00:12 jwb: What does that mean, exactly? 19:00:13 (I guess I should have waited to ask that until jwb's question was finished) 19:00:16 pjones: give me a sec 19:00:17 It's built but no one is testing it? 19:00:31 jwb: yeah. Don't need to address it now, just wanted to put it on your radar. 19:00:47 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 pjones: i think i should be able to get this working by beta 19:01:01 i'll CC myself and try and follow up in the bug 19:01:35 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 jwb: thanks! 19:01:51 Changes have to be testable by Alpha in some meaningful way 19:02:08 +1 19:02:15 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 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 .bug 998565 19:03:14 esepcially w.r.t to signing 19:03:18 abadger1999: Bug 998565 Allow kdump on secureboot machines - https://bugzilla.redhat.com/show_bug.cgi?id=998565 19:03:38 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 sgallagh: it's not true (about blockers after beta) 19:04:12 jreznik: Sorry, blockers and exceptions. 19:04:27 sgallagh: who are we expecting to test between alpha and beta 19:04:35 sgallagh: if it just developer testing, I will do that. 19:05:18 sgallagh: still not true - freeze is lifted between beta/final change deadline 19:05:27 but not with the existing fedora bits tho right? since it's not fully landed? 19:05:32 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 vgoyal: Has the code been posted anywhere for review? 19:06:05 vgoyal: is it just the one package needed? 19:06:05 mjg59: no 19:06:16 vgoyal: So you want to land entirely unreviewed code after alpha? 19:06:24 Proposal: Initiate the contingency plan for the NFS v4.2 Change and retarget for F21. 19:06:26 mjg59: i am planning to post kernel patches today to fedora kernel mailing list 19:06:54 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 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 nirik: vgoyal just said he's still planning to send out kernel patches for review 19:07:19 vgoyal: It's a huge security consideration 19:07:25 sgallagh: this is two different things. ;) 19:07:34 sgallagh: vgoyal is discussing kdump on secureboot machines 19:07:36 vgoyal: The thing it risks breaking is Fedora's valid signatures 19:07:54 nirik: And as mjg59 points out, this has significant security impact. I for one am not comfortable landing that post-alpha 19:07:58 mjg59: if there are major security concern with the pathces, I think it will be reasonable to not include it 19:08:03 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 mjg59: are you referring to fedora's kernel signature? 19:08:40 vgoyal: that's... sort of the problem with landing code late that has a security impact. 19:08:54 pjones: Yes, I think I see where we're getting tripped up here. Whoops. 19:08:56 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 vgoyal: Yes 19:09:03 sgallagh: yeah, totally my fault, sorry 19:09:13 pjones: s'ok 19:09:40 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 pjones: my pathces are dependent on secure_modules() and keyring patches 19:10:02 and these patches kind of stablized in kernel yesterday 19:10:06 late evening 19:10:21 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 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 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 is there a reason you didn't? 19:11:18 jwb: yes i had them working for f19 19:11:35 i think i should have posted it then. just that I started sorting out signing stuff in user space instead 19:12:10 jwb: nothing particular. I just wanted to sort out user space signing using smart card and i got busy in that 19:12:17 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 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 i don't believe this is just kernel related 19:12:49 jwb: there are kexec-tools patches which compile it statically 19:13:12 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 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 i think most important piece here is kernel patches and making sure that fundamentally they are not introducing any security hole 19:14:06 So what you're saying is that *none* of this feature has landed yet? 19:14:18 pjones: yes, none of it has landed yet 19:14:42 * abadger1999 would vote for contingency plan 19:14:44 regardless of fesco's position, post the kernel patches so they can get reviewed 19:14:47 please 19:15:03 jwb: sure, i should have these posted by the end of day today 19:15:23 jwb: +1 If nothing else, that gives a headstart on getting into the next release. 19:15:29 vgoyal: The security model is that there's an appropriately signed piece of userspace, right? 19:15:49 yes, I extend root of trust to /sbin/kexec 19:15:56 vgoyal: So I think the userspace components are also pretty critical for carrying out a security review 19:16:21 vgoyal: Who does the kexec signing? 19:16:24 mjg59: kexec-tools changes are not big. I just compile it statically 19:16:42 vgoyal: Yes, but the ima policy needs to exist, right? 19:16:45 and there is small piece of code which recognizes that secureboot is enabled and verifies signature of bzImage 19:17:14 mjg59: I use IMA subsystem by exporting some functions from it 19:17:14 i as such don't load an IMA policy 19:17:31 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 and keyctl() in turn calls in IMA function to do the job 19:17:49 Ok 19:17:55 wait.. you modified a system call? 19:17:56 Who signs kexec? 19:17:58 * notting notes we're at 15 minutes for this feature alone 19:18:03 so it is IMA code usage but not enabling IMA policy as such or loading any IMA policy 19:18:17 ima-evm-utils 19:18:23 When? 19:18:35 Using which key? 19:18:38 mjg59: when kexec-tools package is being built 19:18:56 mjg59: i wanted to create an /sbin/kexec signing key (which in turn is signed by fedora CA key) 19:19:03 vgoyal: Where is this key kept? 19:19:28 mjg59: I wanted it to be created in a smart card on fedora build server 19:19:32 jreznik: didn't patches punt web assets? 19:19:39 vgoyal: Have you spoken to infrastructure about this? 19:19:57 vgoyal: It sounds like you're asking for new build servers just to build kexec-tools 19:20:00 mjg59: this build bit is yet to be made to work 19:20:03 mjg59: not that I am aware of 19:20:05 vgoyal: … 19:20:28 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 Is there a particular reason we're designing a new feature post-Alpha in a FESCo meeting? 19:20:37 I'm starting to think this shouldn't have been considered a "self contained" change at all. 19:20:41 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 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 pjones: it's a system-wide one 19:20:58 vgoyal: But you haven't actually spoken to anyone involved in making that happen 19:20:58 so partially, yes 19:20:59 but there are large parts of the Change filed that don't make that clear. 19:21:16 notting: oh, my mistake. 19:21:29 mjg59: yes, i have not. I was just stuck making code work on my local smart cards 19:21:36 proposal: move kdump-with-secureboot to F-21? 19:21:43 notting, +1 19:21:43 notting: +1 19:21:45 (just given the way this discussion is going) 19:21:48 finally a proposal :D 19:21:53 +1 19:21:55 notting: +1 19:22:06 notting: +1 19:22:15 This clearly needs more time to get right 19:22:20 +1 19:22:32 vgoyal: Also, please add the things discussed here that aren't already in the Plan to the Plan page. 19:22:47 abadger1999: ok, will add more details to plan page 19:23:33 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 19:23:56 #agreed retarget Kdump with Secure Boot for F-21 (+:8, -:0, 0:0) 19:24:02 vgoyal: +1 (also +1 to the use of irrespective instead of *shudder* irregardless) 19:24:07 thre are so many pieces that I was hoping we carry some of the pieces in F20 19:24:41 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 and then make the infra setup and enablement bits F21. 19:25:01 which is really what the feature is 19:25:07 pjones: ok, ima-evm-utils maintainer has fixed the issues, I will repost it for review 19:25:12 any other concerns on specific features at this point? 19:25:20 BTW, no one else voted on my earlier proposal about NFS 4.2 19:25:35 Proposal: Initiate the contingency plan for the NFS v4.2 Change and retarget for F21. 19:25:42 sgallagh, +1 19:25:43 sgallagh: -1 19:25:55 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 sgallagh: +1 19:27:06 * notting notes with -4, that can not pass 19:27:55 next topic :D 19:28:04 ok 19:28:16