On 02/21/2011 11:13 AM, Andreas Schwab wrote:
> Stanislav Ochotnicky writes:
>
>> On 02/16/2011 04:58 PM, Andreas Schwab wrote:
>>> That does not mean that the compressed contents will always be the same.
>>
>> $ git clone -q git://github.com/sonatype/sisu
>
> $ GIT_DIR=sisu/.git git archive --p
Stanislav Ochotnicky writes:
> On 02/16/2011 04:58 PM, Andreas Schwab wrote:
>> That does not mean that the compressed contents will always be the same.
>
> $ git clone -q git://github.com/sonatype/sisu
$ GIT_DIR=sisu/.git git archive --prefix="sonatype-sisu-1.4.3.2/" --format=tar
sisu-1.4.3.2
> That does not mean that the compressed contents will always be the same.
> At least the gzip compressed tarballs from github contain a time stamp.
That is true of the tarball-generation feature of gitweb or whatever it's
called last I looked too. It's easily fixed by having it pass -n to gzip
(
On 02/16/2011 04:58 PM, Andreas Schwab wrote:
> Stanislav Ochotnicky writes:
>
>> On 02/16/2011 03:36 PM, Matej Cepl wrote:
>>> Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a):
> Which basically takes the tag name and creates a nice tarball from it.
Although I should pipe it thr
Stanislav Ochotnicky writes:
> On 02/16/2011 03:36 PM, Matej Cepl wrote:
>> Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a):
Which basically takes the tag name and creates a nice tarball from it.
>>>
>>> Although I should pipe it through gzip/bzip2 :-/
>>
>> And you really don't resolve
On 02/16/2011 03:36 PM, Matej Cepl wrote:
> Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a):
>>> Which basically takes the tag name and creates a nice tarball from it.
>>
>> Although I should pipe it through gzip/bzip2 :-/
>
> And you really don't resolve the issue with unstable MD5 checksum.
Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a):
>> Which basically takes the tag name and creates a nice tarball from it.
>
> Although I should pipe it through gzip/bzip2 :-/
And you really don't resolve the issue with unstable MD5 checksum.
Matěj
--
devel mailing list
devel@lists.fedorap
I ran into Github-related issues as well and filed a bug report:
http://support.github.com/discussions/repos/4565-sha-in-download-filename-does-not-match-directory
You can simply append the filename to the URL and it'll work, I'm using
this for example in
http://pkgs.fedoraproject.org/gitweb/?p=
Dne 16.2.2011 02:24, Tom Lane napsal(a):
> Ken Dreyer writes:
>> On Tue, Feb 15, 2011 at 4:22 PM, BJ Dierkes
>> wrote:
>>> I'm wondering how other people have resolved these issues for projects using
>>> GitHub as the upstream Source0 download provider.
>>> Finally, debian has a web app to resol
On 02/16/2011 10:55 AM, Stanislav Ochotnicky wrote:
> On 02/16/2011 12:22 AM, BJ Dierkes wrote:
>> Hello all,
>>
>> I hope I am not the first to come across packaging issues for projects that
>> use GitHub as their upstream source download. For those not familiar,
>> GitHub dynamically generates
On 02/16/2011 12:22 AM, BJ Dierkes wrote:
> Hello all,
>
> I hope I am not the first to come across packaging issues for projects that
> use GitHub as their upstream source download. For those not familiar, GitHub
> dynamically generates downloads for all git 'tags'. So for example:
>
> $ git
BJ Dierkes wrote:
> What would be the thoughts of using that to produce more sane/traditional
> tarbals of upstream GitHub source?
It doesn't fix the third, and main, issue: GitHub-generated tarballs get a
new checksum each time they're regenerated (because some file dates change).
This makes th
Ken Dreyer writes:
> On Tue, Feb 15, 2011 at 4:22 PM, BJ Dierkes
> wrote:
>> I'm wondering how other people have resolved these issues for projects using
>> GitHub as the upstream Source0 download provider.
>> Finally, debian has a web app to resolve these issues at:
>> http://githubredir.debian
On Tue, Feb 15, 2011 at 4:22 PM, BJ Dierkes
wrote:
> I'm wondering how other people have resolved these issues for projects using
> GitHub as the upstream Source0 download provider.
I package a github-hosted package, and I ran across this when I was
testing with rpmlint. It is too bad that Git
Hello all,
I hope I am not the first to come across packaging issues for projects that use
GitHub as their upstream source download. For those not familiar, GitHub
dynamically generates downloads for all git 'tags'. So for example:
$ git tag -a -m 'Tagging 1.0.0' 1.0.0
This would create a t
15 matches
Mail list logo