(Let's try this again, but with less fail!) Getting source tarballs from github is a nightmare. See http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html The debian tool doesn't help very much because one still needs revision garbage in the specfile. Is there any more recent ways to mitigate this? Perhaps we could "lobby" github to change their ways, at least partially?

Corey Richardson wrote: > Getting source tarballs from github is a nightmare. See > http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html > > The debian tool doesn't help very much because one still needs revision > garbage in the specfile. Is there any more recent ways to mitigate this? > Perhaps we could "lobby" github to change their ways, at least partially? I don't know if this will be of any use to you, but for tcplay there isn't a tagged release, so I use this script to create an suitable tarball from a github commit with a known hash, by doing a clone then archiving it locally. Certainly this doesn't solve the problem of not having a source URL. #!/bin/sh # usage: tcplay-get-snapshot.sh <hash> git clone git://github.com/bwalex/tc-play ( cd tc-play && \ git archive --format=tar --prefix=tcplay-$1/ $1 \ ) | xz - >tcplay-$1.tar.xz

On Fri, 2012-04-20 at 20:51 -0700, Eric Smith wrote:

> #!/bin/sh > # usage: tcplay-get-snapshot.sh <hash> > git clone git://github.com/bwalex/tc-play > ( cd tc-play && \ > git archive --format=tar --prefix=tcplay-$1/ $1 \ > ) | xz - >tcplay-$1.tar.xz We could probably add something like this to the 'snippets' bit of the packaging guidelines, since github is pretty significant. Just to try and help packagers do it in a uniform and guideline-complaint way. As a reminder for packagers following the thread - any time you have to 'generate' a source tarball like this (i.e. it is not possible to provide a Source: URL that can be expected to remain valid), you should ensure the tarball is reliably reproducible by others and include all necessary instructions to produce it, using comments in the .spec file and/or a script like Eric's - so if you wanted to use Eric's script, you should ensure you actually check the script itself into git (and probably cite it as a Source itself, so it winds up in the .src.rpm), then have a comment in the .spec file which specifies the invocation of the script that was used to generate the source tarball.

"wget --content-disposition https://github.com/$user/$project/tarball/$tag" lets you download a tarball named $user-$project-$tag-0-$gitsha1.tar.gz. That saves the maintainer from having to document how to generate the tarball, in exchange for dealing with a tarball name that contains random content (the sha1). The path of files in the tarball also contains the sha1. Even so, this still seems preferable to me than making packagers generate the tarball each time and document the process, which seems very prone to error. Regards -- Andy ps btw that wget w/o --content-disposition gets you a tarball named $tag. pps I both package and maintain upstream code in github, guidelines on the wiki would be great.

My problem is I'm wedded to spectool -g and it doesn't use --content-disposition. Would it be safe to have spectool always use that option?

Nice! I'll note explicitly that this also works with short git tags, so: %global commit bd245c9 Source0: https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz %setup -q -n jukka-pcfi-%{commit} works.

On Fri, 2012-04-20 at 20:51 -0700, Eric Smith wrote: > Corey Richardson wrote: >> Getting source tarballs from github is a nightmare. See >> http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html >> >> The debian tool doesn't help very much because one still needs revision >> garbage in the specfile. Is there any more recent ways to mitigate this? >> Perhaps we could "lobby" github to change their ways, at least partially? > > I don't know if this will be of any use to you, but for tcplay there > isn't a tagged release, so I use this script to create an suitable > tarball from a github commit with a known hash, by doing a clone then > archiving it locally. Certainly this doesn't solve the problem of not > having a source URL. > > #!/bin/sh > # usage: tcplay-get-snapshot.sh<hash> > git clone git://github.com/bwalex/tc-play > ( cd tc-play&& \ > git archive --format=tar --prefix=tcplay-$1/ $1 \ > ) | xz ->tcplay-$1.tar.xz We could probably add something like this to the 'snippets' bit of the packaging guidelines, since github is pretty significant. Just to try and help packagers do it in a uniform and guideline-complaint way. As a reminder for packagers following the thread - any time you have to 'generate' a source tarball like this (i.e. it is not possible to provide a Source: URL that can be expected to remain valid), you should ensure the tarball is reliably reproducible by others and include all necessary instructions to produce it, using comments in the .spec file and/or a script like Eric's - so if you wanted to use Eric's script, you should ensure you actually check the script itself into git (and probably cite it as a Source itself, so it winds up in the .src.rpm), then have a comment in the .spec file which specifies the invocation of the script that was used to generate the source tarball.

%global commit bd245c9 Source0: https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz %setup -q -n jukka-pcfi-%{commit}

On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote: > Suppose I cut a package last year: > swift3-1.0.0-878c23.tag.xz > Then I build an RPM: > openstack-swift-plugin-swift3-1.0.0-878c23-1.fc17.noarch.rpm > > Today I run the same git-archve and get: > swift3-1.0.0-5c74ba.tag.xz > openstack-swift-plugin-swift3-1.0.0-5c74ba-1.fc18.noarch.rpm > > Great, how do I update from the old one to the new one? That's why the guidelines are saying: 20110102snap 20110102git 20110102git9e88d7e using the date as well as the git hash http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag Pierre

On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote: > On Mon, 23 Apr 2012 14:08:05 -0600 > Orion Poplawski <orion(a)cora.nwra.com&gt; wrote: > > > %global commit bd245c9 > > > > Source0: > > > https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz > > > > %setup -q -n jukka-pcfi-%{commit} > > I do not understand how this is supposed to work in the face of > "yum update". But if you read his email carefully, Orion isn't speaking about the version. So commit will be bd245c9 but the version might very well be Version: 20120613git%{commit} and as long as the date gets updated, yum will be happy with it.

On Wed, 2012-06-13 at 20:10 +0200, Pierre-Yves Chibon wrote: > On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote: > > On Mon, 23 Apr 2012 14:08:05 -0600 > > Orion Poplawski <orion(a)cora.nwra.com&gt; wrote: > > > > > %global commit bd245c9 > > > > > > Source0: > > > > > https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz > > > > > > %setup -q -n jukka-pcfi-%{commit} > > > > I do not understand how this is supposed to work in the face of > > "yum update". > > But if you read his email carefully, Orion isn't speaking about the > version. > So commit will be bd245c9 but the version might very well be > > Version: 20120613git%{commit} > > and as long as the date gets updated, yum will be happy with it. The guidelines actually require an integer before the date/rcs rev part, which should be incremented at every build. Like so: 1.20110102git9e88d7e 2.20110102git9e88d7e 3.20120201git8fg34f6 4.20120201git8fg34f6 It doesn't get reset when you bump the snapshot, to double-plus-ensure that no mess in the snapshot bit of the tag can ever cause problems.