gdb.git hiccup

gdb.git hiccup

[Jim Meyering]

FYI,

In setting up binutils.git, my mirroring script added a bunch of junk to
gdb.git's staging repo (blame the module name that they share, "src"),
and then the regularly-scheduled "sync-from-cvs" pushed a bunch of old
binutils commits and refs to the official gdb.git repo.

Bottom line: gdb.git just got a lot bigger, and at least one ref
(master) is no longer pointing where it should.

If someone can point me to a gdb.git repository I can trust, preferably
already uploaded to sourceware,org, I'll put things back in order.

Sorry for the trouble,

Jim

Re: gdb.git hiccup

[Jim Meyering]

Jim Meyering wrote:
> In setting up binutils.git, my mirroring script added a bunch of junk to
> gdb.git's staging repo (blame the module name that they share, "src"),
> and then the regularly-scheduled "sync-from-cvs" pushed a bunch of old
> binutils commits and refs to the official gdb.git repo.
>
> Bottom line: gdb.git just got a lot bigger, and at least one ref
> (master) is no longer pointing where it should.
>
> If someone can point me to a gdb.git repository I can trust, preferably
> already uploaded to sourceware,org, I'll put things back in order.

BTW, I will soon have a copy, thanks to Matt Rice.

Re: gdb.git hiccup

[Jim Meyering]

Jim Meyering wrote:
> Jim Meyering wrote:
>> In setting up binutils.git, my mirroring script added a bunch of junk to
>> gdb.git's staging repo (blame the module name that they share, "src"),
>> and then the regularly-scheduled "sync-from-cvs" pushed a bunch of old
>> binutils commits and refs to the official gdb.git repo.
>>
>> Bottom line: gdb.git just got a lot bigger, and at least one ref
>> (master) is no longer pointing where it should.
>>
>> If someone can point me to a gdb.git repository I can trust, preferably
>> already uploaded to sourceware,org, I'll put things back in order.

FYI, so far, here's all I've done:

  head=a4a5c910c73f0bf2b7d063912274461838139423
  git update-ref HEAD $head
  git update-ref master $head

That should be enough for now.
However, I'll bet there are now a ton of useless-to-gdb
references (tags and branches) and commits taking up lots of space.
If anyone can say which tags and branches can be removed, I'll be happy
to remove them and prune all associated commits.

At the same time, I'll compress the whole server-side repo
to a more reasonable size.  Currently it weighs in at around 500MB.

Let me know.

Re: gdb.git hiccup

[Joel Brobecker]

Hi Jim,

Bad luck on the gdb.git repository. I have been very much enjoying
the git mirror for GDB, so I'm very thankful you're taking the time
to do that for us.

> If anyone can say which tags and branches can be removed, I'll be happy
> to remove them and prune all associated commits.

Do you think they take much space? Perhaps keeping all the branches
related to GDB might be convenient occasionally.

The following branches are not gdb-related, so I'm assuming we can
get rid of them:

  origin/binutils-2_10-branch
  origin/binutils-2_11-branch
  origin/binutils-2_12-branch
  origin/binutils-2_13-branch
  origin/binutils-2_14-branch
  origin/binutils-2_15-branch
  origin/binutils-2_16-branch
  origin/binutils-2_17-branch
  origin/binutils-2_18-branch
  origin/binutils-2_19-branch
  origin/binutils-2_20-branch
  origin/binutils-arc-20081103-branch
  origin/binutils-csl-2_17-branch
  origin/binutils-csl-arm-2005q1-branch
  origin/binutils-csl-gxxpro-3_4-branch
  origin/cgen-1_1-branch
  origin/cgf-deleteme
  origin/cgf-dev-branch

Not sure what this is about, but they don't follow the naming convention
for GDB branches, so I think it's OK to delete these as well:

  origin/cr-0x5e6
  origin/cr-0x5ef
  origin/cr-0x5f1
  origin/cr-0x9b
  origin/cr-0x9c
  origin/cr-0x9e

