[gentoo-amd64] unsubscribe

[gentoo-amd64] unsubscribe

[redspot]

unsubscribe

On Wed, Mar 21, 2012 at 5:03 AM,  <gentoo-amd64+help@lists.gentoo.org> wrote:
> Topics (messages 13110 through 13125):
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13110 - Frank Peters <frank.peters@comcast.net>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13111 - Mark Knecht <markknecht@gmail.com>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13112 - Frank Peters <frank.peters@comcast.net>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13113 - Cheng Renquan <crquan@gmail.com>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13114 - Mark Knecht <markknecht@gmail.com>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13115 - Mark Knecht <markknecht@gmail.com>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13116 - Frank Peters <frank.peters@comcast.net>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13117 - Mark Knecht <markknecht@gmail.com>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13118 - Paul Hartman <paul.hartman+gentoo@gmail.com>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13119 - Barry Schwartz <chemoelectric@chemoelectric.org>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13120 - Mark Knecht <markknecht@gmail.com>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13121 - Barry Schwartz <chemoelectric@chemoelectric.org>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13122 - Frank Peters <frank.peters@comcast.net>
>
> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>      13123 - Barry Schwartz <chemoelectric@chemoelectric.org>
>
> [gentoo-amd64] Re: Kernel-3.3.0 and Nvidia-drivers
>      13124 - Duncan <1i5t5.duncan@cox.net>
>      13125 - Duncan <1i5t5.duncan@cox.net>
>
>
>
> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
> the plain vanilla source.
>
> After rebooting to the command console, and before starting X, I needed
> to re-install the nvidia-driver module for the new kernel.  Doing
> "emerge nvidia-drivers" gave me the following error (the entire build log
> is attached):
>
>>>> Source prepared.
>>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>> Source configured.
>>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
> Preparing nvidia module
> make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>
> *** Unable to determine the target kernel version. ***
>
> make: *** [select_makefile] Error 1
> emake failed
> ERROR: x11-drivers/nvidia-drivers-295.20-r1 failed (compile phase):
>  Unable to emake HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS=-m elf_x86_64  IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux             SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>
> Call stack:
>    ebuild.sh, line   85:  Called src_compile
>  environment, line 3711:  Called linux-mod_src_compile
>  environment, line 2668:  Called die
> The specific snippet of code:
>              eval "emake HOSTCC=\"$(tc-getBUILD_CC)\"
>
>
> The first part of the build log (see attached file) indicates that the
> kernel source was correctly found (at /usr/src/linux), but for some
> reason the make process fails.
>
> Could this be due to some changes in the kernel-3.3.0 tree?
>
> Frank Peters
>
>
> On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters <frank.peters@comcast.net> wrote:
>> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
>> the plain vanilla source.
>>
> <SNIP>
>> The first part of the build log (see attached file) indicates that the
>> kernel source was correctly found (at /usr/src/linux), but for some
>> reason the make process fails.
>>
>> Could this be due to some changes in the kernel-3.3.0 tree?
>>
>> Frank Peters
>>
>
> Possibly this from Google will help?
>
> Good luck & post back,
> Mark
>
> On Mon, 19 Mar 2012 09:35:34 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>> Possibly this from Google will help?
>>
>
> Did you intend to include a link?  If so, it must have gotten
> lost somewhere.
>
> Frank Peters
>
>
> I have switched to nouveau driver, for over 1 year,
> using with gnome3 interface, no performance issue, and quite stable,
>
> enjoying every mainline kernel 3.0, 3.1, 3.2, 3.3, no building issue
>
>
> I think it's time for everyone to give up nvidia-drivers, the blob of binary
>
> On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters <frank.peters@comcast.net> wrote:
>> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
>> the plain vanilla source.
>>
>> After rebooting to the command console, and before starting X, I needed
>> to re-install the nvidia-driver module for the new kernel.  Doing
>> "emerge nvidia-drivers" gave me the following error (the entire build log
>> is attached):
>>
>>>>> Source prepared.
>>>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>>> Source configured.
>>>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>> Preparing nvidia module
>> make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>>
>> *** Unable to determine the target kernel version. ***
>
> On Mon, Mar 19, 2012 at 12:05 PM, Frank Peters <frank.peters@comcast.net> wrote:
>> On Mon, 19 Mar 2012 09:35:34 -0700
>> Mark Knecht <markknecht@gmail.com> wrote:
>>
>>>
>>> Possibly this from Google will help?
>>>
>>
>> Did you intend to include a link?  If so, it must have gotten
>> lost somewhere.
>>
>> Frank Peters
>>
>>
>
> Gadzooks, yes I did. Sorry!
>
> http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/
>
> To be clear, I have no idea if it will solve your exact problem. It
> didn't for all.
>
> My experience with nvidia is pretty good if you give them a couple of
> days, but very spotty on the first or second day a new kernel minor
> rev is released. Nominally I use this page:
>
> http://www.nvidia.com/Download/indexsg.aspx?lang=en-us
>
> and then search out my specific card to determine what _exact_ driver
> they want me to run. It almost always requires i run ~amd64.
>
> HTH,
> Mark
>
> On Mon, Mar 19, 2012 at 12:14 PM, Cheng Renquan <crquan@gmail.com> wrote:
>> I have switched to nouveau driver, for over 1 year,
>> using with gnome3 interface, no performance issue, and quite stable,
>>
>> enjoying every mainline kernel 3.0, 3.1, 3.2, 3.3, no building issue
>>
>>
>> I think it's time for everyone to give up nvidia-drivers, the blob of binary
>>
>
> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
> support all the CUDA stuff?
>
> Cheers,
> Mark
>
> On Mon, 19 Mar 2012 09:35:34 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>> Possibly this from Google will help?
>>
>
> OK, I think I've found the URL that you may have intended:
>
> http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/
>
> I followed the second fix that is described and now the nvidia-drivers
> emerge and work nicely with linux kernel-3.3.
>
> Thanks for the hint.
>
> There are changes to the kernel-3.3 tree that will have to addressed
> by the gentoo nvidia-drivers or other users will hit this problem
> as well.
>
> Frank Peters
>
>
> On Mon, Mar 19, 2012 at 12:30 PM, Frank Peters <frank.peters@comcast.net> wrote:
>> On Mon, 19 Mar 2012 09:35:34 -0700
>> Mark Knecht <markknecht@gmail.com> wrote:
>>
>>>
>>> Possibly this from Google will help?
>>>
>>
>> OK, I think I've found the URL that you may have intended:
>>
>> http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/
>>
>> I followed the second fix that is described and now the nvidia-drivers
>> emerge and work nicely with linux kernel-3.3.
>>
>> Thanks for the hint.
>>
>> There are changes to the kernel-3.3 tree that will have to addressed
>> by the gentoo nvidia-drivers or other users will hit this problem
>> as well.
>>
>> Frank Peters
>>
>>
>
> Glad you found it. That is the link I just sent along and good to know
> it helped a bit.
>
> As I said, on kernel revision number changes I ALWAYS wait a minimum
> of 3-5 days before trying to upgrade. nvidia always seems to need at
> least a few days to catch up with a new release, or that's been my
> experience in the past anyway.
>
> Cheers,
> Mark
>
> On Mon, Mar 19, 2012 at 3:08 PM, Mark Knecht <markknecht@gmail.com> wrote:
>>
>> As I said, on kernel revision number changes I ALWAYS wait a minimum
>> of 3-5 days before trying to upgrade. nvidia always seems to need at
>> least a few days to catch up with a new release, or that's been my
>> experience in the past anyway.
>
> Same here, nvidia-drivers and vmware-modules are why I usually wait
> until the .1 release on a new kernel series. :)
>
> Mark Knecht <markknecht@gmail.com> skribis:
>> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
>> support all the CUDA stuff?
>
> I think they may have reverse engineered CUDA, but whether it is
> implemented I don’t know, and I wouldn’t want to be the one to test
> it, either. :)
>
> I’m donating processor time with boinc and that’s good enough reason
> to use the binary driver if it gives me more processor to donate.
>
> (Waiting before installing anything new is painful, I know, because
> with Gentoo you always feel like you want it to be doing something, or
> at least that’s my experience. :) )
>
> On Mon, Mar 19, 2012 at 2:28 PM, Barry Schwartz
> <chemoelectric@chemoelectric.org> wrote:
>> Mark Knecht <markknecht@gmail.com> skribis:
>>> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
>>> support all the CUDA stuff?
>>
>> I think they may have reverse engineered CUDA, but whether it is
>> implemented I don’t know, and I wouldn’t want to be the one to test
>> it, either. :)
>>
>> I’m donating processor time with boinc and that’s good enough reason
>> to use the binary driver if it gives me more processor to donate.
>>
>> (Waiting before installing anything new is painful, I know, because
>> with Gentoo you always feel like you want it to be doing something, or
>> at least that’s my experience. :) )
>>
>
> I have no problem with you or anyone else running nouveau. None at all.
>
> I do have a problem with someone saying 'it's time for everyone to
> give up nvidia-drivers' without demonstrating they know the full
> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
> people who don't need anything other than basic X capabilities should
> consider running nouveau' I wouldn't have even chimed in.
>
> And thanks for running boinc. It's good of you and good for you.
>
> Cheers,
> Mark
>
> Mark Knecht <markknecht@gmail.com> skribis:
>> I do have a problem with someone saying 'it's time for everyone to
>> give up nvidia-drivers' without demonstrating they know the full
>> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
>> people who don't need anything other than basic X capabilities should
>> consider running nouveau' I wouldn't have even chimed in.
>
> Sage Notebook (sage-on-gentoo overlay) can use CUDA as well. I think
> you don't have to worry that nvidia-drivers would go away; in the
> worst case it would end up in a good overlay. That's unlikely IMO, and
> would mostly likely be if there were an established alternative
> implementation of CUDA.
>
> On Mon, 19 Mar 2012 14:40:34 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>> I have no problem with you or anyone else running nouveau. None at all.
>>
>> I do have a problem with someone saying 'it's time for everyone to
>> give up nvidia-drivers' without demonstrating they know the full
>> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
>> people who don't need anything other than basic X capabilities should
>> consider running nouveau' I wouldn't have even chimed in.
>>
>
> I think the main complaint is that the Nvidia drivers are closed
> binary blobs while Nouveau is an attempt to create an entirely
> open source driver.  The spirit of free software demands that we
> support these open initiatives.
>
> Actually, until recently, I was very happy using the legacy open
> source xorg nvidia driver known simply as as "nv."  It is still
> available in Gentoo as x11-drivers/xf86-video-nv.
>
> Since I do not do gaming or other intensive graphic activities,
> I could get by nicely with just nv.  However, the nv driver does
> not seem to support the latest hardware too well.  On one of
> my machines I have a card based on Nvidia GeForce 210.  Although
> the nv driver works with this card, it does not enable the Xv
> extension and consequently the graphic response is poor.
>
> On older cards nv does work quite well for ordinary purposes.
>
> Frank Peters
>
>
> Frank Peters <frank.peters@comcast.net> skribis:
>> I think the main complaint is that the Nvidia drivers are closed
>> binary blobs while Nouveau is an attempt to create an entirely
>> open source driver.
>
> Unfortunately the nvidia drivers are needed not only for graphics but
> also to use the GPU for scientific calculations, including for
> donating processor time to medical research, for instance.
>
>
> Frank Peters posted on Tue, 20 Mar 2012 00:03:06 -0400 as excerpted:
>
>> Actually, until recently, I was very happy using the legacy open source
>> xorg nvidia driver known simply as as "nv."  It is still available in
>> Gentoo as x11-drivers/xf86-video-nv.
>>
>> Since I do not do gaming or other intensive graphic activities, I could
>> get by nicely with just nv.  However, the nv driver does not seem to
>> support the latest hardware too well.
>
> FWIW, the old nv driver is legacy, now, and won't be supporting new
> hardware.  AFAIK older hardware should be switching as well, for support
> with current software, as nv won't be updated for that any longer, either.
>
> The same thing happened to it as happened to nvidia's proprietary network
> driver some years ago; pretty much everyone involved, including the
> distros that used to ship nv and nvidia itself, seems to have recognized
> that the reverse-engineered work is now better than nvidia's basic
> freedomware stub driver, nv, and nouveau has officially taken its place.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
> Barry Schwartz posted on Tue, 20 Mar 2012 01:20:13 -0500 as excerpted:
>
>> Unfortunately the nvidia drivers are needed not only for graphics but
>> also to use the GPU for scientific calculations, including for donating
>> processor time to medical research, for instance.
>
> My donation ends where their disrespect for human freedom begins.  (Over
> a decade ago, back on MS, I used to run distributed.net.  However, they
> don't have a freedomware client, or at least didn't back then, and while
> I understand the reasons why -- someone cheating and saying they did the
> work when they didn't, just to get the stats -- that didn't change the
> fact that I wasn't going to run servantware.  But as they say, YMMV.)
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>

Re: [gentoo-amd64] unsubscribe

[Dale]

redspot wrote:
> unsubscribe
> 


Nope.  It ain't going to happen.  Sorry.  This is Hotel California so
you can't leave.  OK.  Stop laughing.  This may help:

Send email to gentoo-amd64+unsubscribe@lists.gentoo.org and then wait.
You should get a confirmation that you want to leave us poor lonesome
folks all alone.  If you really want to leave us here all alone, just
hit reply, don't change anything and hit send.  You will get one more
confirmation email.  After that, we will just all sit here alone without
you.

I hope you think about the Hotel California song all day long.  LOL

Dale

:-)  :-)


