Thread: compile/install of git

compile/install of git

From
Bruce Momjian
Date:
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>

Re: compile/install of git

From
Dave Page
Date:
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


Re: compile/install of git

From
Bruce Momjian
Date:
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. +


Re: compile/install of git

From
Andrew Dunstan
Date:

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


Re: compile/install of git

From
Bruce Momjian
Date:
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. +


Re: compile/install of git

From
Tom Lane
Date:
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


Re: compile/install of git

From
Andrew Dunstan
Date:

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


Re: compile/install of git

From
David Blewett
Date:
<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> 

Re: compile/install of git

From
Andrew Dunstan
Date:



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


Re: compile/install of git

From
Robert Haas
Date:
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


Re: compile/install of git

From
"Matthew D. Fuller"
Date:
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.


Re: compile/install of git

From
Mark Wong
Date:
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


Re: compile/install of git

From
Robert Haas
Date:
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


Re: compile/install of git

From
Andrew Dunstan
Date:

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


Re: compile/install of git

From
Mark Wong
Date:
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


Re: compile/install of git

From
Andrew Dunstan
Date:

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