Re: Testsuite regression with perl 5.8.0 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 29/01/15 16:52, Jeff King wrote: Both this and the curl-version issue you reported seem to have simple solutions that you've already worked out and tested. Would you like to express them in the form of patches so they can be applied? :) Patches have been posted as requested. -tgc -- 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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 29/01/15 16:43, Jeff King wrote: Weird. The pubkeys are there in keyring.gpg; I wonder why the older version of gpg has trouble extracting them (and how one was _supposed_ to export secret keys at that time). Importing the unmodified keyring.gpg with 1.2.6 yields this: $ gpg --homedir $GNUPGHOME --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: Total number processed: 2 gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir $GNUPGHOME --list-keys $ gpg --homedir $GNUPGHOME --list-secret-keys /home/tgc/gpghome/secring.gpg - sec 1024D/CDDE430D 2007-06-07 C O Mitter commit...@example.com ssb 2048g/7703B0E5 2007-06-07 sec 2048R/B7227189 2013-03-22 Eris Discordia disc...@example.net ssb 2048R/29472784 2013-03-22 $ So if I understand you correctly, the tests should pass with the patch below? Yes, adding the pubkeys as a separate entity makes gpg 1.2.6 understand things fine. gnupg 1.2.6 with the patched keyring: $ gpg --homedir $GNUPGHOME --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key C O Mitter commit...@example.com imported gpg: key B7227189: public key Eris Discordia disc...@example.net imported gpg: Total number processed: 4 gpg: imported: 2 (RSA: 1) gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir $GNUPGHOME --list-keys /home/tgc/gpghome/pubring.gpg - pub 1024D/CDDE430D 2007-06-07 C O Mitter commit...@example.com sub 2048g/7703B0E5 2007-06-07 pub 2048R/B7227189 2013-03-22 Eris Discordia disc...@example.net sub 2048R/29472784 2013-03-22 $ The patch should work as posted, though I have only tested the new keyring by hand as shown above. It feels a bit hacky, and I wish I knew more about why the current file doesn't work (i.e., if we did gpg --export-secret-keys with v1.2.6, would it produce different output that can be read by both versions?). I grabbed the binary keyrings from 1e3eefb^ and pointed gpg 1.2.6 at them. $ gpg --homedir $GNUPGHOME --armor --export-secret-keys CDDE430D CDDE430D.secret.key $ gpg --homedir $PWD/gpghome3 --import CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome3/secring.gpg' created gpg: keyring `/home/tgc/gpghome3/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir $PWD/gpghome3 --list-keys $ No public key imported however the pubkey *was* exported to CDDE430D.secret.key Importing that same keyfile using gnupg 1.4.5 on an RHEL5 host: $ gpg --homedir $PWD/gpghome --import /tmp/CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key C O Mitter commit...@example.com imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir /home/tgc/gpghome --list-keys /home/tgc/gpghome/pubring.gpg - pub 1024D/CDDE430D 2007-06-07 uid C O Mitter commit...@example.com sub 2048g/7703B0E5 2007-06-07 $ So gnupg 1.2.6 can export fine but cannot correctly import the same. Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). That would seem a bit heavy-handed as it is otherwise working fine with the old gnupg. snip patch -tgc -- Tom G. Christensen - Systemmedarbejder - IT-drift Statsbiblioteket - Victor Albecks Vej 1 - 8000 Aarhus C Tlf: (+45) 8946 2027 - Fax: (+45) 8946 2029 CVR/SE: 10100682 - EAN: 5798000791084 -- 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
All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 28/01/15 00:35, Junio C Hamano wrote: A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. All signed commit tests fail on RHEL4 which is a regression from 2.2.2. From t4202.42: ++ git tag -s -m signed_tag_msg signed_tag gpg: key CDDE430D: secret key without public key - skipped gpg: skipped `C O Mitter commit...@example.com': secret key not available gpg: signing failed: secret key not available error: gpg failed to sign the data error: unable to sign the tag error: last command exited with $?=128 There are indeed no public keys available after commit 1e3eef which seems to be contrary to the commit log: Instead import public and secret keys for one key pair from a text file that holds ASCII-armored export of them. I extracted the pubkeys as ascii armored text from the old binary keyrings and added them to the new keyring.gpg and then the tests pass. This is apparently only a problem for older gnupg versions (RHEL4 has gnupg 1.2.6) since it did not fail on RHEL5 (gnupg 1.4.5). -tgc -- 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
Broken makefile check for curl version on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 28/01/15 00:35, Junio C Hamano wrote:
A release candidate Git v2.3.0-rc2 is now available for testing
at the usual places.
Building is broken on RHEL4 which is a regression from 2.2.2.
The makefile check for curl = 7.34.0 fails and enables
USE_CURL_FOR_IMAP_SEND even though curl is 7.12.1.
# curl-config --vernum
70C01
# { echo 072200; curl-config --vernum 2/dev/null ; } | sort -r | sed -ne 2p
072200
#
I checked the curl release tarballs and this problem seems to exist for
curl 7.11.0 (0x70B00) through 7.12.2 (0x70C02). In both 7.10.7
(0x070a07) and 7.12.3 (0x070c03) the version is correctly set using 6
hex digits as documented.
I tried to verify this using the official curl repo on github but it
does not seem to record this discrepancy and shows the correct 6 digit
version numbers for the affected releases.
As a workaround I'm piping curl-config --vernum through sed -e
'/^70[B-C]/ s/^7/07/'.
-tgc
--
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
Testsuite regression with perl 5.8.0 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 28/01/15 00:35, Junio C Hamano wrote: A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. Commit 2cf770 added testing of the --[no-]xmailer option to git send-email in t9001-send-email.sh Unfortunately it used the modern Getopt::long style of --no-option to negate the option which is not supported with Getopt::Long 2.32 as shipped with perl 5.8.0 on RHEL3 causing the tests to fail. Changing the --no-xmailer option to the old --noxmailer style allows the tests to pass. -tgc -- 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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 02:11:05PM +0100, Tom G. Christensen wrote: All signed commit tests fail on RHEL4 which is a regression from 2.2.2. From t4202.42: ++ git tag -s -m signed_tag_msg signed_tag gpg: key CDDE430D: secret key without public key - skipped gpg: skipped `C O Mitter commit...@example.com': secret key not available gpg: signing failed: secret key not available error: gpg failed to sign the data error: unable to sign the tag error: last command exited with $?=128 There are indeed no public keys available after commit 1e3eef which seems to be contrary to the commit log: Instead import public and secret keys for one key pair from a text file that holds ASCII-armored export of them. I extracted the pubkeys as ascii armored text from the old binary keyrings and added them to the new keyring.gpg and then the tests pass. This is apparently only a problem for older gnupg versions (RHEL4 has gnupg 1.2.6) since it did not fail on RHEL5 (gnupg 1.4.5). Weird. The pubkeys are there in keyring.gpg; I wonder why the older version of gpg has trouble extracting them (and how one was _supposed_ to export secret keys at that time). So if I understand you correctly, the tests should pass with the patch below? It feels a bit hacky, and I wish I knew more about why the current file doesn't work (i.e., if we did gpg --export-secret-keys with v1.2.6, would it produce different output that can be read by both versions?). Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). -- 8 -- Subject: [PATCH] t/lib-gpg: include separate public keys in keyring.gpg Since 1e3eefb (tests: replace binary GPG keyrings with ASCII-armored keys, 2014-12-12), we import our test GPG keys from a single file. Each keypair in the import stream contains both the secret and public keys. However, older versions of gpg reportedly fail to import the public half of the key. We can solve this by including duplicates of the public keys separately. The duplicates are ignored by modern gpg, and this makes older versions work. Reported by Tom G. Christensen t...@statsbiblioteket.dk on gpg 1.2.6 (from RHEL4). Signed-off-by: Jeff King p...@peff.net --- t/lib-gpg.sh | 2 ++ t/lib-gpg/keyring.gpg | 54 +++ 2 files changed, 56 insertions(+) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index d88da29..16e0d3f 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -23,6 +23,8 @@ else # To write armored exported key to keyring: # gpg --homedir /tmp/gpghome --export-secret-keys \ # --armor 0xDEADBEEF lib-gpg/keyring.gpg + # gpg --homedir /tmp/gpghome --export \ + # --armor 0xDEADBEEF lib-gpg/keyring.gpg # To export ownertrust: # gpg --homedir /tmp/gpghome --export-ownertrust \ #lib-gpg/ownertrust diff --git a/t/lib-gpg/keyring.gpg b/t/lib-gpg/keyring.gpg index fb1f048..d4754a1 100644 --- a/t/lib-gpg/keyring.gpg +++ b/t/lib-gpg/keyring.gpg @@ -86,3 +86,57 @@ Z9Ei+zj6JD5Pcdi3BJhQo9WOLOVEJ0NHmewTYqk9QVXH/0v1Hdl4LMJtgcbdbDWk BOW78WUxzhu0YJTLKy+iKCjg5HS5dx6OC+e4aEEgfhNPCMkbvDsJjtQ= =hieJ -END PGP PRIVATE KEY BLOCK- +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1 + +mQGiBEZnyykRBACzCPjIpTYNL7Y2tQqlEGTTDlvZcWNLjF5f7ZzuyOqNOidLUgFD +36qch1LZLSZkShdR3Gae+bsolyjxrlFuFP0eXRPMtqK20aLw7WZvPFpEV1ThMne+ +PRJjYrvghWw3L0VVIAIZ8GXwrVBuU99uEjHEI0ojYloOvFc2jVPgSaoBvwCg48Tj +fol2foSoJa7XUu9yAL8szg8D/RUsTzNF+I9hSRHl7MYKFMYoKEY9BDgrgAujp7YY +8qdGsiUb0Ggyzp2kRjZFt4lpcvKhGfHn5GEjmtk+fRbD5qPfMqKFW+T0NPfYlYmL +JJ4fs4qZ8Lx7x6iG6X51u+YNwsQuIGjMCC3CeNi3F7or651kkNYASbaQ1NROkCIN +NudyA/0aasvoZUoNJAc2cP5Ifs6WhXMWLfMR2p2XbfKwKNYneec60usnSComcKqh +sJVk0Gytvr3FOYVhRkXnKAbx+0W2urFP8OFVBTEKO6Ts2VygWGgneQYoHnqzwlUE +yjOjlr+lyf7u2s/KAxpKA6jnttEdRZAmzWkhuox1wwAUkr27/bQiQyBPIE1pdHRl +ciA8Y29tbWl0dGVyQGV4YW1wbGUuY29tPoheBBMRAgAeBQJGZ8spAhsDBgsJCAcD +AgMVAgMDFgIBAh4BAheAAAoJEBO29R7N3kMNdB0AoL3Z/7A6tORuY8R/676oD8a/ +oHFDAJ9DXbwlcKLcykwHy0jYqajXm1iCebkCDQRGZ8tOEAgAzrl5P1Pr6CDR8mf5 +DGGzcUUM+PEroA4FLdKJ5ZaZc7qy1lmmW9vuvb6xdinwcwee2c5fdNE+iUjHV2x2 +S/dbfDzJTN/0uajZcw+xnf+KxZ0Rs4gDSs7cHXHBtA7u8ShYd4Hu7JggXpiwgfSk +yrGQiZyLAHW2ck8H07Go8eUP8fLIeva+iPqeYQZo9BaPz92R/J6debpeY1lRkv+y +WTq1GE3C/hxbdBAuHf2duLP2uq9kwoVdfzCRjgV1CQmMIbCrMb7vIlzIe96bb3+K +r/+NEtmB2I3wHBXcwJMnIOnz9Zv933KNlxSbVF23BGLB+F9D7OanKymbs7Eg18fr +mt/t/wAEDQgAtGIxGz944Pn2OtheY9JlBRuIAuVskm24/Zz03dZnk6CuEOIBb5IM +g36GAPKcn1vsLZ0TfE1q53jNpcAAXjgngnRsCjZm1mglqPD4ZfBpl+Hhnuc80fAR +xsUPj+5c8KP2M+Rws4moaZRjVpd3KCi3ceflT/OjwnE9DzdhslCGTMA5n8cajAs2 +oqAaQssefVf2prLQLGV9NB4Q3lFnKXdvipHMaAYAsW+iF7JkhTDVNuNGlufeSqUm +igRBjTZXBcVd8sj8vDOCWKUfqxJyS+zRYcotn7QvpvcKAkc3ZGxntDHAIGLVp6ay
Re: Testsuite regression with perl 5.8.0 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 02:30:57PM +0100, Tom G. Christensen wrote: On 28/01/15 00:35, Junio C Hamano wrote: A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. Commit 2cf770 added testing of the --[no-]xmailer option to git send-email in t9001-send-email.sh Unfortunately it used the modern Getopt::long style of --no-option to negate the option which is not supported with Getopt::Long 2.32 as shipped with perl 5.8.0 on RHEL3 causing the tests to fail. Changing the --no-xmailer option to the old --noxmailer style allows the tests to pass. Both this and the curl-version issue you reported seem to have simple solutions that you've already worked out and tested. Would you like to express them in the form of patches so they can be applied? :) -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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 10:43:20AM -0500, Jeff King wrote:
It feels a bit hacky, and I wish I knew more about why the current file
doesn't work (i.e., if we did gpg --export-secret-keys with v1.2.6,
would it produce different output that can be read by both versions?).
Another option is to just declare that version old and broken, and skip
the tests (either by checking its version, or just checking after we
import the keys that we can actually _use_ them).
That would look like this:
-- 8 --
Subject: [PATCH] t/lib-gpg: sanity-check that we can actually sign
Some older versions of gpg (reportedly v1.2.6 from RHEL4)
cannot import the keyrings found in our test suite, and thus
cannot even make a signature. We can detect this case by
doing a test-sign before declaring the GPG prerequisite
fulfilled.
Signed-off-by: Jeff King p...@peff.net
---
t/lib-gpg.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index d88da29..a87747a 100755
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -34,6 +34,8 @@ else
$TEST_DIRECTORY/lib-gpg/keyring.gpg
gpg --homedir ${GNUPGHOME} 2/dev/null --import-ownertrust \
$TEST_DIRECTORY/lib-gpg/ownertrust
+ gpg --homedir ${GNUPGHOME} /dev/null /dev/null 21 \
+ --sign -u commit...@example.com
test_set_prereq GPG
;;
esac
--
2.3.0.rc1.287.g761fd19
--
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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
Tom G. Christensen t...@statsbiblioteket.dk writes: On 29/01/15 16:43, Jeff King wrote: Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). That would seem a bit heavy-handed as it is otherwise working fine with the old gnupg. Thanks, both, for tracking this one down. I am tempted to say that we should do both. This export public key, even though new importers do not need fix to make things usable with 1.2.6, and the other one to catch and skip breakages when future versions of GPG breaks us in whichever way we do not anticipate now. -- 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
[ANNOUNCE] Git v2.3.0-rc2
A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. Hopefully this can become the final v2.3.0 next week, almost as-is. There are no regression noticed and/or fixed since -rc1, and the changes are mostly l10n and minor documentation updates. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.3.0-rc2' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.3 Release Notes (draft) == Updates since v2.2 -- Ports * Recent gcc toolchain on Cygwin started throwing compilation warning, which has been squelched. * A few updates to build on platforms that lack tv_nsec, clock_gettime, CLOCK_MONOTONIC and HMAC_CTX_cleanup (e.g. older RHEL) have been added. UI, Workflows Features * It was cumbersome to use GIT_SSH mechanism when the user wanted to pass an extra set of arguments to the underlying ssh. A new environment variable GIT_SSH_COMMAND can be used for this. * A request to store an empty note via git notes meant to remove note from the object but with --allow-empty we will store a (surprise!) note that is empty. * git interpret-trailers learned to properly handle the Conflicts: block at the end. * git am learned --message-id option to copy the message ID of the incoming e-mail to the log message of resulting commit. * git clone --reference=over there learned the --dissociate option to go with it; it borrows objects from the reference object store while cloning only to reduce network traffic and then dissociates the resulting clone from the reference by performing local copies of borrowed objects. * git send-email learned --transfer-encoding option to force a non-fault Content-Transfer-Encoding header (e.g. base64). * git send-email normally identifies itself via X-Mailer: header in the message it sends out. A new command line flag --no-xmailer allows the user to squelch the header. * git push into a repository with a working tree normally refuses to modify the branch that is checked out. The command learned to optionally do an equivalent of git reset --hard only when there is no change to the working tree and the index instead, which would be useful to deploy by pushing into a repository. * git new-workdir (in contrib/) can be used to populate an empty and existing directory now. * Credential helpers are asked in turn until one of them give positive response, which is cumbersome to turn off when you need to run Git in an automated setting. The credential helper interface learned to allow a helper to say stop, don't ask other helpers. Also GIT_TERMINAL_PROMPT environment can be set to false to disable our built-in prompt mechanism for passwords. * git branch -d (delete) and git branch -m (move) learned to honor -f (force) flag; unlike many other subcommands, the way to force these have been with separate -D/-M options, which was inconsistent. * diff-highlight filter (in contrib/) allows its color output to be customized via configuration variables. * git imap-send learned to take -v (verbose) and -q (quiet) command line options. * git remote add $name $URL is now allowed when url.$URL.insteadOf is already defined. * git imap-send now can be built to use cURL library to talk to IMAP servers (if the library is recent enough, of course). This allows you to use authenticate method other than CRAM-MD5, among other things. * git imap-send now allows GIT_CURL_VERBOSE environment variable to control the verbosity when talking via the cURL library. * The prompt script (in contrib/) learned to optionally hide prompt when in an ignored directory by setting GIT_PS1_HIDE_IF_PWD_IGNORED shell variable. Performance, Internal Implementation, Development Support etc. * Earlier we made rev-list --object-edge more aggressively list the objects at the edge commits, in order to reduce number of objects　 fetched into a shallow repository, but the change affected cases other than fetching into a shallow repository and made it unusably slow (e.g. fetching into a normal repository should not have to suffer the overhead from extra processing). Limit it to a more specific case by introducing --objects-edge-aggressive, a new option to rev-list. * Squelched useless compiler warnings on Mac OS X regarding the crypto API. * The procedure to generate unicode table has been simplified. * Some filesystems assign filemodes in a strange way, fooling then automatic filemode
