15:59:55 <spot> #startmeeting Fedora Packaging Committee
15:59:55 <zodbot> Meeting started Wed Nov 24 15:59:55 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:57 <spot> #meetingname fpc
15:59:58 <zodbot> The meeting name has been set to 'fpc'
16:00:28 <spot> #topic Roll Call
16:00:41 * limburgher here
16:00:47 * spot is here
16:00:55 * tibbs|h here
16:02:17 <spot> geppetto, rdieter: ping
16:02:27 <geppetto> pong
16:02:29 <rdieter> oh, pongy pongy
16:02:40 <spot> okay, that's quorum
16:03:04 <spot> and here is racor
16:03:08 <racor> yep
16:03:35 <spot> so, lets get started.
16:03:56 <spot> #topic Systemd Guidelines - https://fedorahosted.org/fpc/ticket/31
16:04:05 <spot> http://fedoraproject.org/wiki/Systemd_Packaging_Draft
16:04:25 <spot> As noted in the ticket, assume that the guidelines start at "Scriptlets"
16:06:20 <spot> One obvious thing that stood out to me was a need to better define the situation when a unit file is enabled by default.
16:06:53 <tibbs|h> "This seems to be the common case" and "This is probably what we want" don't really sound like final draft for consideration material to me.
16:07:00 <hicham> IMHO it shouldn't
16:07:03 <spot> mclasen proposed that Services in the default install should almost always be on by default (because they are needed for a working system, which is why they are in the default install).
16:07:32 <tibbs|h> We never defined any of that for the old initscript guidelines, did we?
16:07:43 <spot> Nope, but it wouldn't hurt to have that clarification here.
16:08:48 <rdieter> though... decisions about default services issue feels a bit out of place in packaging guidelines
16:08:58 <limburgher> Is there a list of the services that are allowed to be on by default?
16:09:06 <spot> limburgher: not that i know of.
16:09:35 <spot> rdieter: we could ask FESCo to make that decision
16:09:39 <limburgher> spot: Hmm.  Wish there was, along with how one gets something on that list.  I assume that's a FESCO decision.
16:09:41 <spot> and simply document it
16:09:55 <limburgher> spot: nods
16:09:56 <rdieter> spot: nod, that should be their call
16:10:04 <geppetto> spot: So I think we've got a problem where we've been very lax with dbus activated services … but I think mclasen is thinking "is installed" and not just "in @base"
16:10:20 <spot> okay, so i'll open a FESCo ticket for that
16:10:22 <tibbs|h> Honestly, I'd just leave the default enabled case out and concentrate on what the vast majority of packages will need to do.
16:11:00 <limburgher> tibbs|h: Agreed.
16:11:03 <geppetto> IMO almost all services should be off by default, but then anaconda can enable some/most/all things it installs.
16:11:15 <geppetto> But, that's probably harder... :(
16:11:26 <spot> okay, we can do that for now, and if FESCo wants the default-on case documented in more detail, we can.
16:13:38 <geppetto> Back to the systemd documentation … given that we will be changing everyone's %post etc. … and that there is a huge number of scriptlets which will be the same … can we just "require" that something provide "system-std-service-post" "system-std-service-postun" etc. … then everyone would just call "system-std-service-post httpd"
16:13:48 <racor> what's systemd's counterpart to chkconfig?
16:14:03 <geppetto> racor: AIUI systemctl does everything
16:14:12 <tibbs|h> I guess systemctl, though chkconfig is supposed to continue to work.
16:14:19 <racor> i am missing any notion the admin enabling/disabling services
16:14:43 <tibbs|h> Why would that be in the packaging guidelines?
16:14:50 <spot> the syntax for that is /bin/systemctl enable nameof.service
16:15:04 <spot> but i agree, it doesn't seem useful in the packaging guidelines
16:15:31 <racor> my feel is, these %post etc. examples lack any concept of conditionally activating services,
16:15:42 <racor> hence the confusion about on/off by default
16:16:18 <spot> well, i believe we plan to assume that "off by default" is appropriate for the guidelines
16:16:24 <tibbs|h> How do our current initscripts guidelines have any concept of conditionally activating services?
16:16:34 <limburgher> Should we state it explicitly?
16:16:57 <spot> limburgher: yes, that would replace the "This seems to be the common case where we install something but want the system administrator to explicitly enable it: "
16:17:13 <racor> tibbs|h: I don't know off head, however this is being handled implicitly through chkconfig etc.
16:17:20 <limburgher> spot: Noted.
16:18:02 <tibbs|h> I don't see any reason we shouldn't just translate what's in the current initscript guidelines to whatever systemd needs and be done with it.
16:18:39 <spot> well, they say: "Note that the default for most network-listening scripts is off. This is done for better security. We have multiple tools that can enable services, including GUIs. "
16:20:32 <racor> tibbs|h: the current scripts add services, but do not enable them (/sbin/chkconfig --add <service>)
16:20:37 <spot> i almost feel like this page just needs to be rewritten to feel more like a replacement for the existing sysvinit guidelines
16:21:00 <racor> I am not sure about what /bin/systemctl enable <service> does.
16:21:02 <spot> the meat is there, it just flows poorly.
16:21:35 <tibbs|h> racor: That turns makes it start at next reboot.
16:21:35 <spot> racor: restarting the systemd daemon updates the list of available services
16:21:38 <abadger1999> Hi.  Sorry I'm late
16:22:03 <spot> racor: so the /bin/systemctl daemon-reload is functionally equivalent to /sbin/chkconfig --add
16:22:14 <racor> spot: OK, I guess I have to read some manuals ...
16:22:43 <tibbs|h> That "common case" block seems to me to be a direct translation of the behavior we currently recommend.
16:23:04 <spot> tibbs|h: yes
16:23:31 <spot> i think that is the block we would keep, and drop the other block (unless FESCo comes up with criteria and wants that other case documented)
16:24:00 <tibbs|h> I'm afraid I don't understand the triggerun bit, though.
16:24:14 <tibbs|h> Is that only for the "default on" case?
16:24:40 <spot> tibbs|h: no, i think that is the case where it is on (either by default or by the admin) and they do an upgrade
16:24:58 <spot> the thought being that they would expect the service to still be on post-upgrade
16:25:14 <tibbs|h> Oh, I guess chkconfig returns true if the service is enabled.
16:25:18 <spot> it uses chkconfig to check to see if it is on and if so, enables it.
16:25:20 <rdieter> right, that's my understanding
16:25:38 * spot dislikes triggers, but i can't think of another good way to do it
16:27:49 <spot> so, do you want me to try to reformat this to be a closer analogue to the existing guidelines, or do we want to consider this (with the default-on case dropped and improved language describing the default case)?
16:27:49 * abadger1999 is with geppetto about turning services on being an anaconda/firstboot thing.
16:28:38 <tibbs|h> I think Lennart plans to start mass-filing bugs for all of this soon.
16:29:10 <tibbs|h> We really need to get guidelines in place.
16:29:27 <spot> i can have this rewritten today, work is slow due to the holiday
16:29:42 <rdieter> spot: reformatting would be better long-term, but could wait for later.  tibbs' is right, getting this in sooner rather than later is a good thing
16:29:52 <geppetto> So I don't mind just doing a straight port, and I'll +1 that … but given that this should be the last time we change "everyone's" post/etc. in a while, it'd be nice to clean a bunch of it up
16:29:57 <tibbs|h> What about the rest of the draft?
16:30:00 * geppetto clarrifies
16:30:37 <abadger1999> tibbs|h: I think he already has :-(
16:30:43 <geppetto> I think we want all mention of sysVinit to go away
16:30:53 <abadger1999> err.. actually, that was a different feature I got a bug for last night.
16:30:54 <tibbs|h> abadger1999: Fail, as expected.
16:31:13 <abadger1999> which I think there's still open questions so.. yeah, still fail.
16:31:32 <rdieter> the tempfs /var/run stuff
16:31:43 <abadger1999> Is anyone here running systemd right now?
16:31:51 <tibbs|h> The thing about this guideline is that a good part of it reads as "here's how to transition from sysvinit stuff".
16:31:52 <limburgher> Not I.
16:31:57 <tibbs|h> abadger1999: I have a test vm.
16:32:17 <abadger1999> tibbs|h: Have you by chance tested that this all works as documented?
16:32:35 <tibbs|h> I haven't.
16:32:50 <tibbs|h> I mean, I'm still coming to grips with the basics.
16:33:07 <tibbs|h> And converting a service over is something I still don't completely understand how to do.
16:33:50 <spot> it would be useful to have a macro equivalent to %{_initddir}
16:34:05 <spot> %{_unitdir} perhaps
16:34:14 <rdieter> worksforme
16:34:27 <rdieter> could be evil and macro'ize more of these snippets too
16:34:29 <geppetto> is there only one dir?
16:34:59 <spot> yes, /lib/systemd/system/
16:35:07 <abadger1999> rdieter: I'd hesitate to macroize things that sysadmins want to do alot.
16:35:08 <tibbs|h> Are we entirely sure that sysadmins won't need to edit unit files?
16:35:35 <abadger1999> Since the scriptlets could also serve as "documentation" for a sysadmin going, wtf did that package do on install?
16:35:47 <rdieter> abadger1999: sure, the only/primary advantage being that if anything needs changing, folks wont need to re-touch all the packaging
16:36:15 <rdieter> abadger1999: but, baby steps first.  get an initial (working) implementation
16:37:08 <abadger1999> When I read this over last week, I go the impression that there were still questions in the top (not part of the actual guideline portion) that weren't answered in the guidelines.
16:37:16 <tibbs|h> Me, too.
16:37:31 <tibbs|h> It does not sound like the author thinks the document is finished.
16:37:47 <abadger1999> But I'm not sure if that's actually true or just that the writing is not well organized to answer those questions.
16:38:29 <abadger1999> I think that I created this page with questions and general areas that needed filling and someone answered them like a FAQ.
16:38:47 <abadger1999> which is why it's disjoint to read and seems overly limited a lot.
16:39:05 <spot> i think i can make this much clearer if i rework it
16:39:23 <abadger1999> I just thought of someone that might be able to help.
16:39:25 <tibbs|h> Yes.
16:39:26 <abadger1999> mattdm.
16:39:48 <tibbs|h> The guidelines should say: where to put the files, what the files look like, what the spec scriptlets should look like.
16:40:05 <abadger1999> <nod>
16:40:07 <abadger1999> k.
16:41:06 <abadger1999> Okay, I'm +1 to rewriting this definitely.
16:41:17 <tibbs|h> Me, too, but we're short on time.
16:41:23 <tibbs|h> Or are we?
16:41:42 <tibbs|h> I mean, we shouldn't feel like we have to race Lennart.
16:42:17 <abadger1999> I don't know.... notting nad lennart's idea for last release was that mass porting of things to systemd would be more like a f16 feature....
16:42:25 <abadger1999> I don't know why that's changed.
16:42:40 <abadger1999> except that someone who is not lennart proposed it as a feature.
16:42:53 <tibbs|h> Oh, I didn't realize it wasn't him.
16:43:16 <spot> okay, let me take a crack at rewriting this
16:43:22 <limburgher> Sounds like a plan.
16:43:22 <spot> i will update the ticket when i'm done
16:44:04 <spot> #action spot will work on a rewrite of this draft for clarity and flow
16:44:48 <spot> #topic Slight clarification on -libs subpackage sentence - https://fedorahosted.org/fpc/ticket/37
16:45:02 <spot> this one should hopefully be quick and non-controversial
16:45:05 <abadger1999> Can we also agree to discuss the revised draft on the list?
16:45:17 <spot> abadger1999: i see no problem with that.
16:45:23 <spot> i'll send an email off when i do
16:45:23 <abadger1999> Excellent.
16:45:25 <tibbs|h> Sure; we should probably open up discussion anyway.
16:45:34 <tibbs|h> +1 to this clarification.
16:45:40 <spot> +1 from me
16:45:44 <rdieter> -libs clarification: +1
16:45:45 <geppetto> +1
16:45:47 * abadger1999 +1'd in the ticket.
16:46:01 <tibbs|h> I see how it could be misread if you were looking to misread it.
16:46:45 <spot> that's +5, racor and limburgher?
16:47:23 <racor> +1
16:48:43 <spot> #action Clarification on -libs subpackage sentence passes (+1:6, 0:0, -1:0)
16:48:55 <limburgher> +1
16:49:07 <spot> #topic Clarifications around bundling - https://fedorahosted.org/fpc/ticket/35
16:49:26 <spot> toshio pointed out that Javascript is not a valid example in item #1 and i agree
16:49:42 <tibbs|h> Agreed.
16:49:48 <spot> so we can either table #1 or replace Javascript with something else equally valid, such as Python
16:50:21 <spot> is there a preference there?
16:50:30 <abadger1999> I'm fine with substituting python for javascript.  Or even noting that javascript is currently an exception but may not be in the future.
16:50:50 <limburgher> Python is good.
16:51:29 <tibbs|h> Honestly I have no preference.
16:51:51 <spot> okay, then i propose that we substitute Python for Javascript in item #1.
16:52:07 <tibbs|h> Are people really confused by what "library" means?
16:52:13 <spot> tibbs|h: yes.
16:52:14 <abadger1999> s/JavaScript/Python/  and add sentence.  At this time, browser-based JavaScript is specifically exempted from this as it runs on a client's machine, not the web server that has the data but this will likely change in the future.
16:52:39 <spot> abadger1999: works for me.
16:52:40 <abadger1999> (and JavaScript that is intended to run on the server is not exempt).
16:53:04 <tibbs|h> Sure, although that sentence has dependent clause confusion.
16:53:08 <abadger1999> as kkofler and others pointed out that there's now JavaScript bindings for local apps to use.
16:53:12 <geppetto> tibbs|h: I assume the worry is that people will willingly mis-read "library" as not pertaining to modules
16:53:29 <abadger1999> how about:
16:53:46 <spot> fwiw, a packager proposed this language as he ran into this confusion.
16:54:05 <abadger1999> " At this timeJavaScript intendedto be served to a web browser is specifically exempted from this but this will likely change in the future"
16:54:11 <spot> (not me, i just drove it forward)
16:54:31 <tibbs|h> abadger1999: +1
16:54:33 <spot> abadger1999: still fine with it
16:54:36 <abadger1999> +1
16:55:04 <limburgher> +1
16:55:11 <spot> +1
16:55:33 <rdieter> +1
16:55:34 <geppetto> +1
16:56:04 <racor> +1
16:56:23 <spot> okay, i count +6 on the revised draft (+1 if tibbs's vote was on the whole as opposed to just the sentence)
16:56:36 <tibbs|h> Yes, +1 to the revision.
16:56:39 <spot> okay.
16:56:58 <spot> #action Changes approved with additional sentence on javascript and example changed from Javascript to Python.
16:57:13 <spot> #action Voting (+1: 7, 0:0, -1:0)
16:58:09 <spot> okay, we have plenty of bundling tickets we can start working through, or we can look at the rpmlint items
16:58:43 <abadger1999> Did any of the bundlers update their tickets after I triaged them?
16:59:04 <spot> #34
16:59:50 <tibbs|h> I read the comment in 34 as being "we're not going to bother doing anything"; did I misinterpret?
17:00:17 <spot> tibbs|h: perhaps more of a "why bother if there is a chance we might not be able to do it in the final release"
17:00:52 <spot> to which i would rebut that it works right now, and to go ahead and do it.
17:01:12 <spot> (in rawhide)
17:01:42 <abadger1999> Hmmm... My f13 box has sqlite-2.7.2
17:01:47 <tibbs|h> Current sqlite in rawhide is 3.7.3, which is also the current upstream version.
17:01:47 <limburgher> spot: agreed
17:01:51 <abadger1999> err 3.7.2
17:01:58 <spot> abadger1999: you may have gotten that from my repo?
17:02:10 <abadger1999> Ah that could be... checking yum info now
17:02:12 <tibbs|h> Yeah, f13 has 3.6.22.
17:02:50 <tibbs|h> Heh, sqlite spec doesn't meet packaging guidelines.  Joy.
17:03:36 <geppetto> Doesn't Panu still own it?
17:03:50 <spot> geppetto: yes, i think so
17:03:58 <tibbs|h> Yes.  Hey, and it passed merge review, too.  Somehow.
17:04:15 <tibbs|h> I shouldn't have looked.
17:04:19 <limburgher> Whoa.  A merge review got finished?  :)
17:04:21 <abadger1999> :-)
17:04:58 <spot> So, on ticket #34
17:05:10 <racor> What prevents us from upgrading sqlite? SONAMEs etc. are identical, so unless upstream screwed it, this should be fairly painless.
17:05:17 <tibbs|h> So, look, unless firefox is going to fork sqlite or they're going to ship unreleased code or something, I don't see what's in rawhide wouldn't satisfy them.
17:05:29 <spot> i propose that we tell xulrunner (gecko-maint) to enable system sqlite in rawhide, and if bundling becomes necessary, to request permission with FPC in the future.
17:05:34 <tibbs|h> sqlite doesn't need to be updated; we're at the current upstream version already.
17:05:45 <tibbs|h> spot: +1
17:05:49 <abadger1999> spot: +1
17:05:57 <spot> +1 to my own proposal. :)
17:05:59 <limburgher> spot: So we just unbundle and move on.  I like.
17:05:59 <rdieter> spot: +1
17:06:07 <limburgher> spot: +1
17:06:12 <abadger1999> spot: and they should add the virtual provides to the earlier releases but they don't have to rebuild specifically for this.
17:06:15 <racor> -1
17:06:41 <spot> racor: i assume you are -1 because you want this to apply beyond rawhide?
17:07:07 <tibbs|h> Either that or somehow racor is for continuing to bundle sqlite, which goes against my expectations.
17:07:09 <racor> correct.
17:07:32 <geppetto> Will saying -1 help that?
17:07:35 <tibbs|h> No.
17:07:39 <spot> i do not believe that we are appropriately empowered to require the sqlite maintainer to update here.
17:07:43 <geppetto> +1 then here too
17:07:49 <racor> tibbs|h: no, I want xulrunner to use the system libs, if possible.
17:07:57 <abadger1999> spot: Well... we could ask the sqlite maintainer to update.
17:08:07 <spot> abadger1999: sure. i would back that.
17:08:29 <racor> abadger1999: ack.
17:08:34 <abadger1999> I'm not certain what all went intothe 2.7.x release though and it is pretty critical to the distro.
17:08:44 <tibbs|h> I don't think FPC has any power to force the sqlite maintainer to update.
17:08:46 <abadger1999> So I'd go with whatever the maintainer decides there.
17:09:04 <geppetto> Yeh … is someone breaks sqlite, that's going to be pretty bad
17:09:05 <tibbs|h> And it would be kind of against other guidelines about not pushing new major versions to distros.
17:09:26 <tibbs|h> So... -1 to even attempting to force this change in release branches.
17:09:28 <geppetto> Do we know how much xulrunner needs the newer sqlite?
17:09:44 <spot> geppetto: i believe they depend on sepcific new functionality
17:09:50 <racor> abadger1999: Correct, but letting xulrunner continuing to use the "other sqlite", means to beta-test the newer sqlite as part of xulrunner.
17:10:38 <abadger1999> Oh, this leads into this ticket that I filed as well: https://fedorahosted.org/fpc/ticket/33
17:10:49 <racor> my proposal would be: have the testers spend 2 weeks with an updated sqlite and watch for what will happen.
17:11:14 * spot notes that quite a few people have been using the updated sqlite without realizing it as a byproduct of using my ff4 repo
17:11:35 <rdieter> abadger1999: +1
17:12:01 <spot> i'll ask the sqlite maintainer to consider whether an update would be acceptable.
17:12:38 <abadger1999> +1 to the modified plan :-)
17:12:51 <spot> Do we also want to tell xulrunner that if an appropriate version of sqlite becomes available as an update for release branches, they should also use it in any future xulrunner updates to those release branches?
17:13:01 <hicham> he refused
17:13:17 <abadger1999> spot: yes, we need to tell them that.
17:13:23 <rdieter> hicham: documented somewhere?
17:13:29 <spot> can i get a quick round of votes on that?
17:13:39 <abadger1999> hicham: He can take that to fesco to ask them to override us but otherwise, he needs to comply.
17:13:39 <limburgher> +1
17:13:58 <tibbs|h> Sorry, which "that" are we voting on?
17:14:13 <hicham> rdieter : stransky asked him before
17:14:21 <spot> "Tell xulrunner that if an appropriate version of sqlite becomes available as an update for release branches, they must also use it in any future xulrunner updates to those release branches."
17:14:25 <geppetto> +1
17:14:26 * rdieter takes that as a no
17:14:30 <rdieter> +1
17:14:47 <tibbs|h> spot: +1
17:14:56 <abadger1999> +1
17:15:31 <spot> +1
17:15:33 <racor> 0, better but no cigar from me
17:15:52 <hicham> what did you decide about rawhide ? ( sorry, I got disconnected )
17:16:14 <spot> Xulrunner (gecko-maint) must enable system sqlite in rawhide, and if bundling becomes necessary, to request permission with FPC in the future.
17:17:40 <spot> #action Voting on rawhide unbundling passes (+1: 6, 0: 0, -1: 1). Voting on handling release branches if necessary sqlite becomes available: (+1: 6, 0: 1, -1: 0)
17:17:55 <spot> lets look at #33, since it ties in so nicely
17:18:04 <spot> #topic New exception reason - https://fedorahosted.org/fpc/ticket/33
17:18:27 <abadger1999> A small but noticable number of libraries are bundling for this reason.
17:18:58 <spot> i'm okay with this as documented in the draft
17:19:40 * rdieter too
17:20:10 <spot> So... +1 from me.
17:20:19 <tibbs|h> Hmm.
17:20:31 <geppetto> abadger1999: I'm not 100% against this, but I think we really want an answer to "why can't the library you are depending on just move to the pre-release … or even just have a patch you send them"
17:20:51 <tibbs|h> Ah, ninja'd.
17:21:05 <abadger1999> Okay.   /me works that in.
17:21:16 <tibbs|h> Yeah, there needs to be a dialog with the maintainer of the bundled library
17:22:36 * spot will give abadger1999 a moment to make the revision
17:23:14 <abadger1999> Okay, hit refresh.
17:23:43 <tibbs|h> +1
17:23:48 <spot> +1
17:23:49 <geppetto> +1
17:24:05 <geppetto> Although … can we bold the word "Note"
17:24:08 <geppetto> :)
17:24:49 <limburgher> +1
17:24:57 <abadger1999> Of course :-)
17:25:08 <spot> thats +4... racor, abadger1999, rdieter ?
17:25:13 <abadger1999> s/Note/'''Note'''/
17:25:14 <rdieter> +1
17:25:18 <racor> +1, geppetto is right. this section needs a stronger emphasize to encourage upstream
17:25:19 <abadger1999> +1
17:25:44 <spot> okay, that's +7
17:26:04 <spot> #action approved with changes made on the fly, (+1:7, 0:0, -1:0)
17:26:45 <spot> So, my inclination is to hold on the other bundled items until clarification comes in
17:26:53 <limburgher> Probably prudent.
17:27:02 <spot> with the possible exception of EMBOSS, if people think they can vote on that now.
17:27:46 <geppetto> do we have a timeline yet, other than "hopefully, soon" :)
17:27:48 <spot> There is a proposal on the ticket (https://fedorahosted.org/fpc/ticket/25) to permit the bundling as long as the library ends up in a subpackage.
17:28:03 <tibbs|h> I can get behind emboss.
17:28:25 <tibbs|h> They've essentially forked.
17:28:26 <geppetto> I can +1 with sub-package … basically treat it as a fork, if need be
17:28:33 <tibbs|h> +1
17:28:43 * spot has to abstain here
17:28:53 <abadger1999> .whoonws EMBOSS
17:28:59 <spot> abadger1999: i do.
17:29:03 <abadger1999> k.
17:29:27 <spot> but for the record, the proposal works for me.
17:29:35 <rdieter> +1
17:29:53 <racor> +1, it's full fork.
17:29:58 <limburgher> +1
17:30:12 <spot> i count +5, abadger1999?
17:30:25 <abadger1999> I put my conditional +1 in the ticket... since an FPC owner maintains the package, just want to make sure we're a good example for others.
17:31:14 <spot> abadger1999: do you want to wait for me to get feedback from the plplot owner before making that a solid +1?
17:31:20 <abadger1999> (the condition being properly document when emboss plans to work on proposing its changes to plplot and the fedora plplot maintainer asking to comment.)
17:31:51 <spot> EMBOSS is unlikely to be able to give us a timeline
17:31:59 <spot> other than "within the next year"
17:32:31 <abadger1999> spot: I can +1 now as long as you come back to us if they say something outrageous like "we were thinking in 2015 or so".
17:32:36 <abadger1999> within the next year is fine.
17:32:38 <spot> abadger1999: i'm fine with that.
17:32:55 <abadger1999> +1
17:33:17 <spot> #action ticket 25 approved exception, fork must go into subpackage (Voting: +1:6, 0:0, -1: 0, spot abstained)
17:33:38 <spot> okay, open floor time
17:33:41 <spot> #topic Open Floor
17:33:44 <tibbs|h> rpmlint
17:33:47 <abadger1999> Ithink this ticket: https://fedorahosted.org/fpc/ticket/15
17:34:29 <abadger1999> for bundling can also be passed... fesco already passed it once and it's what prompted me to write #33.
17:34:39 <spot> abadger1999: i'm okay with that logic.
17:34:50 <abadger1999> If that's okay with people, I'll just ask probinson for the details.
17:34:59 * nirik wonders if FPC has had a chance to look at the /var/run /var/tmp stuff and has any comment on it.
17:35:04 <spot> abadger1999: sounds good, we'll look at it next week.
17:35:07 <abadger1999> (timeline of changes to the bundled lib getting merged upstream)
17:35:11 <spot> nirik: i do not believe we have an open ticket on that.
17:35:33 <abadger1999> nirik: No open ticket... I did comment on the list.
17:35:33 <tibbs|h> It's sort of a fait accompli anyway, isn't it?
17:35:38 <spot> nirik: personally, it seems sensible enough.
17:36:22 <spot> tibbs|h: tickets #32 and #36?
17:36:30 * nirik thinks again we should have a 'mass bug filing SOP'. The first few steps of which are: ask FPC to bless your change idea/make sure it's in guidelines.
17:36:33 <geppetto> I think it'd be nicer if systemd was "cleverer" … but I don't hate it, as is
17:36:33 <abadger1999> tibbs|h: There was no condition from fesco that we would not reevaluate any of there decisions.
17:37:05 <nirik> anyhow, just wanted to note it and if there were any concerns to cause us to put the brakes on it. ;)
17:37:08 <abadger1999> ohh-- fait acompli == ticket15 or /var/run on tmpfs
17:37:13 <tibbs|h> abadger1999: Right.
17:37:33 <abadger1999> nirik: Yeah -- I don't know why we're %ghosting there.
17:37:35 <tibbs|h> I mean, Lennart just announced he was turning it on.  He wasn't requesting input.
17:37:51 <abadger1999> Yep... and then he filed bugs... (I got one last night)
17:38:03 <tibbs|h> We will need to look at the issue, but right now I'm certainly not up to speed.
17:38:31 <tibbs|h> At least we need to revise any guidelines that relate to that stuff.
17:38:36 * nirik got 5 tickets and there has been some confusion on the list.
17:38:51 <tibbs|h> I did ask him directly not to mass file bugs.
17:39:31 <tibbs|h> He obviously ignored me.
17:39:48 <tibbs|h> Anyway, lunch is here, so I have only a couple of minutes.
17:39:52 <geppetto> co-operation is always nice
17:40:06 <abadger1999> nirik: I don't know what we can do... but I don't think we want people acting on the bugs yet.
17:40:11 * geppetto nods … have a good turkey day, for the usians
17:40:14 <tibbs|h> Re: rpmlint, scop offered to let us take it over.
17:40:23 <nirik> abadger1999: then perhaps we should note that to the list at least and file a ticket to look at it further?
17:40:29 <limburgher> I only had 1 bug, and didn't need to change anything.
17:40:30 <nirik> but I suspect maintainers are already changing things for the bugs.
17:40:37 <abadger1999> yeah.  Sounds good.
17:40:39 <spot> tibbs|h: then lets just do it.
17:40:55 <limburgher> nirik: THose that aren't already whacked out on overconsumption. . .
17:40:58 <tibbs|h> I'll sign onto it; does anyone else wish to do so?
17:41:09 <tibbs|h> I'd hope we could get perhaps three maintainers.
17:41:10 <spot> tibbs|h: yeah, i'll also help
17:41:21 <abadger1999> tibbs|h: Would be fine with me although scop has a great relationship with upstream and I don't think any of the rest of us do atm.
17:41:22 <tibbs|h> Maybe someone who knows python a bit better than I do.
17:41:38 <tibbs|h> Really we just need to maintain the fedora-version-specific config files.
17:41:53 * abadger1999 can sign on to but doesn't have a lot of time atm.
17:41:58 <tibbs|h> And maybe downgrade a couple of errors to warnings that people have complained of.
17:42:03 <tibbs|h> Time is my problem as well.
17:42:13 * abadger1999 says that as if that's an unusual state :-(
17:42:15 <tibbs|h> But rpmlint gets less useful with every guideline change we make.
17:42:24 <abadger1999> <nod>
17:42:30 <geppetto> indeed, I don't really want to sign up and not do anything :(
17:43:04 * spot has very little time, but i can at least help here, given that i've written patches for rpmlint in the past.
17:43:13 <tibbs|h> Well, need to go.  Thanks, folks.
17:43:26 <spot> yeah, we should call this a meeting
17:43:28 <spot> thanks everyone
17:43:30 <spot> #endmeeting