Hello,
While working on an update to the git packages in tgcware(1) I ran into
segfaults when running the testsuite.
Here's what it looks like on Solaris 7/SPARC:
Core was generated by
`/export/home/tgc/buildpkg/git/src/git-upstream/git update-index
should-be-empty'.
Program terminated wit
On 07/04/16 20:32, Junio C Hamano wrote:
"Tom G. Christensen" writes:
The reason for the crash is simple, a null value was passed to the 's'
format for the *printf family of functions.
...
Passing a null value to the 's' format is explicitly documented as
givin
On 07/04/16 20:50, Junio C Hamano wrote:
Junio C Hamano writes:
So perhaps this is all we need to fix your box.
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Yes that seems to work very well.
I applied this patch to 2.8.0 and have completed a testsuite run on
Solaris 2.6
On 07/04/16 22:19, Tom G. Christensen wrote:
On 07/04/16 20:50, Junio C Hamano wrote:
Junio C Hamano writes:
So perhaps this is all we need to fix your box.
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I applied this patch to 2.8.0 and have completed a testsuite run on
On 09/04/16 19:39, Jeff King wrote:
[1/3]: config: lower-case first word of error strings
[2/3]: git_config_set_multivar_in_file: all non-zero returns are errors
[3/3]: git_config_set_multivar_in_file: handle "unset" errors
I applied them to 2.8.1 and ran the testsuite again on Solar
Hello,
Looking at the testsuite results on Solaris I see a failure in t5532.3.
Running the testsuite with -v -i revealed a shell syntax error:
proxying for example.com 9418
./proxy: syntax error at line 3: `cmd=$' unexpected
not ok 3 - fetch through proxy works
#
# git fetch fake
On 09/04/16 23:04, Jeff King wrote:
I did some quick grepping around, and I suspect you may run
into the same thing in other places (e.g., t3404.40 looks
like a similar case).
There are only a few tests that fail and just t5532.3 seems affected by
this issue.
Subject: [PATCH] t5532: use wri
On 04/04/17 04:54, Jeff King wrote:
A nearby thread raised the question of whether we can rely on a version
of libcurl that contains a particular feature. The version in question
is curl 7.11.1, which came out in March 2004.
My feeling is that this is old enough to stop caring about. Which means
: Tom G. Christensen
---
perl/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/perl/Makefile b/perl/Makefile
index 15d96fcc7..ce53a240c 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -25,7 +25,12 @@ clean:
$(makfile): PM.stamp
ifdef NO_PERL_MAKEMAKER
With curl < 7.10.7 we cannot get the proxy CONNECT response code.
As a workaround set it to zero which means no response code available.
Signed-off-by: Tom G. Christensen
---
http.c | 4
1 file changed, 4 insertions(+)
diff --git a/http.c b/http.c
index 96d84bbed..ce618bdca 100644
--
This allows running the git-svn testsuite with Python 2.2.
Signed-off-by: Tom G. Christensen
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 11ac6f692..86bf4a742
This adds man page installation when using NO_PERL_MAKEMAKER to ensure
parity with the normal case where ExtUtils::MakeMaker is used.
Signed-off-by: Tom G. Christensen
---
perl/Makefile | 13 +
1 file changed, 13 insertions(+)
diff --git a/perl/Makefile b/perl/Makefile
index
These are patches currently needed to support building and running git
on RHEL/CentOS 3 and 4.
Tom G. Christensen (7):
Make NO_PERL_MAKEMAKER behave more like ExtUtils::MakeMaker
Install man pages when NO_PERL_MAKEMAKER is used
Allow svnrdump_sim.py to be used with Python 2.2
Handle
This adds an OLD_GNUPG define to the Makefile which when activated will
ensure git does not use the --keyid-format argument when calling the
'gpg' program.
This is consistent with how 'gpg' was used in git < 2.10.0 and slightly
decreases security.
Signed-off-by: Tom G. Chr
Do not try and use CURLINFO_SSL_DATA_{IN,OUT} for curl < 7.12.1.
Signed-off-by: Tom G. Christensen
---
http.c | 4
1 file changed, 4 insertions(+)
diff --git a/http.c b/http.c
index ce618bdca..a46ab23af 100644
--- a/http.c
+++ b/http.c
@@ -649,10 +649,12 @@ static int curl_trace(C
Commit 17966c0a added an unguarded use of curl_easy_strerror.
This adds a guard so it is not used with curl < 7.12.0.
Signed-off-by: Tom G. Christensen
---
http.c | 4
1 file changed, 4 insertions(+)
diff --git a/http.c b/http.c
index a46ab23af..104caaa75 100644
--- a/http.c
+++ b/htt
On 05/04/17 12:51, Ævar Arnfjörð Bjarmason wrote:
On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen
wrote:
Whoah. So my assumption in
that nobody was compiling this & thus not reporting failures was
false. Rather there's an entire community & distribution mechanism
around pat
On 05/04/17 15:40, Ævar Arnfjörð Bjarmason wrote:
On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen wrote:
This allows running the git-svn testsuite with Python 2.2.
+CC-ing Eric S. Raymond who added these version limitations in a33faf2827.
Also, in his patch contrib/svn-fe/svnrdump_sim.py
On 06/04/17 11:21, Jeff King wrote:
On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:
I don't use the el3 and el4 versions much any more and el5 use will also
drop of now as I'm busy converting machines from el5 to el7.
Thanks for sharing, that's a really i
On 09/08/17 15:38, Ævar Arnfjörð Bjarmason wrote:
RHEL/CentOS 5.x has perl 5.8.8, but it also has curl 7.15.5[1] which is
obseleted by these curl patches. Maybe we'd want to be more conservative
with perl for whatever reason, but I'd like to at least bump our
requirenment of 5.8.0 to 5.8.8. Thos
[I am resending this since the original does not seem to have made it to
the list, at least I cannot find it in any archives]
On 09/08/17 23:47, Jeff King wrote:
On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote:
I mean, if we even go out of our way to support the completely
On 09/08/17 23:47, Jeff King wrote:
On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote:
I mean, if we even go out of our way to support the completely outdated
and obsolete .git/branches/ for what is likely a single user, it may not
be the worst to keep those couple of #ifdef gu
On 10/08/17 23:32, Jeff King wrote:
On Thu, Aug 10, 2017 at 10:33:18PM +0200, Tom G. Christensen wrote:
You've totally ignored the argument I made back then[1], and which I
reiterated in this thread. So I'll say it one more time: the more
compelling reason is not the #ifdefs, but the
On 11/08/17 00:54, Jeff King wrote:
On Fri, Aug 11, 2017 at 12:23:42AM +0200, Tom G. Christensen wrote:
Er, sorry if I'm being dense, but how? Are you suggesting that by
removing the callsite of get_curl_allowed_protocols(), the compiler
might elide the now-dead code completely? I
On 11/08/17 01:23, Jeff King wrote:
On Fri, Aug 11, 2017 at 01:17:51AM +0200, Tom G. Christensen wrote:
OK, thanks for double-checking. I'm still puzzled why your build
succeeds and mine does not.
I know what's going on now and it's so simple.
Red Hats version of curl 7.
Turn the version check into a feature check to ensure this functionality
is also enabled with vendor supported curl versions where the feature
may have been backported.
Signed-off-by: Tom G. Christensen
---
http.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/http.c
these changes against upstream curl 7.12.0 (fails),
7.12.1 and 7.15.5. I have also built and run the testsuite against the
Red Hat provided curl versions listed above.
Tom G. Christensen (2):
http: Fix handling of missing CURLPROTO_*
http: use a feature check to enable GSSAPI delegation control
h
check.
This is done to ensure that vendor supported curl versions that have had
CURLPROTO_* support backported are handled correctly.
Signed-off-by: Tom G. Christensen
---
http.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/http.c b/http.c
index e00264cff..569909e8a 100644
On 12/08/17 00:15, Junio C Hamano wrote:
"Tom G. Christensen" writes:
I have build tested these changes against upstream curl 7.12.0 (fails),
7.12.1 and 7.15.5. I have also built and run the testsuite against the
Red Hat provided curl versions listed above.
Hmph, what does &quo
On 12/08/17 02:30, Junio C Hamano wrote:
This may make the code to _compile_, but is it sensible to let the
code build and be used by the end users without the "these protocols
are safe" filter, I wonder?
Git will display a warning at runtime if this is not available but
perhaps this warning
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.
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 withou
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- to
nega
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.
-tgc
--
Tom G. Christensen - Systemmedarbejder - IT-drift
Statsbiblioteket - Victor Albecks Vej 1 - 8000 Aar
;. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
See also:
d2559f734bba7fe5257720356a92f3b7a5b0d37c
907a0b1e04ea31cb368e9422df93d8ebb0187914
84eeb687de7a6c7c42af3fb51b176e0f412a979e
3fee1fe87144360a1913eab86af9ad136c810076
S
correctly.
Signed-off-by: Tom G. Christensen
---
This was discoved while building on RHEL4 which has curl 7.12.1.
The makefile check for curl >= 7.34.0 failed and enabled
USE_CURL_FOR_IMAP_SEND.
# curl-config --vernum
70C01
# { echo 072200; curl-config --vernum 2>/dev/null ; } | sort -r | s
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 uns
On 30/01/15 15:50, Andreas Schwab wrote:
"Tom G. Christensen" writes:
diff --git a/Makefile b/Makefile
index c44eb3a..69a2ce3 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,13 +1035,13 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PR
On 01/02/15 23:48, Junio C Hamano wrote:
I was reviewing the recent bugs and fixes for the last time, and was
wondering if we want to do 2.3-rc3 with build fix for those with
ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround
for those with Perl with older Getopt::Long (tc/t9001-n
The __builtin_ctzll function was added in gcc 3.4.0.
This extends the check for gcc so that use of __builtin_ctzll is only
enabled if gcc >= 3.4.0.
---
I noticed this on RHEL3 during 2.0.0rc phase but I see that the same
issue was noticed on Debian Sarge:
http://article.gmane.org/gmane.comp.versio
Commit dd61399 introduced support for http proxies that require
authentication but it relies on the CURL_PROXYAUTH option which was
added in curl 7.10.7.
This makes sure proxy authentication is only enabled if libcurl can
support it.
Signed-off-by: Tom G. Christensen
---
RHEL3 ships with curl
The __builtin_ctzll function was added in gcc 3.4.0.
This extends the check for gcc so that use of __builtin_ctzll is only
enabled if gcc >= 3.4.0.
Signed-off-by: Tom G. Christensen
---
v2:
Add S-o-b
v1:
I noticed this on RHEL3 during 2.0.0rc phase but I see that the same
issue was noticed
01: turn --no$option workarounds to --no-$option
Kyle J. McKay (1):
git-send-email.perl: support no- prefix with older GetOptions
git-send-email.perl | 10 ++
t/t9001-send-email.sh | 10 +-
2 files changed, 15 insertions(+), 5 deletions(-)
Tested-by: Tom G. Christensen
I
43 matches
Mail list logo
