16:00:20 <geppetto> #startmeeting fpc
16:00:20 <zodbot> Meeting started Thu Oct 25 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 <zodbot> The meeting name has been set to 'fpc'
16:00:20 <geppetto> #topic Roll Call
16:00:26 * limburgher here
16:00:27 <decathorpe> o/
16:00:32 <geppetto> #chair decathorpe
16:00:32 <zodbot> Current chairs: decathorpe geppetto
16:00:36 <geppetto> #chair limburgher
16:00:36 <zodbot> Current chairs: decathorpe geppetto limburgher
16:00:36 <ignatenkobrain> .hello2
16:00:37 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
16:00:39 <geppetto> #chair ignatenkobrain
16:00:39 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher
16:00:57 <redi> hello hello
16:01:16 <geppetto> #chair redi
16:01:16 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher redi
16:04:58 <geppetto> No tibbs?
16:05:07 <tibbs> Damn, it's Thursday.
16:05:11 <geppetto> INdeed
16:05:15 <geppetto> #chair tibbs
16:05:15 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher redi tibbs
16:05:21 <geppetto> #topic Schedule
16:05:25 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/TCDBEO25XN5P3EX66REKMSWC3DPBP47H/
16:06:12 <geppetto> Same schedule as last week … anything to talk about with it?
16:06:34 <redi> not from me
16:06:40 <decathorpe> I'm a bit concerned that all the forge macro changes were pushed to rawhide without testing ...
16:06:50 <tibbs> That's not entirely accurate.
16:07:33 <decathorpe> just look at https://apps.fedoraproject.org/koschei/groups/go-sig?
16:07:42 <decathorpe> almost half the packages are broken in rawhide now.
16:07:55 <tibbs> From my perspective the go usage of these things was incredibly premature.
16:08:07 <decathorpe> I agree
16:08:31 <ignatenkobrain> decathorpe (IRC): I believe that it is koschei which still didn't retry building them after rh-rpm-config change
16:08:37 <geppetto> #topic #719 Simplify packaging of forge-hosted projects
16:08:40 <geppetto> #topic #719 Simplify packaging of forge-hosted projects
16:08:44 <geppetto> .fpc 719
16:08:44 <ignatenkobrain> I mean this https://src.fedoraproject.org/rpms/redhat-rpm-config/c/8ba2a65b5ce1777906d200d0e20e435e02c76a58
16:08:48 <zodbot> geppetto: Issue #719: Simplify packaging of forge-hosted projects - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/719
16:08:54 <tibbs> From FPC's perspective, what's left is the actual guidelines for these things.
16:09:08 <decathorpe> which I guess nobody wants to work on anymore?
16:09:21 <tibbs> The pending PRs have been merged (though there may be new ones now).
16:09:31 <eclipseo> decathorpe: they'll be rebuilt, I'll plan to do a full scan of the packages of the SIG when i have the time
16:09:43 <decathorpe> okay
16:09:46 <decathorpe> fair enough
16:10:07 <decathorpe> I already fixed or orphaned my packages.
16:10:09 <tibbs> I don't know if koschei considers redhat-rpm-macros to be a dependency of absolutely everything.
16:10:16 <decathorpe> tibbs: it does
16:10:24 <mizdebsk> it does
16:11:51 <tibbs> It doesn't make any sense if you orphaned packages because of this.
16:12:28 <decathorpe> I wanted to get rid of them before this happened, and I announced it a week in advance if anyone wanted to pick them up. nobody did
16:12:37 <tibbs> OK, good.
16:12:56 <tibbs> The alternative was some weird passive-aggressive protest thing, and I'd hope none of us would stoop to that level.
16:13:07 <tibbs> But in any case, for the forge things, it's still at the guidelines level.
16:13:25 <decathorpe> is there a new draft?
16:13:31 <tibbs> And I'm glad that didn't make it too far, because the last few changes added a pile of stuff so we'd just have to redo it.
16:14:11 <tibbs> I don't think anything new has happened on the draft front.  Now even the original documentation doesn't completely suffice.
16:14:31 <tibbs> So it now needs someone to go over the macros, compare that to any existing docs, and turn that into guidelines.
16:14:43 <tibbs> I may have a little time if I don't spend it all on ~.
16:15:17 <geppetto> anyone else want to volunteer?
16:15:47 <eclipseo> nim wrote the macros he knows them better than anyone else
16:16:03 <tibbs> True, but I think he's mostly tapped at this point.
16:16:07 <geppetto> Yeh, it'd be great if people outside the FPC could write the draft
16:16:45 <decathorpe> last time we asked nim, he wasn't interested in working on the documentation anymore
16:16:50 <ignatenkobrain> well, if I say "I would look at it" and it would make tibbs (IRC)  to spend more time on `~`, then I would say that ;)
16:16:50 <eclipseo> the draft are here https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
16:17:10 <geppetto> ignatenkobrain: nice :)
16:17:34 <geppetto> #action ignatenkobrain will look at the draft, so tibbs can spend some time on ~ ticket ;)
16:17:50 <tibbs> I will try to look as well.
16:17:55 * geppetto nods
16:18:17 <geppetto> #topic #398: Tilde in version
16:18:22 <geppetto> .fpc 398
16:18:27 <zodbot> geppetto: Issue #398: Tilde in version - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/398
16:18:29 <geppetto> So … talking about it … it appears
16:18:56 <geppetto> Anyone have anything to say about this before tibbs looks at it again?
16:19:00 <tibbs> I sent a wall of text quite recently.
16:19:05 <geppetto> Yeh, I read that
16:19:32 <tibbs> Now trying to make markdown tables work so I can post a summary of how things look under various proposals.
16:19:50 <geppetto> I mostly agree … common case being easy == good. Although I do think it's useful if we could move to "version == upstream data" "release == fedora data"
16:19:58 <geppetto> And tilda allows that.
16:20:02 <tibbs> It does.
16:20:16 <tibbs> But the question that remains is what's fedora's data versus what's upstream's data.
16:20:24 <tibbs> Basically git hash.
16:20:37 <geppetto> git hash from upstream repo. == upstream data IMNSHO
16:20:41 <tibbs> kkoffler's proposal is very interesting to me because it leaves Release: as an integer.
16:21:03 <tibbs> I think you can argue either way about the date.
16:21:38 <decathorpe> Release as just a number would remove a whole lot of complexity in the release bump algorithms
16:22:03 <tibbs> But note that any change to where we put the git hash has bearing on the forge macros now, and nim said that he wouldn't change the macros he wrote and would make us do it.
16:22:05 <geppetto> If it's a date from the upstream git/tarball/whatever then it's upstream … if it's the date from the fedora git then it's fedora data.
16:22:20 <geppetto> 👍
16:22:27 <tibbs> Well we say that the date is when you took the snapshot.
16:22:47 <tibbs> Which is bounded by the date when upstream made the change, but isn't determined by it.
16:23:10 <tibbs> I will point out that we always have the option of not using the date....
16:23:28 * geppetto nods
16:23:45 <tibbs> We've just consistently voted that it needs to be there because of its value in showing how old something is.
16:24:14 <geppetto> it is nice, but we don't do the same thing for tarballs
16:24:23 <geppetto> and it would be useful in the same contexts there
16:24:23 <tibbs> Yes, that's exactly my thought.
16:24:32 <tibbs> oops, we lost eclipseo.
16:24:47 <redi> hoo boy that's a lot of text to read
16:25:01 <redi> (I've not seen this one before, so I've got 4 yeas to catch up)
16:25:10 <tibbs> Yeah, sorry, this ticket is kind of broken.
16:25:12 <ignatenkobrain> tbh, I was always advocating to use number of commtis instead of the date
16:25:33 <tibbs> Well that makes sense for subversion, I guess.
16:25:54 <tibbs> But it's generally as meaningless as the git hash as long as we have to prepend an integer anyway.
16:26:28 <geppetto> Yeh, it'd be nice if we could guarantee it was monotonically increasing … but it isn't
16:26:41 <limburgher> And not all commits are equal, for every "Fix for CVE-2018-blah" you have six "Frick, I forgot the patch."
16:26:41 <geppetto> at least on the git side.
16:27:07 <tibbs> Even then, the "second case" portion of my questionnaire shows that monotonically increasing doesn't help you.
16:27:15 <geppetto> that's less important than the fact people rebase/etc. so the number can go down or sideways
16:27:40 <tibbs> Since snapshots may be part of a sequence that isn't ordered in any way that a computer can determine.
16:28:18 <tibbs> One fun question: is there other metadata that an end user could use to tell how "old" something is without having is cram a date in there?
16:29:12 <tibbs> The rpm changelog I guess would be the best answer.
16:29:29 <geppetto> that's just build date though
16:29:53 <decathorpe> it doesn't even have to be the build date
16:29:56 <tibbs> I mean rpm -q --changelog
16:29:59 <geppetto> or similar … commitdate/builddate tell you something, but it doesn't always match up … esp. on CentOS
16:30:10 <ignatenkobrain> changelog I guess it would be
16:30:49 <tibbs> You can see from that what change intruduced the current git hash.  Certainly that's no less meaningful than the date that the packager filled into the <snapinfo> bit.
16:31:13 * geppetto nod
16:31:28 <tibbs> Not as easy to see, but I would say that in the off chance you actually care, it isn't hard to look.
16:31:46 <tibbs> Anyway, it's something of an orthogonal issue.
16:32:08 <tibbs> Neither the current guidelines nor any of the proposed changes break if we were to remove the requirement for a date.
16:32:23 <tibbs> They'd need changes to the definition of <snapinfo> but that's it.
16:32:41 <tibbs> Now, the forge macros, on the other hand.... any change we make bears on that.
16:32:52 <geppetto> :)
16:33:16 <tibbs> The kkoffler scheme in particular does have some bad interactions, I think.
16:33:23 <tibbs> But I'd have to look at it.
16:34:01 <tibbs> My problem here is that eliminating all crap (besides %dist) from Release: is actually enough of a change that I think it makes it worthwhile to switch to a new sheme.
16:34:03 <tibbs> scheme.
16:34:24 <tibbs> Finally providing a good answer to the "what does this buy us" question.
16:35:02 <tibbs> But the problem is that we have actual disagreement about that one.
16:35:38 <tibbs> In case anyone is curious, it is perfectly OK from an infrastructure/releng standpoint to use '+' in a version string.
16:36:18 <tibbs> The proposal doesn't depend on that but I do like how it makes the "post-release" case obvious in the same way that tilde makes the prerelease case obvious.
16:36:37 <decathorpe> yeah, but still the version comparison doesn't work right with "+"
16:37:03 <decathorpe> rpm knows to sort "~" lower than anything else, but it ignores "+" just like "."
16:37:07 <ignatenkobrain> what do you mean?
16:37:41 <redi> yeah 1+1 is newer than 11 isn't it?
16:37:41 <decathorpe> give me a second to come up with an example
16:37:54 <redi> "newer" according to rpm
16:38:18 <geppetto> redi: no, the other way around
16:38:25 <redi> oh
16:38:32 <decathorpe> "1.0+dev < 1.0.0"
16:38:35 <tibbs> 1+1-1 == 1.1-1
16:38:47 <geppetto> rpm basically compares 11 vs. the first 1 of 1+1
16:39:05 <decathorpe> "1.0+1 == 1.0.1"
16:39:26 <tibbs> It compares exactly as a dot does as far as I can tell.
16:39:51 <decathorpe> which isn't what we want for post-release snapshots.
16:39:54 <tibbs> Which is fine.  The alternative if it bothers someone is to just use '.'.
16:39:59 <geppetto> yeh, it's just in the group of special symbols that split the other parts but do nothing
16:40:31 <tibbs> If you don't want '+' for post-release snapshots then you don't want '.' either.
16:40:42 <geppetto> The real fnu is stuff like:
16:40:43 <geppetto> % rpmdev-vercmp 1.+.2.3 1+2+3
16:40:44 <geppetto> 1.+.2.3 == 1+2+3
16:40:45 <tibbs> And then the remaining question would be "what do you want".
16:41:15 <tibbs> I can't think of a case where either '+' or '.' doesn't do what we want, but maybe I'm missing something.
16:41:17 <decathorpe> I guess the "make sure you know what you're doing" still applies to packaging, so using "+" should be fine
16:41:29 * geppetto nods
16:41:45 <decathorpe> and ... does koji let you build "older" packages? I don't think sop
16:41:47 <tibbs> Well the point of providing clear guidelines here is that you don't have to know the internals of the rpm version comparison function.
16:41:50 <geppetto> And, again … hopefully we can make the common cases easier … then people don't need to know quite so much.
16:42:05 <ignatenkobrain> koji doesn't care about versions
16:42:16 <tibbs> koji lets you build any git hash and only compares versions stringwise.
16:42:24 <geppetto> really?
16:42:50 <tibbs> Sure, why not?
16:42:55 <geppetto> you mean only compares for equality?
16:43:04 <tibbs> Yes, stringwise equality.
16:43:16 <tibbs> And then only to see if something has already been tagged.
16:43:27 <ignatenkobrain> yes
16:43:28 <ignatenkobrain> also it doesn't know anything about epoch
16:43:29 * geppetto nods … ok, I thought you mean they were ordering by string cmp too for a minute
16:43:35 <decathorpe> not even rpmlint complains if the version goes down. fun.
16:43:52 <tibbs> Well rpmlint works against a single package in isolation.
16:44:03 <tibbs> So it wouldn't know what the "current" version is to compare against.
16:44:21 <decathorpe> I meant "rpmlint *.spec"
16:44:41 <tibbs> I don't see how that changes anything.
16:44:59 <tibbs> It doesn't require that the package be installed.
16:45:02 <decathorpe> it doesn't check the changelog version-releases for order.
16:45:19 <tibbs> Ah, that is something it could do indeed.
16:45:27 <tibbs> Shouldn't be too hard.
16:45:34 <tibbs> Anyway, so my plan for today:
16:45:37 <geppetto> epoch isn't in the changelog version info is it?
16:45:46 <tibbs> We don't require that it be there.
16:45:49 <geppetto> So, it can't.
16:46:09 <tibbs> Well, epoch is not the common case so it would certainly be useful to indicate.
16:46:32 <tibbs> BTW, since epoch factors into all of this tilde and versioning mess...
16:46:55 <tibbs> We really don't need to keep Epoch stable between releases these days.
16:47:23 <limburgher> Why not?
16:47:27 <tibbs> It's not our call as to whether that policy is kept or not, but I wondered if anyone had opinions about it.
16:47:27 <decathorpe> since nobody cares about upgrade path anymore
16:47:43 <decathorpe> (I complained and was told "we don't care anymore)
16:47:44 <tibbs> No, just that upgrade path doesn't matter any more.
16:47:49 <tibbs> Upgrades do distro-sync.
16:48:03 <tibbs> So packages can and will go backwards when you do a dnf system-upgrade.
16:48:21 <decathorpe> (still, the scenario I complained about had nothing to do with that, but with missing updates from f29)
16:48:22 <tibbs> And if you don't use system-upgrade but live upgrades, you've pretty much always had to do distro-sync anyway.
16:49:10 <tibbs> You should still be informed if a package you maintain is in a state where an upgrade will go backwards.
16:49:22 <tibbs> That hit me (and limburgher) recently.
16:49:24 <ignatenkobrain> FYI, I believe that system-upgrade uses upgrade instead of distro-sync
16:49:27 <ignatenkobrain> but this is not 100%
16:49:32 <decathorpe> no, distro-sync
16:49:35 <decathorpe> I'm sure
16:49:50 <decathorpe> there's a --no-downgrade switch if you don't want it.
16:49:51 <tibbs> I have verified cases of packages going backwards on upgrade.
16:50:02 <tibbs> Of course, the problem in all of this is rawhide.
16:50:22 <tibbs> That's the big question in any policy decision here.
16:50:32 <tibbs> But it won't be our question to answer.
16:50:43 <ignatenkobrain> https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/plugins/system_upgrade.py#L298-L301
16:51:00 <ignatenkobrain> yeah, there is just option to not do that
16:51:12 <decathorpe> that's what I said. ;)
16:51:50 <tibbs> But that option is almost guaranteed to hit dependency issues eventually.  Not that it shouldn't be there but it's one of those things where you have to know what you're doing.
16:52:57 <tibbs> The major point is that if we accept that rawhide users will need to distro-sync "occasionally", there is no reason for Epoch: to be permanent.
16:53:25 <tibbs> I think a "backwardsing" would be a thing you'd have to announce, but I think it should be doable.
16:53:58 <tibbs> And disappearing epoch would theoretically be something dnf could detect and inform you of directly.
16:55:11 <decathorpe> yeah. getting rid of Epoch periodically would be a nice cleanup
16:55:23 <tibbs> Anyway, what I'm basically saying is that if Epoch weren't quite so terrible, it might be more useful as a tool in versioning instead of the addition of random integers all over the place.
16:55:54 <tibbs> (We could also just remove the 'c' from the dist tag at the next mass rebuild, too....
16:56:14 <decathorpe> and break all of our muscle memory? ;)
16:56:41 <tibbs> Hey, some of us have agonized about it since F7.
16:56:42 <limburgher> :popcorn:
16:56:44 <ignatenkobrain> opensuse doesn't have %{?dist} :P
16:56:52 <limburgher> tibbs: true that.
16:57:06 <ignatenkobrain> let's get rid out of dist entirely! 🍿
16:57:06 <tibbs> Other distros either don't need it or completely internalize it in other metadata.
16:57:21 <tibbs> ignatenkobrain: Fix koji and we can, rather easily.
16:57:30 <decathorpe> hey, but ubuntu's version stings are even worse
16:57:32 <ignatenkobrain> tibbs (IRC): yeah
16:57:46 <tibbs> It would still be in the filename, of course, you just wouldn't need it to actually exist in the spec.
16:58:00 <ignatenkobrain> btw
16:58:01 <ignatenkobrain> https://en.opensuse.org/openSUSE:Package_naming_guidelines
16:58:01 <ignatenkobrain> ^F tilde
16:58:34 <geppetto> ignatenkobrain: they use the header though IIRC
16:58:39 <tibbs> That's something Neil (don't know what his nick is this minute) was working on.
16:59:06 <tibbs> They did take a lot of guidelines from us, didn't they?
16:59:15 <geppetto> yeh
16:59:40 <tibbs> Their use of git --describe is interesting.
16:59:43 <geppetto> Anyway … I'm going to close this up now, as it's the hour
17:00:00 <geppetto> #topic Open Floor
17:00:06 <tibbs> Maybe that's what ignatenkobrain meant when he talked about counting commits.
17:00:11 <geppetto> I assume nothing else needs to be brought up?
17:00:28 <tibbs> I do wonder how
17:00:33 <ignatenkobrain> tibbs (IRC): yes
17:00:35 <tibbs> folks are feeling about the versioning thing.
17:00:48 <decathorpe> I have a bonus question
17:01:26 <decathorpe> anybody care to guess if this refers to a stable release or a snapshot build?
17:01:28 <decathorpe> "Release: 3.dev.git%{shortcommit0}%{?dist}"
17:01:31 <coremodule> hey folks, we have the go/no-go meeting in here right now...
17:01:54 <ignatenkobrain> coremodule: so go then ;)
17:01:58 <geppetto> coremodule: ok
17:02:02 <geppetto> #endmeeting