16:00:18 <geppetto> #startmeeting fpc
16:00:18 <zodbot> Meeting started Thu Jul 11 16:00:18 2019 UTC.
16:00:18 <zodbot> This meeting is logged and archived in a public location.
16:00:18 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:18 <zodbot> The meeting name has been set to 'fpc'
16:00:19 <geppetto> #meetingname fpc
16:00:19 <zodbot> The meeting name has been set to 'fpc'
16:00:19 <geppetto> #topic Roll Call
16:00:34 <mhroncok> hey
16:00:58 <geppetto> #chair mhroncok
16:00:58 <zodbot> Current chairs: geppetto mhroncok
16:01:05 <tibbs> Hey, folks.
16:01:10 <geppetto> #chair tibbs
16:01:10 <zodbot> Current chairs: geppetto mhroncok tibbs
16:01:12 <geppetto> hey
16:01:21 <tibbs> Finally got in after waiting for 90 minutes to get someone towed out of my parking spot.
16:02:12 <geppetto> ugh, bad day for two people
16:02:54 <Rombobeorn> I'm here, hoping that a decision on source file verification will be made today.
16:03:25 * limburgher ohai
16:03:32 <geppetto> #chair limburgher
16:03:32 <zodbot> Current chairs: geppetto limburgher mhroncok tibbs
16:04:43 <ignatenkobrain> .hello2
16:04:44 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
16:05:44 <geppetto> #chair ignatenkobrain
16:05:44 <zodbot> Current chairs: geppetto ignatenkobrain limburgher mhroncok tibbs
16:06:06 <geppetto> hey, hopefully wifi stays working for the next hour :)
16:06:30 <mhroncok> geppetto: Just a note, I have a question for the open floor
16:06:51 <decathorpe> hey guys, sorry for being late
16:06:56 <geppetto> mhroncok: ok
16:06:59 <ignatenkobrain> I hope so
16:07:00 <geppetto> #chair decathorpe
16:07:00 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher mhroncok tibbs
16:07:08 <geppetto> #topic Schedule
16:07:11 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/WRTI5UXWGULGOR4RKX27XXFS37P2CAKD/
16:07:20 <ignatenkobrain> this wifi issue is really bad, but it seems that f30 has patch backported, so should be good
16:07:52 <geppetto> Rombobeorn: What was the issue you wanted us to look at?
16:08:11 <Rombobeorn> https://pagure.io/packaging-committee/issue/610
16:08:30 <Rombobeorn> And this is the pull request: https://pagure.io/packaging-committee/pull-request/836
16:09:10 <Rombobeorn> The software is in place in Fedora 29, 30 and Rawhide. As far as I can see this proposal is ready for voting.
16:09:22 <geppetto> #topic Check upstream tarball signatures
16:09:29 <geppetto> .fpc 610
16:09:33 <zodbot> geppetto: Issue #610: Packaging guidelines: Check upstream tarball signatures - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/610
16:09:51 <geppetto> This is … really old. I mostly remember bits.
16:10:05 <geppetto> Some of you probably weren't here when it first came up though
16:10:38 <ignatenkobrain> I'm +1 on this, and I'll leave wording to tibbs :)
16:11:02 <tibbs> +1.
16:11:04 <mhroncok> https://pagure.io/packaging-committee/pull-request/836
16:11:40 <tibbs> Though I think that section is long enough that I will put it in a separate page.  The main guidelines page is long enough as it is.
16:11:55 <mhroncok> +1
16:12:08 <decathorpe> sounds good
16:12:10 <decathorpe> +1
16:12:14 <Rombobeorn> A separate page works for me.
16:12:40 <tibbs> But that's immaterial to the proposal, and it should be OK to merge the PR and then let me fix it up.
16:13:08 <geppetto> Quick link to the additions: https://pagure.io/packaging-committee/pull-request/836#request_diff
16:13:12 <tibbs> If you want to rebase, that would be nice.  Sadly pagure won't let us rebase these days so we have to di it manually.
16:13:18 <geppetto> +1
16:13:47 <ignatenkobrain> limburgher: vote?
16:14:36 <Rombobeorn> It says it can be merged with a merge commit, but I suppose I can rebase again if you want.
16:16:51 <limburgher> +1
16:17:14 <geppetto> #action Check upstream tarball signatures (+1:6, 0:0, -1:0)
16:17:14 <tibbs> Yeah, some people don't like merge commits for whatever reason.  Personally it doesn't much bother me but I'd click the rebase button if it hadn't stopped working.
16:17:24 <geppetto> Rombobeorn: Done :)
16:17:34 <Rombobeorn> Thanks guys.
16:17:39 <geppetto> #topic #900 Proposed Packaging Guidelines
16:17:42 <geppetto> .fpc 900
16:17:43 <zodbot> geppetto: Issue #900: Proposed Packaging Guidelines - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/900
16:18:46 <ignatenkobrain> for this one, we probably need some header for the guidelines which are  in "preview" state so that they can be viewed easily. And also finally do the wiki redirection
16:19:00 <decathorpe> what's this about? the Go Packaging Guidelines have been merged, so it's more about what should happen with future "Proposed Guidelines"?
16:19:11 <geppetto> yeh
16:19:12 <tibbs> The last comment has three requests of us.
16:19:37 <mhroncok> I don't really understand 3.
16:19:39 <tibbs> Cleaning up old wiki pages that anyone may have created anywhere.  (Which frankly I don't think we have the time to do).
16:19:54 <tibbs> Somehow making the pull requests more visible somehow, maybe.
16:20:04 <mhroncok> but we should probobly clean the actual wiki guidelines finally
16:20:12 <tibbs> Somehow trying to keep people from packaging things until we have guidelines for them.
16:20:21 <mhroncok> that's not possbile
16:20:27 <mhroncok> *possible
16:20:35 <geppetto> I think #1 seems easyish and +1 … #2 is probably getting all drafts into their own category
16:20:40 <tibbs> So for the second request, sure, we could have dummy guidelines pages explaining that there is a draft or something.
16:20:50 <tibbs> #1 seems rather impossible, actually.
16:20:50 <geppetto> #3 I'm less sure about
16:21:26 <tibbs> I have no way at all to know what random pages someone may have made in the wiki.  Though of course all of the old actual guideline pages should eventually be redirected.
16:21:29 <geppetto> For #1 can't we just put a #warning on the page, at least.
16:21:44 <tibbs> If we know about a page that someone has made, sure.
16:22:12 <tibbs> These things aren't categorized.
16:23:03 <ignatenkobrain> it should be just iterative effort. just if somebody of us found such page, redirect it to our new guidelines.
16:23:06 <ignatenkobrain> probably we can't do more
16:24:37 <geppetto> yeh, I'm fine with doing what we can do and saying no to what we can't.
16:26:25 <tibbs> I can see creating dummy pages in the guidelines repo saying "there are not currently any guidelines for (language/subsystem) but here is a link to a draft." But then I fear those things would accumulate.
16:26:51 <tibbs> Frankly I think we have enough to do without any of this, and don't understand how anyone would think we could reasonably do all of it.
16:27:13 <mhroncok> exactly
16:27:55 <limburgher> Sorry, I have to step away.
16:28:01 <tibbs> Official drafts will have tickets and pull requests.  Random things in the wiki are just random things; I guess we could attach warnings or delete things if someone brings them to our attention.  I have some elevated wiki privileges.
16:29:05 <geppetto> seems fair
16:29:30 <tibbs> And, well, if FESCo wants us to have enforcement powers where we can purge things from the repositories which were added in contravention of packaging guidelines then, uh, they would have to do that and even then I'm not sure we would want to do that kind of thing.
16:29:54 <mhroncok> I don't think FESCo wants such things
16:29:56 <tibbs> We tried to block go way back in the beginning and already have a way to denote review tickets which are waiting for guideline approval.
16:30:13 <tibbs> But everyone wanted docker and nobody cared what mess it took to get it in the distro.
16:30:54 <tibbs> Seems odd for the project leadership to now tell us we should have blocked it when it was the project leadership that told people not to care about what we had to say on the matter.
16:31:11 * decathorpe shrugs
16:31:25 <decathorpe> and now docker (sorry, moby-engine) has been orphaned
16:31:25 <tibbs> (Though obviously I know the composition and attitudes of the project leadership changes over time.)
16:31:52 <tibbs> Yeah, I can't keep up with that stuff any longer.
16:32:08 <tibbs> Anyway, I should respond in the ticket.
16:32:21 <geppetto> ok, so anything non ranty we want to say ;) … We'll continue to do the best we can?
16:33:02 <decathorpe> sounds reasonable ;)
16:33:27 <mhroncok> I trust tibbs to comment there the right thing (TM). I think we should move to the next ticket
16:33:44 <geppetto> #info All the official policies should be somewhat obvious due to their category, we'll continue to do what we can to make it obvious what packages should do.
16:33:51 <geppetto> #topic #902 Cleanup & enhance spec files
16:33:55 <geppetto> .fpc 902
16:33:57 <zodbot> geppetto: Issue #902: Cleanup & ehnance spec files - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/902
16:35:04 <ignatenkobrain> I don't know hwat do we need to discuss here, but I'm +1 to cleanup specs in our guidelines... Also probably move them out of those long pages into the separate files where it makes sense
16:35:39 <decathorpe> isn't already something in the Guidelines about not depending on the manpage compression?
16:36:13 <geppetto> Yeh, I'm fine with the spec cleanup … although I'd rather someone just compressed the flatpack man pages.
16:36:28 <tibbs> decathorpe: Well, sort of.  See my comment from a month ago.
16:36:55 <decathorpe> right
16:37:05 <decathorpe> that's what I was thinking of
16:37:12 <tibbs> I really don't think it's fair to do mass cleanups based on someone's personal style preferences.  Those things should be codified in the guidelines.
16:38:01 <decathorpe> good point. so if someone wants to propose a general cleanup, it should be included in the Guidelines first?
16:38:55 <tibbs> So to summarize my opinions: Of the things listed in the ticket, I disagree with 3 and am ambivalent about 1.  2 is correct based on what I think the guidelines are trying to say, but we should clarify it.
16:39:25 <tibbs> And yes, we should get things codified in guidelines before doing mass cleanups.
16:39:48 <tibbs> If you help maintain packages and want to adapt to your preferred style, that's between you and the other maintainers.
16:41:32 <tibbs> But you shouldn't just go through and remove %doc from anything which RPM would automatically mark as %doc; making it explicit hurts nobody.
16:42:05 <tibbs> They can propose a guidelines change and if it passed then it could be cleaned up.
16:42:13 <mhroncok> I agree with the general rule: mass changes need to be sancioned by the guidelines
16:42:32 <geppetto> sure
16:42:41 <mhroncok> there's also https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes/
16:43:02 <geppetto> although I'm mostly +1 on any guideline change that makes the specs look the same to do the same thing
16:43:12 <tibbs> Yeah, I wrote most of that originally.  I didn't realize it had moved out of the wiki.
16:44:11 <geppetto> #info Propose guideline changes we can vote on, if those pass then it's fine to do scripted cleanups
16:44:22 <geppetto> #topic #904 Caret versioning
16:44:25 <geppetto> .fpc 904
16:44:27 <zodbot> geppetto: Issue #904: Caret versioning - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/904
16:44:35 <tibbs> I need to address the typos.
16:44:44 <tibbs> Trying to avoid getting drawn into unrelated stuff.
16:45:19 <geppetto> I'm blah about this
16:46:03 <geppetto> RPM devs. intentionally missed the el8 window so everything is broken for years anyway, I don't see the rush to put anything in rawhide
16:46:14 <tibbs> Avoiding the nitpicking issues, I do think that this is premature.
16:46:36 <tibbs> I'm curious about your use of "intentionally".
16:46:54 <tibbs> Obviously there's plenty of information I don't have.
16:46:56 <geppetto> I guess when it's in F31 we can go with it, although we should warn people about incompatibility
16:47:20 <tibbs> I wouldn't mind if rpm in F30 didn't refuse to parse any spec which used it.
16:47:30 <decathorpe> geppetto: you mean waiting until the f31 branch point, or until 31 GA?
16:47:47 <geppetto> decathorpe: branch point is probably fine.
16:48:12 <decathorpe> that were my thoughts as well.
16:48:23 <tibbs> I mean, I wouldn't mind moving forward at a brisker pace.  But right now if you try it in a spec, you can't even parse that spec on any released Fedora unless you patch RPM.
16:48:35 <geppetto> yeh
16:48:56 <tibbs> The patch is trivial, of course, if all you want to make RPM do is accept it without teaching it how to do the extra version comparison.
16:48:59 <geppetto> ignatenkobrain: do you know if rpm plan to backport an update to F30 at least?
16:49:30 <geppetto> tibbs: I'm not sure that's better
16:49:34 <ignatenkobrain> as I said, chicken-egg problem. we don't use it in rawhide, and they dont want to backport it for nothing]
16:49:45 <tibbs> I don't think RPM has any issues with an actual .rpm or .srpm file that uses this, though.
16:50:16 <geppetto> tibbs: Atm. we have two behaviours … syntax error, or does the right thing … having a third option of "accepted but parses differently -- doing nothing" isn't great.
16:50:35 <tibbs> Sadly I think it's more complicated than that.
16:50:56 <tibbs> Basically there's "rpm" behavior and "rpm-build" behavior.
16:51:26 <ignatenkobrain> libsolv supports caret for long time, so dnf is fine
16:51:37 <tibbs> I think currently "rpm" doesn't care, but "rpm-build" does.  "rpm-build" rejects the unknown character in Version: but otherwise doesn't care about version comparisons.
16:51:46 <geppetto> tibbs: those only seem different if you ignore the possibility of caret in build-requires etc.
16:52:17 <tibbs> Well, one is about syntax and the other is about behavior.
16:52:22 <geppetto> yeh
16:52:53 <mhroncok> not being able to work with the spec file is a bummer
16:53:06 <mhroncok> however I don't think they'll backport anything until they see a reson
16:53:11 <tibbs> Currently F30 rpm-build rejects on syntax, but I think F30 rpm doesn't care at all and will happily operate on such packages but get the version comparison "wrong".
16:53:39 <tibbs> Anyway, none of this prevents us from being ready for a more appropriate time.
16:53:46 <mhroncok> at least beaing able to do fedpkg srpm or similar is a must
16:53:57 <tibbs> Thing is, ignatenkobrain said he wanted this for an auto-rebuild system.
16:54:42 <ignatenkobrain> yes, we are working on moving changelog and release out which means nothing like gittags and things like that should be in Release
16:54:49 <ignatenkobrain> and we need caret to handle these cases
16:54:55 <tibbs> One day I will file a ticket for relaxing the requirement to have a date in the snapshot info unless someone beats me to it.
16:55:29 <tibbs> Of course, nothing prevents you from working on these changes.  It's just premature to tell packagers to use them.
16:55:56 <ignatenkobrain> well, more you wait, less possible it gets backported to EL7
16:56:09 <ignatenkobrain> it is already 7.7, which means it is almost like maintenance mode only
16:56:19 <tibbs> That's an odd form of extortion, really.
16:56:28 <geppetto> yeh, and I really don't see it as a chicken/egg thing … if we go first everything breaks; if rpm compatibility goes first and nobody uses it they lose a day of work or whatever.
16:56:29 <mhroncok> why do we care baout el7?
16:56:32 <ignatenkobrain> and RPM developers are not going to backport if we are not using it in fedora
16:56:47 <mhroncok> *about
16:57:02 <tibbs> If people really want, we can declare that limited experimental use is acceptable.
16:57:17 <tibbs> If having it somewhere in the guidelines is really that important.
16:57:50 <tibbs> Or we could approve the draft (with the cleanups already discussed) and add a big caveat at the beginning.
16:58:02 <geppetto> ignatenkobrain: So you've tested that if you put a package with caret in rawhide then F30 dnf can install that package?
16:58:52 <tibbs> To be honest I've only experimented with how rpm deals with such a package.  I don't know what dnf would do.
16:59:19 <ignatenkobrain> I did not test this, but resolving dependencies should be fine
16:59:21 <tibbs> I did ask and the compose process should be OK with it, but if any of the QA stuff wants to look at the specfile then it will bomb.
16:59:27 <geppetto> tibbs: ignatenkobrain implied that because of libsolv support dnf should already work
16:59:30 <geppetto> Hmmm
16:59:58 <tibbs> Thing is, we do need to test it, in coordination with releng.  So that's worthy of a ticket.
17:00:06 <geppetto> yeh, this seems like a bad idea until we have at least branched F31
17:00:16 <geppetto> unless rpm devs. are willing to do compat. updates
17:00:18 <tibbs> Let me add a list of things to test to the ticket and we can work through those.
17:00:27 * geppetto nods
17:00:45 <geppetto> #action tibbs will add list of things that need testing.
17:01:10 <geppetto> #info In general we seem fine on adding this after F31 GA, and probably even F31 branch.
17:01:41 <mhroncok> ack
17:06:02 <geppetto> #topic Open Floor
17:06:07 <Rombobeorn> The rebase that Tibbs requested is done. Those who dislike merges should be happy.
17:06:09 <geppetto> mhroncok: You had something?
17:07:00 <mhroncok> yes, sorry
17:07:16 <mhroncok> 1 thing- could somebody please help review https://pagure.io/packaging-committee/pull-request/913 ?
17:08:00 <mhroncok> another thing: what is you opinion on this? should we always have %license with relative paths? https://src.fedoraproject.org/rpms/python38/pull-request/33#comment-27533
17:08:08 <tibbs> +1 we should just merge PR913.
17:08:37 <geppetto> it's just updating requires?
17:09:02 <geppetto> Assuming the note is true … it looks fine :)
17:09:04 <tibbs> I think it's just making a note and and updating the example.
17:09:20 * geppetto nods
17:09:25 <tibbs> But.... that behavior change sort of makes versions go backwards.
17:09:40 <tibbs> 1.1.0-1.fc30 > 1.1-1.fc31
17:09:53 <mhroncok> tibbs: sort of, but only for virtual provides (there is no release in those)
17:10:08 <tibbs> 1.1.0-1.fc30 > 1.1-2.fc31 is more fun.
17:10:13 <mhroncok> the main problme is when people had requirement on >= x.y.0
17:10:19 <mhroncok> but Ie mass changed those
17:10:30 <tibbs> I don't think it will hurt in practice, though.
17:10:33 <geppetto> yeh, it's fine if we go from foo >= 4.2 … but not if foo goes from providing 4.2.0 to providing just 4.2
17:10:51 <mhroncok> if foo goes from providing 4.2.0 to providing just 4.2, what exactly breaks?
17:10:52 <geppetto> And something sitll requires >= 4.2.0
17:11:06 <mhroncok> yes, that breaks
17:11:16 <mhroncok> I'm watching those, should be totally fine after mass rebuild
17:11:33 * geppetto nods
17:12:14 <geppetto> mhroncok: Ok, you good with ending the meeting?
17:12:23 <mhroncok> sure
17:12:46 <geppetto> Ok, I'll give you your -12 minutes back ;)
17:12:51 <geppetto> #endmeeting