16:00:26 <geppetto> #startmeeting fpc
16:00:26 <zodbot> Meeting started Thu Sep  3 16:00:26 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:26 <geppetto> #meetingname fpc
16:00:26 <zodbot> The meeting name has been set to 'fpc'
16:00:26 <geppetto> #topic Roll Call
16:00:30 <tibbs|w> Howdy.
16:00:36 <geppetto> #chair tibbs
16:00:36 <zodbot> Current chairs: geppetto tibbs
16:00:39 <geppetto> #chair mbooth
16:00:39 <zodbot> Current chairs: geppetto mbooth tibbs
16:00:45 <tibbs|w> Sorry, I'm mostly useless this week.
16:00:52 <geppetto> tibbs: Isn't that true of all types of users :)
16:00:55 <orionp> Morning
16:01:01 <geppetto> #chair orionp
16:01:01 <zodbot> Current chairs: geppetto mbooth orionp tibbs
16:02:27 <tibbs|w> Have been trying to work on a draft for the distinction between applications and libraries/modules and when they should be split, but it's not done.
16:03:00 * geppetto nods
16:04:06 <geppetto> limburgher racor Rathann SmootherFr0gZ: FPC ping
16:04:17 * racor is here
16:04:31 <geppetto> #chair racor
16:04:31 <zodbot> Current chairs: geppetto mbooth orionp racor tibbs
16:04:46 <geppetto> Ok, that's five … I'll give the others another minute or so
16:06:05 <geppetto> #topic Schedule
16:06:08 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-September/010958.html
16:06:17 <geppetto> #topic #562 	Bundling exception for MongoDB
16:06:17 <geppetto> .fpc 562
16:06:17 <geppetto> https://fedorahosted.org/fpc/ticket/562
16:06:20 <zodbot> geppetto: #562 (Bundling exception for MongoDB) – fpc - https://fedorahosted.org/fpc/ticket/562
16:07:28 <geppetto> this is blah … I'm +1 for a temp. exception while upstream works out if they are going to just ship it as part of mongo, or if they'll unbundle it again
16:07:59 <geppetto> As tibbs would say "Software engineering, have you heard of it" :)
16:08:26 <tibbs|w> I kid of agree, but then I wonder why nobody has bothered to answer the question I asked in the ticket.
16:08:36 <orionp> It seemed like upstream was pretty adamant about not unbundling it - we're special and not wanting to do work that benefits anyone else and all that
16:10:07 <Rathann> hi
16:10:11 <tibbs|w> That was the impression I got from upstream as well.
16:10:12 <geppetto> #chair Rathann
16:10:12 <zodbot> Current chairs: Rathann geppetto mbooth orionp racor tibbs
16:10:28 <mbooth> "Don't you have to solve this problem for other open source projects?" lol
16:10:28 <geppetto> Yeh, but then they might go all the way and stop shipping it outside mongoDB
16:10:29 <tibbs|w> Well, from reading the upstream discussion.  They just don't care about the bundling thing at all.
16:10:43 <mbooth> We totally have the man-power to solve all the world's problems...
16:11:16 <racor> what makes me nervous about bundling is the fact mongodb currently is still F23FTBFS-ing
16:11:22 <tibbs|w> We only have to solve the problem for other open source projects which don't understand software engineering.
16:11:44 <tibbs|w> Do we know that the failure to build isn't related to the packager's attempts to unbundle?
16:12:02 <tibbs|w> I though that was what precipitated the request.  But maybe not.
16:12:46 <tibbs|w> I would suggest that the ticket submitter answer my question and any others that folks here might pose, and then let us know when the thing is actually building.
16:12:55 <racor> tibbs|w: I know close to nothing about mongodb, but FTBFSs due to testsuite failures, let me have doubts on a code-basis quality.
16:12:57 <tibbs|w> Or is there any point in waiting for it to build?
16:13:06 <orionp> Yeah, I think the testsuite is failing because the wiredtiger versions are different
16:13:20 <tibbs|w> Doubts about the quality of upstream code bases aren't exactly rare around here, bundling or not.
16:13:33 <geppetto> indeed
16:15:24 <geppetto> Can someone run a quick repoquery to see what else require WT in rawhide?
16:15:27 <tibbs|w> So what to do?  I don't think we can get to +5 today.
16:15:28 <orionp> Since nothing else seems to use wiredtiger in Fedora, can we just ship mongodb's version?
16:15:49 <geppetto> Yeh, pretty much what I was thinking orionp
16:16:06 <tibbs|w> That's what I suggested in the ticket as well.
16:16:24 <tibbs|w> At least, I have a vague memory of doing so.
16:17:15 <orionp> " There's an alternate solution which involves simply packaging the upstream mongodb-3.0 branch of WT, but I'm not sure that this actually helps"
16:17:29 <tibbs|w> So, anyway, I'm not inclined to +1 this until the submitter responds to my comments in the ticket.
16:17:36 <geppetto> #action Need answer to tibbs question about permanence of this bundling.
16:18:12 <orionp> and recommend packaging mondodb version of wiredtiger for now
16:18:15 <geppetto> #action Do we know of anything else that uses WT, as other wise it seems pretty simple to remote WT and make it a sub-package of mongoDB and just ship whatever they ship.
16:18:41 <geppetto> #action Please fix the FTBFS for mongoDB, as this also seems related.
16:18:47 <Rathann> upstream just doesn't understand: https://groups.google.com/d/msg/mongodb-dev/31FQSo4KVCI/szupz-c5IwAJ
16:18:55 <orionp> I think I'd keep wiredtiger as a separate package.
16:20:17 <tibbs|w> I had the thought that doing that might actually hurt us security wise.
16:20:31 <tibbs|w> Because it's extra work to pull that code out and get it packaged separately.
16:20:48 <tibbs|w> But that would be up to the maintainer in any case.  I don't know the internals of the packaging.
16:21:04 <tibbs|w> And since the maintainer hasn't commented on the feasibility of doing any of that....
16:21:27 <Rathann> also, what are the changes between latest WT release and what's bundled in MongoDB?
16:21:28 <geppetto> yeh, it seems like anyone not mongoDB who wants to use WT needs to make the upstream not be a bunch of idiots first
16:21:47 <orionp> It looks like the wiredtiger repo has a mongodb-3 branch - just package that
16:21:50 <geppetto> So just pretending it's part of the giant ball of mud within mongoDB seems like the path of least resistence
16:22:14 <tibbs|w> I wouldn't have a problem if this was just a situation where they needed to engineer things quickly and developing them in lock-step for a while made sense.
16:22:37 <tibbs|w> But it doesn't make much sense to do it for their stable releases.  Especially for something like a database server.
16:22:59 <geppetto> it seems more like it's an "it's easier for us" type thing
16:23:39 <geppetto> don't need to test for ABI changes, or do real QA
16:24:14 <geppetto> Anyway, we've got actions … can move on.
16:24:29 <geppetto> #topic #564 	Bundling exception for apacheds-jdbm
16:24:29 <geppetto> .fpc 564
16:24:29 <geppetto> https://fedorahosted.org/fpc/ticket/564
16:24:30 <zodbot> geppetto: #564 (Bundling exception for apacheds-jdbm) – fpc - https://fedorahosted.org/fpc/ticket/564
16:25:50 <geppetto> the last 3 questions seem like the answer is easy, but the description of upstream having changed too is weird
16:26:16 <Rathann> looks like only temporary until apacheDS switches to mavibot?
16:26:30 <geppetto> yeh
16:26:40 <geppetto> but they said "distant" there
16:27:01 <tibbs|w> So much Java bundling....
16:27:20 <geppetto> indeed
16:27:29 <Rathann> meh the attached diff is done without -wbB options
16:27:36 <Rathann> so it's unreadable
16:30:26 <geppetto> #action Given you said the changes are good for everyone, and the forked version could be canonical. Can you speak to the Fedora maintainer about doing that?
16:31:04 <geppetto> Anyone want to say anything else?
16:31:26 <tibbs|w> Not me.
16:31:26 <mbooth> No, agree with that action.
16:31:27 <orionp> There is no fedora maintainer of jdbm
16:31:33 <orionp> It was retired
16:31:50 <geppetto> #undo
16:31:50 <zodbot> Removing item from minutes: ACTION by geppetto at 16:30:26 : Given you said the changes are good for everyone, and the forked version could be canonical. Can you speak to the Fedora maintainer about doing that?
16:31:54 <tibbs|w> Then won't these packages disappear anyway?
16:32:11 <geppetto> #action Given you said the changes are good for everyone, and the forked version could be canonical. Can you become the Fedora maintainer and use your version?
16:32:21 <mbooth> So even easier for apache-jdbm to become the canonical version of jdbm
16:32:29 <geppetto> yeh
16:32:29 <tibbs|w> Well, I guess they don't care if the library is bundled.
16:32:29 <mbooth> Just package rename
16:32:29 <tibbs|w> But indeed.
16:32:59 <geppetto> Ok, now for a "fun" one:
16:33:01 <geppetto> #topic #567 	Packaging Python 3 applications and modules for EPEL 7+
16:33:02 <geppetto> .fpc 567
16:33:02 <geppetto> https://fedorahosted.org/fpc/ticket/567
16:33:03 <zodbot> geppetto: #567 (Packaging Python 3 applications and modules for EPEL 7+) – fpc - https://fedorahosted.org/fpc/ticket/567
16:33:30 <geppetto> So, I think we can solve this with a cage match of tibbs vs. orionp ;)
16:34:03 <tibbs|w> I haven't had a chance to read the updated spec anyway.
16:34:44 <geppetto> it's just the example that changed
16:34:47 <geppetto> https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3&diff=421403&oldid=405371
16:34:48 <tibbs|w> So I'm still a bit confused.
16:35:13 <tibbs|w> I am getting two incompatible impressions from all of this:
16:35:38 <tibbs|w> EPEL will have multuiple different python3 versions.
16:36:13 <tibbs|w> Or: EPEL will have exactly two different python3 versions only for the purpose of easing the transition to the newest version.
16:36:58 <orionp> My understanding is the latter
16:37:19 <tibbs|w> And I think that's not everyone's understanding.
16:37:30 <orionp> And will not always have two
16:37:37 <orionp> sometimes will only have one
16:37:46 <orionp> (like now)
16:38:00 <Rathann> regarding #564 I've just took a look at the diff and the changes don't seem that huge, so +1 to making the fork the canonical version of jdbm
16:38:44 <orionp> But I'm not sure what makes the two impressions incompatible
16:39:01 <orionp> with multiple <= 2
16:39:30 <tibbs|w> I just didn't phrase it particularly well.
16:40:23 <tibbs|w> Anyway, with this cleaned up, it's obviously not too bad.
16:41:08 <tibbs|w> But with careful definition of the %py3_other* and __python3_other macros (to /bin/true) you could get rid of some ifdefs....
16:41:27 <orionp> The main funkiness in replacing "python3" with "python%{python3_pkgversion}"
16:41:50 <tibbs|w> Yeah, that's not enjoyable.
16:41:50 <orionp> Yeah, I was wondering about that
16:42:17 <tibbs|w> I wasn't really joking when I suggest replacing the %package/%description blocks with a macro, either.
16:43:24 <orionp> That would be nice if possible
16:43:26 <geppetto> as an optional thing for EPEL only, I'm probably +1 on it
16:44:21 <geppetto> But I can't help but think that we should solve the transition problem some other way, and only ever need 1 version of py3 in epel
16:44:33 <orionp> geppetto - I'm sure I know what that means - ie. personally I would maintain the same spec in Fedora and EPEL - would you not allow that?
16:44:34 <tibbs|w> Oh, I'm +1 on it if it doesn't make it into Fedora; it's all pretty reasonable.  But it's already made it into Fedora.
16:44:47 <tibbs|w> People are using this now.
16:44:56 <geppetto> makes everyone else's life easier … just some pain for someone(people) to do group rebuilds whenever a new minor version comes out.
16:45:07 <tibbs|w> Does EPEL not have side tags?
16:45:38 <geppetto> orionp: That would kind of suck :( … is it really a big hit to not be able to share the specfiles?
16:45:44 <tibbs|w> I mean, we could keep two versions of boost around for exactly the same reason.
16:45:45 <orionp> I don't know, I don't see why they couldn't have side tags
16:45:57 <tibbs|w> But we don't, because we just handle things.
16:46:22 <orionp> tibbs|w - time frame is a *LOT* longer in EPEL....
16:46:32 <tibbs|w> I don't see how.
16:46:41 <orionp> and we have multiple versions of lots of things in EPEL because of it
16:46:50 <geppetto> We do?
16:47:04 <tibbs|w> I think that people are just afraid of any python3 version transition because of how badly they screwed up the change to python3.
16:47:27 <orionp> e.g. zabbix (2.0), zabbix22, zabbix24, etc.
16:48:17 <geppetto> Hmmm … I also see 3 compat-* packages
16:48:42 <geppetto> I didn't think we did multiversions that much more … but I'm not sure how to see that easily.
16:48:43 <orionp> You're also dealing with users who want stability and to manage transitions on their own schedule, while epel is essentially a rolling release
16:50:01 <tibbs|w> See, I love compat packages.  Because they make the separation obvious.
16:51:38 <tibbs|w> Anyway, can folks try to clean up a few ifdefs, and maybe I'll see if people could stomach a macro to generate teh %package and %description statements.  Too bad tomspur isn't able to be here today; he knows more about that than I do.
16:55:06 <orionp> Oh, geppetto - yeah it's really nice just merge from master/f# to epel7
16:55:27 * geppetto nods
16:56:17 <orionp> but there are going to be a lot of python3 epel only packages -  all python packages that are already in RHEL7
16:56:22 <geppetto> You don't have to manually merge the specfiles anyway, due to changelog etc.?
16:56:53 * geppetto nods
16:56:58 <orionp> I don't give a #*$ about the changelog  (at least the rebuilt for ....)
16:57:30 <tibbs|w> I do understand.
16:58:23 <tibbs|w> I just think that in the general case people do more work maintaining specs for all of these old releases than it takes to just keep them separate.
16:58:41 <orionp> but merges would work for that - it wouldn't work for propagating changes from python3 files, etc to python3 (other)
16:58:46 <tibbs|w> But EL7 isn't all that bad (though it's soon going to get annoying again with %filetrigger.
16:59:17 <tibbs|w> Anyway, if the purpose is to ease the transition, then shouldn't these things only be added when we know the transition is going to be difficult?
17:00:03 <geppetto> meh, I can understand the desire not to have a huge number of updates when py3.6 hits
17:00:05 <tibbs|w> I mean, the majority of packages won't need to care about py35 differences.
17:00:21 <geppetto> I thought that too
17:00:26 <orionp> Possibly.  At the moment there is no need to add the %python3_other* stuff as we don't have one
17:00:36 <tibbs|w> Well people have already done so.
17:00:39 <geppetto> But orion implied most py3 packages in epel would need minor versions
17:01:08 <orionp> but we do need %python3_pkgversion now if we want to support that later
17:02:39 <tibbs|w> If done right, you don't.
17:02:49 <tibbs|w> python3 should be the latest you support.
17:03:01 <tibbs|w> python34 would appear at some later date.
17:04:13 <mbooth> Sorry, I have to duck out early today
17:04:28 <orionp> I don't see how that would work with provides/obsoletes/etc
17:04:40 <tibbs|w> But it wouldn't matter if %package was macro-generated.  I'll just have to see if that works (I know it does for debuginfo) and if people would actually accept it.
17:04:50 <tibbs|w> orionp: Well it's how every compat package works now....
17:05:16 <orionp> you'd want python3-foo-1  ->  python34-foo-1 and python3-foo-1(for python35)
17:05:18 <tibbs|w> I'm thinking that this hasn't been thought all the way through particularly well and someone just tossed the first pass over the fence at us.
17:05:49 <orionp> I'm a bit upset with that characterization.  there was a fair amount of discussion in epel
17:06:00 <tibbs|w> Well, that's certainly what it feels like.
17:06:26 <tibbs|w> Plus, it seems at the same time we're doing all of this closely related work and nobody thought to even mention it.
17:07:26 <orionp> Yeah, that was not so good - probably not helped by the transition in the python maintainers
17:07:42 <geppetto> mbooth: Ok, in theory these meetings are only an hour long … so not that early :)
17:08:48 <tibbs|w> Theory has matched practise about once in the past few years....
17:08:54 <geppetto> orionp: I don't think that split requires pkgversion usage before it happens.
17:08:59 <geppetto> tibbs: :)
17:09:14 <orionp> python3_pkgversion = 34 in epel
17:09:21 <orionp> 3 in Fedora
17:09:21 <geppetto> right now?
17:09:37 <orionp> it should
17:09:55 <geppetto> huh … I assumed it was still 3 atm.
17:10:01 <tibbs|w> Does something at least provide python3?
17:10:16 <tibbs|w> Because otherwise I need to edit out mention of EL7 from the Fedora guidelines completely.
17:10:17 <orionp> yes, I believe python34 should
17:10:47 <geppetto> So the example package on current epel will only build python34-blah packages, right?
17:10:56 <orionp> right
17:11:13 <orionp> later it would build python34- and python35-
17:11:17 <geppetto> So how do the python3-foo packages get built?
17:11:25 <orionp> they don't
17:11:26 <geppetto> they don't from the example?
17:11:29 <geppetto> ok
17:12:09 <tibbs|w> But if you use the Fedora guidelines then what happens?
17:12:17 <geppetto> you get python3-foo
17:12:24 <tibbs|w> Yes, of course.
17:12:34 <tibbs|w> But is that actually useful?
17:12:49 <tibbs|w> I mean, EPEL packages are going to need different dependencies, too.
17:12:55 <geppetto> ¯\_(ツ)_/¯
17:13:15 <tibbs|w> And they'd have to know if they need to require python3-foo or python34-foo.
17:14:15 <orionp> hence the 3 -> %python3_pkgversion
17:14:39 <tibbs|w> My point is that we're not going to put that into the Fedora guidelines.  (Or at least I wouldn't vote for it.)
17:15:36 <tibbs|w> And EPEL kind of benefits from having an easy transition from a Fedora package to an EPEL package.
17:16:22 <tibbs|w> I mean, currently I have a python package that I have built for EL7 because the spec just works, but I'll probably just drop it if I can't do that.
17:16:54 <tibbs|w> But that's kind of offtopic.  I don't have any opinion on what EPEL packages do on their own branches.
17:20:31 <geppetto> Yeh, but as orionp said … people will want to share specfiles
17:20:38 <geppetto> to allow git merge
17:21:16 <geppetto> Which … meh. Really need better merge tool than git merge, but what can you do.
17:21:20 <tibbs|w> My point is that before this they could just do that without worrying about it.  The specs needed 0 changes.
17:21:29 <tibbs|w> Now, oops.
17:21:56 * geppetto nods
17:21:56 <tibbs|w> Which is still fine, people would just have to go and read some more guidelines pages and hopefully they get it all right.
17:23:19 <geppetto> So … do we have any actions for this, for next week?
17:23:41 <tibbs|w> Hopefully I can find some time to find a way to hide most of this.
17:24:19 <tibbs|w> If I can pull together a full day to work on FPC work then I should be able to produce something by next week.
17:24:25 <tibbs|w> We're not on a deadline, are we?
17:24:41 <geppetto> #action tibbs Find a way to hide the differences between Fedora/EPEL in an updated draft
17:24:42 <geppetto> ?
17:24:52 <geppetto> I don't think so … 3.5 isn't due anytime oon AFAIK
17:25:23 <tibbs|w> If it was, then we really wouldn't need to care about this until 3.6.
17:25:28 <geppetto> Ugh … maybe it is:
17:25:29 <geppetto> https://www.python.org/dev/peps/pep-0478/
17:25:44 <tibbs|w> Because there are only... 0 python modules in EL7 right now.
17:25:47 <geppetto> lol, 10 days from now 3.5 final
17:25:50 <orionp> If we're going to support the transition as currently planned now, we need to build python34- packages not python3-
17:26:31 <tibbs|w> So really, EPEL should just deal with the 35 transition.
17:26:41 <tibbs|w> And let this come up for the 36 transition.
17:27:05 <tibbs|w> OK, there's one python3 thing in EPEL: python3-pkgversion-macros-1-3.el7.noarch.rpm
17:27:14 <tibbs|w> Which I don't believe is a module anyway.
17:27:24 <tibbs|w> Otherwise there's just the base python34 package.
17:28:10 <orionp> yeah, we're waiting for this
17:30:04 <geppetto> #info py3.5 released in 10 days (13th Sept), so this is more aimed. at the 3.5 => 3.6 transition
17:30:15 <geppetto> Ok … so anything else to note here?
17:30:51 <geppetto> Do we have anything to look at for RPM file triggers … and do we want to do so this week?
17:30:55 <geppetto> Or just open floor?
17:32:51 <tibbs|w> Not really for file triggers, though they are pulling 4.13 into F23 which means we'll get to use this sooner.
17:33:00 <geppetto> cool
17:33:06 <geppetto> #topic Open Floor
17:33:20 <geppetto> Anything else anyone wants to bring up?
17:34:26 <tibbs|w> As far as I know there's only one package using this.
17:34:37 <tibbs|w> But as far as I can tell it works wel enough.
17:35:31 <tibbs|w> As for our guidelines, I guess we'll just add "Only needed on F22 and older" around the scriptlets once packages are converted.
17:35:45 <tibbs|w> Well, once the right packages gain %filetrigger statements.
17:36:20 <tibbs|w> But not needing to call ldconfig or random systemd macros or icon cache stuff or whatever will be really nice.
17:37:46 <geppetto> yeh
17:38:00 <geppetto> I have it on my TODO list to see how much of %post will be affected
17:38:05 <geppetto> my assuption is quite a bit though
17:38:30 <tibbs|w> Yes, almost all of packages will lose %post.
17:38:38 * geppetto nods
17:39:18 <tibbs|w> And those that don't just have pasted-in scriptlets are probably doing some old config file upgrade or something like that which has been in there since F12 or whatever and can just be dropped.
17:39:29 <geppetto> There are a few things like /etc/shells where it'd make sense to have a /etc/shells.generate.d and have some filter trigger place on that
17:39:54 <tibbs|w> Yeah, we can do that kind of thing now.  Which is awesome.
17:40:00 * geppetto nods
17:40:21 <tibbs|w> So loads of ideas.  Though they're not really FPC things.
17:40:55 <geppetto> Yeh, kind of related but not all the work on us … in theory.
17:41:30 <tibbs|w> Well, someone's going to need to drive this.
17:41:43 <tibbs|w> Probably more devel list fodder, though.
17:42:18 <geppetto> Maybe, I might have some time to work on it
17:44:39 <tibbs|w> I can at least make a mailing list post and try to follow a thread.
17:45:15 <tibbs|w> Shouldn't be hard to identify the packages which should contain the triggers for each thing on our scriptlets page and in the various guidelines pages.
17:45:25 <tibbs|w> And then it's just begging.
17:45:35 <tibbs|w> Well, and giving them patches to merge.
17:46:22 <tibbs|w> Actually getting rid of the scriptlets can come later.
17:46:42 <tibbs|w> Though I wonder what happens if a package has scriptlets and another package has a trigger.
17:46:48 <geppetto> for some, yeh it doesn't matter if things run twice
17:46:51 <tibbs|w> I'd guess things get run twice.
17:47:02 <geppetto> for others, maybe not a great thing
17:47:05 <tibbs|w> Hopefully all of our scriptlets are idempotent.
17:47:19 <geppetto> I'm sure that's not true
17:47:45 <tibbs|w> They damn well should be or else you can't just do yum reinstall.
17:48:14 <geppetto> reinstall isn't the same from a scriptlets POV
17:48:37 <tibbs|w> Now, fonts.... I tried to install about 30 fonts onto a fast machine with an SSD and it still took, well, long enough that I ctrl-C'd it.
17:48:57 <geppetto> Because the remove+install happens at the same time … so I'm pretty sure the install number args. will be different from an actual remove followed by install
17:49:11 <geppetto> tibbs: You know what it was doing?
17:49:23 <tibbs|w> Running scriptlets, I guess.
17:49:44 <tibbs|w> But anyway, I think we do have issues if the scriptlets aren't idempotent.
17:50:01 <tibbs|w> But then again, the ones in the guidelines are, so we should be good there.
17:50:14 * geppetto nods
17:50:23 <tibbs|w> "All scriptlets must be idempotent" would probably be a good guideline.
17:50:39 <Rathann> +1 to that
17:50:55 <Rathann> also, I need to drop off as we're nearing the 2h mark
17:50:58 <tibbs|w> Anyway, nearly two hours and I have to leave soon.
17:51:02 <tibbs|w> Heh.
17:51:21 <tibbs|w> Hopefully things will calm down a bit here and I'll have more time next week.
17:52:25 * geppetto nods
17:52:33 <Rathann> thanks and see you next week, bye
17:52:37 <geppetto> See ya
17:54:01 <tibbs|w> I wonder if the ancient rpm in EL5 supports multiline macros.
17:54:17 <tibbs|w> I know rpm 4.0 didn't, but that was a very long time ago.
17:55:38 * geppetto has no idea
17:55:51 <tibbs|w> Want to try using a macro for %description so it doesn't have to be repeated in the specs.
17:56:15 <tibbs|w> I just never know how things will break when stepping into the minefield of EL5 packages.
17:56:27 <geppetto> Yeh, /usr/lib/rpm/macros on my el5 machine has multiline macros
17:56:56 <geppetto> used for debuginfo
17:57:20 <tibbs|w> I do wonder what a complete cross-release package for a python module would actually look like now.
17:57:54 <tibbs|w> Probably just two completely separate specs in one file, each wrapped in %if/%endif.
17:58:06 <tibbs|w> Sometimes I think that might be simpler.
18:00:31 <geppetto> ugh
18:00:46 <geppetto> Anyway … it's 2 hours exactly
18:00:51 <geppetto> #endmeeting