Re: .spec file Source0 magic for github release source tarballs?

[Andrew Lutomirski]

On Fri, Jan 24, 2014 at 4:57 PM, Adam Williamson  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?

[Alec Leamas]

Indeed, as well as in other places e. g., the iconcache snippets.

--alec

On 1/27/14, Vít Ondruch  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?

[Vít Ondruch]

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?

[Adam Williamson]

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?

[Alec Leamas]

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 wrote:

> -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ý
> >>  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?

[Stephen Gallagher]

-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ý
>>  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?

[Adam Williamson]

On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote:
> On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý 
> 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

Re: .spec file Source0 magic for github release source tarballs?

[Alec Leamas]

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  wrote:

> On 01/21/2014 12:39 PM, Richard Shaw wrote:
>
>> On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas > > 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

Re: .spec file Source0 magic for github release source tarballs?

[Richard Shaw]

On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas  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?

[Kaleb KEITHLEY]

On 01/21/2014 12:39 PM, Richard Shaw wrote:

On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas 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?

[Alec Leamas]

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  wrote:

> On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý 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
>
-- 
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?

[Richard Shaw]

On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý  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?

[Tom Callaway]

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?

[Peter Lemenkov]

2014/1/21 Kaleb KEITHLEY :
>
> 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?

[Miroslav Suchý]

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

.spec file Source0 magic for github release source tarballs?

[Kaleb KEITHLEY]

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