Re: math/R eats up all.
- Original Message - From: NAKATA Maho [EMAIL PROTECTED] Date: Tuesday, January 23, 2007 7:54 pm Subject: Re: math/R eats up all. To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] How about using math/atlas-devel ? or if this is a bug of gfortran how about math/atlas with WITH_OPTIMIZED_FLAGS or WITHOUT_OPTIMIZED_FLAGS ? just tries. -- NAKATA, Maho ([EMAIL PROTECTED]) Thanks for the suggestions. I will try them. I updated math/atlas to math/atlas-devel successfully. Building math/R hangs in the same way with math/atlas-devel as with math/atlas. So, next, I will try your suggestions to test options for gfortran. Thanks, Rick Voland [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SpamAssassin (spamd) eating a lot of CPU....
Forrest Aldrich wrote: Since a recent update of Spamassassin to: PORTVERSION=3.1.7 PORTREVISION= 3 I've noticed that each email that gets scanned causes the process to eat up 80+% of the CPU time, and it's slow... I'm not really sure what changed. Likewise, when I start it up for the first time, I see: [ top output ] 49106 root1 1060 290M 267M RUN0 0:17 *98.52%* perl5.8.8 I have a Dell system here, and it cranks up the fan every time a message comes in now, with the recent spamd. Curious if anyone else has had these issues, etc. The system is not otherwise active, so I'm certain it's not a resource issue (or constraint thereof). Thanks. We had this issue. But we assumed that it was an increase in spam on the internet (perhaps recent MS worms). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: vmware-tools3-3.1.1.1790
Hi, Could you please help me out I'm a new user of VMWare? VMware Workstation 5.5.3 Host OS WinXP SP2. Toshiba Laptop P4, ATI Radeon 9000 Graphics Card. RAM for VMware allocated 512 MB. DVD-RW/CDROM-RW Combo. I install and update Fedora Core6 in VMware Workstation5.5.3 gest OS WinXP successfully. I could not see any virtual CD or DVD ROM Drive in my Window XP explorer. But a DVD drive which works fine in XP and VMware workstation. When I click Install VMware Tools from Menue Bar in VMware Workstation it does not start installation automatically. Then I click Computer Icon placed on my desktop in VMware workstation and click on CDROM Icon. It open Folder root/media/VMware Tools Where I can see setup.exe and other files. When I click on setup.exe or VMware Tools.msi I got this message. Couldn't display /media/VMware Tools/setup.exe. I tried to run From my WInXP start- Run- G:/setup/setup.exe I got messeage Please insert disk into drive G: Where G is DVD drive letter. Here I uncompresserd VMware Tools ISO image file in WinXP location is C:\Program Files\VMware\VMware Workstation\VMwareTools\setup.exe When I run Setup.exe from here it started and then I got this message The VMware Tools should only be installed inside a virtula machine. Thanks MIr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SpamAssassin (spamd) eating a lot of CPU....
On Tue, Jan 23, 2007 at 11:02:34PM -0500, Forrest Aldrich wrote: Since a recent update of Spamassassin to: PORTVERSION=3.1.7 PORTREVISION= 3 I've noticed that each email that gets scanned causes the process to eat up 80+% of the CPU time, and it's slow... I'm not really sure what changed. Likewise, when I start it up for the first time, I see: [ top output ] 49106 root1 1060 290M 267M RUN0 0:17 *98.52%* perl5.8.8 I have a Dell system here, and it cranks up the fan every time a message comes in now, with the recent spamd. Curious if anyone else has had these issues, etc. The system is not otherwise active, so I'm certain it's not a resource issue (or constraint thereof). I've seen this happen before, although with older SpamAssassin releases (though I have no proof the problem got fixed at all). At that time, we were using mail/spamass-rules as well. Since, we've removed using mail/spamass-rules, and haven't seen this problem. Possibly there's some SpamAssassin rule which causes the daemon to spin when certain regexs are matched. Not sure. Ours (note the much smaller memory footprint): root 58179 2.2 5.2 28088 27084 ?? S 3:58am 1:44.79 spamd child (perl5.8.8) root 65228 0.0 5.0 27172 26128 ?? S 5:58am 0:23.17 spamd child (perl5.8.8) root 313 0.0 4.3 23812 22176 ?? Ss2Jan07 11:40.79 /usr/local/bin/spamd -c -d -r /var/run/spamd/spamd.pid (perl5.8.8) It may be worth truss'ing the perl process and opening a Bug with the SpamAssassin team. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Has anybody ported Linux PARIDE
Has anybody ported the Linux PARIDE parallel-port IDE drivers to FreeBSD? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SpamAssassin (spamd) eating a lot of CPU....
(see below) Jeremy Chadwick wrote: On Tue, Jan 23, 2007 at 11:02:34PM -0500, Forrest Aldrich wrote: Since a recent update of Spamassassin to: PORTVERSION=3.1.7 PORTREVISION= 3 I've noticed that each email that gets scanned causes the process to eat up 80+% of the CPU time, and it's slow... I'm not really sure what changed. Likewise, when I start it up for the first time, I see: [ top output ] 49106 root1 1060 290M 267M RUN0 0:17 *98.52%* perl5.8.8 I have a Dell system here, and it cranks up the fan every time a message comes in now, with the recent spamd. Curious if anyone else has had these issues, etc. The system is not otherwise active, so I'm certain it's not a resource issue (or constraint thereof). I've seen this happen before, although with older SpamAssassin releases (though I have no proof the problem got fixed at all). At that time, we were using mail/spamass-rules as well. Since, we've removed using mail/spamass-rules, and haven't seen this problem. Possibly there's some SpamAssassin rule which causes the daemon to spin when certain regexs are matched. Not sure. Ours (note the much smaller memory footprint): root 58179 2.2 5.2 28088 27084 ?? S 3:58am 1:44.79 spamd child (perl5.8.8) root 65228 0.0 5.0 27172 26128 ?? S 5:58am 0:23.17 spamd child (perl5.8.8) root 313 0.0 4.3 23812 22176 ?? Ss2Jan07 11:40.79 /usr/local/bin/spamd -c -d -r /var/run/spamd/spamd.pid (perl5.8.8) It may be worth truss'ing the perl process and opening a Bug with the SpamAssassin team. Thanks for the replies. I did clean up the extra rules (dujor and others) and that seems to have resolved the problem... for now. It's worth noting that I've had these extra rules in there for a while, and only recently has this caused the high CPU consumption. So I would tend to wonder if there's a bug somewhere. Might be more resource friendly if this were in C, but I don't want to go there ;-) Thanks, Forrest ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: math/R eats up all.
I helped the mantainer to update R to both 2.4.0 and to 2.4.1 (ports/107638, still waiting to be committed, long overdue). I can't understand the point! On a pentium 4 notebook I hadn't the slightest problem in compiling the latest R, atlas, blas and lapack. As a matter of fact R requires 'blas' as a dependency as well as 'atlas'. So if you compile/update atlas (i did it yesterday!) by default blas should be compiled and installed. I suggest to install the following packages with the default configuration in this order: 1) blas 2) atlas 3) R Let me know Ciao Vittorio Alle 01:30, mercoledì 24 gennaio 2007, NAKATA Maho ha scritto: Hi, I recieved some message that we cannot build math/R. If one use ATLAS instead of BLAS/LAPACK, build of math/R stops at: mkdir ../../../../library/grDevices/libs and then hangs with 100% CPU usage. I don't know how I fix it sorry. -- NAKATA, Maho ([EMAIL PROTECTED]) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: paragui wants earlier version of libSDL
Joshua Tinnin píše v út 23. 01. 2007 v 21:07 -0700: I don't know enough about libtool to understand which port is referencing the old version of libSDL. Here's the failure: libtool: link: cannot find the library `/usr/local/lib/libSDL-1.1.la' or unhandled argument `/usr/local/lib/libSDL-1.1.la' +*** Error code 1 Builds fine here, this is your local installation problem. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Fairy tales do not tell children that dragons exist. Children already know dragons exist. Fairy tales tell children that dragons can be killed. -- G. K. Chesterton signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: ports/102499: lftp asc file checksum mismatch
Kris Kennaway wrote: On Thu, Jan 25, 2007 at 12:55:09AM +0300, Roman Kurakin wrote: I am crossposting this to both bugs@ and ports@ so all who will join this discussion keep this in mind if you'll reply. Pav Lucistnik wrote: So, what's the status on this one? My opinion is that the whole ticket is bogus and should be closed. No, it shouldn't. Sorry I didn't have enough time to investigate the problem further, but it is a real pain for port distribution. IIRC the point I've reached was: all software works correctly. All files correct but port can't be build. The reason that default behaviors are not the same on all levels and conversion of new line from single char to double could occur. The solution is to request text file as binary than all layers will bypass it without modifications or to convert newline explicitly for all text files before computation of checksum to the one default value (I guess to single-char variant). So the problem not in the port itself but in the set of conditions. And probably this bug report should be reopened with other description. I didnt see earlier mails in the thread, but I assume the problem is All that was discussed in gnuts, it is not much. that lftp gets a corrupted distfile when fetching through a squid proxy. This is because in the default configuration squid fetches all plain text files in ftp ascii mode, which does CR/LF translation and botches up the checksum. IIRC this is not a bug and squid do not translate in all cases. Any way the file is marked as a text and any such translation do not look like a violation. I guess it was done for convenience of M$ users. IIRC it is impossible to switch this off in squid (this is the only thing they was wrong). My point of view that we should not blame the squid, this wouldn't help. Now I know that there is such problem, you know, a couple of peoples who will read this. But for the rest the project would look in the bad way. More over not all peoples can control which proxy in front of them even if they know about this problem. My idea was to tech a fetch to request a binary mode for all files despite of their mime type. rik IMO this is a bug in the squid configuration. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/102499: lftp asc file checksum mismatch
On Thu, Jan 25, 2007 at 01:48:02AM +0300, Roman Kurakin wrote: that lftp gets a corrupted distfile when fetching through a squid proxy. This is because in the default configuration squid fetches all plain text files in ftp ascii mode, which does CR/LF translation and botches up the checksum. IIRC this is not a bug and squid do not translate in all cases Any way the file is marked as a text and any such translation do not look like a violation. I guess it was done for convenience of M$ users. Bug in the sense of broken behaviour. IMO it is broken behaviour for squid to force a non-default translation policy on the client. If a FTP client really wants a non-default translation mode the protocol allows them to specify it. IIRC it is impossible to switch this off in squid (this is the only thing they was wrong). It can be corrected by editing squid's mime.conf. My point of view that we should not blame the squid, this wouldn't help. Now I know that there is such problem, you know, a couple of peoples who will read this. But for the rest the project would look in the bad way. More over not all peoples can control which proxy in front of them even if they know about this problem. My idea was to tech a fetch to request a binary mode for all files despite of their mime type. This may not be hard to do, can you look into it? The other option would be for the squid port to install a fixed mime.conf. Kris pgpAA3MIHh3SN.pgp Description: PGP signature
Re: ports/102499: lftp asc file checksum mismatch
My point of view that we should not blame the squid, this wouldn't We have to blame squid. We can't blame lftp port. Also, what's the use of these .asc files anyway? We could just lose their fetching from the port. They do nothing. My idea was to tech a fetch to request a binary mode for all files despite of their mime type. fetch does binary mode for all files. It's the squid which talks ascii with the original ftp site. IMO this is a bug in the squid configuration. Agreed. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Why do we need a film of Lord of the Rings when we have the book? Because watching a cg enhanced Legolas fire a flaming arrow into the heart of a warg is cool? - [EMAIL PROTECTED] in rec.games.roguelike.angband ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/102499: lftp asc file checksum mismatch
On Wed, Jan 24, 2007 at 11:58:13PM +0100, Pav Lucistnik wrote: My point of view that we should not blame the squid, this wouldn't We have to blame squid. We can't blame lftp port. Also, what's the use of these .asc files anyway? We could just lose their fetching from the port. They do nothing. Maybe, but this also affects a handful of other ports too. My idea was to tech a fetch to request a binary mode for all files despite of their mime type. fetch does binary mode for all files. It's the squid which talks ascii with the original ftp site. IMO this is a bug in the squid configuration. Agreed. Kris pgpvO7fVyUPsZ.pgp Description: PGP signature
Re: paragui wants earlier version of libSDL
On Wed, Jan 24, 2007 at 08:57:30PM +0100, Pav Lucistnik wrote: Joshua Tinnin píše v út 23. 01. 2007 v 21:07 -0700: I don't know enough about libtool to understand which port is referencing the old version of libSDL. Here's the failure: libtool: link: cannot find the library `/usr/local/lib/libSDL-1.1.la' or unhandled argument `/usr/local/lib/libSDL-1.1.la' +*** Error code 1 Builds fine here, this is your local installation problem. OK, but do you have any suggestions on how to go about fixing it? I have rebuilt every dependency ... - jt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
no origin recorded
pkg_* programs are frequently complaining: pkg_add: package BABagntux has no origin recorded pkg_add: package BABcmagt has no origin recorded pkg_add: package BABagntux has no origin recorded pkg_add: package BABcmagt has no origin recorded pkg_add: package BABagntux has no origin recorded The problem is - yes, they don't have an origin because they're not in the ports - it's a binary-only third party backup agent, which is sort-of half-registered as a package by their install script. Any way to suppress these messages? They are making port operations hard to read. signature.asc Description: OpenPGP digital signature
phpBB patch?
hi, portupgrade just upgraded phpbb-2.0.22 to phpbb-2.0.22_1. it used phpBB-2.0.22.tar.bz2 from www.phpbb.com (same as before), and as far as i can tell the .php files are the same (and naturally the database is untouched). does anyone know what this upgrade was meant to achieve? - gareth ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: phpBB patch?
gareth wrote: hi, portupgrade just upgraded phpbb-2.0.22 to phpbb-2.0.22_1. it used phpBB-2.0.22.tar.bz2 from www.phpbb.com (same as before), and as far as i can tell the .php files are the same (and naturally the database is untouched). does anyone know what this upgrade was meant to achieve? This update has removed a patch which is previously used to protect users against session exhaustion problem that hurts when heap session table is used, which is common and is suggested by phpBB developers in the MySQL 3.x age. Unfortunately, the continued phpBB development has more and more (ab)use of the session table and simply rejecting anonymous session is no longer feasible, as it causes problem for many places in phpBB especially for its new features. Instead of using the patch, users have to re-create session table if they used heap session table in the past, to prevent the DoS problem. This would not cause serious performance penalty for newer MySQL versions. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Is there anybody will port the ATI linux driver to FreeBSD?
Hi, guys, As http://www.fglrx-freebsd.com/index.php will shutdown at Jan. 31,2007. Will anybody continue to port the latest ATI driver to FreeBSD? A ported version of ATI drivers on above is 8.20.8, but ATI had released their updated driver to 8.33.6 at Jan. 10, 2007, but it seems nobody will continue to port such this important driver to FreeBSD. Lots of people use the new ATI card supported by the latest driver, AFAIK, 8.20.8 is a very out-date version and it's not support R5xx series chipset or any other advanced series, if nobody continue to port or maintain this driver, i think FreeBSD may lose lots of ATI users at this point. Could anybody will do the community a favour? B.Rgds, Janvier Pang ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: phpBB patch?
On 1/24/07, gareth [EMAIL PROTECTED] wrote: hi, portupgrade just upgraded phpbb-2.0.22 to phpbb-2.0.22_1. it used phpBB-2.0.22.tar.bz2 from www.phpbb.com (same as before), and as far as i can tell the .php files are the same (and naturally the database is untouched). does anyone know what this upgrade was meant to achieve? From the log[1]: --- Remove previously added security patch against session table exhaustion, as it causes more problems in the latest phpbb version. Users are advised to drop and re-create their session tables (phpbb_sessions, phpbb_sessions_keys) without using HEAP tables. --- Gordon [1] http://www.freshports.org/www/phpbb/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/102499: lftp asc file checksum mismatch
On Wed, 2007-Jan-24 18:04:57 -0500, Kris Kennaway wrote: IIRC it is impossible to switch this off in squid (this is the only thing they was wrong). It can be corrected by editing squid's mime.conf. ... The other option would be for the squid port to install a fixed mime.conf. Note that this would not the issue where someone is fetching ports from behind a SQUID proxy that they do not control (eg corporate firewall). It looks like distinfo can contain multiple checksums for a file and the checksum test will pass if any checksum is correct. In this case, another option would be to provide two sets of checksum entries for the problematic files: One for the file with CR-LF and one for the file with just LF. -- Peter Jeremy pgpLGBW6UaOy6.pgp Description: PGP signature