-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-amd64] unsubscribe

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Mar 22, 2012 7:57 PM, "Dale" <rdalek1967@gmail.com> wrote:
>
> redspot wrote:
> > unsubscribe
> >
>
>
> Nope.  It ain't going to happen.  Sorry.  This is Hotel California so
> you can't leave.  OK.  Stop laughing.  This may help:
>
> Send email to gentoo-amd64+unsubscribe@lists.gentoo.org and then wait.
> You should get a confirmation that you want to leave us poor lonesome
> folks all alone.  If you really want to leave us here all alone, just
> hit reply, don't change anything and hit send.  You will get one more
> confirmation email.  After that, we will just all sit here alone without
> you.
>
> I hope you think about the Hotel California song all day long.  LOL
>
> Dale
>
> :-)  :-)
>
>
> --
> I am only responsible for what I said ... Not for what you understood or
> how you interpreted my words!
>
> Miss the compile output?  Hint:
> EMERGE_DEFAULT_OPTS="--quiet-build=n"
>

for some bizarre reason I lost The Game because of your email :p

Alex | wired

[-- Attachment #2: Type: text/html, Size: 1387 bytes --]

Re: [gentoo-amd64] unsubscribe

[Dale]

Alex Alexander wrote:
> On Mar 22, 2012 7:57 PM, "Dale" <rdalek1967@gmail.com
> <mailto:rdalek1967@gmail.com>> wrote:
>>
>> redspot wrote:
>> > unsubscribe
>> >
>>
>>
>> Nope.  It ain't going to happen.  Sorry.  This is Hotel California so
>> you can't leave.  OK.  Stop laughing.  This may help:
>>
>> Send email to gentoo-amd64+unsubscribe@lists.gentoo.org
> <mailto:gentoo-amd64%2Bunsubscribe@lists.gentoo.org> and then wait.
>> You should get a confirmation that you want to leave us poor lonesome
>> folks all alone.  If you really want to leave us here all alone, just
>> hit reply, don't change anything and hit send.  You will get one more
>> confirmation email.  After that, we will just all sit here alone without
>> you.
>>
>> I hope you think about the Hotel California song all day long.  LOL
>>
>> Dale
>>
>> :-)  :-)
>>
>>
>> --
>> I am only responsible for what I said ... Not for what you understood or
>> how you interpreted my words!
>>
>> Miss the compile output?  Hint:
>> EMERGE_DEFAULT_OPTS="--quiet-build=n"
>>
> 
> for some bizarre reason I lost The Game because of your email :p
> 
> Alex | wired
> 


