16:00:47 #startmeeting fpc 16:00:47 Meeting started Thu Oct 1 16:00:47 2015 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:47 #meetingname fpc 16:00:47 The meeting name has been set to 'fpc' 16:00:47 #topic Roll Call 16:01:02 geppetto limburgher mbooth orionp racor Rathann SmootherFr0gZ tibbs|w tomspur: FPC ping 16:01:08 hello 16:01:09 Howdy. 16:01:11 Hey 16:01:24 Trying to do a push to fix some CVEs in one of my packages. 16:01:31 #chair orionp 16:01:31 Current chairs: geppetto orionp 16:01:34 #chair tibbs 16:01:34 Current chairs: geppetto orionp tibbs 16:01:36 #chair mbooth 16:01:36 Current chairs: geppetto mbooth orionp tibbs 16:02:10 #chair racor 16:02:10 Current chairs: geppetto mbooth orionp racor tibbs 16:03:01 hi 16:03:04 * tomspur is here 16:03:05 #chair Rathann 16:03:05 Current chairs: Rathann geppetto mbooth orionp racor tibbs 16:03:09 #chair tomspur 16:03:09 Current chairs: Rathann geppetto mbooth orionp racor tibbs tomspur 16:03:24 Ok, almost everyone is ehre this week :) 16:03:31 #topic Schedule 16:03:37 https://lists.fedoraproject.org/pipermail/packaging/2015-September/011037.html 16:04:09 #topic #573 Clarify 'library bundling' guidelines, part 1: consolidate 'bundling' definition and clarify relationship between Guidelines sections 16:04:09 .fpc 573 16:04:09 https://fedorahosted.org/fpc/ticket/573 16:04:11 geppetto: #573 (Clarify 'library bundling' guidelines, part 1: consolidate 'bundling' definition and clarify relationship between Guidelines sections) – fpc - https://fedorahosted.org/fpc/ticket/573 16:04:20 This one seems like it might be easy 16:04:43 It looks good to me 16:06:00 Yeh, +1 16:06:01 Yes, as step 1 this is good. 16:06:02 +1. 16:06:23 I've always maintained that those guidelines aren't great as written. 16:06:37 +1 as well 16:06:45 Also, I've never been sure why we have three different places for bundling guidelines. 16:07:04 (except the last commenting out line of course) 16:07:16 +1 16:07:28 tomspur: ? 16:07:51 -1 - I don't see this clarifies anything. 16:08:06 +1 16:08:11 geppetto: It looks like the last line in the diff comments out the category of the guidelines 16:08:29 Yes, I would obviously leave that out when writing this up. 16:08:48 racor: Do you see it as more confusing? 16:08:48 Oh, yeh, I see it now 16:08:57 Yeh, I assume that was just for the draft 16:09:10 https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Packaging_Guidelines&diff=423213&oldid=423211 16:09:16 Son_Goku: Cute, but only FPC members get a vote :) 16:09:20 +1 from me 16:09:28 geppetto: oops 16:09:41 I’ll leave then 16:09:49 I keep forgetting stuff like that 16:09:54 Son_Goku: You can still talk 16:09:56 I am concerned about the second patch. 16:09:57 You are welcome to comment. 16:10:13 Just no voting 16:10:19 #action Clarify 'library bundling' guidelines, part 1 (+1:6, 0:0, -1:1) 16:10:33 #topic #569 texlive bundles lua 16:10:34 .fpc 569 16:10:34 https://fedorahosted.org/fpc/ticket/569 16:10:35 geppetto: #569 (texlive bundles lua) – fpc - https://fedorahosted.org/fpc/ticket/569 16:11:01 Looked like a +1 before and after orionp looked at this, it seems like a simple +1 16:11:01 IMO, it effectively carte-blanched bundling 16:11:51 It just links out to define what bundling is … instead of repeating it 16:11:54 I think lua is basically half-way to a copylib. It's intended to be an embeddable language. 16:12:34 can it at least be built from the same source as the currently packaged one? 16:12:36 tibbs|w: perhaps - but you can embed and extend in most cases without needing the internal source 16:12:37 So I think it should definitely be unbundled if possible, but when they make modifications they're kind of following the intent of the lua devs. 16:12:38 There is no mentioning of FPC and bundling exceptions anymore. 16:12:49 Rathann: no 16:13:54 racor: huh? … the bit that was removed doesn't say anything about FPC 16:14:32 geppetto: The old section was: "However, when this is unavoidable, packagers must apply for a Bundling Exception with the Fedora Packaging Committee. ..." 16:14:47 no such word in the new version 16:15:03 racor: Oh, that one … you see that's about fonts, right? 16:15:46 geppetto: No. Title is == Bundling of multiple projects == 16:15:56 The new text explicitly says for library stuff (the stuff we care about) they need to follow the library bundling process 16:17:39 Anyway … more votes for texlive to bundle lua? 16:17:42 Ok, I've read many times over the new text now, but I don't get what it means 16:18:26 I think we are at +2 (me and tibbs) … with a probable from orionp? 16:18:36 orionp: So it seems lua people did some change and don't care to upstream it? I don't understand their first sentence either 16:18:51 I'm like +.5 right now. 16:18:59 Hmmm, ok 16:20:09 I read the upstream discussion and it seems that they are a bit confused, but then so am I. 16:20:23 orionp: Do I understand correctly that they actually added new language features? 16:20:40 And not just extra functions, as you're kind of expected to do with lua? 16:20:42 I'm +1, barely. I'd be more tempted to suggest just dropping luatex from texlive if texlive wasn't such a bitch to work with 16:21:26 So you think it would be hard to remove it? 16:21:36 They overwrite 3 (at least) lua internal functions popen/read/lines 16:22:12 They also added functions 16:22:34 That latter part would port fairly easily 16:22:43 I know lua has a mechanism for adding functions without hacking its source. 16:22:56 I thought it also had a mechanism for overriding the builtins. 16:22:57 The first makes it completely tied to 5.2 16:23:53 0 from me at this point - there isn't enough information to vote either way IMHO 16:24:31 in particular, the standard questions are not answered completely 16:24:51 That's kind of true; I think folks are giving spot somewhat of a pass here. 16:25:07 And orionp is doing the legwork to get the necessary answers. 16:25:22 s/0/-1/ I mean 16:25:30 yeh 16:25:46 I don't have a problem with waiting for more info. 16:25:53 I'd say it might be "to small to care" from the number of users of luatex, but have no clue how upstream deals with security issues 16:26:42 luatex still seems to be at the research stage as well. I know we're supposed to be First, but... 16:27:21 well if they had plans to allow building against system lua then I'd be +1 16:27:41 I agree. But it seems they don't particularly care at the current state of development. 16:28:19 Has there ever been an actual CVE against Lua? 16:28:30 #action spot How hard is it to just remove luatex, as it seems very alpha at best? 16:28:39 Indeed there has been. 16:28:43 #action spot Can you answer the std. bundling questions? 16:28:53 http://www.cvedetails.com/cve/CVE-2014-5461/ 16:29:05 Anything else we want to ask for next week? 16:29:21 Would be fun to see how much of our bundled lua stuff still has that problem. 16:29:34 heh 16:29:42 "fun" 16:30:08 Things like this are a great argument for why FPC needs to at least talk about these things. 16:30:19 * geppetto nods 16:30:23 The current proposal before FESCo cuts FPC out of the loop entirely. 16:31:33 Yeh, well it's hard to see the downside until it's too late 16:32:01 * geppetto shrugs … atm. I've avoided wadding into the mess. If they screw it up, so be it 16:32:13 Since luatex uses 5.2.2 I suspect it is still vulnerable to that last CVE 16:32:26 We're not running space probes or nuclear reactors, so "too late" just means embarrassing compromises. 16:32:49 right, we get to learn from zlib all over again 16:32:54 Sometimes I wonder if a few folks need an object lesson. 16:32:59 Well, a more recent object lesson. 16:34:47 * geppetto shrug … on the other side debian seems to be doing more bundling than we do by default now … and they tend to be thought of as the strict packaging distro. 16:34:55 So maybe we're just old and wrong. 16:35:01 They're looser about licenses than we are, too. 16:35:01 Anyway … 16:35:35 #info Since luatex uses 5.2.2 we suspect it is still vulnerable to http://www.cvedetails.com/cve/CVE-2014-5461/ 16:35:49 #topic #558 Switch order of install macros 16:35:49 .fpc 558 16:35:49 https://fedorahosted.org/fpc/ticket/558 16:35:50 geppetto: #558 (Switch order of install macros) – fpc - https://fedorahosted.org/fpc/ticket/558 16:35:53 But folks are definitely right that the new wave of "just get it done like Apple because they're so great" github-using developers simply do not care at all. 16:36:06 * geppetto nods 16:36:27 I haven't made any changes to the draft in 558. 16:36:27 * racor sigh 16:36:39 Did we speak about it last week? 16:37:02 A couple of folks said they agreed with it but we didn't really discuss it. 16:37:08 * geppetto nods 16:37:27 Well … much people here this week … be good if everyone read it, might have some more comments 16:37:37 AFAIK we don't have anything else after this ticket 16:40:54 it'd be useful to have a real example there 16:41:24 +1 16:41:24 it speaks of perl and python packages but only mentions "example" and "example-libs" 16:41:28 Can you suggest one? I think it's too long already but it would probably be illustrative. 16:41:43 Drop: Note: be aware of erroneously generated Provides:; see the section on filtering. 16:42:49 couldn't the Provides: in an unsplit package be for the included binary in a primarily python-module package? 16:43:15 no just the other way around? 16:43:51 tibbs|w: Maybe whaawmp if the python module would actually be in use, so that it'd count as library? 16:44:26 I would write: If the executables or other non-library portions of a package have additional dependencies which are not necessary to simply make use of the library portions, the package should be split 16:45:36 Don't we already talk about splitting compiled code into -libs/-devel etc elsewhere? 16:47:19 We have a section about -devel, but I didn't see anything about -libs. 16:49:10 tibbs|w: Actually, we don't have a -libs packaging policy at all 16:49:28 That was my understanding as well.[ 16:49:51 tibbs|w: *-libs, *-docs are Debianisms ;) 16:50:05 Splitting them is kind of a necessity due to the conflicts that happen as soon as your package is multilibbed. 16:50:11 racor: doesn't debian use libfoo instead of foo-libs? 16:50:15 I dont' see how that's a debianism. 16:50:48 But we have no stricture on naming or anything like that. Hence people complaining that I used -libs instead of -lib. 16:50:54 I don't care but we should pick one. 16:51:30 Yeh, debian uses libfoo* 16:51:53 with major numbers too IIRC … which is a problem as they then have 666 packages that start with lib 16:52:16 And we have similar problems … so I'd much prefer *-lib or *-libs … don't really care which 16:53:08 -libs seems more popular, let's use that 16:53:51 fine by me 16:55:05 Anything else? 16:55:10 Rathann: Yep, but that's not my point. The point is deb has problems with handling apps/docs in multilib'ed packages. Therefore they generally enforce a strict apps/libs/docs/... separation 16:55:47 ok 16:56:02 rpm resorts to implicitly ignoring apps/docs in multilib'ed packages 16:56:12 Obviously I need to give this at least two more passes for grammar and concision. 16:56:48 tibbs|w: did you consider adding something about "arched" doc packages? 16:57:08 And add some examples, and figure out where to put it, and then make sure all of the other guidelines are clear about what applies to "modules" and what applies generally. 16:57:23 I did not consider doc packages at all; I'm not sure they're relevant. 16:57:40 tibbs|w: Though docs should be noarch'ed, I found many arch'ed doc packages. 16:58:02 OK, but this is about libraries/modules/applications. 16:58:13 Feel free to draft something about doc packages. 16:58:14 tibbs|w: /usr/share/doc .... arched packages? 17:01:33 Ok … 17:01:38 #topic Open Floor 17:01:46 Anything anyone wants to talk about? 17:02:12 Didn't we have EPEL7 python stuff still? 17:02:34 Yes. 17:02:51 Currently I think that those guidelines should go into EPEL. 17:02:52 Yeh, but nothing had changed on it 17:02:56 we're hung up waiting on that before getting python3 stuff into EPEL 17:03:15 If that stuff gets into Fedora then it will just get into Fedora and we'll have crappy packages again. 17:03:31 At some point we can try to get some better macros in to clean this stuff up. 17:03:42 #topic #567 Packaging Python 3 applications and modules for EPEL 7+ 17:03:42 .fpc 567 17:03:42 https://fedorahosted.org/fpc/ticket/567 17:03:45 geppetto: #567 (Packaging Python 3 applications and modules for EPEL 7+) – fpc - https://fedorahosted.org/fpc/ticket/567 17:03:49 I've been playing with it as I find the time but I have a lot to learn about rpm macros. 17:04:12 orionp: So you want us to vote on the changes in comment 10? 17:05:01 wiki just went down? 17:05:13 works for me here 17:05:23 dito 17:05:41 I get a service is unavailable clicking on https://fedoraproject.org/w/index.php?title=PackagingDrafts%3APython&diff=cur&oldid=422445 17:06:39 Try again, I guess. Occasionally you get a bad proxy. 17:07:03 now it's working 17:07:14 And I don't think the %py_package macro is ready at the moment. 17:08:21 But conceptually I think the idea is sound even though it does hide a whole bunch of stuff. 17:09:09 Yeh, I'm like +0.5 atm 17:09:13 I don't have a problem with the stuff it hides even though I normally advocate for more transparency. 17:09:44 But I'm working through some alternate macros. 17:09:52 If %py_package creates all possible subpackages, should %py_build also build all packages in one step? 17:09:56 The thing is, at this point I'm not sure why the EPEL7 stuff is held up. 17:10:04 tomspur: I've been going back and forth with that. 17:10:42 The "raw, no pretty macros" guidelines are fine for EPEL and should be written into their guidelines if they haven't already. 17:11:11 I know I said I didn't want that stuff leaking into Fedora, but after looking at the horrible state of some python specs I think that's a pointless battle. 17:11:12 tibbs|w: As I understand it, we need to get some macros (like %python3_pkgversion into the epel buildroots - and releng wants FPC signoff before doing that 17:11:33 I don't get why releng wants FPC approval for EPEL things. 17:11:44 Ok, so do we want to vote on this as is now … on the assumption it'll change a bit? 17:11:46 Since FPC doesn't really control EPEL guidelines. 17:12:10 Or do we want a minimal change that we can vote on for rel-eng to do their thing, and we can vote on the full policy later? 17:12:12 Well, I would like to see if folks agree conceptually to hiding that much behind macros. 17:12:27 I'm fine with it 17:12:29 https://bugzilla.redhat.com/show_bug.cgi?id=1248040 17:12:32 But at this point I would basically +1 the original proposal. 17:12:45 on the Fedora side 17:13:01 Oh, well, the Fedora side. That's a whole other animal. 17:13:35 I don't understand why this alone is a different macro package, though. 17:13:54 I mean, the existing python macros aren't even in the buildroot. 17:14:08 And we worked around that, so why does this matter? Just depend on the package. 17:14:26 I guess I'm not getting the whole point here. 17:14:42 tibbs|w: it's not hiding too much, so I'd be ok with that 17:15:53 Putting them into epel-rpm-macros would have made more sense to me 17:16:45 tomspur: You mean only there? AIUI orionp wants the same spec in both EPEL and Fedora, for packages he's maintaining 17:17:01 Sometimes life intervenes. 17:17:34 tomspur: that's where they are in epel 17:19:01 geppetto: I guess we would have them then also in Fedora and not just in epel7 17:20:14 orionp: Then I don't understand the python3-pkgversion-macros package 17:21:04 We really just need python3-macros in Fedora. We can even get that into the buildroot so that all specs can assume their existence without conditionalizing. 17:21:10 To add %python3_pkgversion to Fedora 17:21:13 But this I don't get. 17:21:50 I'd be happy to see python3-pkgversion-macros merged with a python3-macros package 17:21:53 It seems we are trying to leave the macros only in epel7 so that we don't need to vote over the %python3_pkgversion macro. And now we don't vote on it and get it added to Fedora? 17:24:18 I thought the discussion was so that we could vote on something, so that rel-eng can let EPEL go forward with things 17:25:20 orionp: What do you want to vote on today? 17:25:54 Really all I'm getting here is that nothing is holding up py3 in el7. 17:26:29 I would like to vote on allowing %python3_pkgversion to be define in the Fedora buildroot - how that is done I don't care 17:26:30 It's just that it's been set up so that those specs simply won't work in Fedora unless Fedora changes something. 17:26:41 tibbs|w: you are correct 17:26:54 That isn't what was stated earlier. 17:27:01 I'm 100% +1 on adding a new macro to help out EPEL 17:27:15 Are there any objections? 17:27:21 I don't have a problem either. But I've no idea why this needs to be in the buildroot when the actual python macros aren't in the buildroot. 17:27:41 The python folks could just go ahead and add that macro at any time. I'm not sure why we're even talking about it. 17:27:42 Packages can BR python%{python3_pkgversion}-devel 17:28:12 I think that needs to be in the buildroot then 17:28:21 tibbs: Maybe us voting +1 will help everything move along, and it can't hurt anything 17:28:40 No, that's true; it's just another thing about this that wasn't really thought out well. 17:28:59 So, would folks be amenable to having all of the python macros in the buildroot? 17:29:25 Is there any good reason not to have them? 17:29:30 * tomspur would like to avoid such macros on fedora if possible :/ 17:29:44 tomspur: Sorry, which macros are "such macros"? 17:29:44 tomspur: Including %python3_pkgversion ? 17:29:53 yes 17:30:10 Because if we can assume that all of the necessary python macros are in the buildroot, then that really simplifies a lot of the packaging. 17:30:32 Sure, +1 then 17:31:40 tibbs|w: Weren't you saying that this macro does complicate python packaging for fedora? 17:31:53 So if it is epel only it is just fine 17:32:08 tomspur: That's only if it's used 17:32:13 tomspur: It being defined is fine. 17:32:19 geppetto: it will be :) 17:32:25 Well, used by everyone 17:33:34 And it's not really complicate packaging … as we didn't want to force it on people who wouldn't want to use it anyway … IIRC/AIUI 17:33:55 Just as an aside: these packaging complexities really do hurt contributions. I tried to make a PHP pecl package the other day so I copied one of Remi's specs (figuring that he's the master). It had so much extraneous macro crap that I couldn't figure out what was actually going on. 17:34:06 tomspur: Does that change your opinion of %python3_pkgversion being in Fedora, and/or all of the other macros? 17:34:25 Anyway, I don't really care what's defined. 17:34:42 I don't think we should change the existing python guidelines to mention that macro, though. 17:34:47 tomspur: Being defined, that is 17:35:02 Just another thing that folks who don't know the whole story will get to trip over. 17:35:13 That people think this is a good thing baffles me. 17:35:16 That's fine, I think … as long as orionp has something to show rel-eng … can just point to this vote 17:35:23 tibbs|w: it's not in my draft, only in the epel guidelines 17:35:26 But I'm not going to stand against it. 17:36:26 mbooth: racor: Rathann: You want to vote on including all the macros in Feodra, even if they are only used in EPEL … and/or just including %python3_pkgversion in Fedora? 17:36:26 I think that the py_package macro is a much better route and %python3_pkgversion can be avoided on epel too. Furthermore it benefits Fedora and epel. If waiting a bit on the %py_package would simplify packaging I'd wait for it 17:36:46 Proposal: Merge python3-pkgversion-macros and python-macros into a separate python-macros package with python3_pkgversion defined and allow it in the buildroot 17:37:10 +1 17:37:13 But for actually seeing/deciding if the py_package can avoid all the other python3 specifics on epel, I know to less about epel 17:39:12 0. Sorry orionp 17:39:36 +1 for the record. 17:39:46 mbooth: racor: Rathann: vite? 17:39:50 +1 from me 17:39:51 okay, I'd be happy to move forward with %py_package instead, but that seems to be stalled 17:40:40 Well, only need 1 more +1 from mbooth or racor 17:41:32 For now I think we should just do this one package, until we can get a separate python macros sorted and then it can define the macro appropriately. 17:41:45 If that made any sense at all. 17:42:07 mbooth: racor: vote? 17:42:39 tibbs|w: I thought it might be easier to only muck with the buildroots once, but either way 17:43:01 Well, hopefully releng won't kill us. I've no idea how easy it is to change the buildroots. 17:43:45 We've known for a long time that sorting out all of the python macros was going to take some time. 17:43:54 I'd hoped it wouldn't take this long, but.... 17:46:30 +1 17:46:46 #action Merge python3-pkgversion-macros and python-macros into a separate python-macros package with python3_pkgversion defined and allow it in the buildroot (+1:5, 0:1, -1:0) 17:46:50 Ok 17:46:59 #topic Open Floor 17:47:16 geppetto: Any luck on the triggers? 17:47:53 tibbs: It's mostly progressing on it's own … from my last update. Mostly on the desktop side. 17:48:05 Yeah. 17:48:14 I'm on holiday for a bit, so probably nothing from me until after the next meeting 17:48:16 Do you know of an easy way to test them? 17:48:22 Ah, didn't realize you were away. 17:49:03 I would like to try them with texlive but I don't want to get into a big test/rebuild cycle given the immense size of that POS. 17:49:32 Not really … I'm mostly assuming that rpm works … so it's just a matter of "can you run the script N times" and "does everything work before the script is run" 17:49:42 * geppetto nods 17:50:33 I think the best thing is probably core packages adding a Provide … and then leaf packages can Require that provide as they remove their scriptlets 17:50:47 But nobody has done anything like that atm. AFAIK 17:51:48 Oh, I see what you're saying. 17:51:56 Provides: foo-scriptlets 17:52:05 Yeh 17:52:20 Instead of having packages trying to depend on the exact release where the scriptlets went in. 17:52:20 Well foo-filetriggers, I guess 17:52:25 Yeh 17:52:26 Either way. 17:52:31 I have to drop off now 17:52:32 * geppetto nods 17:52:34 sorry guys 17:52:37 This kind of thing does need guidelines. 17:52:39 Rathann: Ok, I think we are mostly done anyway 17:52:42 bye 17:52:44 * geppetto nods 17:52:45 Take care. 17:52:54 I'll try to draft something in my copious spare time. 17:53:15 Yeh, it's on my TODO list too 17:53:30 so which one of us wins, wins ;) 17:54:39 Indeed. 17:54:39 Ok, going to close in a minute 17:54:47 Everyone enjoy lunch, etc. :) 17:54:49 Thanks. for running as usual. 17:54:57 no problem 17:55:34 #endmeeting