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