17:00:23 <geppetto> #startmeeting fpc 17:00:23 <zodbot> Meeting started Thu Nov 20 17:00:23 2014 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:23 <geppetto> #meetingname fpc 17:00:23 <zodbot> The meeting name has been set to 'fpc' 17:00:23 <geppetto> #topic Roll Call 17:00:37 * limburgher here 17:00:37 <geppetto> geppetto limburgher mbooth orionp racor Rathann SmootherFr0gZ spot tibbs|w tomspur: FPC ping 17:00:37 <geppetto> #char limburgher 17:00:40 <geppetto> #chair limburgher 17:00:40 <zodbot> Current chairs: geppetto limburgher 17:00:41 <mbooth> Heya 17:00:47 <geppetto> #chair mbooth 17:00:47 <zodbot> Current chairs: geppetto limburgher mbooth 17:00:50 <geppetto> #chair racor 17:00:50 <zodbot> Current chairs: geppetto limburgher mbooth racor 17:00:50 <orionp> morning 17:00:55 <geppetto> #chair orionp 17:00:55 <zodbot> Current chairs: geppetto limburgher mbooth orionp racor 17:01:04 * tomspur is here 17:01:08 <geppetto> #chair tomspur 17:01:08 <zodbot> Current chairs: geppetto limburgher mbooth orionp racor tomspur 17:01:35 <geppetto> Ok, tibbs said he's been called away for a few minutes … so that's probably it. 17:01:49 <geppetto> #topic #469 Unified bootstrapping 17:01:54 <geppetto> https://fedorahosted.org/fpc/ticket/469 17:02:54 <limburgher> It's certainly a problem that needs solving. . . 17:03:27 <Rathann> I'm here 17:03:39 <geppetto> yeh, and the policy looks ok to me … but I've very rarely dealt with it. 17:03:42 <geppetto> #chair Rathann 17:03:42 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp racor tomspur 17:04:04 <tomspur> So a macro would be prefered over the with syntax? 17:04:05 <orionp> I'm all for standardization in general 17:04:11 <geppetto> Anyone dealt with bootstrapping packages? 17:04:23 <racor> FWIW: I'll have to leave earlier than usual. No later than 18:00 UTC 17:04:29 <mbooth> It looks okay, but is not a full solution for at least one package I touch frequently 17:04:36 <Rathann> I haven't yet, but I know a few people who did/do 17:04:44 <geppetto> racor: ok, with any luck this week we'll be finished by then anyway 17:04:45 <limburgher> mbooth: What would you change/add? 17:04:51 <racor> geppetto: Yes, we apply similar rule in perl-packages for a long time 17:04:54 <mbooth> E.g. Tycho has two kinds of bootstrap: http://pkgs.fedoraproject.org/cgit/tycho.git/tree/tycho.spec 17:05:05 * geppetto looks 17:05:16 * mbooth deals with bootstrapping eclipse quite frequently 17:05:36 * limburgher recoils, offers sympathy 17:05:38 <geppetto> racor: So the proposed policy compatible with what you do in perl? 17:07:41 <racor> geppetto: Dunno without having checked details yet. 17:07:50 <geppetto> racor: That 17:08:05 <geppetto> racor: That's cool, can give you time to read :) 17:08:12 <mbooth> I'm not convinced about the need for virtual provides/requires for non-bootstrap builds though... 17:08:25 <racor> perl uses %perl_bootstrap 17:08:46 <geppetto> mbooth: With tyco it looks like having with_bootstrap control both variables might still do something useful … you know if that's true? 17:09:04 * mirek-hm is here if you want me ask about boostrap, i was waiting in #fedora-meeting by mistake 17:09:22 <geppetto> mirek-hm: <mbooth> E.g. Tycho has two kinds of bootstrap: http://pkgs.fedoraproject.org/cgit/tycho.git/tree/tycho.spec 17:09:30 <racor> its statically set in some /etc/rpm/* macro in "bootstrap" (build from scatch) 17:10:25 <racor> and later unset inside this macro-file to rebuild many packages (recursively) again. 17:10:26 * mirek-hm checking 17:10:26 * orionp wonders why we check the existence of one macro to set another 17:10:53 <mbooth> geppetto: Probably it only needs to set "%tycho_bootstrap" for the most common case 17:11:53 <mirek-hm> geppetto: can both be set to 1? 17:12:00 <racor> Background: perl has lengthy, complicated recursive dep-chains. In general, when bootstrapping perl, all packages using %perl_bootstrap are built twice. 17:12:18 * orionp timidly mentions %bcond_with bootstrap 17:12:49 <geppetto> mirek-hm: I think so … but mbooth would know 17:12:56 <Rathann> bcond_with bootstrap would be pretty standard 17:12:58 <geppetto> orionp: Now you are just being fancy ;) 17:13:50 <mbooth> mirek-hm geppetto: Yes, when bootstrapping into a new root, the build order is something nuts like "tycho both bootstraps"->"eclipse bootstrap"->"tycho full build"->"eclipse full build" 17:13:58 <geppetto> racor: So … would it be difficult to move to a common bootstrap variable? 17:15:11 <mirek-hm> my goal with this draft is to aim at most of the cases. I'm not trying all bootstrapping, because some of them probably can not be solved automatically, but in library/languages worlds is quite common use of _with_doc etc. which is basicaly bootsrap, now it must be solved manually and it is lots of work 17:15:27 <mirek-hm> so I'm trying to automatize it in mock/mockchain 17:15:43 <mbooth> mirek-hm: That's fair, tycho/eclipse is an unusual case 17:17:53 <racor> geppetto: I am not sure, if it makes sense - Possibly setting %perll_bootstrap to %bootstrap if it's defined is useful. 17:18:00 <geppetto> yeh, we can cover the common cases … just need wording that says that. 17:18:25 <mbooth> mirek-hm: Probably we would simply set %tycho_bootstrap in the more common case that an updated dep means tycho cannot build itself 17:19:23 <racor> geppetto: I just can't find the package, where it's defined - AFAICT, it has moved recently ;) 17:19:34 <geppetto> Ok, do we want to tweak the wording today … or leave it with mbooth / racor / mirek-hm … and come back to it in a couple of weeks? 17:19:42 <mirek-hm> mbooth: I would say: make it working with common set, we will meet few bumps for sure and when we will see how it works and we will have the tooling in place, we can try to do something with those bumps like tycho 17:20:47 <mirek-hm> I would suggest that instead of 17:20:49 <mirek-hm> If your package introduce circular dependencies in build time, you have to define and use this macro: 17:21:12 <tomspur> racor, /usr/lib/rpm/macros.d/macros.perl-srpm is in perl-srpm-macros-1-12.fc21.noarch over here 17:21:17 <mirek-hm> If your package introduce circular dependencies in build time, you should use (unless there are technical obstacles) this macro: 17:21:36 <mirek-hm> that should be enough 17:21:53 <racor> tomspur: Thanks, just found it ;) 17:22:49 <geppetto> mirek-hm: yeh, changing to should might be enough … mbooth ? 17:23:25 <geppetto> mbooth: You also said you had some concerns about the need for the provides? 17:24:02 <mbooth> geppetto: Yeah, but most of my packages (java-land) auto-generate requires/provides so there would be no need for this 17:24:32 <mbooth> i.e. provides would automatically be missing if there are missing parts that are not built in a bootstrap build 17:24:42 <geppetto> mbooth: So with your packages there would be an auto provide that would be there/missing depending on how it was built anyway? 17:24:47 * geppetto nods 17:24:58 <tomspur> mirek-hm, would this "tycho(ecipse)" help to break the dependency chain somehow automatically? 17:25:16 <geppetto> Ok, probably some wording then about "if auto. provides don't do it for you, then add a provide like … " 17:26:46 <mirek-hm> tomspur: well that part about provides is because of the case: 17:28:15 <mirek-hm> package A have Provides: Aa Ab (and we are speaking just about explicit provides, because autoprovides are without problem), but if you build A with bootstrap=1 then it does not have functionality Ab, which some package B may require, so we make sure we do not try to build B with bootsrapped A 17:29:07 <mirek-hm> geppetto: yes, that is good wording 17:31:02 <mbooth> How about "If your package explicitly Provides: some functionality that is missing when bootstrapped, then that Provides: should look like:" 17:31:19 <mbooth> I don't think there is a need to introduce virtual provides, is there? 17:31:59 <mirek-hm> mbooth: excelent. 17:32:03 <Rathann> yeah, just add the same Provides: manually in the bootstrap case 17:32:10 <mirek-hm> I do not see reason for virtual provides neither 17:32:26 <geppetto> Yeh, seems good … mirek-hm are you updating a draft? 17:35:07 <racor> Another thought: What is "bootstrapping" supposed to mean? Building the whole distro in one run? I doubt this can be made working. 17:35:30 <mirek-hm> racor: no, just one package 17:36:12 <mirek-hm> typicaly you have N package, and you could not build none of them, but if you bootstrap one of them, then you break the circle and you continue normaly with the rest of them 17:36:14 <tibbs|w> Finally. 17:36:44 <geppetto> #chair tibbs|w 17:36:45 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp racor tibbs|w tomspur 17:37:47 <tibbs|w> Are we still on the first topic? 17:38:13 <mirek-hm> https://etherpad.mozilla.org/d2nV4zZM5V 17:38:20 <mirek-hm> this the edited draft 17:38:51 <racor> mirek-hm: Thanks - I think we should contact ppisar, AFAICT it was him who did the last "perl_bootstrap" 17:39:21 <geppetto> tibbs|w: yeh 17:39:23 <mirek-hm> racor: I talk to him today in kitchen in office, his statement is: 17:39:23 <tibbs|w> For the record, I'm definitely in favor of this but the devil is in the details. 17:39:44 <mbooth> mirek-hm: This is now redundant: "Packages which requires this functionality should require this virtual provides." 17:39:51 <mbooth> I'd probably remove that sentance 17:40:09 <limburgher> I say add an s to introduce on line 4, capitalize Provides in line 30, and it's good. 17:40:18 <orionp> Is "Set this to 0 after we've bootstrapped" correct? 17:40:43 <mirek-hm> that he is generaly fine with this, if he personally initiated this he would just go through perl first, python then , ruby... etc for every different language different macro, and only then when all are fine, unify it 17:41:01 <orionp> ah follows it now 17:41:04 <mirek-hm> mbooth: remove 17:41:14 <mbooth> mirek-hm: Thanks :-) 17:41:23 <mirek-hm> I personally think we can do it in one step 17:41:53 <mirek-hm> limburgher: feel free to edit it 17:42:04 <Rathann> also, there should be an underscore before with in %{!? with_bootstrap: 17:42:22 <Rathann> i.e. %{!?_with_bootstrap:... 17:42:38 <limburgher> mirek-hm: Neat, didn't know I could do that. :) 17:44:30 <tibbs|w> So does mock support passing --with flags to rpmbuild now? 17:44:57 <mirek-hm> tibbs|w: yes 17:45:02 <tibbs|w> Well, I'm really asking about koji, I guess. 17:45:12 <mirek-hm> even --rpmbuild-opts=OPTIONS 17:45:26 <tibbs|w> One reason we never did this is that our buildsys doesn't support it in any case. 17:45:33 <mirek-hm> but it is in mock-1.2.x which is not in stable. yet. 17:46:10 <mirek-hm> it must first support underlying tools (mock) then we can talk about higher level (koji, copr) 17:46:26 <racor> IIRC, there must not be a blank after the ":" In %{?something:more} 17:47:12 <tomspur> Rathann: why should there be an underscore? It seems _with_bootstrap has another meaning for rpm, which we override now, isn't it? http://www.rpm.org/wiki/PackagerDocs/ConditionalBuilds 17:47:15 <mirek-hm> racor: which line? 17:48:17 <orionp> --with bootstrap will define _with_bootstrap , correct? 17:48:29 <racor> https://fedorahosted.org/fpc/ticket/469 ... section "Bootstrapping" ... %{!? with_bootstrap: %global bootstrap 1} 17:49:25 <tibbs|w> Why is this not using bcond_with? 17:49:27 <racor> AFAICT off head, this needs to be %{!?with_bootstrap:%global bootstrap 1} 17:49:31 <tomspur> orionp: Looks like "%bcond_with bootstrap" defines it and relies on --with bootstrap if it is "--with-bootstrap" or "--without-bootstrap" 17:50:00 <orionp> tomspur : -14: bcond_with %{expand:%{?_with_%{1}:%global with_%{1} 1}} 17:50:12 <orionp> it uses it 17:50:40 <orionp> tibbs|w I timidly mentioned that earlier :) 17:51:59 <racor> sorry folks, I need to quit ;) 17:52:09 <limburgher> racor: See you, thanks! 17:52:21 <mirek-hm> I just tried it it is _with_bootstrap 17:53:05 <mirek-hm> and it expand to "--with-bootstrap" 17:56:37 <geppetto> Ok, are all the edits done now? 17:56:49 <geppetto> orionp: You don't want to use bcond? 17:59:12 <orionp> I don't really care - people generally find the syntax confusing so I'm happy not to use it. 17:59:47 <tibbs|w> Yeah, either way I think this looks good. 18:00:01 <geppetto> Ok, We want to vote on it? 18:00:19 <geppetto> +1 18:00:22 <tomspur> +1 18:00:25 <tibbs|w> +1 18:00:31 <limburgher> +1 18:00:54 <mbooth> +1 18:01:32 <tibbs|w> Sorry, I'm poking around on the etherpad; I've never used it before. 18:02:06 <mbooth> tibbs|w: Etherpad is awesome :-) 18:03:29 <tibbs|w> We should definitely use this more often. 18:03:44 <geppetto> Rathann: You want to vote? 18:03:53 <Rathann> right 18:03:56 <geppetto> orionp: You want to vote? 18:03:56 <Rathann> +1 there 18:06:40 <mbooth> Was that the only item? 18:06:41 <geppetto> #action Unified bootstrapping, with edits during meeting. (+1:6, 0:0, -1:0) 18:06:46 <geppetto> mbooth: The only new one, yeh 18:06:50 <mbooth> Cool 18:07:02 <mirek-hm> thank you guys 18:07:06 <mbooth> mirek-hm: Thanks for talking about the proposal with us :-) 18:07:48 <geppetto> #topic Open Floor 18:07:54 <mirek-hm> should I put it to just after http://fedoraproject.org/wiki/Packaging:Guidelines#Build_time_network_access or somebody else will do that? 18:07:56 <geppetto> Ok, nothing else seems to have been updated 18:08:11 <geppetto> Anyone want to own altering the wiki? 18:08:26 <geppetto> mbooth: ? 18:08:34 <tibbs|w> There must be some old business we can deal with. 18:08:49 <mbooth> geppetto: Sure I can do that 18:08:57 <geppetto> tibbs|w: Not as far as I can see … nothing has been updated recently. 18:09:15 <geppetto> tibbs|w: Obviously there are a lot of old tickets waiting on being put in the wiki 18:09:19 <tibbs|w> And how are we on writeups currently? I've really been out of it (being in hospital for a while) but I can scrape together a little time. 18:09:23 <tibbs|w> Ninja'd. 18:09:28 <geppetto> :) 18:09:30 <tibbs|w> Are those in the writeup state? 18:09:47 <geppetto> Yeh, they "should" all be in the writeup state 18:10:05 <geppetto> I've put a few tickets in that state over the last month 18:10:11 <Rathann> there's a report on trac showing all in writeup state 18:10:23 <geppetto> Yeh, I need to put that on the wiki 18:10:23 <tibbs|w> Yes, and there is a huge load of them. 18:10:54 <tibbs|w> OK, I'll try to look at some of those as I get free time. 18:11:07 * geppetto nods 18:11:15 <geppetto> We should all try for one a week or something 18:11:43 * mbooth is new to this 18:11:45 <geppetto> Also note that I assume we won't have a meeting next week … as it's thanksgiving in the US 18:11:54 <mbooth> I didn't realise there was such a report 18:11:59 <mbooth> I will try a grab a couple 18:12:32 <tibbs|w> I set up a trac workflow and some reports ages ago. I have no idea whether it was actually useful, though. 18:13:42 <geppetto> What's the report URL? 18:13:51 <tibbs|w> https://fedorahosted.org/fpc/report/14 18:13:57 <geppetto> nevermind … it's already in the wiki 18:14:03 * geppetto nods 18:14:34 <geppetto> Ok, if anyone has anything else speak up soon … or I'll close. 18:15:24 <tibbs|w> I think some of the old tickets should be moved to the "needinfo" state. 18:15:52 <tibbs|w> Also, what state is this one in?https://fedorahosted.org/fpc/ticket/436 18:16:21 <tibbs|w> It looks like it has enough votes, but it's ancient. 18:16:38 <tomspur> it seems ticket 433 is already done, so next state is resolved as fixed? 18:16:54 <geppetto> yeh, got the final vote in the ticket 18:17:08 <tibbs|w> Maybe I'll add a "voting" state so we can easily see which tickets are just awaiting extra votes. 18:17:44 <geppetto> yeh 18:18:43 <tibbs|w> Wow, I forgot what the workflow system looked like. 18:18:59 * tomspur closes now https://fedorahosted.org/fpc/ticket/433 unless there are objections 18:19:19 <geppetto> no … was about to 18:19:22 <tibbs|w> Yeah. 18:19:25 <geppetto> I closed 436 18:19:35 <geppetto> just wasn't 100% on what state 433 goes into 18:19:46 <geppetto> Resolve as fixed? 18:20:02 <geppetto> or request approved? 18:20:44 <tomspur> uh... I set resolved as fixed now... 18:20:59 <mbooth> Sorry guys I have to leave, have a good rest-of-day everyone 18:22:20 <tibbs|w> I think "approve" and "deny" should probably just go away. 18:22:43 <tibbs|w> I'm not sure we need to use those; maybe I'll just take them out of the workflow. 18:22:45 <geppetto> maybe … I guess the idea is that we don't really have bugs that get fixed 18:23:00 <geppetto> maybe someone also ran a report at one point to see how much stuff got approved vs. denied 18:23:13 <geppetto> I'm not bothered though 18:24:03 <tomspur> maybe add a resolved as approved/denied to avoid the confusion with the other state? 18:24:12 <tomspur> (if that's possible) 18:26:08 <geppetto> not sure 18:27:28 <geppetto> tibbs|w: Any idea? 18:27:51 <tibbs|w> Not really. I will look at it. 18:28:22 <tibbs|w> I think the only thing special about "closed" is the default reports only look at that for determining active tickets. 18:28:28 <tibbs|w> But we can change the reports, so.... 18:28:54 * geppetto nods 18:29:04 * tomspur found it: https://fedorahosted.org/fpc/admin/ticket/resolution 18:30:07 <geppetto> ok, I'm going to close now … thanks for coming everyone 18:30:09 <geppetto> #endmeeting