16:00:18 <geppetto> #startmeeting fpc
16:00:18 <zodbot> Meeting started Thu Jul  2 16:00:18 2015 UTC.  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: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:31 <tomspur> Hi
16:00:36 <tibbs|w> Howdy.
16:01:01 <tomspur> tibbs|w: Just saw your message in #fedora-python this morning...
16:01:09 <geppetto> #chair tomspur
16:01:09 <zodbot> Current chairs: geppetto tomspur
16:01:11 <geppetto> #chair tibbs_
16:01:11 <zodbot> Current chairs: geppetto tibbs_ tomspur
16:01:16 <geppetto> #undo
16:01:16 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x348f0410>
16:01:26 <geppetto> #chair tibbs|w
16:01:26 <zodbot> Current chairs: geppetto tibbs_ tibbs|w tomspur
16:01:31 <geppetto> damn it
16:01:34 <tibbs|w> tomspur: Wow, that was several days ago.
16:01:34 <tomspur> tibbs|w: The python macros are there, but %python_provide cannot be used yet as the macro is not in the minimal root...
16:01:39 <geppetto> #unchair tibbs_
16:01:39 <zodbot> Current chairs: geppetto tibbs|w tomspur
16:01:46 <geppetto> hey that worked :)
16:02:03 <tomspur> tibbs|w: yeah, I had a troublesome week...
16:02:12 <tibbs|w> No big deal.
16:02:20 <tibbs|w> I just have to hold off for a while.
16:02:30 <tibbs|w> But where is %python_provide supposed to go?
16:02:46 <tibbs|w> I mean, I am happy to just push things to redhat-rpm-config.
16:02:47 <tomspur> Would it be possible to pull in python-macros into the minimal root?
16:02:55 <tibbs|w> I don't think that's reasonable.
16:02:59 <geppetto> limburgher mbooth orionp racor Rathann SmootherFr0gZ: FPC ping
16:02:59 <tomspur> That would be the other option
16:03:03 <tibbs|w> But why does it have to be in the minimal root?
16:03:08 <mbooth> Hi geppetto
16:03:18 <geppetto> #chair mbooth
16:03:18 <zodbot> Current chairs: geppetto mbooth tibbs|w tomspur
16:03:25 <tomspur> It emits a Provide, so when creating the srpm, it fails
16:03:28 <geppetto> hey Matt
16:03:28 <gbcox> Hi, I'm here to answer any questions about #571 if it comes up
16:03:43 <gbcox> actually 547 sorry
16:03:59 * geppetto nods
16:04:09 <tomspur> tibbs|w: https://kojipkgs.fedoraproject.org//work/tasks/8199/10248199/build.log
16:04:09 <geppetto> #chair racor
16:04:09 <zodbot> Current chairs: geppetto mbooth racor tibbs|w tomspur
16:04:17 <geppetto> And then there were 5
16:05:39 <geppetto> #topic Schedule
16:05:45 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-July/010793.html
16:05:55 <geppetto> #topic #547 	SourceURL addition/clarification - Git Hosting Services
16:05:55 <geppetto> .fpc 547
16:05:55 <geppetto> https://fedorahosted.org/fpc/ticket/547
16:05:57 <zodbot> geppetto: #547 (SourceURL addition/clarification - Git Hosting Services) – fpc - https://fedorahosted.org/fpc/ticket/547
16:06:23 <geppetto> Draft is: https://fedoraproject.org/wiki/User:Gbcox/PackagingDrafts/SourceURL
16:07:15 <tibbs|w> You know, since a lot of this is advisory stuff and not really guidelines, should we consider just putting it on a community-edited page and not worrying about it?
16:07:49 <pingou> well, a part of it is ensuring reproducibility of the builds
16:08:02 <pingou> ensuring we are providing the same thing as what upstream is providing
16:08:05 <tibbs|w> Or do we want to actually require the macro setup and such?
16:08:11 <gbcox> That's fine, but I think there were some Git changes since the original guidelines were written so some of the stuff in there doesn't quite apply anymore
16:08:19 <tibbs|w> pingou: But that's a general requirement anyway.
16:08:25 <geppetto> tibbs_: No because reviewers will only let you do stuff if it's in policy
16:08:55 <tibbs|w> I have no particular problem with saying "you must use this" because that allows more automation.
16:08:57 <gbcox> @geppetto which was why I did this in the first place
16:09:08 <pingou> tibbs|w: indeed (but that's what the large discussion on the list was about and I fear making the page open would end-up in a sort of edit-war)
16:09:10 <geppetto> tibbs_: I recently had to use the full commit/shortcommit snafu for a github project because the reviewer refused to accept tags.
16:09:12 <tibbs|w> And this really needs a tool to handle updates automatically.
16:09:23 <geppetto> Even though I was the upstream, and knew the tags would be canonical and not change.
16:09:26 * geppetto shrugs
16:09:36 <geppetto> gbcox: yeh
16:09:43 <tibbs|w> geppetto: Then that reviewer wouldn't accept tarballs, I guess.
16:09:55 <tibbs|w> Because they're non-canonical and can change.
16:09:57 <geppetto> tibbs_: I'd assume they would
16:10:08 <tibbs|w> In other words, you're fighting dumb.
16:10:22 <geppetto> Welcome to FPC :)
16:11:06 <gbcox> On the list the only issue people seemed to have was related to using the Git Tags
16:11:13 <geppetto> Although it's worth noting that there is currently a page on github URLs … and it kind of implies that you should always use commit hashes
16:11:25 <gbcox> and I think that issue now is kind of moot because of three reasons
16:11:35 <gbcox> 1.  Checksum matches now
16:11:47 <gbcox> 2.  The full commit hash is imbedded in the tar now
16:11:58 <pingou> gbcox: 1 only if the tag isn't moved :)
16:12:03 <gbcox> 3.  We are telling people to rely on the tags for version number anyway, so what's the difference?
16:12:20 <gbcox> No, the commit number stays the same regardless
16:12:21 <pingou> 2 means we should check it in the spec
16:12:27 <gbcox> doesn't matter what upstream does
16:12:34 <geppetto> gbcox: Where is the full commit?
16:12:35 <tibbs|w> version numbers do convey useful information that a 40-character hex string doesn't.
16:12:50 <gbcox> it's imbedded in the tar file, there is a git command to extract it
16:13:02 <pingou> tibbs|w: well, we're not speaking about the version number but the Source0
16:13:07 <racor> the same applies to dates. hashes etc. are non human readable
16:13:30 <geppetto> gbcox: Can you put that magic in the git tags section?
16:13:44 <tibbs|w> There's a reason we require the date in Release: for snapshots.
16:14:20 <gbcox> geppetto, I could, I was just trying to keep it from being too wordy... but if that is what you all want, no problem
16:14:26 <tibbs|w> pingoi: I know we're not talking about Version: but having the version in the tarball still provides useful information.
16:14:38 <geppetto> gbcox: It might make people happier knowing they can easily get the commit hash anyway
16:14:54 <geppetto> gbcox: And I've no idea how to do it, so am curious ;)
16:15:06 <gbcox> no prob... I can add it, it is easy
16:15:10 <pingou> tibbs|w: not if that URL can point in time to different tarballs :/
16:15:12 <tibbs|w> And those shortcommit macros really need to be in redhat-rpm-config.
16:15:28 <tibbs|w> pingou: That is exactly the same for any URL to any tarball anywhere.
16:15:37 <pingou> tibbs|w: not in pypi for example
16:15:56 <tibbs|w> What pypi does is completely irrelevant.
16:16:10 <pingou> it's a counter-example :)
16:16:12 <racor> pingou: That's why we have md5sums and yell at upstreams which replace tarballs ;)
16:16:19 <pingou> racor: indeed :)
16:16:28 <geppetto> yeh
16:17:04 <pingou> racor: now, you update to 1.1, upstream re-tags and you don't notice it, we now have a different behavior between 1.1 packaged and 1.1 upstream
16:17:15 <pingou> using the hash, at least prevents that
16:17:18 <gbcox> I think with the current guideline was written, Git didn't do all that it does now... hence, all the stuff that was in there now is kinda moot
16:17:36 <tibbs|w> Anyway, I have no particular problems with this.  I don't like the names of some of the macros but I don't think it's a big deal.
16:18:02 <mbooth> pingou: You use the commit hash, upstream amends the commit and uses git push -f
16:18:06 <tibbs|w> I'd get rid of the '0's, for example.  The vast majority of projects don't use two different git pulls.
16:18:11 <gbcox> the names were just and example, people can use what they want as long as it works...
16:18:17 <pingou> mbooth: and the old hash still works
16:18:22 <geppetto> Yeh, I'm fine with it … I kind of understand why you went with commit0 instead of commit, but I'm not sure it's worth it
16:18:48 <tibbs|w> If we're going this far, we should actually standardize the macros.
16:19:08 <tibbs|w> Then it can all be automated and the automation pushed into fedpkg.
16:20:22 <gbcox> we just need to ensure people get the fact how it relates to multiple sources (if required)
16:20:38 <geppetto> I'm fine with it as is
16:20:40 <geppetto> +1
16:21:06 <geppetto> although I still don't see that magic git command ;)
16:22:20 <gbcox> git get-tar-commit-id < $tar_file_name
16:22:43 <geppetto> Although given the macros we have listed it might be worthwhile to have a %global snapshot0 20070221
16:22:50 <geppetto> or commitdate0 … not sure
16:23:05 <geppetto> gbcox: And that works on all three hosts?
16:23:20 <gbcox> I thought of adding those, but they are discussed in a different guideline, so I didn't want to repeat
16:23:26 <gbcox> yup...
16:23:30 <geppetto> cool
16:23:44 <gbcox> I was carefull to test against all the hosts
16:24:06 <gbcox> any differences are noted in the examples
16:24:24 <tibbs|w> To be honest, I'll +1 anything that actually works at this point.
16:24:32 <gbcox> ROFL
16:24:34 <gbcox> thanks!
16:24:41 <tibbs|w> And since this has been tested and is far better than what we had, +1.
16:25:26 <tibbs|w> I mean, if we can agree to nuke the '0's then great, and I would nuke the first sentence of the "Git Hosting Services" section and slightly modify the second.
16:25:33 <tibbs|w> But no big deal.
16:26:14 <RemiFedora> nice, I have >100 packages not comùpliant to new guidelines, going to prepare a mass orphan
16:26:15 <tomspur> gbcox: Do you have an example for a diverging submodule version from upstream?
16:26:32 <tibbs|w> RemiFedora: We don't impose guidelines retroactively.
16:26:55 <pingou> nice to see we prefer to be less reliable
16:27:25 <tibbs|w> pingou: Because of the tags?
16:27:33 <RemiFedora> tibbs|w, so I will not propose any new packages
16:27:39 <pingou> tibbs|w: yes
16:28:01 <RemiFedora> thanks to break a clean an reliable guidelines
16:28:09 <tibbs|w> What?
16:28:11 <gbcox> tomspur - no I tried to keep it basic to just give an idea; but people can interpolate
16:28:23 <tibbs|w> I'm still not getting the counterarguments.
16:28:39 <pingou> relying on the hash works, even if upstream git push -f
16:28:43 <tibbs|w> pingou seems to be arguing that upstream can do things that might bother us, which isn't anything new.
16:28:47 <pingou> relying on the tags means playing on wet sand
16:29:01 <pingou> tibbs|w: but unlike the other situation, here we can do something about it
16:29:01 <racor> RemiFedora: What is your point of criticism, what don't you like?
16:29:03 <tibbs|w> Relying on anything upstream does is the same.
16:29:21 <geppetto> #chair RemiFedora
16:29:21 <zodbot> Current chairs: RemiFedora geppetto mbooth racor tibbs|w tomspur
16:29:25 <pingou> so we until now, we were actually better using git
16:29:40 <mbooth> pingou: I don't think we should legislate for the extreme minority of cases -- if the upstream is known to mess with tags, then use a commit hash -- a packager is capable of making that decision
16:29:51 <tibbs|w> I really don't care either way.
16:30:03 <pingou> mbooth: and how do you find this out?
16:30:06 <RemiFedora> I still thisnk the current Guidelines say "must use the hash commit" to generate a tarball is enough
16:30:07 <tibbs|w> But pulling from a tag and not a hash makes far more sense to me if the tag is available.
16:30:09 <pingou> mbooth: when it's too late?
16:30:22 <geppetto> Yeh, I'd be happy with us saying that the packager can continue using hashes if they want, as a bonus RemiFedora is still good ;)
16:30:52 <gbcox> What I wrote doesn't imply that you can't use commit hash all the time if you want
16:30:55 <tibbs|w> So where in here is the use of tags required?
16:30:58 <RemiFedora> geppetto, hosnetly I don't care too much... except for review I'm going to do or to submit
16:30:59 <tibbs|w> I still don't get it.
16:31:00 <tomspur> pingou: How is this different from tarballs? You need to pull both and compare to the lookaside cache
16:31:10 <gbcox> second, we're already relying on git tags for the version
16:31:13 <pingou> tomspur: the difference: here we have a change to actually do thing right
16:31:35 <RemiFedora> gbcox, No the tag IS NOT the version
16:31:36 <gbcox> and you immediately know by the checksum if there are shenanigans
16:31:50 <gbcox> read the current guidelines remi
16:31:50 <geppetto> Anyway … AIUI me and tibbs_ have +1'd
16:32:00 <pingou> geppetto: https://github.com/Guake/guake ok tell me, did upstream moved tags?
16:32:05 <geppetto> RemiFedora: mbooth racor tomspur: You want to vote?
16:32:08 <pingou> gbcox: ^ sorry
16:32:14 <tibbs|w> I care not at all if we want to drop the tag section entirely, though.
16:32:25 <RemiFedora> the version is something given by upstream, and the tag is usually "nearly" the same 1.0.0 => v1.0.0 => 1_0_0 => FOO-1.0.0... etc
16:32:42 <RemiFedora> how can you imagine using the tag as a version...
16:32:46 <tomspur> pingou: We can also ban tarballs altogether and always check out from vcs... Is this also doing the right thing?
16:32:51 <RemiFedora> no sense
16:32:58 <pingou> tomspur: eventually, it could
16:33:00 <racor> racor: No, though I appreciate this effort (Its a good draft), I think we are not ready to vote.
16:33:03 <geppetto> RemiFedora: You have tag=v%{version}
16:33:21 <gbcox> If the release corresponds to a Git Tag with a sane numeric version, you must use that version to populate the Version Tag in the Spec file.
16:33:24 <geppetto> RemiFedora: And it's super obvious what is happening … the alternative is you have:
16:33:27 <RemiFedora> geppetto, see my previous comment  1.0.0 => v1.0.0 => 1_0_0 => FOO-1.0.0... et
16:33:31 <gbcox> says it right there, we're telling people to rely on it
16:33:34 <geppetto> # This is actually 1.0.1
16:33:50 <geppetto> commit=https://fedoraproject.org/wiki/User:Gbcox/PackagingDrafts/SourceURL
16:34:04 * RemiFedora won't tag anymore its upstream projects
16:34:25 <geppetto> RemiFedora: That's fine … you as a packager and an upstream can do what you want
16:34:54 <geppetto> But I'd much father not have random 6f9eec8f894ff8208dcb085ccfa46d7b39cffdb1 like numbers in my specfiles when they just make things harder
16:35:00 * geppetto shrugs
16:35:22 <geppetto> RemiFedora: There's nothing stopping you from doing what you always did, with these new guidelines
16:35:37 <tibbs|w> The kind of absolutism I'm seeing here is really bizarre.
16:35:45 <RemiFedora> so, please write explicitly they are only example
16:35:52 <RemiFedora> or better move them out the Guidelines
16:35:58 <RemiFedora> in a packaging tips page
16:36:01 <tibbs|w> "I just won't tag any of my packages because I don't want people using tags for any package."
16:36:03 <tibbs|w> I mean, what?
16:36:36 <pingou> tibbs|w: knowing RemiFedora I think the language barrier should be taken into account here
16:36:38 <RemiFedora> tibbs|w, I don't need tag, I provide tarballs
16:36:57 <tibbs|w> Of course you don't need to tag.
16:37:06 <geppetto> RemiFedora: We need the commit/snaptshot info. in the guidelines ... and if the tags info. isn't there then reviewers can/will start failing reviews "because guidelines say you have to use commits"
16:37:13 <tibbs|w> And if you provide tarballs then the second line of the new section in this draft says you should use them.
16:37:23 <tibbs|w> So, again, what's the problem?
16:37:34 <geppetto> RemiFedora: I'm sure gbcox is happy to change some wording in the tags section to make it more obvious that it's a choice to use them
16:38:52 <gbcox> geppetto - correct, my thought here is that it is the packager's discretion on what they use
16:39:45 <gbcox> and the problem is people are reading things into what I wrote, that simply aren't there
16:40:12 <tibbs|w> We can add a note that upstream can move tags and if this is an issue then hashes should be used instead.
16:40:12 <pingou> and again, here is a project: https://github.com/Guake/guake can someone tell me if upstream moved tags ?
16:40:22 <pingou> if not, then relying on tag is... unreliable
16:41:41 <pingou> yes if upstream publishes tarball in an apache server it would be the same
16:41:49 <geppetto> pingou: Can you tell me if: http://example.com/foo/blah.tar.gz … has ever changed?
16:41:50 <pingou> except here we can make a difference
16:41:52 <gbcox> pingou - fedora-review will tell you if the checksum doesn't match
16:42:18 <pingou> gbcox: and you run fedora-review on a daily basis on all your packages?
16:42:43 <gbcox> and you can use the git command to extract the full commit hash from the tar file if you wish
16:42:44 <racor> geppetto: once a package is in Fedora's git you can tell this (sources contains the md5sum)
16:42:46 <pingou> geppetto: I can't, but using git tags I could
16:43:07 <pingou> git hash*
16:43:09 <geppetto> racor: dito. with anything from a git tag
16:43:23 <geppetto> pingou: So we should ban tarballs now?
16:43:35 <pingou> geppetto: did I say that? :)
16:43:35 <racor> geppetto: ACK. I think we are discussing a non issue, here.
16:43:49 <pingou> geppetto: so should we take the easy way or the right way?
16:43:54 <geppetto> pingou: "<pingou> if not, then relying on tag is... unreliable"
16:44:03 <tibbs|w> Actually, can we guarantee that tarballs made from a git hash will have matching checksums if the content didn't change?
16:44:04 <pingou> geppetto: yes, git tags are unreliable
16:44:05 <racor> pingou: "right" is relative
16:44:06 <tibbs|w> I don't think we can.
16:44:19 <tibbs|w> So you can't rely on tarball checksums to tell you anything.
16:44:20 <geppetto> pingou: We should take the way that works 99% of the time, and is obviously right … IMNSHO
16:44:28 <geppetto> Otherwise we end up with offline updates
16:44:52 <gbcox> yes, the checksums will always match
16:44:57 <pingou> geppetto: this makes me think of the FOSS debate, 99% of users use nvidia drivers, that mean we should include them as well?
16:45:08 <tibbs|w> gbcox: Even if different users make the tarballs?
16:45:14 <gbcox> yes
16:45:25 <tibbs|w> Hmm, that's surprising.
16:45:31 <gbcox> if you mean using the tarball function of git
16:45:43 <pingou> gbcox: I was going to ask that :)
16:45:59 <geppetto> pingou: I think the only similarity in those things is the use of 99% … what's your point?
16:46:06 <gbcox> when you use commit hash or git tag the timestamp is stored permanantly for that action
16:46:11 <tibbs|w> tar usually encodes the user into the tarball, but I guess git archive just forces that to root.
16:46:24 <pingou> geppetto: that doing what everyone does does not imply it's the rigth thing to do
16:46:30 <gbcox> it's explained in the link I put in the draft
16:46:34 <tibbs|w> How about this: If using tags, we require that the tag->hash mapping be included in the spec.
16:46:36 <gbcox> under git tag
16:46:50 <pingou> tibbs|w: I'll be ok with that
16:47:08 <tomspur> tibbs|w: If it is should. I still don't see that as a must...
16:47:17 <gbcox> pingou - I actually wrote it that way if you read it
16:47:20 <geppetto> pingou: Yes, we should obviously always do the opposite of what everone wants … new this year in FPC, all votes are opposite because the majority is always wrong
16:47:22 <mizdebsk> tarballs are usually compressed and different flags, versions or even different implementations of the same compressor may give different results
16:47:31 <pingou> geppetto: nice :)
16:47:32 * geppetto rolls eyes
16:47:47 <pingou> geppetto: way to put words in someone else's mouth :)
16:48:04 <tibbs|w> mizdebsk: Indeed, unless you just use uncompressed tarballs.
16:48:15 <tibbs|w> Let's calm down for a bit.
16:48:28 <tibbs|w> We can't 100% rely on tarball checksums, but in general we can.
16:48:36 <tibbs|w> We can't 100% rely on git tags, but in general we can.
16:48:45 <geppetto> RemiFedora: mbooth racor tomspur: You want to vote?
16:48:48 <pingou> we can 100% rely on git hash
16:48:49 <tomspur> +1
16:49:02 <tibbs|w> We can easily know if tags were moved if we require noting the tag->hash mapping.
16:49:05 <tomspur> (With maybe a small rewording)
16:49:05 <racor> -1 (This is not ready)
16:49:18 <RemiFedora> geppetto, I'm not FPC memebr anyumore ;)   but still -1 on the proposal
16:49:19 <racor> NB: my -1 is temporary
16:49:31 <tibbs|w> I reiterate my +1 but we can always fix it.
16:49:49 <tibbs|w> I would certainly also +1 the thing without the tags section.
16:49:50 <geppetto> racor: What needs to change?
16:50:12 <geppetto> RemiFedora: ahh, my bad … thought you were
16:50:16 <geppetto> #unchair RemiFedora
16:50:16 <zodbot> Current chairs: geppetto mbooth racor tibbs|w tomspur
16:50:50 <racor> Like I said before, I am insisting on dates in  addition to hashes, because hashes are not human readable
16:51:06 <geppetto> #chair orionp
16:51:06 <zodbot> Current chairs: geppetto mbooth orionp racor tibbs|w tomspur
16:51:13 <orionp> hello, sorry
16:51:17 <gbcox> racor, isn't that covered in another guideline?
16:51:22 <geppetto> Hey
16:51:27 <racor> I am saying so because I have seen packages with multiple tarballs
16:51:44 <geppetto> orionp: You missed a lot of shouting … but still just looking at 547
16:51:46 <racor> which nobody would be able to understand if only using hashes
16:52:10 <gbcox> think pre-release or snapshot
16:52:12 <geppetto> racor: The tarballs have different names, right?
16:52:13 <racor> gbcox: could you elaborate? I don't understand what you are referring to.
16:52:52 <gbcox> Alternately, if you are using a specific revision that is either a pre-release revision or a post-release revision, you must follow the "snapshot" guidelines. They are documented here: Snapshot packages. You can substitute %{shortcommit0} for %{checkout} in that section.
16:53:07 <gbcox> the date is in %{checkout}
16:53:21 <racor> geppetto: No different versions. sources: x-1.tar.gz, x-2.tar.gz x-3.tar.gz etc.
16:53:23 <gbcox> that's why I didn't go into detail here
16:53:45 <geppetto> gbcox: maybe highlight  that paragraph?
16:54:10 <gbcox> geppetto - I can... I just lifted it directly from the current as is
16:55:42 <gbcox> sorry guys, I didn't think this would be so controversial
16:56:01 <tibbs|w> Neither did I.
16:56:01 * orionp chuckles
16:56:34 <pingou> well the discussion on the list was quite long :)
16:57:00 <geppetto> with about as much positive outcome
16:57:13 <pingou> indeed
16:57:49 <pingou> geppetto: but here FPC gets to vote and close the debate
16:58:06 <mbooth> I can +1 as is, though I dislike it when we add complexity to the guidelines because I think the returns diminish
16:58:14 * mbooth shrugs
16:58:42 <geppetto> orionp: it's all on you now (no pressure ;)
16:58:42 <mbooth> As long as don't mandate commit hashs -- I want to use tags for upstreams who are reliable
16:58:56 <geppetto> Yeh, that's pretty much the point of the policy change.
16:59:00 <racor> geppetto: You don't want to know what I think of such discussions ;) IMO, Fedora has not evolved to the positivly in recent times.
16:59:03 <pingou> geppetto: more than 50% voted +1, so no pressure :)
16:59:14 <geppetto> need 5
16:59:16 <geppetto> have 4
16:59:27 <pingou> ah corum?
16:59:51 <orionp> are we concerned that the submodule stuff will promote bundling?
17:00:12 <geppetto> It's the opposite of bundling, right?
17:00:12 <pingou> that hasn't even been discussed
17:00:34 <geppetto> upstream bundles everything into one git project … we want to unbundle for package … follow those rules.
17:00:44 <gbcox> there is a guideline that discusses bundling... this doesn't change that at all
17:01:05 <pingou> gbcox: I'm always  a little confuse in the difference between sub-modules and bundling
17:01:06 <orionp> how many packages does this git submodule stuff apply to?
17:02:10 <gbcox> orionp - AFAIK it's not a terrible popular feature, but it does come up... Kevin just sent me an example of one he was doing
17:03:02 <racor> OK. my final vote: -1 - I consider it a grave design flaw not to a  steadily increasing tag (similar to dates and version) in git etc checkouts.
17:03:22 <tibbs|w> But that's a flaw with git, isn't it?
17:03:39 <tibbs|w> I mean, git has no monotonic commit identifier.  Nor is it remotely possible to provide one.
17:03:48 <racor> tibbs|w: yes, but it's one we have been able to work around so far.
17:04:03 <tibbs|w> Right, by requiring the date in Release:
17:04:13 <tibbs|w> But that isn't changing.
17:04:15 <racor> this new guide drops this (== regression)
17:04:30 <tibbs|w> Umm, no it doesn't.
17:04:48 <geppetto> Well the date isn't monotonically increasing in git either =
17:04:48 <gbcox> racor - I'm confused a bit... we're relying on tags for version number... we direct folks to at all possible to use it
17:04:52 <tibbs|w> This guideline doesn't even have Release: mentioned.
17:05:07 <tibbs|w> It just tells you to go to the naming guidelines, which are as they always have been.
17:05:10 <tibbs|w> So again, I don't get it.
17:05:26 <racor> tibbs: we had <packager>-%{snapdate}git%{shortcommit}.tar.gz
17:05:35 <tibbs|w> And, wow, we still do.
17:05:47 <racor> <package>-%{snapdate}git%{shortcommit}.tar.gz
17:05:58 <geppetto> racor: We still do in the naming guidlines
17:06:05 <tibbs|w> Wait, we never imposed naming on the actual tarball.  Ever.
17:06:08 <geppetto> racor: This is just for the source0 URL
17:06:21 <geppetto> Nothing has changed
17:06:25 <gbcox> that's the snapshot guidelines isn't it?
17:06:38 <gbcox> I haven't touched that... still applies and I reference it
17:06:39 <tibbs|w> We've never imposed any naming requirements on any tarball ever.
17:07:02 <racor> the end of the source0 url is the tarball name.
17:07:07 <geppetto> gbcox: my brain has melted … yeh, naming snapshots
17:07:15 <tibbs|w> Racor: are you referring to this:
17:07:24 <tibbs|w> For the source tarball, you should use this syntax:
17:07:25 <tibbs|w> Source0:        https://github.com/$OWNER/$PROJECT/archive/%{commit}/$PROJECT-%{commit}.tar.gz
17:07:38 <tibbs|w> Because that's enforced by github, not by us.
17:08:22 <orionp> Can we use something other than $ for these things?  Makes me think of shell variables....
17:08:41 <geppetto> that's what we use in all the other guildelines
17:08:52 <geppetto> although there are a lot here
17:08:55 * geppetto shrugs
17:09:08 <pingou> s/$PROJECT/%{name} ?
17:09:27 <geppetto> pingou: gitname isn't always the same as %name
17:09:34 <tibbs|w> Do we have anything else we can talk about today?
17:09:35 <pingou> true
17:09:45 <tibbs|w> To be honest I thought these were shell variables.
17:09:50 <orionp> and $OWNER is something else
17:09:53 <racor> No, that's not what I am referring to, but I just can't find the page I am referring to anymore.
17:10:22 <orionp> I think I would suggest just dropping the $
17:10:28 <racor> I am sure it existed, because I struggled with it quite a bit to press one of my packages into it.
17:10:37 <tibbs|w> Because this obviously needs some kind of work.  I'm personally OK with doing that incrementally, but I'm happy if others want to wait.
17:11:00 <tibbs|w> The problem is that I don't think we agree on what kind of work it needs.
17:11:05 <geppetto> I'm happy with just removing the $'s
17:11:20 <geppetto> tibbs_: If orionp votes +1 it doesn't need any work
17:11:32 <tibbs|w> Oh, things always need work.
17:11:35 <geppetto> Unless anyone else is stupid enough to try to make it better
17:11:43 <gbcox> ROFL
17:11:47 <pingou> geppetto: thank you
17:11:57 <pingou> geppetto: feel nice to try to contribute
17:12:38 <tibbs|w> Language barrier again.
17:12:52 <pingou> stupid is quite the same in French and in English
17:12:55 <tibbs|w> His comment was not intended to have an insulting connotation.
17:12:59 <geppetto> pingou: Not sure if being sarcastic … but this was a pretty simple "stuff just got better" change, and we've been at it for over an hour.
17:13:21 <geppetto> pingou: That won't exactly inspire people to propose other changes to make other things better.
17:13:26 <pingou> geppetto: and before on the list and I'm still not convinced we're improving
17:13:36 <pingou> and I explained my pov, now I accept the decision of the FPC
17:13:43 <tibbs|w> Oh, we're improving.
17:13:59 <pingou> geppetto: now if I'm not welcomed to express myu opinion, just tell me
17:14:05 <tibbs|w> Because before we had nothing, and people argued about that.  Now we have something over which we can argue!
17:14:53 <orionp> pingou - you don't like moving away from the git hash?  (sorry, I was gone)
17:15:11 <pingou> orionp: basically, yes
17:15:46 <geppetto> Even though he agrees that it's at least as good as tarballs, and doesn't want to remove tarballs
17:15:53 <tibbs|w> I proposed putting the tag->hash mapping in the spec, but tomspur didn't want it as a must.
17:16:14 <gbcox> tag hash mapping is in the guidelines
17:16:24 <pingou> geppetto: actually I would not mind removing tarbal for projects using gits, having a macro that would git clone and generate the tarball would be quite cool
17:16:27 <gbcox> and I give a nice easy command on how to do it
17:16:45 <pingou> geppetto: but that's (imo) out of the scope of this discussion
17:16:46 <tomspur> hmm, where?
17:17:00 <pingou> geppetto: but again, maybe I shouldn't express my opinions...
17:17:12 <gbcox> tomspur:  Once the commit hash and Git Tag are known, you can define them in your Spec file as follows:
17:17:18 <tomspur> You need to have a shortcommit0 for bitbucket, but not for github
17:17:18 <gbcox> it's in the example
17:17:28 <gbcox> the git ls-remote commands gives you both
17:18:20 * tomspur would package a package on github without always adjusting the hash of the new version. But I'm not against it, so having it as a should is just fine
17:19:43 <tomspur> If that is a must and one needs to adjust the hash all the time, there is no point in using tags or commit ids, as you need to provide the information anyhow...
17:19:58 <gbcox> tomspur - yeah, the differences are just quirks of the different services
17:20:37 <gbcox> but again, the full commit hash is just on git command away for anyone who wants it
17:20:48 <tibbs|w> tomspur: Except that using the tag gives you the semantic information you get from an actual version.
17:21:07 <tibbs|w> And once this is all in a standard format, we can write a utility that just does all of this automatically.
17:21:17 <racor> gbcox: Only if the remote repo still exists. If it goes away, the hashes are worthless.
17:21:29 <tomspur> :)
17:21:41 <pingou> racor: well, that's true for any projects
17:21:43 <tibbs|w> Actually the hashes are consistent across any repository.
17:22:04 <tibbs|w> So if someone deletes his github account and I have a checkout, I can just push it to my github repository and everything still works.
17:22:14 <tibbs|w> Except that the project name will need to change, of course.
17:22:20 <gbcox> once you have the tar file, you permanently have the hash... if upstream goes away that can happen with any project
17:22:29 <gbcox> regardess of whether they use git or not
17:22:45 <racor> pingou: remote repos vanish every day. We likely have 100s of packages without upstream in Fedora.
17:22:47 <geppetto> orionp: You have any more questions, or want to vote?
17:22:58 <pingou> racor: very likely
17:23:10 <orionp> I'm +1 with the following - drop the $'s, change PROJECT to %{name} (it's inconsistent now and 99% correct with %name)
17:23:26 <racor> what saved us until now was using tarballs!
17:23:33 <geppetto> gbcox: Can you do that?
17:23:42 <gbcox> yes but...
17:23:46 <tibbs|w> racor: We'll still have tarballs.
17:23:51 <tibbs|w> It's not as if they're going away.
17:23:54 <gbcox> we've got to be carefull with PROJECT
17:24:11 <racor> anyway, I need to quit now.
17:24:13 <racor> bye
17:24:15 <geppetto> Yeh, I assume people will work it out in the few cases where it doesn't work
17:24:24 <tibbs|w> gbcox: For the small amount of cases where project and name aren't the same, you just change one.
17:24:29 <gbcox> ok, that's fine
17:24:35 <tibbs|w> Probably just hardcode it in the URL.  People can figure that out.
17:24:37 <tibbs|w> I hope.
17:24:55 <gbcox> people should be able to figure that out... and it shouldn't cause a reviewer to spin out
17:25:04 * geppetto crosses fingers
17:25:22 <tibbs|w> Anything cause a reviewer to "spin out".  Or go off the deep end.  Or whatever.
17:25:33 <tibbs|w> Sometimes I just go in, assign the package to myself and approve it.
17:25:33 <gbcox> ROFL... ok, let me make the changes should be posted in a little bit
17:25:43 <geppetto> ok, ping us when it's done
17:25:44 <tibbs|w> People hate me for it, and I'm OK with that.
17:25:48 <gbcox> ok
17:25:52 <gbcox> brb
17:25:55 <orionp> I change the section after the git ls-remote to use definition lists - the <pre> made me think it went into a spec file
17:26:25 <geppetto> tibbs|w: I'm more jealous than hating
17:26:47 * pingou still wonders the difference between git sub-modules and bundling
17:26:50 <tibbs|w> Why?  We all have the power.
17:26:57 <tibbs|w> pingou: Me, too, kind of.
17:27:08 <tibbs|w> But I guess there are situations where it's not bundling.
17:27:13 <pingou> tibbs|w: that's what I first asked for the two changes to be separated
17:27:18 <pingou> tibbs|w: when?
17:27:47 <tibbs|w> pingou: Upstream simply choosing that method to organize their sources.
17:27:48 <geppetto> sub-modules are when you are trying to fix bundling upstream
17:27:51 <tibbs|w> It's reasonable.
17:28:08 <orionp> I  would be happy to see git modules go into packaging tricks instead of the guidelines
17:28:19 <pingou> orionp: +1
17:28:22 <tibbs|w> orionp: I wouldn't argue.
17:28:50 <pingou> tibbs|w: so like it's a different library that's bundled into the code and never released on its own or something like this?
17:28:50 <tomspur> +1
17:28:50 <geppetto> I don't really care … although they kind of belong with all the other stuff on this page
17:28:55 <orionp> Most submodule use I've seen has been bundling
17:29:05 <geppetto> Fair enough
17:29:05 <tibbs|w> pingou: To be honest I really have no idea why you'd do that.
17:29:14 <tibbs|w> Well, actually, I do.
17:29:29 <tibbs|w> We have things with blanked bundling exceptions.
17:29:48 <tibbs|w> What's the one that's everywhere?  gnulib or something like that?
17:30:04 <pingou> tibbs|w: yes but then the bundling guidelines apply no?
17:30:16 <tibbs|w> They have blanket exceptions.
17:30:35 <tibbs|w> And using a git submodule would at least allow upstream to keep completely up to date.
17:30:35 <geppetto> yeh, gnulib
17:30:50 <tibbs|w> But I'm just making up an example; given that it's gnu it's probably not in git anyway.
17:30:57 <geppetto> lol
17:30:58 <tibbs|w> It's still a reasonable example anyway.
17:31:12 <geppetto> a lot of gnu has moved to git now, I think
17:31:42 <pingou> +1 for git tricks
17:33:14 * tomspur would also leave soonish. Could we continue next week?
17:34:15 <geppetto> tomspur: it should be done soon
17:34:39 <geppetto> You can obviously +1 now, with the changes that orionp wanted
17:35:01 <geppetto> I'm kind of assuming all the +1s carry over with the minimal change anyway
17:35:35 <tomspur> Hmm, I think I already did :)
17:35:42 <tibbs|w> Me as well.
17:36:04 <tibbs|w> Good thing this was the only thing on the agenda.
17:36:23 <tibbs|w> tomspur: Though I still need to figure out the status of the python stuff.
17:36:37 <tibbs|w> I guess I can't write up anything except the "don't use -OO' bit.
17:37:00 <tomspur> tibbs|w: If the requires of python-macros is not ok, it would be also just fine to push it into redhat-rpm-config
17:37:23 <tibbs|w> I would prefer to do the latter and save a line in a thousand spec files.
17:37:39 <tomspur> tibbs|w: I would just have tested it for a day or two before sending out the announcement and to not break rawhide with all the changes
17:37:47 <tibbs|w> Yes, of course.
17:37:59 <tibbs|w> There are macros in rawhide python currently.
17:38:03 <tibbs|w> Is that not all of them?
17:38:18 <tibbs|w> I also need to see if the bizarre changelog versioning got fixed.
17:38:26 <tomspur> Yes, only that %python_provide is not usable right now
17:38:41 <tibbs|w> Why isn't it usable?
17:38:50 <tomspur> Because it is not in the minimal root
17:38:58 <tibbs|w> Oh, it needs to be defined in order to parse the spec?
17:39:03 <tomspur> Yes...
17:39:28 <tibbs|w> OK, I'll have to play with that.  There are only a few places where that matters but I guess after Provides: is one of them.
17:39:59 <tibbs|w> You can fix it by conditionally defining the macro in the spec, but that's again the kind of stuff we want to avoid.
17:40:01 <geppetto> If it works without the provides then you could just use %{?python_provides}
17:40:15 <tibbs|w> But it doesn't.
17:40:18 <geppetto> ahh
17:40:23 <tibbs|w> You need Provides: %python_provide
17:40:40 <tibbs|w> And without the macro the spec doesn't parse.
17:40:46 <tomspur> No, the "Provides:" is included in the %python_provide
17:40:53 <tibbs|w> Uh, then...
17:40:57 <tomspur> So that should just work then
17:40:58 <tibbs|w> It should just work, no?
17:41:16 <tibbs|w> Needs testing, I guess.
17:41:18 <tomspur> Didn't think about the "?"...
17:41:40 <tibbs|w> For F22/F21 packaging, do you know if there's a chance of getting the python package updated?
17:41:50 <tibbs|w> Or does this stuff need to get into redhat-rpm-macros there?
17:42:50 <tomspur> tibbs|w: I can push the updates once anything is settled in rawhide. mstuchli agreed to that
17:42:59 <tibbs|w> OK, cool.
17:43:18 <gbcox> ok, done
17:44:00 <geppetto> where are you doing the changes?
17:44:16 <gbcox> https://fedoraproject.org/wiki/User:Gbcox/PackagingDrafts/SourceURL
17:44:19 <geppetto> nevermind … shift reload worked
17:44:35 <geppetto> orionp: good?
17:45:05 <tomspur> tibbs|w: a quick test with "?" doesn't work... Will continue tomorrow and let you know...
17:45:09 <tomspur> See you next week
17:45:17 <tibbs|w> Cool, thanks.
17:45:27 <geppetto> tomspur: see ya
17:45:32 <tibbs|w> Need to update denyhosts to v3 with py3 support so I can play with this as well.
17:45:35 <geppetto> tomspur: Enjoy the holiday
17:45:51 <tibbs|w> Does he get a holiday?
17:46:06 <orionp> geppetto - +1
17:46:07 <tibbs|w> I can't remember where he is.
17:46:10 <geppetto> Ahh, I assumed he was in us from "see you next week"
17:46:24 <geppetto> #action SourceURL addition/clarification - Git Hosting Services (+1:5, 0:0, -1:1)
17:46:36 <tibbs|w> Yeah, I'm good with the latest bit.
17:46:38 <geppetto> #topic Open Floor
17:46:45 <tibbs|w> If we need to fix typos or whatever, we can fix them.
17:46:49 <geppetto> yeh
17:47:00 <tibbs|w> I'm sure we'll get a flood of tickets.
17:47:13 <tibbs|w> This one has actually generated more real on-list discussion than any in recent memory.
17:47:25 <geppetto> yeh, that's true
17:47:34 <tibbs|w> I wonder what happened with 540.
17:47:36 <tibbs|w> .fpc 540
17:47:37 <zodbot> tibbs|w: #540 (Define gcc and gcc-c++ as providing minimal C and C++ compilation environments.) – fpc - https://fedorahosted.org/fpc/ticket/540
17:47:44 <tibbs|w> I guess it's stuck in needinfo.
17:47:55 <tibbs|w> The submitter was kind of confused about the process.
17:48:07 <geppetto> yeh
17:48:24 <tibbs|w> I guess I don't have a problem with adding a C and C++ section like we have a section for everything else.
17:48:36 <geppetto> I'm sympathetic to their worries, but I'm also not sure that anything needs to be done
17:48:43 <tibbs|w> Me neither.
17:48:53 <tibbs|w> Most people will blissfully assume that the buildroot will never change.
17:49:04 <tibbs|w> And I doubt it will, but if it does, we don't have to care at all.
17:49:17 <geppetto> And they'll mostly work out what to do when it does, and stuff doesn't build anymore
17:49:35 <tibbs|w> But whatever.  540 is in needinfo anyway.
17:49:40 * geppetto nods
17:50:45 <tibbs|w> I don't know what we're doing with the openstack-neutron thing.
17:51:07 <tibbs|w> That's sort of stuck with the stuff I was hacking on.  If I can ever dig myself out of this hole....
17:53:33 * geppetto nods
17:53:43 <geppetto> Nobody seems to be complaining atm.
17:54:01 <geppetto> But it would be cool to have the generic solution to this problem solved
17:54:31 <geppetto> Anyway … going to close at 55
17:54:37 <geppetto> unless anyone has anything?
17:54:41 <tibbs|w> Nope.
17:54:51 <gbcox> thanks guys!  have a great holiday!
17:54:56 <geppetto> Enjoy the holiday, those of you in the US (or elsewhre that also have holidays ;)
17:55:07 <geppetto> #endmeeting