Was you laughing or singing the song to yourself?

I try not to be mean about it.  Most mailing lists don't work like
Gentoos so people just need a little nudge.  ;-)

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[gentoo-amd64] Re: unsubscribe

[Duncan]

Dale posted on Thu, 22 Mar 2012 13:37:32 -0500 as excerpted:

> I try not to be mean about it.  Most mailing lists don't work like
> Gentoos so people just need a little nudge.  ;-)

FWIW, gmane filters the unsubscribes, but obviously not the followups... 
which is OK, because they're often entertaining.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: unsubscribe

[kmcdona1]

> FWIW, gmane filters the unsubscribes, but obviously not the followups...
> which is OK, because they're often entertaining.  =:^)
>

While I certainly don't mean any offense...

I used to LOVE reading the 2-page long "how to unsubscribe" posts that 
would come along.
Talk about entertaining! I still remember there was on that had me in fits!

Re: [gentoo-amd64] Re: unsubscribe

[Craig Lewis]

For the love of god
Please unsubscribe

Sent from my iPhone

On Mar 22, 2012, at 8:08 PM, kmcdona1 <kmcdona1@rochester.rr.com> wrote:

> 
>> FWIW, gmane filters the unsubscribes, but obviously not the followups...
>> which is OK, because they're often entertaining.  =:^)
>> 
> 
> While I certainly don't mean any offense...
> 
> I used to LOVE reading the 2-page long "how to unsubscribe" posts that would come along.
> Talk about entertaining! I still remember there was on that had me in fits!
> 
> 

