Re: [ANNOUNCE] Git v1.9-rc0
On 01/28/2014 05:58 PM, Kacper Kornet wrote: On Mon, Jan 27, 2014 at 10:58:29AM -0800, Jonathan Nieder wrote: Hi, Kacper Kornet wrote: The change in release numbering also breaks down gitolite v2 setups. One of the gitolite commands, gl-compile-conf, expects the output of git --version to match /git version (\d+)\.(\d+)\.(\d+)/. I have no idea how big problem it is, as I don't know how many people hasn't migrate to gitolite v3 yet. http://qa.debian.org/popcon.php?package=gitolite says there are some. I guess soon we'll see if there are complaints. http://gitolite.com/gitolite/migr.html says gitolite v2 is still maintained. Hopefully the patch to gitolite v2 to fix this would not be too invasive --- e.g., how about this patch (untested)? Thanks, Jonathan diff --git i/src/gl-compile-conf w/src/gl-compile-conf index f497ae5..8508313 100755 --- i/src/gl-compile-conf +++ w/src/gl-compile-conf @@ -394,8 +394,9 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.([^.-]*)/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); +$gv_patchrel = 0 unless ($gv_patchrel =~ m/^\d+$/); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised die \n\t\t* AAARGH! *\n . It works for 1.9.rc1 but I think it will fail with final 1.9. The following version should be ok: diff --git a/src/gl-compile-conf b/src/gl-compile-conf index f497ae5..c391468 100755 --- a/src/gl-compile-conf +++ b/src/gl-compile-conf @@ -394,7 +394,7 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, undef, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)(\.(\d+))?/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised Gitolite v3 will be 2 years old in a month or so. I would prefer to use this as an opportunity to encourage people to upgrade; v2 really has nothing going for it now. People who cannot upgrade gitolite should simply cut that whole block of code and throw it out. Distro's should probably do that if they are still keeping gitolite v2 alive, because it is clearly not needed if the same distro is up to 1.9 of git! My policy has been to continue support for critical bugs. A bug that can be fixed by simply deleting the offending code block, with no harm done, is -- to my mind -- not critical enough :-) side note, Kacper: I'd use non-capturing parens than an undef in the destination list. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Mon, Jan 27, 2014 at 10:58:29AM -0800, Jonathan Nieder wrote: Hi, Kacper Kornet wrote: The change in release numbering also breaks down gitolite v2 setups. One of the gitolite commands, gl-compile-conf, expects the output of git --version to match /git version (\d+)\.(\d+)\.(\d+)/. I have no idea how big problem it is, as I don't know how many people hasn't migrate to gitolite v3 yet. http://qa.debian.org/popcon.php?package=gitolite says there are some. I guess soon we'll see if there are complaints. http://gitolite.com/gitolite/migr.html says gitolite v2 is still maintained. Hopefully the patch to gitolite v2 to fix this would not be too invasive --- e.g., how about this patch (untested)? Thanks, Jonathan diff --git i/src/gl-compile-conf w/src/gl-compile-conf index f497ae5..8508313 100755 --- i/src/gl-compile-conf +++ w/src/gl-compile-conf @@ -394,8 +394,9 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.([^.-]*)/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); +$gv_patchrel = 0 unless ($gv_patchrel =~ m/^\d+$/); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised die \n\t\t* AAARGH! *\n . It works for 1.9.rc1 but I think it will fail with final 1.9. The following version should be ok: diff --git a/src/gl-compile-conf b/src/gl-compile-conf index f497ae5..c391468 100755 --- a/src/gl-compile-conf +++ b/src/gl-compile-conf @@ -394,7 +394,7 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, undef, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)(\.(\d+))?/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised -- Kacper -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Tue, Jan 21, 2014 at 02:14:22PM -0800, Junio C Hamano wrote: It has been reported that turning git.rc into git.res does not like the new 2-dewey-decimal release numbering scheme; packagers of various distro might find similar issues in their build procedures, in which case they have about 3 weeks to update them until the final release. The change in release numbering also breaks down gitolite v2 setups. One of the gitolite commands, gl-compile-conf, expects the output of git --version to match /git version (\d+)\.(\d+)\.(\d+)/. I have no idea how big problem it is, as I don't know how many people hasn't migrate to gitolite v3 yet. -- Kacper -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Hi, Kacper Kornet wrote: The change in release numbering also breaks down gitolite v2 setups. One of the gitolite commands, gl-compile-conf, expects the output of git --version to match /git version (\d+)\.(\d+)\.(\d+)/. I have no idea how big problem it is, as I don't know how many people hasn't migrate to gitolite v3 yet. http://qa.debian.org/popcon.php?package=gitolite says there are some. I guess soon we'll see if there are complaints. http://gitolite.com/gitolite/migr.html says gitolite v2 is still maintained. Hopefully the patch to gitolite v2 to fix this would not be too invasive --- e.g., how about this patch (untested)? Thanks, Jonathan diff --git i/src/gl-compile-conf w/src/gl-compile-conf index f497ae5..8508313 100755 --- i/src/gl-compile-conf +++ w/src/gl-compile-conf @@ -394,8 +394,9 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.([^.-]*)/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); +$gv_patchrel = 0 unless ($gv_patchrel =~ m/^\d+$/); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised die \n\t\t* AAARGH! *\n . -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Jeff King p...@peff.net writes:
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the Releases page of git/git. I
imagine there is a programmatic way to do so via GitHub's API, but I
don't know offhand. I can look into it if you are interested.
I already have a script that takes the three tarballs and uploads
them to two places, so adding GitHub as the third destination should
be a natural and welcome way to automate it.
I came up with the script below, which you can use like:
./script v1.8.2.3 git-1.8.2.3.tar.gz
It expects the tag to already be pushed up to GitHub. I'll leave
sticking it on the todo branch and integrating it into RelUpload to
you. This can also be used to backfill the old releases (though I looked
on k.org and it seems to have only partial coverage).
It sets the prerelease flag for -rc releases, but I did not otherwise
fill in any fields, including the summary and description. GitHub seems
to display reasonably if they are not set.
Thanks.
-- 8 --
#!/bin/sh
#
# usage: $0 tag tarball
repo=git/git
# replace this with however you store your oauth token
# if you don't have one, make one here:
# https://github.com/settings/tokens/new
token() {
pass -n github.web.oauth
Hmph, what is this pass thing?
}
post() {
curl -H Authorization: token $(token) $@
}
# usage: create tag-name
create() {
case $1 in
*-rc*)
prerelease=true
;;
*)
prerelease=false
;;
esac
post -d '
{
tag_name: '$1',
prerelease: '$prerelease'
}' https://api.github.com/repos/$repo/releases;
}
# use: upload release-id filename
upload() {
url=https://uploads.github.com/repos/$repo/releases/$1/assets;
url=$url?name=$(basename $2)
post -H Content-Type: $(file -b --mime-type $2) \
--data-binary @$2 \
$url
}
# This is a hack. If you don't mind a dependency on
# perl's JSON (or another parser), we can do a lot better.
extract_id() {
perl -lne '/id:\s*(\d+)/ or next; print $1; exit 0'
}
create $1 release.json
id=$(extract_id release.json)
upload $id $2 /dev/null
rm -f release.json
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Mon, Jan 27, 2014 at 02:56:28PM -0800, Junio C Hamano wrote:
# replace this with however you store your oauth token
# if you don't have one, make one here:
# https://github.com/settings/tokens/new
token() {
pass -n github.web.oauth
Hmph, what is this pass thing?
It's a poor man's Keychain:
https://github.com/peff/pass
Judging from your use of netrc in Meta/RelUpload, you probably just
want:
token() {
cat ~/.github-token
}
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the Releases page of git/git. I
imagine there is a programmatic way to do so via GitHub's API, but I
don't know offhand. I can look into it if you are interested.
I already have a script that takes the three tarballs and uploads
them to two places, so adding GitHub as the third destination should
be a natural and welcome way to automate it.
I came up with the script below, which you can use like:
./script v1.8.2.3 git-1.8.2.3.tar.gz
It expects the tag to already be pushed up to GitHub. I'll leave
sticking it on the todo branch and integrating it into RelUpload to
you. This can also be used to backfill the old releases (though I looked
on k.org and it seems to have only partial coverage).
It sets the prerelease flag for -rc releases, but I did not otherwise
fill in any fields, including the summary and description. GitHub seems
to display reasonably if they are not set.
-- 8 --
#!/bin/sh
#
# usage: $0 tag tarball
repo=git/git
# replace this with however you store your oauth token
# if you don't have one, make one here:
# https://github.com/settings/tokens/new
token() {
pass -n github.web.oauth
}
post() {
curl -H Authorization: token $(token) $@
}
# usage: create tag-name
create() {
case $1 in
*-rc*)
prerelease=true
;;
*)
prerelease=false
;;
esac
post -d '
{
tag_name: '$1',
prerelease: '$prerelease'
}' https://api.github.com/repos/$repo/releases;
}
# use: upload release-id filename
upload() {
url=https://uploads.github.com/repos/$repo/releases/$1/assets;
url=$url?name=$(basename $2)
post -H Content-Type: $(file -b --mime-type $2) \
--data-binary @$2 \
$url
}
# This is a hack. If you don't mind a dependency on
# perl's JSON (or another parser), we can do a lot better.
extract_id() {
perl -lne '/id:\s*(\d+)/ or next; print $1; exit 0'
}
create $1 release.json
id=$(extract_id release.json)
upload $id $2 /dev/null
rm -f release.json
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Jeff King p...@peff.net writes: Junio, since you prepare such tarballs[1] anyway for kernel.org, it might be worth uploading them to the Releases page of git/git. I imagine there is a programmatic way to do so via GitHub's API, but I don't know offhand. I can look into it if you are interested. I already have a script that takes the three tarballs and uploads them to two places, so adding GitHub as the third destination should be a natural and welcome way to automate it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Will there be any change on how tarballs are distributed, taking into account that Google will be shutting down Google Code Downloads section[1][2]? Cheers Javier Domingo Cansino [1] Google Code download service change announcement: http://google-opensource.blogspot.se/2013/05/a-change-to-google-code-download-service.html [2] Google Code download section FAQ: https://code.google.com/p/support/wiki/DownloadsFAQ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Javier Domingo Cansino javier...@gmail.com writes: Will there be any change on how tarballs are distributed, taking into account that Google will be shutting down Google Code Downloads section[1][2]? Aside from the obvious we won't be able to use something that is no longer offered? They are not the only download site even now, so... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Am I missing something or what's wrong with this:
https://github.com/gitster/git/archive/v1.9-rc0.tar.gz
or any
https://github.com/gitster/git/archive/$TAG.tar.gz
??
(As long as Junio continues to push to github, of course)
Stefan
--
/dev/random says: Folks who think they know it all bug those of us who do
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Stefan Näwe stefan.na...@atlas-elektronik.com writes: Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: Will there be any change on how tarballs are distributed, taking into account that Google will be shutting down Google Code Downloads section[1][2]? Am I missing something or what's wrong with this: https://github.com/gitster/git/archive/v1.9-rc0.tar.gz or any https://github.com/gitster/git/archive/$TAG.tar.gz ?? Do these consume CPU every time somebody asks for a tarball? That might be considered wrong depending on the view. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Näwe stefan.na...@atlas-elektronik.com writes: Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: Will there be any change on how tarballs are distributed, taking into account that Google will be shutting down Google Code Downloads section[1][2]? Am I missing something or what's wrong with this: https://github.com/gitster/git/archive/v1.9-rc0.tar.gz or any https://github.com/gitster/git/archive/$TAG.tar.gz ?? Do these consume CPU every time somebody asks for a tarball? That might be considered wrong depending on the view. No, our infrastructure caches frequently requested tarballs so they don't have to be regenerated on the fly. If you would prefer to distribute a different version of the tarball for the release (e.g. one with a different filename or folder structure), you can upload it directly to the release page of the tag: https://github.com/gitster/git/releases/tag/v1.9-rc0 We'll automatically mirror your release to S3 and serve it from there. You can also go ahead and edit the release page with the changelog you've posted in this email thread to make it more user friendly. WE WILL SERVE YOUR RELEASES, JUNIO BECAUSE WE LOVE YOU -vmg -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Vicent Martí tan...@gmail.com writes: Do these consume CPU every time somebody asks for a tarball? That might be considered wrong depending on the view. No, our infrastructure caches frequently requested tarballs so they don't have to be regenerated on the fly. Thanks. That is certainly good enough for consumers, and better than having to manually create and upload for me ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote: Vicent Martí tan...@gmail.com writes: Do these consume CPU every time somebody asks for a tarball? That might be considered wrong depending on the view. No, our infrastructure caches frequently requested tarballs so they don't have to be regenerated on the fly. Thanks. That is certainly good enough for consumers, and better than having to manually create and upload for me ;-) Two questions: Does regenerating (e.g. if the tarball has dropped out of the cache) change its sums (md5sum or similar) ? In (beyond) linuxfromscratch we use md5sums to verify that a tarball has not changed. Also, will there be links for manpages and htmldocs tarballs ? I note that all of these *are* still available at googlecode for the moment : https://code.google.com/p/git-core/downloads/list ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Ken Moffat zarniwh...@ntlworld.com writes: I note that all of these *are* still available at googlecode for the moment : https://code.google.com/p/git-core/downloads/list As I said, Cgc is not the ony download site. The end of http://git-blame.blogspot.com/p/git-public-repositories.html lists the two sites that currently have the material. I may replace Cgc with something else (and add it/them to the list), but in the meantime I do not think k.org will go out of business in anytime soon, so... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote: Ken Moffat zarniwh...@ntlworld.com writes: I note that all of these *are* still available at googlecode for the moment : https://code.google.com/p/git-core/downloads/list As I said, Cgc is not the ony download site. The end of http://git-blame.blogspot.com/p/git-public-repositories.html lists the two sites that currently have the material. I may replace Cgc with something else (and add it/them to the list), but in the meantime I do not think k.org will go out of business in anytime soon, so... OK, thanks for the pointer to https://www.kernel.org/pub/software/scm/git/ for released tarballs. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote: Two questions: Does regenerating (e.g. if the tarball has dropped out of the cache) change its sums (md5sum or similar) ? In (beyond) linuxfromscratch we use md5sums to verify that a tarball has not changed. The tarballs we auto-generate from tags are cached, but they can change if the cached version expires _and_ the archive-generation code changes. We use git archive to generate the tarballs themselves, and then gzip the with gzip -n. So it should be consistent from run to run. However, very occasionally there are bugfixes in git archive which can affect the output. E.g., commit 22f0dcd (archive-tar: split long paths more carefully, 2013-01-05) changes the representation of certain long paths, and generating a tarball with and without it will result in different checksums (for some repos). So if you are planning on baking md5sums into a package-build system, it is much better to point at official releases which are rolled once by the project maintainer, rather than the automatic tag page. Junio, since you prepare such tarballs[1] anyway for kernel.org, it might be worth uploading them to the Releases page of git/git. I imagine there is a programmatic way to do so via GitHub's API, but I don't know offhand. I can look into it if you are interested. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
