bugzilla down
On Sat, 12 Jun 2004, Ryan Underwood wrote: I have two bugs open on the mga driver that I'd like some feedback on: http://bugs.xfree86.org/show_bug.cgi?id=1098 bugs.xfree86.org seems to be down right now, but I've dug out my G400DH and will try this outr when it comes back online. -- Well I hope that it is not serious as we don't have backups of it as Stuart said he would handle all administrative concerns. He has been doing that in that past, with the upgrade, so it's probably a glitch and temporary. Thanks though for the notice. I'm cc'ing Stuart as he may not know. Georgina ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
FW: bugzilla down
--- On Sat 06/12, georgina o. economou [EMAIL PROTECTED] wrote: From: georgina o. economou [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] == it would help if I could spell... Date: Sat, 12 Jun 2004 11:51:03 -0400 Subject: bugzilla down On Sat, 12 Jun 2004, Ryan Underwood wrote: I have two bugs open on the mga driver that I'd like some feedback on: http://bugs.xfree86.org/show_bug.cgi?id=1098 bugs.xfree86.org seems to be down right now, but I've dug out my G400DH and will try this outr when it comes back online. Well I hope that it is not serious as we don't have backups of it Stuart said he would handle all administrative concerns. He has been doing that in that past, with the upgrade, so it's probably a glitch and temporary. Thanks though for the notice. I'm cc'ing Stuart as he may not know. ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: FW: bugzilla down
On Sat, 12 Jun 2004, georgina o. economou wrote: Thanks though for the notice. I'm cc'ing Stuart as he may not know. Sorry about that. Apache fell over this morning, but it's back now. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: FW: bugzilla down
Super! Thanks again Stu. G- --- On Sat 06/12, Stuart Anderson [EMAIL PROTECTED] wrote: From: Stuart Anderson [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sat, 12 Jun 2004 12:37:45 -0400 (EDT) Subject: Re: FW: bugzilla down Apache fell over this morning, but it's back now. ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 Bugzilla ...
On Wed, Apr 14, 2004 at 05:33:48PM -0400, Tristan Van Berkom wrote: Hi team, I'm not so sure about the proper patching etiquette so I'll ask here, I seem to have rights to do whatever I want with a bug, so I filed the bug, I fixed the bug (not in bugzilla), attatched a proposed patch, assigned the bug to myself; but I dont think I should be able to mark it fixed if its not in cvs HEAD, correct ? As far as I know there are no restrictions on who can do what, except for configuration-type things that only the bugzilla admin can do. Here is the bug info: http://bugs.xfree86.org/show_bug.cgi?id=1332 One more thing, Is it desireable that this version of driver be compileable for X 3.3.x series ? XFree86 3.3.x is no longer maintained. The general preference is to not include compatiblity code in drivers. I don't know if the author of the input drivers with 3.3.x compatility code still has a need to keep it around. If so, my patch is broken as it makes use of the posix_tty functions provided only in 4.x versions (could easily fix that... #ifdef... ). That's fine as far as I'm concerned. I'm committing your patch now. Thanks for your contribution. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 Bugzilla ...
Hi team, I'm not so sure about the proper patching etiquette so I'll ask here, I seem to have rights to do whatever I want with a bug, so I filed the bug, I fixed the bug (not in bugzilla), attatched a proposed patch, assigned the bug to myself; but I dont think I should be able to mark it fixed if its not in cvs HEAD, correct ? Here is the bug info: http://bugs.xfree86.org/show_bug.cgi?id=1332 One more thing, Is it desireable that this version of driver be compileable for X 3.3.x series ? If so, my patch is broken as it makes use of the posix_tty functions provided only in 4.x versions (could easily fix that... #ifdef... ). Maybe there is a document on this stuff someone could point me towards ? Cheers, -Tristan ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ICEauthority files and bugzilla #902
Hi, in order to fix the core dump described in bugzilla #902 http://bugs.xfree86.org/show_bug.cgi?id=902, I need help to understand the ICE auth specification. My understanding is that at least 3 fields (protocol name, netid and auth_name) cannot be of 0 length in an entry stored in a valid .ICEauthority. Can anyone confirm this ? If I'm wrong what are the correct rules ? Thanks in advance. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla process for submitting fixes
On Thu, 2003-11-20 at 14:01, Alan Coopersmith wrote: Is there some way to mark a newly filed bug so it's clear that there's a patch attached and it just needs to be reviewed and checked in? According to the bugzilla docs, FIXED means the code is checked in and there doesn't seem to be any Fix Provided state other than NEW. It's not clear to me there's any way other than manual review of NEW bugs to determine which ones need time spent debugging and fixing, and which ones just need to be reviewed and committed, but it would seem if we could mark bugs like that when submitting the patches, the people who do the reviews and commits could more easily get through them without wading through those they don't have the time to try to fix themselves at the moment. (Maybe changing it to be assigned to [EMAIL PROTECTED] instead of developers or something like that would work.) One could use the Keywords field (which XFree86 Bugzilla doesn't seem to have), e.g., Keywords: INCLUSION. This could require an upgrade of Bugzilla, I'm no expert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla
On Fri, 21 Nov 2003, Georgina Economou wrote: I noticed today this notice. Does this matter to us as we are 2.17.4 or not? And if so, who takes care of this? I still take careof the bugzilla. I'll look into this, and probably schedule an update if there is need for security reason,s or there are interesting new features in the newer versions. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla
On Sat, 22 Nov 2003 16:29:40 -0500 (EST), Stuart Anderson [EMAIL PROTECTED] wrote: On Fri, 21 Nov 2003, Georgina Economou wrote: I noticed today this notice. Does this matter to us as we are 2.17.4 or not? And if so, who takes care of this? I still take careof the bugzilla. I'll look into this, and probably schedule an update if there is need for security reason,s or there are interesting new features in the newer versions. Okay Stu. I was just wondering. Thanks for the update. Georgina ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bugzilla
http://www.bugzilla.org/ [ 2003 Nov 09 ] Bugzilla 2.17.6 Released We had a small oops with the 2.17.5 release, whereas one of the new features that was introduced also introduced a new security hole. For the full details, read the security advisory. Note that this affects version 2.17.5 only and the current stable version 2.16.4 is not affected. Since this is the development branch, there have been other checkins besides the security fix. For a complete list, click the 2.17.5 2.17.6 link on the changelog page. Version 2.17.6 is available on the download page. I noticed today this notice. Does this matter to us as we are 2.17.4 or not? And if so, who takes care of this? Georgina ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bugzilla process for submitting fixes
Is there some way to mark a newly filed bug so it's clear that there's a patch attached and it just needs to be reviewed and checked in? According to the bugzilla docs, FIXED means the code is checked in and there doesn't seem to be any Fix Provided state other than NEW. It's not clear to me there's any way other than manual review of NEW bugs to determine which ones need time spent debugging and fixing, and which ones just need to be reviewed and committed, but it would seem if we could mark bugs like that when submitting the patches, the people who do the reviews and commits could more easily get through them without wading through those they don't have the time to try to fix themselves at the moment. (Maybe changing it to be assigned to [EMAIL PROTECTED] instead of developers or something like that would work.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla process for submitting fixes
put [PATCH] in the bug description maybe? Alex --- Alan Coopersmith [EMAIL PROTECTED] wrote: Is there some way to mark a newly filed bug so it's clear that there's a patch attached and it just needs to be reviewed and checked in? According to the bugzilla docs, FIXED means the code is checked in and there doesn't seem to be any Fix Provided state other than NEW. It's not clear to me there's any way other than manual review of NEW bugs to determine which ones need time spent debugging and fixing, and which ones just need to be reviewed and committed, but it would seem if we could mark bugs like that when submitting the patches, the people who do the reviews and commits could more easily get through them without wading through those they don't have the time to try to fix themselves at the moment. (Maybe changing it to be assigned to [EMAIL PROTECTED] instead of developers or something like that would work.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla process for submitting fixes
On Thu, Nov 20, 2003 at 11:01:49AM -0800, Alan Coopersmith wrote: Is there some way to mark a newly filed bug so it's clear that there's a patch attached and it just needs to be reviewed and checked in? According to the bugzilla docs, FIXED means the code is checked in and there doesn't seem to be any Fix Provided state other than NEW. It's not clear to me there's any way other than manual review of NEW bugs to determine which ones need time spent debugging and fixing, and which ones just need to be reviewed and committed, but it would seem if we could mark bugs like that when submitting the patches, the people who do the reviews and commits could more easily get through them without wading through those they don't have the time to try to fix themselves at the moment. I've never seen a good answer to this one. If I were submitting patches, I'd be discussing them here. It is usually a good idea to do that anyway, regardless of the patch submission mechanisms. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla process for submitting fixes
On Thu, Nov 20, 2003 at 02:06:16PM -0800, Alan Coopersmith wrote: I'm getting ready to submit an XDMCP/IPv6 patch as soon as I finish testing it that will change the default IPv6 multicast address to the one IANA finally assigned after we decided to go ahead and start the standards public review without waiting for it. I don't think there's much there worth discussing, but would like to see it in the 4.4 release so it doesn't go out with a different multicast group address than everyone else (and presumably later XFree releases) will be using. Send a copy here as soon as you have a version ready for review. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bugzilla and XFree86 version
A number of bug reports have gotten filed against XFree86 4.3 which are actually CVS head bugs. I think it makes sense to add CVS as a version also, so people can choose that too. Might want to add CVS 4.3.99.n versions too, but that might be overkill. I can report this in bugzilla against bugzilla so it is tracked, but I wanted to ask about it here first. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Bugzilla #460] BIGREQUEST size change.
On Tue, 8 Jul 2003, Egbert Eich wrote: This is a matter that maybe should also be discussed on 'forum'. I don't know how to initiate a joint discussion on both lists. There is a comment on Roland Mainz's changes to make BIGREQUEST size tunable. Further comments are welcome. Egbert. === comment by Juliusz Chroboczek Roland, The below is not an objection to your change, just an explanation. XFree86 does not reschedule clients within requests; all rescheduling happens at a request boundary. Thus, with very large requests it is possible for a client to lock-out other clients for noticeable amounts of time. The situation is even worse on the SI, where scheduling is done by counting requests (rather than measuring time, as is done on XFree86). There, using big requests can impact the server's fairness in a big way. If Mozilla needs big requests to function with half-decent performance, then Mozilla is broken and should be fixed. Including work-arounds in XFree86 is counter-productive in the long term. I would like to suggest that you should file a bug with Mozilla. I personally don't have any objection to this change. Requests that tie up the server for an inordinate amount of time should be dealt with in a more generic fashion, IMO. And, perhaps, including this change would up the pressure to deal with the more generic problem. 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
[Bugzilla #460] BIGREQUEST size change.
This is a matter that maybe should also be discussed on 'forum'. I don't know how to initiate a joint discussion on both lists. There is a comment on Roland Mainz's changes to make BIGREQUEST size tunable. Further comments are welcome. Egbert. === comment by Juliusz Chroboczek Roland, The below is not an objection to your change, just an explanation. XFree86 does not reschedule clients within requests; all rescheduling happens at a request boundary. Thus, with very large requests it is possible for a client to lock-out other clients for noticeable amounts of time. The situation is even worse on the SI, where scheduling is done by counting requests (rather than measuring time, as is done on XFree86). There, using big requests can impact the server's fairness in a big way. If Mozilla needs big requests to function with half-decent performance, then Mozilla is broken and should be fixed. Including work-arounds in XFree86 is counter-productive in the long term. I would like to suggest that you should file a bug with Mozilla. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bugzilla #479: RFE: FreeType font engine should block opening
Here is an issue for discussion from bugzilla (submitted by Roland Mainz). Any opinions? Juliusz? Egbert. === RFE: xc/lib/font/FreeType/ font engine should block opening fonts when there is no encodings file available for it. Currently the behaviour seems to be that if an *.enc files is missing for the requested XLFD the code simply assumes ISO8859-1 for the non-existant *.enc files (which is horribly WRONG in most cases). Steps to reproduce: 1. Configure Xserver with freetype2 font engine and a fonts.dir entry like sonti.ttf -foobar-courier-medium-r-normal--0-0-0-0-m-0-blabla-666 2. Let a client open that font Expected behaviour: |XLoadFont()XLoadQueryFont/XQueryFont()| failure since the encoding if the font is unknown. Current behaviour: |XLoadFont()XLoadQueryFont/XQueryFont()| return a font handle which is likely not what the application expects (since ISO8859-1 encoding is used instead of blabla-666) ... ;-( ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bugzilla #479: RFE: FreeType font engine should block opening
EE Here is an issue for discussion from bugzilla (submitted by Roland EE Mainz). Any opinions? Juliusz? I'm the author of this code, and obviously I disagree (otherwise I wouldn't have designed it this way). I don't feel strongly about it, though, and have no objection if you decide to change it. You'll note that the difference only happens if the user decides to create broken fonts.dir, so truly the point is of little import... Places to change if you decide to do so: - Type1/t1funcs.c, line 628; - FreeType/ftenc.c, line 107. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
Ian Romanick writes: I looked into the code, and I now understand what's going on. Alexis made a good catch of a very subtle bug! The main problem that I had was that it wasn't 100% clear at first glance how bufSize / buf / pc were used. Some form of - 8 should be applied to bufSize. I have attached the patch that I plan to apply to the DRI tree. I suspect that it has only cosmetic and / or commentary differences from your patch. Some things have moved around in the DRI tree, so this patch probably won't apply to the XFree86 tree. We can wait until the DRI stuff is merged back again. The patch indeed is very similar to what has been proposed in #439. I've also looked at the GLX code. At line 671 in glxext.c there is : maxSize = ctx-bufSize - sizeof(xGLXRenderLargeReq); Wouldn't we have to add sz_xGLXRenderReq there again? I suppose if the size is to small it is saver as if it is too big. Would you mind taking bug #439 and close it when the code is scheduled for merger with XFree86? Thanks a lot! Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
There is a report in bugzilla (#439) which claims: the bug is in xc/lib/GL/glx/glxcmds.c int bufSize = XMaxRequestSize(dpy) * 4; should be int bufSize = XMaxRequestSize(dpy) * 4 - 8; or more cleanly int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq); it happens that you may completely fill your GLX buffer if you use variable size command larger than 156 bytes (and smaller than 4096 bytes) in that case you find yourself with an X command larger than 256Kbytes. This is very unlikely but possible. It explain why this bug has not shown itself before in this very old SGI code. I've briefly looked at the code and it seems to be correct. However I would like to double check before I commit anything. Any opinions? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
Egbert Eich wrote: There is a report in bugzilla (#439) which claims: the bug is in xc/lib/GL/glx/glxcmds.c int bufSize = XMaxRequestSize(dpy) * 4; should be int bufSize = XMaxRequestSize(dpy) * 4 - 8; or more cleanly int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq); it happens that you may completely fill your GLX buffer if you use variable size command larger than 156 bytes (and smaller than 4096 bytes) in that case you find yourself with an X command larger than 256Kbytes. This is very unlikely but possible. It explain why this bug has not shown itself before in this very old SGI code. I've briefly looked at the code and it seems to be correct. However I would like to double check before I commit anything. Any opinions? I'm not sure this is correct. bufSize is used to allocate the buffer (gc-buf in the code) that will hold the commands, including the xGLXRenderReq header. I've been doing a lot of work lately on the GLX code (both client-side server-side) in the DRI tree lately. I'll take a look at this a bit more and get back to you. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
Ian Romanick wrote:
Egbert Eich wrote:
There is a report in bugzilla (#439) which claims:
the bug is in xc/lib/GL/glx/glxcmds.c int bufSize =
XMaxRequestSize(dpy) * 4;
should be int bufSize = XMaxRequestSize(dpy) * 4 - 8;
or more cleanly
int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq);
it happens that you may completely fill your GLX buffer if you use
variable size command larger than 156 bytes (and smaller than 4096 bytes)
in that case you find yourself with an X command larger than
256Kbytes. This
is very unlikely but possible. It explain why this bug has not shown
itself
before in this very old SGI code.
I've briefly looked at the code and it seems to be correct.
However I would like to double check before I commit anything.
Any opinions?
I'm not sure this is correct. bufSize is used to allocate the buffer
(gc-buf in the code) that will hold the commands, including the
xGLXRenderReq header. I've been doing a lot of work lately on the GLX
code (both client-side server-side) in the DRI tree lately. I'll take
a look at this a bit more and get back to you.
I looked into the code, and I now understand what's going on. Alexis
made a good catch of a very subtle bug! The main problem that I had was
that it wasn't 100% clear at first glance how bufSize / buf / pc were
used. Some form of - 8 should be applied to bufSize. I have attached
the patch that I plan to apply to the DRI tree. I suspect that it has
only cosmetic and / or commentary differences from your patch.
Some things have moved around in the DRI tree, so this patch probably
won't apply to the XFree86 tree.
Index: glxcmds.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/glx/glxcmds.c,v
retrieving revision 1.44
diff -u -d -r1.44 glxcmds.c
--- glxcmds.c 25 Jun 2003 00:39:58 - 1.44
+++ glxcmds.c 30 Jun 2003 20:49:15 -
@@ -198,7 +261,7 @@
GLXContext AllocateGLXContext( Display *dpy )
{
GLXContext gc;
- int bufSize = XMaxRequestSize(dpy) * 4;
+ int bufSize;
CARD8 opcode;
if (!dpy)
@@ -217,7 +280,14 @@
}
memset(gc, 0, sizeof(struct __GLXcontextRec));
-/* Allocate transport buffer */
+/*
+** Create a temporary buffer to hold GLX rendering commands. The size
+** of the buffer is selected so that the maximum number of GLX rendering
+** commands can fit in a single X packet and still have room in the X
+** packed to for the GLXRenderReq header.
+*/
+
+bufSize = (XMaxRequestSize(dpy) * 4) - sz_xGLXRenderReq;
gc-buf = (GLubyte *) Xmalloc(bufSize);
if (!gc-buf) {
Xfree(gc);
Re: bugzilla
Egbert Eich wrote: Thank a lot for your offer! Currently the bugzilla is maintained by Stuart Anderson [EMAIL PROTECTED]. He managed to find a sponsor for the machine, volunteered to set it up and host it for us. He is an experienced software developer and has done X development for a long time. However he doesn't have much expereince in customizing a bugzilla. I'm sure he'd appreciate any help he can get administering the system. About me: Using Linux for about 10 years; working professionally with Linux as a SW architect in embedded and server environments. btw. we know each other from some Linux meetings, I am the guy talking about the ct driver for embedded system requirements; maybe you remember. Hm, I remember talking to several people about this subject. I'm sure I remember you, but please be a little more specific so I know exactly who you are ;-) I am *the* (:-)) one praising the quality of the CT driver and its complete set of accelerated functions, which I did not expect from a non-mainstream component. Just in case you got more pats on your back for the driver, you might remember that I was working on a car multimedia system based on Linux/X11. Bye, Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bugzilla
Hello Egbert, First people advocated that XFree86 has a bugzilla. Now we have one and people complain that it is broken. Our expertise is developing X not running a bugzilla. Where are the people with this expertise, the volunteers who step up and offer to help us to tweak it so it suits our needs best? I have some limited experience with bugzilla, having it adapted and introduced within our company. If someone could at least list some of the problems, so that I can estimate the time requirements, I would be willing to maintain the XFree86 bugzilla. About me: Using Linux for about 10 years; working professionally with Linux as a SW architect in embedded and server environments. btw. we know each other from some Linux meetings, I am the guy talking about the ct driver for embedded system requirements; maybe you remember. Regards, Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bugzilla #306 (Building with #define BuildRender NO)
Hi, I've attached a proposed patch to Bugzilla #306. Please review and comment. I may have missed something important... Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bugzilla #306 (Building with #define BuildRender NO)
I did something very similar, but also had to make changes in other parts of the code. In the end I gave up because of the myriad of problems in fb. Instead I just defined 'Option RenderColormapMode mono' in the ServerFlags section of the config file. My reason for disabling the Render extension at compile time was to prevent it from using up space in the colour map, but setting the mode to mono basically achieves the same thing. Regards, Lindsay Haigh Matthieu Herrb [EMAIL PROTECTED] To: [EMAIL PROTECTED] anadoo.fr cc: Sent by:Subject: Bugzilla #306 (Building with #define BuildRender NO) [EMAIL PROTECTED] 86.Org 01/06/03 23:20 Please respond to devel Hi, I've attached a proposed patch to Bugzilla #306. Please review and comment. I may have missed something important... Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: XFree86 bugzilla available
No DRI developer expressed his interest or opposition, probably because there isn't opposition, or simply no interest. In either case I see no reasons why not proceed, so I'll open a bug to address this. I'll ask that [EMAIL PROTECTED] (the same addressed used on SF BT system) is set as the default owner for DRI bugs. Also, what's the general mailing list one can subscribe to receive notifications everytime a bug is open? José Fonseca On Wed, Mar 19, 2003 at 12:07:56PM +, José Fonseca wrote: On Tue, Mar 18, 2003 at 08:04:22PM -0500, David Dawes wrote: An XFree86 bugzilla is now available at http://bugs.xfree86.org/. Many thanks to Hewlett-Packard for supplying the hardware, netSweng for hosting, and the many developers who helped configure and test it. I know that the current policy on DRI is to post bugs on dri-users or dri-devel, but with XFree86 having a bug database is inevitable that people will eventually post bugs there too. Therefore what's the possibility of: - Setting up a general owner for DRI bugs, which probably would be [EMAIL PROTECTED] - automatically set the owner of DRI bugs, e.g., by the users adding a DRI keyword, or associating the XFree86 Server-DRI extension component. - Add the possibility to add comments to bugs via e-mail. Basically I would like to be possible that: - An user adds a bug concerning DRI - The owner is (either manually or automatically) set to [EMAIL PROTECTED], which receives the bug - Any developer on the dri-devel list which has an account on XFree86 Bugzilla can reply and that comment is added to the bug database. - Certain maintainence tasks (such as closing the bug, read an attachment) will require to use Bugzilla web interface, but bugzilla can be configured to remember our login, so it's straightforward. I would appreciate if the XFree86 and DRI developers considered this. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: XFree86 bugzilla available
José Fonseca wrote: No DRI developer expressed his interest or opposition, probably because there isn't opposition, or simply no interest. In either case I see no reasons why not proceed, so I'll open a bug to address this. I'll ask that [EMAIL PROTECTED] (the same addressed used on SF BT system) is set as the default owner for DRI bugs. Also, what's the general mailing list one can subscribe to receive notifications everytime a bug is open? Sorry... I think it's a good idea as proposed. Keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: XFree86 bugzilla available
On Fre, 2003-03-21 at 21:07, José Fonseca wrote: No DRI developer expressed his interest or opposition, probably because there isn't opposition, or simply no interest. In either case I see no reasons why not proceed, so I'll open a bug to address this. I'll ask that [EMAIL PROTECTED] (the same addressed used on SF BT system) is set as the default owner for DRI bugs. I think it's a good idea but that dri-devel makes more sense than dri-patches. Also, what's the general mailing list one can subscribe to receive notifications everytime a bug is open? Currently [EMAIL PROTECTED] gets them all. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 bugzilla available
On Tue, 18 Mar 2003 20:04:22 -0500 David Dawes [EMAIL PROTECTED] wrote: An XFree86 bugzilla is now available at http://bugs.xfree86.org/. Many thanks to Hewlett-Packard for supplying the hardware, netSweng for hosting, and the many developers who helped configure and test it. This is a very welcome addition, i have personally had problems in finding out if an error i encountered was: a. My fault b. A bug c. Reported already. Enjoy. I will ! David -- David Dawes Release Engineer/President The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- .-. /v\ L I N U X // \\ --Phear the Penguin-- /( )\ ^^-^^ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 bugzilla available
On Wed, 19 Mar 2003, [iso-8859-15] José Fonseca wrote: I know that the current policy on DRI is to post bugs on dri-users or dri-devel, but with XFree86 having a bug database is inevitable that people will eventually post bugs there too. Therefore what's the possibility of: - Setting up a general owner for DRI bugs, which probably would be [EMAIL PROTECTED] - automatically set the owner of DRI bugs, e.g., by the users adding a DRI keyword, or associating the XFree86 Server-DRI extension component. - Add the possibility to add comments to bugs via e-mail. Bugzilla requires a valid authenticated login. Not possible to do that with email-bugzilla at least currently. Basically I would like to be possible that: - An user adds a bug concerning DRI - The owner is (either manually or automatically) set to [EMAIL PROTECTED], which receives the bug - Any developer on the dri-devel list which has an account on XFree86 Bugzilla can reply and that comment is added to the bug database. Click on the URL in the bugzilla email, the bug comes up, and you can enter a comment directly into bugzilla. Even pine can do this easily. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 bugzilla available
An XFree86 bugzilla is now available at http://bugs.xfree86.org/. Many thanks to Hewlett-Packard for supplying the hardware, netSweng for hosting, and the many developers who helped configure and test it. Enjoy. David -- David Dawes Release Engineer/President The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