Re: [gentoo-amd64] Re: unsubscribe

[Benny Pedersen]

Den 2012-03-23 04:16, Craig Lewis skrev:
> For the love of god
> Please unsubscribe
>
> Sent from my iPhone

get a nokia, most selling right now is lumia 800 :-)

stats just dont say how many users keep it

Re: [gentoo-amd64] unsubscribe

[Zhu Sha Zang]

No, you can't.

Not this way, try something like sending a e-mail to:

gentoo-amd64+unsubscribe@lists.gentoo.org


Good Luck

On 22-03-2012 13:42, redspot wrote:
> unsubscribe
>
> On Wed, Mar 21, 2012 at 5:03 AM,<gentoo-amd64+help@lists.gentoo.org>  wrote:
>    
>> Topics (messages 13110 through 13125):
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13110 - Frank Peters<frank.peters@comcast.net>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13111 - Mark Knecht<markknecht@gmail.com>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13112 - Frank Peters<frank.peters@comcast.net>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13113 - Cheng Renquan<crquan@gmail.com>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13114 - Mark Knecht<markknecht@gmail.com>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13115 - Mark Knecht<markknecht@gmail.com>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13116 - Frank Peters<frank.peters@comcast.net>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13117 - Mark Knecht<markknecht@gmail.com>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13118 - Paul Hartman<paul.hartman+gentoo@gmail.com>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13119 - Barry Schwartz<chemoelectric@chemoelectric.org>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13120 - Mark Knecht<markknecht@gmail.com>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13121 - Barry Schwartz<chemoelectric@chemoelectric.org>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13122 - Frank Peters<frank.peters@comcast.net>
>>
>> [gentoo-amd64] Kernel-3.3.0 and Nvidia-drivers
>>       13123 - Barry Schwartz<chemoelectric@chemoelectric.org>
>>
>> [gentoo-amd64] Re: Kernel-3.3.0 and Nvidia-drivers
>>       13124 - Duncan<1i5t5.duncan@cox.net>
>>       13125 - Duncan<1i5t5.duncan@cox.net>
>>
>>
>>
>> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
>> the plain vanilla source.
>>
>> After rebooting to the command console, and before starting X, I needed
>> to re-install the nvidia-driver module for the new kernel.  Doing
>> "emerge nvidia-drivers" gave me the following error (the entire build log
>> is attached):
>>
>>      
>>>>> Source prepared.
>>>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>>> Source configured.
>>>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>>>            
>> Preparing nvidia module
>> make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>>
>> *** Unable to determine the target kernel version. ***
>>
>> make: *** [select_makefile] Error 1
>> emake failed
>> ERROR: x11-drivers/nvidia-drivers-295.20-r1 failed (compile phase):
>>   Unable to emake HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS=-m elf_x86_64  IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux             SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>>
>> Call stack:
>>     ebuild.sh, line   85:  Called src_compile
>>   environment, line 3711:  Called linux-mod_src_compile
>>   environment, line 2668:  Called die
>> The specific snippet of code:
>>               eval "emake HOSTCC=\"$(tc-getBUILD_CC)\"
>>
>>
>> The first part of the build log (see attached file) indicates that the
>> kernel source was correctly found (at /usr/src/linux), but for some
>> reason the make process fails.
>>
>> Could this be due to some changes in the kernel-3.3.0 tree?
>>
>> Frank Peters
>>
>>
>> On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters<frank.peters@comcast.net>  wrote:
>>      
>>> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
>>> the plain vanilla source.
>>>
>>>        
>> <SNIP>
>>      
>>> The first part of the build log (see attached file) indicates that the
>>> kernel source was correctly found (at /usr/src/linux), but for some
>>> reason the make process fails.
>>>
>>> Could this be due to some changes in the kernel-3.3.0 tree?
>>>
>>> Frank Peters
>>>
>>>        
>> Possibly this from Google will help?
>>
>> Good luck&  post back,
>> Mark
>>
>> On Mon, 19 Mar 2012 09:35:34 -0700
>> Mark Knecht<markknecht@gmail.com>  wrote:
>>
>>      
>>> Possibly this from Google will help?
>>>
>>>        
>> Did you intend to include a link?  If so, it must have gotten
>> lost somewhere.
>>
>> Frank Peters
>>
>>
>> I have switched to nouveau driver, for over 1 year,
>> using with gnome3 interface, no performance issue, and quite stable,
>>
>> enjoying every mainline kernel 3.0, 3.1, 3.2, 3.3, no building issue
>>
>>
>> I think it's time for everyone to give up nvidia-drivers, the blob of binary
>>
>> On Mon, Mar 19, 2012 at 9:12 AM, Frank Peters<frank.peters@comcast.net>  wrote:
>>      
>>> Linux-3.3.0 is released and, as is my usual habit, I downloaded and compiled
>>> the plain vanilla source.
>>>
>>> After rebooting to the command console, and before starting X, I needed
>>> to re-install the nvidia-driver module for the new kernel.  Doing
>>> "emerge nvidia-drivers" gave me the following error (the entire build log
>>> is attached):
>>>
>>>        
>>>>>> Source prepared.
>>>>>> Configuring source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>>>> Source configured.
>>>>>> Compiling source in /tmp/portage-acc/tmp/portage/x11-drivers/nvidia-drivers-295.20-r1/work ...
>>>>>>              
>>> Preparing nvidia module
>>> make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.0/build CC=x86_64-pc-linux-gnu-gcc clean module
>>>
>>> *** Unable to determine the target kernel version. ***
>>>        
>> On Mon, Mar 19, 2012 at 12:05 PM, Frank Peters<frank.peters@comcast.net>  wrote:
>>      
>>> On Mon, 19 Mar 2012 09:35:34 -0700
>>> Mark Knecht<markknecht@gmail.com>  wrote:
>>>
>>>        
>>>> Possibly this from Google will help?
>>>>
>>>>          
>>> Did you intend to include a link?  If so, it must have gotten
>>> lost somewhere.
>>>
>>> Frank Peters
>>>
>>>
>>>        
>> Gadzooks, yes I did. Sorry!
>>
>> http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/
>>
>> To be clear, I have no idea if it will solve your exact problem. It
>> didn't for all.
>>
>> My experience with nvidia is pretty good if you give them a couple of
>> days, but very spotty on the first or second day a new kernel minor
>> rev is released. Nominally I use this page:
>>
>> http://www.nvidia.com/Download/indexsg.aspx?lang=en-us
>>
>> and then search out my specific card to determine what _exact_ driver
>> they want me to run. It almost always requires i run ~amd64.
>>
>> HTH,
>> Mark
>>
>> On Mon, Mar 19, 2012 at 12:14 PM, Cheng Renquan<crquan@gmail.com>  wrote:
>>      
>>> I have switched to nouveau driver, for over 1 year,
>>> using with gnome3 interface, no performance issue, and quite stable,
>>>
>>> enjoying every mainline kernel 3.0, 3.1, 3.2, 3.3, no building issue
>>>
>>>
>>> I think it's time for everyone to give up nvidia-drivers, the blob of binary
>>>
>>>        
>> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
>> support all the CUDA stuff?
>>
>> Cheers,
>> Mark
>>
>> On Mon, 19 Mar 2012 09:35:34 -0700
>> Mark Knecht<markknecht@gmail.com>  wrote:
>>
>>      
>>> Possibly this from Google will help?
>>>
>>>        
>> OK, I think I've found the URL that you may have intended:
>>
>> http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/
>>
>> I followed the second fix that is described and now the nvidia-drivers
>> emerge and work nicely with linux kernel-3.3.
>>
>> Thanks for the hint.
>>
>> There are changes to the kernel-3.3 tree that will have to addressed
>> by the gentoo nvidia-drivers or other users will hit this problem
>> as well.
>>
>> Frank Peters
>>
>>
>> On Mon, Mar 19, 2012 at 12:30 PM, Frank Peters<frank.peters@comcast.net>  wrote:
>>      
>>> On Mon, 19 Mar 2012 09:35:34 -0700
>>> Mark Knecht<markknecht@gmail.com>  wrote:
>>>
>>>        
>>>> Possibly this from Google will help?
>>>>
>>>>          
>>> OK, I think I've found the URL that you may have intended:
>>>
>>> http://weltall.heliohost.org/wordpress/2012/01/20/linux-kernel-3-3-rc1-and-nvidia-drivers/
>>>
>>> I followed the second fix that is described and now the nvidia-drivers
>>> emerge and work nicely with linux kernel-3.3.
>>>
>>> Thanks for the hint.
>>>
>>> There are changes to the kernel-3.3 tree that will have to addressed
>>> by the gentoo nvidia-drivers or other users will hit this problem
>>> as well.
>>>
>>> Frank Peters
>>>
>>>
>>>        
>> Glad you found it. That is the link I just sent along and good to know
>> it helped a bit.
>>
>> As I said, on kernel revision number changes I ALWAYS wait a minimum
>> of 3-5 days before trying to upgrade. nvidia always seems to need at
>> least a few days to catch up with a new release, or that's been my
>> experience in the past anyway.
>>
>> Cheers,
>> Mark
>>
>> On Mon, Mar 19, 2012 at 3:08 PM, Mark Knecht<markknecht@gmail.com>  wrote:
>>      
>>> As I said, on kernel revision number changes I ALWAYS wait a minimum
>>> of 3-5 days before trying to upgrade. nvidia always seems to need at
>>> least a few days to catch up with a new release, or that's been my
>>> experience in the past anyway.
>>>        
>> Same here, nvidia-drivers and vmware-modules are why I usually wait
>> until the .1 release on a new kernel series. :)
>>
>> Mark Knecht<markknecht@gmail.com>  skribis:
>>      
>>> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
>>> support all the CUDA stuff?
>>>        
>> I think they may have reverse engineered CUDA, but whether it is
>> implemented I don’t know, and I wouldn’t want to be the one to test
>> it, either. :)
>>
>> I’m donating processor time with boinc and that’s good enough reason
>> to use the binary driver if it gives me more processor to donate.
>>
>> (Waiting before installing anything new is painful, I know, because
>> with Gentoo you always feel like you want it to be doing something, or
>> at least that’s my experience. :) )
>>
>> On Mon, Mar 19, 2012 at 2:28 PM, Barry Schwartz
>> <chemoelectric@chemoelectric.org>  wrote:
>>      
>>> Mark Knecht<markknecht@gmail.com>  skribis:
>>>        
>>>> And how would one use CUDA if we gave up nvidia-drivers? Does nouveau
>>>> support all the CUDA stuff?
>>>>          
>>> I think they may have reverse engineered CUDA, but whether it is
>>> implemented I don’t know, and I wouldn’t want to be the one to test
>>> it, either. :)
>>>
>>> I’m donating processor time with boinc and that’s good enough reason
>>> to use the binary driver if it gives me more processor to donate.
>>>
>>> (Waiting before installing anything new is painful, I know, because
>>> with Gentoo you always feel like you want it to be doing something, or
>>> at least that’s my experience. :) )
>>>
>>>        
>> I have no problem with you or anyone else running nouveau. None at all.
>>
>> I do have a problem with someone saying 'it's time for everyone to
>> give up nvidia-drivers' without demonstrating they know the full
>> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
>> people who don't need anything other than basic X capabilities should
>> consider running nouveau' I wouldn't have even chimed in.
>>
>> And thanks for running boinc. It's good of you and good for you.
>>
>> Cheers,
>> Mark
>>
>> Mark Knecht<markknecht@gmail.com>  skribis:
>>      
>>> I do have a problem with someone saying 'it's time for everyone to
>>> give up nvidia-drivers' without demonstrating they know the full
>>> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
>>> people who don't need anything other than basic X capabilities should
>>> consider running nouveau' I wouldn't have even chimed in.
>>>        
>> Sage Notebook (sage-on-gentoo overlay) can use CUDA as well. I think
>> you don't have to worry that nvidia-drivers would go away; in the
>> worst case it would end up in a good overlay. That's unlikely IMO, and
>> would mostly likely be if there were an established alternative
>> implementation of CUDA.
>>
>> On Mon, 19 Mar 2012 14:40:34 -0700
>> Mark Knecht<markknecht@gmail.com>  wrote:
>>
>>      
>>> I have no problem with you or anyone else running nouveau. None at all.
>>>
>>> I do have a problem with someone saying 'it's time for everyone to
>>> give up nvidia-drivers' without demonstrating they know the full
>>> impact of what they are suggesting. Had Cheng Renquan suggest 'Maybe
>>> people who don't need anything other than basic X capabilities should
>>> consider running nouveau' I wouldn't have even chimed in.
>>>
>>>        
>> I think the main complaint is that the Nvidia drivers are closed
>> binary blobs while Nouveau is an attempt to create an entirely
>> open source driver.  The spirit of free software demands that we
>> support these open initiatives.
>>
>> Actually, until recently, I was very happy using the legacy open
>> source xorg nvidia driver known simply as as "nv."  It is still
>> available in Gentoo as x11-drivers/xf86-video-nv.
>>
>> Since I do not do gaming or other intensive graphic activities,
>> I could get by nicely with just nv.  However, the nv driver does
>> not seem to support the latest hardware too well.  On one of
>> my machines I have a card based on Nvidia GeForce 210.  Although
>> the nv driver works with this card, it does not enable the Xv
>> extension and consequently the graphic response is poor.
>>
>> On older cards nv does work quite well for ordinary purposes.
>>
>> Frank Peters
>>
>>
>> Frank Peters<frank.peters@comcast.net>  skribis:
>>      
>>> I think the main complaint is that the Nvidia drivers are closed
>>> binary blobs while Nouveau is an attempt to create an entirely
>>> open source driver.
>>>        
>> Unfortunately the nvidia drivers are needed not only for graphics but
>> also to use the GPU for scientific calculations, including for
>> donating processor time to medical research, for instance.
>>
>>
>> Frank Peters posted on Tue, 20 Mar 2012 00:03:06 -0400 as excerpted:
>>
>>      
>>> Actually, until recently, I was very happy using the legacy open source
>>> xorg nvidia driver known simply as as "nv."  It is still available in
>>> Gentoo as x11-drivers/xf86-video-nv.
>>>
>>> Since I do not do gaming or other intensive graphic activities, I could
>>> get by nicely with just nv.  However, the nv driver does not seem to
>>> support the latest hardware too well.
>>>        
>> FWIW, the old nv driver is legacy, now, and won't be supporting new
>> hardware.  AFAIK older hardware should be switching as well, for support
>> with current software, as nv won't be updated for that any longer, either.
>>
>> The same thing happened to it as happened to nvidia's proprietary network
>> driver some years ago; pretty much everyone involved, including the
>> distros that used to ship nv and nvidia itself, seems to have recognized
>> that the reverse-engineered work is now better than nvidia's basic
>> freedomware stub driver, nv, and nouveau has officially taken its place.
>>
>> --
>> Duncan - List replies preferred.   No HTML msgs.
>> "Every nonfree program has a lord, a master --
>> and if you use the program, he is your master."  Richard Stallman
>>
>>
>> Barry Schwartz posted on Tue, 20 Mar 2012 01:20:13 -0500 as excerpted:
>>
>>      
>>> Unfortunately the nvidia drivers are needed not only for graphics but
>>> also to use the GPU for scientific calculations, including for donating
>>> processor time to medical research, for instance.
>>>        
>> My donation ends where their disrespect for human freedom begins.  (Over
>> a decade ago, back on MS, I used to run distributed.net.  However, they
>> don't have a freedomware client, or at least didn't back then, and while
>> I understand the reasons why -- someone cheating and saying they did the
>> work when they didn't, just to get the stats -- that didn't change the
>> fact that I wasn't going to run servantware.  But as they say, YMMV.)
>>
>> --
>> Duncan - List replies preferred.   No HTML msgs.
>> "Every nonfree program has a lord, a master --
>> and if you use the program, he is your master."  Richard Stallman
>>
>>
>>      
>
>    

[gentoo-amd64] Possible Math Problem - Request For Verification

[Frank Peters]

[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]

Hello,

Believe it or not, at the very beginning, Linux/GNU had some math problems.
In particular, it would do somewhat poorly on various floating point tests
that are available on-line.  Because I do mathematical work on my machine,
I used to regularly evaluate my software using these tests.

However, for the past several years Linux/GNU has gotten nearly perfect
scores on these same tests and it seemed that glibc and/or gcc had finally
gotten the math code right.  As a result of this, I stopped my regular
evaluations of the software.

Just recently I decided to run these tests again.  I expected to see the
same nearly perfect scores but, to my surprise, a failure occurred in the
area of complex number operations.  This may not be a very serious failure,
but it was not present during prior tests and thus it should not be present
now.

Possibly a fault has crept in somewhere either in glibc or gcc.  Because
I had stopped my regular testing I can't relate the failure to any specific
version change of either package.

I need to request a verification from any Gentoo users.  All that needs to
be done is run a straightforward software test.

The software is called UCBTEST and is described at http://www.netlib.org/fp/

The source code, however, is ancient Unix (1995) code and must be patched.
I have created a patched tarball that can run on recent Linux.  This file
is attached as ucbtest.tar.bz2

If one is accustomed to modern GUI software, this code is a mess, but it is
rather straightforward to implement.  Here are the steps:

1) Create a directory somewhere, e.g. /tmp/fp-test