These are really old development branches. I don't think anyone
is gonig to refer to them anymore, so I think it's OK to delete these:

  origin/cagney-unwind-20030108-branch
  origin/cagney_bfdfile-20040213-branch
  origin/cagney_bigcore-20040122-branch
  origin/cagney_convert-20030606-branch
  origin/cagney_fileio-20030521-branch
  origin/cagney_frameaddr-20030403-branch
  origin/cagney_framebase-20030326-branch
  origin/cagney_lazyid-20030317-branch
  origin/cagney_offbyone-20030303-branch
  origin/cagney_regbuf-20020515-branch
  origin/cagney_sysregs-20020825-branch
  origin/cagney_tramp-20040309-branch
  origin/cagney_writestrings-20030508-branch
  origin/cagney_x86i386-20030821-branch
  origin/carlton_dictionary-branch
  origin/kettenis-i386newframe-20030308-branch
  origin/kettenis_i386newframe-20030406-branch
  origin/kettenis_i386newframe-20030419-branch
  origin/kettenis_sparc-20030918-branch
  origin/kseitz_interps-20020528-branch
  origin/offbyone-20030313-branch
  origin/sid-20020905-branch
  origin/tcltk840-20020924-branch

I noticed the same branch/tags are sometimes duplicated, one under
origin and the other under origin/cvs.  Not sure if one of the two
needs to go.

Hope this helps,
-- 
Joel

Re: gdb.git hiccup

[Daniel Jacobowitz]

On Sat, Oct 03, 2009 at 05:38:00PM +0200, Jim Meyering wrote:
> FYI, so far, here's all I've done:
> 
>   head=a4a5c910c73f0bf2b7d063912274461838139423
>   git update-ref HEAD $head
>   git update-ref master $head
> 
> That should be enough for now.

So, this is supposed to be fixed now?

I've been getting this all day:

dan@henry1:/scratch/dan git clone git://sourceware.org/git/archer.git
Initialized empty Git repository in /scratch/dan/archer/.git/
fatal: The remote end hung up unexpectedly

which I assumed was related...

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb.git hiccup

[Jim Meyering]

Daniel Jacobowitz wrote:

> On Sat, Oct 03, 2009 at 05:38:00PM +0200, Jim Meyering wrote:
>> FYI, so far, here's all I've done:
>>
>>   head=a4a5c910c73f0bf2b7d063912274461838139423
>>   git update-ref HEAD $head
>>   git update-ref master $head
>>
>> That should be enough for now.
>
> So, this is supposed to be fixed now?

For gdb, yes, I think we're ok.

> I've been getting this all day:
>
> dan@henry1:/scratch/dan git clone git://sourceware.org/git/archer.git
> Initialized empty Git repository in /scratch/dan/archer/.git/
> fatal: The remote end hung up unexpectedly
>
> which I assumed was related...

I assumed that, too.

But when I tried to diagnose it, I discovered that there are unreadable
temporary pack files owned by from back in February that prevent a local clone.

  sourceware$ cd /git/archer.git/objects; ls -l tmp*
  -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
  -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
  -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m

I have neither root access nor archer group membership, so cannot remove
them, and sent a request to overseers yesterday.  No reply yet.

Re: gdb.git hiccup

[Frank Ch. Eigler]

Hi -

On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
> [...]
> But when I tried to diagnose it, I discovered that there are unreadable
> temporary pack files owned by from back in February that prevent a local clone.
> 
>   sourceware$ cd /git/archer.git/objects; ls -l tmp*
>   -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>   -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>   -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
> [...]

These have been zapped.

- FChE

Re: gdb.git hiccup

[Jim Meyering]

Frank Ch. Eigler wrote:
> On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>> [...]
>> But when I tried to diagnose it, I discovered that there are unreadable
>> temporary pack files owned by from back in February that prevent a local clone.
>>
>>   sourceware$ cd /git/archer.git/objects; ls -l tmp*
>>   -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>>   -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>>   -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
>> [...]
>
> These have been zapped.

