Re: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)dunslane(dot)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(at)momjian(dot)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(at)postgresql(dot)org)
To make changes to your sub...

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(at)dunslane(dot)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(at)over-yonder(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)gmail(dot)com> wrote:
> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)dunslane(dot)net> wrote:
>
>
> On 09/20/2010 12:24 PM, Mark Wong wrote:
>>
>> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian<bruce(at)momjian(dot)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(at)dunslane(dot)net> wrote:
>>
>> On 09/20/2010 12:24 PM, Mark Wong wrote:
>>> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian<bruce(at)momjian(dot)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