=================================== #fedora-meeting: FESCO (2011-06-22) =================================== Meeting started by ajax at 17:30:55 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-06-22/fesco.2011-06-22-17.30.log.html . Meeting summary --------------- * whenisgood followup (ajax, 17:33:34) * LINK: http://whenisgood.net/fescoweekly/ seems to report error (fedora_richie, 17:36:51) * LINK: http://whenisgood.net/fescoweekly/results/br7teq still shows a time (mjg59, 17:46:50) * AGREED: new meeting time is 1700UTC (1pm eastern, 7pm brno) (ajax, 17:47:14) * systemd conversion followup (ajax, 17:47:53) * #563 suggested policy: all daemons must set RELRO and PIE flags (ajax, 17:53:41) * LINK: https://fedorahosted.org/fpc/ticket/93 (nirik, 17:54:34) * ACTION: nirik to come up with guidelines for next week (ajax, 18:07:03) * ACTION: ajax to add relro to redhat-rpm-config (ajax, 18:07:16) * #599 F16Feature: ConsoleKit Removal/Automatic Multi-Seat Support (ajax, 18:08:33) * #607 F16Feature: Perl 5.14 (ajax, 18:09:12) * AGREED: feature is approved (ajax, 18:12:27) * AGREED: feature is tentatively declined pending demonstration that it works without extra downloaded binaries; afterwards, tentatively accepted pending anaconda integration (ajax, 18:26:34) * ACTION: mjg59 to raise discussion on devel@ (ajax, 18:31:01) * F16Feature: Boost 1.47 (ajax, 18:33:40) * AGREED: feature is approved (ajax, 18:46:00) * AGREED: revisit the feature process, please, please, please. (ajax, 18:46:12) * Orphaned package ownership claiming clarification (ajax, 18:46:29) * ACTION: nirik to write up proposal in the ticket (ajax, 19:05:51) * Next week's chair (ajax, 19:06:19) * ACTION: sgallagh to run next week's meeting (ajax, 19:07:24) * open floor (ajax, 19:08:04) * LINK: http://fedoraproject.org/wiki/FESCo_meeting_process (ajax, 19:08:13) * ACTION: ajax to postmortem on RemoveSETUID feature (ajax, 19:21:23) Meeting ended at 19:25:16 UTC. Action Items ------------ * nirik to come up with guidelines for next week * ajax to add relro to redhat-rpm-config * mjg59 to raise discussion on devel@ * nirik to write up proposal in the ticket * sgallagh to run next week's meeting * ajax to postmortem on RemoveSETUID feature Action Items, by person ----------------------- * ajax * ajax to add relro to redhat-rpm-config * ajax to postmortem on RemoveSETUID feature * mjg59 * mjg59 to raise discussion on devel@ * nirik * nirik to come up with guidelines for next week * nirik to write up proposal in the ticket * sgallagh * sgallagh to run next week's meeting * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * ajax (159) * pjones (117) * nirik (95) * sgallagh (68) * notting (51) * t8m (48) * mjg59 (45) * cwickert (29) * simo (25) * abadger1999 (22) * zodbot (11) * fenrus02 (11) * rbergeron (6) * kalev (5) * fedora_richie (3) * j_dulaney (2) * MarkDude (1) * drago01 (1) * mmaslano (0) ---- 17:30:55 <ajax> #startmeeting FESCO (2011-06-22) 17:30:55 <zodbot> Meeting started Wed Jun 22 17:30:55 2011 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:55 <ajax> #meetingname fesco 17:30:55 <ajax> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 17:30:56 <zodbot> The meeting name has been set to 'fesco' 17:30:56 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:31:07 * nirik waves. Thanks for taking the meeting wrangling on this week. 17:31:23 <pjones> woooo FESCO! 17:31:29 * notting is here 17:31:30 <pjones> let's get this party started! yeah! 17:31:45 <sgallagh> pjones: Might want to switch to decaf :) 17:32:00 <ajax> one moment while i dig up the command reference for stuff and/or wait for more people to join 17:32:01 <j_dulaney> Party? 17:32:07 <pjones> sgallagh: I don't actually drink coffee. 17:32:11 * cwickert is here 17:32:32 <sgallagh> pjones: Neither do I 17:32:47 <cwickert> brb, 5 minutes 17:32:50 * rbergeron hands out fesco pompoms 17:33:10 * MarkDude takes a pompom 17:33:27 <j_dulaney> PomPom? 17:33:30 <ajax> let's start in, this one will probably take long enough for cwickert to get back 17:33:34 <ajax> #topic whenisgood followup 17:33:49 <ajax> i saw a lot of chatter on the ticket and at least three different URLs 17:33:57 <ajax> which one am i expected to believe? 17:34:12 <pjones> well, the first one didn't work. 17:34:16 <ajax> .fesco 613 17:34:17 <zodbot> ajax: #613 (Whenisgood for FESCo weekly meetings) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/613 17:34:18 <pjones> I went with the last one, because the page loaded. 17:34:46 * sgallagh went with the one that was emailed out 17:34:48 <pjones> This is my advanced technique that qualifies me for A Leadership Role. 17:34:48 <mjg59> Yeah, sorry about dropping the ball on this 17:35:00 * nirik filled out one of them. 17:35:04 <nirik> I think the one from the email. 17:35:10 <pjones> sgallagh: at least two were emailed. 17:35:32 <sgallagh> pjones: Only one was emailed directly to the list. The others were (erroneously?) emailed as updates to the Trac ticket 17:35:33 <t8m> hello 17:35:43 <sgallagh> But for clarification, I filled out http://whenisgood.net/fescoweekly 17:35:44 <t8m> I'm sorry for being late 17:35:47 <nirik> hey t8m 17:35:53 <ajax> t8m: welcome, just talking about this 17:36:04 <ajax> er, about your whenisgood ticket 17:36:09 <ajax> got results yet? 17:36:11 <t8m> OK 17:36:22 <mjg59> Yeah, sorry, I'd just been in the process of setting it up when I saw the ticket 17:36:27 <mjg59> Then found that the URL in the ticket didn't seem to work 17:36:48 <pjones> This is going to sound insane, but as a result of the timezone/setup preferences being different between the two pages, my availability times on them vary. 17:36:49 <t8m> yeah I made the mistake with added / 17:36:51 <fedora_richie> http://whenisgood.net/fescoweekly/ seems to report error 17:37:04 <mjg59> fedora_richie: Welcome to the past 17:37:10 <pjones> fedora_richie: without the slash works. 17:37:14 * nirik wishes there was a better way to do this. whenisgood always confuses me. ;) 17:37:23 <pjones> nirik: it really is awful. 17:37:28 <fedora_richie> thanks, yes 17:37:41 <drago01> doodle? isn't really better though 17:37:42 <t8m> so the results are: http://whenisgood.net/fescoweekly/results/br7teq 17:37:57 <notting> that's in prague/brno time? 17:38:03 <t8m> yes 17:38:20 <t8m> -2h utc 17:38:25 <mjg59> So Tuesday looks like the most promising 17:38:47 <pjones> I love how you can't change the timezone on the results page, only on the input pages. 17:38:52 <t8m> actually utc is -2h 17:39:02 <mjg59> pjones: If you click on a date then it'll show you the local times 17:39:31 <cwickert> re 17:40:01 <ajax> cwickert: you appear to be the only one without a response on that results page? 17:40:02 <sgallagh> I'd like to express a preference for the Tuesday at 8:00 BRNO time 17:40:03 <cwickert> notting: you can select the timezone if set up properly 17:40:05 <pjones> mjg59: truly precious that there are 3 different zones listed for 5 people in the same timezone. 17:40:10 <mjg59> pjones: Yeah 17:40:18 <cwickert> ajax: for a reson, see my mail on fesco list 17:40:30 <cwickert> and Tuesday is the day that works least for me :( 17:40:42 <ajax> okay, well. 17:41:11 <ajax> the limited selections are noted, but you still haven't described your availability 17:41:13 <t8m> so then there is the Monday 7pm Brno time 17:41:19 <pjones> cwickert: in general I agree; this is the reason for the difference I mentioned above. 17:41:54 <cwickert> ajax: so how can I actually respond? 17:42:04 <cwickert> I cannot mark anything 17:42:22 <ajax> if you had marked nothing, we'd have known that none of them work for you. 17:42:30 <ajax> instead it looks like there are four available times. 17:42:49 <fedora_richie> filled in :) its done, happy now :) 17:42:51 <cwickert> ajax: it is not that nothing works but that the poll is not set up properly 17:43:08 <ajax> yes yes, i get it, it wasn't set up properly. 17:43:13 <ajax> tell me when you are available. 17:43:34 <mjg59> cwickert: Are you available at any of the times that are in the poll? 17:43:51 <mjg59> Because if not that's still meaningful information 17:44:05 * notting sees sgallagh's availability, concocts plan to send him to more meetings 17:44:16 <pjones> fedora_richie: don't take this the wrong way, but why are you telling us your availability? 17:44:34 <sgallagh> notting: I try to bundle them together on Thursdays so I only have one wasted day in the week :) 17:44:39 <cwickert> ok, I have now added my response 17:44:50 <cwickert> reload http://whenisgood.net/fescoweekly/results/br7teq please 17:44:58 <ajax> hey, exactly one time slot. 17:45:09 <nirik> so, perhaps we should do another one (or use mjg59's) to get a more global time... sounds like we will never get 100% coverage tho. 17:45:12 <t8m> OK so Monday 7pm Brno time 5pm UTC is it? 17:45:25 <cwickert> ajax: for me it shows none?! 17:45:29 <mjg59> Works for me 17:45:42 <sgallagh> t8m: That's noon EDT, yes? 17:45:46 <ajax> cwickert: for everyone else it appears to show 7pm brno. 17:45:51 <notting> sgallagh: 1PM 17:45:52 <cwickert> "No match. Consider excluding the least flexible respondents by clicking on the names towards the end of the list." 17:45:58 <mjg59> cwickert: Monday 19:00 is ok for you? 17:46:05 <pjones> Europe/Berlin 17:46:05 <pjones> Date: June 27, 2011 17:46:05 <pjones> Time: 7:00:00 PM 17:46:05 <pjones> Invitees: Christoph Wickert 17:46:11 <pjones> it... seems to say you said you're available. 17:46:21 <ajax> cwickert: you marked tuesday as unavailable and every other time slot as available 17:46:27 <cwickert> right 17:46:28 <t8m> sgallagh, no 1pm EDT 17:46:29 <nirik> what an interface whenisgood has. ;) 17:46:32 <cwickert> Monday works for me 17:46:39 <ajax> cool 17:46:42 <cwickert> Tuesday would also work, but only an hour later 17:46:44 <pjones> nirik: is that your zoidberg immitation? 17:46:45 <notting> and as the guy who has the 8PM brno/2PM edt conflict, i'm fine most days if we run over that hour 17:46:50 <mjg59> http://whenisgood.net/fescoweekly/results/br7teq still shows a time 17:46:53 <sgallagh> works for me 17:46:56 <mjg59> So let's go with that 17:46:59 <pjones> yes. 17:47:04 <pjones> let's go with that. 17:47:08 <nirik> so, monday at 5UTC? 17:47:10 <cwickert> +1 17:47:12 <sgallagh> +1 17:47:14 <ajax> #agreed new meeting time is 1700UTC (1pm eastern, 7pm brno) 17:47:14 <t8m> +1 17:47:18 * notting now completely writes off his mondays 17:47:27 <pjones> notting: I hear there's a song about that. 17:47:38 <nirik> hurray 17:47:51 <ajax> next 17:47:53 <ajax> #topic systemd conversion followup 17:48:06 <ajax> sgallagh: this was yours i think? 17:48:17 <sgallagh> Yes 17:48:39 <sgallagh> I'd like to invite Viking-Ice to fill in where I make mistakes, but I'll try to sum up 17:49:14 <sgallagh> Viking-Ice proposed that the alpha cutoff should be "Services on the livecd" instead of "services in @base" 17:49:43 <sgallagh> He and collaborated to create a tracking BZ, https://bugzilla.redhat.com/show_bug.cgi?id=713562 17:50:02 <t8m> If I disconnect it is due to a thunderstorm - not that I would not like to stay on the meeting :) 17:50:32 * nirik finds that fine. Hopefully we can reach that target. 17:50:34 <sgallagh> I agreed with his recommendation that the livecd makes more sense 17:50:47 <ajax> only 35 bugs, seems quite achievable 17:51:03 <sgallagh> It is my understanding ( Viking-Ice, please correct me) that all of these have at least a proposed patch available, save cpuspeed 17:51:12 <t8m> I'm fine with that too. 17:51:28 <sgallagh> The discussion on cpuspeed seems to be leaning towards not having an init/unit script at all in F16 17:52:06 <nirik> cool. 17:52:09 <nirik> less files. ;) 17:52:23 <ajax> all bugs are in files, after all. 17:52:23 <sgallagh> So I would say that we appear to be in good shape for our Alpha goal. 17:52:42 <sgallagh> ajax: Except the PEBKACs 17:53:02 <ajax> excellent! i think we can leave this to bugzilla for now then, if it becomes an issue as alpha approaches we can look into it then. 17:53:12 * nirik nods. 17:53:30 <sgallagh> I agree 17:53:32 <t8m> +1 17:53:36 <ajax> right, next issue then. 17:53:41 <ajax> #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:53:42 <ajax> .fesco 563 17:53:43 <zodbot> ajax: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 17:54:03 <nirik> so, I asked FPC to look at this. 17:54:14 <nirik> they basically would like to do something like we did for the services allowed to start on boot... 17:54:34 <nirik> https://fedorahosted.org/fpc/ticket/93 17:54:47 <ajax> to the extent that this was on me, i haven't changed redhat-rpm-config for relro yet (locally, but not in git) since i hadn't verified the change yet. 17:54:59 <nirik> basically they would add to guidelines that folks can do foo and bar to override the flags and a list of packages that should do so it at: X 17:55:53 <nirik> ie, they would like us to make the list and/or hurestic. ;) 17:56:39 <nirik> would someone be willing to write up a draft and/or list of packages? 17:56:42 <ajax> something like "runs setuid or listens on a privileged port" ? 17:56:46 <pjones> So we can just start the list as [] and wait for somebody to complain, right? ;) 17:57:07 <nirik> well, long ago the orig ticket for this listed some of them... 17:57:09 <pjones> Oh, they want a list of packages that /should/ do it. huh. 17:57:13 <nirik> yeah. 17:57:29 <abadger1999> FPC also wasn't clear what the slowdown we were worried about was -- 0.5s startup wasn't much and the runtime cost that Jakub mentions wasn't quantified inthe fesco ticket. 17:57:35 <t8m> IMO there should be a general recommendation rule and not a strict list of packages. 17:57:36 <nirik> unless we wish to press jakub more about why it's bad to enable globally. He said there is a .5 second startup cost. 17:57:53 <pjones> seems a _little_ weird to whitelist rather than blacklist. 17:58:09 <mjg59> .5 second startup cost in what? 17:58:13 <mjg59> The system? Each app? 17:58:14 <abadger1999> We'd be fine with sticking to "Use CFLAGS" and CFLAGS starts using relro and pie but that doesn't seem to be what was asked for. 17:58:15 <pjones> .5 seconds is too long for a great many things, but not really for most daemons. 17:58:16 <ajax> mjg59: whole system, iirc 17:58:34 <ajax> abadger1999: PIE is really the contention here 17:58:34 <pjones> oh, for the whole system. well, that's terrible, but maybe not a deal breaker. 17:58:39 <mjg59> Because if it's .5 seconds for the whole system for a demonstrable improvement in security, then really 17:58:46 <ajax> relro costs virtually nothing 17:58:53 <pjones> mjg59: then really: omg, why's it take .5 seconds? 17:58:57 <ajax> (after app start) 17:59:18 <ajax> and even at startup it's like two additional syscalls in the worst case. microseconds. 17:59:35 <nirik> "Furthermore, PIEs aren't prelinkable, so you will loose up to half a second or so on startup of larger apps. " 17:59:42 <pjones> oh. 17:59:45 <pjones> sure, no problem. 17:59:48 <mjg59> Ah, right 17:59:52 <pjones> well into "don't care". 17:59:55 <abadger1999> <nod> I'd recommend adding relro to the global cflags then and narrow what's still in contention to just pie. 18:00:05 <nirik> abadger1999: that was the plan. ;) 18:00:12 <abadger1999> :-) 18:00:24 <pjones> those apps are exactly the sort of apps that show the most benefit - long running things that talk to random user-supplied data files and network input. 18:00:31 <ajax> so, who wants to write guidelines? 18:00:51 <t8m> the -Wl,-z,now and -pie was the "only for selected packages" 18:01:05 <ajax> also i tend to thinkof pie not being prelinkable as an indictment of prelink more than of pie 18:01:30 * t8m never liked prelink at all :) 18:01:40 * nirik would be happy to wave goodbye to prelink, but last time I tried people still wanted it around. 18:01:52 <abadger1999> We (FPC) could take a blacklist instead of a whitelist -- if that's the case, though, I'd suggest adding pie to the default cflags and just listing the packages that are allowed to filter pie out of cflags. 18:02:14 <mjg59> It's the big apps like Libreoffice and Firefox that would benefit most from this 18:02:24 <notting> i think a whitelist would probably be easier to write, unforutnately 18:02:34 <mjg59> And I think a hit on their startup is reasonable 18:02:38 <nirik> openoffice (at the time) was one of the big supporters of prelink 18:03:02 * pjones has always had regrets about prelink as well 18:03:16 <nirik> they do have a quicklauncher thing now tho, so perhaps they would be less resistant. 18:03:33 <mjg59> nirik: Oh, I know it benefits them. And I think that's rational for the plain prelink/no-prelink case. 18:03:50 <mjg59> nirik: But if the choice is prelink/no-prelink+additional security... 18:04:14 <pjones> so even if we do a whitelist as fpc has asked, the things we'd list on it are still things that prelink helps be tolerable. 18:04:20 <ajax> irritatingly, openoffice went so far as to submit patches to the runtime linker that would have eliminated most of that cost, and glibc studiously refused them. 18:05:00 <nirik> bummer. ;( 18:05:20 <nirik> anyhow, I suppose I could take a stab at a list or guideline... 18:05:24 <sgallagh> [OT] glibc has a serious case of NIH that should be addressed at some point 18:05:28 <nirik> probibly a list would be easier. 18:05:57 <simo> sgallagh, good luck with that :) 18:06:05 <ajax> nirik: that would be excellent. do you have a preference for discussing it next week in the meeting, or on devel@, or... 18:06:10 <t8m> I think the guideline proposal from Toshio is fine. 18:06:11 <nirik> suid/cap_sysadmin/priv port using/has had security issues in the past or something. 18:06:31 <nirik> yeah, lets hit it next week at least... hopefully I will have something then. 18:06:33 <sgallagh> nirik: Might want to specify which category of security issues 18:06:51 <nirik> sgallagh: yeah, that could play into it too. 18:06:53 <sgallagh> Minor, local DoS vs. Remotely executable privilege escalation 18:06:53 <pjones> nirik: I think also any longrunning process (web browser, office suite, emacs) 18:07:03 <ajax> #action nirik to come up with guidelines for next week 18:07:12 <pjones> nirik: we have to look after security of our users' data as well as overall system security, after all. 18:07:16 <ajax> #action ajax to add relro to redhat-rpm-config 18:07:27 <ajax> anything else on this? we're close to 15. 18:07:29 <nirik> yeah, so it might be a long list... I guess we can see. ;) 18:07:36 * nirik has nothing more. 18:08:21 <ajax> hmm. 18:08:24 <ajax> so i have in my notes: 18:08:33 <ajax> #topic #599 F16Feature: ConsoleKit Removal/Automatic Multi-Seat Support 18:08:33 <ajax> .fesco 599 18:08:43 <ajax> but i don't think we actually had anything to follow up on for this 18:08:44 <zodbot> ajax: #599 (F16Feature: ConsoleKit Removal/Automatic Multi-Seat Support - https://fedoraproject.org/wiki/Features/ckremoval) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/599 18:08:44 <nirik> oh, my bad. I think we approved that. I just forgot to close it. 18:09:01 <ajax> nirik: no worries, i'll close it out after this meeting 18:09:08 <ajax> onward! 18:09:12 <ajax> #topic #607 F16Feature: Perl 5.14 18:09:13 <ajax> .fesco 607 18:09:14 <zodbot> ajax: #607 (F16Feature: Perl 5.14 - https://fedoraproject.org/wiki/Features/perl5.14) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/607 18:09:48 <nirik> we approved this one too, but this is the 'official via the feature wrangler' version. ;) 18:09:51 <nirik> so, still +1 from me. 18:10:07 <sgallagh> This is little more than a mass rebuild in most cases, yes? 18:10:12 <t8m> +1 18:10:18 <mjg59> +1 18:10:19 <ajax> sgallagh: looks that way to me 18:10:33 <pjones> +1 18:10:40 <sgallagh> I noted that the Feature specified that some perl features changed in a non-backwards-compatible manner 18:11:05 <pjones> sgallagh: sure, but that happens on a regular basis, and people maintaining perl modules and such just need to keep up. c'est la vie. 18:11:31 * notting is still +1 18:11:35 <sgallagh> pjones: Understood, I'm just a little wary of the sparseness of the contingency plan 18:12:11 <ajax> yeah, the "if they don't have any other deps" is a little cavalier 18:12:20 <ajax> but we won't know until we know, i guess 18:12:24 <cwickert> +1 18:12:27 <ajax> #agreed feature is approved 18:12:30 <sgallagh> I'm +0 on this 18:12:32 <t8m> sgallagh, I think this time the incompatibilities are not huge 18:12:44 <pjones> and still, it's better to move forward and force the apps than to get stuck in the position we used to with e.g. zope+python. 18:13:00 <sgallagh> I don't disagree, but I don't like the lack of a plan. 18:13:07 <ajax> #608 F16Feature: Trusted Boot 18:13:07 <ajax> .fesco 608 18:13:09 <zodbot> ajax: #608 (F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/608 18:13:14 <sgallagh> So I'm not going to vote against it, but I'm not FOR it either 18:13:47 * nirik is -1. I don't want to encourage using or accomodate binary only closed source things. 18:13:49 <pjones> I hate this with every fiber of my being. 18:13:56 <notting> that screenshot is horrible 18:14:39 <ajax> gwei makes the assertion (on the ticket) that we would not need to ship any binary blobs ourselves for this 18:14:45 <sgallagh> Is there any way that this could be pushed to RPMfusion and leave us out of it? I'm guessing "no" since it's so early in the boot process 18:14:50 <t8m> Note that they said that the binary blob is part of BIOS 18:14:50 <ajax> which at least makes it less horrible 18:15:01 <pjones> ajax: there's been some back and forth on that, but I'm not convinced either story is true 18:15:26 * cwickert needs to read first 18:15:29 <nirik> I don't think we need to ship any... 18:15:31 <ajax> at any rate, i can't fathom any reason why this should need installer UI 18:15:41 <mjg59> I'm greatly unenthusiastic about tboot, but if the sinit block is in system BIOS then I think accepting it would be consistent 18:15:50 <nirik> but we need to adjust ALL our users boot process to accomodate those people who choose to download a binary only blob 18:15:59 <pjones> ajax: we'd get out of it by having it be provided by the firmware, which a) right now it's not on any BIOS i've ever seen, b) it might be on some UEFI systems, and c) doesn't mean we're not running proprietary code on the host cpu with kernelish (well, SMMish) protections at runtime. 18:16:10 * nirik re-reads. I thought a download was required. 18:16:16 <mjg59> But: 18:16:24 <pjones> so they're really differentiating shipping it from running it, which only fixes one of the problems we have. 18:16:31 <mjg59> I would say that this needs to be testable without requiring any non-BIOS blobs 18:16:32 <cwickert> sorry if this is stupid question, but what is "trusted boot". The wiki page everybody knows it 18:16:47 <ajax> cwickert: it's a way of getting your BIOS to not load the OS 18:16:52 <cwickert> s/wiki page/wiki page assumes 18:16:58 <mjg59> cwickert: The ability to ensure that every piece of software you run, from the BIOS up, is from an identified source 18:17:05 * cwickert googles 18:17:12 <pjones> cwickert: the idea is that you can have your bootloader/kernel checkpointed in such a way that if they're tampered with, the system will refuse to boot. 18:17:28 <pjones> there is a fleeting but technically extant class of exploits that it solves. 18:17:42 <ajax> (my phrasing was a bit clever there, apologies if it translates poorly) 18:17:44 <sgallagh> I'd like to propose that we reject this as a feature for Fedora 16 and work on having it be implemented as a Spin. We can consider merging it in F17 18:17:53 <pjones> mjg59: sadly, not just identified but (implicitly) approved. 18:17:54 <mjg59> Proposal: Decline the feature unless it can be demonstrated to work on existing platforms without requiring distribution or downloading of closed binaries 18:18:20 <t8m> mjg59, +1 18:18:21 <notting> pjones: so, public/private keys? 18:18:24 <notting> mjg59: +1 18:18:38 <pjones> notting: with the private key being on your northbridge, AIUI 18:18:40 <ajax> mjg59: +1 18:18:53 <cwickert> what is the scope of the feature? having tboot as a package or having it so prominently in the installer? 18:19:05 <pjones> cwickert: not really well specified. 18:19:09 <cwickert> -1 for adding it as a separate group to anaconda 18:19:15 <mjg59> If it can be then I don't think we have any reason to refuse it other than taste, but it should also be obvious that we're approving the process of development and not mandating that Anaconda suddenly develop tboot buttons 18:19:16 <cwickert> and not sure about the rest 18:19:16 <t8m> cwickert, tboot as a package is already in Fedora 18:19:22 <pjones> a separate anaconda group wouldn't be a sensible way of doing it in any event. 18:19:23 <notting> i would assume 1) ship the tboot package 2) make it a default package in base/core 3) add grubby hooks for it 18:19:27 <sgallagh> Was I supposed to prefix my proposal above with Proposal: to have it voted on? 18:19:35 <t8m> pjones, of course 18:19:45 <ajax> sgallagh: it's unambiguous in this case 18:20:11 <ajax> oh wait, did you propose something and i missed it? 18:20:16 <sgallagh> ajax: Well, mjg59's proposal is to deny. Mine is to deny but encourage a spin. 18:20:18 <pjones> mjg59: +1 I guess, though I'm really not thrilled with the position that leaves us in if they comply with that. 18:20:30 <pjones> sgallagh: I'm definitely -1 to encouraging a spin here. 18:20:50 <nirik> mjg59: +1 I guess... 18:20:53 <sgallagh> pjones: Well, it seems to me that this is a feature useful to a small target as well 18:20:54 <pjones> (in that it'll still mean more work for the anaconda team that could be devoted to something users want instead) 18:21:25 <mjg59> sgallagh: I think at this point we're still talking about a technical enough audience that we could just tell people to add tboot to a kickstart file 18:21:30 <nirik> adding in another step of the boot process 100% of our users have to use for something that very very very very few will want to or bother to use, seems poor to me. 18:21:48 <ajax> pjones: i guess i'm not entirely clear on why it needs to chainload like xen 18:21:50 <pjones> sgallagh: but what I want to avoid is forcing people other than the proposer to work on this. 18:22:10 <ajax> as opposed to just being a kernel feature 18:22:10 <sgallagh> pjones: Understood, but they can submit their own patches to anaconda if they want to :) 18:22:13 <pjones> ajax: because the root of trust needs to be before the kernel starts, iirc. 18:22:27 <notting> pjones: what exactly happens on kernel upgrade? you call some magic command to hash the kernel and store it in the tpm? 18:22:35 <pjones> ajax: but don't take my word for that, it's been quite some time since I looked at this thoroughly from a technical implementation standpoint 18:22:38 <ajax> pjones: okay, grub2 then 18:22:41 <pjones> notting: completely unclear. 18:23:15 <mjg59> ajax: Because that would mean writing grub code 18:23:19 <notting> pjones: presumably *something* of that sort happens then 18:23:27 <sgallagh> Proposal: drop tboot for F16. Revisit in F17. 18:23:38 <ajax> so technically we have a majority on mjg59's proposal; are we still debating? it sounds like we are. 18:23:40 <mjg59> sgallagh: I think that's a bit strong 18:23:44 <pjones> ajax: I think they got tired of trying to push a grub1 _tree_ at me and decided to do it as a multiboot module instead, but as with congressional confirmation hearings: "I can't know the motivations of others". 18:23:50 * nirik would personally be for mjg59's proposal + is setup as 'opt-in' for people who wish it. (with a tool or guide or whatever) but not default. 18:24:00 <notting> nirik: isn't that the current state? 18:24:14 <pjones> sgallagh: I don't want to give them no chance to move forward in getting our blessing; just dropping it is too harsh. 18:24:29 <nirik> notting: perhaps? there's no tool I don't think... or way to tell users who could use it? 18:24:34 <pjones> that being said, they do actually need to, you know, satisfy our questions. 18:24:34 <sgallagh> pjones: A fair point. I withdraw my proposal 18:24:42 <sgallagh> mjg59: +1 18:24:47 <ajax> right then 18:24:48 <mjg59> I think we should tentatively decline until it's demonstrated that there's working setups which don't require extra binary objects, and if so tentatively accept with the proviso that Anaconda integration is going to have to be negotiated with the Anaconda team 18:25:05 <t8m> +1 18:25:09 <sgallagh> mjg59: +1 18:25:11 <ajax> politics! 18:25:12 <ajax> +1 18:25:22 <notting> sure, +1 18:25:41 <ajax> i still only barely understand why people would want to make booting more fragile, but i guess people are weird. 18:25:42 <nirik> sure, +1 18:25:58 <mjg59> ajax: See: EFI 18:26:04 <t8m> ajax, :) 18:26:34 <ajax> #agreed feature is tentatively declined pending demonstration that it works without extra downloaded binaries; afterwards, tentatively accepted pending anaconda integration 18:26:56 <notting> ajax: it's not about making it more fragile, it's about creating sealed devices 18:27:03 <pjones> ajax: uh, I don't think that's what we agreed on. 18:27:15 <ajax> oh? 18:27:18 <pjones> Well, okay, I guess that's what 5 people agreed on, so I guess it is. 18:27:24 <pjones> I just don't happen to like it. 18:27:45 <ajax> oh i don't either 18:28:03 <pjones> I think we need more details to even know what it is we're approving. The fact that we've isolated one thing we're not okay with shouldn't mean we're accepting it if we see that thing explained away. 18:28:19 <ajax> also fair. 18:28:28 <pjones> so I'm onboard with "tentatively rejecting", but I'm not okay with implicitly approving. 18:28:41 <mjg59> Yeah, ok. s/anaconda integration/technical discussion/ ? 18:28:43 <ajax> #note there may well be other issues that prevent inclusion; we're not deciding that here. 18:28:50 <pjones> good enough. 18:29:15 <sgallagh> pjones makes a good point. I think we should reject today and leave open the option to re-propose the feature if and when the questions we raised are answered 18:29:36 <mjg59> Perhaps also encourage bringing it up on devel@? 18:29:39 * nirik nods. I would be fine with that. 18:29:46 <mjg59> It's wide-ranging enough that we probably need to have a broad discussion 18:30:03 <pjones> I think we need somebody from jreiden's team to explain what it is they're doing in this regard as well 18:30:16 <pjones> because I'd hate to have intel and rh disagreeing on what's supposed to be getting done. 18:30:17 <ajax> who wants to start the thread? 18:30:27 <mjg59> ajax: I'll do that 18:30:47 <ajax> mjg59: way to step in front of that bullet 18:31:01 <ajax> #action mjg59 to raise discussion on devel@ 18:31:04 <t8m> pjones, although I am from jrieden's team I do not work on TPM 18:31:38 <ajax> anything else here? 18:31:59 <pjones> t8m: right. I imagine we probably want Jack, or at least to ask him who we should be talking to. 18:32:20 <ajax> sounds like a no to me. next item: 18:32:21 <ajax> #609 F16Feature: Boost 1.47 18:32:22 <ajax> .fesco 609 18:32:23 <zodbot> ajax: #609 (F16Feature: Boost 1.47 - http://fedoraproject.org/wiki/Features/F16Boost147) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/609 18:33:13 <sgallagh> I'm not clear why this is a Feature 18:33:19 * nirik hands ajax a #topic 18:33:29 <ajax> oops. 18:33:38 <mjg59> sgallagh: Because it's the only way to get stuff in the release notes? 18:33:40 <ajax> #topic F16Feature: Boost 1.47 18:33:44 <nirik> sgallagh: they have been in the past I guess... 18:33:51 <notting> mjg59: i'm not even sure why this merits a release note 18:33:59 <ajax> yeah, this is really in the same pile as all the other developer features 18:34:03 <mjg59> notting: Well, yes 18:34:27 <nirik> see http://fedoraproject.org/wiki/Features/F15Boost146 http://fedoraproject.org/wiki/Features/F14Boost144 http://fedoraproject.org/wiki/Features/F13Boost141... 18:34:28 <notting> Proposal: keep up the good work & coordination, but this does not need to be a feature 18:34:28 <sgallagh> Yeah, we don't have a Feature for every GLib update (for example) 18:34:40 <t8m> notting, +1 18:34:47 <sgallagh> notting: +1 18:34:51 <mjg59> +1 18:35:05 <abadger1999> It's a feature because it requires coordination with other packagers. 18:35:20 <ajax> +1, although that's creeping close to rewriting the feature process (or at least criteria), which isn't really the issue in front of us right now. 18:35:28 <abadger1999> It's one of those "Does not need a release note, needs developer cooperation and harmony" features. 18:35:30 <nirik> "I'm rebuilding your package for the new boost feature" 18:35:41 <sgallagh> abadger1999: How much developer time are we talking? 18:35:44 <ajax> rbergeron: how's that coming along, btw 18:35:54 <sgallagh> If it's not a trivial rebuild, I may change my vote. 18:36:20 <notting> abadger1999: it's a ABI change. we don't categorize all of those as Features, so the question is roughly at what scale we start doing that. 18:36:33 <abadger1999> sgallagh: That would block many things from ever going into Fedora. 18:36:45 <cwickert> +1, sorry I'm late 18:36:51 <t8m> abadger1999, why? 18:36:59 <sgallagh> abadger1999: No, I meant that I wouldn't vote against it as a Feature in that case :) 18:37:10 <abadger1999> sgallagh: oh, okay :-) 18:37:45 <sgallagh> abadger1999: Is it a SOname bump? 18:37:46 <t8m> I do not think there have to be features for upstream rebases with ABI change. 18:37:53 <abadger1999> notting: Sure... it would seem to fall under the current definition of a feature, though: http://fedoraproject.org/wiki/Features/Policy/Definitions 18:38:12 <nirik> so, I think this needs addressing as part of the feature process rework, but for now, I am ok with +1ing it as we have previous ones. 18:38:12 <abadger1999> "Are there a large number of packages that depend on your package that will be affected by an upgrade/change/etc ?" 18:38:13 <sgallagh> Right, point 2) 18:38:30 <pjones> I can't possibly communicate how much I don't care about boost, but I'm +1 to shipping their current release in our current release, and +1 to notting's proposal. 18:38:30 <notting> abadger1999: at which point, we're quibbling over the definition of 'large' 18:38:45 <t8m> abadger1999, if it's just a rebuild it is not really affected much 18:38:51 <abadger1999> Someone could add a summary of "define large" to: https://fedoraproject.org/wiki/Fixing_features :-) 18:38:58 <abadger1999> hint hint, nudge nudge 18:39:15 <pjones> abadger1999: uh, pretty sure the point notting was making was that we _don't_ want to play that game. 18:39:15 <t8m> if there were serious API changes needing patching ... 18:39:19 <nirik> well, it's rebuilding a bunch of packages... some of them need porting/fixing each time IIRC. 18:39:32 <ajax> look. 18:39:35 <rbergeron> ajax: /me looks up 18:39:41 <ajax> we're going to war with the feature process we've got, not the feature proces we want. 18:39:46 <ajax> (to abuse a metaphor) 18:39:49 <nirik> right. 18:39:52 <abadger1999> ajax: +1 18:39:55 <rbergeron> ajax: WAR 18:39:55 <t8m> :) 18:39:59 <ajax> let's not decide whether this ought or oughtn't be a feature 18:40:06 <pjones> right. and what we're saying is: go ahead, but drop the feature. 18:40:11 <rbergeron> ajax: I'm concatenating it all into blog post literally atm. 18:40:15 <sgallagh> ajax: Isn't that the whole point of this? 18:40:21 <ajax> let's decide whether, with the feature process we have, this is one. 18:40:23 <rbergeron> and feel free to add to the wiki page if you want. 18:40:37 <ajax> sgallagh: well, no. 18:40:50 <sgallagh> ajax: Given http://fedoraproject.org/wiki/Features/Policy/Definitions I vote +1 to including it as a Feature 18:40:53 <rbergeron> ajax: but any "feature process changes" would go into shift next cycle, not mid-this-cycle, that's just too much to throw on people to deal with. 18:41:00 * nirik is +1 for the feature. If we wish to change the feature process, we should, but not right now. 18:41:01 <ajax> rbergeron: indeed. 18:41:18 <pjones> the feature process we've got, at its core, is about announcing things to end users. do we need to announce that we're shipping a recent version of boost? 18:41:25 <t8m> why not just politely ask them whether they need a Feature for this but if they insist then approve it? 18:41:34 <nirik> pjones: we have thought so for the past N releases. ;) 18:41:39 <notting> t8m: +1 18:41:42 <ajax> pjones: if we announce new perl, why not new boost? both are just developer data points. 18:42:09 <pjones> ajax: fair point, but... 18:42:09 * cwickert thinks that boost qualifies as a feature, although all the boost upgrades become a little boring ;) 18:42:12 <abadger1999> pjones: That's only one of the purposes of the Feature process. Which is one of the problems with the feature process listed on the Fixing_features page. 18:42:13 <t8m> ajax, fair point 18:42:32 <pjones> abadger1999: I'm well aware. 18:42:59 <notting> # repoquery -q --whatrequires boost | wc -l 18:42:59 <notting> 7 18:43:04 <notting> # repoquery -q --whatrequires perl | wc -l 18:43:04 <notting> 2801 18:43:10 <notting> ajax: ^^^ that's why. 18:43:18 <t8m> yep :) 18:43:22 <sgallagh> heh 18:43:25 <ajax> notting: i don't think that's sufficiently transitive 18:43:59 <ajax> given that the 'boost' package contains no files 18:44:01 <notting> in any case, i'm +1 to them doing the work 18:44:04 <ajax> it's intensely subpackaged 18:44:05 <pjones> ajax: tbh I think the reasons perl got approved almost, uh, 20 minutes ago and we're having this conversation about boost is a) perl seems somewhat more important and b) perl came first in our discussion and there's only so much people like to talk about features. 18:44:32 <ajax> pjones: reaching the end of that rope myself 18:44:43 <notting> ajax: ok. 377. still an order of magnitude. 18:44:47 <pjones> which is to say if they'd be in the opposite order, we might be having the same discussion about whether shipping a new perl is worthy. 18:45:15 <pjones> (and we might come to a different conclusion because perl is, in fact, more important.) 18:45:25 <ajax> so just so i'm counting votes accurately: Proposal: feature is accepted for inclusion in F16 18:45:30 <ajax> (i'm +1) 18:45:33 <sgallagh> +1 18:45:39 <mjg59> I guess +1 18:45:44 <pjones> +1 to the work anyway. 18:45:48 <cwickert> +1 18:45:52 <notting> +1, jfdi. 18:45:53 <nirik> +1 (but yes, lets revisit the feature process soon. ;) 18:45:57 <t8m> +1 18:46:00 <ajax> #agreed feature is approved 18:46:12 <ajax> #agreed revisit the feature process, please, please, please. 18:46:22 <ajax> next. 18:46:29 <ajax> #topic Orphaned package ownership claiming clarification 18:46:30 <ajax> #531 Orphaned package ownership claiming clarification 18:46:30 <ajax> .fesco 531 18:46:31 <zodbot> ajax: #531 (Orphaned package ownership claiming clarification) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/531 18:46:36 <nirik> oh yeah... 18:46:43 <nirik> this was still in meeting items. 18:46:43 <pjones> this does seem inconsistent. 18:46:52 * nirik looks to see what state it was in. 18:47:24 <nirik> I dropped the ball here and never filed any further ticket. 18:47:39 <nirik> do we want to revisit this? and confirm what we would like to do here? 18:47:42 <pjones> okay, so that's where we stand. 18:47:50 <pjones> I'm a little unclear from the ticket what was actually decided. 18:48:04 <ajax> i don't think anything was decided. 18:48:09 <pjones> It says "FESCo would like to setup a script that auto blocks and retires packages after 3 months." 18:48:16 <pjones> but... after 3 months of what exactly? 18:48:19 <t8m> I have no problem with the proposal in the Solution Overview 18:48:29 <ajax> pjones: being orphaned? 18:48:43 <nirik> yeah, being orphaned. 18:48:54 <pjones> ajax: okay, that's fine. 18:49:14 <nirik> so, they move from orphaned (anyone can take them) to depreciated (needs an admin to move them back to orphan and they can check for a review) 18:49:33 <notting> also, blocked means that they immediately fall out of rawhide, deps break, etc. 18:49:34 <pjones> yeah. 18:49:55 <nirik> so, not sure how this would fit into the per cycle orphaning... 18:49:56 <pjones> that should mean we're also /removing/ the re-review requirement on freshly orphaned packages. 18:49:58 <sgallagh> I've added a comment to the ticket as well. I don't like having packages arbitrarily retired if they haven't been modified 18:50:07 <nirik> or it would get rid of having to do that? 18:50:09 <pjones> (which it doesn't say) 18:50:30 * cwickert needs to leave 18:50:45 <pjones> nirik: it'd mean that things that are per-cycle orphaned magically become depreciated halfway through the cycle. 18:50:51 <nirik> pjones: there should not be one... only for orphans > 3 months old. 18:50:58 <pjones> right. 18:51:03 <ajax> man i hate that "d" word. 18:51:19 <nirik> pjones: right. or right before release. ;) 18:51:26 <nirik> or anytime really. 18:51:56 <sgallagh> This doesn't even begin to broach the subject of dependent packages. 18:52:30 <pjones> sgallagh: no, but presumably people with dependent packages have some incentive to help keep the packages in question maintained. 18:52:38 <pjones> so *shrug* 18:53:02 <ajax> nirik: so what do we want to do here? 18:53:07 <nirik> I guess the reason for the ticket is that it's currently a manual process to determine if you need a re-review of something... 18:53:23 <nirik> and we were trying to come up with an automated way to handle that. 18:53:36 <sgallagh> nirik: I'm not sure it shouldn't be a policy to have all packages re-reviewed every three years or something. 18:53:46 <t8m> we are also changing the rule slightly 18:53:47 <sgallagh> Plenty of non-orphaned packages get way out of compliance over time 18:53:51 <nirik> sgallagh: in the ideal world, sure. 18:53:58 <t8m> not-modified -> orphaned 18:54:01 <nirik> sadly our new package queue continues to grow. 18:54:02 <fenrus02> why 3 years? seems a mighty long time for a 6mo release cycle 18:54:23 <t8m> sgallagh, there is no way to accomplish that 18:54:29 <sgallagh> fenrus02: Because we have thousands of packages, and nobody wants to do NEW package reviews, let alone re-reviewing old ones 18:54:32 <ajax> let's assume "3 years" is simply an arbitrary number. 18:54:40 <pjones> sgallagh: not saying I disagree, but somewhat off topic. 18:54:46 <sgallagh> fair enough 18:55:10 <fenrus02> sgallagh, point. 18:55:21 <notting> so, this is merely 'orphaned packages are retired from rawhide after three months of being orphaned'? 18:55:23 * nirik isn't sure what the answer is here... the automated 3month thing has downsides now that I think about it. 18:55:24 <notting> sure, i can be +1 to that 18:55:37 <pjones> sgallagh: which I guess means: you should think up a well reasoned policy proposal and stick it on the trac to get discussed ;) 18:55:51 <sgallagh> pjones: I will think on it 18:55:54 <pjones> notting: yes, that seems to be it. and I'm also +1 to that. 18:56:07 <ajax> nirik: what downsides are you thinking of? 18:56:14 <notting> does this replace the once-per-cycle orphan removal? 18:56:26 <nirik> well, I'm +1 too for rawhide, but that doesn't help us with other branches does it? 18:56:37 <pjones> I don't think it does - I think it just moves stuff into that bucket. So we need to be careful about the timing of these two things. 18:56:47 <pjones> maybe move things to being orphans right /after/ the orphan removal. 18:56:47 <t8m> notting, + requiring the re-review not based on whether the package was not modified 18:57:25 <nirik> well, the per cycle thing is operating on branched? or rawhide? is that before branching? 18:57:31 <pjones> nirik: I'm not sure you can really apply this to non-rawhide. We do try to discourage updates, after all. 18:57:51 <notting> nirik: branched if there is a branch. it's supposed to be done pre-branch, but we're not always that diligent 18:58:22 <nirik> if it's pre-branch then it could replace that. 18:58:28 <abadger1999> Well... orphan removal's idea is to keep things from going into Fedora(next) that provenpackagers need to fix because the maintainer has gone missing. 18:58:41 <fenrus02> nirik, why bother dropping a package for a release branch? leave it orphaned or it's a nightmare. 18:59:09 <pjones> yeah, I think the dropping really has to be branched/unbranched rawhide, not release branches. 18:59:11 <nirik> well, I guess you would get orphans less than 3 months old in branched. Instead of none. 18:59:12 <abadger1999> So if the proposal is also making it easier to unblock/deprecate a package; the important timing is the once-per-release orphan=>deprecation vs final freeze. 18:59:29 <notting> and as long as we have a script to do it, i don't think it even needs to be automated as much as scheduled 19:00:37 <fenrus02> is there an autoqa script that can check deps, by using orphans as 'missing' ? (for reporting, not for actual builds) 19:00:54 <nirik> no idea off hand. 19:00:58 <notting> fenrus02: there's a orphan script in the releng git repo that essentially does that 19:01:12 <fenrus02> notting, could that be used routinely on rawhide ? 19:01:37 <notting> fenrus02: sure. would require some cleanup 19:01:56 <notting> (has hardcoded koji stuff in the script, etc.) 19:02:08 <nirik> so, I guess I am +1 to automating it if possible in rawhide. and keep doing per cycle to move all orphans at that time so they don't go into a branched. Then we change the guideline to say "if it's an orphan, feel free to revivie it, if it's depreciated, it needs a re-review" 19:02:31 <notting> nirik: i especially like that last sentence - clarity is good 19:02:32 <fenrus02> sounds like that report might stir some interest - "i need package foo, bar, and baz for mine. two of my deps were just orphaned. I have 3mo to find an owner." or something to that effect. 19:02:36 <nirik> so, some things might move to depreciated fast, others could take 3 months. 19:03:00 <nirik> ie, someone orphans something right before the per cycle thing. 19:03:07 <nirik> or someone does it right after that. 19:03:11 <ajax> sounds sane 19:03:37 <nirik> or hum... just drop the automated and do per cycle. 19:03:59 <nirik> that would move it to a max of 6 months, or a min of a day or whatever, which is kinda variable. 19:04:56 <nirik> or perhaps this all needs more discussion? 19:04:58 <ajax> i have another meeting i should get to in the next 5 to 10 minutes 19:05:01 <nirik> is this thing on? 19:05:02 <nirik> :) 19:05:08 <ajax> so if we can wrap up, that'd be pleasant 19:05:20 <ajax> nirik: notes in the ticket, revisit next week? 19:05:28 <nirik> sure. 19:05:32 <mjg59> Sounds sane 19:05:34 * abadger1999 has two things for open floor, neither of which needs to be discussed to death this week. 19:05:38 <sgallagh> ajax: I have two issues to raise during Open Floor, unfortunately 19:05:51 <ajax> #action nirik to write up proposal in the ticket 19:06:04 <ajax> well then i may not be around for them 19:06:12 <ajax> but we'll see 19:06:15 <ajax> first! 19:06:19 <ajax> #topic Next week's chair 19:06:34 <ajax> hot potato time. who wants it? 19:06:51 <sgallagh> I'll get my turn over with next week :) 19:06:52 <mjg59> I can 19:07:00 <mjg59> Actually, I can't 19:07:06 <ajax> well then sgallagh wins 19:07:07 <mjg59> I won't be around next Monday 19:07:24 <ajax> #action sgallagh to run next week's meeting 19:07:35 <nirik> sgallagh: I wrote up a howto/sop. Hopefully it makes sense. If not, let me know and we can adjust it. 19:07:50 <sgallagh> nirik: thanks 19:08:02 <t8m> nirik, where's the howto? 19:08:04 <ajax> #topic open floor 19:08:13 <ajax> http://fedoraproject.org/wiki/FESCo_meeting_process 19:08:18 <ajax> sgallagh: you first i guess 19:08:22 <nirik> yeah, that ^ 19:08:57 <sgallagh> 1) Hopefully short: What is our official plan RE: Firefox, now that they're declaring EOL faster? 19:09:14 <pjones> when in wonder or in doubt... 19:09:19 <notting> 'whatever caillon decides to do' wfm. 19:09:21 <notting> is that cheating? 19:09:31 <sgallagh> 2) simo wanted to raise a concern about systemd with non-standard process start order 19:09:33 <pjones> notting: wfm 19:09:40 <ajax> firefox's new version numbers are basically just eliminating minors 19:09:43 <ajax> ff5 is ff4.1 19:09:44 <simo> sgallagh, ah thanks for the heads up 19:09:55 <pjones> what's the issue? 19:09:59 <t8m> notting, wfm as well :] 19:10:11 <simo> yeah I would like to know if there will be guidelines on how to deal with systemd for services that start other services 19:10:20 <fenrus02> pjones, users are asking for ff5 in el5,el6,f14,f15 19:10:29 <sgallagh> Yes, but what about F14, which still has Firefox 3 19:10:30 <pjones> fenrus02: I was asking about the other thing. 19:10:41 <simo> FreeIPA for example has a core of servies that are always started but most of them are started only after reading the list of services to start from LDAP 19:10:43 <notting> fenrus02: el5/el6 is covered by the guidelines. (i.e., no.) otherwise, up to maintainers 19:10:45 <fenrus02> pjones, my bad 19:10:51 <pjones> simo: in general we don't create guidelines unless there's a clear need. 19:11:00 <sgallagh> pjones: I think that qualifies as a clear need 19:11:17 <notting> simo: are you talking in terms of systemd units or sysv init scripts? 19:11:21 <nirik> FYI, my understanding is that FF5 is planned for f15+ (I don't know if it will need an exception from us based on the stable updates policy or not). 19:11:29 <pjones> sgallagh: I'm not seeing how, but that's probably an indicator that this is the sort of thing we need a ticket on so we can be prepared ahead of time. 19:11:31 <simo> systemd seem to not cope well with these situations, esp. wrt ordering, which they turned from a simple "start-this-before-that" approach to actual dependencies so that a service will not be started unless systemd has seen a "dependency" been started earlier 19:11:44 <fenrus02> notting, i see. firefox is 'gecko-maint' so i've no idea who to ask there. 19:11:58 <simo> notting, we are still using sysv scripts, but if I understand correctly there is a push to convert eveything to systemd units 19:12:33 <simo> pjones, one example is bind 19:12:36 <ajax> simo: i suspect, once you do convert to systemd units, that you'll have given systemd enough information to do the right thing 19:12:53 <notting> simo: right, but it might be useful to see if systemd can be cajoled to handle ds/cs/ipa's unusual usage 19:12:57 <pjones> ajax: yeah, I suspect that as well. 19:12:59 <simo> ajax, how ? the information is in ldap, not in files 19:13:23 <simo> notting, I am asking for guidelines on how to do that 19:13:26 <pjones> simo: but the stuff in ldap necessarily is after the first thing, so why would systemd start it earlier? 19:13:42 <simo> pjones, for example normally bind is started very early 19:13:45 <notting> simo: how to have systemd cope with the sysv script? would be patching 19:13:51 <pjones> so what you actually want is a howto, not "guidelines" 19:13:58 <notting> simo: how to do the systemd units? would take more investigation 19:14:01 <pjones> or, you know, patches. 19:14:13 <simo> but in a freeipa setup it has to be started after ldap as it stores data in there 19:14:44 <ajax> sounds like you should talk to lennart 19:15:02 <ajax> it's a worthwhile subject, but i don't think it's something we have an answer for immediately 19:15:02 <simo> I did earlier, he wasn't really listening from that ear 19:15:04 <notting> (this has happened in the past, it got loud) 19:15:12 <t8m> well then the freeipa setup script would have to create modified unit files probably? 19:15:37 <simo> t8m, let me say it again, the order is written in ldap, it is not stored in files 19:15:47 <pjones> simo: so? 19:15:49 <notting> sgallagh: simo: i would think that this is not something we can solve in this meeting today 19:15:49 <simo> t8m, it can be changed by the management framework at any time 19:15:58 <pjones> you're not actually stating a problem so far as I can see. 19:16:01 <simo> pjones, so systemd has no way to see it before ldap is started 19:16:12 <ajax> you can add and remove units at runtime 19:16:19 <simo> notting, ok, just saying there is a problem here 19:16:22 <sgallagh> notting: I tend to agree, but since it was falling on deaf ears in the systemd community, I suggested escalating it to FESCo 19:16:26 <t8m> simo, hmm then this is really out of systemd :} perhaps you could just call the systemctl from the first startup script? 19:16:32 <simo> ajax, if the guidelines suggest that that is ok to do I will do it 19:16:37 <pjones> yeah, so just don't inject a systemd unit for the things you don't want started until after you check with ldap 19:16:46 <pjones> simo: of course it's okay. it's part of the design on purpose. 19:16:46 <simo> ajax, I am asking for guidance on how fedora wants to handle these situations 19:16:55 <ajax> simo: in some sense, the thing that makes it work can't ever be wrong. 19:16:56 <t8m> yes, this seems more for a mailing list discussion 19:17:13 <sgallagh> ajax: Unless we're dealing with glibc :-P 19:17:55 <simo> ajax, ok 19:18:11 <simo> I'm fine with that 19:18:26 <ajax> simo: i may have missed it, is there an existing thread about this on fedora-devel, or just on the systemd list? 19:19:22 <notting> ajax: there have been threads about parts of the general IPA/systemd issues. they devolved, as threads do. 19:19:32 <ajax> well then. 19:19:32 <simo> ajax, I had private conversations with lennart early on when systemd was messing up sysv script 19:19:53 <simo> ajax, the temporary solution was to prevent systemd to deal with services at all 19:19:53 * nirik thinks the systemd list and/or #systemd would be the place to try and take it... 19:19:55 <pjones> okay, but in general: it is okay to interject systemd units at runtime. that's why the ability exists. 19:20:02 <simo> but now I am requested to change stuff so ... 19:20:24 <simo> pjones, ok that statement was all I was really looking about 19:20:31 <ajax> excellent. 19:20:37 <ajax> abadger1999: you had things? 19:20:39 <abadger1999> 1) I'm looking for a post-mortem on http://fedoraproject.org/wiki/Features/RemoveSETUID to try to add a helpful suggestion to the fixing features page -- basically, this is at 100% and a completed F15 feature but it's very clearly not completed for F15 (still setuid apps and no packaging guidelines) 19:20:41 <simo> whether it will really work is a matter of debugging and bugfxing 19:20:52 <ajax> abadger1999: i can take that on. 19:21:01 <ajax> given i reverted it from X 19:21:01 <abadger1999> ajax: Thanks a bunch. 19:21:07 <ajax> (i have opinions on the matter, you see) 19:21:23 <ajax> #action ajax to postmortem on RemoveSETUID feature 19:21:26 <fenrus02> it does not make sense to use caps for X really 19:21:29 <abadger1999> 2) I'm probably going to add a ticket to discuss whether blocking services that don't have a systemd native unit file for F16 is a good idea but I want to talk to Viking-Ice about it first. 19:21:44 <fenrus02> there are likely a select few other apps that fall into this category as well, but not many 19:21:51 <abadger1999> So this is a heads up to think about it but it'll be next week rather than now. 19:21:54 <pjones> I think we can handle 2 when it does or doesn't happen. 19:22:10 <pjones> Make sure it's in the Plan next week ;) 19:22:11 <notting> i think that's a bad idea personally 19:22:13 <pjones> (or isn't) 19:22:29 <ajax> abadger1999: cool, thanks for the heads up 19:22:37 <ajax> anyone or anything else? 19:23:00 <nirik> thanks for running the meeting this week ajax 19:23:07 <ajax> will close in 30s if not 19:23:26 <kalev> I was slighlty annoyed during F15 cycle when boost landed like 1 day before branching 19:23:46 <kalev> could you ask boost maintainers to land the new boost earlier this cycle? 19:23:51 <ajax> certainly 19:24:17 <ajax> #note dear boost: please land new boost more than 5 minutes before branch 19:24:35 <kalev> thanks! 19:24:36 <ajax> i'll ask when they plan to merge though 19:24:47 <kalev> this is also important, because they don't tend to do rebuilds themselves 19:25:00 <kalev> and it takes time for other maintainers to do rebuilds 19:25:12 <ajax> right, really have to end now, and it sounds like we're wound down 19:25:16 <ajax> #endmeeting - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
