17:00:56 <geppetto> #startmeeting fpc 17:00:56 <zodbot> Meeting started Thu Jan 7 17:00:56 2016 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:56 <zodbot> The meeting name has been set to 'fpc' 17:00:57 <geppetto> #meetingname fpc 17:00:57 <zodbot> The meeting name has been set to 'fpc' 17:00:57 <geppetto> #topic Roll Call 17:01:08 <orionp> Hello 17:01:38 <geppetto> #chair orionp 17:01:38 <zodbot> Current chairs: geppetto orionp 17:01:56 <tomspur> Hey 17:02:14 <geppetto> #chair tomspur 17:02:14 <zodbot> Current chairs: geppetto orionp tomspur 17:03:41 * orionp doesn't seem to get notifications of new FPC tickets, should he? 17:04:17 <geppetto> yeh, you should get emails for each new ticket and each comment 17:04:23 <tomspur> I noticed that the notifications take really long today 17:04:36 <tomspur> Might need ~10-15mins or so... 17:04:42 <geppetto> oh, yeh 17:04:47 <orionp> I'm never seeing them... 17:05:07 <tomspur> Aaah, new FPC tickets... 17:05:27 <tomspur> orionp: So no pings about this meeting, you mean the tickets from track? 17:05:47 <orionp> I mean tickets in trac 17:06:33 <tomspur> There was an option in trac to subscribe to them, somewhere 17:08:14 <tomspur> orionp: It's "smtp_always_bcc" in the trac administration 17:08:55 <orionp> tomspur: what section? 17:11:01 <orionp> that should help 17:11:15 <tomspur> So it seems we are 3 today? 17:11:50 <geppetto> yeh 17:11:56 <tomspur> Hmm, there was something about the German holiday from yesterday, but I thought only racor would be missing then 17:12:10 <geppetto> I know tibbs was up late last night 17:12:35 <geppetto> meh. … can skip one more week 17:12:54 <tibbs|w> Hey. 17:12:55 <geppetto> getting two more seems unlikely, so I'll close at 15 past 17:12:59 <geppetto> #chair tibbs 17:12:59 <zodbot> Current chairs: geppetto orionp tibbs tomspur 17:13:33 <mbooth> Hi 17:13:38 <geppetto> #chair mbooth 17:13:38 <zodbot> Current chairs: geppetto mbooth orionp tibbs tomspur 17:14:05 <geppetto> My special double reverse bluff worked ;) 17:14:57 <geppetto> tibbs: Is the discussion above about orionp getting emails the correct/normal fix? 17:15:08 <geppetto> (if you know) 17:15:39 <tibbs|w> Hmm, I thought it went out to the fas group but... I think the fas group is new so there must be a list in trac. Let me take a look. 17:15:55 * geppetto nods … cool. And thanks. 17:16:08 <tibbs|w> "orion" is trac_admin. 17:16:08 <geppetto> #topic Schedule 17:16:14 <geppetto> https://lists.fedoraproject.org/archives/list/packaging%40lists.fedoraproject.org/message/H4SRQRXL6URL44MXGIZ3MYGJQC7QIUWI/ 17:16:43 <orionp> I added myself to the bcc list 17:16:54 <geppetto> #topic #584 Update to latest AppData specification 17:16:58 <geppetto> .fpc 584 17:16:59 <zodbot> geppetto: #584 (Update to latest AppData specification) – fpc - https://fedorahosted.org/fpc/ticket/584 17:17:00 <geppetto> https://fedorahosted.org/fpc/ticket/584 17:18:10 <tibbs|w> orionp: For future reference, where did you do that? 17:19:06 <mbooth> https://fedorahosted.org/fpc/admin/tracini/notification ? 17:19:09 <tibbs|w> For 584, We should obviously follow upstream specifications. 17:19:15 <tibbs|w> This is just changing the example, right? 17:19:15 <geppetto> I'm not sure 17:19:26 <geppetto> The only difference I see is the dropped _ from update_contact 17:19:40 <geppetto> But given it has the same copyright year, I'm wondering if it's a typo 17:19:58 * tomspur doesn't see a (visual) difference 17:20:14 <geppetto> altough I guess it could be a typo in the version that made it into Packaging: 17:20:33 <orionp> It would be good if the submitter prepared a new page so we could see 17:20:39 <orionp> the changes 17:21:00 <tomspur> There is a <image> tag for the jpgs 17:21:28 <tibbs|w> orionp: Yes. 17:21:35 <orionp> application -> component type=desktop ? 17:21:47 <geppetto> yeh, wouldn't hurt to have richard review the changes too 17:21:53 <tibbs|w> Still, are these still entirely hand-generated? 17:22:43 <tibbs|w> I'm just wondering if we really need a complete example here. 17:22:45 <geppetto> Ahh, yeh, the very top changed … maybe so they can put non GUI apps. in there, only N years later than asked for but still … 17:22:55 <geppetto> That makes it less likely the differences are typos. 17:23:13 <tibbs|w> Maybe I should just use the sample from https://secure.freedesktop.org/~hughsient/appdata/ directly. 17:23:28 <tibbs|w> It's completely different. 17:24:49 <tibbs|w> BTW, I edited the ticket so that you can actually read things. 17:25:00 <geppetto> ahh, coool … reloads 17:26:44 <tibbs|w> Hell, I just wrote it up and will revert if necessary. 17:26:48 <tibbs|w> https://fedoraproject.org/w/index.php?title=Packaging%3AAppData&diff=431361&oldid=413661 17:26:49 <geppetto> Ok 17:26:51 <tibbs|w> That's what changed. 17:27:13 <tibbs|w> Didn't feel like copying the thing to another page just to generate a diff. Call me lazy. 17:27:35 <geppetto> Yeh, it's probably fine … the other upstream example seems consistent with the new version. 17:27:46 <orionp> thanks, looks good 17:27:50 <geppetto> No idea what that means for older Fedora or EPEL7 … but meh 17:28:39 <tomspur> So all existing appdata files must change at one point, or do they both work? 17:28:51 <mbooth> Ugh, I hope older appdata files still work 17:29:16 <tibbs|w> This is why this kind of ticket is annoying. 17:29:34 <tibbs|w> No useful information besides "change this". 17:29:47 <tomspur> http://people.freedesktop.org/~hughsient/appdata/ explains it a bit 17:30:04 <mbooth> Hughsie is a smart guy so I'm sure it's fine, but it wouldn't hurt to confirm with him that the old format still works 17:30:08 <tomspur> appstream-util upgrade upgrades the old format to the new one 17:30:32 <tomspur> "You can continue to use the old format" 17:30:50 <mbooth> Yay, cool 17:31:16 * mbooth adds updating some of these to his todo 17:31:51 <geppetto> #action Updated the example using info. from ticket and upstream. 17:32:00 <tomspur> I favor the change. A comment of Hughsie in the ticket would still be nice. Maybe he didn't submit the ticket because of ....? 17:32:17 <geppetto> #topic #585 Blanket reauth. of bootstrapping exceptions (Free Pascal 17:32:21 <geppetto> .fpc 585 17:32:22 <zodbot> geppetto: #585 (Blanket reauth. of bootstrapping exceptions (Free Pascal Compiler, atm.)) – fpc - https://fedorahosted.org/fpc/ticket/585 17:32:27 <geppetto> https://fedorahosted.org/fpc/ticket/585 17:32:36 <geppetto> I'm +1 on this. 17:32:47 <tibbs|w> +1 17:33:05 <tomspur> +1 17:33:13 <tibbs|w> If a package needs bootstrapping once, we should assume there's a good chance of it needing to be bootstrapped again. 17:33:21 <orionp> +1 17:33:29 <tibbs|w> And we shouldn't make them run through us every time they need to flip a flag and rebuild. 17:33:33 <mbooth> +1, but I thought there was provision for bootstrapping anyway 17:33:37 * mbooth shrugs 17:34:09 <mbooth> tibbs|w: That's good because I probably rebootstrap a few times a year 17:34:25 * geppetto nods … I'm kind of surprised this wasn't already true 17:34:37 <geppetto> I think most people who bootstrapped just assumed it was too ?;) 17:34:42 <tibbs|w> I think it's less untrue than it is simply unspecified. 17:34:59 <mbooth> geppetto: You are probably right :-) 17:35:01 <tibbs|w> We say "if you need to bootstrap, contact us for approval" but we don't really say what the approval gets you. 17:35:03 <geppetto> #action Blanket reauth. of bootstrapping exceptions (+1:5, 0:0, -1:0) 17:35:18 <tibbs|w> I wonder if we actually keep track of the exceptions. 17:35:26 <geppetto> haha 17:35:37 <tibbs|w> I should probably make another type of ticket for it so we could at least query. 17:35:42 <tibbs|w> I'll do a search. 17:36:20 <geppetto> #topic #567 Packaging Python 3 applications and modules for EPEL 7+ 17:36:25 <geppetto> .fpc 567 17:36:27 <zodbot> geppetto: #567 (Packaging Python 3 applications and modules for EPEL 7+) – fpc - https://fedorahosted.org/fpc/ticket/567 17:36:29 <geppetto> https://fedorahosted.org/fpc/ticket/567 17:36:58 <geppetto> orionp: last comment from you 17:37:05 <orionp> yup 17:37:38 <orionp> This have changed a little again I think 17:37:48 <tibbs|w> My fancy new python macros idea turned into sort of a mess because I've just been working on other things. 17:38:00 <orionp> https://bugzilla.redhat.com/show_bug.cgi?id=1294904 is my current review 17:38:02 <tibbs|w> Unless that's what orion is actually working on pushing. 17:38:13 <tibbs|w> I unfortunately haven't been keeping track. 17:38:26 <orionp> It will produce a python-srpm-macros package that will be required by redhat-rpm-config 17:38:37 <geppetto> So you want p-srpm-m for buildroots, that gets automatically pulled in by deps. … and p-rpm-m that is the same? Why can't people just install the p-srpm-m ? 17:39:15 <orionp> No, p-rpm-m is different - the build time macros 17:39:50 <orionp> I think it's worth keeping the buildroot deps/macros small 17:40:21 <tibbs|w> You know, I think we should have a fedora-rpm-config package and collect macros there. 17:40:55 <tibbs|w> I don't think it's a good idea to have a proliferation of macro packages, because people will complain about "bloat". 17:40:57 <Rathann> hello, sorry for being late 17:40:58 <tomspur> tibbs|w: And all macros are pushed/changed by us? 17:41:00 <tibbs|w> When it's just one file. 17:41:12 <geppetto> #chair Rathann 17:41:13 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs tomspur 17:41:17 <tibbs|w> tomspur: Not necessarily FPC, no, but that's an idea. 17:41:28 <tibbs|w> Actually not a bad one; I hadn't thought of that. 17:42:08 <tomspur> tibbs|w: With different python-rpm-macros/ruby-rpm-macros all can be changed in their areas without us involved (at least not the implementation details) 17:42:28 <tibbs|w> It's just that redhat-rpm-config is more complicated that it probably should be, and so it would perhaps be simpler to have the macros elsewhere, but I do think we want to keep the proliferation of macro packages down. 17:42:49 <tibbs|w> Especially if we're going to get behind the idea of having more macros directly in the buildroot by default. 17:43:05 <tibbs|w> But we could also just limit the package to macros that absolutely must be there at srpm build time. 17:43:34 <tibbs|w> I just don't like having to make that distinction, or having packagers do magic things to work around the lack of macros at srpm build time. 17:43:39 <orionp> Whatever is in the buildroot should only have macros for building srpms imo 17:44:59 <tomspur> I would like the fedora-rpm-config package. One package for all buildroot macros. 17:44:59 <tibbs|w> I disagree, because that gets unto the complication of having to worry about how to split things. 17:45:18 <orionp> I lean towards the federated approach, but not particularly strongly 17:45:51 <tibbs|w> Sorry, what do you define as the federated approach. 17:45:53 <tibbs|w> ? 17:46:34 <tibbs|w> Just having the fedora-rpm-config package with everything, or having a fedora-rpm-config package with the minimal amount of macros for building srpms? 17:46:38 <geppetto> I'm guessing a list of deps. on SIG managed packages? 17:46:52 <orionp> redhat-rpm-config requiring various *-srpm-macros package rather than containing all of them itself 17:47:41 <orionp> It does a mixture at the moment 17:47:50 <tibbs|w> I would really like to keep the package proliferation down because otherwise we will eventually have to have that argument. 17:47:59 <tibbs|w> Actually, people are already complaining about it. 17:48:31 <tibbs|w> And I do think we should at least consider the idea of gating through FPC for this. 17:50:46 <tibbs|w> Offtopic: I need to add something to the Talk page of each guideline page indicating that you shouldn't use the Talk pages. 17:50:53 <tibbs|w> I wonder if we can just disable them. 17:50:59 <Rathann> +1 to reducing the number of macro packages 17:52:11 * orionp really doesn't see what the problem is with having many macro packages... 17:52:28 * tomspur also 17:52:31 <tibbs|w> They all have to get installed at every buildroot init. 17:52:47 <tibbs|w> And people are already complaining that this means a bunch of macros get pulled in. 17:53:23 <Rathann> buildroot init is the slowest part of the build process for small packages 17:53:54 <geppetto> do small packages really affect that though? 17:53:56 <orionp> Well, the srpm-macros are going to be there regardless 17:53:59 <tibbs|w> I don't think it's a huge thing, but, well, I'd like to avoid those arguments. 17:54:12 <geppetto> My guess would be no … that the major problem would be large packages like glibc … and/or scriptlets 17:56:11 <Rathann> anyway, I think we should at least mandate some naming convention for macro/hook packages, for example rpm-build-foo 17:56:28 <tibbs|w> Agreed, but I don't want to bikeshed. 17:56:45 <orionp> I think we already are close to a convention 17:56:48 <tibbs|w> Someone looked up which convention was currently the most used. 17:56:52 <orionp> in pratice 17:56:56 <tibbs|w> Let's just go with that unless it really sucks. 17:57:08 * geppetto nods 17:57:45 <orionp> at least for macros - not for fileattrs 17:58:07 <orionp> anyway, back to buildroot macros maybe? 17:58:57 <tibbs|w> What are the current questions? 17:58:58 <orionp> We have a current convention of *-srpm-macros required by redhat-rpm-config, which seems fine by me 17:59:25 <Rathann> yeah, it's not too bad 17:59:50 <mbooth> I have to leave in a sec, but it doesn't look like there anything to vote on right now? 18:00:19 <orionp> I'm going to produce a python-srpm-macros sub-package from python-rpm-macros and add it to the redhat-rpm-config requires 18:00:24 <geppetto> no, and this should be the last ticket 18:00:44 <tibbs|w> Actually, there should be one more thing beyond this. 18:00:47 <orionp> This is slightly different than was what agreed to 18:03:51 <orionp> tibbs|w: ? 18:04:08 <tibbs|w> I meant that there's another ticket to consider after this one. 18:04:13 <geppetto> which one? 18:04:37 <geppetto> 580? 18:04:44 <tibbs|w> Yeah. 18:04:56 * geppetto hadn't seen any updates so assume nothing to do this week 18:05:08 <tibbs|w> Because I totally forgot to hit the submit button on the draft I wrote last night 18:05:19 <geppetto> Ahh 18:05:52 <tibbs|w> https://fedorahosted.org/fpc/ticket/580#comment:6 18:05:57 <tibbs|w> Promised I would do that. 18:06:27 <tibbs|w> I also did send a ticket to fesco, https://fedorahosted.org/fesco/ticket/1514 18:07:43 <tibbs|w> It got some discussion at the meeting before the holidays but I didn't get a ping about it yesterday so perhaps they didn't get to it. 18:08:32 <Rathann> I think it's too soft 18:08:35 <tibbs|w> Anyway, I guess that's just a status update unless folks want to vote on the draft. 18:09:00 <Rathann> I'd say "Such code should be regenerated as part of the build process." at the beginning of the last paragraph 18:09:07 <tibbs|w> Rathann: Too soft how? We agreed on "suggesting code should be regenerated". 18:09:33 <tibbs|w> I can go with "should" except that I'm not entirely sure that's actually the correct thing to say. 18:09:52 <tibbs|w> Do we really want running autoreconf to be a "should"? 18:10:21 <tibbs|w> Also, there's a question about configure in general and whether this guideline should apply to that at all. 18:10:54 <tibbs|w> Well, autoconf stuff. Or build infrastructure in general, I guess. As opposed to the code that's actually compiled into the package. 18:11:03 <tibbs|w> Also, documentation, too. 18:11:29 <tibbs|w> I'm happy without making the distinction, though. 18:12:39 <orionp> I really don't see the point in regenerating this stuff unless it fixes an issue 18:12:55 <orionp> Though certainly someone should be able to if desired 18:13:04 <tibbs|w> Which is why I left it as "suggested". 18:13:12 <geppetto> yeh, I'm fine with your wording 18:13:22 <geppetto> Rathann: Why do you want it to be should or must? 18:13:53 <geppetto> #topic #580 [Clarification] Policy on auto-generated code 18:13:59 <geppetto> .fpc 580 18:13:59 <zodbot> geppetto: #580 ([Clarification] Policy on auto-generated code) – fpc - https://fedorahosted.org/fpc/ticket/580 18:14:19 * geppetto changes the topic, as that seems to be what we are talking about now. 18:15:49 <geppetto> I'm +1 on the draft in comment 6 18:16:00 <geppetto> Anyone else want to vote, or leave it for next week? 18:16:20 <tibbs|w> I'm +1 but of course we can strengthen it if there's call for it. 18:16:24 <orionp> I'm +1 18:16:38 <tibbs|w> Or split out build infrastructure or whatever. 18:16:54 <Rathann> I'm basically only concerned about packager's ability to patch the sources if necessary 18:17:26 <Rathann> you can leave the wording as is for now, until FESCo responds to the ticket 18:17:55 <tibbs|w> Once fesco does kick in then there will need to be an additional bit about that kind of thing. 18:18:04 <tibbs|w> Of course we could wait until they respond to do anything. 18:18:04 <Rathann> +1 for now 18:18:10 <tomspur> +1 18:19:29 <geppetto> #action new section: Use of pregenerated code (+1:5, 0:0, -1:0) 18:19:38 <geppetto> #topic Open floor 18:19:43 <tibbs|w> I'll write it up. 18:19:47 <geppetto> Ok, anything anyone wants to speak about before lunch? 18:19:57 <tibbs|w> So did we actually get anywhere on 567? 18:20:32 <geppetto> 567 I don't think so 18:21:03 <geppetto> I don't mind orion's federated way … but I'm not against having a single macros package either, esp. if it's controlled by fpc 18:21:40 <tibbs|w> I think we should think about the "fpc approving macros" thing a bit more and separately. So I guess I'll open a ticket on that. 18:21:41 * geppetto shrugs 18:21:49 * geppetto nods 18:23:13 <geppetto> If there's nothing else I'll close in a couple of minutes 18:23:20 <tibbs|w> Yeah, I'm out. 18:25:38 <tibbs|w> And I just want to add one off-topic thing: Fuck cancer. 18:25:43 <Rathann> me too, thanks guys 18:25:59 <tibbs|w> A friend of mine died this morning. 18:26:16 * orionp gives his condolences... 18:26:22 <tibbs|w> Triple negative breast cancer; they gave her three months and she lasted two weeks. 18:26:40 <tibbs|w> Most horrible thing I've seen. 18:26:56 <geppetto> :( 18:27:02 <tomspur> :/ 18:28:44 <tibbs|w> Thanks for that. I'm off. 18:28:58 <geppetto> #endmeeting