Обсуждение: 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. + *** ./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
<p>Sorry for top-posting... I was under the impression that git over http was just as efficient since 1.6.6 [1].<p>DavidBlewett<br /> 1. <a href="http://github.com/blog/642-smart-http-support">http://github.com/blog/642-smart-http-support</a><br /><p><blockquotetype="cite">On Sep 18, 2010 12:26 PM, "Andrew Dunstan" <<a href="mailto:andrew@dunslane.net" target="_blank">andrew@dunslane.net</a>>wrote:<br /><br /><p><font color="#500050"><br /><br />On 09/18/2010 11:37 AM,Tom Lane wrote:<br /> ><br />> Andrew Dunstan wrote:<br />>>><br />>>> Test machines belong in...</font> Right. I was just reacting to Bruce's observation about what people said about his moving off BSD/OS.<p><fontcolor="#500050"><br /><br />> Bruce Momjian<<a href="mailto:bruce@momjian.us" target="_blank">bruce@momjian.us</a>> writes:<br /> >><br />>> My big point in posting was to say that compiling...</font>Yeah. Git over HTTP is horribly inefficient anyway - it's really a last resort.<br /><br /> cheers<br/><font color="#888888"><br /> andrew</font><p><font color="#500050"><br /><br />-- <br />Sent via pgsql-hackersmailing list (<a href="mailto:pgsql-hackers@postgresql.org" target="_blank">pgsql-hackers@postgresql.org</a>)<br/>To make changes to your sub...</font></blockquote>
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-support >> > > It'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