Re: .spec file Source0 magic for github release source tarballs?
Dne 21.1.2014 18:01, Kaleb KEITHLEY napsal(a): Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? Thanks, -- Kaleb Just thinking loud Wouldn't be useful to have some macro for sources from GitHub? It could look like: Source0: %source_github(name, project, hash) ... Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
Indeed, as well as in other places e. g., the iconcache snippets. --alec On 1/27/14, Vít Ondruch vondr...@redhat.com wrote: Dne 21.1.2014 18:01, Kaleb KEITHLEY napsal(a): Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? Thanks, -- Kaleb Just thinking loud Wouldn't be useful to have some macro for sources from GitHub? It could look like: Source0: %source_github(name, project, hash) ... Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Fri, Jan 24, 2014 at 4:57 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2014-01-24 at 08:13 -0500, Stephen Gallagher wrote: Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. Actually, it's not a problem with tarballs. That's *precisely* why we store the tarball hashes. This way, we at least know whether they still match. It's still better to avoid the problem than to know it exists...I don't think we disagree, I'm just explaining why (I think) it's a good idea to use a commit ID for a github project even if a tarball is available. I'm currently working on a way to prove that a tarball matches a git commit id. It's maybe 1/4 done. The idea is that you could do $ xzcat tarball.tar.xz |git untar --commit=1234abc38387272... --prefix=project-1.23 And you'd get an error if the tarball has been tampered with. (Or if the packager messed up.) The main gotcha I can think of so far is that a lot of projects have release scripts that generate autotools files and such. Those wouldn't be compatible with this scheme (or those files could be stripped back out at untar time and regenerated by a specfile, perhaps). If/when this is done and makes it into upstream git, it would be nice to integrate this into rpm / fedpkg / wherever it goes. I know nothing about rpm internals, though. FWIW, heavyweight git tags can't be rewritten. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 05:49 PM, Adam Williamson wrote: On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. Actually, it's not a problem with tarballs. That's *precisely* why we store the tarball hashes. This way, we at least know whether they still match. And it's still possible to 'ninja' a github repository with a history rewrite (for example if the upstream discovers that they have content that was impermissible to distribute, they might retroactively delete if from the history). This would change all git hashes that occur after this time. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLiZvsACgkQeiVVYja6o6Pe0wCeNUI3x2sa0br+2qMs2MLmL2yX GvsAni3A4//1e5s+hXhbUlh75gtpqazp =fSzG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
Agreed. But the difference is that using full commits a history rewrite will always be detected. Using a tag is making it possible for upstream to bind the same tag to a different commit. And since it's possible, it will happen. It's a shame there is no way to block forced updates on github. It's a little bit to easy to make a history rewrite there. On Fri, Jan 24, 2014 at 2:13 PM, Stephen Gallagher sgall...@redhat.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 05:49 PM, Adam Williamson wrote: On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. Actually, it's not a problem with tarballs. That's *precisely* why we store the tarball hashes. This way, we at least know whether they still match. And it's still possible to 'ninja' a github repository with a history rewrite (for example if the upstream discovers that they have content that was impermissible to distribute, they might retroactively delete if from the history). This would change all git hashes that occur after this time. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLiZvsACgkQeiVVYja6o6Pe0wCeNUI3x2sa0br+2qMs2MLmL2yX GvsAni3A4//1e5s+hXhbUlh75gtpqazp =fSzG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Fri, 2014-01-24 at 08:13 -0500, Stephen Gallagher wrote: Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. Actually, it's not a problem with tarballs. That's *precisely* why we store the tarball hashes. This way, we at least know whether they still match. It's still better to avoid the problem than to know it exists...I don't think we disagree, I'm just explaining why (I think) it's a good idea to use a commit ID for a github project even if a tarball is available. And it's still possible to 'ninja' a github repository with a history rewrite (for example if the upstream discovers that they have content that was impermissible to distribute, they might retroactively delete if from the history). This would change all git hashes that occur after this time. Sure, possible, but probably less common than people doing 'silent' releases... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
.spec file Source0 magic for github release source tarballs?
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
2014/1/21 Kaleb KEITHLEY kkeit...@redhat.com:
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
where there's a button for Source code (tar.gz) pointing at
https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
I'm using a different scheme (there are few at GitHub):
https://github.com/lemenkov/erlsyslog/archive/0.6.2/erlsyslog-0.6.2.tar.gz
E.g.
https://github.com/%{upstream}/%{name}/archive/%{version}/%{name}-%{version}.tar.gz
Actually we should teach our builsystem to work with Git, tags, and
branches and forget about tarballs forever.
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On 01/21/2014 12:09 PM, Richard Shaw wrote: Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. I agree, but practice has shown that few projects on github are using release tags. ~tom == ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
Actually, the GL are pretty clear here: the source should be referenced using the full commit, nothing else. There is some reasoning why. The tag should got to Version: (as long its 'sane'). Besides that this is the existing GL, there is also a subtle difference in git-archive (which supposedly runs this). When archiving a tag, the sources gets today's date. OTOH, when archiving a commit, the sources modification dates are their commit date. Last time I checked this was also true on github. On Tue, Jan 21, 2014 at 6:09 PM, Richard Shaw hobbes1...@gmail.com wrote: On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.comwrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On 01/21/2014 12:39 PM, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com
mailto:leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be
referenced using the full commit, nothing else. There is some
reasoning why. The tag should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle
difference in git-archive (which supposedly runs this). When
archiving a tag, the sources gets today's date. OTOH, when
archiving a commit, the sources modification dates are their commit
date. Last time I checked this was also true on github.
Of course github could change it at any time but it looks to be working
properly right now, in the case of OpenColorIO:
Source0:
https://github.com/%{upstream}/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
Yes, that's the magick I needed. Works for me in nfs-ganesha.
Thanks,
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be referenced
using the full commit, nothing else. There is some reasoning why. The tag
should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle difference in
git-archive (which supposedly runs this). When archiving a tag, the
sources gets today's date. OTOH, when archiving a commit, the sources
modification dates are their commit date. Last time I checked this was also
true on github.
Of course github could change it at any time but it looks to be working
properly right now, in the case of OpenColorIO:
Source0:
https://github.com/%{upstream}/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
run through spectool:
https://github.com/imageworks/OpenColorIO/archive/v1.0.9/OpenColorIO-1.0.9.tar.gz
downloaded right now:
$ curl -LO
https://github.com/imageworks/OpenColorIO/archive/v1.0.9/OpenColorIO-1.0.9.tar.gz
$ ll OpenColorIO-1.0.9
total 72
-rw-rw-r--. 1 build build 11958 Oct 8 17:59 ChangeLog
-rw-rw-r--. 1 build build 15763 Oct 8 17:59 CMakeLists.txt
drwxrwxr-x. 6 build build 4096 Oct 8 17:59 docs
drwxrwxr-x. 5 build build 4096 Oct 8 17:59 export
drwxrwxr-x. 3 build build 4096 Oct 8 17:59 ext
-rw-rw-r--. 1 build build45 Oct 8 17:59 INSTALL
-rw-rw-r--. 1 build build 11286 Oct 8 17:59 LICENSE
-rw-rw-r--. 1 build build 1115 Oct 8 17:59 README
drwxrwxr-x. 6 build build 4096 Oct 8 17:59 share
drwxrwxr-x. 11 build build 4096 Oct 8 17:59 src
drwxrwxr-x. 2 build build 4096 Oct 8 17:59 testdata
Still has the Oct 8 tag date.
Is there a possibility of updating the guidelines? I like this method much
better, no only is it clearer but easier to maintain. Of course if upstream
does not tag releases, then the current method should be used.
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
You could file a issue at the FPC trac, preferably with a proposal for new
GL.
That said, I notice that we use what works for me, despite any GL so
maybe it doesn't matter. Dunno.
--alec
On Tue, Jan 21, 2014 at 6:41 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote:
On 01/21/2014 12:39 PM, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com
mailto:leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be
referenced using the full commit, nothing else. There is some
reasoning why. The tag should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle
difference in git-archive (which supposedly runs this). When
archiving a tag, the sources gets today's date. OTOH, when
archiving a commit, the sources modification dates are their commit
date. Last time I checked this was also true on github.
Of course github could change it at any time but it looks to be working
properly right now, in the case of OpenColorIO:
Source0:
https://github.com/%{upstream}/%{name}/archive/v%{version}/%
{name}-%{version}.tar.gz
Yes, that's the magick I needed. Works for me in nfs-ganesha.
Thanks,
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
