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