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