===================================
#fedora-meeting: FESCO (2013-09-04)
===================================
Meeting started by notting at 18:00:44 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-09-04/fesco.2013-09-04-18.00.log.html
.
Meeting summary
---------------
* init process (notting, 18:00:54)
* #1115 guidance from FESCO on packagekit upstream policykit change
(notting, 18:04:34)
* mattdm to close out per notes from last week's meeting (notting,
18:06:25)
* #1136 F20 System Wide Change: ARM as primary Architecture -
https://fedoraproject.org/wiki/Changes/ARM_as_Primary (notting,
18:06:48)
* 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) (notting, 18:25:40)
* #1148 F20 System Wide Change: Application Installer -
https://fedoraproject.org/wiki/Changes/AppInstaller (notting,
18:26:13)
* AGREED: revisit next week (+:8, -:0, 0:0) (notting, 18:40:42)
* #1164 F20 Changes - Progress on Changes Freeze (notting, 18:54:47)
* AGREED: retarget Kdump with Secure Boot for F-21 (+:8, -:0, 0:0)
(notting, 19:23:56)
* #1168 Non responsive maintainer due to death. (notting, 19:28:16)
* AGREED: No need to change policies for this - handle reasonably if
it occurs with ticket to fesco and/or infrastructure (+:6, -:0, 0:0)
(notting, 19:32:02)
* 1172 Handle retired packages that are not blocked (notting, 19:32:45)
* AGREED: Proposal in #1172 is accepted - retired packages should be
blocked in rawhide/f20, and any issues then cleaned up. (+:7, -:0,
0:0) (notting, 19:38:11)
* next week's chair (notting, 19:41:37)
* mmaslano to chair next week's meeting (notting, 19:41:46)
* LINK: https://fedorahosted.org/fesco/ticket/1171 (nirik, 19:41:56)
* Open Floor (notting, 19:44:09)
* please vote on fesco ticket #1171 in the ticket (notting, 19:45:12)
Meeting ended at 19:48:13 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* notting (86)
* nirik (54)
* vgoyal (45)
* sgallagh (44)
* handsome_pirate (43)
* abadger1999 (38)
* jwb (33)
* pjones (29)
* jreznik (24)
* mjg59 (20)
* tflink (17)
* zodbot (15)
* t8m (13)
* mmaslano (12)
* mattdm (11)
* tyll (7)
* bconoboy (6)
* frankieonuonga (5)
* pwhalen (3)
* dgilmore (2)
* mitr (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
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
<pbrobin...@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 <jwbo...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
