16:00:13 #startmeeting fpc 16:00:13 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:14 #meetingname fpc 16:00:14 #topic Roll Call 16:00:14 The meeting name has been set to 'fpc' 16:00:16 * tomspur waves 16:00:20 Howdy. 16:00:25 /msg fedbot say #fedora-devel FPC meeting starting now in #fedora-meeting-1 16:00:26 Another crap week for me, sorry. 16:00:29 #chair tomspur 16:00:29 Current chairs: geppetto tomspur 16:00:31 #chair tibbs 16:00:31 Current chairs: geppetto tibbs tomspur 16:01:48 Hello 16:01:57 limburgher orionp racor Rathann SmootherFr0gZ: FPC ping 16:02:02 sgallagh: Hey 16:02:10 sgallagh: You want to do darktable first? 16:02:31 #chair racor 16:02:31 Current chairs: geppetto racor tibbs tomspur 16:02:40 geppetto: At your discretion. 16:02:53 Need a quorum first, I guess. 16:02:57 /me is concurrently in the blocker review meeting 16:03:33 oriionp is around 16:05:24 I can't see the results for darktable changing in any case under the current set of rules surrounding bundling. 16:05:41 which ticket number is it? 16:05:46 And completely abandoning the current bundling policy is in the realm of FESCo anyway. 16:06:06 550? 16:06:08 tibbs|w: I'd like to reconsider darktable under the "Too big to fail" exception 16:06:29 I considered it that way previously when I made my original vote. 16:06:43 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 tibbs|w, were you aware that dropping darktable is essentially going to kill the design suite spin? 16:07:41 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 This situation is kind of sad. 16:08:46 But under the current rules I don't believe that I would change my opinion. 16:08:59 The problem is that I don't necessarily agree fully with the current rules. 16:09:05 and what of benefit is the current decision to fedora? 16:09:06 Which puts me in not the best situation. 16:09:10 i can only see a huge list of negatives 16:09:14 not the least of which is user attrition 16:09:20 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 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 hi 16:10:01 tibbs: You don't think it deserves a "shrug, have to accept" ? 16:10:08 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 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 geppetto: I was sort of half there before. 16:10:32 tibbs|w: I'm attempting to do that in parallel with the thread on devel@ 16:10:40 (I haven't had a chance to read your reply yet, sorry) 16:10:46 sgallagh: You mean packaging@, I hope. 16:10:52 Otherwise I've missed a thread. 16:10:57 how does it not qualify for a copylib exemption https://bugzilla.redhat.com/show_bug.cgi?id=972604#c24 16:11:00 tibbs|w: Sent to both lists, with replies requested on devel@ 16:11:01 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 crossposting bad. 16:11:28 tibbs|w: That's why I asked for replies only on devel@ 16:11:33 bochecha, i have been told that doing so is against fesco policy 16:11:43 bochecha, (regardless of whether or not its technically feasible) 16:11:49 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 mizmo: rpmfusion has been doing it for some time now, I'm not sure fesco governs rpmfusion 16:12:08 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 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 No, fesco doesn't govern rpmfusion though they do try to follow Fedora guidelines. 16:12:46 adamw: The first question was before we knew anything about it … Eg. it's size. 16:13:00 adamw: The second isn't true … while shared is nice, static is fine. 16:13:16 sorry, helping a user... 16:13:20 adamw: But 30k+ is a pretty big thing that people should just copy around 16:13:26 #chair orionp 16:13:26 Current chairs: geppetto orionp racor tibbs tomspur 16:13:35 Ok, we have 5 16:13:40 #topic Schedule 16:13:48 https://lists.fedoraproject.org/pipermail/packaging/2015-September/010965.html 16:14:01 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 geppetto: gnulib is pretty enormous too; I don't think the size is directly relevant 16:14:10 #topic #550 Darktable and Rawspeed internal library 16:14:14 (And is not documented as being such) 16:14:15 .fpc 550 16:14:16 geppetto: #550 (Darktable and Rawspeed internal library) – fpc - https://fedorahosted.org/fpc/ticket/550 16:14:16 https://fedorahosted.org/fpc/ticket/550 16:14:21 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 geppetto: I'm here as well 16:14:30 sgallagh: But people only take parts of gnulib 16:14:33 is there anywhere in the packaging guidelines that demonstrates a size requirement for copylib because i dont see it 16:14:33 #chair Rathann 16:14:33 Current chairs: Rathann geppetto orionp racor tibbs tomspur 16:14:39 Rathann: Ahh, sorry didn't see you 16:14:49 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 upstream authors are also authors of the said library 16:15:18 i would politely suggest everyone stop bombarding questions. there is literally no time to reply to any of them 16:15:29 adamw: Experience tells upstreams who say "this is copylib" often are clueless or just being lazy. 16:16:21 also, upstream themselves said they could make it a proper library, but have other priorities so patches welcome 16:16:25 #chair SmootherFrOgZ 16:16:25 Current chairs: Rathann SmootherFrOgZ geppetto orionp racor tibbs tomspur 16:16:29 racor: you should evaluate specific requests on their specific merits, not on some nebulous claim about 'past experience'. 16:16:35 racor, have you met the darktable authors? because i have, they are not clueless or lazy 16:17:00 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 Then my fiurst question to them would be why are you shipping a 30k copylib? 16:17:57 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 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 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 From reading the github discussion, I took away one reason is to ensure synchronized support for hardware 16:18:24 Rathann, how about the impact to users 16:18:28 I think the argument is that this cripples a spin.[ 16:18:33 Rathann, darktable has been in fedora for years 16:18:37 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 we have many users 16:18:40 It would be great if we could stop passing judgment on the character of upstream developers. :-) 16:19:04 geppetto: same here 16:19:06 removing darktable is going to likely break f22=>f23 upgrades for a user population that tends to be less technical (designers) 16:19:18 Rathann: The new information is the significant loss to (and likely, *of*) users due to this 16:19:22 We're primarily an engineering committee so some of that doesn't really get considered here. 16:19:24 or, it'll result in unupdated potential security issue laden software remianing on the F23 upgrade if it works 16:19:25 yes, let's just say that they place lower priority on unbundling than we do 16:19:43 Also, FESCo gets to override any FPC decision by the charter, so.... 16:19:46 mizmo: and that'd a good reason to change the vote, thank you 16:19:56 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 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 second meeting never even touched on it. 16:20:35 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 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 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 mizmo: With this argument we can simply stop with all unbundling effort and just push anything out there that is "used" 16:21:01 tibbs|w: Does that go to sgallagh proposal? 16:21:08 geppetto: I was initially proposing a temp exception 16:21:11 so yes 16:21:19 tomspur, no but thanks anyway 16:21:24 mizmo: what you say to me is populism. 16:21:29 2 releases-long is fine by me 16:21:29 tomspur: To be fair, I think this qualifies as more than just used. 16:21:45 racor, which appears to be exactly what "too big to fail" exceptions are for 16:21:48 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 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 jwb: Exactly, adopting this rule was a mistake. 16:22:20 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 geppetto: I don't read that this way above, sorry. 16:22:23 how about a temporary exemption until the guidelines which i have seen committee members admit they dont agree with are fixed? 16:22:39 tomspur: no problem … there is currently a wall of text 16:22:51 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 mizmo: The back ground of exceptions is to give all parties time to work things out. 16:23:05 geppetto and I are pretty much on the fence about this, but for different reasons. 16:23:09 wonderful, the future of fedora is we'll have 5 users 16:23:12 At least I think so. 16:23:13 mizmo: I just proposed that half a page up, although people might not have read it yet 16:23:16 mizmo, hyperbole won't help. 16:23:39 tibbs: I'm not on the fence, esp. for the tmp. exception 16:23:59 geppetto: Sorry if I mischaracterized. 16:24:02 no problem 16:24:28 Did you vote +1 originally? I can't recall the vote now. 16:24:30 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 So, anyway … for a tmp. exception I think we are at +3 … me, Rathann, tomspur? 16:24:51 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 racor: I've seen them as well and I understand the issue. 16:25:06 tibbs|w: which ticket are we on? 16:25:06 since i know the former was already considered last meeting 16:25:08 But I think we need a balance. 16:25:16 racor: It's 550: https://fedorahosted.org/fpc/ticket/550 16:25:43 Also, this question is a bit more complicated than "bundle or not". 16:25:54 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 geppetto: +1 on tmp exception 16:26:02 Because the thing folks would like to bundle also bundles something else. 16:26:23 doesn't the ticket say they took it out? 16:26:53 Does it? 16:27:03 tibbs: I'm also not sure that matters given the criteria we are exempting it under. 16:27:25 geppetto: True, my point was just that this is more cimplicated than it seems on the surface. 16:28:06 And as far as I can see, there's no mention of rawspeed having unbundled pugixml. 16:28:14 Ok, so we are at +4 for a 23/24 exception atm. 16:28:22 Yeh, I don't think it has 16:28:36 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 +1 for that exception in any case. 16:28:55 Ok, +5 16:28:56 stickster: OK, thanks. 16:29:06 orionp: racor: Want to vote for the recrod? 16:29:51 Also I wanted to say special thanks to Rathann for having the discussion with upstream *cordially* 16:30:01 stickster: you're welcome 16:30:04 :D 16:30:12 Yes, that has been very helpful. 16:30:18 I hope I managed to pour some oil on the troubled waters 16:30:27 ... 16:30:37 That must be an expression that didn't translate well into English. 16:30:47 I was thinking the exact same thing :) 16:30:54 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 So, look, a temporary exemption isn't a solution. 16:31:06 orionp: This is just for 23/24 atm/. 16:31:22 The solution doesn't lie with rawspeed/darktable/whatever. It lies with our guidelines. 16:31:28 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 There's an argument that the bundling rules, and specifically the ones surrounding copylibs are unclear. 16:32:12 Maybe, but we don't need to argue about that with a looming 23 and very unhappy design spin participants 16:32:30 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 Well, we need to discuss it eventually. 16:32:32 thank you 16:32:52 this was too short notice for the designers for sure 16:32:54 adamw: It's hard because the whole issue is hard. 16:33:22 mizmo: No problem, it wasn't clear how needed it was before. So sorry for the panic attacks 16:33:34 geppetto++ 16:33:34 mizmo: Karma for james changed to 1 (for the f22 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:34:04 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 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 tibbs|w, geppetto: I may have misremembered the idiom, sorry 16:34:59 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 tibbs|w: The issue is not that hard. 16:35:09 adamw - I'm afraid we don't just let upstream declare themselves a copylib. Sorry. 16:35:18 This is not gtk+ or qt or openssl, which already exist as standalone libraries. 16:35:18 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 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 Are we really going to say that people can't copy around random pieces of free software? 16:36:04 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 rishi: We already have. 16:36:19 adamw: Generally the size of things we'll take upstreams word on "this is a copylib" is like md5 16:36:46 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 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 s/we/they/ 16:37:05 There's no valid reason to piss people off at this point. 16:37:38 Yeh, it's already +5 there doesn't seem much point in discussing it more this week 16:37:48 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 we clearly haven't anticipated that someone would make a copylib of that size (or even larger like kwsys) 16:37:54 sorry, phone ring like crazy, trying to catch up. 16:38:57 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 adamw: The guidelines say "Some of the criteria are..." the final decision can be made here in the meeting. 16:39:12 That's the whole point behind my vote at least. 16:39:34 adamw: The rules aren't mean to be hard and fast … specifically so we aren't forced to do bad things 16:39:36 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 Lots of options, but yes, changing policy is one option. 16:40:35 adamw: the policy doesn't cover all corner cases 16:40:36 my vote on 550: -1, classical case of an upstream doing a poor job. 16:40:50 rawspeed and kwsys are such cases 16:40:54 orionp: Going to give you another minute, and then just action it, so we can move on. 16:41:06 I'm 0 16:41:09 ok, thanks 16:41:19 #action Temporary exception during 23/24 for Darktable, due to critical usage in Design spin (+1:5, 0:1, -1:1) 16:41:40 #topic #567 Packaging Python 3 applications and modules for EPEL 7+ 16:41:41 .fpc 567 16:41:41 https://fedorahosted.org/fpc/ticket/567 16:41:42 geppetto: #567 (Packaging Python 3 applications and modules for EPEL 7+) – fpc - https://fedorahosted.org/fpc/ticket/567 16:41:47 Do the various things that bundle this at least have the proper Provides: ? 16:41:53 so doesn't this mean we will have the same discussione again in one year? .... 16:42:19 drago01: Over the next year we will have more discussions, yes … but hopefully everyone will have a cooler head about it 16:42:24 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 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 ok fair enough ... I just prefer final decisions than to postpone it but works for now 16:43:36 Anyway … 16:43:42 * Rathann still holds to the hope that upstream or someone else will make rawspeed a proper library 16:43:48 orionp: You want to say anything about 567? 16:44:20 Rathann: Yeh, given they said they'll accept patches … that's another option 16:44:23 I suppose 16:44:52 EPEL would like to be able to support two concurrent python3 stacks 16:45:15 Packagers (me at least) would like to maintain the same spec in Fedora and EPEL7 16:45:49 rel-eng is waiting for FPC approval before allowing python-pkgversion-macros (name?) in buildroots 16:46:06 I think those are the salient points 16:47:04 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 right 16:48:15 Haven't checked in %python3_package anywhere yet, waiting for feedback 16:48:23 Current guidelines do annoyingly require that you paste the %description at least three times. 16:48:53 In my test cases I just did %global desc with some multiline thing, which is suboptimal but not really that bad. 16:48:56 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 That's kind of why I liked the macro. 16:49:28 I don't suppose you pinged any rpm devs. about having access to the description from lua? 16:49:42 I filed a bug.. 16:49:55 geppetto: Would be nice, but there's zero chance of that ever being able to actually help EPEL. 16:49:57 Ahh, cool … you know what it is? 16:50:05 tibbs: ahh, true 16:50:24 And the problem will go away on it's own for el8 16:50:52 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 I also filed http://rpm.org/ticket/894 fwiw 16:51:48 ah, I sent a message to the rpm list - nothing back though 16:52:08 ok 16:52:29 Might be worth saying what the value of %1 is … also should probably open a BZ 16:52:34 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 I'm not sure how much track is used for rpm.org 16:53:03 http://lists.rpm.org/pipermail/rpm-list/2015-September/001763.html 16:53:18 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 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 orionp: Did you want to update the draft with py3_package? 16:54:29 Fedora python packages will need to define enough macros to make things work. 16:54:36 tomspur: Yes, we've been talking about that. 16:54:53 tibbs|w: Was that last week? I wasn't there then. 16:54:53 tomspur: If you can do that without it looking like yuck, we would happily vote on that at some point 16:55:16 But I think at some point the rpmspecfile language needs to become an actual language for that to work. 16:55:19 tomspur: I'm definitely for that even though it does sort of straddle the line of hiding too much behind macros. 16:55:34 geppetto: That is a certainty. But we work with the RPM we have. 16:55:40 * geppetto nods 16:55:51 Yeah, there needs to be an opinion to disable non-working python versions for a package... :/ 16:57:45 That should be pretty unlikely with minor version changes, right? 16:58:04 Esp. as it's a tmp. thing to help upgrades, so the packager has to deal with it eventually 17:00:20 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 I'll work on an updated draft. put a link in the python guidelines to the epel7 specific guidelines 17:00:54 Ok, you want to wait another week then? 17:01:02 sure 17:01:22 ok 17:01:28 So - do we want a generic %py_package macro? 17:01:54 I'm happy for it to be called that 17:02:06 So whichever you'd prefer 17:02:21 I'm not sure it's possible actually 17:02:49 Well, maybe if everything really has a python2- provide/name 17:03:13 which it is suppose to now, so maybe 17:04:24 #action orionp Update draft, incl. py3_pkg etc. 17:04:40 #info Everyone mostly seems in favour of it for el7 optional 17:04:50 #topic #566 RPM file triggers 17:04:50 .fpc 566 17:04:50 https://fedorahosted.org/fpc/ticket/566 17:04:52 geppetto: #566 (RPM file triggers) – fpc - https://fedorahosted.org/fpc/ticket/566 17:05:11 Do we have anything to discuss here? 17:05:18 I've looked at it quite a bit 17:05:37 We need to keep track of which master packages have added the triggers, at least. 17:05:45 * geppetto nods 17:05:49 I saw that another one had done it recently but now I can't recall which it was. 17:06:12 interesting 17:06:14 Eventually we would like to bug the various maintainers to add them (glibc, especially). 17:06:16 i am quite irritated about the font-config guy having galopped ahead 17:06:25 Why? 17:07:00 Are you suggesting that we should have some guidelines in place first? 17:07:02 tibbs|w: Is their change 100% transparent on the rpm.spec level - AFAICT no 17:07:16 I don't know what you mean by "100% transparent". 17:07:35 It doesn't require packages to do anything, though they can drop their scriptlets if they like. 17:07:55 tibbs|w: More verbose: Does their change require any change on the rpm-spec level? 17:08:10 ... in other packages. 17:08:21 No. 17:08:29 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 In fact, it allows packages to remove things. 17:08:52 geppetto: Actually we don't really care where the trigger scripts go. RPM takes care of that. 17:09:51 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 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 Which package needs to be installed to trigger the e.g. gdk-pixbuf scripts? 17:10:24 I guess the main gdk-pixbuf2 package needs to be installed for RPM to "see" the triggers? 17:10:31 tomspur: Yes. 17:10:44 But it would necessarily be a dependency anyway. 17:11:04 Is it possible to move them to another package? 17:11:21 They can go in any package as long as it's in the dependency chain. 17:11:23 tomspur: Yes, but the triggers are run on package install/remove 17:11:27 Though I don't know why you would want to do that. 17:11:53 Technically the triggers are run whenever a package adds or removes something to/from the relevant directories. 17:12:22 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 I'm having trouble understanding how that would come about. 17:13:56 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 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 So glibc gains a trigger on /usr/lib /usr/lib64 etc. that runs ldconfig. 17:15:09 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 For right now, just think of what's on the ScriptletSnippets page. 17:16:24 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 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 tomspur: The only thing that matters is the dependency chain. 17:16:43 Sure it's a corner case, but basically that was what I had in mind above 17:16:53 Rathann: ok. Hopefully we should finish before then. 17:17:06 If somehow the dep chain will pull in the package containing the triggers, then things will happen as they should. 17:17:08 (or I didn't fully understand how the triggers are implemented in RPM) 17:19:00 It's actually pretty simple, but I misunderstood it for a while. 17:19:01 tomspur: If I understand your example correclty … then yes 17:19:18 ok, great 17:20:14 Are these triggers supposed to be "stateless". I mean do they rebuild "everything"? 17:21:16 They're supposed to be idempotent. No different than the scriptlets we have now. 17:21:39 racor: they are given the list of files that apply in the current transaction 17:21:40 package puts a file in /usr/lib64, that triggers ldconfig to run. 17:21:56 racor: But AFAIK all of them are simple and rebuild everything atm. 17:22:07 they can be once per package or once per transaction 17:22:26 right, that too 17:22:30 transaction ones are presumably more "stateless" 17:23:01 AFAIK it doesn't matter 17:23:05 OK, but we also have scriptlets, which work incremental. 17:23:10 they can still just trigger off the list of files. 17:23:34 The main difference is if the scriptlet will need to be run before any depending packages get installed 17:23:40 If so you can't do transaction level 17:25:40 ok, anything else we need to say about this? 17:25:52 At least until we get some draft or something? 17:26:35 Not really. 17:26:43 I have a few things 17:26:47 We just need to keep track of what packages add what triggers. 17:26:49 kalev: o 17:26:51 kalev: ok 17:27:00 first is that the new rpm just landed in F23 so it should be fine to use file triggers there too 17:27:10 And then update the various pages to note which scriptlets are unneeded in F23. 17:27:12 yeh, that's in the ticket 17:27:14 kalev: Yeah, that's in the ticket. 17:27:32 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 right now builders are on F21 and older rpm 17:28:08 Hmmm … ok, doesn't that happen automatically (so the f23 builders will now build with the new rpm)? 17:28:11 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 Ahh 17:28:25 Now that's interesting. 17:28:26 no, all builders are on F21 right now and mock uses host system's rpm 17:28:40 but releng said they are planning on updating the builders to F23 17:28:45 ok 17:28:50 so it shouldn't be an issue for long 17:29:15 another thing I had in mind is the icon theme rebuilding scripts 17:29:27 * kalev finds the scriptlet page. 17:29:40 https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache 17:30:04 so right now it does 'touch touch --no-create /usr/share/icons/hicolor' in %post 17:30:14 * geppetto nods 17:30:14 and then runs the actual rebuilding script in %posttrans 17:30:47 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 I haven't verified that yet 17:31:02 yeh, it's just a path prefix match AIUI 17:31:10 Yes, it's a string match. 17:31:11 Basically if path.startswith(foo) 17:31:24 cool, I guess then we can just have a file trigger that does the touch + gtk-update-icon-cache 17:31:38 and finally, last item: how are upgrades going to work 17:31:51 AIUI you can just have a trigger that does the update-icon-cache for the transaction 17:31:59 let's say someone is upgrading from F22 that has older gtk-update-icon-cache rpm, that has no file triggers 17:32:32 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 does the new, F23 gtk-update-icon-cache rpm's file triggers run in that case? 17:33:03 Yes. As the new rpm is installed, the triggers are run (due to file paths existing in installed packages) 17:33:08 or do we need to have a versioned dep in each package on the new F23 gtk-update-icon-cache rpm? 17:33:32 great :) 17:33:51 Also worth pointing out: 17:33:53 F23 will be kind of interesting in that respect. 17:33:53 https://wiki.mageia.org/en/RPM_filetriggers#Currently_supported_filetriggers 17:34:16 They jumped all over this. 17:34:32 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 Someone uses rpm5? 17:35:10 yeh, they were the one … but that was before the split 17:35:25 AIUI mageia is the one after the split that went back to non-rpm5 17:35:38 I can't keep track. 17:35:45 But they carried around a patch for file triggers for a bit, and are now very happy something got upstream :) 17:35:46 mageia was patching rpm to add file triggers support for quite some time, I believe 17:35:50 yep :) 17:36:08 anyway, all from me, just wanted to point out those few things :) 17:36:23 * geppetto nods … ok 17:36:27 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 I guess I'll add something else to my list. 17:36:51 it may not be a problem for some kinds of triggers 17:37:15 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 #info Builders are currently at F21, but should move to F23 soon … can't use them until then though. 17:37:29 True. I think even ldconfig is just a caching thing. 17:37:36 yeh 17:37:42 A lot are probably fine 17:37:52 But I'm sure there's one that'll break the world ;) 17:38:07 Anyway … anything else: 17:38:08 #topic Open Floor 17:41:57 * Rathann is back and reading the backlog 17:42:08 Ok … going to close in a minute or so. 17:42:18 Thanks for coming 17:45:08 #endmeeting