2) Unpack the tarball into this directory.

3) Change into the /tmp/fp-test directory

4) Modify the ucbREADME/linux.sh file as follows:

Line 10 -- specify a full path for the results directory -- all test results
will be stored here -- e.g. /tmp/fp-test-results

Line 11 -- specify the full path to the Unix time program -- ucbtest won't run
without time -- for Gentoo just "emerge time" and the path will be "/usr/bin/time"

Line 17 -- specify the full path to the test directory -- same as in step #1

Line 36 -- enter your CFLAGS here

That's it as far as configuration.  Now, from the top directory of the source
just execute: 

ucbREADME/linux.sh

The code will take several minutes to compile, execute, and complete.  While
the test is running it will spit out its progress to stdout.  Upon completion
a brief summary is given:

UCBFAIL indicates problems!
/tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic 
/tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double 
/tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double 
/tmp/fp-test-results/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests completed
/tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic 

only 11 out of 14 show UCBPASS!


There are expected failures in the trigonometric tests since trigonometric
performance is not specified in IEEE754/854.  The failure in powd (double power
function) is also expected.  But everything else should have passed.

In my case, the new failure occurs in the cabsd test, which is the absolute
value for complex numbers.  I have never seen this error previously and
it may possibly indicate some problem with either glibc or gcc. 

