14:59:24 <spot> #startmeeting Fedora Packaging Committee
14:59:24 <zodbot> Meeting started Wed Sep 14 14:59:24 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:28 <tibbs|h> Howdy.
14:59:30 <spot> #meetingname fpc
14:59:30 <zodbot> The meeting name has been set to 'fpc'
14:59:39 <spot> #topic Roll Call
14:59:45 * limburgher here
15:00:07 * abadger1999 here
15:00:23 <spot> rdieter, geppetto: ping
15:00:31 * geppetto is here
15:00:34 <rdieter> here
15:00:47 <spot> okay, thats quorum
15:00:59 <spot> lets go ahead and get started
15:01:22 <spot> #topic t4k_common & liblinebreak - https://fedorahosted.org/fpc/ticket/98
15:01:25 <limburgher> I may be in and out, $_DAYJOB is psycho
15:01:31 <limburgher> So of course we start with mine.
15:01:31 <limburgher> :)
15:01:34 <spot> hehe
15:01:39 <limburgher> I can't vote anyway.
15:01:52 <spot> well, based on upstream's feedback here, my inclination is to grant this exception request
15:02:30 <rdieter> nod, exception +1
15:02:53 <spot> with the usual requirement of adding Provides: bundled(liblinebreak)
15:03:29 <spot> +1 from me
15:03:47 <geppetto> yeh, basically they have the same "name" but it's different code
15:03:49 <geppetto> +1
15:04:09 <geppetto> And they are porting too … so bonus +1 for that ;)
15:04:09 <spot> geppetto: also, they're planning on moving to the later, split out code. :)
15:04:36 <abadger1999> +1 as long as we get a rough estimate of time to add to the ticket (and followup on when the time passes)
15:04:43 <tibbs|h> Seems OK to me.  +1
15:05:05 <tibbs|h> But I note that a google search for t4k is at best useless.
15:05:09 <spot> #action temporary exception approved (+1:5, 0:0, -1:0)
15:05:22 <abadger1999> geppetto: Welll... really we have an old version of the code that no one in the bundling app kept track of to update.
15:06:17 <spot> Okay, onwards.
15:06:26 <spot> #topic Socket Activation in systemd - https://fedorahosted.org/fpc/ticket/103
15:06:55 <spot> FESCo (in #666) confirmed that on-demand socket activated services are permitted
15:06:56 <tibbs|h> Well, fesco met.
15:07:38 <spot> so, we need to adjust the systemd guidelines to reflect that
15:07:55 <tibbs|h> Hmm, I thought the discussion was more nuanced.
15:08:02 <abadger1999> On a related topic -- Viking-Ice asked if we wanted to mention something about xinetd being replaced by socket activation as well.
15:08:17 <tibbs|h> abadger1999: That's going too far.
15:08:21 <spot> ticket 666 says simply "AGREED: socket activated services should be allowed. "
15:08:43 <tibbs|h> abadger1999: Because, basically, it's not generally a replacement.
15:08:51 <spot> i'd rather just focus our efforts at this point on adjusting the guidelines to reflect that on-demand socket activated services are okay
15:08:54 <abadger1999> On a related topic -- Viking-Ice asked if we wanted to mention something about xinetd being replaced by socket activation as well.emd.
15:09:03 <abadger1999> grr..
15:09:17 * abadger1999 must figure out how to disable trackpad scrolling after meeting
15:09:45 <abadger1999> tibbs|h: Apparently, they've ported some set of xinetd activated apps to use systemd instead.
15:10:05 <limburgher> Belated thanks, all!
15:10:11 <abadger1999> tibbs|h: Viking-Ice used the term "All" but I don't know if that's "all in Fedora" or "all in @core" or something else.
15:10:36 <spot> i don't think we're mandating that xinetd enabled programs migrate to systemd
15:11:04 <spot> if the upstream chooses to do that, well, we just package it as we would any upstream sw with a socket and a service
15:11:12 <tibbs|h> OK, I've skimmed the meeting log.
15:11:26 <abadger1999> We should probably find out what Viking-Ice is doing then :-)
15:11:54 <spot> if by "We" you mean, FESCo? ;)
15:11:55 <tibbs|h> What's in 666 is correct; there were dissenters but there were also sufficient +1 votes for it to pass.
15:12:16 <tibbs|h> abadger1999: He's on what could only be usefully termed a crusade.
15:12:43 <tibbs|h> It's actually somewhat damaging, but as long as nobody thinks that they're mandated to pay attention to him, it shouldn't hurt anything in the long run.
15:13:10 <spot> tibbs|h: *nod* What it means for us is that we need to rewrite https://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation to describe the two cases (socket activated but on by default && socket activated and waiting for a request to start)
15:13:16 <tibbs|h> Indeed.
15:13:21 <abadger1999> <nod>
15:13:28 <tibbs|h> Note that I did update that document with the changes approved last week.
15:13:33 <spot> tibbs|h: *nod*
15:13:41 <tibbs|h> And I'm up to working on it again.
15:13:53 * abadger1999 nodding to spot's description of the easy fix here.
15:14:00 <tibbs|h> Well, not quite.
15:14:20 <tibbs|h> Because there's that thing about not having guidance on writing the socket files which I guess we'd actually need to have.
15:14:37 <tibbs|h> Or maybe not; I guess I'm not sure.
15:14:37 <spot> tibbs|h: no, we still just say socket files should come from upstream
15:15:01 <spot> if you have an upstream with a socket and a service, you need to determine whether it should load on demand or by default.
15:15:19 <spot> if you want it on by default, you need to meet the "on by default" rules FESCo set up
15:15:22 <tibbs|h> If they're supposed to come from upstream, why is someone filing a bunch of bugs against packages in Fedora?
15:15:25 <tibbs|h> (rhetorical)
15:15:32 <spot> tibbs|h: socket from upstream, not service
15:15:48 <spot> and the reasoning there is that socket enablement takes more than just a socket file
15:15:58 <spot> the app needs to be recoded in virtually all cases to support it
15:16:04 <tibbs|h> That is untrue.
15:16:12 <spot> that was lennart's opinion on it.
15:16:23 <tibbs|h> Well, it's patently untrue.
15:16:51 <tibbs|h> I mean, systemd will basically do what xinetd does.
15:17:04 * spot isn't taking sides here, if you think you can come up with a set of guidelines on how to write a proper socket file and what to check for in the upstream code to ensure it will work...
15:17:05 <tibbs|h> You don't have to rewrite the daemons.  You don't change them at all.
15:17:37 <geppetto> tibbs|h: I assume you have to change something for a normal daemon though, right?
15:17:48 <tibbs|h> xinetd just runs something and sets stdin/stdout to go through the socket.
15:17:53 <abadger1999> ah... Is this lennart only thinking about unix sockets and ignoring tcp ip sockets?
15:17:56 <tibbs|h> systemd can do the same thing.
15:18:00 <spot> abadger1999: possibly
15:18:06 <tibbs|h> unix sockets, yes, that's a completely different thing.
15:18:21 <geppetto> tibbs|h: So systemd can run one thing per. connection?
15:18:22 <spot> perhaps that clarification detail is worth mentioning
15:18:23 <tibbs|h> But xinetd doesn't do that now; that's into new systemd behavior
15:18:53 <spot> if the socket type is tcp/ip, it should be possible for the packager to write their own socket file, here's how...
15:19:30 <spot> if the socket type is unix (or anything else), it will probably require upstream code changes to the daemon, please open a bug with upstream
15:19:37 <tibbs|h> I think part of the issue is that "socket activation" encompasses various types of behavior, some analogous to what xinetd does and some new to systemd.
15:19:56 <tibbs|h> And that's confusing folks.
15:20:29 <spot> well, tbh, if our stance is "only worry about socket activation if upstream provides you a socket file" does nicely dodge most of it.
15:21:03 <spot> then we just need to document the two use cases
15:21:12 <abadger1999> spot: in the past, though, we've written both initscripts and xinetd config for software we package.
15:21:25 <abadger1999> so we probably don't want to doge too far.
15:21:51 <tibbs|h> There's this whole push for systemd to get those things back to being non-distro-specific.
15:21:54 <spot> okay, so it sounds like this is going to need to involve documenting when you need a socket file, how to write it, and the two deployment cases.
15:21:55 <tibbs|h> Which I can agree with.
15:22:00 * abadger1999 agrees with spot's separation of tcp/ip and unix socket
15:22:29 <spot> lennart is in the office today, so i might be able to get him to draft something
15:22:41 <tibbs|h> That would be excellent.
15:23:04 <spot> let me try that, and if he says no for some reason, we'll look for fpc victims^Wvolunteers
15:23:11 <tibbs|h> Because while I've converted a simple xinetd thing over to systemd socket activation, I don't completely understand why I had to do what I did.
15:24:00 <spot> okay, we'll revisit this next week, hopefully with a draft from lennart
15:24:01 <tibbs|h> The foo.socket file was easy; the foo@.service file, well, I still don't understand why.
15:24:25 <spot> #topic Open Floor
15:24:37 <tibbs|h> I noticed we have some... old tickets sitting around.
15:24:40 <spot> nirik: please have ajax update the PIE draft.
15:24:55 <nirik> oh yeah, will bug him again. ;(
15:25:01 <spot> this is starting to sound like a broken record. :(
15:25:20 <spot> tibbs|h: such as?
15:25:22 <nirik> yeah. I should perhaps just do it.
15:25:26 <tibbs|h> Say, 27.
15:25:40 <tibbs|h> https://fedorahosted.org/fpc/ticket/27
15:25:41 <spot> yeah...
15:25:56 <tibbs|h> I mean, nearly a year, no response to the last pingg in February.
15:26:03 <spot> didn't we decide that js bundling was okay
15:26:20 <tibbs|h> that's a javascript interpreter, not javascript code.
15:26:32 <tibbs|h> libjs.
15:26:45 <spot> oh.
15:26:53 <tibbs|h> It's just one of those things that's probably never going to get an answer.
15:27:01 <spot> well, i don't see any reason there as to why they shouldn't just patch to use the system js
15:27:13 <limburgher> No answer==no justification, I'd say.
15:27:34 <tibbs|h> Also, the review request is closed wontfix.
15:27:44 <tibbs|h> So the ticket is just pointless.
15:27:51 <spot> I propose that we deny the exception request, and recommend that they patch to use the system js, and only if that is determined to be impractical/impossible, reopen.
15:28:09 <tibbs|h> I was just wondering how long we plan to keep these things open without getting any response.
15:28:32 <spot> probably need to do a pass through them and at least poke all the zombie ones to see if we can get a response.
15:29:08 <spot> if anyone is interested, this is an "EASYTASK"
15:29:36 <spot> bueller? anyone?
15:29:52 * abadger1999 can't commit right now but if it doesn't get done, will help out.
15:29:57 * spot will bribe you with cake (the cake is a lie)
15:30:01 <tibbs|h> I poked the hornets nest so I guess some of that is on me.
15:30:02 <abadger1999> hehe
15:30:26 <spot> can we get a quick vote on denying 27?
15:30:31 <limburgher> +1
15:30:34 <abadger1999> +1 to deny
15:30:37 <spot> +1
15:30:44 <tibbs|h> +1 assuming there's still any point.
15:31:01 <spot> tibbs|h: i want to do it in case someone else revives the packaging effort
15:31:02 <geppetto> +1
15:31:15 <tibbs|h> Sounds good.
15:31:23 <spot> racor, rdieter, if you want to vote for the record, now is the time
15:31:23 <racor> +1
15:32:29 <spot> okay, floor is still open
15:33:15 <spot> i will close it out at 1536 if there is no new items
15:34:05 <tibbs|h> Nothing from me.
15:34:22 <limburgher> nada.
15:36:05 <spot> okay, thanks everyone
15:36:07 <spot> #endmeeting