Hi Frank,

That helps.
Now a local clone gets farther, but fails like this:

    sourceware$ git clone /git/archer.git
    Initialized empty Git repository in /tmp/.j/archer/.git/
    fatal: git upload-pack: cannot find object e2fb0c192ff44cc1a5512545741ac9ab7826ddab:
    fatal: The remote end hung up unexpectedly

I suppose archer has refs into the gdb.git tree?

I have insufficient access to the archer repo, so even if I were to
diagnose the problem, I could not do anything to fix it.

Re: gdb.git hiccup

[Frank Ch. Eigler]

Hi -

On Sun, Oct 04, 2009 at 02:15:02PM +0200, Jim Meyering wrote:
> [...]
> Now a local clone gets farther, but fails like this:
>     sourceware$ git clone /git/archer.git
>     Initialized empty Git repository in /tmp/.j/archer/.git/
>     fatal: git upload-pack: cannot find object e2fb0c192ff44cc1a5512545741ac9ab7826ddab:
>     fatal: The remote end hung up unexpectedly
>
> I suppose archer has refs into the gdb.git tree?

Yes, and it looks as if those references become broken.  Has someone
regenerated the gdb.git repo?  Someone with a recent complete
archer.git clone should be able to help restore it.

- FChE

Re: gdb.git hiccup

[Matt Rice]

On Sun, Oct 4, 2009 at 4:09 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>> [...]
>> But when I tried to diagnose it, I discovered that there are unreadable
>> temporary pack files owned by from back in February that prevent a local clone.
>>
>>   sourceware$ cd /git/archer.git/objects; ls -l tmp*
>>   -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>>   -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>>   -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
>> [...]
>
> These have been zapped.

unfortunately it still isn't working, I think here is what happened

http://sources.redhat.com/git/gitweb.cgi?p=gdb.git;a=commitdiff;h=d1ea5a6d98

from this email (about the win32-termcap.c -> windows-termcap.c rename)

http://sourceware.org/ml/archer/2009-q1/msg00349.html

If archer.git was cloned using --reference or --shared pointing to the
gdb.git repository the archer.git
repository is probably referencing that commit which is no longer
contained in the gdb.git

also, gdb.git currently is missing the windows-termcap.c file, so
wouldn't build on windows

