compile/install of git
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
/rtmp/difftext/x-diffDownload
*** ./git-1.7.3.rc2/Makefile.orig Fri Sep 17 14:01:17 2010
--- ./git-1.7.3.rc2/Makefile Fri Sep 17 14:36:57 2010
***************
*** 1141,1146 ****
--- 1141,1152 ----
endif
endif
+ NO_NSEC = YesPlease
+ NO_PREAD = YesPlease
+ NEEDS_LIBGEN =
+ NO_TCLTK = YesPlease
+ NO_PYTHON = YesPlease
+
-include config.mak.autogen
-include config.mak
***************
*** 1244,1250 ****
PROGRAM_OBJS += daemon.o
endif
ifndef NO_OPENSSL
! OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
BASIC_CFLAGS += -I$(OPENSSLDIR)/include
OPENSSL_LINK = -L$(OPENSSLDIR)/$(lib) $(CC_LD_DYNPATH)$(OPENSSLDIR)/$(lib)
--- 1250,1256 ----
PROGRAM_OBJS += daemon.o
endif
ifndef NO_OPENSSL
! OPENSSL_LIBSSL = -lssl -lcrypto
ifdef OPENSSLDIR
BASIC_CFLAGS += -I$(OPENSSLDIR)/include
OPENSSL_LINK = -L$(OPENSSLDIR)/$(lib) $(CC_LD_DYNPATH)$(OPENSSLDIR)/$(lib)
***************
*** 1260,1266 ****
OPENSSL_LIBSSL =
endif
ifdef NEEDS_SSL_WITH_CRYPTO
! LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto -lssl
else
LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto
endif
--- 1266,1272 ----
OPENSSL_LIBSSL =
endif
ifdef NEEDS_SSL_WITH_CRYPTO
! LIB_4_CRYPTO = $(OPENSSL_LINK) -lssl -lcrypto
else
LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto
endif
***************
*** 1274,1281 ****
EXTLIBS += $(ICONV_LINK) -liconv
endif
ifdef NEEDS_LIBGEN
! EXTLIBS += -lgen
endif
ifdef NEEDS_SOCKET
EXTLIBS += -lsocket
endif
--- 1280,1289 ----
EXTLIBS += $(ICONV_LINK) -liconv
endif
ifdef NEEDS_LIBGEN
! # EXTLIBS += -lgen
endif
+ EXTLIBS += -lpoll
+
ifdef NEEDS_SOCKET
EXTLIBS += -lsocket
endif
***************
*** 1498,1504 ****
ifndef V
QUIET_CC = @echo ' ' CC $@;
QUIET_AR = @echo ' ' AR $@;
! QUIET_LINK = @echo ' ' LINK $@;
QUIET_BUILT_IN = @echo ' ' BUILTIN $@;
QUIET_GEN = @echo ' ' GEN $@;
QUIET_LNCP = @echo ' ' LN/CP $@;
--- 1506,1513 ----
ifndef V
QUIET_CC = @echo ' ' CC $@;
QUIET_AR = @echo ' ' AR $@;
! # QUIET_LINK = @echo ' ' LINK $@;
! QUIET_LINK=
QUIET_BUILT_IN = @echo ' ' BUILTIN $@;
QUIET_GEN = @echo ' ' GEN $@;
QUIET_LNCP = @echo ' ' LN/CP $@;
*** ./git-1.7.3.rc2/git-compat-util.h.orig Fri Sep 17 12:25:09 2010
--- ./git-1.7.3.rc2/git-compat-util.h Fri Sep 17 12:35:23 2010
***************
*** 106,112 ****
#include <arpa/inet.h>
#include <netdb.h>
#include <pwd.h>
! #include <inttypes.h>
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include <grp.h>
--- 106,119 ----
#include <arpa/inet.h>
#include <netdb.h>
#include <pwd.h>
!
! typedef u_int64_t uint64_t;
! typedef u_int32_t uint32_t;
! typedef u_int16_t uint16_t;
! typedef long int intptr_t;
! typedef unsigned long int uintptr_t;
!
! //#include <inttypes.h>
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include <grp.h>
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.
I thought you were replacing that old thing with pile of hardware that
Matthew was putting together?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
Dave Page wrote:
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.I thought you were replacing that old thing with pile of hardware that
Matthew was putting together?
Matthew was busy this summer so I am going to try to get some of his
time by January to switch to Ubuntu. And some people are complaining we
will lose a BSD test machine once I switch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On 09/18/2010 10:22 AM, Bruce Momjian wrote:
Dave Page wrote:
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian<bruce@momjian.us> wrote:
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.I thought you were replacing that old thing with pile of hardware that
Matthew was putting together?Matthew was busy this summer so I am going to try to get some of his
time by January to switch to Ubuntu. And some people are complaining we
will lose a BSD test machine once I switch.
Test machines belong in the buildfarm. And why would they complain about
losing a machine running a totally out of date and unsupported OS? Maybe
you should run BeOS instead.
cheers
andrew
Andrew Dunstan wrote:
On 09/18/2010 10:22 AM, Bruce Momjian wrote:
Dave Page wrote:
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian<bruce@momjian.us> wrote:
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.I thought you were replacing that old thing with pile of hardware that
Matthew was putting together?Matthew was busy this summer so I am going to try to get some of his
time by January to switch to Ubuntu. And some people are complaining we
will lose a BSD test machine once I switch.Test machines belong in the buildfarm. And why would they complain about
losing a machine running a totally out of date and unsupported OS? Maybe
you should run BeOS instead.
Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also research fixes easier because I am using the OS,
rather than running blind tests. I am just telling you what people told
me.
My big point in posting was to say that compiling git was not the
nightmare I expected it to be. I figured it would want tons of newer or
odd libraries I didn't have, but that was not the case at all. I am
sure others will need to compile git themselves for odd operating
systems, and I wanted to encourage them to try.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Andrew Dunstan wrote:
Test machines belong in the buildfarm.
So? People are still going to want to git-ify their buildfarm critters.
Bruce Momjian <bruce@momjian.us> writes:
My big point in posting was to say that compiling git was not the
nightmare I expected it to be.
FWIW, I've also successfully installed git on my old HPUX box.
I avoided most of the library dependencies by giving up support for
http: URLs for repositories. I figure git: and ssh: should cover
what I need to do with it.
For anyone else trying to get it installed on an odd platform:
their configure script improved quite a lot in the last six months,
so get a recent version. I had to do a lot of hacking to get 1.7.1
to build, but 1.7.2.3 fixes most of those problems. It still misses
a few things, but you can probably fix any problems by adjusting the
config.mak.autogen file afterwards.
regards, tom lane
On 09/18/2010 11:37 AM, Tom Lane wrote:
Andrew Dunstan wrote:
Test machines belong in the buildfarm.
So? People are still going to want to git-ify their buildfarm critters.
Right. I was just reacting to Bruce's observation about what people said
about his moving off BSD/OS.
Bruce Momjian<bruce@momjian.us> writes:
My big point in posting was to say that compiling git was not the
nightmare I expected it to be.FWIW, I've also successfully installed git on my old HPUX box.
I avoided most of the library dependencies by giving up support for
http: URLs for repositories. I figure git: and ssh: should cover
what I need to do with it.
Yeah. Git over HTTP is horribly inefficient anyway - it's really a last
resort.
cheers
andrew
Sorry for top-posting... I was under the impression that git over http was
just as efficient since 1.6.6 [1].
David Blewett
1. http://github.com/blog/642-smart-http-support
On Sep 18, 2010 12:26 PM, "Andrew Dunstan" <andrew@dunslane.net> wrote:
On 09/18/2010 11:37 AM, Tom Lane wrote:
Andrew Dunstan wrote:
Test machines belong in ...
Right. I was just reacting to Bruce's observation about what people said
about his moving off BSD/OS.
Bruce Momjian<bruce@momjian.us> writes:
My big point in posting was to say that compiling...
Yeah. Git over HTTP is horribly inefficient anyway - it's really a last
resort.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub...
Import Notes
Reply to msg id not found: AANLkTimF_LVmBU_tisVsEX9uCJtaCEjZZ1XWKnH8OePi@mail.gmail.com
On 09/18/2010 02:20 PM, David Blewett wrote:
I was under the impression that git over http was just as efficient
since 1.6.6 [1].David Blewett
1. http://github.com/blog/642-smart-http-support
It's hard to keep up, the landscape is still changing quite fast.
cheers
andrew
On Sat, Sep 18, 2010 at 2:30 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 09/18/2010 02:20 PM, David Blewett wrote:
I was under the impression that git over http was just as efficient since
1.6.6 [1].David Blewett
1. http://github.com/blog/642-smart-http-supportIt's hard to keep up, the landscape is still changing quite fast.
Every time I've tried to use it, it's been dog slow. But what do I know?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Sat, Sep 18, 2010 at 02:20:53PM -0400 I heard the voice of
David Blewett, and lo! it spake thus:
Sorry for top-posting... I was under the impression that git over http was
just as efficient since 1.6.6 [1].
That's about talking over HTTP to a git server running as CGI; it
doesn't help if you're talking HTTP to just a plain HTTP host.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian <bruce@momjian.us> wrote:
Andrew Dunstan wrote:
On 09/18/2010 10:22 AM, Bruce Momjian wrote:
Dave Page wrote:
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian<bruce@momjian.us> wrote:
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.I thought you were replacing that old thing with pile of hardware that
Matthew was putting together?Matthew was busy this summer so I am going to try to get some of his
time by January to switch to Ubuntu. And some people are complaining we
will lose a BSD test machine once I switch.Test machines belong in the buildfarm. And why would they complain about
losing a machine running a totally out of date and unsupported OS? Maybe
you should run BeOS instead.Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also research fixes easier because I am using the OS,
rather than running blind tests. I am just telling you what people told
me.
I've been slowly trying to rebuild something that was in use at the
OSDL to test patches. I just proofed something that I think works
with the git repository:
http://207.173.203.223:5000/patch/show/48
If you click on the PASS or FAIL text, it will display the SHA1,
author and commit message that the patch was applied to. Think this
will be useful?
Mark
On Mon, Sep 20, 2010 at 12:24 PM, Mark Wong <markwkm@gmail.com> wrote:
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian <bruce@momjian.us> wrote:
Andrew Dunstan wrote:
On 09/18/2010 10:22 AM, Bruce Momjian wrote:
Dave Page wrote:
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian<bruce@momjian.us> wrote:
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.I thought you were replacing that old thing with pile of hardware that
Matthew was putting together?Matthew was busy this summer so I am going to try to get some of his
time by January to switch to Ubuntu. And some people are complaining we
will lose a BSD test machine once I switch.Test machines belong in the buildfarm. And why would they complain about
losing a machine running a totally out of date and unsupported OS? Maybe
you should run BeOS instead.Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also research fixes easier because I am using the OS,
rather than running blind tests. I am just telling you what people told
me.I've been slowly trying to rebuild something that was in use at the
OSDL to test patches. I just proofed something that I think works
with the git repository:http://207.173.203.223:5000/patch/show/48
If you click on the PASS or FAIL text, it will display the SHA1,
author and commit message that the patch was applied to. Think this
will be useful?
Seems interesting. You might need to take precautions against someone
uploading a trojan, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On 09/20/2010 12:24 PM, Mark Wong wrote:
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian<bruce@momjian.us> wrote:
Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also research fixes easier because I am using the OS,
rather than running blind tests. I am just telling you what people told
me.I've been slowly trying to rebuild something that was in use at the
OSDL to test patches. I just proofed something that I think works
with the git repository:http://207.173.203.223:5000/patch/show/48
If you click on the PASS or FAIL text, it will display the SHA1,
author and commit message that the patch was applied to. Think this
will be useful?
The issue has always been how much we want to ask people to trust code
that is not committed. My answer is "not at all." Reviewers and
committers will presumably eyeball the code before trying to compile/run
it, but any automated system of code testing for uncommitted code is way
too risky, IMNSHO.
cheers
andrew
On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 09/20/2010 12:24 PM, Mark Wong wrote:
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian<bruce@momjian.us> wrote:
Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also research fixes easier because I am using the OS,
rather than running blind tests. I am just telling you what people told
me.I've been slowly trying to rebuild something that was in use at the
OSDL to test patches. I just proofed something that I think works
with the git repository:http://207.173.203.223:5000/patch/show/48
If you click on the PASS or FAIL text, it will display the SHA1,
author and commit message that the patch was applied to. Think this
will be useful?The issue has always been how much we want to ask people to trust code that
is not committed. My answer is "not at all." Reviewers and committers will
presumably eyeball the code before trying to compile/run it, but any
automated system of code testing for uncommitted code is way too risky,
IMNSHO.
I was hoping this would be more of a reviewing tool, not something
that would be an excuse for someone to not try running with a patch.
For example, if patch doesn't apply, configure, or build the output is
captured and can be referenced. Also specifically in Bruce's example
if there is enough concern about making the buildfarm red I thought
this could help in these few specific aspects. But maybe I don't
understand the scope of testing Bruce is referring to. :)
Regards,
Mark
On 09/20/2010 01:16 PM, Mark Wong wrote:
On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan<andrew@dunslane.net> wrote:
On 09/20/2010 12:24 PM, Mark Wong wrote:
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian<bruce@momjian.us> wrote:
Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also research fixes easier because I am using the OS,
rather than running blind tests. I am just telling you what people told
me.I've been slowly trying to rebuild something that was in use at the
OSDL to test patches. I just proofed something that I think works
with the git repository:http://207.173.203.223:5000/patch/show/48
If you click on the PASS or FAIL text, it will display the SHA1,
author and commit message that the patch was applied to. Think this
will be useful?The issue has always been how much we want to ask people to trust code that
is not committed. My answer is "not at all." Reviewers and committers will
presumably eyeball the code before trying to compile/run it, but any
automated system of code testing for uncommitted code is way too risky,
IMNSHO.I was hoping this would be more of a reviewing tool, not something
that would be an excuse for someone to not try running with a patch.
For example, if patch doesn't apply, configure, or build the output is
captured and can be referenced. Also specifically in Bruce's example
if there is enough concern about making the buildfarm red I thought
this could help in these few specific aspects. But maybe I don't
understand the scope of testing Bruce is referring to. :)
The whole point of the buildfarm is to identify quickly any
platform-dependent problems. Committers can't be expected to have access
to the whole range of platforms we support, so as long as they make sure
that things are working well on their systems they should be able to
rely on the buildfarm to cover the others. But that also means that the
buildfarm should contain instances of all the supported platforms. I
don't think we should be afraid of sending the buildfarm red. If we do
it's an indication that it's doing its job. If you're a committer and
you haven't made it go red a few times you're either very lucky or not
very active. Making it go red isn't a problem. Leaving it red is, but
we've really been pretty darn good about that.
Having someone act in effect as an informal buildfarm member is less
than satisfactory, IMNSHO. For one thing, it is likely to be less timely
about notifying us of problems than the automated system. And it's also
much less likely to catch problems on the back branches. So if you want
platform X supported (even BSD/OS, regardless of the fact that it's way
out of date), the first thing you should do is set up a buildfarm member
for it.
cheers
andrew