Re: [Dri-devel] DRI Mailing list maintanence / maintaner
Could the list be set up to: 1) maintain a list of email addresses that have been verified GOOD. 2) maintain a list of email addresses that have been verified BAD (e.g. [EMAIL PROTECTED]). 3) Check all inbound messages, such that: 3a) If the message is from an email subscribed to the list, ACCEPT. 3b) If the message is from a verified GOOD email, ACCEPT. 3c) If the message is from a verified BAD email, REJECT. 3d) Otherwise, hold message for 1 week, and send message to sender asking for confirmation. 3e) If no confirmation received after 1 week, purge message. 3f) If confirmation received, add sender to GOOD list and post message. That way, everything is automated, 99.9% of the spams will be dropped, and any spammers that DO confirm can be moved from the good list to the bad list. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRIInfoRec, Identifiers and DRI Configuration
Felix and I have been slowing working on a more solidified design of the DRI configuration idea that has been discussed on this list a couple of times. During our last public discussion in which we were talking about configuration file formats we attempted to find a item in which to key everything else from. We played around with using Screens and driver names, but in the end we were looking at keying off the device identifier. At this time I still believe that is the best thing to use, but we have no way at this time of grabbing such information from inside a DRI driver. What I would like to do is add a field to the DRIInfoRec struct: char* cardIdentifier or char* configIdentifier It seems to be the most logical route since most of these type of options already exist there: /* device info */ char* drmDriverName; char* clientDriverName; char* busIdString; This option would set in the DRIScreenInit much like the busIdString is set during initialization. Does anyone see any issues with this or does anyone have any technical objections on why this shouldn't be done? -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
On Fri, Feb 14, 2003 at 06:24:50PM -0500, Leif Delgass wrote: >On Fri, 14 Feb 2003, David Dawes wrote: > >[snip] > >> There are some more serious things holding up 4.3, including the issue >> that Leif mentioned here a couple of days ago. I haven't seen anyone >> comment on his proposed solution for that one either... >> >> David > >I was wondering about that myself. :) I'll reiterate the problem, but this >time with a patch to give people something more concrete to comment on. >This is, I think, the easiest and quickest fix, if not necessarily the >most correct. This patch does the following: Thanks Leif. I'll commit that now. If it needs any further fine tuning we can do that later. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI Mailing list maintanence / maintaner
On Fri, Feb 14, 2003 at 08:35:02PM -0500, Leif Delgass wrote: > On Sat, 15 Feb 2003, Alan Hourihane wrote: > > > On Fri, Feb 14, 2003 at 03:34:45 -0700, Brian Paul wrote: > > > Smitty wrote: > > > >Hi Rich > > > > > > > > > > > >>>Is there anything that can be done to cut down the spam on dri-devel? > > > >>>Several other mailing lists I'm on hold submissions by non-subscribers > > > >>>for approval. I'd even be willing to sort the non-subscribed emails, > > > >>>so that everyone else could avoid them... > > > > > > > >That would be great, its really starting to get on my tits now. > > > > > > > >What you've mentioned has been suggested by Alex in response to one of my > > > >emails about this. > > > > > > > >I've tried contacting the list mainatiner privately but it would appear > > > >that the maintainer listed under dri-devel list info is incorrect. > > > > > > > > > > > >>I've just started running bogofilter on all incoming email, myself, > > > >>though yeah, it'd be nice if it weren't so necessary. > > > > > > > >I'm on the dri-digest(s) option so I just live with it. > > > > > > > > > > > >>>Or am I just being obnoxious? > > > >> > > > >>Less so than the spammers. :) > > > > > > > >I skipped your email because of the subject line. > > > > > > I'd be happy to see postings restricted to subscribers too. > > > > > > Unfortunately, I don't know what the list-admin password is. Maybe Daryll > > > or Rik do? > > > > I could do it, but I don't think it's a good idea to restrict those > > who are non-members of the list. Cross postings from the xfree86 lists > > are sometimes useful. > > > > Alan. > > What about dri-patches? It gets all the same spam that -devel and -users > do. I don't see any reason not to restrict posting to that list to > project members. Of course, there may be people with commit access that > aren't subscribed. Is there a way to restrict it to sourceforge accounts > rather than the subscriber list? I've set the restriction on dri-patches and added @users.sourceforge.net to the list of acceptable posters. That should cover the non-subscribed committers. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
On Tue, 2003-02-11 at 20:11, Leif Delgass wrote: > I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been > updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've > updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 > driver. Testing hasn't shown any problems so far. > > I haven't adapted the mach64 drm to the os-independence changes yet. I > could start this, but we are going to need a generic replacement for the > pci_alloc_consistent Linux interface. I think it's probably best to hold > off on making that switch, pending the changes Jose has proposed: > http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html > > In the meantime, the drm can still be compiled and used from the old linux > kernel directory like the other drivers which have yet to be converted. > > I'd recommend that people using the mach64-0-0-5-branch from CVS update to > this new branch and report any regressions or new bugs to the list. > Sometime in the next few weeks, I'll also be updating the GATOS Xvideo > patch available at the site in my sig. Since the GATOS head is now based > on current XFree86 cvs, I may not have a new patch until 4.3.0 is released > and changes get propagated back to the DRI and GATOS trees. I've been working on this locally a little, but haven't tackled the pci_alloc_consistent in a proper manner yet (the corresponding interface for us is bus_dma, which I am just beginning to understand while working on ati_pcigart.h/drm_scatter.h conversion). If you would approve of me moving the mach64 files to shared/drm/kernel, I could at least work on things incrementally (much of this stuff is mechanical changes), and then hopefully provide something pretty to review for pci_alloc_consistent. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] system lockup when KMess draws to screen while OpenGL screensaver is running
Hello, I'm experiencing the following behavior on my IBM A20p ThinkPad with an ATI Rage Mobility M3 video card, running XFree86-4.2. When certain GL screensavers are running, the entire system locks up (requiring a hard boot) when the messaging client I'm using (KMess 0.9.8, for KDE 3.x) draws a notification balloon to the screen. From the experimentation I've done, this appears to only happen with GL screensavers. Furthermore, it only happens with some of them: When running the "Flux" screensaver that comes with KDE 3.1, the drawing of the notification balloon will lockup the system. When running another GL screensaver (KEuphoria), the screensaver will only appear to skip frames (jerky motion) when KMess' notification balloon appears on screen, but then it will resume normal behavior once the notification balloon has disappeared. I've spent a fair amount of time searching the dri-devel and dri-users mailing list archives, but could find no report of similar problems. Perhaps I'm not entering appropriate queries. I'm not sure what info would be useful to include here, so I've pasted the output of 'glxinfo' and 'xvinfo' below. Thanks for any suggestions! Alvin 'glxinfo' output: display: :0.0 screen:0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Rage128 20010405 M3 AGP 1x x86/MMX/SSE OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 'xvinfo' output: X-Video Extension version 2.2 screen #0 Adaptor #0: "ATI Rage128 Video Overlay" number of ports: 1 port base: 59 operations supported: PutImage supported visuals: depth 16, visualID 0x23 depth 16, visualID 0x24 depth 16, visualID 0x25 depth 16, visualID 0x26 depth 16, visualID 0x27 depth 16, visualID 0x28 depth 16, visualID 0x29 depth 16, visualID 0x2a number of attributes: 4 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 30) "XV_BRIGHTNESS" (range -64 to 63) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range 0 to 31) client settable attribute client gettable attribute (current value is 16) "XV_DOUBLE_BUFFER" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) maximum XvImage size: 2048 x 2048 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) _ Tired of spam? Get advanced junk ma
[Dri-devel] Re: DRI Mailing list maintanence / maintaner
On Fri, 14 Feb 2003, Leif Delgass wrote: >> I could do it, but I don't think it's a good idea to restrict those >> who are non-members of the list. Cross postings from the xfree86 lists >> are sometimes useful. >> >> Alan. > >What about dri-patches? It gets all the same spam that -devel and -users >do. I don't see any reason not to restrict posting to that list to >project members. Of course, there may be people with commit access that >aren't subscribed. Is there a way to restrict it to sourceforge accounts >rather than the subscriber list? Why not just have posts from non-members moderated? They would get held long enough for someone to look at them and go "ah, this is not spam", then accept the message for posting. Of course, that would mean a message would get held until a moderator could look at it. I do this on our xfree86-list, and it works well. I dunno if that would be something one of the list maintainers would want to do or not though. Just a suggestion nonetheless. On the other side of things, spamassassin rocks. It nails almost all of my spam. A good 93% to date anyway. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI Mailing list maintanence / maintaner
On Sat, 15 Feb 2003, David D. Hagood wrote: >Date: Sat, 15 Feb 2003 09:23:08 -0600 >From: David D. Hagood <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii; format=flowed >List-Id: >Subject: Re: DRI Mailing list maintanence / maintaner > >Could the list be set up to: >1) maintain a list of email addresses that have been verified GOOD. >2) maintain a list of email addresses that have been verified BAD (e.g. >[EMAIL PROTECTED]). >3) Check all inbound messages, such that: > 3a) If the message is from an email subscribed to the list, ACCEPT. > 3b) If the message is from a verified GOOD email, ACCEPT. > 3c) If the message is from a verified BAD email, REJECT. > 3d) Otherwise, hold message for 1 week, and send message to sender >asking for confirmation. > 3e) If no confirmation received after 1 week, purge message. > 3f) If confirmation received, add sender to GOOD list and post message. > >That way, everything is automated, 99.9% of the spams will be dropped, >and any spammers that DO confirm can be moved from the good list to the >bad list. spamassassin does probably better spam filtering than any homebrew mechanism someone could come up with in a short amount of time. That handles getting rid of the BAD posts, and with very low false positives. I get about 0.5% false positives. With minor tweaking it would be 0 though. As for #1 above, the list of addresses verfied "GOOD" would be those who subscribed to the list in the first place. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
On 15 Feb 2003, Eric Anholt wrote: > On Tue, 2003-02-11 at 20:11, Leif Delgass wrote: > > I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been > > updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've > > updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 > > driver. Testing hasn't shown any problems so far. > > > > I haven't adapted the mach64 drm to the os-independence changes yet. I > > could start this, but we are going to need a generic replacement for the > > pci_alloc_consistent Linux interface. I think it's probably best to hold > > off on making that switch, pending the changes Jose has proposed: > > http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html > > > > In the meantime, the drm can still be compiled and used from the old linux > > kernel directory like the other drivers which have yet to be converted. > > > > I'd recommend that people using the mach64-0-0-5-branch from CVS update to > > this new branch and report any regressions or new bugs to the list. > > Sometime in the next few weeks, I'll also be updating the GATOS Xvideo > > patch available at the site in my sig. Since the GATOS head is now based > > on current XFree86 cvs, I may not have a new patch until 4.3.0 is released > > and changes get propagated back to the DRI and GATOS trees. > > I've been working on this locally a little, but haven't tackled the > pci_alloc_consistent in a proper manner yet (the corresponding interface > for us is bus_dma, which I am just beginning to understand while working > on ati_pcigart.h/drm_scatter.h conversion). > > If you would approve of me moving the mach64 files to shared/drm/kernel, > I could at least work on things incrementally (much of this stuff is > mechanical changes), and then hopefully provide something pretty to > review for pci_alloc_consistent. As long as the Linux build still works, that's fine by me. If you want to create the makefile links, move it to shared, and work on macro-izing the ioctls and whatnot, go for it. I was going to do this eventually, but if you're eager to get started, that's great. Of course, this will all have to happen in the mach64-0-0-6-branch for now, until we get the DRM interface/security changes done. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRI Mailing list maintanence / maintaner
On Sat, 15 Feb 2003, Mike A. Harris wrote: > On Fri, 14 Feb 2003, Leif Delgass wrote: > > >> I could do it, but I don't think it's a good idea to restrict those > >> who are non-members of the list. Cross postings from the xfree86 lists > >> are sometimes useful. > >> > >> Alan. > > > >What about dri-patches? It gets all the same spam that -devel and -users > >do. I don't see any reason not to restrict posting to that list to > >project members. Of course, there may be people with commit access that > >aren't subscribed. Is there a way to restrict it to sourceforge accounts > >rather than the subscriber list? > > Why not just have posts from non-members moderated? They would > get held long enough for someone to look at them and go "ah, this > is not spam", then accept the message for posting. Of course, > that would mean a message would get held until a moderator could > look at it. > > I do this on our xfree86-list, and it works well. I dunno if > that would be something one of the list maintainers would want to > do or not though. Just a suggestion nonetheless. > > On the other side of things, spamassassin rocks. It nails almost > all of my spam. A good 93% to date anyway. I think spam filtering for dri-devel and dri-users would be a good solution -- IMO, that would be better than moderation. For dri-patches, the Reply-To is dri-devel. I'd rather have just commit messages and nothing else on dri-patches. Any comments/replies to specific patches, or posts dealing with CVS should go to dri-devel anyway. That's why I suggested limiting just dri-patches to sourceforge addresses. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Your message to Dri-patches awaits moderator approval (fwd)
Speaking of Dri-patches... ;) There seems to be a problem with the @users.sourceforge.net wildcard address in the subscriber list. I'm subscribed to Dri-patches, but not with my sourceforge email. -- Leif Delgass http://www.retinalburn.net -- Forwarded message -- Date: Sat, 15 Feb 2003 18:01:02 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Your message to Dri-patches awaits moderator approval Your mail to 'Dri-patches' with the subject CVS Update: xc (branch: mesa-4-0-4-branch) Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRI Mailing list maintanence / maintaner
I have only been glancing at this thread, but basically it comes down to this - If the spam bothers you that much setup spam filtering on your personal machine and be done with it. We waste more time and bandwidth talking about what "should" be done (with the list) then actually doing what really "should" be done (with dri). Just my thoughts ... On Sat, 15 Feb 2003, Leif Delgass wrote: > On Sat, 15 Feb 2003, Mike A. Harris wrote: > > > On Fri, 14 Feb 2003, Leif Delgass wrote: > > > > >> I could do it, but I don't think it's a good idea to restrict those > > >> who are non-members of the list. Cross postings from the xfree86 lists > > >> are sometimes useful. > > >> > > >> Alan. > > > > > >What about dri-patches? It gets all the same spam that -devel and -users > > >do. I don't see any reason not to restrict posting to that list to > > >project members. Of course, there may be people with commit access that > > >aren't subscribed. Is there a way to restrict it to sourceforge accounts > > >rather than the subscriber list? > > > > Why not just have posts from non-members moderated? They would > > get held long enough for someone to look at them and go "ah, this > > is not spam", then accept the message for posting. Of course, > > that would mean a message would get held until a moderator could > > look at it. > > > > I do this on our xfree86-list, and it works well. I dunno if > > that would be something one of the list maintainers would want to > > do or not though. Just a suggestion nonetheless. > > > > On the other side of things, spamassassin rocks. It nails almost > > all of my spam. A good 93% to date anyway. > > I think spam filtering for dri-devel and dri-users would be a good > solution -- IMO, that would be better than moderation. For dri-patches, > the Reply-To is dri-devel. I'd rather have just commit messages and > nothing else on dri-patches. Any comments/replies to specific patches, or > posts dealing with CVS should go to dri-devel anyway. That's why I > suggested limiting just dri-patches to sourceforge addresses. > > -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration
On Sat, Feb 15, 2003 at 01:24:26PM -0600, D. Hageman wrote: >... We played around with using Screens and driver > names, but in the end we were looking at keying off the device identifier. > At this time I still believe that is the best thing to use, but we have > no way at this time of grabbing such information from inside a DRI driver. > > What I would like to do is add a field to the DRIInfoRec struct: > > char* cardIdentifier or char* configIdentifier > ... > > This option would set in the DRIScreenInit much like the busIdString is > set during initialization. Does anyone see any issues with this or does > anyone have any technical objections on why this shouldn't be done? I'm coming from a solaris driver background (and am actively working on a drm port to solaris) In solaris, it is much more common (practically required, really) that driver "instances" are bound to a particular piece of hardware, by the OS level driver loading proceedures. [This is because the OS is very rigid about deciding where to send interrupt notifications to] As such, instances of drm in solaris already come associated with a particular video card. I would like to see a model where, instead of the X server telling /dev/drm/card0, "You are bound to this card", the **drm** driver tells the X server, "I am associated with this card ". (here is the base address, here is the PCI id, etc, etc) I think this is a much cleaner overall design. After all, you dont open /dev/fbX and tell it, "I want you to be associated with this video card now..." --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRI Mailing list maintanence / maintaner
What about people getting the list as a digest? Also, the spam ends up in the mail archives. On Sat, 15 Feb 2003, D. Hageman wrote: > > I have only been glancing at this thread, but basically it comes down to > this - If the spam bothers you that much setup spam filtering on your > personal machine and be done with it. We waste more time and bandwidth > talking about what "should" be done (with the list) then actually doing > what really "should" be done (with dri). Just my thoughts ... > > > > On Sat, 15 Feb 2003, Leif Delgass wrote: > > > On Sat, 15 Feb 2003, Mike A. Harris wrote: > > > > > On Fri, 14 Feb 2003, Leif Delgass wrote: > > > > > > >> I could do it, but I don't think it's a good idea to restrict those > > > >> who are non-members of the list. Cross postings from the xfree86 lists > > > >> are sometimes useful. > > > >> > > > >> Alan. > > > > > > > >What about dri-patches? It gets all the same spam that -devel and -users > > > >do. I don't see any reason not to restrict posting to that list to > > > >project members. Of course, there may be people with commit access that > > > >aren't subscribed. Is there a way to restrict it to sourceforge accounts > > > >rather than the subscriber list? > > > > > > Why not just have posts from non-members moderated? They would > > > get held long enough for someone to look at them and go "ah, this > > > is not spam", then accept the message for posting. Of course, > > > that would mean a message would get held until a moderator could > > > look at it. > > > > > > I do this on our xfree86-list, and it works well. I dunno if > > > that would be something one of the list maintainers would want to > > > do or not though. Just a suggestion nonetheless. > > > > > > On the other side of things, spamassassin rocks. It nails almost > > > all of my spam. A good 93% to date anyway. > > > > I think spam filtering for dri-devel and dri-users would be a good > > solution -- IMO, that would be better than moderation. For dri-patches, > > the Reply-To is dri-devel. I'd rather have just commit messages and > > nothing else on dri-patches. Any comments/replies to specific patches, or > > posts dealing with CVS should go to dri-devel anyway. That's why I > > suggested limiting just dri-patches to sourceforge addresses. > > > > > > -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Horny-Married Women Await You1cR6U8
5509HYTi3-038kEHp0343ZAIO1-963kwgB1395UPuh9-001aCDl0273YfdP5-732pgQR0842KQtd7-217Qhl78 [Fwd: Married, Lonely, and home alone! Looking for a no-strings relationship ? How about a lonely, HOT, married woman? This site was started by a married woman, run by married women. They are for real, they are home alone, and are looking for FUN ! No strings, no commitments, just erotic fun ! Visit their website today http://magichand.hostyouradultwithus4free.com/users/happy/fhwam/ **IF THE ABOVE SITE IS BUSY, TRY THIS LINK** http://sexyadultpages.net/mblamy/index.htm WE KEEP OUR PROMISES! Unlike many, we DO clean our lists. If you don't want to be bothered with further messages from us, just simply send an email to: [EMAIL PROTECTED] with NoWivesForMe in the subject, or just touch the link below and send us a request e-mail. Please note: May take 7-10 business days to take effect. mailto:[EMAIL PROTECTED]?subject=NoWivesForMe 5509HYTi3-038kEHp0343ZAIO1-963kwgB1395UPuh9-001aCDl0273YfdP5-732pgQR0842KQtd7-217Qhl78 2156WyEF0-305CseF2189xhdh5-699mGjV2320Cl37 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