The results directory is also a mess (someone should really clean this code up).
In the results directory (see step #4) all detailed test results are contained
in the *.output files.

Anyway, if anyone wants to try this test, the steps have been outlined.
In spite of the messiness, the procedure is really quite simple, and the
ucbtest is a very good test of floating point performance.

Frank Peters


[-- Attachment #2: ucbtest.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 520301 bytes --]

Re: [gentoo-amd64] unsubscribe

[Dale]

Piotr Hosowicz wrote:
> unsubscribe
>
>

NO !!!  You can't leave.  :-P

List-Unsubscribe:<mailto:gentoo-amd64+unsubscribe@lists.gentoo.org>

That may help tho.  Just do like you did when you checked in.  We MAY let you check out.  lol

Dale

:-)  :-)

Re: [gentoo-amd64] unsubscribe

[Lie Ryan]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

2011/6/27 Dale <rdalek1967@gmail.com>

> Piotr Hosowicz wrote:
>
>> unsubscribe
>>
>>
>>
> NO !!!  You can't leave.  :-P
>
> List-Unsubscribe:<mailto:gento**o-amd64+unsubscribe@lists.**gentoo.org<gentoo-amd64%2Bunsubscribe@lists.gentoo.org>
> >
>
> That may help tho.  Just do like you did when you checked in.  We MAY let
> you check out.  lol
>
>
Anyone noticed that this list have a higher than normal tendency to bully
those who tried to unsubscribe and failed?

