Re: [XJANITOR] : bug fix in savage driver
[EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Of course, there are such advantages to using bugzilla, but the above listed steps are a lot more overhead for submission of trivial patches than cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED] For a very short patch like this: Certainly. But this is just too bad: we cannot make it right for everyone. People have been pressing us to provide a bugzilla. Of course sometimes another solution may be better. But now since we have it we should it should be used. Besides I have been advocating a somewhat simpler IF for bug submissions. However we need somebody with experience in tweaking the bugzilla frontend to do this. We already have one volunteed to help. Maybe there will be a lot less overhead in the future. Hopefully. I guess I'm just sharing your frustration. As you've been saying there were lots of advocates for bugzilla that indicated a willingness to help, but that hasn't happened (at least so far). Along with that, in that most recent round of bugzilla advocacy, one of the advertised benefits was email access, but it hasn't happened. I've used at least three other bug/trouble ticket tracking systems that had at least some functions available via email and they've been much nicer to work with because of it. To my knowledge this is available in bugzilla also. But a lot of advocates appearantly only knew bugzilla from the user side or from hearsay. They have been working with highly tweaked and beautified interfaces. I wonder why non of these tweaks make it back into the official bugzilla. Anyway, since Marc committed that small patch embedded in my last message, well under an hour after I sent it, it seems this list is a very efficient email interface to the XFree86 patch submission system ;^) It can be efficient but your patches could just as well get lost. There are projects that neither have a bugtracking system nor a publically visible bug tracking system. There patches are always sent to the developers list. People interested in a specific patch just pick it up and apply it to their source tree for testing. The patch then gets discussed on the very same list and eventually some maintainer will pick it up and stick it in the next official version - a happy anarchy but a lively community. We have all the nice gadgets now - like bugzilla, cvs etc. but still the community is far from being lively. There are too many folks out on this list who have great expectations but little willingness to make things happen. However there is hope. We already have one volunteer to help out with the bugzilla. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
Owen Taylor writes: On Wed, 2003-06-04 at 14:59, [EMAIL PROTECTED] wrote: Isn't the number of patches where you don't want: - An explanation of what is wrong - A bug number to be ability to refer to the change later - The ability to add further comments to the bug report if more information is needed Yes, these were the features that conviced me of the bugzilla. We have some patches in the bugzilla.gnome.org to allow it, but: - Patching bugzilla extensively degrades your ability to upgrade to newer versions, so take the advice of experience, try to avoid it. Yes, that's true. On the other hand I've seen quite a few bugzillas that have been heavily tweaked. There seems to be a great demand to get away from the spartanic looking default face and also there seems to be demand for functionalities that the default face doesn't offer. - Bugzilla really doesn't want to send mail to people without accounts; so, if you get a bug submitted by a non-account-holder it's sort of second class Something more sophisticated (email creation of accounts, etc) is certainly theortically possible, but I don't know of an implementation. Account creation by bugzilla may not be all that importand. However creating and commenting on a bug may be more interesting. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fast way to check local X is running
How about ps -ax | X to find out if X is running, if it is xdpyinfo | grep number of screens: 2 or similar (not sure on syntax). This should be quite quick because it wont wait for any timeouts. jeb Andriy Rysin wrote: -display :0.1 and -display unix:0.1 both give 6 sec. Andriy Alan Coopersmith wrote: Try -display :0.1 or -display unix:0.1 -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - Sun Software Group Quality / User Experience (QUE) - Globalization Platform Globalization Engineering: X11 Development Andriy Rysin wrote: Just found that if I use 'localhost:0.1' form, XOpenDisplay tries to connect with TCP stream, while if DISPLAY is NULL it choses fastest method it can find. And actually running just 'xlsfonts' with X down gives error right away. The problem is that I have to check for screen 0.1. Is there any way to use XOpenDisplay specifying screen 0.1 without forcing it to TCP mode? Thanks, Andriy Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
David Dawes writes: On Tue, Jun 03, 2003 at 10:56:49AM +0200, Egbert Eich wrote: David Dawes writes: The submission process is to go to bugs.xfree86.org. If people want their submissions to be seen, that's where they should go. That's the clearest explanation of the submission system that I can come up with. Submissions sent elsewhere may or may not be seen. Do we use fixes@ and patches@ to accept submissions which the author chooses not to be seen? No, and I don't understand why you're coming up with possible uses for a mechanism that you've previously said should be eliminated. I was just referring to your answer. Perhaps the only way to eliminate the apparent confusion that people seem so adept at finding is to remove those addresses completely so that mail sent to them bounces. Sorry, I misread your first message on this issue. You were saying that the old submission process was deprecated ie. submissions were no longer accepted thru this channel. I somehow misread this. I have to apologize. It's really very simple. There is one place for all general (i.e. non-security) submissions. These submissions shouldn't be made until they can be seen. They'll be seen once committed anyway. Yes. Why should anybody want his submissions not to be seen? The only case I can think of that should remain confidential until officially announced are security fixes. These however should be dealt with differently anyway. We have a [EMAIL PROTECTED] address for security-related issues, and an associated PGP key so that they can be encrypted if desired. This address of course has a very limited and closed distribution. See http://www.xfree86.org/security/. Right. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SDK and drivers.
On Wed, Jun 04, 2003 at 06:02:15PM +0200, Egbert Eich wrote: Sven Luther writes: No problem, i have been busy with other things too, and my motherboard died on saturday, so i could not do much work this WE. I'm sorry to hear that. No problem, it was under guarantee :))) Also, would your new SDK still use a fixed path or should it be possible to install it anywhere ? Fixed path? I have not looked at the old SDK, but my plan is to have it like the build tree so you should be able to put it anywhere. Well, once you build and install the SDK, the PROJECTROOT gets expanded in the Imakefiles/Makefiles, and it has problem during the build phase if you moved it, since it tries to erase files in the old location, for which it may not have the rights. I was able to override this behavior by calling make wile overriding one of the make variables, i forgot which one right now, but i think it was something like USRINCDIR or something such. Ideally it would be easy to build in any place, possibly not as root, and then to be able to install as root, and with the install path accepting the $(DESTDIR) prefix, so the drivers can be installed into a package. My plan is to create a self-contained build environment which does not use any absolute paths but builds the stuff in directories relative to its root directory - much like the full build does. This sounds fine. But i guess it will be ready for the 4.4 timeframe, right ? I will continue hacking on the current SDK for 4.3 in the meantime. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
Emmanuel writes:
So in short : where the trivial fixes (more or less like the janitor
ones) should be submitted (for now they are submitted via bugzilla)?
Thanks
Yes.
1. Please create yourself a bugzilla account and log in.
2. You can then use the 'create' function to create a new
submission.
3. Please try to identify as closely as possible the component
the submission is for, add a brief description and use the
'attachment' button to create an attachment containing your
diff.
4. Please don't forget to set the mimetype of the attachment
to 'patch'.
This is importand as it helps to locate those entries that
contain patches.
You can then always search for the entry and find out if
the fix has been submitted already or if somebody has a
comment on your submission.
Of course, there are such advantages to using bugzilla, but the above listed
steps are a lot more overhead for submission of trivial patches than
cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED]
For a very short patch like this:
diff -u -r1.13 xf86MiscExt.c
--- xf86MiscExt.c 3 Apr 2003 16:15:56 - 1.13
+++ xf86MiscExt.c 4 Jun 2003 18:44:04 -
@@ -618,7 +618,7 @@
{
ScrnInfoPtr pScr = xf86Screens[scrnIndex];
-DEBUG_P(MiscExtGetFilePaths);
+DEBUG_P(MiscExtPassMessage);
if (*pScr-HandleMessage == NULL)
return BadImplementation;
a simpler submission method seems more appropriate.
Anyone know anything more about the mythical email interface to bugzilla?
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
fast way to check local X is running
I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re : Re : [XJANITOR] : bug fix in savage driver
Emmanuel writes: Thanks for the clarity. I have done it as you said already, I will insist on the mime type for attachments on the janitor page. OK, thanks. Just one more thing : the patches I have submitted are trivial (minor mem leaks, clean-ups, and only one more severe bug) but I had no feedback (#274, 278, 279). Yes, I've seen that. This week I'm still not near my development systems therefore I cannot look at it. I'll take a look at it next week. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fast way to check local X is running
ps -ax|grep XFree86 On Wed, Jun 04, 2003 at 01:20:08PM -0700, Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel pgp0.pgp Description: PGP signature
Re: fast way to check local X is running
Just found that if I use 'localhost:0.1' form, XOpenDisplay tries to connect with TCP stream, while if DISPLAY is NULL it choses fastest method it can find. And actually running just 'xlsfonts' with X down gives error right away. The problem is that I have to check for screen 0.1. Is there any way to use XOpenDisplay specifying screen 0.1 without forcing it to TCP mode? Thanks, Andriy Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fast way to check local X is running
A bit ugly but the case is even not that :) - I have to check for screen 0.1 (tv output in my case) and ps -ax will not give me that information. Andriy [EMAIL PROTECTED] wrote: ps -ax|grep XFree86 On Wed, Jun 04, 2003 at 01:20:08PM -0700, Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/deve l ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fast way to check local X is running
Specify :0.1 (note: no hostname) as the DISPLAY. That will use UNIX domain sockets, which I am assuming that X using when you pass NULL. Harold Andriy Rysin wrote: Just found that if I use 'localhost:0.1' form, XOpenDisplay tries to connect with TCP stream, while if DISPLAY is NULL it choses fastest method it can find. And actually running just 'xlsfonts' with X down gives error right away. The problem is that I have to check for screen 0.1. Is there any way to use XOpenDisplay specifying screen 0.1 without forcing it to TCP mode? Thanks, Andriy Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fast way to check local X is running
I tried that, the delay is the same as with 'localhost:0.1' ~6 sec. Man page says If the hostname is a host machine name and a single colon (:) separates the hostname and display number, XOpenDisplay connects using TCP streams. If the hostname is not specified, Xlib uses whatever it believes is the fastest transport. If the hostname is a host machine name and a double colon (::) sepa- rates the hostname and display number, XOpenDisplay connects using DEC- net. So it's supposed to be 'fastest transport' when no hostname is specified but from the other side it says that colon ':' specifes TCP (and '::' specifies DECnet). So there's some ambiguity here. Andriy Harold L Hunt II wrote: Specify :0.1 (note: no hostname) as the DISPLAY. That will use UNIX domain sockets, which I am assuming that X using when you pass NULL. Harold Andriy Rysin wrote: Just found that if I use 'localhost:0.1' form, XOpenDisplay tries to connect with TCP stream, while if DISPLAY is NULL it choses fastest method it can find. And actually running just 'xlsfonts' with X down gives error right away. The problem is that I have to check for screen 0.1. Is there any way to use XOpenDisplay specifying screen 0.1 without forcing it to TCP mode? Thanks, Andriy Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
[EMAIL PROTECTED] writes: Of course, there are such advantages to using bugzilla, but the above listed steps are a lot more overhead for submission of trivial patches than cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED] For a very short patch like this: Certainly. But this is just too bad: we cannot make it right for everyone. People have been pressing us to provide a bugzilla. Of course sometimes another solution may be better. But now since we have it we should it should be used. Besides I have been advocating a somewhat simpler IF for bug submissions. However we need somebody with experience in tweaking the bugzilla frontend to do this. We already have one volunteed to help. Maybe there will be a lot less overhead in the future. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fast way to check local X is running
-display :0.1 and -display unix:0.1 both give 6 sec. Andriy Alan Coopersmith wrote: Try -display :0.1 or -display unix:0.1 -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - Sun Software Group Quality / User Experience (QUE) - Globalization Platform Globalization Engineering: X11 Development Andriy Rysin wrote: Just found that if I use 'localhost:0.1' form, XOpenDisplay tries to connect with TCP stream, while if DISPLAY is NULL it choses fastest method it can find. And actually running just 'xlsfonts' with X down gives error right away. The problem is that I have to check for screen 0.1. Is there any way to use XOpenDisplay specifying screen 0.1 without forcing it to TCP mode? Thanks, Andriy Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
[EMAIL PROTECTED] writes: Of course, there are such advantages to using bugzilla, but the above listed steps are a lot more overhead for submission of trivial patches than cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED] For a very short patch like this: Certainly. But this is just too bad: we cannot make it right for everyone. People have been pressing us to provide a bugzilla. Of course sometimes another solution may be better. But now since we have it we should it should be used. Besides I have been advocating a somewhat simpler IF for bug submissions. However we need somebody with experience in tweaking the bugzilla frontend to do this. We already have one volunteed to help. Maybe there will be a lot less overhead in the future. Hopefully. I guess I'm just sharing your frustration. As you've been saying there were lots of advocates for bugzilla that indicated a willingness to help, but that hasn't happened (at least so far). Along with that, in that most recent round of bugzilla advocacy, one of the advertised benefits was email access, but it hasn't happened. I've used at least three other bug/trouble ticket tracking systems that had at least some functions available via email and they've been much nicer to work with because of it. Anyway, since Marc committed that small patch embedded in my last message, well under an hour after I sent it, it seems this list is a very efficient email interface to the XFree86 patch submission system ;^) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote: Anyway, since Marc committed that small patch embedded in my last message, well under an hour after I sent it, it seems this list is a very efficient email interface to the XFree86 patch submission system ;^) Tee hee. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
On Wed, 2003-06-04 at 14:59, [EMAIL PROTECTED] wrote:
Of course, there are such advantages to using bugzilla, but the above listed
steps are a lot more overhead for submission of trivial patches than
cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED]
For a very short patch like this:
Isn't the number of patches where you don't want:
- An explanation of what is wrong
- A bug number to be ability to refer to the change later
- The ability to add further comments to the bug report
if more information is needed
Really tiny? At least for GTK+, a good fraction
of the trivial patches that don't need further explanation
people send in tend to be of the form:
- /* use widget */
+ if (widget)
+ /* use widget */
[...]
diff -u -r1.13 xf86MiscExt.c
--- xf86MiscExt.c 3 Apr 2003 16:15:56 - 1.13
+++ xf86MiscExt.c 4 Jun 2003 18:44:04 -
@@ -618,7 +618,7 @@
{
ScrnInfoPtr pScr = xf86Screens[scrnIndex];
-DEBUG_P(MiscExtGetFilePaths);
+DEBUG_P(MiscExtPassMessage);
if (*pScr-HandleMessage == NULL)
return BadImplementation;
a simpler submission method seems more appropriate.
Anyone know anything more about the mythical email interface to bugzilla?
We have some patches in the bugzilla.gnome.org to allow it, but:
- Patching bugzilla extensively degrades your ability
to upgrade to newer versions, so take the advice of experience,
try to avoid it.
- Bugzilla really doesn't want to send mail to people without
accounts; so, if you get a bug submitted by a non-account-holder
it's sort of second class
Something more sophisticated (email creation of accounts, etc)
is certainly theortically possible, but I don't know of an
implementation.
Regards,
Owen
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
