16:00:20 <geppetto> #startmeeting fpc
16:00:20 <zodbot> Meeting started Thu May 24 16:00:20 2018 UTC.
16:00:20 <zodbot> This meeting is logged and archived in a public location.
16:00:20 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:20 <zodbot> The meeting name has been set to 'fpc'
16:00:20 <geppetto> #meetingname fpc
16:00:20 <geppetto> #topic Roll Call
16:00:20 <zodbot> The meeting name has been set to 'fpc'
16:00:30 <mbooth> Hi
16:00:30 <redi> hi
16:00:34 <geppetto> #chair mbooth
16:00:34 <zodbot> Current chairs: geppetto mbooth
16:00:36 <geppetto> #chair redi
16:00:36 <zodbot> Current chairs: geppetto mbooth redi
16:00:52 <tibbs> Howdy.
16:00:56 <geppetto> #chair tibbs
16:00:56 <zodbot> Current chairs: geppetto mbooth redi tibbs
16:01:03 <ignatenkobrain> .hello2
16:01:04 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:01:16 <geppetto> #chair ignatenkobrain
16:01:16 <zodbot> Current chairs: geppetto ignatenkobrain mbooth redi tibbs
16:02:19 <tibbs> decathorpe indicated he would not be here today.  And mhroncok is out for this week and the next.
16:02:31 <geppetto> ok
16:05:01 <geppetto> #topic Schedule
16:05:03 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/5ICHLHX6BAVTJV4RLSPAWL5VV5NW7DTD/
16:05:54 <geppetto> #topic #719 Simplify packaging of forge-hosted projects
16:05:56 <geppetto> .fpc 719
16:05:59 <zodbot> geppetto: Issue #719: Simplify packaging of forge-hosted projects - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/719
16:06:39 <geppetto> so do we need to wait for decathorpe for this?
16:06:44 <geppetto> tibbs: ?
16:07:02 <tibbs> He is far more familiar with the issues there than I am.
16:07:41 <tibbs> It seems that the underlying issue here is that the versioning guidelines require that the date be included in there next to the git hash.
16:08:38 <tibbs> So they invented a method of automatically including it, but that assumes that the timestamp on the tarball is always maintained, which works but isn't really guaranteed by anything.
16:09:16 <tibbs> My only real contribution there was to say that if we want to revisit the requirement that the date be included, that should happen as a separate discussion.
16:09:50 <tibbs> It's not a discussion which I particularly want to have yet again, but I do understand the issue.
16:10:09 * geppetto nods
16:10:49 <tibbs> No ticket has been filed for that, so... I don't know what the path forward is.  Maybe decathorpe would have more of an idea when he's back.
16:10:56 <tibbs> Can ping the ticket for updates, I guess.
16:11:28 <tibbs> Or we can talk about whether automatically determining the date like that is something we would accept.
16:12:03 <tibbs> Personally I don't really like it because it's far too fragile.
16:12:06 <geppetto> eh, I'm fine with it … as I assume it will mostly just work.
16:12:45 <tibbs> I honestly don't know that it will "just work", but it does appear to work through the buildsystem.
16:12:46 <geppetto> anyway …
16:12:48 <geppetto> #topic #657 Keeping packager tooling in sync with our guidelines
16:12:50 <geppetto> .fpc 657
16:12:52 <zodbot> geppetto: Issue #657: Keeping packager tooling in sync with our guidelines - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/657
16:13:25 <tibbs> This was more of a general question about how much responsibility we as a committee should have over some of the packaging-related tools.
16:13:52 <redi> "it depends" would be my unhelpful answer :)
16:14:04 <tibbs> Currently we sort of ignore the fact that rpmlint and (expecially) fedora-review can be way out of sync the guidelines.
16:14:23 <redi> I think expecting the FPC to update rpmdev-newspec seems reasonable
16:14:43 <tibbs> Interestingly I did try to fix some of those things up in the past.
16:14:56 <tibbs> And the problem there is "but they might be making a spec for RHEL4".
16:15:05 <redi> ugh
16:15:17 <tibbs> Of course, that was back when we still supported RHEL4.
16:15:38 <tibbs> I would say that these days, if it's really bad then we should just change it and if someone yells then they'll yell.
16:16:45 <tibbs> But these days, rpmdev-newspec is, well, almost OK.
16:16:58 <tibbs> Still has "rm -rf $RPM_BUILD_ROOT" for some unknown reason.
16:17:03 <redi> I think I agree with mhroncok that filing bugs against the bigger tools should be FPC's job, but not fixing it directly
16:17:32 <tibbs> That's different from saying that we shouldn't fix things if we are able (i.e. have the time).
16:17:40 <redi> but if somebody on FPC happens to be comfortable changing the tool, they can send a pull req instead, or attach a patch to the bug
16:18:16 <redi> so is the decision that needs to be made just "should FPC push fixes directly, or ask maintainers to do it?" ?
16:18:24 <geppetto> yeh, in an ideal world … I just don't see having time for that in the near future.
16:18:47 <tibbs> Again, there's a difference between not having the time to do it, and deciding that we shouldn't do it even if we have the time.
16:19:14 <geppetto> I think "ask anyone who can do it to do so" … and, in theory, that person could be us too ;)
16:19:20 <redi> :)
16:19:56 <geppetto> I feel that being the maintainer for rpmlint shouldn't mean you have to write all the rpmlint changes as policy changes either … but obviously someone should do it at some point.
16:20:00 <geppetto> ¯\_(ツ)_/¯
16:22:16 <tibbs> https://bugzilla.redhat.com/show_bug.cgi?id=1523826 is perhaps a useful example.
16:22:34 <geppetto> tibbs: is there anything you want to vote on … we seem to be mostly in agreement that we can do it if we have time, but we probably don't
16:23:09 <tibbs> Nah, I don't think there's any consensus for the committee becoming more involved in those things.
16:23:12 <geppetto> yeh, that can just be removed now
16:23:43 <tibbs> Right, but it seems that rpmdev-newspec will actually let you make a spec for different RPM versions.
16:23:44 <geppetto> I guess I might find time to do a PR to just delete the line … but I'm not sure if the maintainer wants something more for some reason.
16:23:58 <tibbs> The problem is that it has no ability to make a spec for different _Fedora_ versions.
16:24:09 * geppetto nods
16:24:15 <tibbs> So, for example, it's wrong about ldconfig.
16:24:24 <tibbs> But it understands when to add %license.
16:24:45 <redi> should 1523826 be moved back to rawhide and get the FutureFeature keyword?
16:24:52 <tibbs> Anyway, I guess that we as a committee shouldn't really worry about this.  But if one or more of us wants to, then fine.
16:25:33 <tibbs> I guess that would be up to Neal.  I thought the maintainer was still Ville, who was resistant to changes of this nature.  But Neal would probably be willing to work on it.
16:26:17 <tibbs> Anyway, I say we can close this and if I'm bored I can do a survey of how unsynchronized the tooling is.
16:26:58 <geppetto> #info Committe doesn't mind doing work ourself, if we have time … which we often don't.
16:28:06 <geppetto> #action tibbs In his copious free time will survey how out of sync. the tooling is.
16:28:09 <geppetto> #topic #723 Guidelines for handling deprecated dependencies during review
16:28:13 <geppetto> .fpc 723
16:28:15 <zodbot> geppetto: Issue #723: Guidelines for handling deprecated dependencies during review - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/723
16:28:35 <geppetto> Draft:
16:28:37 <geppetto> #link https://fedoraproject.org/wiki/User:Churchyard/Packaging:Deprecating_Packages
16:31:31 <geppetto> I'm fine with it, if ignatenkobrain wants a simple "Provides: deprecated()" I'm fine with adding that too … but generally the %name thing is what we've done.
16:32:22 <geppetto> Hmm, I would change the MUST NOT depend to a SHOULD NOT.
16:32:31 <tibbs> For some reason I missed the fact that there was a draft.
16:33:21 <tibbs> I have no preference for Provides: deprecated() versus Provides deprecated(%name).  Or even both.
16:35:41 <tibbs> So, MUST NOT versus SHOULD NOT.....
16:36:37 <tibbs> I think the initial request was that _new_ packages could not depend on any deprecated packages.
16:37:39 <tibbs> But the case where a package comes along and starts depending on something that is deprecated is also a case I think we'd want to avoid since the idea is to trend towards nothing depending on any particular deprecated thing.
16:38:24 <geppetto> Yeh, it's weird … I probably agreed completely before, but the example of net-tools (aka. ifconfig) is making me reconsider.
16:38:59 <tibbs> How so?
16:39:13 <tibbs> I mean, it is taking forever to deprecate net-tools.
16:39:24 <geppetto> just that if something came along and decided they want to depend on ifconfig it seems silly to say no that's not allowed.
16:39:33 <tibbs> Which I think was actually the initial impetus for this request being filed.
16:40:17 <tibbs> I think that's just the point, though.  If a real fesco-approved deprecation of net-tools is happening, then why should anything start depending on ifconfig now?
16:40:33 <tibbs> Or rather, why should anything be allowed to start depending on ifconfig now?
16:40:35 <redi> if something depends on a deprecated package, should we say it MUST itself be deprecated?
16:40:47 <tibbs> redi: I don't think so.
16:40:50 <redi> ok
16:41:02 <tibbs> Lots of things just needed a rebuild to get rid of libwrap.
16:41:19 <tibbs> All of those things certainly shouldn't have been deprecated.
16:41:29 <redi> sorry, I phrased that badly, I was only thinking about new packages being added, which depend on deprecated things
16:42:03 <redi> so if somebody wanted to add something depending on ifconfig, that new thing is itself deprecated (otherwise it'll just disappear without deprecation if net-tools ever goes)
16:42:21 <geppetto> I was just thinking of some random tool that uses ifconfig in some way, it seems bad to say you can't be in fedora because net-tools is deprecated … even though we expect it to be around another 5 years anyway.
16:42:27 <tibbs> Seems beyond foolish to do that, though.
16:42:55 <tibbs> geppetto: Indeed, I do see the point.  It's mainly because net-tools is taking absolutely forever to actually go away.
16:43:16 <geppetto> it's almost like backwards compatibility is a thing people care about
16:43:26 * geppetto ᕕ( ᐛ )ᕗ
16:43:29 <tibbs> It's an interesting point.
16:43:57 <tibbs> I mean, there's a difference between something we provide because end-users expect to be able to run ifconfig, and something that packages in the distribution should actually use.
16:44:16 <geppetto> I guess that's fair
16:44:26 <tibbs> Witness the various old python interpreter versions that are supplied, which all packages in the distribution are forbidden to depend upon.
16:45:06 <tibbs> But that only indicates that the topic is nuanced enough that perhaps blanket prohibition might be going too far.
16:45:47 <geppetto> I won't vote against MUST if everyone else thinks it's better
16:46:07 <geppetto> if something comes up people can always open a ticket (or just ignore it ;)
16:46:34 <tibbs> Yep, it's fun to spend time thinking about this stuff which will just be ignored when someone wants to do something anyway.
16:47:01 <geppetto> Do we want to vote on it then?
16:47:18 <geppetto> +1
16:47:22 <tibbs> Or does anyone else have a preference between should or must?
16:47:31 <tibbs> I'm +1 and have no real preference.
16:48:20 <geppetto> redi: mbooth: ignatenkobrain: vote?
16:48:56 <redi> what exactly is the vote, to change MUST to SHOULD?
16:49:07 <tibbs> It's a vote on the draft as presented, I assume.
16:49:11 <redi> ah ok
16:49:15 <redi> +1
16:49:26 <geppetto> yeh, draft as is
16:49:29 <tibbs> But if you have a preference for must/should, feel free to state it.
16:49:33 <redi> not really
16:49:37 <ignatenkobrain> I'm +1 if we don't add a name. this would simplify automation.
16:50:13 <ignatenkobrain> because running whatprovides("deprecated()") is fast while whatprovides("deprecated(*)") is not
16:50:15 <geppetto> ignatenkobrain: can't dnf do wildcard queryies like whatprovides deprecated(*) ?
16:50:20 <ignatenkobrain> I don't have preference between MUST and SHOULD
16:50:38 <tibbs> Is there any situation at all where the name there would be useful?
16:50:39 <ignatenkobrain> it can
16:50:40 <ignatenkobrain> but it's slower
16:50:41 <ignatenkobrain> I mean "much" slower
16:50:49 <ignatenkobrain> if you have thousands of packages
16:50:56 <geppetto> ignatenkobrain: If you want to change the draft to include both, I'm fine with it … but a few extra seconds for automated stuff doesn't seem like a big deal.
16:50:58 <tibbs> I mean, if you want to know what depends on net-tools, you just ask what depends on net-tools.
16:50:58 <ignatenkobrain> tibbs: I don't think so
16:51:30 <tibbs> I certainly hope nobody would ever try to dnf install 'deprecated()'.
16:51:39 <geppetto> tibbs: :)
16:52:53 <geppetto> ignatenkobrain: so, vote or change the draft?
16:53:11 <tibbs> For the record I'm fine with and without %name there.
16:53:23 <ignatenkobrain> I would prefer to change draft to remove %name
16:53:25 <tibbs> I just want the packages to be marked with _something_.
16:53:36 <ignatenkobrain> there is no point in having it there
16:53:38 <ignatenkobrain> at least I couldn't find any use for it
16:54:04 <ignatenkobrain> but this is so trivial that we can do it during import of page
16:54:20 <ignatenkobrain> can we vote for removal of %name and accepting this?
16:54:41 <redi> +1
16:54:41 <geppetto> mbooth: opinions? vote?
16:55:11 <tibbs> +1 without %name as well.  (I'm Mr. +1 today, I guess.  +1 for everything!)
16:55:17 <geppetto> I'm fine with it if you must only have one
16:55:58 <geppetto> that's +4 for no %name
16:57:24 <geppetto> #info Got +4 for no %name
16:57:35 <geppetto> Ok, looks like mbooth is afk.
16:57:40 <geppetto> #topic Open Floor
16:57:54 <geppetto> Anything that needs to be spoken of in the last couple of minutes?
16:58:35 <ignatenkobrain> nothing from me
16:59:22 <tibbs> My guess is that Miro will vote in the ticket when he gets a chance.
17:01:39 <geppetto> #endmeeting