Re: cvsup & sourceware repositories?

[Andrew Cagney <ac131313@cygnus.com>]

Jimmy Guo wrote:
> 
> <<sorry I sent the original question under a different subject line,
>   here it is again!>>
> 
> A general question about the repositories on sourceware:
> Can we use cvsup client tool to maintain a local repository?  Instead of
> getting 'snapshots' via the CVS interfaces, I'd like to use the cvsup
> tool to get updates to the repositories.  It requires sourceware to run
> a cvsupd daemon.
> 
> Otherwise, what is the easiest way to maintain local repository?  I want
> to create a local repository containing gdb, dejagnu, and binutils
> products, and be able to automatically 'synchronize' with sourceware's
> every night or on demand (turn-key solution here).

At present only rsync is available for this :-(  See:
http://sourceware.cygnus.com/ml/overseers/2000/msg00102.html .
My things to do today list includes leaning on someone (....) so that
CVSupd runs on sourceware so that I can do the same thing from up here.

	Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002161409.e1GE9nh00758@delius.kettenis.local>
References: <38AA42EA.5106E153@cygnus.com>
X-SW-Source: 2000-q1/msg00310.html
Content-length: 1457

   Date: Wed, 16 Feb 2000 17:25:46 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   Target Specific:


   GNU/Linux/i386:
   After gdb_proc_service.h patch, its results are:
   # of expected passes            6363
   # of unexpected failures        12
   # of expected failures          200
   but it didn't run the threads tests.  I believe the solib.c problem is
   still dangling.  Actually, a testcase for what ever it is is needed
   first.

Looks like I misinterpreted the test logs.  The results above do
include running the thread tests.  The relevant test script tries to
link with -lpthreads first, which fails on most systems, but then
tries -lpthread, which succeeds.

I am working on the solib.c problem.  HJ reported that there is indeed
only a problem with dlclose(): GDB doesn't remove the shared library
from its list of loaded objects.  As a consequence a subsequent
dlopen() isn't noticed by GDB.  Basically my approach is based on a
patch from FreeBSD, but I'm changing things to minimize the amount of
data read from the target.  I'll need a few more days, and this patch
really needs to be tested on some more platforms (at least SunOS 4)
before it can be integrated.

I have a test case.  I'll try to integrate it in the test-suite.

   Solaris: No feed back, I'll put it on my list of things to do.

I have successfully built GDB on Solaris 2.6, see:

   http://sourceware.cygnus.com/ml/gdb-testers/2000-q1/msg00030.html

Mark
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002280657.BAA27090@indy.delorie.com>
X-SW-Source: 2000-q1/msg00431.html
Content-length: 330

defs_h in gdb/Makefile includes config.status.  This makes all of the
GDB sources depend on it.  The result is that each time I reconfigure
the package, everything gets recompiled, which is quite annoying when
working on some minor configury buglets.

Why does GDB need to be dependent on config.status, in addition to
config.h? 
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: patch database proposal
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002251827.NAA09955@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00422.html
Content-length: 8847

Here's a tentative proposal for how the patch database should work.
In reality, a good part of this is set up and ready to go, but there's
nothing we can't revise, in the presence of good ideas or persuasive
criticism.

Please let me know what you think; post your comments to the list.

----

If you've written a patch for GDB, either to fix a bug or to improve
the program, you should make sure it gets into the GDB patch database.
The GDB patch database is a GNATS database created to help GDB's
maintainers keep track of patches that need reviewing, and helps you
stay on top of what's happening to your patch.

Anyone can submit a patch.  There are two ways to do so:

- Visit the GDB Patch Submission page [Jason will supply URL], and
  submit your patch there.

- Submit your patches via E-mail, by sending a message to
  `gdb-patches-gnats@sourceware.cygnus.com'.  We have a template for
  mail messages [link here].  Following this template helps make sure
  we have the information we need to choose a reviewer for your patch,
  and to do the review itself.

We'd prefer that you use the web form, if possible, because that
provides more helpful prompts, and checks your input more thoroughly.

The database assigns each new patch a number, like `gdb-patch/209'.
Whenever you send mail regarding your patch, be sure to include the
address `gdb-patches-gnats@sourceware.cygnus.com' in the CC list, and
make sure the message subject starts with `gdb-patch/209: ', or
whatever your patch number is.  This way, GNATS will automatically log
the discussion along with the patch in the database.

Once you've submitted your patch, you can visit [another URL] to check
on its status, or to search the patch database in various ways.  Each
patch in the database has a set of headers, much like a mail message;
the two most interesting headers to look at are:

- `Responsible' --- this is the name of the person currently
  responsible for moving the patch forward.

- `State' --- the current status of the patch.

Here are the different states a patch might be in:

- `unclaimed'

  If the database software can't figure out automatically which
  maintainer should evaluate your patch, then it declares the patch
  `unclaimed', and sets the `Responsible' person to the GDB patch
  secretary.  It is then the secretary's job to find someone who can 
  review the patch, and change the patch's `State' and `Responsible'
  headers appropriately.

  Also, if the maintainer responsible for a patch decides that they
  can't process it --- for example, they might know they won't be able
  to evaluate it promptly --- then they can put it back in the
  `unclaimed' state.  As before, the patch secretary should find
  someone else to tend to it.  The patch database logs all changes
  to a patch's state or responsible party, along with all mail
  communication about the patch, which can help the new person pick
  the patch where it left off.

- `claimed'

  The person named in the patch's `Responsible' header has volunteered
  or been designated to review the patch, but they haven't made any
  decision about it yet, or they haven't gotten around to looking at
  it yet.

  The maintainer indicates his or her decision by putting the patch in
  one of the states below.

  If the patch requires additional maintainers' approval, then the
  maintainer should leave the patch in the `claimed' state, and simply
  change the `Responsible' field to the next maintainer in line.
  Since all changes in responsibility are logged with the patch, each
  maintainer can tell when the review process is complete.  The last
  maintainer to evaluate the patch should actually change the state to
  something more conclusive.

  As the name suggests, patch claims are voluntary.  Maintainers
  should feel free to claim interesting unclaimed patches for
  themselves, and to trade or reallocate patches amongst themselves as
  appropriate, simply by changing patches' `State' and `Responsible'
  headers.  Assignments made automatically by the database software,
  or manually by the patch secretary, are simply an optimization,
  meant to help the process run more smoothly.

  Of course, if a maintainer consistently fails to review patches in a
  timely fashion, the team will eventually suggest that they step
  down, or share the responsibility with someone more responsive.

- `feedback'

  This state indicates that the maintainer feels the patch needs
  revision, or that the author's intent is unclear and the patch
  should be further explained.  It is now the responsibility of the
  original author of the patch to satisfy the maintainer's concerns,
  to allow the patch to move forward.

  The maintainer's concerns should always be recorded with the patch
  somehow, either in a mail message logged with the patch, or in the
  state change message.

  Note that the maintainer is still responsible for patches in this
  state.  If the author is slow to respond, the maintainer must pursue
  the matter, or put the patch in the `rejected' state (described
  below) if the author doesn't reply.

- `prereqs'

  The maintainer approves of the patch, but can't apply it until some
  other change is made --- some other patch must be applied first, for
  example.  The maintainer should explain what they are waiting for in
  the patch record.  It is the maintainer's responsibility to notice
  when the prerequisites have been met, and move the patch along.

- `accepted'

  The maintainer has decided to apply the patch, and has accepted
  responsibility for whatever further work is necessary to get it into
  the sources.

- `applied'

  The maintainer has applied the patch, and expects no further work on
  that patch to be necessary.

- `rejected'

  This state represents several possible outcomes:

  - The maintainer has decided that the patch should not be applied, and
    is not expecting to do revisions or further work on that patch.

  - The patch's author has withdrawn it, and the maintainer agrees.

  - The patch is actually several smaller changes lumped together;
    the author must resubmit it as several separate patches.

  - The patch is so old that it is no longer useful in revising the
    current sources, and neither the author nor the maintainer has any
    intention of bringing it up to date.

  In any case, the maintainer should explain why the patch was
  rejected, in the patch notes.
  
  Of course, it is always possible for a maintainer to resurrect a
  rejected patch, simply by putting it back in one of the other
  states.

- `papers'

  The maintainer would like to apply the patch, but the patch is large
  enough that it is automatically copyrighted by the author, and
  cannot be applied to the GDB sources.  In this case, the author
  needs to assign his or her copyright interest in the patch to the
  Free Software Foundation; see [link], or the file `gdb/CONTRIBUTE'
  in the GDB source tree, for details about this.

[We'll work in full documentation for the other headers somewhere, but
this page is mostly about the process, which is the least obvious
part.]


If you're interested in monitoring patch activity, you may wish to
subscribe to `gdb-patches-prs@sourceware.cygnus.com'.  This mailing
list receives:

  - messages announcing newly submitted patches

  - all discussion about existing patches

  - messages indicating that a patch has changed state, and why

To subscribe, [appropriate instructions or link]


If you are having problems using the patch database, send mail to
`gdb-patches-secretary@sourceware.cygnus.com'.  The patch secretary
is responsible for:

  - the quality of the database (removing spam, getting people to use
    the headers in a helpful way, making sure all patches are placed
    in the database [in my experience, every database gets dirty, and
    there needs to be someone working to counteract entropy]);

  - passing `unclaimed' patches to willing and appropriate maintainers;

  - all GDB-specific documentation and web pages supporting the patch
    database; and

  - any other administration specific to the GDB patch database

The patch secretary is not responsible for:

  - technical issues (like evaluating patches);

  - administration of shared sourceware infrastructure, not specific to the
    GDB database (fixing wedged servers, upgrading software, etc.); or

  - prodding unresponsive maintainers.  (General community pressure is
    best for this; beyond that, the prodding needs to be done by
    someone with real authority over their time, like their manager,
    or authority over their maintainership, like the committee that
    made them a maintainer in the first place.)

In the GDB source tree, the file gdb/MAINTAINERS lists the current
patch secretary, along with all the maintainers and the areas they're
responsible for.
From P.Leggett@gre.ac.uk Sat Apr 01 00:00:00 2000
From: Peter Leggett <P.Leggett@gre.ac.uk>
To: gdb@sourceware.cygnus.com
Subject: gdb functionality query
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000228114844.A3717@gre.ac.uk>
X-SW-Source: 2000-q1/msg00432.html
Content-length: 1342

Hello,

I hope that this list is the appropriate one to ask a general
gdb question. If not please excuse this mail.
                                             
The research group I work in uses the Sun debugger/dbx which has some
these extremly useful features without which we would find debugging
our codes much harder. We are now also running on linux boxes
and are exploring the possibilites of gdb.

I would very much appreciate it if anyone could tell me if gdb has
the following specific functionality:-
  
a) Ability to pop program call frame stack and then continue. I know one
   can browse up and down the frames in gdb but can one pop it and      
   continue from a calling frame up the stack.                    
  
b) make an arbitary call to user code (with possibly arguments and
   expressions) from gdb  and break point within that call etc..  
   e.g.
       
   gdb-> break usersub
   gdb-> call usersub(a,fred+2,jim*2+1)
   ...                                 

   where a, fred and kim are user variables.
   
Thank you

Pete

--
  
Dr Peter F. Leggett                  Tel: +44 (0)20-8331-8731
Parallel Processing Research Group   Fax: +44 (0)20-8331-8665
University of Greenwich            Email: P.Leggett@gre.ac.uk
Maritime Greenwich Campus       Internet: http://www.gre.ac.uk/~lp01
30 Park Row
London SE10 9LS