[-- Attachment #2: Type: text/html, Size: 919 bytes --]

Re: [gentoo-amd64] unsubscribe

[Volker Armin Hemmann]

On Monday 27 June 2011 03:26:59 Lie Ryan wrote:
> 2011/6/27 Dale <rdalek1967@gmail.com>
> 
> > Piotr Hosowicz wrote:
> >> unsubscribe
> > 
> > NO !!!  You can't leave.  :-P
> > 
> > List-Unsubscribe:<mailto:gento**o-amd64+unsubscribe@lists.**gentoo.org<g
> > entoo-amd64%2Bunsubscribe@lists.gentoo.org>
> > 
> > 
> > That may help tho.  Just do like you did when you checked in.  We MAY
> > let
> > you check out.  lol
> 
> Anyone noticed that this list have a higher than normal tendency to bully
> those who tried to unsubscribe and failed?

bully? No, make fun of people failing to follow basic instructions? Maybe. But 
not more than gentoo-user...

-- 
#163933

[gentoo-amd64] Re: unsubscribe

[Duncan]

Volker Armin Hemmann posted on Sun, 26 Jun 2011 19:31:27 +0200 as
excerpted:

> On Monday 27 June 2011 03:26:59 Lie Ryan wrote:

>> Anyone noticed that this list have a higher than normal tendency to
>> bully those who tried to unsubscribe and failed?
> 
> bully? No, make fun of people failing to follow basic instructions?
> Maybe. But not more than gentoo-user...

Exactly.

1) Instructions are in the headers of every post.  A simple view-headers 
is all that's required.

