git repository still not up to scratch

Saturday, March 20. 2010

The following steps produced a nasty failure for me today, as I was preparing to patch something in release 8.1:

git clone git://git.postgresql.org/git/postgresql.git pgsql
cd pgsql/
git checkout -b REL8_1_STABLE -t origin/REL8_1_STABLE
./configure --prefix=/home/andrew/foo/inst.5702 --with-pgport=5702 --enable-depend \
      --enable-debug --enable-cassert --with-perl -with-openssl
make

The failure looks like this:

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels  \
     -fno-strict-aliasing -fwrapv -g -I../../../../src/include -D_GNU_SOURCE   -c -o indexvalid.o  \
     indexvalid.c -MMD
In file included from ../../../../src/include/executor/execdesc.h:19,
                 from ../../../../src/include/executor/executor.h:17,
                 from ../../../../src/include/executor/execdebug.h:17,
                 from indexvalid.c:19:
../../../../src/include/nodes/execnodes.h:23:29: error: nodes/tidbitmap.h: No such file or directory
In file included from ../../../../src/include/executor/execdesc.h:19,
                 from ../../../../src/include/executor/executor.h:17,
                 from ../../../../src/include/executor/execdebug.h:17,
                 from indexvalid.c:19:
../../../../src/include/nodes/execnodes.h:934: error: expected specifier-qualifier-list before ‘TIDBitmap’
../../../../src/include/nodes/execnodes.h:959: error: expected specifier-qualifier-list before ‘TIDBitmap’
make[4]: *** [indexvalid.o] Error 1

Not a good result. It looks like we still have some way to go before we can be satisfied that the git repository is working as we expect. That also makes it more imperative for me to get the buildfarm work with git and the back branches as soon as possible.

Update

There are similar (but different) failures on the 8.0 and 7.4 branches too. *sigh*.

Posted by Andrew Dunstan in PostgreSQL at 15:58 | Comments (5) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

I've mentioned this failure on -hackers a couple of times. I'm glad to see it bothers someone else

#1 eggyknap on 2010-03-19 23:49 (Reply)

I'm trying to do this via rsync -> cvs2svn -> git-svn because git cvsimport was still running a day after I started it. I suspect we will have to test the one-time imports and then cast off from CVS as storage on some particular day, although git can act as though it's a CVS repository.

#2 David Fetter (Homepage) on 2010-03-22 00:58 (Reply)

If we can't keep the mirror in reasonable working sync with the authoritative CVS repo it is a major problem for me. It means I can't validate that the buildfarm client changes work reliably for the back banches. So to me this is a serious issue right now, and your suggestion doesn't address it satisfactorily.

#2.1 Andrew Dunstan on 2010-03-22 01:54 (Reply)

I wish there were some way to keep CVS->git working, but since CVS is non-transactional, I'm not seeing how to do it. That we're using a non-transactional data store is a problem we need to fix, sooner rather than later.

I get that there's a desire to have an unbroken chain back to Postgres 1.02, or whatever it was, but it is far from clear to me that we have such a thing even in CVS.

#2.1.1 David Fetter (Homepage) on 2010-03-22 07:31 (Reply)

My complaint has nothing to do with an unbroken chain back into the mists of time. It has to do with being able to use the buildfarm to build currently maintained branches, and to test changes to the buildfarm with those branches.

#2.1.1.1 Andrew Dunstan on 2010-03-22 14:44 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry