Re: [Dri-devel] Re: Re: SPAM : DRI Devel ratio
On Thu, May 29, 2003 at 07:34:28AM +0200, Sven Luther wrote: On Thu, May 29, 2003 at 12:00:22AM -0400, Mike A. Harris wrote: On Wed, 28 May 2003, Sven Luther wrote: I was being sarcastic, his message was encoded with koi8-r, which, along with being html, is one of the indescriminate reasons people block email (and get a good number of false positives) however, foreign language encoding is separate from html email. blocking based on foreign language encodings is not such a good idea. blocking html is not so bad, though. You need to block multi-part mails with only one html part too though, which is not so easy to do, i think. This filter doesn't catch *everything*, but for the last 6 years or so, it has had zero false positives for me while subscribed to limitless numbers of mailing lists. :0: * ^Content-Type:.*text/html HTML Yep, i have this too, but half the html spam i get pass trough this, and because it is : Content-Type: multipart/alternative; boundary=E_BBFDE6F0B.95CA_CC.D7. ... This is a multi-part message in MIME format. --E_BBFDE6F0B.95CA_CC.D7. Content-Type: text/html Content-Transfer-Encoding: quoted-printable ... --E_BBFDE6F0B.95CA_CC.D7.-- On the other hand i don't want to catch the emails which have a text and an html section, since they are mostly valid ones. The XFree86 mailing list filtering checks for a few different types of html-only messages, including a few levels deep of nesting (which I've seen in some spam). It does catch the occasional false-positive, but it's fairly rare, and a reasonable tradeoff given its effectiveness. Anyway, i have almost managed to write a sed script doing this, but i am not sure if it is possible to get the value of the boundary and match on it in the address pattern when using sed. If you're prepared to use perl, there are packages for breaking out the mime structure. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture wrap modes
Ian Romanick wrote: Ian Romanick wrote: Log message: Fixed the various supported texture wrap modes. Added a fallback for unsupportable combinations of S/T wrap modes. All of the exported modes on Radeon, R200, and MGA should be correct now. I'm going to try and look at i830 this week. Could somebody please see about fixing up Rage128 and 3dfx? I see that both of those have some of the same problems that the fixed drivers used to have. Has anyone had a chance to look at this on either Rage128 or 3dfx? I did a little snooping in both drivers, and I have a couple theories, but someone with the actual hardware will have to verify them. I think the Rage128 driver is wrong in a couple of ways. It uses the same mode for GL_CLAMP and GL_CLAMP_TO_BORDER. If the hardware, like the Intel hardware, can't support GL_CLAMP, then it should use GL_CLAMP_TO_EDGE. This is consistent with the Intel driver. I think it's also closer to what people are likely to expect. I looked at Delph3D, and the Rage128 drivers for the other operating system don't support ARB_texture_mirrored_repeat. They do, however, support ATI_texure_mirror_once. Changing 'b' in texwrap.c to 1.2 (from 0.2) will show which the driver is actually doing. http://delphi3d.net/hardware/viewreport.php?report=294 The Rage128 driver also doesn't export the SGI versions of any of the clamp extensions. This is trivial and not necessary, but is probably a good idea. The 3dfx driver also has a number of problems. The switch-statement that handles texture wrap modes doesn't have a case for GL_CLAMP_TO_EDGE, which is a required part of GL 1.2. The bad part is that because GL_CLAMP_TO_EDGE comes after GL_CLAMP in the test, it will probably look okay in the test. Moreover, I don't see a mode for it (or GL_CLAMP_TO_BORDER) in tdfx_glide.h. I'm not sure what we should do about that. At the very least we should make GL_CLAMP_TO_EDGE work like GL_CLAMP. Leaving the currently set mode as-is is just plain wrong. tdfx_glide.h has a mirror mode (GR_TEXTURECLAMP_MIRROR_EXT, line 308), so the hardware probably supports ARB / IBM_texture_mirrored_repeat. That should be investigated. The driver also doesn't export any of the extension strings. I assme that is because it doesn't actually support any of the extensions (even the required one). The Banshee driver (from 07-Jan-2000), Voodoo3 driver (from 16-Jan-2001), and the Voodoo5 driver (from 21-Nov-2000) for that other operating system all export SGIS_texture_edge_clamp, but that's all. Either 3dfx implements GL_CLAMP as GL_CLAMP_TO_EDGE (like Intel), or there some missing bits in tdfx_glide.h. http://delphi3d.net/hardware/viewreport.php?report=19 http://delphi3d.net/hardware/viewreport.php?report=17 http://delphi3d.net/hardware/viewreport.php?report=204 --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture wrap modes
On Thu, 29 May 2003, Ian Romanick wrote: Ian Romanick wrote: Ian Romanick wrote: Log message: Fixed the various supported texture wrap modes. Added a fallback for unsupportable combinations of S/T wrap modes. All of the exported modes on Radeon, R200, and MGA should be correct now. I'm going to try and look at i830 this week. Could somebody please see about fixing up Rage128 and 3dfx? I see that both of those have some of the same problems that the fixed drivers used to have. Has anyone had a chance to look at this on either Rage128 or 3dfx? I did a little snooping in both drivers, and I have a couple theories, but someone with the actual hardware will have to verify them. I think the Rage128 driver is wrong in a couple of ways. It uses the same mode for GL_CLAMP and GL_CLAMP_TO_BORDER. iirc, textures with a border are a fallback on r128. GL_CLAMP looks the same in texwrap on r128 as it does with software/indirect rendering. If the hardware, like the Intel hardware, can't support GL_CLAMP, then it should use GL_CLAMP_TO_EDGE. This is consistent with the Intel driver. I think it's also closer to what people are likely to expect. I looked at Delph3D, and the Rage128 drivers for the other operating system don't support ARB_texture_mirrored_repeat. They do, however, support ATI_texure_mirror_once. Changing 'b' in texwrap.c to 1.2 (from 0.2) will show which the driver is actually doing. I tried this. It is in fact doing mirrored repeat (looks the same as software/indirect rendering with b set to 1.2). http://delphi3d.net/hardware/viewreport.php?report=294 The Rage128 driver also doesn't export the SGI versions of any of the clamp extensions. This is trivial and not necessary, but is probably a good idea. I think we should export the EXT and SGIS edge clamp extensions (the texwrap demo gave a warning about that since the GL version is 1.2 but the extensions aren't present). I'll add this. The 3dfx driver also has a number of problems. The switch-statement that handles texture wrap modes doesn't have a case for GL_CLAMP_TO_EDGE, which is a required part of GL 1.2. The bad part is that because GL_CLAMP_TO_EDGE comes after GL_CLAMP in the test, it will probably look okay in the test. Moreover, I don't see a mode for it (or GL_CLAMP_TO_BORDER) in tdfx_glide.h. I'm not sure what we should do about that. At the very least we should make GL_CLAMP_TO_EDGE work like GL_CLAMP. Leaving the currently set mode as-is is just plain wrong. tdfx_glide.h has a mirror mode (GR_TEXTURECLAMP_MIRROR_EXT, line 308), so the hardware probably supports ARB / IBM_texture_mirrored_repeat. That should be investigated. The driver also doesn't export any of the extension strings. I assme that is because it doesn't actually support any of the extensions (even the required one). The Banshee driver (from 07-Jan-2000), Voodoo3 driver (from 16-Jan-2001), and the Voodoo5 driver (from 21-Nov-2000) for that other operating system all export SGIS_texture_edge_clamp, but that's all. Either 3dfx implements GL_CLAMP as GL_CLAMP_TO_EDGE (like Intel), or there some missing bits in tdfx_glide.h. http://delphi3d.net/hardware/viewreport.php?report=19 http://delphi3d.net/hardware/viewreport.php?report=17 http://delphi3d.net/hardware/viewreport.php?report=204 --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Ian Romanick wrote: Keith Whitwell wrote: Michel Dänzer wrote: The bottom line is that with a 2.5 kernel, sched_yield() will discard the time slice of the process, so misuse of it will cause bad performance. I guess it's possible that this could be a problem. The yield is there to allow two graphics apps to somewhat smoothly share the card cpu - otherwise you get very non-smooth interleaving or even starvation of some of the graphics apps on 2.4. Wouldn't a better sollution be to release the hardware lock then re-get it? That should allow a blocked 3D process to get the lock and make progress. Or am I missing something about the way locking works in DRI? The lock doesn't seem to be 'fair' like that - in practise it isn't transfered to the waiting process (unless you do a sched_yield() after unlocking). Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
On Thu, 29 May 2003, Keith Whitwell wrote: The lock doesn't seem to be 'fair' like that - in practise it isn't transfered to the waiting process (unless you do a sched_yield() after unlocking). Indeed. If you want fairness, you need to code for it explicitly. It's not hard per se, but it does slow down locking, sometimes noticeably. This is not likely to be a huge problem for DRI, but it comes up in other circumstances (ie in-kernel spinlocks don't even try to be fair, it's just too expensive and if you get the kind of contention that you care you must do something else altogether). The DRI locking really should be revisited at some point. It could probably be done more cleverly, and without these problems. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 108] matrox drm code cannot find framebuffer, crashes X
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=108 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Additional Comments From [EMAIL PROTECTED] 2003-05-29 16:47 --- I agree, if one is using Matrox's drivers, they're not using what ships with XFree86, but rather a binary blob loaded into a driver that isn't what ships with XFree86. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Quoting Linus Torvalds ([EMAIL PROTECTED]): On Thu, 29 May 2003, Keith Whitwell wrote: The lock doesn't seem to be 'fair' like that - in practise it isn't transfered to the waiting process (unless you do a sched_yield() after unlocking). Indeed. If you want fairness, you need to code for it explicitly. It's not hard per se, but it does slow down locking, sometimes noticeably. This is not likely to be a huge problem for DRI, but it comes up in other circumstances (ie in-kernel spinlocks don't even try to be fair, it's just too expensive and if you get the kind of contention that you care you must do something else altogether). The DRI locking really should be revisited at some point. It could probably be done more cleverly, and without these problems. In the kernel part of Fusion (our IPC API) I'm currently calling yield() after unlocking a long-time lock. Maybe you have some hints before I'm working on that issue. BTW, you might want to look at Fusion when you have time (see our web cvs). We had to do an IPC API from scratch, because SysV IPC was not sufficient enough to reach the current level of stability and speed. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] End this abusive advertising l nkb87k17s5o
*Warning - your PC is vulnerable to Messenger Spam* Ever have a window pop up on your screen, offering to sell you some garbage you don't need? This is a cruel invasion of your privacy and should not be allowed to continue. Here are some facts about unsolicited Messenger advertising: - ISPs and governments are powerless to stop it. There are no laws governing these types of messages yet. - Messenger Spam is the fastest growing type of unsolicited advertising on the Internet today, and has been recorded growing as much as 1500% a month. - You are not protected! If you haven't received a pop up message through Messenger, you are guaranteed to any day now. It is next to impossible to trace the senders of such messages Stop unwanted messenger popups forever! Cease future mailings please --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
On Fri, 30 May 2003, Denis Oliver Kropp wrote: In the kernel part of Fusion (our IPC API) I'm currently calling yield() after unlocking a long-time lock. Maybe you have some hints before I'm working on that issue. You really shouldn't unconditionally yield. That just tells the kernel that you don't have anything to do, and since it isn't directed any way the kernel can't really do anything smart about it, and has to assume that you're less important than basically _all_ other programs (modulo nice levels). Which looks like it works for many trivial cases, and gives _wonderful_ interactivity, but you'll see just how much it sucks if you ever have a compile going on in the background, and you continually yield to it and tell the system that the compile is more important than you are. See the problem? You _really_ want to use futex'es for any user-space locking. It's back-ported to 2.4.x, and it gets these cases _right_. There are fair user-space locks based on futexes as part of modern glibc sources, and they are _fast_, since all non-contention (common case) is done entirely in user space, and they do the right thing (*) when there is contention. BTW, you might want to look at Fusion when you have time (see our web cvs). Docs/design where? Linus (*) Right thing: sleep and _directed_ wake-ups, no random yields. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Do you remember me?
wmfacm2zpf63pcguh13x8wab1 Stop Mailings Here ffk0j21cvznp0mj0y3nfsnd72
[Dri-devel] GL_NV_texture_rectangle on radeon
I copied together (from r200 driver) a patch which enables GL_NV_texture_rectangle on radeon. The yuvrect.c test from mesa seems to work, but texrect.c doesnt. strange. Other issues: 1) radeonEmitBlit uses an already shifted color_fmt, which is defined in radeon_reg.h, r200EmitBlit uses an unshifted color_fmt which is defined in r200_reg.h. - should we shift back and forth in the radeon-driver to match the r200-driver? 2) I just included radeonEmitBlit and radeonEmitWait in radeon_ioctl.c, the r200-driver has a separate file r200_cmdbuf.c for them. 3) which drmMinor is needed to support the new cmd-packets? 4) no AGP-texturing Any hints? greetings, Andreas nv_rectangle.patch Description: Binary data
Re: [Dri-devel] Re: sched_yield()
Linus Torvalds wrote: On Fri, 30 May 2003, Denis Oliver Kropp wrote: In the kernel part of Fusion (our IPC API) I'm currently calling yield() after unlocking a long-time lock. Maybe you have some hints before I'm working on that issue. You really shouldn't unconditionally yield. That just tells the kernel that you don't have anything to do, and since it isn't directed any way the kernel can't really do anything smart about it, and has to assume that you're less important than basically _all_ other programs (modulo nice levels). Which looks like it works for many trivial cases, and gives _wonderful_ interactivity, but you'll see just how much it sucks if you ever have a compile going on in the background, and you continually yield to it and tell the system that the compile is more important than you are. See the problem? You _really_ want to use futex'es for any user-space locking. It's back-ported to 2.4.x, and it gets these cases _right_. There are fair user-space locks based on futexes as part of modern glibc sources, and they are _fast_, since all non-contention (common case) is done entirely in user space, and they do the right thing (*) when there is contention. You're right. We do _really_ want to use futex'es. However, I don't think they're available on *BSD or Solaris. I don't know if there's anyone working on DRI right now that knows enough about Linux and *BSD to be able to determine what the effort would be to make futex'es or a futex-like wrapper for those systems. I honestly believe that is the only reason we haven't already started using futex'es. We also have the problem of having to support old kernels with new user-mode drivers. Hmmm...I'll have to look in to futex'es more... --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bin. driver packages
Two questions... 1. Are the wrapped binary driver packages ever coming back? 2. It seems with an old one I got (binary driver packages) it was missing the libGL's so that once installed, (for example) glxinfo segfaults as it tries to load old libGL's. An oversight or purposeful omission? Thanks John --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
On Thu, 29 May 2003, Ian Romanick wrote: You're right. We do _really_ want to use futex'es. However, I don't think they're available on *BSD or Solaris. No. But you don't want to use them directly anyway, they're at the wrong level. I haven't checked what glibc does, but I bet it has a nice wrapper around them that makes them look basically like user-level spinlocks. And once you have a nice wrapper and they look like spinlocks, *BSD and Solaris must have _some_ equivalent. If worst comes to worst, you do a loop with atomic accesses and yield() thing as a fallback. We also have the problem of having to support old kernels with new user-mode drivers. You may also have interesting binary compatibility issues with old and new DRI binaries running concurrently. However, I don't think the old kernels are that much of an issue, I think futexes got back-ported a fair time ago, and I'd assume that most people who want to have a really recent DRI setup have a fairly recent distribution too.. But yeah, I don't know which distributions picked up the backports. I don't follow 2.4.x.. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Quoting Linus Torvalds ([EMAIL PROTECTED]): On Fri, 30 May 2003, Denis Oliver Kropp wrote: In the kernel part of Fusion (our IPC API) I'm currently calling yield() after unlocking a long-time lock. Maybe you have some hints before I'm working on that issue. You really shouldn't unconditionally yield. That just tells the kernel that you don't have anything to do, and since it isn't directed any way the kernel can't really do anything smart about it, and has to assume that you're less important than basically _all_ other programs (modulo nice levels). Which looks like it works for many trivial cases, and gives _wonderful_ interactivity, but you'll see just how much it sucks if you ever have a compile going on in the background, and you continually yield to it and tell the system that the compile is more important than you are. See the problem? Yes, I think for now I can add a check to call yield() only if another task is waiting for the lock. You _really_ want to use futex'es for any user-space locking. It's back-ported to 2.4.x, and it gets these cases _right_. There are fair user-space locks based on futexes as part of modern glibc sources, and they are _fast_, since all non-contention (common case) is done entirely in user space, and they do the right thing (*) when there is contention. One special requirement to nearly all Fusion primitives is much like the SEM_UNDO flag for SysV semaphores. Are futexes automatically unlocked if the process that locked it gets killed by SIGKILL? Fusion also implements reference counters that way. The problem with SysV semaphores was that the undo counter is stored thread wise (Fusion stores it per file handle as the API is a bunch of ioctls and the release file op does the cleanup). BTW, you might want to look at Fusion when you have time (see our web cvs). Docs/design where? I'm sorry, there's no documentation or design paper yet. But I will start writing one. A bit documentation can be found in the headers of the user level part of Fusion in DirectFB/src/core/fusion. (*) Right thing: sleep and _directed_ wake-ups, no random yields. I will have a look at the futex implementation, thanks. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
On Thu, May 29, 2003 at 10:52:15PM -0700, Linus Torvalds wrote: On Thu, 29 May 2003, Ian Romanick wrote: You're right. We do _really_ want to use futex'es. However, I don't think they're available on *BSD or Solaris. ... And once you have a nice wrapper and they look like spinlocks, *BSD and Solaris must have _some_ equivalent. If worst comes to worst, you do a loop with atomic accesses and yield() thing as a fallback. Dunno anything about futex'es. But Solaris does not seem to have an equivalent of any of atomic_inc(), atomic_dec(), atomic_read() FYI. It has the old standards of mutexes, and semaphores. Oh, and condition variables. [ cv_wait, cv_signal ] --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bin. driver packages
On Fri, May 30, 2003 at 12:49:57AM -0500, John Sheu wrote: Two questions... 1.Are the wrapped binary driver packages ever coming back? Appearently there is a problem while building them, because they are back for some time. I'm going to look into it. 2.It seems with an old one I got (binary driver packages) it was missing the libGL's so that once installed, (for example) glxinfo segfaults as it tries to load old libGL's. An oversight or purposeful omission? Not an oversight - libGL shouldn't be necessary as the one that comes with XFree86 suits perfectly. The segfault must be due to something else. José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Phentramine
Title: New Page 1
[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugs.xfree86.org/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the Reassign bug to owner of selected component option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the Accept bug command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW[EMAIL PROTECTED] Or, you can use the general query page, at http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185 --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: SPAM : DRI Devel ratio
On Thu, May 29, 2003 at 11:53:32AM -0400, David Dawes wrote: On Thu, May 29, 2003 at 07:34:28AM +0200, Sven Luther wrote: On Thu, May 29, 2003 at 12:00:22AM -0400, Mike A. Harris wrote: On Wed, 28 May 2003, Sven Luther wrote: I was being sarcastic, his message was encoded with koi8-r, which, along with being html, is one of the indescriminate reasons people block email (and get a good number of false positives) however, foreign language encoding is separate from html email. blocking based on foreign language encodings is not such a good idea. blocking html is not so bad, though. You need to block multi-part mails with only one html part too though, which is not so easy to do, i think. This filter doesn't catch *everything*, but for the last 6 years or so, it has had zero false positives for me while subscribed to limitless numbers of mailing lists. :0: * ^Content-Type:.*text/html HTML Yep, i have this too, but half the html spam i get pass trough this, and because it is : Content-Type: multipart/alternative; boundary=E_BBFDE6F0B.95CA_CC.D7. ... This is a multi-part message in MIME format. --E_BBFDE6F0B.95CA_CC.D7. Content-Type: text/html Content-Transfer-Encoding: quoted-printable ... --E_BBFDE6F0B.95CA_CC.D7.-- On the other hand i don't want to catch the emails which have a text and an html section, since they are mostly valid ones. The XFree86 mailing list filtering checks for a few different types of html-only messages, including a few levels deep of nesting (which I've seen in some spam). It does catch the occasional false-positive, but it's fairly rare, and a reasonable tradeoff given its effectiveness. Are they available somewhere so i can take a look ? Anyway, i have almost managed to write a sed script doing this, but i am not sure if it is possible to get the value of the boundary and match on it in the address pattern when using sed. If you're prepared to use perl, there are packages for breaking out the mime structure. I would rather not use perl, if anything, i would write a small ocaml program to do it or maybe extend spamoracle which i already call. The execution cose per mail would be lower this way. Friendly, Sven Luther David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Build problems...
For the past 24 hours, I've been having build problems with the cvs trunk: make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common' cleaning in lib/GL/mesa/src/drv/r200... make[5]: Entering directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' Makefile:8: *** missing separator. Stop. make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' Anyone know what's up? Adam --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
