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