Tom Lane wrote:
In the meantime, though, it's not quite clear why this would lead to
a buildfarm failure --- it should just mean a lot of extraneous files
appearing in a fresh checkout. (Looks a bit harder ... Oh, it looks
like btree_gist has some files that used to be autogenerated and are
Tom Lane wrote:
So I think that cvs rtag -d REL7_4_STABLE pgsql will fix it.
I'd like someone to double-check that though. Also maybe we should back
up the repository first?
Just for your info: all VMs on tribble, which includes cvs, are backed
up at 02:30 every day, CEST (that's 00:30 UTC
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
So I'd say your strategy looks good - backup and remove the phony tag.
I'd also say we should probably be logging tag commands in taginfo.
Presumably we mere mortal committers should not be doing any tagging
whatsoever, and tags
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd like someone to double-check that though. Also maybe we should back
up the repository first?
Just for your info: all VMs on tribble, which includes cvs, are backed
up at 02:30 every day, CEST
Good, but the salient followup
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd like someone to double-check that though. Also maybe we should back
up the repository first?
Just for your info: all VMs on tribble, which includes cvs, are backed
up at 02:30 every day, CEST
Good, but the
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
They are dumped to a NFS share on this schedule. That NFS share is
dumped to
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
They are dumped to a NFS share on this schedule. That NFS share
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
They are dumped to a NFS share on this schedule. That NFS
On 8/15/07, Tom Lane [EMAIL PROTECTED] wrote:
I wrote:
Kris Jurka [EMAIL PROTECTED] writes:
It looks like parts of the CVS repository have been mistagged as belonging
to REL7_4_STABLE or have been corrupted somehow:
I have no idea how you make CVS do that, but I'm
sure there is some
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
They are dumped to a NFS share on this
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd like someone to double-check that though. Also maybe we should back
up the repository first?
Just for your info: all VMs on tribble, which includes cvs, are backed
up at 02:30 every day,
Stefan Kaltenbrunner wrote:
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd like someone to double-check that though. Also maybe we should back
up the repository first?
Just for your info: all VMs on tribble, which includes cvs, are
Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
we should at least log such commands, and maybe disallow to anyone
except Marc's pgsql account.
I don't think we should disallow it. Or otherwise we might one day be stuck
if we need to release while some specific person is on vacation.
I
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
They are dumped to a NFS share on this
Andrew Dunstan wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
They are dumped to
Peter Eisentraut wrote:
Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
we should at least log such commands, and maybe disallow to anyone
except Marc's pgsql account.
I don't think we should disallow it. Or otherwise we might one day be stuck
if we need to release while some
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
we should at least log such commands, and maybe disallow to anyone
except Marc's pgsql account.
I don't think we should disallow it. Or otherwise we might one day be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, August 15, 2007 12:11:35 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
we should at least log such commands, and maybe disallow to anyone
except Marc's pgsql account.
I
Marc G. Fournier wrote:
--On Wednesday, August 15, 2007 12:11:35 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
we should at least log such commands, and maybe disallow to anyone
except Marc's pgsql account.
I don't think we should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, August 15, 2007 20:57:14 +0200 Magnus Hagander
[EMAIL PROTECTED] wrote:
Marc G. Fournier wrote:
--On Wednesday, August 15, 2007 12:11:35 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Am Mittwoch, 15. August 2007 04:20
Marc G. Fournier wrote:
If you're doing that, we should probably just delete the pgsql userid
from the system? Or at least change it so it doesn't have 'dev'
permissions. That way you can't do it wrong in that direction ;-)
Seems reasonable?
there is no pgsql user *on* cvs.postgresql.org,
Looking into recent buildfarm failures on the 7.4 branch:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
It looks like parts of the CVS repository have been mistagged as belonging
to REL7_4_STABLE or have been corrupted somehow:
Kris Jurka [EMAIL PROTECTED] writes:
It looks like parts of the CVS repository have been mistagged as belonging
to REL7_4_STABLE or have been corrupted somehow:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE
Hmm ...
I wrote:
Kris Jurka [EMAIL PROTECTED] writes:
It looks like parts of the CVS repository have been mistagged as belonging
to REL7_4_STABLE or have been corrupted somehow:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE
Tom Lane wrote:
In the meantime, though, it's not quite clear why this would lead to
a buildfarm failure --- it should just mean a lot of extraneous files
appearing in a fresh checkout. (Looks a bit harder ... Oh, it looks
like btree_gist has some files that used to be autogenerated and are
Andrew Dunstan [EMAIL PROTECTED] writes:
Looking at the Committers mail, it looks like there have only been two
very small commits since Michael's series of commits around 12 to 13.5
hours ago, and before that nothing since around 28 hours ago. Do we have
a backup snapshot of the repo taken
I wrote:
I did a fresh checkout of the 7.4 branch and diff'd against my local
copy, and it seems clear that every file that was not in 7.4 at all has
had its HEAD version tagged as REL7_4_STABLE. The files that did exist
then are all right. That's throughout the whole tree, not just in
Tom Lane wrote:
So I think that cvs rtag -d REL7_4_STABLE pgsql will fix it.
I'd like someone to double-check that though.
I will test on a copy of my mirror.
Also maybe we should back
up the repository first?
Amen.
cheers
andrew
---(end of
Andrew Dunstan wrote:
Tom Lane wrote:
So I think that cvs rtag -d REL7_4_STABLE pgsql will fix it.
I'd like someone to double-check that though.
I will test on a copy of my mirror.
I copied the mirror, did a checkout from it, ran the command above in
the checked out version, then
Andrew Dunstan [EMAIL PROTECTED] writes:
So I'd say your strategy looks good - backup and remove the phony tag.
I'd also say we should probably be logging tag commands in taginfo.
Presumably we mere mortal committers should not be doing any tagging
whatsoever, and tags should only be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 14, 2007 22:20:16 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
+1 ... we should at least log such commands, and maybe disallow to anyone
except Marc's pgsql account. Particularly since they don't get
reported in
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tuesday, August 14, 2007 22:20:16 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Meanwhile, is there anyone around who can either (1) tar up the
repository directory tree as root, or (2) confirm that a tarball
made by a non-root committer is sufficient?
I wrote:
Great --- launching cvs rtag command now.
Done, and I got a plausible-looking mix of messages like
cvs rtag: Not removing branch tag `REL7_4_STABLE' from
`/cvsroot/pgsql/src/tutorial/funcs_new.c,v'.
and a fresh checkout of REL7_4_STABLE now matches what I had locally.
So I think we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 14, 2007 23:26:03 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
I wrote:
Great --- launching cvs rtag command now.
Done, and I got a plausible-looking mix of messages like
cvs rtag: Not removing branch tag `REL7_4_STABLE' from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 14, 2007 23:26:03 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
* restrict, or at least log, cvs tag/rtag commands. Maybe report them
to pgsql-committers.
It should be done ... if you try and create a tag, it should generate an
Marc G. Fournier [EMAIL PROTECTED] writes:
That was a good thing, but for security's sake these files ought to be
chown'd to some existing committer's account.
I can do a quick chown -R scrappy on the whole repository ... ok?
Seems close enough, but please keep that tarball around for awhile
Marc G. Fournier [EMAIL PROTECTED] writes:
It should be done ... if you try and create a tag, it should generate
an error message ...
Uh, nope:
$ cvs tag fooey README
T README
$ cvs log README | more
RCS file: /cvsroot/pgsql/src/backend/optimizer/README,v
Working file: README
head: 1.39
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
'k, let me play with it ...
- --On Wednesday, August 15, 2007 00:13:11 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
It should be done ... if you try and create a tag, it should generate
an error message ...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
One better (and done now):
find . -nouser -exec chown scrappy {} \;
so, all files that had valid users owning them stay with those ...
- --On Wednesday, August 15, 2007 00:08:07 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Marc G. Fournier [EMAIL
Marc G. Fournier [EMAIL PROTECTED] writes:
One better (and done now):
find . -nouser -exec chown scrappy {} \;
[ eyeballs repository ... ] Check, that looks great from here.
regards, tom lane
---(end of broadcast)---
TIP
40 matches
Mail list logo
