From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Tom Tromey Cc: Michael Meissner , Jason Molenda , gdb-patches@sourceware.cygnus.com Subject: Re: patch management? Date: Fri, 19 Nov 1999 10:35:00 -0000 Message-id: References: <199911152157.QAA26389@zwingli.cygnus.com> <19991116101108.B23372@tiktok.cygnus.com> <19991116113818.B1587@cygnus.com> <199911162051.MAA17286@ferrule.cygnus.com> <19991117212650.B11794@tiktok.cygnus.com> <199911181817.KAA18832@ferrule.cygnus.com> X-SW-Source: 1999-q4/msg00297.html > Jim> Here's a set of states which I think could do the job. Do you > Jim> think these would work? > > Jim> State: unclaimed > Jim> State: assigned > > For the Java Gnats database we have a "java-hacker" "person" which is > really the unassigned state. Does it make sense to go this way > instead? I don't know. I thought about that, too, but the "unclaimed" state is exclusive of all the others, so to put that information in a different field seems too loose. What does it mean for a patch to be "State: accepted", but "Responsible: java-hacker"? Databases always get dirty. You would have to screen for all these cases in your queries. Part of the confusion, I think, is because "assigned" is kind of a non-name. It mostly indicates what *hasn't* happened to the patch: no decision has been made, and no questions have been reached. The patch is still assigned to someone when it's in "feedback". So the name doesn't really mean what it suggests. "Assigned" really means, "Well, at least it's not unclaimed!" Maybe "pondering" would be a better name for the state. I like that better. It hints that a decision is expected, and it lets you tell people, "Go away --- I'm pondering patches." :) >From jimb@cygnus.com Fri Nov 19 10:37:00 1999 From: Jim Blandy To: Jason Molenda Cc: gdb-patches@sourceware.cygnus.com Subject: Re: getting patches organized Date: Fri, 19 Nov 1999 10:37:00 -0000 Message-id: References: <199911172343.SAA28254@zwingli.cygnus.com> <19991117161503.A15122@cygnus.com> <19991118150355.E5316@cygnus.com> X-SW-Source: 1999-q4/msg00298.html Content-length: 690 > Why not just use the emacs interface, then? The gnatsweb WWW interface > is great largely because it requires no installation on users' systems. > For people who are going to use gnats often, I recommend installing > one of the local clients. The tcl/tk one, tkgnats, looks quite nice; > the emacs one is favored by many. I personally have used the command > line ones for years. I find the Emacs PRMS interface Cygnus installs to be totally annoying. That query thing was the only thing I ever used within Emacs. I was hoping to use the web interface. Maybe the Emacs interface is improved now. Given my past, I suppose it is my personal duty to improve it if I don't like it... >From hjl@lucon.org Fri Nov 19 10:52:00 1999 From: hjl@lucon.org (H.J. Lu) To: tromey@cygnus.com (Tom Tromey) Cc: guo@cup.hp.com (Jimmy Guo), tromey@cygnus.com (Tom Tromey), gdb-patches@sourceware.cygnus.com Subject: Re: Patch: gdb -vs- Debian 2.0 Date: Fri, 19 Nov 1999 10:52:00 -0000 Message-id: <19991119185237.A1A271B493@ocean.lucon.org> References: <199911191800.KAA19976@ferrule.cygnus.com> X-SW-Source: 1999-q4/msg00299.html Content-length: 722 > > Jimmy> One more bit of information -- gdb used to compile on Linux > Jimmy> Redhat 5.1 (the PC cannot be upgraded to more recent versions > Jimmy> due to onboard SCSI controller <-> Linux driver problem), but > Jimmy> some time ago quite recently I have to compile gdb on Linux > Jimmy> Redhat 6.0, probably due to the same change Tom's patch is > Jimmy> trying to fix. > > Was the problem that PTRACE_GETREGS was not defined? If so, then that > is a slightly different problem, with a slightly different fix. > PTRACE_GETREGS is defined on my machine, it just doesn't work. > FWIW, the single binary of my gdb 4.17.0.14 works with all Linux kernels. It detects everything at runtime. -- H.J. Lu (hjl@gnu.org) >From guo@cup.hp.com Fri Nov 19 10:55:00 1999 From: Jimmy Guo To: Tom Tromey Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patch: gdb -vs- Debian 2.0 Date: Fri, 19 Nov 1999 10:55:00 -0000 Message-id: References: <199911191800.KAA19976@ferrule.cygnus.com> X-SW-Source: 1999-q4/msg00300.html Content-length: 736 On Fri, 19 Nov 1999, Tom Tromey wrote: >Jimmy> One more bit of information -- gdb used to compile on Linux >Jimmy> Redhat 5.1 (the PC cannot be upgraded to more recent versions >Jimmy> due to onboard SCSI controller <-> Linux driver problem), but >Jimmy> some time ago quite recently I have to compile gdb on Linux >Jimmy> Redhat 6.0, probably due to the same change Tom's patch is >Jimmy> trying to fix. > >Was the problem that PTRACE_GETREGS was not defined? If so, then that >is a slightly different problem, with a slightly different fix. >PTRACE_GETREGS is defined on my machine, it just doesn't work. Just tried a build on the Redhat 5.1 system ... yes, PTRACE_(GET|SET)[FP]REGS were not defined. - Jimmy Guo, guo@cup.hp.com