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