16:02:54 <abadger1999> #startmeeting fpc
16:02:54 <zodbot> Meeting started Thu Apr  3 16:02:54 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:01 <abadger1999> #meetingname FPC
16:03:01 <zodbot> The meeting name has been set to 'fpc'
16:03:04 <abadger1999> #topic Roll Call
16:03:06 <abadger1999> Who's here?
16:03:23 <sagitter> sagitter is here
16:03:33 * geppetto is here
16:04:06 <geppetto> sagitter: who are you?:)
16:04:28 * racor is here
16:04:30 <sagitter> I'm me :)
16:04:33 <geppetto> ha
16:04:45 <sagitter> for ticket #391
16:05:10 <geppetto> sagitter: Ahh, icecat … cool
16:05:16 <abadger1999> tibbs|w, spot, SmootherFrOgZ, RemiFedora: FPC ping
16:05:27 <tibbs|w> Oh, back an hour now.
16:05:33 <tibbs|w> Ugh; I can never keep track.
16:05:34 * RemiFedora here
16:06:02 <abadger1999> #chair geppetto racor tibbs|w RemiFedora
16:06:02 <zodbot> Current chairs: RemiFedora abadger1999 geppetto racor tibbs|w
16:06:52 <abadger1999> #topic SCls https://fedorahosted.org/fpc/ticket/339
16:07:09 <abadger1999> Still no activity on the blocking bug but I've been working on touch ups to other parts of hte guideline.
16:07:34 <abadger1999> opened anther (non-blocking) bug this morning: https://bugzilla.redhat.com/show_bug.cgi?id=1084095
16:07:44 <abadger1999> (would let us remove some boilerplate from the guidelines)
16:08:03 <RemiFedora> abadger1999, I already open the same bug....
16:08:22 <abadger1999> RemiFedora: Ah sorry -- none of hte bugzilla subjects jumped out at me when I filed that.
16:08:34 <abadger1999> I can close as a dupe if you tell me the right bug report.
16:08:47 <abadger1999> I changed the guidelines to place the macros into %{_rpmconfdir}
16:09:15 <abadger1999> But that's also some boilerplate... Could file a bug to have that changed in scl-utils as well but I'm not sure how hard it is.
16:09:26 <RemiFedora> abadger1999, see https://bugzilla.redhat.com/show_bug.cgi?id=1079258
16:11:46 <abadger1999> RemiFedora: Cool.  I'll take care of duping/closing.
16:12:18 <abadger1999> RemiFedora: If you have any influence to ask that the other bug also gets attention, that would be great.
16:12:50 <abadger1999> #topic Go Packaging
16:12:53 <abadger1999> Still nothing.
16:13:24 <abadger1999> I'll try to ping mattdm and see if he can see what's going on.
16:14:03 * abadger1999 skips fox for now
16:14:15 <abadger1999> #topic #405     Downstream versioning of shared libraries. https://fedorahosted.org/fpc/ticket/405
16:16:53 <abadger1999> Okay, After I straightened out how SONAME is used in my head, I'm for the general strategy.
16:17:32 <RemiFedora> trying to add a soname, when not manage by upstream seems a bit risky (when upstream will start to manage it)
16:17:40 <abadger1999> Things I'm unsure about: "The n should be the number of downstream release. Do not forget to add the SONAME field (see below) to the library. " <= we don't want to bump n everytime upstream makes a new release so perhaps the initial "n" shouldn't be the release either.
16:18:05 <RemiFedora> perhaps the -release option (libtool iirc) is simpler
16:18:41 <abadger1999> Probabaly should mention that the goal is to provide an SONAME that has the least possibility of conflicting with upstream if they ever decide to officially provide shared libs.
16:19:27 * geppetto nods … I thought someone was heavily against us doing this, but there isn't a comment to that affect in the ticket
16:19:47 <RemiFedora> (-release is what we use for php embedded library)
16:19:59 <abadger1999> I would like something more for how to run configure/get the linker line into an autotools makefile but it sounds like the reporter doesn't have that information.
16:20:00 <racor> abadger1999: Tying SONAME to Version/Release combos as done in the proposal is a classic beginner's mistake.
16:20:55 <racor> abadger1999: What counts is the ABI. info libtool has a long section about this issue.
16:21:05 <abadger1999> racor: yeah.  He does understand not to tie it after the initial release:"if it detects any incompatibilities, bump the n number"
16:21:30 * geppetto nods
16:21:36 <abadger1999> but it seems misleading to use upstream's version for the initial build.
16:22:42 * SmootherFrOgZ here
16:22:46 <abadger1999> RemiFedora: -release is also possible although not foolproof.  some upstreams end up with libraries that have numbers in their name too.
16:22:50 <abadger1999> #chair SmootherFrOgZ
16:22:50 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto racor tibbs|w
16:23:15 <abadger1999> anyhow... I can fix tmy first two comments.
16:23:42 <abadger1999> I don't the best way to pass in the linker flags to configure/autotools driven builds though.
16:23:53 <abadger1999> Can anyone help me out with that?
16:25:49 <abadger1999> tibbs|w: One question for you -- is there a reason you advise people to use 0.0.n rather than 0.n?
16:25:56 <geppetto> I have a giant thing that I copied from glib a long time ago, when I want to do it
16:26:14 <geppetto> Which sets LT_RELEASE / LT_CURRENT / LT_REVISION
16:26:19 <geppetto> and LT_AGE
16:26:25 <geppetto> and then libtool does it's thing
16:26:30 <tibbs|w> I guess it just seemed less likely to conflict.  As in, it's closer to zero but reserves plenty of still less than 1 space for upstream if they do change their mind.
16:27:31 <tibbs|w> This has only come up a couple of times in reviews that I did, and really the only one I can remember is some network-related library where the package maintainer simply refused to version the library.
16:27:51 <tibbs|w> To be honest I'm not 100% sure why it should be necessary in any case, besides rpmlint complaining about it.
16:28:29 <abadger1999> <nod>
16:28:36 <racor> tibbs|w: I recall this issue had come up in the very early days of Fedora,  but hasn't been a major issue since then.
16:28:48 <tibbs|w> Yes, this was very long ago.
16:29:00 <abadger1999> yeah I remember libnet and vaguely another time as well.
16:30:00 <abadger1999> geppetto: k.  So that was a patch to configure.ac and then re-run the autotools to regenerate the Makefiles?
16:30:30 <racor> tibbs|w: I guess, either upstreams adopted proper SONAME names, or packages are just hacked to using "..0" ignoring any ABI incompatibilities ;)
16:31:03 <tibbs|w> Right, what we lose when we don't do this is dependency-breaking when libraries have ABI changes.
16:32:01 <racor> <nod> I fear we have quite a few such cases.
16:32:23 <tibbs|w> In any case, this guideline only says that the maintainer has to try and get upstream to do the good/right/useful thing.
16:32:43 <tibbs|w> If upstream doesn't, then they have a choice, and if they choose to version the library then it gives them instructions.
16:33:02 <tibbs|w> I'm 100% for that, as long as the instructions are useful.
16:35:07 <abadger1999> Okay -- I've just removed the libtool language.
16:35:12 <abadger1999> How's this look: https://fedoraproject.org/wiki/User:Jstanek/Draft_-_Downstream_.so_name_versioning#SONAME_handling
16:36:23 <abadger1999> If someone comes to us wanting to know how to do this in an autotools build we can research how to do it then.
16:36:29 <abadger1999> Proposal: Approve the revised Downstream .so versioning draft
16:36:52 <abadger1999> +1
16:37:23 <RemiFedora> common pratice is only 1 digit in soname, the proposal is 2 digit...
16:37:41 <abadger1999> RemiFedora: right.  And I think that's part of the heart of the proposal.
16:38:02 <tibbs|w> Because ld only does a simple equality check, I guess ordering with upstream doesn't matter; the only problem is if upstream releases a version that happens to be exactly the same as what Fedora chose, and that's unlikely enough that I can't see us caring.
16:38:05 <RemiFedora> but, this is not explained ;)
16:38:07 <abadger1999> RemiFedora: Since common practice is 1 digit and we do not want to conflict with upstream, we should set it to be something with more than one digit.
16:38:17 <tibbs|w> +1 from me.
16:38:20 <RemiFedora> abadger1999, yes
16:38:38 * abadger1999 adds a note about why two digits after the example
16:38:58 <RemiFedora> +1 with the note about why 2 digits
16:39:10 <racor> Why this sentence: "Keep in mind that altough the SONAME and the filename should be the same,"
16:39:29 <SmootherFrOgZ> +1 with changes
16:39:54 <racor> This simply is not true. To the contrary, it's common practice these are not the same.
16:40:29 <geppetto> racor: how so?
16:41:00 <racor> libXXX.so.3 -> libXXX.so.3.5 ... with SONAME=libXXX.so.3
16:41:29 <abadger1999> Okay, added: "The n should initially be a small integer (for instance, "1"). we use two digits here ("0.n") because the common practice with upstreams is to use only a single digit here. Using multiple digits helps us avoid potential future conflicts. Do not forget to add the SONAME field (see below) to the library. "
16:41:59 <abadger1999> racor: how about if I s/should be/is often/
16:42:00 <geppetto> racor: Ahh, right … I just think of the symlink to the major version to be the filename … my bad
16:42:39 <geppetto> abadger1999: no, it should be something like … the symlink from ldconfig should be the same as the SONAME
16:43:03 <geppetto> abadger1999: And the filename should be the SONAME and an incrementing minor version.
16:47:09 <abadger1999> Okay -- changed that whole sentence.  New one reads: "Keep in mind that although the filename is usually the library's SONAME plus an incrementing minor version there's nothing that intrinsically links these. The dynamic linker uses the SONAME field and disregards the filename. "
16:47:41 <abadger1999> I wasn't sure if I should put the ldconfig symlink information in there... seemed like it might just confuse the issue.
16:49:08 <abadger1999> We're at +4.  racor, geppetto any other changes I can make to get another +1?
16:49:39 <racor> abadger1999: I think it should be mentioned, because setting up the symlink is on of the reasons we are mandating running ldconfig in %post/etc. for packages with shared libs.
16:49:47 <geppetto> +1
16:49:52 <racor> +1
16:53:16 <abadger1999> https://fedoraproject.org/wiki/User:Jstanek/Draft_-_Downstream_.so_name_versioning#SONAME_handling
16:53:22 <abadger1999> Added something about ldconfig.
16:53:31 <abadger1999> racor: let me know if what I wrote was inaccurate :-)
16:53:44 <RemiFedora> abadger1999, "If tjat fails ..."
16:54:03 <abadger1999> #info  the revised Downstream .so versioning draft Approved (+1:6, 0:0, -1:0)
16:54:10 * abadger1999 fixes typo
16:54:49 <abadger1999> The two bundling exceptions needing votes passed in ticket.
16:55:06 <SmootherFrOgZ> sounds good to me.
16:55:23 <racor> abadger1999: It's vague enough, we can refine it should this become an issue. ATM, I am actually pretty surprized we have to discuss this at all. I guess, c-library authors are a dying species ;)
16:55:40 <abadger1999> #topic #411     proposal: migrate license files to %license instead of %doc
16:55:46 <abadger1999> https://fedorahosted.org/fpc/ticket/411
16:57:24 <abadger1999> oops.. I missed icecat -- we can come back to that after htis.
16:57:29 <abadger1999> So we startd voting in ticket.
16:58:21 <abadger1999> This comment has the actual guideline draft: https://fedorahosted.org/fpc/ticket/411#comment:5
16:58:42 <abadger1999> It's a bit messy because there's text sprinkled throughout the wiki to update. (and I probably missed some places)
16:58:43 <geppetto> yeh, this seems like a no brainer +1
16:59:11 <geppetto> as tibbs said, some guidance on which EPELs this applies to would be good
16:59:31 <geppetto> ahh, EPEL-7+
16:59:44 <abadger1999> So far, tibbs|w, abadger1999, geppetto +1  (spot I think is +1... he was positive on the concept in comment:1, before I posted an actual draft).
16:59:56 <SmootherFrOgZ> +1 from me
17:00:58 <abadger1999> RemiFedora, racor: votes?
17:01:05 <racor> -1 - To me this all is redundant to License: and not helpful at all
17:01:22 <RemiFedora> I don't understand how this helps
17:01:46 <abadger1999> RemiFedora: cloud wants to create images using --nodocs
17:01:54 <abadger1999> Currently that would mean that license files are excluded.
17:02:04 <abadger1999> For some licenses, that's a violation of their terms
17:02:06 <RemiFedora> I have tons of package where license is managed and install, with doc, in some "suptream" folder
17:02:13 <racor> abadger1999: They still have rpm's License: tag.
17:02:15 <tibbs|w> So according to Panu's comment, if we require this then we force EPEL packages to be different.
17:02:17 <abadger1999> as the license has to be included when you distribute.
17:03:02 <racor> abadger1999: It's simply insane forcing people to modify all Fedora packages.
17:03:35 <tibbs|w> I don't think we usually force people to modify everything when we pass guidelines.
17:04:12 <abadger1999> tibbs|w: hmm.. that might be true... should we ask panu if there's a recipe to make a compat macro in the specfile that evaluates to either %license or %doc?
17:04:15 <tibbs|w> Though to solve individual legal issues someone might have to go in and change something, but that's no different than anything else we do.
17:04:28 <tibbs|w> abadger1999: Yeah, I don't know if it can be conditionalized.
17:04:58 <tibbs|w> I think the amount of conditional cruft starts to get overwhelming.
17:05:09 <abadger1999> Yeah -- we aren't mandating that packagers change here but the cloud WG is going to allocate provenpackagers from within their ranks to fix packages they care about.
17:05:48 <abadger1999> tibbs|w: yep -- b/c of how %doc works.. I'd have to ask panu if there's a way to make that work.
17:06:06 <abadger1999> Okay, I think we should table this until we hear from panu.
17:06:30 <abadger1999> Making a change that means maintainers would have no choice but to have different spec files between epel and fedora is a big change.
17:07:49 <abadger1999> #topic #391     Exception for bundled libraries in icecat
17:07:54 <abadger1999> https://fedorahosted.org/fpc/ticket/391
17:08:04 <abadger1999> So we have several different things to work on in this ticket.
17:08:12 <abadger1999> sagitter: We're discussing your ticket now.
17:08:13 <racor> abadger1999: I think we should consider to propose banning epel/rhel-conditionals in rpm-specs and educate people to take advantage of git to cope with epel/rhel, instead.
17:09:23 <geppetto> racor: massive -1
17:09:42 <abadger1999> Let's take the four proposed exception criteria from https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation discuss and vote.
17:09:59 <geppetto> racor: It's very often helpful to share specfiles, so mandating we don't removes that and I'm 100% against it.
17:10:08 <abadger1999> Then see where we are and try and work out the details of racor's proposal if we don't have an exception for icecat at that point.
17:10:15 <geppetto> racor: I have no problem with suggesting it, somewhere, if you want.
17:10:35 <abadger1999> First potential new criteria: Active upstream Security Team : https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation#Active_upstream_Security_Team
17:10:44 <geppetto> racor: But esp. being able to do things like rebuild the latest rawhide in EPEL-6 quickly … is often very helpful.
17:10:47 <abadger1999> We talked this one over a lot last week.
17:10:58 <abadger1999> Anyone have something to say about it or should we just vote on it?
17:11:08 <racor> geppetto: there are quite a few package which are almost unreadable because they are carrying tons of historic ballast, while the fedora package would be lean and clean.
17:11:56 <racor> geppetto: git merge can take care of this when importing changes from  rawhide to epel.
17:12:19 <geppetto> abadger1999: did you change it much from last week?
17:12:25 <abadger1999> racor: If you want to propse that we ban that file a ticket and we'll look at it next time... We have a few other tickets to get through that affect Fedora 21 Changes
17:12:29 <racor> abadger1999: I already voted on track
17:12:32 <abadger1999> <nod>
17:12:47 <abadger1999> So if there's no more comments on this one let's just vote
17:13:07 <abadger1999> Proposal: Active upstream Security Team as possible criteria for a bundled library exception
17:13:16 <abadger1999> +1
17:13:24 <abadger1999> racor is -1
17:13:38 <geppetto> abadger1999: Should also mention somewhere that _all_ the versions in Fedora will be covered by the upstream Security team.
17:13:55 <tibbs|w> But not necessarily the same one.
17:14:11 <geppetto> abadger1999: Ie. no point in them having a good security team if they refuse to fix something in the oldest Fedora.
17:14:14 <abadger1999> geppetto: oh Maybe there's a point of confusion.
17:14:26 <abadger1999> We're talking about the project that's bundling some version of hte library.
17:14:42 <abadger1999> so the upstream security team would be covering the version that their project is bundling.
17:14:42 <geppetto> yeh
17:14:58 <geppetto> I mean thte version of the thing they are bundling it in
17:15:06 <abadger1999> ah... hmmm...
17:15:59 <racor> As usual, my time's up. I need to quit
17:16:12 <abadger1999> so I think precedent for "not the latest version from upstream" is that if upstream doesn't support the release in the oldest Fedora either the package maintainer fixes it or the package maintainer upgrades the package b/c security trumps the updates policy.
17:16:23 <geppetto> But … given that all of these are "please point out to us which one might help you, but it isn't a guarantee" … I'm happy to +1
17:17:08 <abadger1999> So I don't think I'd make the demand that in this case upstrream care about the older release unless that's what's necessary to make this pass.
17:18:25 <abadger1999> tibbs|w, RemiFedora, SmootherFrOgZ: votes from you all (or notes that yes, we need to say that upstream cares about the older fedora releases)?
17:18:31 <geppetto> abadger1999: I'm just thinking that users might perceive a difference between "old firefox has a security bug, so you have to get the new firefox which has UI changes/whatever" … and "old firefox is bundling an old libbrokenfoo, so you have to get the new firefox which has UI changes/etc."
17:19:16 <SmootherFrOgZ> +1
17:20:27 <abadger1999> geppetto: <nod>  I don't think users will notice that difference but I'm willing to put it in if it's the difference between passing or not.
17:20:54 <geppetto> Well I already +1'd, so …
17:20:58 <abadger1999> tibbs|w, RemiFedora: ?
17:21:01 <abadger1999> <nod>
17:21:08 <tibbs|w> Sorry, someone in my office.
17:21:11 * RemiFedora is confused
17:21:14 <abadger1999> k
17:21:28 <abadger1999> if worse comes to worse, we'll just record the votes we have in ticket.
17:21:38 <abadger1999> RemiFedora: sure -- what can I do to clarify?
17:21:44 <abadger1999> #chair limburgher
17:21:44 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher racor tibbs|w
17:21:50 <RemiFedora> +1
17:22:13 <abadger1999> limburgher: oh hey -- I didn't notice when you joined
17:23:02 <abadger1999> #info Security team criteria is at (+1:4, 0:0, -1:1)  will go to ticket to see if we can get one more vote.
17:23:17 <abadger1999> Second exception criteria is: https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation#Too_Big_to_Fail
17:23:40 <limburgher> ack.  Joined a long time ago.  Wasn't paying attention.  Sorry.
17:24:23 <limburgher> reading. . .
17:24:43 <limburgher> +1
17:24:48 <abadger1999> #undo
17:24:48 <zodbot> Removing item from minutes: INFO by abadger1999 at 17:23:02 : Security team criteria is at (+1:4, 0:0, -1:1)  will go to ticket to see if we can get one more vote.
17:25:08 <abadger1999> #info Security team criteria Passed (+1:5, 0:0, -1:1)
17:25:37 <abadger1999> So too big to fail is basically that some packages (like firefox) might be too popular for us to want to keep out of the distro.
17:25:54 * geppetto nods … to clear it up … my +1 was for the entire page.
17:26:18 <abadger1999> ah okay.
17:26:25 <abadger1999> anyone else want to +1 for the entire page?
17:26:56 <SmootherFrOgZ> I'm k with the entire page so +1
17:27:06 <limburgher> Sure, since my idea for an amendment stipulating that developers that bundle get tracked down and sprayed with hoses. . .+1
17:27:27 <limburgher> . . .will never happen, is how that was meant to end. . .
17:27:51 * abadger1999 finds the too big to fail a little distasteful but willing to +1 even that.
17:27:58 <abadger1999> +1 entire page.
17:28:16 <abadger1999> we're at +3, -1 for the rest of the page
17:29:01 <abadger1999> Err.. +4, -1
17:29:21 <abadger1999> RemiFedora: Do you want to +1 the rest of hte proposed criteria on the page as well?
17:30:25 <RemiFedora> sorry, phone call
17:30:32 <abadger1999> k
17:30:49 <RemiFedora> +1 for entire page
17:31:31 <abadger1999> #info too Big to fail, too small to care, andforks of packages granted an exception are passed (+1:5, 0:0, -1:1)
17:32:28 <abadger1999> So icecat -- firefox has an active security team and I think we were saying that it's an example of too big to fail.
17:33:12 <limburgher> It had better not eat my 401k.
17:34:07 <abadger1999> Proposal: firefox has a bundling exception since it has an active security team tracking issues in their codebase.  icecat has an exception since it is a fork of firefox that closely tracks firefox's changes.
17:34:11 <abadger1999> +1
17:34:32 <RemiFedora> +1
17:34:36 <SmootherFrOgZ> +1
17:34:43 <geppetto> +1
17:35:11 <geppetto> Where's ralf?
17:35:17 <abadger1999> limburgher: Care to vote?
17:35:30 <tibbs|w> racor quit a while back.
17:35:42 <abadger1999> geppetto: He had to leave... I think he's -1 (does not want an exception for firefox)
17:35:50 <geppetto> I wasn't sure from his comment
17:35:57 <abadger1999> although he was positive for a temporary exception for icecat.
17:36:01 <geppetto> he seemed to be +1 … but wanted it to be temporary
17:36:13 <abadger1999> yeah
17:36:34 <abadger1999> we're at +4.  One more to pass.
17:37:26 <tibbs|w> Sorry, I'm back.
17:37:58 <tibbs|w> I sort of think we've gone a bit far here.  Do we really not care to at least gather plans for unbundling and such?
17:38:28 <abadger1999> tibbs|w: that is a question -- somethings we do grant permanent exceptions for.
17:38:46 <abadger1999> if ew want to grant a temporary exception then we would need to gather plans to unbundle.
17:39:20 * abadger1999 saw this as a permanent exception -- as long as firefox continues to have a security team and icecat continues to follow firefox code changes.
17:39:28 <tibbs|w> Even for the "permanent" ones, we someone should occasionally revisit their status.
17:39:49 <tibbs|w> There still might be a point where stuff in, say, firefox is bundled for no reason at all.
17:40:09 <abadger1999> <nod>
17:40:22 <abadger1999> How do we want to phrase that?
17:40:25 <tibbs|w> I'm pretty sure that's the case now.
17:40:45 <tibbs|w> I don't know; we're bad at enforcement.
17:41:09 <limburgher> +1
17:41:13 <limburgher> Sorry, had to step away.
17:41:18 <tibbs|w> Most of the permanent exceptions we have granted have been for cases where we know things aren't going to get any better.  (Dead upstreams, that kind of thing.)
17:41:30 <abadger1999> <nod>
17:41:51 <tibbs|w> But firefox is big and moves fast and almost certainly bundles too much even though it certainly qualifies for some form of exemption for some of the stuff it bundles.
17:42:06 <tibbs|w> And the icecat folks have at least tried to unbundle what they can.
17:42:12 <abadger1999> <nod>
17:43:10 <abadger1999> So -- we have two more tickets that relate to Fedora Changes that we should at least look at today.
17:43:44 <abadger1999> How about we record that we're in favor of an exception but we're going to talk further about how we want to implement it (temporary?  Just some kind of review?  etc?)
17:44:18 <abadger1999> So no final decision yet but we're headed towards an exception in the not too distant future.
17:44:35 <abadger1999> #topic #412     Please change the packaging guidelines to include packaging policy regarding systemd timer units
17:44:40 <abadger1999> https://fedorahosted.org/fpc/ticket/412
17:45:06 <abadger1999> https://fedoraproject.org/wiki/User:Notting/timer
17:45:25 <abadger1999> I've had to look at this in fesco already and I'm willing to approve it.
17:45:47 <abadger1999> This part: https://fedoraproject.org/wiki/User:Notting/timer#Main_page seems very reasonable.
17:46:13 <abadger1999> This part: https://fedoraproject.org/wiki/User:Notting/timer#Timer_activation is a lot of examples of using timers to add to the systemd packaging guidelines.
17:46:49 <abadger1999> The choices make things more complex than cron jobs but I think it's just documenting what exists too.
17:47:08 <abadger1999> +1
17:47:54 <limburgher> So. . .the guideline looks ok, but I've got a quick Q about the system in general.  Is there a central place to store these, analogous to /etc/cron*, or a users's crontab?  is there a per-user mechanism like cron?
17:48:34 <abadger1999> I believe these only replace the system usage of cron (packages and sysadmins that want things to be run periodically).
17:49:04 <limburgher> Got it.
17:49:05 <limburgher> +1
17:49:33 <abadger1999> I think that the timer units go in the same directory as unit files that replace init script-type services.
17:49:43 <limburgher> I figured that might be the case.
17:50:02 <tibbs|w> Oh, I hadn't looked over Notting's draft.  I really don't understand the objections to providing a draft in the original ticket.
17:50:24 <abadger1999> tibbs|w: I didn't either.  I'm glad that notting stepped up to write something.
17:50:38 <tibbs|w> Yeah, this is good stuff.  +1, though I haven't gone over every inch of it for correctness (because I have little idea of how this actually works at this point).
17:51:08 <tibbs|w> The other issue is that only rawhide systemd supports all of this stuff, as I understand things.
17:51:36 <abadger1999> Yeah.  I think that some of it works in F20 but I wasn't clear on which parts those are.
17:51:59 <limburgher> If so it needs to specify f21+ or whatever.
17:52:04 <abadger1999> We're at +3.  geppetto, RemiFedora, SmootherFrOgZ: votes from any of you?
17:52:18 <abadger1999> Hmm... good point.
17:52:49 <RemiFedora> "Whether a timer unit is enabled by default is controlled by systemd presets, just like any other systemd unit." => does this mean we cannot have a systemd timer enabled by default ?
17:53:02 <geppetto> RemiFedora: atm. yeh
17:53:06 <RemiFedora> so -1*
17:53:29 <geppetto> RemiFedora: I've tried to hack around it for ones I've done … but AFAICS it doesn't work.
17:54:09 <geppetto> And as tibbs said, these all all just dumped in the systemd unit dir.
17:54:12 <RemiFedora> if I drop a file in /etc/cron.d => it is enabled
17:54:15 <abadger1999> I'll look up what fedora release these guidelines apply to and add an admon/note saying when we can use them.
17:54:42 <geppetto> although parts of them do end in .timer
17:55:53 <abadger1999> RemiFedora: So... a couple ways to fix that.. " All packages with timed execution or scheduled tasks which already depend on systemd (for example because they contain service units) MUST use timer units instead of cron jobs, with no dependency on a cron daemon. "
17:55:58 <abadger1999> We can change that into a should
17:56:37 <RemiFedora> yes, it was my second comment, must => hould
17:56:58 <geppetto> abadger1999: So ... AIUI the systemd guys look at cron job thigns as services like everything else, so the fact people have those enabled by default is a bug[
17:57:09 <abadger1999> RemiFedora: or we could specifically say that cron jobs that need to be enabled by the package are okay.
17:57:42 <abadger1999> RemiFedora: although -- for me, I think that cron job starting is similar to what services get started... so it's something that fesco can decide on as part of their: what starts by default.
17:57:55 <geppetto> abadger1999: So if we want to keep that behaviour long term. … I think we need to change their opinion to be that they aren't the same, and so always on should be allowed.
17:57:58 <abadger1999> RemiFedora: and I think they are starting to use systemd presets as part of that.
17:58:21 <abadger1999> geppetto: <nod>
17:59:33 <geppetto> I'd change both MUSTs to SHOULDs, I think
17:59:46 <geppetto> But I'm not sure on the rationale for not adding deps. on systemd
18:00:16 <RemiFedora> MUST NOT => should not
18:00:23 <geppetto> I guess I'm +1 on it … even though it's annoyingly obtuse and backwards incompatible, like all things systemd
18:00:25 <abadger1999> geppetto: I think I'm inclined to think that always on is not necessary to preserve but I'm willing to see the musts become shoulds in the short term.
18:01:24 <abadger1999> geppetto: Are you +1 as is or only if s/must/should/ ?
18:01:46 <geppetto> with the must => should … unless someone has some good rationale
18:02:41 <abadger1999> Okay, MUSTs changed to SHOULDs.
18:02:48 <abadger1999> RemiFedora: that satisfies you as well?
18:03:17 <RemiFedora> with should, i'm ok, as this let the packager the choice to not use them
18:03:42 <abadger1999> we'll probably end up revisiting this soon (I imagine Viking_Ice will bring it back to us soon).
18:04:10 <abadger1999> #info Timer activation with some revisions passed: (+1:5, 0:0, -1:0)
18:04:22 <abadger1999> #topic #409     Ruby guidelines: Updates for F21
18:04:25 <abadger1999> https://fedorahosted.org/fpc/ticket/409
18:04:38 <abadger1999> I knw some people have to leave right around now...
18:05:39 <geppetto> this seems fairly simple, actually
18:05:54 <tibbs|w> Sorry, I had to step out again.
18:05:59 <geppetto> basically "it should just work, so don't do anything"
18:06:01 <geppetto> +1
18:06:14 <abadger1999> Yeah -- so since we didn't pass tilde, I guess the generator needs to be updated to not use tilde.
18:06:20 <tibbs|w> I thought the systemd timer thing was a fesco-mandated thing, and we didn't really have the power to change anything to "SHOULD".
18:06:26 <SmootherFrOgZ> sorry, I
18:06:29 <limburgher> Right.  +1 assuming they do that.
18:06:36 <SmootherFrOgZ> I've been side-tracked with other stuff
18:06:45 * SmootherFrOgZ reads
18:07:08 <abadger1999> I suppose that if perl is really throwing in too many autodeps (too many autorequires being the thing I worry about)
18:07:18 <abadger1999> then there's no cause to block ruby.
18:08:04 <tibbs|w> I don't think the perl situation is remotely as bad as described in that comment, but of course that should have no bearing on ruby either way.
18:08:11 <geppetto> Hmm … one thing is how does the autodeps thing interact with scls
18:08:31 <geppetto> As SCLs generally say "turn off autodeps, and do something by hand"
18:08:32 <tibbs|w> Oh, you just had to go and say it.
18:09:38 <SmootherFrOgZ> +1 on ruby's updates
18:10:15 <abadger1999> geppetto: I just glanced at the generator but I didn't see anything that would take care of scls.
18:10:39 <abadger1999> geppetto: So I think that ruby people will have to filter autodeps in scls.
18:10:49 <abadger1999> geppetto: It'll be painful and people will get it wrong all the time.
18:10:57 <abadger1999> geppetto: But I think that's the fualt of scls, not ruby.
18:11:07 <geppetto> ok, that probably needs to be put somewhere then
18:11:09 <abadger1999> +1 to the ruby update
18:11:20 <RemiFedora> +1
18:11:30 <geppetto> +1
18:11:42 <abadger1999> geppetto: I have this in the draft scl guidelines: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#Dealing_With_Automatic_Provides.2FRequires_and_Filtering
18:12:02 <abadger1999> " This includes rpm's automatic provides and requires. In general, the scripts that generate provides and requires do not understand how to handle SCLs. Therefore they must be discarded and manually specified Provides and Requires used in their place"
18:12:56 <abadger1999> We're at +5 -- tibbs|w you can vote for the record or tell us that we're all smoking crack if you see an issue with the update ;-)
18:13:12 <tibbs|w> Yeah, +1 assuming the tilde thing gets handled.
18:13:47 <limburgher> Not mutually exclusive.
18:14:18 <abadger1999> #info ruby guideline update passed with the note that the autodep generator needs to be fixed to not use tilde.  (+1:6, 0:0, -1:0)
18:14:23 <abadger1999> #topic Open Floor
18:14:45 <abadger1999> Reminder: I going to Pycon and vacation until the 27th.
18:14:52 <abadger1999> So I won't be around to run meetings.
18:15:04 <abadger1999> Does anyone want to volunteer to chair next week?
18:15:47 <abadger1999> (and someone else can volunteer for the week after and the week after that)
18:16:34 <geppetto> I can take one of them if you can send me some instructions
18:16:42 <geppetto> actually … I should be fine for next week
18:17:10 <abadger1999> geppetto: Cool.  I'll write up the little bit of standard stuff that I do and send you a link.
18:17:20 <geppetto> abadger1999: ok, thanks
18:17:37 <abadger1999> If no one else has anything, I'll close in 60s.
18:18:24 <RemiFedora> abadger1999, if you need other scl example, see http://copr.fedoraproject.org/coprs/remi/php54more/monitor/
18:18:41 <limburgher> nothing here.
18:18:58 <RemiFedora> I have libevent, and libmemcached (using libevent), and some php extension using libevent andor libmemcached
18:18:59 <abadger1999> And thanks for coming to this extra long meeting everyone!  I think we took care of most of hte Fedora-Change relevant ones.
18:19:30 <RemiFedora> I don't say those are perfect... but seems to work.... (auto-dep hell)
18:19:41 <abadger1999> RemiFedora: cool.  WOuld that be php-pecl-event ?
18:19:55 <abadger1999> I'll download and take a look at that later.
18:19:55 <RemiFedora> yes, php-pecl-event use libevent
18:20:04 <abadger1999> excellent.  Thanks!
18:20:06 <RemiFedora> php-pecl-memecached use libmemcached
18:20:18 <RemiFedora> and libmemcahed uses libevent
18:21:17 <abadger1999> #endmeeting