2) Instructions are available at the same place they signed up, using a 
very similar procedure.  It's not rocket science.  If they could find and 
had the intelligence to subscribe (and even verify their subscription, 
the list IS double-opt-in, after all), unless they just had a stroke or 
some such, they should still be able to find and have the intelligence to 
unsubscribe.

3) Simple reason says that if it's a gentoo list, going to the gentoo 
site and looking for the mailing list info would be an appropriate way to 
figure out how to unsubscribe.  Even if they somehow lost all memory of 
the subscription process, simple reason remains the same, and indeed, the 
gentoo mailing list info can be found on the site exactly as one could 
expect.

4) In this case, all they had to do was read the thread from a couple 
days ago, on the same subject.  Simple netiquette has always expected 
that people follow a list or newsgroup for a bit before they ask what may 
well be a FAQ, and the same arguably applies here.  They can't even read 
the existing thread from the last person who apparently had a stroke or 
something after he subscribed, losing all memory of the process, as well 
as the basic intelligence to reason where he might find unsubscribe 
instructions.

So what's up with these people, anyway?  Do they simply not even /care/ 
if they do it right?  They obviously have the ability to follow that 
level of instructions or they'd not be subscribed in the first place, and 
it's unlikely ALL of them are stroke victims!  Are they deliberately 
TRYING to look dumb?  Maybe they just smoked too many mind altering drugs 
and it's now /permanently/ altered?

So yeah, they do get a bit of fun poked at them.  But along with that 
fun, they usually get the unsubscribe help they're apparently too dumb to 
find any of the /normal/ ways, or simply don't /care/ if they're 
bothering people by not following the easily available instructions. And 
if they don't care if they bother other subscribers, why should other 
subscribers care about poking a little fun their way even as they point 
them at the door? <shrug>

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-amd64] unsubscribe

[Daniele Salatti]

[gentoo-amd64] Re: unsubscribe

[Francesco Talamona]

On Friday 22 August 2008, Daniele Salatti wrote:

From your mail headers:

Date: Fri, 22 Aug 2008 15:24:41 +0200
From: Daniele Salatti <danielesalatti@gmail.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
Precedence: bulk
List-Post: <mailto:gentoo-amd64@lists.gentoo.org>
List-Help: <mailto:gentoo-amd64+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-amd64+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-amd64+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-amd64.gentoo.org>
X-BeenThere: gentoo-amd64@lists.gentoo.org
Reply-to: gentoo-amd64@lists.gentoo.org

List-Unsubscribe: <mailto:gentoo-amd64+unsubscribe@lists.gentoo.org>
Ciao
	FT
-- 
Linux Version 2.6.26-gentoo-r1, Compiled #2 PREEMPT Fri Aug 15 09:40:53 
CEST 2008
One 1GHz AMD Athlon 64 Processor, 2GB RAM, 2004.05 Bogomips Total
aemaeth