16:00:13 <geppetto> #startmeeting fpc
16:00:13 <zodbot> Meeting started Thu Sep 10 16:00:13 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:14 <geppetto> #meetingname fpc
16:00:14 <geppetto> #topic Roll Call
16:00:14 <zodbot> The meeting name has been set to 'fpc'
16:00:16 * tomspur waves
16:00:20 <tibbs|w> Howdy.
16:00:25 <geppetto> /msg fedbot say #fedora-devel FPC meeting starting now in #fedora-meeting-1
16:00:26 <tibbs|w> Another crap week for me, sorry.
16:00:29 <geppetto> #chair tomspur
16:00:29 <zodbot> Current chairs: geppetto tomspur
16:00:31 <geppetto> #chair tibbs
16:00:31 <zodbot> Current chairs: geppetto tibbs tomspur
16:01:48 <sgallagh> Hello
16:01:57 <geppetto> limburgher orionp racor Rathann SmootherFr0gZ: FPC ping
16:02:02 <geppetto> sgallagh: Hey
16:02:10 <geppetto> sgallagh: You want to do darktable first?
16:02:31 <geppetto> #chair racor
16:02:31 <zodbot> Current chairs: geppetto racor tibbs tomspur
16:02:40 <sgallagh> geppetto: At your discretion.
16:02:53 <tibbs|w> Need a quorum first, I guess.
16:02:57 <sgallagh> /me is concurrently in the blocker review meeting
16:03:33 <geppetto> oriionp is around
16:05:24 <tibbs|w> I can't see the results for darktable changing in any case under the current set of rules surrounding bundling.
16:05:41 <geppetto> which ticket number is it?
16:05:46 <tibbs|w> And completely abandoning the current bundling policy is in the realm of FESCo anyway.
16:06:06 <geppetto> 550?
16:06:08 <sgallagh> tibbs|w: I'd like to reconsider darktable under the "Too big to fail" exception
16:06:29 <tibbs|w> I considered it that way previously when I made my original vote.
16:06:43 <sgallagh> Specifically, it's one of the most popular pieces of software in GNOME Software and it's a critical tool used by the Fedora Design Team
16:06:57 <mizmo> tibbs|w, were you aware that dropping darktable is essentially going to kill the design suite spin?
16:07:41 <mizmo> many people use design suite via group package install. i dont know that it's possible to have a package group that spans multiple physical repos (in this case it'd be the main fedora repos + a copr), and dropping darktable would make the design suite a joke
16:08:10 <tibbs|w> This situation is kind of sad.
16:08:46 <tibbs|w> But under the current rules I don't believe that I would change my opinion.
16:08:59 <tibbs|w> The problem is that I don't necessarily agree fully with the current rules.
16:09:05 <mizmo> and what of benefit is the current decision to fedora?
16:09:06 <tibbs|w> Which puts me in not the best situation.
16:09:10 <mizmo> i can only see a huge list of negatives
16:09:14 <mizmo> not the least of which is user attrition
16:09:20 <bochecha> mizmo: you absolutely can have a group spanning multiple repos, in fact rpmfusion augments some fedora groups through its own comps (however, I don't think copr repos can ship comps files)
16:09:51 <mizmo> we are seen as the friendly distro for designers - we always have the latest versions of the core floss design tools with devel versions apcakged in copr, we have a huge library of fonts and generally are a good distro for designers to work on
16:10:01 <Rathann> hi
16:10:01 <geppetto> tibbs: You don't think it deserves a "shrug, have to accept" ?
16:10:08 <tibbs|w> Anyway, my whole point is that I personally believe that revisiting darktable at this time is a waste of time when we should be addressing the root issue.
16:10:27 <mizmo> bochecha, another concern is that including a package outside of the core fedora repo is going to mean the design suite will be delisted from labs.fedoraproject.org and we'll have to completely rebrand it as a remix
16:10:31 <tibbs|w> geppetto: I was sort of half there before.
16:10:32 <sgallagh> tibbs|w: I'm attempting to do that in parallel with the thread on devel@
16:10:40 <sgallagh> (I haven't had a chance to read your reply yet, sorry)
16:10:46 <tibbs|w> sgallagh: You mean packaging@, I hope.
16:10:52 <tibbs|w> Otherwise I've missed a thread.
16:10:57 <mizmo> how does it not qualify for a copylib exemption https://bugzilla.redhat.com/show_bug.cgi?id=972604#c24
16:11:00 <sgallagh> tibbs|w: Sent to both lists, with replies requested on devel@
16:11:01 <bochecha> mizmo: sure, I was only replying to the groups thing, not to anything else (and note that I'm not part of the FPC, just lurking in here, sorry for the noise :) )
16:11:11 <tibbs|w> crossposting bad.
16:11:28 <sgallagh> tibbs|w: That's why I asked for replies only on devel@
16:11:33 <mizmo> bochecha, i have been told that doing so is against fesco policy
16:11:43 <mizmo> bochecha, (regardless of whether or not its technically feasible)
16:11:49 <geppetto> mizmo: Was Tom aware of how big it was when he said that?
16:11:52 * adamw posted to the trac ticket recently, in case anyone didn't see it
16:11:57 <bochecha> mizmo: rpmfusion has been doing it for some time now, I'm not sure fesco governs rpmfusion
16:12:08 <mizmo> geppetto, you can talk to him yourself, i did this morning, and he related to me the opinion this is a clear exception case
16:12:13 <adamw> afaics this whole thing pivoted from 'is rawspeed a copylib?' to 'FPC DEMANDS RAWSPEED BECOME A SHARED LIBRARY!' with no justification and no proper evaluation of copylib status
16:12:16 <tibbs|w> No, fesco doesn't govern rpmfusion though they do try to follow Fedora guidelines.
16:12:46 <geppetto> adamw: The first question was before we knew anything about it … Eg. it's size.
16:13:00 <geppetto> adamw: The second isn't true … while shared is nice, static is fine.
16:13:16 <orionp> sorry, helping a user...
16:13:20 <geppetto> adamw: But 30k+ is a pretty big thing that people should just copy around
16:13:26 <geppetto> #chair orionp
16:13:26 <zodbot> Current chairs: geppetto orionp racor tibbs tomspur
16:13:35 <geppetto> Ok, we have 5
16:13:40 <geppetto> #topic Schedule
16:13:48 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-September/010965.html
16:14:01 <adamw> geppetto: i don't see anything in the current policy which says that size is an indicator of copylib status, nor can I find anything which says it's appropriate for FPC to turn its opinions about correct design into demands on upstream maintainers.
16:14:09 * SmootherFrOgZ here
16:14:09 <sgallagh> geppetto: gnulib is pretty enormous too; I don't think the size is directly relevant
16:14:10 <geppetto> #topic #550 Darktable and Rawspeed internal library
16:14:14 <sgallagh> (And is not documented as being such)
16:14:15 <geppetto> .fpc 550
16:14:16 <zodbot> geppetto: #550 (Darktable and Rawspeed internal library) – fpc - https://fedorahosted.org/fpc/ticket/550
16:14:16 <geppetto> https://fedorahosted.org/fpc/ticket/550
16:14:21 <adamw> you have the upstream author *explicitly stating that the code is intended to be used as a copylib*. that seems like a fairly strong indicator of copylib status.
16:14:23 <Rathann> geppetto: I'm here as well
16:14:30 <geppetto> sgallagh: But people only take parts of gnulib
16:14:33 <mizmo> is there anywhere in the packaging guidelines that demonstrates a size requirement for copylib because i dont see it
16:14:33 <geppetto> #chair Rathann
16:14:33 <zodbot> Current chairs: Rathann geppetto orionp racor tibbs tomspur
16:14:39 <geppetto> Rathann: Ahh, sorry didn't see you
16:14:49 <mizmo> if we're all about adhering to the letter of the guidelines, i would expect a size requirement to be in them
16:15:09 <mizmo> upstream authors are also authors of the said library
16:15:18 <jwb> i would politely suggest everyone stop bombarding questions.  there is literally no time to reply to any of them
16:15:29 <racor> adamw: Experience tells upstreams who say "this is copylib" often are clueless or just being lazy.
16:16:21 <Rathann> also, upstream themselves said they could make it a proper library, but have other priorities so patches welcome
16:16:25 <geppetto> #chair SmootherFrOgZ
16:16:25 <zodbot> Current chairs: Rathann SmootherFrOgZ geppetto orionp racor tibbs tomspur
16:16:29 <adamw> racor: you should evaluate specific requests on their specific merits, not on some nebulous claim about 'past experience'.
16:16:35 <mizmo> racor, have you met the darktable authors? because i have, they are not clueless or lazy
16:17:00 <adamw> racor: is there something specific in https://github.com/klauspost/rawspeed/issues/109 which indicates this specific upstream is 'clueless or just being lazy'?
16:17:11 <geppetto> Then my fiurst question to them would be why are you shipping a 30k copylib?
16:17:57 <Rathann> mizmo: if you'd like us to change the vote then please provide some new arguments, otherwise we're just wasting time here
16:18:00 <geppetto> And being lazy is relative … just because they are working hard on XYZ doesn't mean that they care about software engineering for rawspeed
16:18:09 <adamw> because it's the standard codebase for dealing with something they really need, and they have a perfectly workable system for using it agreed with its author?
16:18:17 <stickster> From reading the github discussion, I took away one reason is to ensure synchronized support for hardware
16:18:24 <mizmo> Rathann, how about the impact to users
16:18:28 <tibbs|w> I think the argument is that this cripples a spin.[
16:18:33 <mizmo> Rathann, darktable has been in fedora for years
16:18:37 <geppetto> But anyway, as sgallagh said, I'm +1 on it for the too big to fail part now … although I still think it's pretty broken
16:18:38 <mizmo> we have many users
16:18:40 <stickster> It would be great if we could stop passing judgment on the character of upstream developers. :-)
16:19:04 <tomspur> geppetto: same here
16:19:06 <mizmo> removing darktable is going to likely break f22=>f23 upgrades for a user population that tends to be less technical (designers)
16:19:18 <sgallagh> Rathann: The new information is the significant loss to (and likely, *of*) users due to this
16:19:22 <tibbs|w> We're primarily an engineering committee so some of that doesn't really get considered here.
16:19:24 <mizmo> or, it'll result in unupdated potential security issue laden software remianing on the F23 upgrade if it works
16:19:25 <Rathann> yes, let's just say that they place lower priority on unbundling than we do
16:19:43 <tibbs|w> Also, FESCo gets to override any FPC decision by the charter, so....
16:19:46 <Rathann> mizmo: and that'd a good reason to change the vote, thank you
16:19:56 <mizmo> the point of fedora is that people USE it, that's really the core point of it, so not considering how this would actually affect our user base seems very shortsighted. i work in an engineering dept and the user is always paramount in decision making
16:20:06 <adamw> Rathann: i'd suggest that the request has never been properly evaluated. the only justification so far for not considering rawspeed as a copylib has been that it's 'too big and active', neither of which is listed as indicating not-a-copylib anywhere that I can find. the specific statement by the upstream author that it is intended to be used as a copylib was also never properly considered: it was not present at the time of the first meeting, and the
16:20:06 <adamw> second meeting never even touched on it.
16:20:35 <tibbs|w> Anyway, I still think this isn't the right place to be making this argument.  How can our rules be changed in a way which would avoid this pain point?
16:20:43 <geppetto> Rathann: tibbs: racor: Would you support a tmp. exception for too bigness, just for 23+24 (or just 23) given how soon it is?
16:20:51 <mizmo> so some points i didn't see in the meeting minutes from your decision (1) no consideration of completely breaking a popular, long-running spin that a fedora team relies on (2) breaking upgrades for current users
16:20:59 <tomspur> mizmo: With this argument we can simply stop with all unbundling effort and just push anything out there that is "used"
16:21:01 <stickster> tibbs|w: Does that go to sgallagh proposal?
16:21:08 <Rathann> geppetto: I was initially proposing a temp exception
16:21:11 <Rathann> so yes
16:21:19 <mizmo> tomspur, no but thanks anyway
16:21:24 <racor> mizmo: what you say to me is populism.
16:21:29 <Rathann> 2 releases-long is fine by me
16:21:29 <geppetto> tomspur: To be fair, I think this qualifies as more than just used.
16:21:45 <jwb> racor, which appears to be exactly what "too big to fail" exceptions are for
16:21:48 <tibbs|w> stickster: Yes, though I think his proposal (which I'm basically seeing as "have no real rules about this" is a bit extreme.
16:21:49 <mizmo> racor, the exemptions in the packaging guidelines exist for a reason otherwise why do you even have exemptions? there is literally a populism exemption. so drop the guff
16:22:16 <racor> jwb: Exactly, adopting this rule was a mistake.
16:22:20 <tibbs|w> mizmo: It would be easier if you had some context about the committee members.
16:22:22 * adamw would still like to see an actual reason for not granting a permanent exception for rawspeed as a copylib, which is clearly what it is, and hasn't yet.
16:22:23 <tomspur> geppetto: I don't read that this way above, sorry.
16:22:23 <mizmo> how about a temporary exemption until the guidelines which i have seen committee members admit they dont agree with are fixed?
16:22:39 <geppetto> tomspur: no problem … there is currently a wall of text
16:22:51 <tibbs|w> racor takes a very hard line, and you're not going to have a whole lot of luck convincing him with the arguments you're making.
16:23:00 <racor> mizmo: The back ground of exceptions is to give all parties time to work things out.
16:23:05 <tibbs|w> geppetto and I are pretty much on the fence about this, but for different reasons.
16:23:09 <mizmo> wonderful, the future of fedora is we'll have 5 users
16:23:12 <tibbs|w> At least I think so.
16:23:13 <geppetto> mizmo: I just proposed that half a page up, although people might not have read it yet
16:23:16 <jwb> mizmo, hyperbole won't help.
16:23:39 <geppetto> tibbs: I'm not on the fence, esp. for the tmp. exception
16:23:59 <tibbs|w> geppetto: Sorry if I mischaracterized.
16:24:02 <geppetto> no problem
16:24:28 <tibbs|w> Did you vote +1 originally?  I can't recall the vote now.
16:24:30 <racor> tibbs|w: Yes, I am taking the hard line, because unlike most people around, I had seen the harm copylibs (and static libs) have on distros.
16:24:46 <geppetto> So, anyway … for a tmp. exception I think we are at +3 … me, Rathann, tomspur?
16:24:51 <mizmo> racor, there is a perceived issue with upstream, but there is also an issue with the actual guidelines. i'd assert the exemption is needed for the latter more than for the former
16:25:01 <tibbs|w> racor: I've seen them as well and I understand the issue.
16:25:06 <racor> tibbs|w: which ticket are we on?
16:25:06 <mizmo> since i know the former was already considered last meeting
16:25:08 <tibbs|w> But I think we need a balance.
16:25:16 <tibbs|w> racor: It's 550: https://fedorahosted.org/fpc/ticket/550
16:25:43 <tibbs|w> Also, this question is a bit more complicated than "bundle or not".
16:25:54 <mizmo> the other side to this hard line racor is that i have a team of volunteer designers working for fedora that i risk losing to another distro
16:25:55 <SmootherFrOgZ> geppetto: +1 on tmp exception
16:26:02 <tibbs|w> Because the thing folks would like to bundle also bundles something else.
16:26:23 <adamw> doesn't the ticket say they took it out?
16:26:53 <tibbs|w> Does it?
16:27:03 <geppetto> tibbs: I'm also not sure that matters given the criteria we are exempting it under.
16:27:25 <tibbs|w> geppetto: True, my point was just that this is more cimplicated than it seems on the surface.
16:28:06 <tibbs|w> And as far as I can see, there's no mention of rawspeed having unbundled pugixml.
16:28:14 <geppetto> Ok, so we are at +4 for a 23/24 exception atm.
16:28:22 <geppetto> Yeh, I don't think it has
16:28:36 <stickster> adamw: tibbs|w: https://github.com/klauspost/rawspeed/issues/109#issuecomment-120702503 is relevant to the second-level bundling I think you're referring to
16:28:42 <tibbs|w> +1 for that exception in any case.
16:28:55 <geppetto> Ok, +5
16:28:56 <tibbs|w> stickster: OK, thanks.
16:29:06 <geppetto> orionp: racor: Want to vote for the recrod?
16:29:51 <stickster> Also I wanted to say special thanks to Rathann for having the discussion with upstream *cordially*
16:30:01 <Rathann> stickster: you're welcome
16:30:04 <Rathann> :D
16:30:12 <tibbs|w> Yes, that has been very helpful.
16:30:18 <Rathann> I hope I managed to pour some oil on the troubled waters
16:30:27 <tibbs|w> ...
16:30:37 <tibbs|w> That must be an expression that didn't translate well into English.
16:30:47 <geppetto> I was thinking the exact same thing :)
16:30:54 <orionp> So, do we have a sense that someone is going to drive the effort to unbundling rawspeed?  Or are we declaring it a copylib permanently?
16:31:01 <tibbs|w> So, look, a temporary exemption isn't a solution.
16:31:06 <geppetto> orionp: This is just for 23/24 atm/.
16:31:22 <tibbs|w> The solution doesn't lie with rawspeed/darktable/whatever.  It lies with our guidelines.
16:31:28 <geppetto> orionp: Based on the fact the Design spin is going to be screwed without it
16:31:48 * stickster would think this needs revisiting based on (1) results of curernt conversation about bundling guidelines; (2) failing (1), timeline (since this is temporary)
16:31:58 <tibbs|w> There's an argument that the bundling rules, and specifically the ones surrounding copylibs are unclear.
16:32:12 <geppetto> Maybe, but we don't need to argue about that with a looming 23 and very unhappy design spin participants
16:32:30 <adamw> and you still haven't clearly evaluated whether rawspeed is a freaking copylib under the current guidelines! i don't get why this is hard.
16:32:31 <tibbs|w> Well, we need to discuss it eventually.
16:32:32 <mizmo> thank you
16:32:52 <mizmo> this was too short notice for the designers for sure
16:32:54 <tibbs|w> adamw: It's hard because the whole issue is hard.
16:33:22 <geppetto> mizmo: No problem, it wasn't clear how needed it was before. So sorry for the panic attacks
16:33:34 <mizmo> geppetto++
16:33:34 <zodbot> mizmo: Karma for james changed to 1 (for the f22 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:34:04 <tibbs|w> And I'll go ahead and be a dick and say that you have your exemption for now, and that that kind of thing doesn't really add to the discussion.
16:34:23 <adamw> tibbs: the guidelines are there. upstream has clearly stated that rawspeed is a copylib per those guidelines. no-one even seems willing to say 'no, we disagree', you just seem to keep avoiding the question.
16:34:29 <Rathann> tibbs|w, geppetto: I may have misremembered the idiom, sorry
16:34:59 <adamw> tibbs: a temporary exception on the grounds that darktable is 'too big to fail' is fundamentally different from a permanent exception on the grounds that rawspeed is a copylib. it seems an important question to me.
16:35:03 <rishi> tibbs|w: The issue is not that hard.
16:35:09 <orionp> adamw - I'm afraid we don't just let upstream declare themselves a copylib.  Sorry.
16:35:18 <rishi> This is not gtk+ or qt or openssl, which already exist as standalone libraries.
16:35:18 <adamw> i don't have a dog in this fight directly; i don't use darktable or rawspeed. i just find the quality of the decision making here lacking.
16:35:30 <geppetto> adamw: Ok then, "no, we disagree" … if upstream glib turned around and said it was a copylib now, we wouldn't just agree.
16:35:59 <rishi> Are we really going to say that people can't copy around random pieces of free software?
16:36:04 <adamw> orionp: but the first meeting on this issue specifically wound up saying we should go and ask upstream to clarify. so someone went and asked upstream to clarify. now you're saying you don't trust what upstream says. so what was the point of that?
16:36:10 <tibbs|w> rishi: We already have.
16:36:19 <geppetto> adamw: Generally the size of things we'll take upstreams word on "this is a copylib" is like md5
16:36:46 <tibbs|w> But really, now we're just off the rails and I'll again be a dick and say that at this point non-FPC people here are just muddling the discussion.
16:36:57 <geppetto> rishi: People can do what we want … just like people can create rpms that throw up a GUI … but some things aren't a good idea.
16:37:04 <geppetto> s/we/they/
16:37:05 <tibbs|w> There's no valid reason to piss people off at this point.
16:37:38 <geppetto> Yeh, it's already +5 there doesn't seem much point in discussing it more this week
16:37:48 <adamw> geppetto: and still the guidelines say nothing at all about size, so you're making decisions with absolutely no support in actual written policy. but sure, if you want to duck the issue, duck it.
16:37:49 <Rathann> we clearly haven't anticipated that someone would make a copylib of that size (or even larger like kwsys)
16:37:54 <racor> sorry, phone ring like crazy, trying to catch up.
16:38:57 <mizmo> the time exemption is in order for the guidelines to be fixed right? so FPC has two releases to fix the guidelines adamw
16:39:11 <tomspur> adamw: The guidelines say "Some of the criteria are..." the final decision can be made here in the meeting.
16:39:12 <tibbs|w> That's the whole point behind my vote at least.
16:39:34 <geppetto> adamw: The rules aren't mean to be hard and fast … specifically so we aren't forced to do bad things
16:39:36 <tibbs|w> Not screw something up now while we figure out how to fix what's unclear and to address the pain points this is obviously causing.
16:39:55 <geppetto> Lots of options, but yes, changing policy is one option.
16:40:35 <Rathann> adamw: the policy doesn't cover all corner cases
16:40:36 <racor> my vote on 550: -1, classical case of an upstream doing a poor job.
16:40:50 <Rathann> rawspeed and kwsys are such cases
16:40:54 <geppetto> orionp: Going to give you another minute, and then just action it, so we can move on.
16:41:06 <orionp> I'm 0
16:41:09 <geppetto> ok, thanks
16:41:19 <geppetto> #action Temporary exception during 23/24 for Darktable, due to critical usage in Design spin (+1:5, 0:1, -1:1)
16:41:40 <geppetto> #topic #567     Packaging Python 3 applications and modules for EPEL 7+
16:41:41 <geppetto> .fpc 567
16:41:41 <geppetto> https://fedorahosted.org/fpc/ticket/567
16:41:42 <zodbot> geppetto: #567 (Packaging Python 3 applications and modules for EPEL 7+) – fpc - https://fedorahosted.org/fpc/ticket/567
16:41:47 <tibbs|w> Do the various things that bundle this at least have the proper Provides: ?
16:41:53 <drago01> so doesn't this mean we will have the same discussione again in one year? ....
16:42:19 <geppetto> drago01: Over the next year we will have more discussions, yes … but hopefully everyone will have a cooler head about it
16:42:24 <tibbs|w> drago01: Well, it shouldn't be exactly the same discussion unless FPC folks decide that none of the existing rules/verbiage need changing.
16:43:01 <geppetto> drago01: And again, there are multiple options for solving it … from just giving darktable a perm. exception and doing nothing else, to changing policy, …
16:43:14 <drago01> ok fair enough ... I just prefer final decisions than to postpone it but works for now
16:43:36 <geppetto> Anyway …
16:43:42 * Rathann still holds to the hope that upstream or someone else will make rawspeed a proper library
16:43:48 <geppetto> orionp: You want to say anything about 567?
16:44:20 <geppetto> Rathann: Yeh, given they said they'll accept patches … that's another option
16:44:23 <orionp> I suppose
16:44:52 <orionp> EPEL would like to be able to support two concurrent python3 stacks
16:45:15 <orionp> Packagers (me at least) would like to maintain the same spec in Fedora and EPEL7
16:45:49 <orionp> rel-eng is waiting for FPC approval before allowing python-pkgversion-macros (name?) in buildroots
16:46:06 <orionp> I think those are the salient points
16:47:04 <orionp> I think my %python3_package macro is ugly, but maybe it is useful
16:47:07 * geppetto nods … so from the last update the new specfiles can have macros for description+summary+requires?
16:47:29 <orionp> right
16:48:15 <orionp> Haven't checked in %python3_package anywhere yet, waiting for feedback
16:48:23 <tibbs|w> Current guidelines do annoyingly require that you paste the %description at least three times.
16:48:53 <tibbs|w> In my test cases I just did %global desc with some multiline thing, which is suboptimal but not really that bad.
16:48:56 <geppetto> Yeh, it looks kind of ugly :( … but if you build for two/three versions you only need one set of info. … which is nice
16:49:11 <tibbs|w> That's kind of why I liked the macro.
16:49:28 <geppetto> I don't suppose you pinged any rpm devs. about having access to the description from lua?
16:49:42 <orionp> I filed a bug..
16:49:55 <tibbs|w> geppetto: Would be nice, but there's zero chance of that ever being able to actually help EPEL.
16:49:57 <geppetto> Ahh, cool … you know what it is?
16:50:05 <geppetto> tibbs: ahh, true
16:50:24 <geppetto> And the problem will go away on it's own for el8
16:50:52 <orionp> hmm, I thought I did
16:50:55 * geppetto shrugs … I'm mostly leaning toward just letting this be an "optional" thing for el7 python packaging
16:51:19 <orionp> I also filed http://rpm.org/ticket/894 fwiw
16:51:48 <orionp> ah, I sent a message to the rpm list - nothing back though
16:52:08 <geppetto> ok
16:52:29 <geppetto> Might be worth saying what the value of %1 is … also should probably open a BZ
16:52:34 <tibbs|w> geppetto: I'm mostly with you.  After cleaning up it appears to just be another set of identical blocks of stuff which is verbosity but not particularly confusing.
16:52:36 <geppetto> I'm not sure how much track is used for rpm.org
16:53:03 <orionp> http://lists.rpm.org/pipermail/rpm-list/2015-September/001763.html
16:53:18 <tibbs|w> I don't particularly like the fact that we need to change to the longer python3_otherversion thing but I think that could easily go in the EPEL guidelines and folks doing Fedora only wouldn't need to care.
16:53:27 * geppetto nods
16:54:01 <tibbs|w> So, Proposal: This stuff should go into EPEL guidelines now.
16:54:21 * tomspur is thinking if this loop over multiple python versions can be macronized fully
16:54:24 <geppetto> orionp: Did you want to update the draft with py3_package?
16:54:29 <tibbs|w> Fedora python packages will need to define enough macros to make things work.
16:54:36 <tibbs|w> tomspur: Yes, we've been talking about that.
16:54:53 <tomspur> tibbs|w: Was that last week? I wasn't there then.
16:54:53 <geppetto> tomspur: If you can do that without it looking like yuck, we would happily vote on that at some point
16:55:16 <geppetto> But I think at some point the rpmspecfile language needs to become an actual language for that to work.
16:55:19 <tibbs|w> tomspur: I'm definitely for that even though it does sort of straddle the line of hiding too much behind macros.
16:55:34 <tibbs|w> geppetto: That is a certainty.  But we work with the RPM we have.
16:55:40 * geppetto nods
16:55:51 <tomspur> Yeah, there needs to be an opinion to disable non-working python versions for a package... :/
16:57:45 <geppetto> That should be pretty unlikely with minor version changes, right?
16:58:04 <geppetto> Esp. as it's a tmp. thing to help upgrades, so the packager has to deal with it eventually
17:00:20 <tomspur> for py_version in ["python2", "python3", "pypy3]: build_package(py_version) - would also help fedora in the end ;)
17:00:24 * tomspur ducks
17:00:30 <orionp> I'll work on an updated draft.  put a link in the python guidelines to the epel7 specific guidelines
17:00:54 <geppetto> Ok, you want to wait another week then?
17:01:02 <orionp> sure
17:01:22 <geppetto> ok
17:01:28 <orionp> So - do we want a generic %py_package macro?
17:01:54 <geppetto> I'm happy for it to be called that
17:02:06 <geppetto> So whichever you'd prefer
17:02:21 <orionp> I'm not sure it's possible actually
17:02:49 <orionp> Well, maybe if everything really has a python2- provide/name
17:03:13 <orionp> which it is suppose to now, so maybe
17:04:24 <geppetto> #action orionp Update draft, incl. py3_pkg etc.
17:04:40 <geppetto> #info Everyone mostly seems in favour of it for el7 optional
17:04:50 <geppetto> #topic #566     RPM file triggers
17:04:50 <geppetto> .fpc 566
17:04:50 <geppetto> https://fedorahosted.org/fpc/ticket/566
17:04:52 <zodbot> geppetto: #566 (RPM file triggers) – fpc - https://fedorahosted.org/fpc/ticket/566
17:05:11 <geppetto> Do we have anything to discuss here?
17:05:18 <geppetto> I've looked at it quite a bit
17:05:37 <tibbs|w> We need to keep track of which master packages have added the triggers, at least.
17:05:45 * geppetto nods
17:05:49 <tibbs|w> I saw that another one had done it recently but now I can't recall which it was.
17:06:12 <geppetto> interesting
17:06:14 <tibbs|w> Eventually we would like to bug the various maintainers to add them (glibc, especially).
17:06:16 <racor> i am quite irritated about the font-config guy having galopped ahead
17:06:25 <tibbs|w> Why?
17:07:00 <tibbs|w> Are you suggesting that we should have some guidelines in place first?
17:07:02 <racor> tibbs|w: Is their change 100% transparent on the rpm.spec level - AFAICT no
17:07:16 <tibbs|w> I don't know what you mean by "100% transparent".
17:07:35 <tibbs|w> It doesn't require packages to do anything, though they can drop their scriptlets if they like.
17:07:55 <racor> tibbs|w: More verbose: Does their change require any change on the rpm-spec level?
17:08:10 <racor> ... in other packages.
17:08:21 <tibbs|w> No.
17:08:29 <geppetto> Yeh, I'm mostly fine with people just trying it out … if we decide later to have all the filetirgger scripts be in a specific dir. or something, it should be easy to change.
17:08:31 <tibbs|w> In fact, it allows packages to remove things.
17:08:52 <tibbs|w> geppetto: Actually we don't really care where the trigger scripts go.  RPM takes care of that.
17:09:51 <geppetto> tibbs: Well, it might be nice to place them in a specific place … apart from anything else that'd then be an implicit "how to find out if a package has them"
17:09:53 <racor> Another issue, which had haunted "triggers" in the past, was it was difficult to get rid of them, e.g. in cases bogus triggers had made it into a package somewhere.
17:10:04 <tomspur> Which package needs to be installed to trigger the e.g. gdk-pixbuf scripts?
17:10:24 <tomspur> I guess the main gdk-pixbuf2 package needs to be installed for RPM to "see" the triggers?
17:10:31 <tibbs|w> tomspur: Yes.
17:10:44 <tibbs|w> But it would necessarily be a dependency anyway.
17:11:04 <tomspur> Is it possible to move them to another package?
17:11:21 <tibbs|w> They can go in any package as long as it's in the dependency chain.
17:11:23 <geppetto> tomspur: Yes, but the triggers are run on package install/remove
17:11:27 <tibbs|w> Though I don't know why you would want to do that.
17:11:53 <tibbs|w> Technically the triggers are run whenever a package adds or removes something to/from the relevant directories.
17:12:22 <tomspur> I could imagine that a package has some subpackages with different triggers. So the triggers should only be available if the specific subpackage is installed. Maybe an example for that would be good for the guidelines?
17:13:30 <tibbs|w> I'm having trouble understanding how that would come about.
17:13:56 <geppetto> tibbs: yeh, but they are also run on package install of the trigger package … so you can install foo which puts a file in /path/to/trigger … then install bar which has a script trigger on that path, and bar will trigger on it's package install
17:14:21 <tibbs|w> Basically: if there are a bunch of packages that have identical scriptlets, and all depend on the same thing for those scriptlets, move those scriptlets into a trigger that's part of that dependency.
17:14:40 <tibbs|w> So glibc gains a trigger on /usr/lib /usr/lib64 etc. that runs ldconfig.
17:15:09 <tibbs|w> And all packages can drop those scriptlets if they want.  (But of course, EPEL compatibility and such will make for yet more fun.)
17:15:18 * tomspur is thinking about a concrete example for the above
17:15:38 * Rathann has to drop off for about 30 minutes
17:15:47 <tibbs|w> For right now, just think of what's on the ScriptletSnippets page.
17:16:24 <tomspur> Let's say you have an empty main package and the subpackages foo and bar. Is it possible to move the triggers to the foo package, so that if bar is installed (but foo not) the triggers are not in effect?
17:16:26 <tibbs|w> All of those are simple cases.  If we can get those handled, then packages can start dropping scriptlets and we can achieve some cleanup.
17:16:43 <tibbs|w> tomspur: The only thing that matters is the dependency chain.
17:16:43 <tomspur> Sure it's a corner case, but basically that was what I had in mind above
17:16:53 <geppetto> Rathann: ok. Hopefully we should finish before then.
17:17:06 <tibbs|w> If somehow the dep chain will pull in the package containing the triggers, then things will happen as they should.
17:17:08 <tomspur> (or I didn't fully understand how the triggers are implemented in RPM)
17:19:00 <tibbs|w> It's actually pretty simple, but I misunderstood it for a while.
17:19:01 <geppetto> tomspur: If I understand your example correclty … then yes
17:19:18 <tomspur> ok, great
17:20:14 <racor> Are these triggers supposed to be "stateless". I mean do they rebuild "everything"?
17:21:16 <tibbs|w> They're supposed to be idempotent.  No different than the scriptlets we have now.
17:21:39 <geppetto> racor: they are given the list of files that apply in the current transaction
17:21:40 <tibbs|w> package puts a file in /usr/lib64, that triggers ldconfig to run.
17:21:56 <geppetto> racor: But AFAIK all of them are simple and rebuild everything atm.
17:22:07 <orionp> they can be once per package or once per transaction
17:22:26 <geppetto> right, that too
17:22:30 <orionp> transaction ones are presumably more "stateless"
17:23:01 <geppetto> AFAIK it doesn't matter
17:23:05 <racor> OK, but we also have scriptlets, which work incremental.
17:23:10 <geppetto> they can still just trigger off the list of files.
17:23:34 <geppetto> The main difference is if the scriptlet will need to be run before any depending packages get installed
17:23:40 <geppetto> If so you can't do transaction level
17:25:40 <geppetto> ok, anything else we need to say about this?
17:25:52 <geppetto> At least until we get some draft or something?
17:26:35 <tibbs|w> Not really.
17:26:43 <kalev> I have a few things
17:26:47 <tibbs|w> We just need to keep track of what packages add what triggers.
17:26:49 <geppetto> kalev: o
17:26:51 <geppetto> kalev: ok
17:27:00 <kalev> first is that the new rpm just landed in F23 so it should be fine to use file triggers there too
17:27:10 <tibbs|w> And then update the various pages to note which scriptlets are unneeded in F23.
17:27:12 <geppetto> yeh, that's in the ticket
17:27:14 <tibbs|w> kalev: Yeah, that's in the ticket.
17:27:32 <kalev> second is that to make use of this in koji / mock, we need to have builders running the new rpm as well
17:27:46 <kalev> right now builders are on F21 and older rpm
17:28:08 <geppetto> Hmmm … ok, doesn't that happen automatically (so the f23 builders will now build with the new rpm)?
17:28:11 <kalev> it doesn't reject the spec file or anything, it's just that when it's installing BuildRequires, it doesn't run any file triggers
17:28:19 <geppetto> Ahh
17:28:25 <tibbs|w> Now that's interesting.
17:28:26 <kalev> no, all builders are on F21 right now and mock uses host system's rpm
17:28:40 <kalev> but releng said they are planning on updating the builders to F23
17:28:45 <geppetto> ok
17:28:50 <kalev> so it shouldn't be an issue for long
17:29:15 <kalev> another thing I had in mind is the icon theme rebuilding scripts
17:29:27 * kalev finds the scriptlet page.
17:29:40 <kalev> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache
17:30:04 <kalev> so right now it does 'touch touch --no-create /usr/share/icons/hicolor' in %post
17:30:14 * geppetto nods
17:30:14 <kalev> and then runs the actual rebuilding script in %posttrans
17:30:47 <kalev> but the files are actually installed in subdirectories; we'll have to make sure the file triggers work recursively on subdirectories too
17:31:01 <kalev> I haven't verified that yet
17:31:02 <geppetto> yeh, it's just a path prefix match AIUI
17:31:10 <tibbs|w> Yes, it's a string match.
17:31:11 <geppetto> Basically if path.startswith(foo)
17:31:24 <kalev> cool, I guess then we can just have a file trigger that does the touch + gtk-update-icon-cache
17:31:38 <kalev> and finally, last item: how are upgrades going to work
17:31:51 <geppetto> AIUI you can just have a trigger that does the update-icon-cache for the transaction
17:31:59 <kalev> let's say someone is upgrading from F22 that has older gtk-update-icon-cache rpm, that has no file triggers
17:32:32 <kalev> and then the upgrade transaction to F23 happens to order the package that installs png files earlier, and gtk-update-icon-cache later
17:32:49 <kalev> does the new, F23 gtk-update-icon-cache rpm's file triggers run in that case?
17:33:03 <geppetto> Yes. As the new rpm is installed, the triggers are run (due to file paths existing in installed packages)
17:33:08 <kalev> or do we need to have a versioned dep in each package on the new F23 gtk-update-icon-cache rpm?
17:33:32 <kalev> great :)
17:33:51 <geppetto> Also worth pointing out:
17:33:53 <tibbs|w> F23 will be kind of interesting in that respect.
17:33:53 <geppetto> https://wiki.mageia.org/en/RPM_filetriggers#Currently_supported_filetriggers
17:34:16 <tibbs|w> They jumped all over this.
17:34:32 <geppetto> Which is what mageia converted to file triggers (although they used rpm5 so we can't just take it … but it gives us an idea of what can be converted)
17:34:47 <tibbs|w> Someone uses rpm5?
17:35:10 <geppetto> yeh, they were the one … but that was before the split
17:35:25 <geppetto> AIUI mageia is the one after the split that went back to non-rpm5
17:35:38 <tibbs|w> I can't keep track.
17:35:45 <geppetto> But they carried around a patch for file triggers for a bit, and are now very happy something got upstream :)
17:35:46 <kalev> mageia was patching rpm to add file triggers support for quite some time, I believe
17:35:50 <kalev> yep :)
17:36:08 <kalev> anyway, all from me, just wanted to point out those few things :)
17:36:23 * geppetto nods … ok
17:36:27 <tibbs|w> But in any case, I don't think there's much else we need to do here.  But the fact that rpm on the builders doesn't handle this gets in the way then we will need to add some kind of notice to the guidelines.
17:36:45 <tibbs|w> I guess I'll add something else to my list.
17:36:51 <kalev> it may not be a problem for some kinds of triggers
17:37:15 <kalev> I mean, it's probably fine if the icon cache doesn't get rebuilt on builders, but if it gets properly rebuilt when installing the actual packages on an actual system
17:37:23 <geppetto> #info Builders are currently at F21, but should move to F23 soon … can't use them until then though.
17:37:29 <tibbs|w> True.  I think even ldconfig is just a caching thing.
17:37:36 <geppetto> yeh
17:37:42 <geppetto> A lot are probably fine
17:37:52 <geppetto> But I'm sure there's one that'll break the world ;)
17:38:07 <geppetto> Anyway … anything else:
17:38:08 <geppetto> #topic Open Floor
17:41:57 * Rathann is back and reading the backlog
17:42:08 <geppetto> Ok … going to close in a minute or so.
17:42:18 <geppetto> Thanks for coming
17:45:08 <geppetto> #endmeeting