Thread: cvsup trouble
I'm trying to update my cvs tree and am currently seeing the following:
Parsing supfile "postgres.cvsup"
Connecting to cvsup.postgresql.org
Cannot connect to cvsup.postgresql.org: Connection refused
Will retry at 20:15:50
Is this expected? Should cvsup.postgresql.org be answering connection
requests yet? My previous connections had been through postgresql.org
(and working for the last few years ;) but currently show
myst$ ./repsync
Parsing supfile "postgres.cvsup"
Connecting to postgresql.org
Connected to postgresql.org
Server software version: REL_16_1
Negotiating file attribute support
Exchanging collection information
Server message: Collection "pgsql" release "cvs" is not available here
Establishing multiplexed-mode data connection
Running
Skipping collection pgsql/cvs
Shutting down connection to server
Finished successfully
So two problems on this one (which might be moot if the new machine
should be doing this instead): the CVSup version is wrong and the
cvs-pulling configuration no longer exists.
- Thomas
Okay, that is fixed ... for some reason, it didn't restart on last reboot, have to watch that one ... On Thu, 20 Sep 2001, Thomas Lockhart wrote: > I'm trying to update my cvs tree and am currently seeing the following: > > Parsing supfile "postgres.cvsup" > Connecting to cvsup.postgresql.org > Cannot connect to cvsup.postgresql.org: Connection refused > Will retry at 20:15:50 > > Is this expected? Should cvsup.postgresql.org be answering connection > requests yet? My previous connections had been through postgresql.org > (and working for the last few years ;) but currently show > > myst$ ./repsync > Parsing supfile "postgres.cvsup" > Connecting to postgresql.org > Connected to postgresql.org > Server software version: REL_16_1 > Negotiating file attribute support > Exchanging collection information > Server message: Collection "pgsql" release "cvs" is not available here > Establishing multiplexed-mode data connection > Running > Skipping collection pgsql/cvs > Shutting down connection to server > Finished successfully > > So two problems on this one (which might be moot if the new machine > should be doing this instead): the CVSup version is wrong and the > cvs-pulling configuration no longer exists. > > - Thomas > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
> Okay, that is fixed ... for some reason, it didn't restart on last reboot,
> have to watch that one ...
Thanks for fixing it. Now of course the machine does not seem to be
visible. That was the case yesterday too; are these planned outages, is
it still bouncing up and down as it is configured, or is it flakey? I
can see postgresql.org pretty consistantly, but cvsup.postgresql.org is
not visible at the same time.
- Thomas
just checked, and the machine has been up 14days now ... I can ssh into it from cvs.postgresql.org, and the last cvsup connection was about 5 minutes ago: Sep 21 09:10:42 server1 cvsupd[50149]: +3 otto@host115.olabinc.com (fs1.olabinc.com) [SNAP_16_1e/16.1] Sep 21 09:11:53 server1 cvsupd[50149]: -3 [165Kin+275Kout] Finished successfully nslookup for it should return: Name: rs.postgresql.org Address: 64.39.15.238 Aliases: cvsup.postgresql.org On Fri, 21 Sep 2001, Thomas Lockhart wrote: > > Okay, that is fixed ... for some reason, it didn't restart on last reboot, > > have to watch that one ... > > Thanks for fixing it. Now of course the machine does not seem to be > visible. That was the case yesterday too; are these planned outages, is > it still bouncing up and down as it is configured, or is it flakey? I > can see postgresql.org pretty consistantly, but cvsup.postgresql.org is > not visible at the same time. > > - Thomas >
Two points 1) I think that the problem with restarting at boot has occurred before. 2) I just sync'ed via cvsup at cvsup.postgresql.org and it deleted all under pgsql/src/interfaces/odbc/*. It also doesnot seem to appear anywhere else. What's up? This is my client version: (193)-> cvsup -v CVSup client, GUI version Copyright 1996-2001 John D. Polstra Software version: SNAP_16_1e Protocol version: 17.0 Operating system: FreeBSD4 http://www.polstra.com/projects/freeware/CVSup/ Report problems to cvsup-bugs@polstra.com This is the start of the output of the session: (195)-> head -20 !$ head -20 20010921.out Parsing supfile "cvsup_config" Connecting to cvsup.postgresql.org Connected to cvsup.postgresql.org Server software version: REL_16_1p3 Falling back to protocol version 16.1 Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection pgsql/cvs > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of > Thomas Lockhart > Sent: Friday, September 21, 2001 6:27 AM > To: Marc G. Fournier > Cc: pgsql-hackers@postgresql.org > Subject: Re: cvsup trouble > > > > Okay, that is fixed ... for some reason, it didn't restart > on last reboot, > > have to watch that one ... > > Thanks for fixing it. Now of course the machine does not seem to be > visible. That was the case yesterday too; are these planned > outages, is > it still bouncing up and down as it is configured, or is it flakey? I > can see postgresql.org pretty consistantly, but > cvsup.postgresql.org is > not visible at the same time. > > - Thomas > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to > majordomo@postgresql.org) > >
Thomas Lockhart <lockhart@fourpalms.org> writes:
> Thanks for fixing it. Now of course the machine does not seem to be
> visible. That was the case yesterday too; are these planned outages, is
> it still bouncing up and down as it is configured, or is it flakey?
Looks fine from here:
$ ping cvsup.postgresql.org
PING rs.postgresql.org: 64 byte packets
64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms
Perhaps there is a routing problem somewhere between you and 64.39.15.238?
That machine is not physically at hub (looks like it's a Rackspace site)
so there might be connectivity issues that are different from hub's.
What do you get from tracerouting to cvsup.postgresql.org?
regards, tom lane
> $ ping cvsup.postgresql.org
> PING rs.postgresql.org: 64 byte packets
> 64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
> 64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms
> Perhaps there is a routing problem somewhere between you and 64.39.15.238?
> That machine is not physically at hub (looks like it's a Rackspace site)
> so there might be connectivity issues that are different from hub's.
> What do you get from tracerouting to cvsup.postgresql.org?
*slaps forehead*
I didn't catch on to the different network, and 64.x has always been a
problem on my firewall/masquerading box since I'm also on a 64.x subnet
and it keeps wanting to put in default routes for a class A network. So
it is all a problem on my end.
I had done some testing at another location yesterday, when I was
finding that cvsup connections were being rejected.
Any hints on how to supress this default route when the network is
configured?
Sorry Marc for the false alarm (today anyway ;)
- Thomas
On Fri, 21 Sep 2001, Thomas Lockhart wrote: > > $ ping cvsup.postgresql.org > > PING rs.postgresql.org: 64 byte packets > > 64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms > > 64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms > > Perhaps there is a routing problem somewhere between you and 64.39.15.238? > > That machine is not physically at hub (looks like it's a Rackspace site) > > so there might be connectivity issues that are different from hub's. > > What do you get from tracerouting to cvsup.postgresql.org? > > *slaps forehead* > > I didn't catch on to the different network, and 64.x has always been a > problem on my firewall/masquerading box since I'm also on a 64.x subnet > and it keeps wanting to put in default routes for a class A network. So > it is all a problem on my end. > > I had done some testing at another location yesterday, when I was > finding that cvsup connections were being rejected. > > Any hints on how to supress this default route when the network is > configured? Best suggestion: Renumber your internal network into one of private networks (10.*, 192.168.*, 172.16.*). Alternate suggestion: configure correct netmask for your internal network (such as, if you choose to be 64.1.1.1 with netmask 255.255.255.0, you will only lose connectivity to 64.1.1.*, not entire 64.*) -alex
> 2) I just sync'ed via cvsup at cvsup.postgresql.org and it deleted all > under pgsql/src/interfaces/odbc/*. It also does not seem to appear > anywhere else. What's up? I see this too. I blew away my repository and populated it from scratch, and still see the problem. In fact, the odbc directory doesn't even appear in (my replicated) repository at all, let alone moving to the attic. Marc, can we verify that the ODBC directory actually exists in the replicated cvs repository? Can we please get a site map to help us navigate around to help diagnose problems? myst$ cvsup -v CVSup client, non-GUI version Copyright 1996-2001 John D. Polstra Software version: SNAP_16_1d Protocol version: 16.1 Operating system: LINUXLIBC6 http://www.polstra.com/projects/freeware/CVSup/ Report problems to cvsup-bugs@polstra.com and the server is running Server software version: REL_16_1p3 This does *not* seem to be fresh enough. JDP recommends installing REL_16_1e, and REL_16_1d was the first with bug fixes for the time tag problem. Not sure what REL_16_1p3 is, but it does not seem to be in the same line of fixed code (maybe a preliminary or patch release from sometime in the past??). Marc, help!! Check http://people.freebsd.org/~jdp/s1g/ for details on the bug and FreeBSD package files which fix it. - Thomas
Fixed ... my exclude file had a rule in it that prevented odbc from being rsync'd down ... all should be downloaded now ... as for a 'sitemap', the server that all of this is on is meant to be purelya 'mirror' of the central one on mail.postgresql.org, except there are no accounts on the machine for you to go looking around it with ... as for a sitemap of the central site ... all the web related stuff is in /usr/local/www, and cvsroot is /cvsroot ... On Sat, 22 Sep 2001, Thomas Lockhart wrote: > > 2) I just sync'ed via cvsup at cvsup.postgresql.org and it deleted all > > under pgsql/src/interfaces/odbc/*. It also does not seem to appear > > anywhere else. What's up? > > I see this too. I blew away my repository and populated it from scratch, > and still see the problem. In fact, the odbc directory doesn't even > appear in (my replicated) repository at all, let alone moving to the > attic. > > Marc, can we verify that the ODBC directory actually exists in the > replicated cvs repository? Can we please get a site map to help us > navigate around to help diagnose problems? > > myst$ cvsup -v > CVSup client, non-GUI version > Copyright 1996-2001 John D. Polstra > Software version: SNAP_16_1d > Protocol version: 16.1 > Operating system: LINUXLIBC6 > http://www.polstra.com/projects/freeware/CVSup/ > Report problems to cvsup-bugs@polstra.com > > and the server is running > > Server software version: REL_16_1p3 > > This does *not* seem to be fresh enough. JDP recommends installing > REL_16_1e, and REL_16_1d was the first with bug fixes for the time tag > problem. Not sure what REL_16_1p3 is, but it does not seem to be in the > same line of fixed code (maybe a preliminary or patch release from > sometime in the past??). > > Marc, help!! Check http://people.freebsd.org/~jdp/s1g/ for details on > the bug and FreeBSD package files which fix it. > > - Thomas >
Thanks Marc ! I just cvsup'ed and odbc seems to be all back. Thanks ! Best regards, .. Otto Otto Hirr OLAB Inc 503.617.6595 otto.hirr@olabinc.com > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Marc > G. Fournier > Sent: Friday, September 21, 2001 7:28 PM > To: Thomas Lockhart > Cc: otto.hirr@olabinc.com; thomas@pgsql.com; > pgsql-hackers@postgresql.org > Subject: Re: cvsup trouble - ODBC blown away !?!? > > > > Fixed ... my exclude file had a rule in it that prevented > odbc from being > rsync'd down ... all should be downloaded now ... > > as for a 'sitemap', the server that all of this is on is meant to be > purelya 'mirror' of the central one on mail.postgresql.org, > except there > are no accounts on the machine for you to go looking around > it with ... > > as for a sitemap of the central site ... all the web related > stuff is in > /usr/local/www, and cvsroot is /cvsroot ... > > > On Sat, 22 Sep 2001, Thomas Lockhart wrote: > > > > 2) I just sync'ed via cvsup at cvsup.postgresql.org and > it deleted all > > > under pgsql/src/interfaces/odbc/*. It also does not > seem to appear > > > anywhere else. What's up? > > > > I see this too. I blew away my repository and populated it > from scratch, > > and still see the problem. In fact, the odbc directory doesn't even > > appear in (my replicated) repository at all, let alone moving to the > > attic. > > > > Marc, can we verify that the ODBC directory actually exists in the > > replicated cvs repository? Can we please get a site map to help us > > navigate around to help diagnose problems? > > > > myst$ cvsup -v > > CVSup client, non-GUI version > > Copyright 1996-2001 John D. Polstra > > Software version: SNAP_16_1d > > Protocol version: 16.1 > > Operating system: LINUXLIBC6 > > http://www.polstra.com/projects/freeware/CVSup/ > > Report problems to cvsup-bugs@polstra.com > > > > and the server is running > > > > Server software version: REL_16_1p3 > > > > This does *not* seem to be fresh enough. JDP recommends installing > > REL_16_1e, and REL_16_1d was the first with bug fixes for > the time tag > > problem. Not sure what REL_16_1p3 is, but it does not seem > to be in the > > same line of fixed code (maybe a preliminary or patch release from > > sometime in the past??). > > > > Marc, help!! Check http://people.freebsd.org/~jdp/s1g/ for > details on > > the bug and FreeBSD package files which fix it. > > > > - Thomas > > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > >
> Fixed ... my exclude file had a rule in it that prevented odbc from being
> rsync'd down ... all should be downloaded now ...
Great! Haven't tested it yet, but Otto is happy so I'm sure I'll be
too...
> > Server software version: REL_16_1p3
> > This does *not* seem to be fresh enough. JDP recommends installing
> > REL_16_1e, and REL_16_1d was the first with bug fixes for the time tag
> > problem. Not sure what REL_16_1p3 is, but it does not seem to be in the
> > same line of fixed code (maybe a preliminary or patch release from
> > sometime in the past??).
What about the server versioning issue? I see no mention of
REL_16_1p<anything> as being safe to use. Please confirm that this is in
fact the 16_1d or 16_1e release!!
- Thomas
On Sat, 22 Sep 2001, Thomas Lockhart wrote: > > Fixed ... my exclude file had a rule in it that prevented odbc from being > > rsync'd down ... all should be downloaded now ... > > Great! Haven't tested it yet, but Otto is happy so I'm sure I'll be > too... > > > > Server software version: REL_16_1p3 > > > This does *not* seem to be fresh enough. JDP recommends installing > > > REL_16_1e, and REL_16_1d was the first with bug fixes for the time tag > > > problem. Not sure what REL_16_1p3 is, but it does not seem to be in the > > > same line of fixed code (maybe a preliminary or patch release from > > > sometime in the past??). > > What about the server versioning issue? I see no mention of > REL_16_1p<anything> as being safe to use. Please confirm that this is in > fact the 16_1d or 16_1e release!! This is what is/was latest in ports after you mentioned the problem ... I'll check ports again over the next day or so to see if John has oploaded something even newer ....
> > What about the server versioning issue? I see no mention of > > REL_16_1p<anything> as being safe to use. Please confirm that this is in > > fact the 16_1d or 16_1e release!! > This is what is/was latest in ports after you mentioned the problem ... > I'll check ports again over the next day or so to see if John has oploaded > something even newer .... Ack! That's the whole point! This is a critical bug fix for which John Polstra has posted the required binaries, including for FreeBSD. If it isn't the right version, we get time-corrupted CVS repositories. The URL is http://people.freebsd.org/~jdp/s1g/ and for all I know that is the only source of packages which contain the fixes. If it isn't the right package, it doesn't fix the problem. I'd really like this so that I can finish the date/time improvements for the beta freeze. - Thomas
> > > Please confirm that this is in
> > > fact the 16_1d or 16_1e release!!
Thank you thank you thank you!!! I see that 16_1e is now installed on
the server, and the world is good again.
I'm about done with extensive patches on date/time support, though I
think I won't be ready to commit them before I leave town for work. I
*should* be able to commit things remotely, and expect to do so Thursday
or Friday after merging with the current cvs tree.
Thanks again for updating the server.
- Thomas
ps. Thank you