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. +

Search Discussions

  • Dave Page at Sep 18, 2010 at 7:17 am

    On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian 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
  • Bruce Momjian at Sep 18, 2010 at 2:22 pm

    Dave Page wrote:
    On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian 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. +
  • Andrew Dunstan at Sep 18, 2010 at 2:43 pm

    On 09/18/2010 10:22 AM, Bruce Momjian wrote:
    Dave Page wrote:
    On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjianwrote:
    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
  • Bruce Momjian at Sep 18, 2010 at 2:59 pm

    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 Momjianwrote:
    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. +
  • Tom Lane at Sep 18, 2010 at 3:41 pm

    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
  • Andrew Dunstan at Sep 18, 2010 at 4:26 pm

    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
  • David Blewett at Sep 18, 2010 at 6:21 pm
    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" 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...
  • Andrew Dunstan at Sep 18, 2010 at 6:30 pm

    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
  • Robert Haas at Sep 18, 2010 at 8:00 pm

    On Sat, Sep 18, 2010 at 2:30 PM, Andrew Dunstan 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
  • Matthew D. Fuller at Sep 20, 2010 at 4:21 am
    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.
  • Mark Wong at Sep 20, 2010 at 4:24 pm

    On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian 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 Momjianwrote:
    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
  • Robert Haas at Sep 20, 2010 at 4:38 pm

    On Mon, Sep 20, 2010 at 12:24 PM, Mark Wong wrote:
    On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian 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 Momjianwrote:
    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
  • Andrew Dunstan at Sep 20, 2010 at 4:42 pm

    On 09/20/2010 12:24 PM, Mark Wong wrote:
    On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjianwrote:
    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
  • Mark Wong at Sep 20, 2010 at 5:16 pm

    On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan wrote:
    On 09/20/2010 12:24 PM, Mark Wong wrote:

    On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjianwrote:
    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
  • Andrew Dunstan at Sep 20, 2010 at 5:35 pm

    On 09/20/2010 01:16 PM, Mark Wong wrote:
    On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstanwrote:
    On 09/20/2010 12:24 PM, Mark Wong wrote:
    On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjianwrote:
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 17, '10 at 9:02p
activeSep 20, '10 at 5:35p
posts16
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase