16:02:57 <abadger1999> #startmeeting fpc
16:02:57 <zodbot> Meeting started Thu Jul 11 16:02:57 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:02 <abadger1999> #meetingname fpc
16:03:02 <zodbot> The meeting name has been set to 'fpc'
16:03:06 <abadger1999> #topic Roll Call
16:03:09 <abadger1999> Who all is here?
16:03:10 * geppetto is here
16:03:10 <tibbs|w> Howdy.
16:03:14 * limburgher here
16:03:33 <Rathann> Hi.
16:03:35 <abadger1999> Rathann: You around?
16:03:39 <abadger1999> ah cool :-)
16:03:56 <abadger1999> We have quorum.
16:04:13 <abadger1999> #topic Bundling exception for nodejs-expect-js https://fedorahosted.org/fpc/ticket/297
16:06:37 <tibbs|w> I guess we can't reasonably deny this given the other exceptions we've approved.
16:06:51 <geppetto> yeh
16:06:59 <tibbs|w> Although this one looks like it takes more code than the others.
16:07:56 <geppetto> the answers to the %check question are confusing … it seems like it's "shipped", but that it isn't normally used by other code (apart from in other %check sections).
16:07:57 <limburgher> Yeah, it's a good reflection of my feelings generally on the way js seems to be handled in the dev community.
16:08:35 <geppetto> But I'm not sure if I'm just being optimistic
16:08:58 <tchol> the library in question is part of a test framework
16:09:06 <tchol> that's why it's mostly going to be used in %check
16:10:01 <abadger1999> Yeah, I think I'm +1 to follow with the other things we've granted exceptions to.
16:10:10 <geppetto> yeh, +1
16:10:30 <tibbs|w> +1 I guess.  Given the reworking of the code I'm surprised anyone even noticed.
16:11:18 <limburgher> +1
16:11:35 <abadger1999> Rathann: have a vote for this?
16:13:21 <Rathann> +1
16:14:05 <abadger1999> #info Bundling exception for nodejs-expect-js passes (+1:5, 0:0, -1:0)
16:14:47 <abadger1999> #topic Please deprecate usage of systemd-sysv-convert in the packaging https://fedorahosted.org/fpc/ticket/308
16:15:41 <abadger1999> Not sure about this one.
16:15:45 <tibbs|w> Well, my notes are on record, and I'm going to +1 any proposal which simplifies this.
16:16:13 <geppetto> I'm +1
16:16:24 <abadger1999> on the one hand, I have never really liked systemd-sysv-convert; otoh, it still serves its intended purpose.
16:16:29 <tibbs|w> One issue here is that there isn't an actual draft.
16:16:57 <tibbs|w> I think its real intended purpose has passed, and now the conversion stuff is just cruft.
16:17:22 <abadger1999> well, there's still stuff that should convert but hasn't.
16:17:30 <geppetto> FWIW I don't think asking around on devel is enough, in general, to remove something … but in this case, meh. … worst case people can still get it and run it, just more annoying.
16:17:50 <abadger1999> but yeah, I think the "critical pacakges" in the distro have been taken care of or analyzed as not going to convert.
16:17:57 <tibbs|w> But is it of such system-breaking importance that not providing this hacking conversion stuff is going to harm anyone?
16:18:03 <abadger1999> yeah.
16:18:25 <tibbs|w> In the end you either have to figure out the conversion thing, or just re-enable the services you need.
16:18:35 <limburgher> Lennart's comment was correct, I did misunderstand.  I'm in favor of removal from the guidelines.  What about the work to get it out of specs?
16:18:42 <tibbs|w> One of those is actually the obvious solution.
16:19:19 <abadger1999> limburgher: it shouldn't hurt if it's in the specs as long as they have the recommended error handling I think.
16:19:22 <tibbs|w> From the devel discussion I think Lennart intends to get rid of the package, though of course anyone else could pick it up.
16:19:38 <tibbs|w> So it would probably have to actually be removed from the specfiles.
16:19:45 <limburgher> RIght.
16:19:58 * abadger1999 takes a look at the recommended stuff more closely.
16:21:39 <abadger1999> ah... I wasn't aware that the only thing systemd-sysv shipped was that script :-(
16:22:32 <abadger1999> Welp, I guess removing it from the guideliens is on us -- but we'll need to mention to lennart that he needs to put in a system-wide Change to remove the package.
16:24:07 <limburgher> Now it's only called by a triggerun for the version where the conversion is first done, so for many of these it's a noop, but still good to get it out.
16:28:06 <abadger1999> Here's a draft: https://fedoraproject.org/wiki/User:Toshio/Systemd_Convert_draft
16:31:11 <tibbs|w> +1 to that.
16:31:12 <abadger1999> Proposal: Drop use of systemd-sysv-convert from the guidelines as per: https://fedoraproject.org/wiki/User:Toshio/Systemd_Convert_draft  and ask Lennart to use the Fedora systemwide Changes process to coordinate removing the package itself.
16:31:14 <abadger1999> +1
16:31:16 <geppetto> +1
16:31:27 <limburgher> +1
16:31:59 <abadger1999> Rathann:  You'll make vote number 5 :-)
16:32:11 <Rathann> yes
16:32:12 <Rathann> +1
16:33:18 <abadger1999> #info Drop use of systemd-sysv-convert from the guidelines Approved (+1:5, 0:0, -1:0)
16:34:02 <abadger1999> #topic Request review of httpd-itk https://fedorahosted.org/fpc/ticket/310
16:34:16 <tibbs|w> Oh, joy.
16:34:27 <abadger1999> This started off in fesco if you guys followed that strange ticket.
16:35:19 <abadger1999> It's come to us because httpd-itk is building an apache module... but it needs to have some features of apache that are not yet released (or even committed to an upstream release tree).  So the package is bundling apache itself.
16:36:11 <limburgher> My gut reaction is . . .why?
16:36:41 <tibbs|w> Well, my understanding is that it wasn't always doing that.
16:36:58 <tibbs|w> But then apache 2.4 came out, and itk wouldn't work with it without patching.
16:37:22 <limburgher> It looks like, from the first changelog entry, that it may actually have been. . .
16:38:04 <limburgher> Yeah, it was.
16:38:57 <Rathann> not sure I understand correctly, but why is httpd-itk version 2.2.x expected to work with modules from httpd version 2.4.x
16:39:42 <tibbs|w> Basically fesco has already gone over this, but I'm not sure if they just punted to us or if they only want is to investigate the bundling issue.
16:39:59 <tibbs|w> Because I've tried to package something that has exactly the same issue.
16:40:20 * geppetto reads lots of history …
16:40:23 <limburgher> Rathann:  I wouldn't expect it to.
16:40:31 * limburgher also reading FESCO ticket.
16:40:45 <Rathann> looks like f18+ has httpd 2.4.x
16:40:52 <Rathann> not sure why httpd-itk didn't follow
16:40:55 <geppetto> So with the bundling httpd-itk still runs as a module under httpd, right?
16:41:01 <abadger1999> tibbs|w: The fesco ticket was "Please force teh apache maintainer to carry these patches that we hope are going to be released in upstream apache sometime in the future".
16:41:13 <geppetto> Are there any new/weird deps. there due to the bundling of a slightly different version of httpd?
16:41:14 <tibbs|w> Well, yeah, that was a non-starter.
16:41:21 <abadger1999> We (fesco) said no to that :-)
16:41:35 <limburgher> No kidding.
16:41:35 <tibbs|w> I'm really concerned about security issues here.
16:41:48 <abadger1999> the alternative proposed by the apache maintainers was for httpd-itk to continue bundling apache as it had been for a while.
16:41:49 <limburgher> I'm really concerned about *many* issues.
16:41:50 <tibbs|w> And that's one of our main reasons for not bundling, so...
16:43:09 <abadger1999> <nod>
16:44:00 <limburgher> Honestly this smells like out-of-tree kernel modules to me.
16:44:18 <tibbs|w> But on the other hand, given that the package obviously shouldn't be allowed to hold back updates to apache, and that forcing httpd to carry patches would be hilarious, what other option is there?
16:44:39 <tibbs|w> I don't think anyone would ask for banning of out of tree apache modules, though.
16:44:43 <limburgher> Would we allow someone to bundle the kernel so they could build it with an acceptibly-licensed out of tree module?  I doubt it.
16:45:00 <tibbs|w> Just that the ones that are there kind of need to actually work with the apache we currently have.
16:45:14 <limburgher> tibbs|w: no, not if they work with our packaged httpd.
16:45:20 <limburgher> Yes.
16:45:23 <geppetto> I'm confused … how did this workign initially, presumably our httpd never included the APIs they needed, so how did it work before?
16:45:35 <abadger1999> I think the precedent is if a package depends on unreleased features of other packages, that package can't be in Fedora until the other package provides the necessary features.
16:45:41 <limburgher> geppetto:  It's bundled httpd from the start.
16:45:48 <geppetto> ahh
16:46:26 <geppetto> Yeh, my gut reaction then is -1 … stick it somewhere not in Fedora until httpd has the APIs you need.
16:47:33 <tibbs|w> But the problem here is that it's already in Fedora.
16:47:47 * Rathann looks at the original review ticket
16:47:50 <Rathann> https://bugzilla.redhat.com/show_bug.cgi?id=598860
16:47:56 <tibbs|w> And "httpd has the APIs you need" changes back and forth over time.
16:48:13 <limburgher> Right.  So what do we do, recommend that it stay broken until it's released, or that it be removed?
16:49:03 <abadger1999> Proposal:  Deny request to bundle apache.  The potential security risk of bundling apache is high.  Unless the maintainer would like to add more information that may change our mind, we'll ask fesco to block the package until apache provides the APIs needed for this package to work without bundling.
16:49:16 <abadger1999> and then give the maintainer a week to try to convince us otherwise.
16:49:21 <geppetto> tibbs: You mean newer updates to httpd-tik depend on even newer APIs?
16:49:34 <geppetto> tibbs: That is fairly easy => You can't update.
16:49:48 <limburgher> This thing is in EPEL, as well.
16:50:04 <tibbs|w> Well, my point is that we obviously can't block apache from updating in a way which would break this package.
16:50:12 <limburgher> tibbs|w:  Right.
16:50:13 <tibbs|w> I guess coordination would be nice, but still.
16:50:13 <Rathann> meh, look at the spec file
16:50:23 <Rathann> personal attacks against httpd maintainer
16:50:27 <tibbs|w> I should never have looked at the review, honestly.
16:50:45 <tibbs|w> It's the five-space-tab guy.
16:50:46 <limburgher> Rathann:  Yeah.
16:51:40 <limburgher> <headdesk>
16:52:08 <limburgher> For lack of better solutions, I'm +1 to abadger1999's proposal.
16:52:44 <limburgher> There's more wrong here, but I'm not sure where to begin, really.
16:53:11 <geppetto> yeh, +1 to abadger1999
16:53:31 <Rathann> +1
16:53:34 <abadger1999> +1
16:53:42 <Rathann> this package should not have passed review
16:53:53 <limburgher> Rathann:  My thoughts exactly.
16:54:03 <tibbs|w> +1, though I kind of empathize.  But, yes, this should have been stopped at the review phase.
16:55:03 <Rathann> I can understand that he wanted to have it in Fedora, but some software just isn't ready to be included in a distro
16:55:11 <Rathann> I wonder how other distros do it
16:55:11 <abadger1999> tibbs|w: <nod> -- I could have seen a time based exception as a possibility but the maintainer hasn't seen fit to add any information that would allow us to go that route.
16:55:54 <limburgher> Reminds me of this one I'm dealing with now:  https://bugzilla.redhat.com/show_bug.cgi?id=982719
16:56:05 <abadger1999> #info httpd-itk's bundling of apache is denied at this time (+1:5, 0:0, -1:0)
16:56:51 <abadger1999> node.js looks too big to finish in the time we have left.
16:57:32 <abadger1999> arch specific headers doesn't have a draft attached so that will take some time as well.
16:57:37 <abadger1999> #topic Open Floor
16:57:45 <Rathann> in debian it seems to be built as a subpackage of apache2
16:57:55 <geppetto> One thing to bring up is that I'll be on holiday for the next two Thursdays
16:58:09 <limburgher> Rathann:  Do they rebuild the whole thing?
16:58:14 <abadger1999> #info geppetto will be unable to attend for the next two weeks
16:58:29 <geppetto> So I won't be here, and won't be able to do the meeting process emails.
16:58:34 <limburgher> geppetto: Enjoy!
16:59:01 <abadger1999> geppetto: Have fun at whatever you're doing :-)
16:59:19 <geppetto> thanks :)
16:59:32 <abadger1999> anyone want to volunteer to do the meeting process emails?
16:59:38 <abadger1999> at least for next week?
16:59:54 <tibbs|w> Are they scripted?  I'm not even sure how they get done.
17:00:09 <geppetto> https://fedoraproject.org/wiki/FPC_meeting_process
17:00:16 <Rathann> limburgher: actually it looks like they integrated the module with the main apache2-bin package
17:00:24 <Rathann> starting from 2.4
17:00:42 <tibbs|w> Oh, cool, I can do that.
17:00:48 <tibbs|w> Let me add some alarms to remind me.
17:00:54 <limburgher> Rathann: Essentially doing what jorton didn't want to do?
17:01:18 <Rathann> I'm looking at the source package to see how they build it
17:01:21 <tibbs|w> Since I'm usually at home on Wednesdays I shouldn't have much problem taking care of the announcements.
17:02:06 <abadger1999> tibbs|w: Thanks!
17:02:25 <abadger1999> #action tibbs|w will handle sending the meeting agenda next week.
17:03:07 <abadger1999> Just an FYI that tchol has been working on some javascript guidelines.  The discussion is currently on the packaging list.
17:03:31 <Rathann> limburgher: they copy the whole server/mpm/prefork directory as server/mpm/itk and apply patches on top of that
17:03:46 <tibbs|w> Yeah, I'm really glad someone decided to take on js again.
17:03:52 <tibbs|w> We need something there badly.
17:04:12 <limburgher> tibbs|w: Yes.
17:04:34 <abadger1999> tchol: From my really quick look this morning it seems like you're adopting a model like Static Libraries which I think is a good compromise... I'll have a look at more of the specifics when I can.
17:04:34 <Rathann> so it looks like itk is a fork of prefork module, just like its website says
17:04:49 <limburgher> Rathann:  Ah.  Seems less than wieldy.
17:05:22 <Rathann> limburgher: the patches on top of prefork are about 30KB
17:06:08 <limburgher> Rathann:  $_DEITY
17:06:27 <Rathann> IMHO Pavel should talk to itk upstream and have them merge with httpd upstream instead of this mess
17:06:51 <Rathann> this reminds me of the compressed folders patch for mutt
17:07:18 <Rathann> it was useful but never merged because it only worked for mbox storage
17:07:48 <tchol> abadger1999: thanks.  one thing I was wondering:  right now the draft says to use bundled(foo) virtual provides to track these, but as you say it's more like static libraries
17:07:55 <limburgher> Yeah, I'd think implementing for maildir would be difficult and somewhat pointless.
17:07:56 <Rathann> so the mutt package maintainer rightly refused my RFE to include it
17:09:07 <tchol> i wonder if we should use a specific virtual provides namespace for this.  I really want to track the included versions somehow so we know when to update, but i'm not sure the best way to do that
17:10:26 <tchol> i thought about using automatic dependency generation so updating a JS library that is included in another one breaks its deps, but that seems like it may be too big a hammer
17:10:37 <abadger1999> tchol: <nod>  I think that's better -- in the draft you talk about using the javascript sources that are installed on the system at buildtime so it seems like either using the static namespace or a new namespace is better than re-using bundled()
17:12:21 <abadger1999> tchol: Hmm... I guess that's probably -- use as big a hammer as people will tolerate... I remember that we had a similar discussion over static libraries when those guidelines were written ages ago.
17:13:07 <abadger1999> tchol: and I think we decided that we could track the version but didn't break end-users if the current version was newer than what was built with.
17:14:10 <abadger1999> Okay,  anything else for the meeting proper?
17:14:23 <abadger1999> I'll close in a minute if not.
17:15:31 <limburgher> Nothing here.
17:16:24 <tchol> abadger1999: i'll change it to use js-static(foo) or something like that
17:16:57 <abadger1999> #endmeeting