17:00:46 <geppetto> #startmeeting fpc
17:00:46 <zodbot> Meeting started Thu Feb 19 17:00:46 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:46 <geppetto> #meetingname fpc
17:00:46 <zodbot> The meeting name has been set to 'fpc'
17:00:46 <geppetto> #topic Roll Call
17:00:52 <geppetto> tibbs: having fun :)
17:01:01 <geppetto> #chair tibbs|w
17:01:01 <zodbot> Current chairs: geppetto tibbs|w
17:01:01 <tibbs|w> Better day than normal, I guess.
17:01:05 <geppetto> :)
17:01:18 <orionp> hello
17:01:23 <geppetto> #chair orionp
17:01:23 <zodbot> Current chairs: geppetto orionp tibbs|w
17:01:33 * tomspur_ is here
17:01:38 * limburgher here
17:01:45 <geppetto> tomspur_:  You want to /nick?
17:01:49 <geppetto> #chair limburgher
17:01:49 <zodbot> Current chairs: geppetto limburgher orionp tibbs|w
17:02:31 <geppetto> #chair tomspur
17:02:31 <zodbot> Current chairs: geppetto limburgher orionp tibbs|w tomspur
17:03:25 <geppetto> #chair mbooth
17:03:25 <zodbot> Current chairs: geppetto limburgher mbooth orionp tibbs|w tomspur
17:04:19 <geppetto> #topic Schedule
17:04:21 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-February/010471.html
17:04:37 <geppetto> #topic #492 	Reverse weak dependencies
17:04:43 <geppetto> https://fedorahosted.org/fpc/ticket/492
17:05:15 <geppetto> tibbs: You wanted to bring it up?
17:06:10 <geppetto> nevermind … I guess they answered all the questions
17:06:26 <tibbs|w> Yeah, I just dropped it out of needinfo because I think we have the info we need.
17:07:15 <tibbs|w> But I guess we actually need a draft.
17:07:31 <tibbs|w> I'm basically in favor of this as long as the tools support it reasonably.
17:07:34 <geppetto> I guess the end of the description is supposed to be a new section?
17:08:07 <geppetto> personally I fail to see why we'd want reverse weak deps. but not normal weak deps.
17:08:26 <limburgher> What happens if someone uses this in f22+ and backports the spec to f21 or less, will the tags just be ignored?
17:08:37 <geppetto> Esp. given that dnf mostly ignores the reverse ones … certainly the policy in the ticket doesn't match the description by the dnf author
17:08:46 <tibbs|w> Hmm.
17:08:56 <geppetto> limburgher: They'll still be there, but yum does even less with them than dnf does
17:09:09 <tibbs|w> limburgher: Well, rpm in F21 supports them, at least.  But yeah, I think not much will happen.
17:09:23 <tibbs|w> Of course, you can use dnf in F21, so who knows?
17:09:25 <limburgher> Ok.  Good to know.
17:09:55 <tibbs|w> I particularly like the reverse dependencies because it puts the work of figuring out what adds to what in the right place.
17:10:20 <tibbs|w> Otherwise you have to update the "main" package every time something comes up which "enhances" it.
17:10:39 <geppetto> True, but did you read the explanation
17:10:47 <geppetto> Because AFAICS … it'll do nothing
17:11:17 <geppetto> "(Suggests, Enhances) are used as package preference (for dnf's version of compare providers)"
17:11:33 <tibbs|w> As long as it's possible to display them somewhere in some way, I think they have value.
17:11:50 <tibbs|w> Even if it has no effect on package installation at all.
17:11:56 <geppetto> Oh, nevermind … I'm getting confused by the stupid names again
17:11:59 <orionp> But Supplements will be brought in
17:12:10 <orionp> yeah, the naming is ....
17:12:29 <tibbs|w> I think we're stuck with the naming; it just falls to us to explain it reasonably.
17:13:34 <geppetto> Yeh, so the policy is still not really correct for enhances
17:14:10 <tibbs|w> And I would, I think, like to see more explanation.  I think this deserves to be split out into a separate guideline document and expanded with examples.
17:14:33 <tibbs|w> I wouldn't normally say that, but this is pretty complicated and if packagers don't get it right, fun will ensue.
17:14:41 <geppetto> Ok, do we want them to include normal weak deps. too?
17:15:03 <tibbs|w> I think it would be nice if they did include them so we can at least see how it is supposed to work.
17:15:20 <tibbs|w> But I'm very concerned about how forward and reverse weak deps interact with each other.
17:16:05 <limburgher> Good point, if one makes something default=yes and the other default=no, who wins?
17:17:11 <geppetto> limburgher: not sure what you mean?
17:17:28 <geppetto> AIUI what jsilan said, there's only one config. variable for both
17:17:49 <tibbs|w> Well, what if one package has a weak forward dependency on a package that has a strong reverse dependency?
17:17:51 <orionp> A recomends B,  B enhances A
17:18:24 <orionp> C suggests D, D supplements C
17:18:36 <limburgher> Right.
17:18:37 <geppetto> In both cases you get both AIUI
17:18:48 <orionp> Do we care?
17:18:52 <limburgher> I guess that makes sense, but what's the default?
17:19:18 <geppetto> All of them are inclusive only, AIUI … so there's nothing like WeakConflicts
17:19:32 <limburgher> I guess I don't really care what the behaviour is as long as it's documented.
17:19:40 <geppetto> :)
17:21:33 <geppetto> #action Create a real policy in the ticket, probably as a new page that is linked to, using the information provided by the dnf maintainer. Include examples for packagers, and how to change the dnf settings.
17:22:25 <geppetto> #action Also include "normal" weak deps., so we can at least make sure they both line up correctly. Although we'll probably vote on them separately.
17:22:43 <geppetto> That sounds good?
17:23:05 <tibbs|w> +1
17:23:06 <orionp> +1
17:23:12 <geppetto> #topic #493 	Bundling exception: python-execnet bundles python-apipkg
17:23:16 <tomspur> Will the dnf wording also count for packagekit?
17:23:33 <geppetto> tomspur: No PK is a different package manager now
17:23:35 <geppetto> https://fedorahosted.org/fpc/ticket/493
17:24:21 <geppetto> tomspur: My guess is that PK will ignore everything, but who knows
17:24:25 <tibbs|w> I think tomspur had a proposal at the bottom.
17:24:25 <tomspur> geppetto: I don't think we should have guidelines specific to dnf only then, such as what the default is
17:25:08 <tomspur> About #493: The python3-apipkg was submitted just yesterday, yet I think a temporary proposal would still be nice
17:25:36 <tomspur> Then we can revisit it in a few weeks again and see if unbundling worked
17:25:53 <tibbs|w> I don't really know; an exception for as long as it takes something to get reviewed and into rawhide?
17:26:00 <geppetto> So the proposal is to allow bundling for a couple of weeks?
17:26:22 <tibbs|w> I mean, I guess, but seems like we're spending our very limited meeting time on something pretty trivial.
17:26:26 <limburgher> I suggest the parties concerned help with the review or solicit assistance.
17:26:36 <geppetto> limburgher: +1
17:28:06 <tibbs|w> I'm confused; it's already in rawhide.
17:28:22 <limburgher> So they could try the unbundling now.
17:28:29 <tomspur> tibbs|w: as of yesterday
17:29:05 <tibbs|w> Sure.  So, why don't we see how it goes and if there's still something we need to do, deal with it then.
17:29:07 <tomspur> I have some doubts with this wording from upstream about unbundling: https://bitbucket.org/hpk42/py/issue/31
17:29:08 <tibbs|w> ?
17:30:03 <tibbs|w> But that was a long time ago, and upstream can always do all kinds of things, and we kind of have to deal with them as they happen.
17:32:04 <tomspur> It was unclear when the python3-apipkg was going to be submitted, so I wanted to give the python-execnet maintainer a bit more time with a temporal exception. Maybe now just move forward and let's see if they can unbundle it now...
17:32:17 <geppetto> #action apipkg is in rawhide, check back if you need anything else. If we don't hear anything we'll close the ticket in a few weeks.
17:32:26 <geppetto> #topic #495 	Proposal: Package Guidelines: PreupgradeAssistant contents packages
17:32:30 <geppetto> https://fedorahosted.org/fpc/ticket/495
17:33:44 <tibbs|w> So I did some cleanup, and then he filled out the draft.
17:34:01 * geppetto nods
17:35:56 <geppetto> The new draft looks much better, to me: https://fedoraproject.org/wiki/User:Phracek/Draft:Packaging:PreupgradeAssistant
17:35:58 <tibbs|w> I think he misunderstood the bit about shortening the macro names.
17:36:20 <tibbs|w> Stil has fedora_preupgrade_name and fedora_preupgrade_dir
17:36:54 <tibbs|w> I'm inclined not to care too much, really, but it does make for some really long lines in the spec.
17:37:33 <tomspur> I'd favor shortening
17:38:13 <tomspur> How about voting on the short version and check back, if he has an argument for leaving them as they are?
17:38:21 <mbooth> Why does preupgrade_build have to be told about "%{fedora_preupgrade_name}/%{name}/" -- will any package use different parameter?
17:38:53 <tibbs|w> Let me edit the draft to shorten the macros.
17:39:14 <geppetto> mbooth: I'd assume not … but it seems weird to specify it otherwise ?:-o
17:40:35 <tomspur> When a package is added to F20, one can only add preupgrade stuff from F20 to F21? Or is it possible to rebuild the update and include content for F20->F21 and F20->F22?
17:40:54 <mbooth> geppetto: I mean, why can't preupgrade_build macro assume "%{fedora_preupgrade_name}/%{name}/" as a sensible default unless you specify something different
17:41:01 <tibbs|w> OK, I shortened all of teh macro names.
17:41:07 <limburgher> I don't think we've ever officially supported upgrading more than one release at a go.
17:41:14 <geppetto> mbooth: yeh
17:41:27 <geppetto> limburgher: we never supported anything :)
17:41:42 <tibbs|w> Could further modify them to use "preupg" instead of "preupgrade".  Again, not sure if I care.
17:41:50 <geppetto> limburgher: el only support one release at a time, but that's becauswe their releases are 3-5 years apart
17:42:06 <mbooth> Also in the "Build section" section you mention %{preupgrade_prep} -- is this a typo?
17:42:13 <mbooth> Should it be %{preupgrade_build} ?
17:42:15 <tibbs|w> And it's only recently that EL supported upgrading at all.
17:42:22 <geppetto> lots of people skip releases in Fedora … but, meh … it's not like it works well anyway :-o
17:43:01 <tibbs|w> I think this whole thing is a pretty good idea in any case.
17:44:20 <geppetto> yeh, I guess I'm +1
17:45:13 <orionp> +1
17:45:27 <limburgher> +1 i think
17:45:30 <geppetto> mbooth: Ahh, I think I see now … the build argument is what you used in %prep … so it's completely arbitrary
17:45:35 <tibbs|w> Seems like we had a lot of questions, though.  At least mbooth did.
17:45:56 <tibbs|w> And are these +1s after I shortened the macros?
17:46:04 <limburgher> Mine is
17:46:06 <geppetto> tibbs: yes, mine anyway
17:46:17 <mbooth> geppetto: Right, but in the prep section it says "Copy all contents files to %{preupgrade_name}/%{name} directory. "
17:46:27 <mbooth> Which is not so arbitrary
17:46:38 <geppetto> mbooth: Yeh, and that argument is arbitrary too … I think
17:47:57 <mbooth> Just seems way more verbose than it needs to be -- a lot of this boilerplate could be hidden by slightly cleverer macros, but then I am not the one implementing this is real packages
17:48:04 * mbooth shrugs
17:48:24 <tibbs|w> I'm +1, but I do see the point.
17:48:30 <geppetto> I mean … now is that time to ask if you want to change it
17:48:54 <tibbs|w> Well, we can always change things later.
17:49:07 <geppetto> True enough
17:49:15 <mbooth> Also, is the macro name in this section wrong? https://fedoraproject.org/wiki/User:Phracek/Draft:Packaging:PreupgradeAssistant#Build_section
17:49:23 <mbooth> There is no mention of it the example spec
17:49:32 <mbooth> I assume it is a typo
17:50:06 <geppetto> the _prep macro?
17:50:11 <mbooth> Yeah
17:50:18 <geppetto> Yeh, maybe he just added that recently and forgot to update the example?
17:50:44 <tibbs|w> Corrected "has to success" in that section.
17:51:02 <tibbs|w> If approved, I'll do a pass for grammar while writing this up.
17:51:08 <mbooth> Well, I assume typo because the section of the wiki page is "Build section"
17:51:08 * geppetto nods
17:51:18 <geppetto> Ahh, true
17:51:40 <geppetto> Yeh, I guess that's it then … tibbs can you s/prep/build/ there?
17:51:53 <tibbs|w> Sure.
17:52:50 <tibbs|w> That _prep macro does appear elsewhere in the document, though.
17:53:05 <geppetto> So, atm. we're at +4 with mbooth and tomspur not voting yet
17:53:27 <tibbs|w> I changed it anyway but I need to look at the actual macro definitions.
17:53:34 <tomspur> +1 from me also
17:53:35 <geppetto> Under the ini file bit … yeh, not sure what that means :-o
17:53:48 <tibbs|w> Ups delivery, back in a sec.
17:55:25 <tibbs|w> OK.
17:55:35 <tibbs|w> Is this preupgrade-assistant thing actually in the distro?
17:55:44 <geppetto> I thought so
17:55:44 <tibbs|w> If so, what's the srpm name?
17:56:08 <geppetto> Is it part of fedup?
17:56:27 <mbooth> I feel like it can be made a lot simpler, but I having nothing against this fundamentally, +1
17:56:55 <tibbs|w> mbooth: Could you maybe write up your suggestions?  Simpler is almost always better when it comes to packaging.
17:57:20 * geppetto nods
17:57:21 <mbooth> tibbs|w: Sure, I will write up some suggestions
17:57:49 <geppetto> #action PreupgradeAssistant contents packages (+1:6, 0:0, -1:0)
17:57:49 <tibbs|w> I don't see rpm macros in the upstream github repo.
17:57:50 <tomspur> Why doesn't %{preupgrade_prep} need to know the buildroot of the installed files?
17:57:55 <tibbs|w> https://github.com/phracek/preupgrade-assistant
17:58:16 <tibbs|w> tomspur: Of course, I removed all references to preupgrade_prep.
17:58:55 <tibbs|w> I've realized that sometimes we have to approve a guideline that we think looks nice even if we've changed it in some way that doesn't match reality.
17:59:02 <tibbs|w> And when that happens we just fix it up.
17:59:09 * tomspur refreshes...
17:59:23 <tibbs|w> It's often better to do that than to let these things sit there blocking real packaging work from happening.
18:00:33 <tibbs|w> It is really tough for us to get it completely right when we can't see the underlying macros, though.
18:00:34 <mbooth> tibbs|w: Agreed -- that's fine. We iterated the java packaging guidlines over the course of a few years such that many packages need just two or three macro calls :-)
18:00:46 <mbooth> It takes time
18:00:49 <tibbs|w> Yes.
18:01:03 <geppetto> #topic #497 	Clean up BuildRequires section; don't try to define the minimal build env
18:01:09 <geppetto> https://fedorahosted.org/fpc/ticket/497
18:01:18 <hhorak> Hey guys, it doesn't seem like you're yet yet, are you? We should probably move Env&Stacks meeting to fedora-meeting-2..
18:01:46 <geppetto> hhorak: yeh, we might finish before 2 today … but not in the next few minutes
18:02:33 <hhorak> geppetto: ok, please send anybody who looks for Env&Stacks to -2
18:02:45 <geppetto> hhorak: ok, no problem
18:02:51 <geppetto> tibbs: Did you send an email?
18:03:05 <geppetto> tibbs: nevermind … I've found it now
18:03:08 <tibbs|w> Yes, and I got a bit of feedback (2 messages), all positive with some suggestions.
18:03:15 <geppetto> I thought I'd seen it, but then couldn't find it :(
18:03:33 <tibbs|w> But it came like ten minutes before that whole "unbundling is too hard and scares people off" message.
18:03:50 <tibbs|w> I need to incorporate the suggestions and post it all again.
18:04:05 <tibbs|w> But if anyone here read and has any suggestions, please let me know.
18:04:24 <tibbs|w> If some folks here wouldn't approve this kind of change regardless, it would be nice not to waste my time.
18:04:43 <tomspur> tibbs|w: I don't think that "RPM has the ability to function and process your spec file." like suggested in one reply
18:05:01 <tibbs|w> Sorry, I can't parse that.
18:05:02 <tomspur> To let rpm parse some macros, some BR are needed from time to time
18:05:16 <tomspur> There is a proposal at: https://lists.fedoraproject.org/pipermail/packaging/2015-February/010470.html
18:05:31 <tibbs|w> Yeah, some of that is good.
18:05:35 <tibbs|w> At least I think so.
18:06:03 <tibbs|w> As for the macros, sometimes I wish that all of the package-related macros were all moved into the proper -devel packages.
18:06:10 <tomspur> With the wording from above. Yet to get all macros recognized one need to have the correct BR sometimes, to the sentense from above is not correct
18:06:25 <tibbs|w> So that you wouldn't even get a lot of the macros if you didn't have the proper BR.
18:06:42 <geppetto> tomspur: tibbs: I think you might just have differnt definitions of parse the specfile … without the packages which have the macro definitions in them rpm can still parse the specfile, it'll just get different results
18:06:54 <tibbs|w> That's true.
18:07:14 <tibbs|w> And I also wish that rpm would error out upon referencing an undefined macro, but that's a discussion for another day.
18:07:14 <geppetto> I'm not sure how to word that clearly
18:07:19 <tibbs|w> geppetto: Indeed.
18:07:38 <tomspur> Maybe define "default/always correctly parsable" macros instead of default BRs? ;)
18:08:24 <tibbs|w> I mean, it's one thing to expect rpm to be able to apply patches.  It's another thing to want to call patch yourself and assume that rpm has pulled it in.
18:08:34 <tibbs|w> I think a BR: is warranted in the latter case.
18:08:59 <geppetto> yeh, that seems fine
18:09:03 <tibbs|w> But macros, I don't know.
18:09:36 <geppetto> What don't you know?
18:10:17 <geppetto> I think you should have to BR any package providing macros that you depend on, and I assume you agree?
18:10:25 <tibbs|w> Oh, of course.
18:11:02 <tibbs|w> I thought the issue was about macros which rpm (or redhat-rpm-config) defines but which might not be useful without additional build deps.
18:11:28 <tibbs|w> You can't assume that just because rpm defines some perl-related macro that it has brought in perl.
18:11:40 <geppetto> sure
18:12:38 <tibbs|w> Which does make me wonder why, say, macros.perl is in rpm-build and not, you know, perl.
18:12:45 <tibbs|w> Probably just historical.
18:13:10 <geppetto> So you want to tweak it and post again, and then we can look at it for next week?
18:13:17 <tibbs|w> Yes, certainly.
18:13:23 <geppetto> ok
18:13:26 <tibbs|w> I just didn't have a chance to do it this morning.
18:13:45 <geppetto> #action tibbs Tweak email with feedback and post again, will look at voting on something next week.
18:13:48 <tibbs|w> And this really isn't urgent in any case.  Should probably drop it way down in the meeting priority.
18:14:00 * geppetto nods
18:14:02 <geppetto> #topic #498 	Seeking guidance: Apps using default Python in Fedora vs. EPEL
18:14:08 <geppetto> https://fedorahosted.org/fpc/ticket/498
18:14:28 <geppetto> tibbs: I'd just gone through all of the old tickets last week, so thought we should do the newer ones this week
18:14:43 <tomspur> Here is an updated diff: https://fedoraproject.org/w/index.php?title=User%3ATomspur%2FUnversioned_Python_Macros&diff=404402&oldid=403797
18:15:12 <tomspur> (Where) should we define the current default python interpreter?
18:15:30 <tibbs|w> BTW, you can replace "404402" with "cur" there and the diff will always be up to date....
18:15:45 <tomspur> For now I have it just in the explanation of __python
18:15:57 <geppetto> The diff seems fine, to me
18:17:36 <geppetto> I'm confused about toshio's last message … why would changing the macros require a new Fedora change?
18:17:56 <tibbs|w> Made one tweak: Python 2 interpreter. Also the default python interpreter -> Python 2 interpreter. Also the current default python interpreter
18:18:31 <geppetto> still looks fine :)
18:18:53 <tibbs|w> Although removing the "also" bit sort of makes more sense to me.  But I'm picking nits, sorry.
18:18:55 <geppetto> tomspur: You know why toshio thinks we need a Fedora change for the macros?
18:19:11 <tomspur> geppetto: We need a change, when we switch to python3...
18:19:38 <tomspur> So when moving %{__python} == {__python2} to %{__python} == {__python3}
18:19:43 <tibbs|w> I would think that if a change in the macros means that packages will have to be fixed, then the change process gets involved.
18:19:48 <tomspur> Yet that is not part of this proposal
18:20:11 <tibbs|w> But if not, then I can't see why someone would need to do the change thing.
18:21:09 <geppetto> tomspur: Yeh, I just assumed that could be under the change the default python Fedora change.
18:22:09 <orionp> It looks good to me
18:22:12 <geppetto> So I'm +1, if a little confused :)
18:22:37 <tomspur> I think toshio and me have same opinions and talk with different (confusing) wordings about exact the same thing ;)
18:22:49 <geppetto> :)
18:22:56 <mbooth> I don't think I've ever read the python guidelines from beginning to end... It's a bit of a long read :-p
18:23:19 <geppetto> ha … I could probably say that about most of them :)
18:23:24 <tibbs|w> mbooth: Yes, too long.
18:23:39 <tibbs|w> I have long bemoaned the terrible state of python packaging in Fedora.
18:23:44 <tibbs|w> So much macro spaghetti.
18:24:35 <mbooth> The contents of the diff seems sensible enough to me, so +1 to that fwiw
18:26:21 <tibbs|w> Is the part about brp-python-bytecompile using whatever __python points to still correct?
18:26:46 <geppetto> orionp: I assume that's a +1
18:26:51 <tibbs|w> https://fedoraproject.org/wiki/User:Tomspur/Unversioned_Python_Macros#Bytecompiling_with_the_correct_python_version
18:26:55 <orionp> yes +1
18:26:59 <geppetto> Dito. assume tomspur and tibbs are going +1?
18:27:05 <tibbs|w> +1 from me as well.
18:27:23 <geppetto> limburgher: vote?
18:27:50 <tomspur> tibbs|w: Unfortunately yes...
18:27:55 <limburgher> +1
18:27:58 <tomspur> geppetto: +1
18:28:03 <tibbs|w> Just had to make sure that __python wasn't referenced in any of the example specs.
18:28:12 <geppetto> #action Apps using default Python in Fedora vs. EPEL (+1:6, 0:0, -1:0)
18:28:26 <tibbs|w> And while we're in there, does anyone know if the bit ab the end about pygtk2 and numpy is still correct?
18:28:35 <geppetto> #topic Open Floor
18:29:00 <tibbs|w> Wow, was that the whole meeting agenda?
18:29:01 <tomspur> tibbs|w: It could be made more generic, or just changed to python2 later on...
18:29:18 <geppetto> tibbs: No, that was all the "newer" tickets
18:29:25 <geppetto> And it's been 1.5 hours … so
18:29:32 <tibbs|w> 435 is waiting on Rathann.
18:29:49 <tibbs|w> Zero idea about 248.
18:29:49 <tomspur> I have a more general question. Would it be possible to check before %build, if there is something included in the package that should get deleted?
18:29:52 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-February/010471.html … we've got 7 anchient tickets
18:30:29 <tibbs|w> We put something off last week until limburgher was here....
18:30:36 <tibbs|w> https://fedorahosted.org/fpc/ticket/221
18:31:01 <tibbs|w> limburgher: You still care about that at all?
18:31:02 <geppetto> #topic #221 	Bundling exception request: numptyphysics and Box2D
18:31:10 <geppetto> https://fedorahosted.org/fpc/ticket/221
18:31:33 <tibbs|w> Otherwise it's another ticket down.
18:31:53 <tibbs|w> We're going to be under 20 after this meeting, I think.
18:32:13 <geppetto> :)
18:32:22 <geppetto> was almost under 10 for the agenda
18:32:40 <limburgher> I do. . .but not the way you think.
18:33:03 <limburgher> numptyphysics seems not to run as of f20, and upstream seems to have vanished.  So I'm going to retire it.
18:33:29 <geppetto> seems like a solution :)
18:33:36 <tibbs|w> I know there's a "but" in there somewhere.
18:33:54 <geppetto> #action retiring package, so doesn't matter.
18:34:35 <limburgher> tibbs|w: ?
18:34:44 <geppetto> #topic Open Floor
18:34:51 <geppetto> Anyone else have anything to bring up?
18:35:06 <tibbs|w> limburgher: I was just figuring there was something else to your statement.
18:35:14 <geppetto> limburgher: I think that was just his optimisim shinning through ;)
18:35:39 <tomspur> Is it possible to search automatically for content that should be deleted before %build?
18:35:44 <tibbs|w> I have precious little these days.
18:35:44 <limburgher> :)
18:36:10 <geppetto> tomspur: like what?
18:36:15 <tibbs|w> tomspur: Well, I think rpm does something before %build that you could hook into.
18:36:32 <tomspur> e.g. One must delete python eggs before building. Would it be possible to search and delete them automatically ?
18:36:42 <tibbs|w> ___build_pre
18:36:48 <tibbs|w> SO, yeah, hack on that.
18:38:49 <tibbs|w> Not a packaging guideline thing, though.  But just hook in one or more shell scripts, with some rpm variable to disable them if absolutely necessary.
18:39:16 <tibbs|w> I certainly wouldn't object at all.
18:39:34 <tomspur> Sounds doable...
18:40:08 <tomspur> I'll have a look, so maybe some removing of content could be automated
18:40:27 <tomspur> tibbs|w: thanks
18:40:53 <geppetto> cool
18:40:58 <tibbs|w> I'm out.
18:41:05 <geppetto> Ok, anything else?
18:41:09 <tibbs|w> Well, out of stuff to say, at least.
18:41:14 <geppetto> If not I'll close in a minute or so :)
18:42:10 <tibbs|w> Maybe next week we can cover all that's left and be done with everything.
18:43:51 <limburgher> Uh hu.
18:43:52 <limburgher> h
18:44:56 <geppetto> tibbs: there's that optimism showing through again :)
18:45:04 <tibbs|w> Hey, it's possible.
18:45:21 <geppetto> it is, we've been lucky the last two weeks to not have any new tickets though
18:45:35 <geppetto> Anyway … time for some lunch
18:45:42 <geppetto> #endmeeting