(so we need to make sure the releases are made from cvs not git atm,
just mention this since Joel mentions he's been using git).

Re: gdb.git hiccup

[Jim Meyering]

Matt Rice wrote:
> On Sun, Oct 4, 2009 at 4:09 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
>> Hi -
>>
>> On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>>> [...]
>>> But when I tried to diagnose it, I discovered that there are unreadable
>>> temporary pack files owned by from back in February that prevent a local clone.
>>>
>>>   sourceware$ cd /git/archer.git/objects; ls -l tmp*
>>>   -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>>>   -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>>>   -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
>>> [...]
>>
>> These have been zapped.
>
> unfortunately it still isn't working, I think here is what happened
>
> http://sources.redhat.com/git/gitweb.cgi?p=gdb.git;a=commitdiff;h=d1ea5a6d98
>
> from this email (about the win32-termcap.c -> windows-termcap.c rename)
>
> http://sourceware.org/ml/archer/2009-q1/msg00349.html
>
> If archer.git was cloned using --reference or --shared pointing to the
> gdb.git repository the archer.git
> repository is probably referencing that commit which is no longer
> contained in the gdb.git
>
> also, gdb.git currently is missing the windows-termcap.c file, so
> wouldn't build on windows

Thanks for pointing that out.
That happened because when I recovered from the binutils->gdb pollution,
I removed the messed up gdb.git repository and re-sync'd it from a
guaranteed-clean mirror already on sourceware.org.  Normally that
works fine.  However, in this case, the mirror was too clean, and
lacked the fix-up I'd pushed to accommodate the cvs-renaming problem
with windows-termcap.c.

I wish I'd pushed it to the staging mirror rather than to the public one.
If I'd done that, there would probably be no problem now.

If someone has a clean, up-to-date repo from Friday,
into which they haven't pulled anything from this weekend,
no local changes and no private branches, please upload
the tar/compressed .git/ directory to some place accessible
(e.g., to dl.free.fr) and send me the resulting link.

Re: gdb.git hiccup

[Jim Meyering]

Jan Kratochvil wrote:
> On Sun, 04 Oct 2009 14:43:28 +0200, Jim Meyering wrote:
>> If someone has a clean, up-to-date repo from Friday,
>> into which they haven't pulled anything from this weekend,
>> no local changes and no private branches, please upload
>> the tar/compressed .git/ directory to some place accessible
>> (e.g., to dl.free.fr) and send me the resulting link.
>
> gdb/master HEAD:
> 	commit a4a5c910c73f0bf2b7d063912274461838139423
> 	Author: gdbadmin <gdbadmin@sourceware.org>
> 	Date:   Sat Oct 3 00:00:33 2009 +0000
>
> archer/master HEAD:
> 	commit e2fb0c192ff44cc1a5512545741ac9ab7826ddab
> 	Author: H.J. Lu <hjl@lucon.org>
> 	Date:   Fri Oct 2 19:03:40 2009 +0000
>
> is in:
> http://people.redhat.com/jkratoch/archer-mirror.tar.xz
> http://people.redhat.com/jkratoch/archer-mirror.tar.bz2

Thanks, Jan.
That looks perfect -- at least for archer.

Can anyone provide the same thing for gdb.git?
Or maybe, demonstrate how to get all of gdb.git out of
archer.git, assuming it includes all of gdb.git's refs.

As soon as I have both, I'll put them back in place.

Re: gdb.git hiccup

[Jan Kratochvil]

On Sun, 04 Oct 2009 22:16:35 +0200, Jim Meyering wrote:
> Can anyone provide the same thing for gdb.git?

I see now some gdb branches were omitted from archer.git, here all the gdb
branches should be present:
	http://www.jankratochvil.net/priv/git/

(I am not a GIT expert so please double-check the content.)


> Or maybe, demonstrate how to get all of gdb.git out of
> archer.git, assuming it includes all of gdb.git's refs.

It does not contain cvs/* and some new ones (such as gdb_7_0-branch).


Thanks,
Jan

Re: gdb.git hiccup

[Jim Meyering]

Jan Kratochvil wrote:
> On Sun, 04 Oct 2009 14:43:28 +0200, Jim Meyering wrote:
>> If someone has a clean, up-to-date repo from Friday,
>> into which they haven't pulled anything from this weekend,
>> no local changes and no private branches, please upload
>> the tar/compressed .git/ directory to some place accessible
>> (e.g., to dl.free.fr) and send me the resulting link.
>
> gdb/master HEAD:
> 	commit a4a5c910c73f0bf2b7d063912274461838139423
> 	Author: gdbadmin <gdbadmin@sourceware.org>
> 	Date:   Sat Oct 3 00:00:33 2009 +0000
>
> archer/master HEAD:
> 	commit e2fb0c192ff44cc1a5512545741ac9ab7826ddab
> 	Author: H.J. Lu <hjl@lucon.org>
> 	Date:   Fri Oct 2 19:03:40 2009 +0000
>
> is in:
> http://people.redhat.com/jkratoch/archer-mirror.tar.xz
> http://people.redhat.com/jkratoch/archer-mirror.tar.bz2

Thanks again, Jan.
I've put that in place on sourceware.org, verbatim --
with two changes:
  - the old description file had to be retained so that gitweb would work
  - I preserved the sole hook script: post-receive

so archer is back in business.

Your (Jan's) gdb.git tarball was a subset of what's on the server now,
so I haven't changed it.  Regarding gdb.git, the automatic
cvs-to-git mirroring was turned off, but I'm about to turn it
back on, now that everything appears to be back to normal.

Re: gdb.git hiccup

[Jan Kratochvil]

On Mon, 05 Oct 2009 12:14:24 +0200, Jim Meyering wrote:
> Thanks again, Jan.
> I've put that in place on sourceware.org, verbatim --
> with two changes:
>   - the old description file had to be retained so that gitweb would work
>   - I preserved the sole hook script: post-receive
> 
> so archer is back in business.
> 
> Your (Jan's) gdb.git tarball was a subset of what's on the server now,
> so I haven't changed it.

I just provided the data and did not prepare it before to be put there
unchanged.  The version with properly copied remote-local tags is at:
	http://www.jankratochvil.net/priv/git/archer.tar.bz2

That one works for me when referenced locally, sorry I expected you will
adjust it appropriately as I did not feel confident with the GIT server side.

The current sourceware.org shows only the "master" branch as the remote one
and produces on `git pull':
	fatal: Couldn't find remote ref archer-tromey-python


Sorry,
Jan

Re: gdb.git hiccup

[Jim Meyering]

Jan Kratochvil wrote:
> On Mon, 05 Oct 2009 12:14:24 +0200, Jim Meyering wrote:
>> Thanks again, Jan.
>> I've put that in place on sourceware.org, verbatim --
>> with two changes:
>>   - the old description file had to be retained so that gitweb would work
>>   - I preserved the sole hook script: post-receive
>>
>> so archer is back in business.
>>
>> Your (Jan's) gdb.git tarball was a subset of what's on the server now,
>> so I haven't changed it.
>
> I just provided the data and did not prepare it before to be put there
> unchanged.  The version with properly copied remote-local tags is at:
> 	http://www.jankratochvil.net/priv/git/archer.tar.bz2

Thanks, and sorry for not checking.
Downloading the new one now.

Too much going on.
I released coreutils-8.0 and parted-2.0 today,
so gdb and archer have not had enough of my attention.

Re: gdb.git hiccup

[Jim Meyering]

Jan Kratochvil wrote:

> On Mon, 05 Oct 2009 12:14:24 +0200, Jim Meyering wrote:
>> Thanks again, Jan.
>> I've put that in place on sourceware.org, verbatim --
>> with two changes:
>>   - the old description file had to be retained so that gitweb would work
>>   - I preserved the sole hook script: post-receive
>>
>> so archer is back in business.
>>
>> Your (Jan's) gdb.git tarball was a subset of what's on the server now,
>> so I haven't changed it.
>
> I just provided the data and did not prepare it before to be put there
> unchanged.  The version with properly copied remote-local tags is at:
> 	http://www.jankratochvil.net/priv/git/archer.tar.bz2
>
> That one works for me when referenced locally, sorry I expected you will
> adjust it appropriately as I did not feel confident with the GIT server side.

It's in place.
Thanks for your help and patience.

Re: gdb.git hiccup

[Christopher Faylor]

On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>But when I tried to diagnose it, I discovered that there are unreadable
>temporary pack files owned by from back in February that prevent a local clone.
>
>  sourceware$ cd /git/archer.git/objects; ls -l tmp*
>  -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>  -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>  -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
>
>I have neither root access nor archer group membership, so cannot remove
>them, and sent a request to overseers yesterday.  No reply yet.

How did rmosely manage to create these files when he does not have
login privileges?  Do we need to close a hole here somewhere?

cgf

Re: gdb.git hiccup

[Jim Meyering]

Christopher Faylor wrote:

> On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>>But when I tried to diagnose it, I discovered that there are unreadable
>>temporary pack files owned by from back in February that prevent a local clone.
>>
>>  sourceware$ cd /git/archer.git/objects; ls -l tmp*
>>  -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>>  -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>>  -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
>>
>>I have neither root access nor archer group membership, so cannot remove
>>them, and sent a request to overseers yesterday.  No reply yet.
>
> How did rmosely manage to create these files when he does not have
> login privileges?

Via git.
tmp_pack_ files are created by git, but obviously not always
removed by the version of git that was running back then.
rmosely *does* have write access to the archer git repository.

> Do we need to close a hole here somewhere?

It'd be good to make sure that can't happen again,
but it's not a security problem (DoS, maybe, though)

Re: gdb.git hiccup

[Christopher Faylor]

On Sun, Oct 04, 2009 at 05:05:02PM +0200, Jim Meyering wrote:
>Christopher Faylor wrote:
>
>> On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>>>But when I tried to diagnose it, I discovered that there are unreadable
>>>temporary pack files owned by from back in February that prevent a local clone.
>>>
>>>  sourceware$ cd /git/archer.git/objects; ls -l tmp*
>>>  -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>>>  -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>>>  -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
>>>
>>>I have neither root access nor archer group membership, so cannot remove
>>>them, and sent a request to overseers yesterday.  No reply yet.
>>
>> How did rmosely manage to create these files when he does not have
>> login privileges?
>
>Via git.
>tmp_pack_ files are created by git, but obviously not always
>removed by the version of git that was running back then.
>rmosely *does* have write access to the archer git repository.
>
>> Do we need to close a hole here somewhere?
>
>It'd be good to make sure that can't happen again,
>but it's not a security problem (DoS, maybe, though)

Ok, so what's the solution?  Should a cron job be cleaning out old tmp*
files or is this no longer an issue with newer versions of git?

cgf

Re: gdb.git hiccup

[Jim Meyering]

Christopher Faylor wrote:

> On Sun, Oct 04, 2009 at 05:05:02PM +0200, Jim Meyering wrote:
>>Christopher Faylor wrote:
>>
>>> On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>>>>But when I tried to diagnose it, I discovered that there are unreadable
>>>>temporary pack files owned by from back in February that prevent a local clone.
>>>>
>>>>  sourceware$ cd /git/archer.git/objects; ls -l tmp*
>>>>  -rw-------  1 rmoseley archer  368640 Feb  9  2009 tmp_pack_hMUtoO
>>>>  -rw-------  1 rmoseley archer  876544 Feb  9  2009 tmp_pack_jmBcho
>>>>  -rw-------  1 rmoseley archer 1007616 Feb  9  2009 tmp_pack_zbwx0m
>>>>
>>>>I have neither root access nor archer group membership, so cannot remove
>>>>them, and sent a request to overseers yesterday.  No reply yet.
>>>
>>> How did rmosely manage to create these files when he does not have
>>> login privileges?
>>
>>Via git.
>>tmp_pack_ files are created by git, but obviously not always
>>removed by the version of git that was running back then.
>>rmosely *does* have write access to the archer git repository.
>>
>>> Do we need to close a hole here somewhere?
>>
>>It'd be good to make sure that can't happen again,
>>but it's not a security problem (DoS, maybe, though)
>
> Ok, so what's the solution?  Should a cron job be cleaning out old tmp*
> files or is this no longer an issue with newer versions of git?

I've poked around a little and see that this has been
reported to happen upon write (e.g., disk full) errors.
The fact that they'd been there for months without
causing trouble suggests that they impede local cloning only,
and not cloning via any server, so I wouldn't worry about it.

Re: gdb.git hiccup

[Joel Brobecker]

Hello Jim,

I just did a quick comparison between the files listed in CVS and
the ones we have in the git mirror, and found the following files
to be missing from gdb.git:

        gdb/windows-termcap.c
        bfd/cpu-rx.c
        bfd/elf32-rx.c
        include/opcode/rx.h
        include/elf/rx.h
        opcodes/rx-decode.opc
        opcodes/rx-dis.c

This is in addition to the cpu subdirectory. Regarding that subdirectory
and how to import it in git, I am personnally completely fine with
importing it as is in one new commit on top of the current conversion.
I can't remember when the last time was when I actually looked inside
that subdirectory, so I don't imagine that having full history for that
tiny part of the GDB sources is going to be critical.

Thanks again for helping us use git.

-- 
Joel

Re: gdb.git hiccup

[Jim Meyering]

Joel Brobecker wrote:
> I just did a quick comparison between the files listed in CVS and
> the ones we have in the git mirror, and found the following files
> to be missing from gdb.git:
>
>         gdb/windows-termcap.c
>         bfd/cpu-rx.c
>         bfd/elf32-rx.c
>         include/opcode/rx.h
>         include/elf/rx.h
>         opcodes/rx-decode.opc
>         opcodes/rx-dis.c
>
> This is in addition to the cpu subdirectory. Regarding that subdirectory
> and how to import it in git, I am personnally completely fine with
> importing it as is in one new commit on top of the current conversion.
> I can't remember when the last time was when I actually looked inside
> that subdirectory, so I don't imagine that having full history for that
> tiny part of the GDB sources is going to be critical.
>
> Thanks again for helping us use git.

Those files are missing, but many more appear to lack changes.
I've just noticed that the version of cvsps (used by git-cvsimport
for incremental updates to the mirrored-to git repos) installed on
the server is only 2.1, while there's a 2.2b1 that has worked
reliably on other sites (savannah.gnu.org and et.redhat.com)
over numerous repositories.

I'll build the newer version and make my cvs-to-git process use it.
It can only help.  Though it can't repair the current holes in gdb.git.
Regarding that, if one of you gdb developers who use gdb.git can send
me git format-patch output that makes a clone from gdb.git identical to
a just-checked-out-from-cvs gdb directory, I will push it to both the
staging and public repositories.

That, in combination with the newer cvsps (and a simple safety net that
I still have to add to ensure the heads of cvs and git repos remain in sync)
should be enough to make this usable and keep it that way.

Re: gdb.git hiccup

[Jim Meyering]

Joel Brobecker wrote:
> Here is a patch that should do the trick.

Thanks, Joel.
I'll take a look in 8-10 hours.

Re: gdb.git hiccup

[Jim Meyering]

Joel Brobecker wrote:
> > I'll build the newer version and make my cvs-to-git process use it.
> > It can only help.  Though it can't repair the current holes in gdb.git.
> > Regarding that, if one of you gdb developers who use gdb.git can send
> > me git format-patch output that makes a clone from gdb.git identical to
> > a just-checked-out-from-cvs gdb directory, I will push it to both the
> > staging and public repositories.
>
> Here is a patch that should do the trick.

FYI, here's what I've done to the public git repo:

    cvs -d /cvs/src co -P gdb  # creates "src/"
    git clone /git/gdb.git gdb-git
    diff -Naur -xCVS -x.git gdb-git src > k
    cd gdb-git
    patch -p1 < ../k
    git add .
    git ci -m 'manually sync from the CVS repository' -a
    git push

Then I did the same to the staging directory into which
cvs-to-git changes are first deposited, and from which
the hourly cron pushes to the public repo.

Now, the checkout/clone-and-comparison shows that the only difference
is the empty contrib/ directory (only-in-cvs in spite of -P):

    cvs -d /cvs/src co -P gdb && git clone /git/gdb.git gdb-git \
      && diff -ru -xCVS -x.git src gdb-git
    Only in src: contrib
    [Exit 1]

With that, and the newly-installed cvsps-2.2b1, let's hope the git
repository stays in sync.  I'm now running this script via cron every hour,
so if something fails to propagate, I'll know right away.

#!/bin/sh
# Ensure that CVS checkout and git clone produce the same tree.

set -e
tmp=$(mktemp -d)

cleanup()
{
  __st=$?;
  rm -rf "$tmp"
  exit $__st
}
trap cleanup 0
trap 'exit $?' 1 2 13 15

cd "$tmp"
cvs -Q -d /cvs/src co -P gdb
git clone -q /git/gdb.git gdb-git
rm -rf src/contrib/CVS
rmdir src/contrib
diff -ru -xCVS -x.git src gdb-git