16:00:54 <geppetto> #startmeeting fpc
16:00:54 <zodbot> Meeting started Thu Jun 22 16:00:54 2017 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:54 <zodbot> The meeting name has been set to 'fpc'
16:00:54 <geppetto> #meetingname fpc
16:00:54 <zodbot> The meeting name has been set to 'fpc'
16:00:54 <geppetto> #topic Roll Call
16:01:01 <tibbs> Howdy.
16:01:02 * limburgher here
16:01:05 <mbooth> Heya
16:01:11 <orionp> here - barely
16:01:48 <racor> here
16:01:53 <geppetto> #chair tibbs
16:01:53 <zodbot> Current chairs: geppetto tibbs
16:01:55 <geppetto> #chair limburgher
16:01:55 <zodbot> Current chairs: geppetto limburgher tibbs
16:01:58 <geppetto> #chair orionp
16:01:58 <zodbot> Current chairs: geppetto limburgher orionp tibbs
16:02:02 <geppetto> #chair racor
16:02:02 <zodbot> Current chairs: geppetto limburgher orionp racor tibbs
16:02:07 <geppetto> #chair mbooth
16:02:07 <zodbot> Current chairs: geppetto limburgher mbooth orionp racor tibbs
16:05:44 <geppetto> Ok, I guess that was it
16:06:08 <geppetto> #topic Schedule
16:06:09 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/ZZHZUV5PWCRT5IZ6SWCZ5FNA2KCJSPSY/
16:06:19 <geppetto> #topic #691 noarch *sub*packages with arch-specific dependencies
16:06:24 <geppetto> .fpc 691
16:07:00 <zodbot> geppetto: Issue #691: guidelines change: noarch *sub*packages with arch-specific dependencies - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/691
16:08:28 <limburgher> This seems still to be developing.
16:10:41 <geppetto> Yeh, I'm not sure … I feel like saying +1 and presuming til knows what is going on … but I feel like everything should just get fixed
16:11:03 <geppetto> like don't drop packages just because a single arch is bad, is an obvious and simple fix?
16:11:10 <limburgher> One would think.
16:12:19 <geppetto> tibbs: you actually commented, did you speak to anyone off ticket?
16:13:01 <racor> isn't this all more a releng issue but a packaging issue?
16:13:06 <tibbs> I did not, sorry.
16:13:30 <limburgher> Is there an example of a package affected by this?
16:13:38 <geppetto> racor: it looks like a packaging thing to workaround a releng thing
16:14:06 <racor> geppetto: why can't releng "work around" it?
16:14:10 <geppetto> tibbs: that's fine, was just being optimistic and hoping you'd tell us what to do :)
16:14:41 <geppetto> racor: I assume assume they would if they could
16:15:13 <Rathann> hi guys, sorry
16:15:19 <racor> geppetto: My gut feeling is, these case show up as broken deps, somewhere.
16:15:31 <geppetto> #chair Rathann
16:15:31 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp racor tibbs
16:15:45 <Rathann> current time is really not working well for me
16:16:11 <Rathann> I'm usually busy @home or running errands at this time
16:16:17 <geppetto> Rathann: yeh, was going to go over the when is good thing at some point
16:17:45 <tibbs> Sorry, had a work issue.
16:18:25 <tibbs> So basically the only part of the proposal that's on the table right now is the thing that says you can't use the noarch excludearch thing when you have subpackages.
16:18:38 <tibbs> Which I guess is true.
16:19:12 <tibbs> But that ticket is starting to morph into something else.
16:19:31 <Rathann> regarding #691, I'll be able to confirm that ExclusiveArch trick works when if I don't receive a "broken deps" mail within the next hour ;)
16:19:46 <tibbs> Honestly I'm thinking we should just table this until we get some more info.
16:19:52 <limburgher> Agreed.
16:19:57 <geppetto> I'm fine with that
16:20:09 <geppetto> #topic #692 Requesting clarification on static/bundling guidelines
16:20:12 <geppetto> .fpc 692
16:20:13 <zodbot> geppetto: Issue #692: Requesting clarification on static/bundling guidelines - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/692
16:21:51 <geppetto> I mostly agree with tibb's comment, although now that bundling is allowed I'm not sure why we should restrict static linking to other packages
16:22:05 <tibbs> I didn't have a chance to do the cleanup I mentioned there, but it does seem pretty obvious to me at least that the guideline was not intended to cover his case.
16:22:31 <tibbs> And I don't know that the bundling situation really has much bearing on whether we want static linking between packages.
16:23:06 <geppetto> Well I just think of static linking as a better form of bundling … so we don't want to limit it and force a worse form of bundling.
16:23:18 <limburgher> tibbs: Agreed. And of course we don't/ :)
16:23:33 <tibbs> I wouldn't really have a problem making it a "SHOULD NOT" instead of "you need approval from some committee".
16:23:42 <geppetto> sure
16:23:54 <geppetto> +1
16:24:12 <tibbs> But it's obvious that the distro as a whole just doesn't care about the potential security issues here.
16:24:53 <tibbs> And you're right that perhaps it is better than bundling because at least the dependency tracking is enforced and queryable at some level.
16:25:10 <orionp> works for me with the currently policies - and I suppose explicitly mentioning static linkage to external packages would clarify this situation
16:25:53 <tibbs> Well, does anyone disagree that the current guideline is supposed to be about linking statically to something provided by a different package?
16:26:14 <tibbs> As opposed to some .a file that happens to be produced as part of your build process.
16:26:19 <Rathann> I don't disagree ;)
16:26:25 <limburgher> Same.
16:26:29 <tibbs> Because a big load of packages would violate that otherwise.
16:26:36 <Rathann> and the upstream issue referenced in the review is informative
16:27:09 <Rathann> they clearly have plans to replace 3 out of 4 forked components with something else anyway
16:27:33 <geppetto> tibbs: yeh, like you I thought that was obvious
16:27:35 <Rathann> and the 4th one is practically maintained in their tree anyway
16:30:06 <tibbs> I have enough going on right now that I'm not going to be able to draft a proposal.
16:30:27 <tibbs> But I can take the general consensus and put something together.
16:30:45 <tibbs> If we could give him an answer that allows him to proceed, though, it might be good.
16:32:11 <geppetto> #info Everyone agrees wording applies to static linking to other packages, not within your package build
16:32:34 <tibbs> Good enough for me.
16:32:52 <geppetto> Vote on the "need approval from committee" to "SHOULD NOT" change?
16:33:33 <limburgher> +1
16:33:44 <Rathann> +1
16:34:14 <tibbs> +1
16:34:54 <racor> +1
16:34:56 <orionp> +1
16:35:34 <geppetto> +1
16:35:55 <geppetto> #action Change wording from  "need approval from committee" to "SHOULD NOT" (+1:6, 0:0, -1:0)
16:36:15 <geppetto> #topic #693 Wiki:Packaging:RPMMacros
16:36:21 <tibbs> Cool, I'll put that in there when I do some cleanup.
16:36:21 <geppetto> .fpc 693
16:36:22 <zodbot> geppetto: Issue #693: Wiki:Packaging:RPMMacros - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/693
16:37:04 <tibbs> I guess my opinion is clear from my comments, but I know that others here disagree about how useful those macros are.
16:37:31 <mbooth> Sorry guys I have to leave early :-(
16:37:53 <tibbs> I do think that if the page is going to stay, we should be clear on what it's for.
16:38:05 <tibbs> The name sort of implies that it documents all of the RPM macros, and, well, it doesn't.
16:38:13 <tibbs> "Useful RPM Macros", perhaps.
16:38:30 <tibbs> But that sounds like something that shouldn't be a part of the guidelines at all.
16:39:12 <geppetto> I think the idea here was that people could build and change prefix to /usr/local or whatever … but I'm pretty sure nobody ever does that, and it probably doesn't work anyway if you try.
16:39:13 <Rathann> move it out of Packaging: then?
16:39:58 <geppetto> I'm tempted to just delete it
16:40:13 <tibbs> SO looking at that page, there's the stuff about things that mimic autoconf, things that represent often longer versions of paths, three things about build flags (which are certainly wrong now) and something that's basically per-user RPM configuration.
16:40:33 <tibbs> And the latter is completely pointless if you're using fedpkg.
16:40:55 <geppetto> In the past couple of weeks I've actually wanted to know a couple of these … and I didn't look at this page, but the /usr/lib/rpm/macros and other rpm specific documentation
16:41:05 <Rathann> +1 to deleting it
16:41:06 <tibbs> I just run rpm --showrc.
16:43:30 * geppetto nods
16:43:35 <tibbs> +1 to deleting it, and creating another page that the community can edit.  Not sure it should contain a verbatim copy, though, as too much stuff there is out of date.
16:43:52 * geppetto nods … I'm happy with that too
16:43:59 <tibbs> However, if we do delete it, how do we handle the current bit of the guidelines which wants people to use those macros?
16:44:09 * racor also uses rpm --showrc, but that's not suitable for new comers.
16:44:46 <tibbs> What's suitable for newcomers is to just have them use the actual paths instead of having to figure out whether there's a macro for something.
16:45:04 <tibbs> https://fedoraproject.org/wiki/Packaging:Guidelines#Macros is the section of the guidelines I'm talking about.
16:45:15 <tibbs> "strongly encouraged" is the weakest I could get that language.
16:45:17 <racor> i.e. I am in favor of entitling this page "some macros" or similar
16:46:18 <Rathann> tibbs: s|see Packaging:RPMMacros|see <code>rpm --showrc</code>|
16:46:42 <Rathann> is rpm --showrc that scary?
16:46:43 <tibbs> I don't think that's a great idea.
16:46:50 <tibbs> It shows everything.
16:46:59 <tibbs> Even stuff that, well, you probably don't want to use.
16:47:14 <Rathann> then just delete the reference
16:47:19 <tibbs> We know that %_libdir is mandatory, and that's stated.
16:47:37 <Rathann> anyway, I'm sorry, but I have to leave earlier today
16:47:51 <tibbs> But we can't say that you're "strongly encouraged" to use some things and then not say what they are.
16:47:59 <Rathann> I'll vote in the ticket if there's a proposal
16:48:05 <limburgher> Rathann: Thanks!
16:48:22 * Rathann is afk
16:48:30 <tibbs> Becuase surely the intent is not to make someone use every single macro possible that they happen to find in rpm --showrc output.
16:48:55 <tibbs> Macros are great when they save you time.  They're needed when things move between architectures, like %_libdir.
16:49:35 <tibbs> And they're important when we have to encapsulate functionality that is bizarre, esoteric or is subject to change between versions.
16:50:02 <limburgher> Yeah, they scale better than sed-wielding carbon units.
16:50:19 <tibbs> But, sorry, %{_rundir} just doesn't make any sense.
16:50:24 * limburgher thinks that would be a lovely band name
16:50:26 <tibbs> Or %{_var}
16:50:40 <racor> another problem with --showrc is it contents being dynamic (i.e. it depends on other macros packages somebody has installed)
16:50:56 <tibbs> Yes, I mentioned that as being an issue in the ticket.
16:52:10 <tibbs> I just think that generally it's unwinnable, and prefer that we just let people use the real paths for things and point them to a page of macros that they are welcome to use if they like.  As long as a particular spec is consistent.
16:54:24 <tibbs> I would personally redo the Macros section to first talk a bit about the different types of macros (ones that hide paths, like %_sbindir, ones that hide executable names like %__rm, and important ones that encapsulate bits of functionality like %autosetup, %configure, or even %make_build.
16:55:08 <tibbs> It also hurts me to type curly brackets so, just like in shell code, I leave them off unless they're necessary.  But I try to leave them in when writing tutorials and guidelines and such.
17:00:00 <tibbs> Guess I typed too much.
17:03:07 <geppetto> I mean … I agree, and I think I'm not the only one :)
17:03:19 <limburgher> Not at all.  It's just that my salad arrived. . .
17:03:27 <geppetto> just how much we want to delete from the page
17:04:19 <geppetto> I just finished my salad :)
17:04:33 <limburgher> Ditto, just part of a roll left.
17:05:31 <geppetto> #info Everyone mostly agrees we need to get this out of packaging, and probably delete a bunch of data so it'll maybe help people
17:05:33 <limburgher> I think a core of standard macros, datadir, sysconfdir, bindir, name, etc, would be helpful, but the more obsure ones, like %meson_build, are handled in other places.
17:05:51 <tibbs> That's sort of what some of the current page is.
17:05:58 <geppetto> Is there anything we want to vote on today?
17:06:14 <tibbs> But then we get requests like the current one: Please document these additional macros.
17:06:58 <tibbs> If we can decide on a set of ones that we are strongly suggesting that people use, then we definitely need to put it somewhere within the guidelines.
17:06:59 <limburgher> They should go in the relevant subsections, so that if I don't touch, say, Go, or Ruby, I don't have to care.
17:07:13 <tibbs> And if we can't, then we really shouldn't be strongly suggesting that people use them.
17:07:31 <racor> don't we already have specialized pages for this (e.g. systemd, python, perl etc.)?
17:07:39 <limburgher> racor: Exactly.
17:08:38 <tibbs> For most of them, yes.
17:08:48 <tibbs> Not for things like %_sbindir or whatever.
17:08:58 <geppetto> Is prefix even useful?
17:09:31 <tibbs> In a hypothetical distribution that renames /usr, maybe.
17:09:38 <geppetto> I can't think of why … and if that isn't then I can't think of why any of the others would be
17:09:57 <geppetto> I guess _libdir needs to stay … but apart from that
17:10:02 <tibbs> The argument was always that we might move things around one day, and so using macros for everything saves effort.
17:10:09 <geppetto> yeh
17:10:18 <tibbs> %_libdir is a specal case that's already described in the main guidelines page anyway.
17:10:38 <geppetto> but we never have, and the things we did move weren't helped by the macros.
17:10:45 <tibbs> Thing is, if we're going to move /usr or even something like %_localstatedir then we have much more work to do than just tweaking specfiles.
17:11:03 * geppetto nods
17:11:15 <geppetto> I'm +1 to delete the page
17:11:25 <limburgher> Yeah, they really only save significant effort if they're universally applied.
17:11:29 <tibbs> Obviously I am +1 as well.
17:11:49 <limburgher> +1
17:12:23 <geppetto> racor: Rathann: orionp: Vote?
17:12:27 <tibbs> Maybe if "universally applied" meant that we had to go through and modify documentation and config files and source code to match, sure.
17:12:37 <racor> -1 to deleting the page.
17:12:51 <geppetto> Fair enough
17:13:00 <geppetto> Do we want to propose any other changes today?
17:13:18 <tibbs> racor: Are you suggesting that the page just needs to exist _somewhere_, or that it must exist within the guidelines?
17:14:08 <tibbs> Because regardless of what we do, I will make a separate page on the wiki that's not restricted to FPC folks that can be used to document these.  If that doesn't already exist.
17:14:30 <racor> tibbs: I consider https://fedoraproject.org/wiki/Packaging:RPMMacros the essential core of rpm macros. I could use some brushup, but deleting it would be a fatal mistake, IMO.
17:14:42 <tibbs> You didn't answer my question.
17:15:03 <racor> tibbs: Then we probably are talking past each other.
17:15:35 <tibbs> I asked a direct question two minutes ago.
17:15:38 <tibbs> ‎<‎tibbs‎>‎ racor: Are you suggesting that the page just needs to exist _somewhere_, or that it must exist within the guidelines?
17:17:07 <racor> tibbs: Let me rephrase what I already said: this page could us a brush up, but it should stay. It is a vital and essential piece of packaging documentation.
17:17:33 <tibbs> That still doesn't answer what I was asking.
17:17:53 <racor> tibbs: I feel you are playing foul games with me.
17:18:04 <tibbs> I understand that there is a language barrier.
17:18:45 <tibbs> I am asking if an equivalent, updated page located in a place the community can edit is acceptable to you.
17:19:08 <geppetto> racor: So you think that everyone better off using _bindir and _datadir instead of just putting real paths there?
17:19:23 <racor> tibbs: What for? This page already do what it is supposed to do.
17:19:25 <tibbs> geppetto: I don't think that was part of the question.
17:19:31 <racor> geppetto: Definitely.
17:19:51 <tibbs> racor: But yet I know you won't edit it to bring it up to date.
17:20:18 <tibbs> And so that work will fall to me.  And I don't think it's a valid use of this committee's time to keep changing that page to add random new macros.
17:20:27 <racor> tibbs: Actually I don't know what you want to change.
17:20:33 <tibbs> FFS.
17:20:42 <tibbs> Did you read the ticket we are discussing?
17:20:53 <tibbs> The person asked us to document macros that aren't documented there.
17:21:07 <tibbs> Doing that shouldn't require a committee action.
17:21:55 <racor> tibbs: Yes, he was asking for %_rundir
17:22:01 <limburgher> I think the crux of tibbs's argument is that macro documentation doesn't prescribe a particular action, it simply documents reality.
17:23:15 <limburgher> And since FPC covers How, and not What, it's not our bailiwick.
17:26:52 <limburgher> And now I'VE written too much.
17:27:45 <geppetto> ¯\_(ツ)_/¯
17:27:59 <geppetto> I've no idea where this is going, but I suspect nowhere atm.
17:28:07 <geppetto> So I'm going to move to...
17:28:12 <geppetto> #topic Open Floor
17:28:22 <geppetto> Ok, so the results …
17:28:26 <limburgher> +1 open floor.
17:28:43 <geppetto> http://whenisgood.net/4kkmgdf/results/9yq4ter
17:29:15 <geppetto> Our best times seem to be 1 hour later on Monday or Wednesday, or the next best being 1 hour later on Thursday
17:29:27 <geppetto> Each is only for an hour too
17:30:04 <geppetto> After that we might as well stay where we are now
17:31:01 <geppetto> BUT, the best we can do is only having 1 person at a bad time … no cases where we all wanted to meet.
17:32:15 <tibbs> That assumes we keep a single meeting time.
17:32:41 <tibbs> We could be inclusive of more people by alternating between two times.
17:33:10 <geppetto> That's an interesting idea … like every other week do Wed. 1pm and Thursday 1pm?
17:33:23 <geppetto> I could go for that.
17:33:49 <orionp> I'm fine to have it change
17:34:04 <tibbs> Well, 1pm in whatever zone the whenisgood is set to use) is the problem.
17:34:26 <geppetto> Yeh, that's 1pm Eastern
17:34:28 <tibbs> I'm thinking more of alternating between 11am and 1pm or something like that.
17:35:06 <geppetto> 1pm Eatern Mon/Wed/Thursday are the best times … sometimes by a lot.
17:35:43 <limburgher> I could do 1pm EDT if necessary, I just might have to miss the tail end occasionally.
17:35:52 <tibbs> True, but that excludes racor pretty much completely.
17:36:20 <tibbs> And mbooth/limburger have stops at 2pm.
17:36:39 <racor> tibbs: exactly 2pm EST is 19:00 CEST ... doesn't work for me
17:36:43 <geppetto> Yeh, there's no good 2 hour slots really
17:36:54 <tibbs> Well, we should try to avoid two hour meetings anyway.
17:37:03 <tibbs> We really should all be doing more in tickets.
17:37:05 <geppetto> So maybe alternate between Wed. 1pm and Thursday noon?
17:37:06 <racor> correction 1pm EST=19:00 CEST
17:37:46 <limburgher> tibbs: Agreed
17:37:55 <limburgher> geppetto: that could work.
17:38:26 <tibbs> Also tomspur's time is incredibly restricted.  But I'd think that the more restrictive your schedule is, the more likely you'd be to try to do things in the tickets.
17:38:39 <tibbs> We can have useful discussions either way.  Well, theoretically.
17:39:38 <racor> It's 19:40 CEST right now => I need to quit now ;)
17:40:24 <limburgher> racor: Thank you!
17:40:38 <tibbs> Honestly we're lucky we can get that many good times.
17:40:53 <geppetto> Ok, I'll propose the dual timeslot to the list … see what people say there
17:40:59 <geppetto> Anything else, or we done?
17:41:06 <limburgher> I updated my availability on the whenisgood to reflect the fact that i forgot I can do IRC on my phone.
17:41:50 <limburgher> Not I, said the duck.
17:41:53 <geppetto> I don't think that changed anything :)
17:42:01 <limburgher> No, not likely.
17:42:18 <tibbs> We should at least try to be inclusive, but somehow we got in this mess of having committee members who can't come to meetings.
17:43:26 <tibbs> Anyway, I'm certainly done.
17:43:41 * geppetto nods
17:43:55 <geppetto> ok, I'll close in a minute or so unless someone shouts
17:49:24 <geppetto> #endmeeting