RE: how to use firefox
From KDE (or Gnome) there is a Run a program or similar on the main menu. Type firefox in there and it will most likely come up. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Merryweather Cooper Sent: Wednesday, 12 July 2006 2:54 AM To: Mihir Sanghavi Cc: freebsd-stable@freebsd.org Subject: Re: how to use firefox Mihir Sanghavi wrote: Hi, I have installed firefox using pkg_add -r firefox and now want to use xterm i tried using xterm and it says: Cannot open display and display not set It sounds like X is not running. Anyway Firefox has very little to do with xterm. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade bug: -M no longer works after v2.1.0
Sergey Matveychuk said the following on 7/11/2006 10:08 PM: Atanas wrote: Recent portupgrade versions no longer obey the -M command line switch, i.e. any optional arguments to be prepended to each make command. How to reproduce: # portinstall -M APACHE_HARD_SERVER_LIMIT=1024 www/apache13 Everything work file. Use -m for getting what you want. For www/apache13 the -m switch could give the same result as -M would, but I'm not sure whether it's not just a coincidence. The -m switch was supposed to serve a different purpose: -m --make-argsSpecify arguments to append to each make(1) com- mand line. -M --make-env Specify arguments to prepend to each make(1) com- mand line. I tried testing another port where I used both: # portinstall -M 'WITH_SYSLOG_FACILITY=local5' -m '-DWITHOUT_IPV6' mail/courier-imap With portupgrade-2.0.1_1,1 (the stock 6.1-RELEASE package) it worked. With portupgrade-2.1.3.2,2 it failed (ignoring the -M part like for www/apache13 before). Then I joined both in one -m switch: # portinstall -m 'WITH_SYSLOG_FACILITY=local5 -DWITHOUT_IPV6' mail/courier-imap and the latest portupgrade-2.1.3.2,2 did it just fine. So, like you suggested, the -m switch seems to cover the functionality that -M used to provide. I'm not sure however whether this prepend to append conversion would work for all ports. But for these that I use it appears to work, so I have no problem and will update my scripts to use -m only. The no longer working (obsolete?) -M switch would need to be removed from the man page though. Thanks, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade bug: -M no longer works after v2.1.0
Atanas wrote: Sergey Matveychuk said the following on 7/11/2006 10:08 PM: Atanas wrote: Recent portupgrade versions no longer obey the -M command line switch, i.e. any optional arguments to be prepended to each make command. How to reproduce: # portinstall -M APACHE_HARD_SERVER_LIMIT=1024 www/apache13 Everything work file. Use -m for getting what you want. For www/apache13 the -m switch could give the same result as -M would, but I'm not sure whether it's not just a coincidence. The -m switch was supposed to serve a different purpose: -m --make-argsSpecify arguments to append to each make(1) com- mand line. -M --make-env Specify arguments to prepend to each make(1) com- mand line. I tried testing another port where I used both: # portinstall -M 'WITH_SYSLOG_FACILITY=local5' -m '-DWITHOUT_IPV6' mail/courier-imap With portupgrade-2.0.1_1,1 (the stock 6.1-RELEASE package) it worked. With portupgrade-2.1.3.2,2 it failed (ignoring the -M part like for www/apache13 before). Then I joined both in one -m switch: # portinstall -m 'WITH_SYSLOG_FACILITY=local5 -DWITHOUT_IPV6' mail/courier-imap and the latest portupgrade-2.1.3.2,2 did it just fine. So, like you suggested, the -m switch seems to cover the functionality that -M used to provide. I'm not sure however whether this prepend to append conversion would work for all ports. But for these that I use it appears to work, so I have no problem and will update my scripts to use -m only. The no longer working (obsolete?) -M switch would need to be removed from the man page though. Both -m and -M works fine but do different things. -m pass its argument as make file argument(s) and -M pass its argument as environment variable(s). You can't set make variable with environment variable. They are different! -M has never worked as you expected. You can test it with a command: %cd /usr/ports/www/apache13 %env APACHE_HARD_SERVER_LIMIT=1024 make against of % make APACHE_HARD_SERVER_LIMIT=1024 I think you confuse the two variables types. -- Dixi. Sem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Securelevels and /dev/io documentation inconsistency
Hello, I believe i have stumbled upon a documentation inconsistency concerning securelevels and usage of /dev/io From init(8) manpage 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, /dev/kmem and /dev/io (if your platform has it) may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded. Note the may not be opened for writing. It is correct for /dev/mem and /dev/kmem but incorrect for /dev/io as the following experiment shows: 3:40pm ~ # sysctl kern.securelevel kern.securelevel: 1 [EMAIL PROTECTED] 3:40pm ~ # head /dev/io head: /dev/io: Operation not permitted [EMAIL PROTECTED] 3:40pm ~ # Now the source code in /usr/src/sys/i386/i386/io.c just checks if securelevel is greater that 0 when opening the device and return accordingly. However from io(4) Note that even read-only access will grant the full I/O privileges. Which means that changing the code to check if the device is opened O_RDONLY and then allowing access would be a mistake cancelling the idea of blocking access to the device through usage of the securelevel. I am correct about the above ? Does the documentation need a correction in that place? Thanks, alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Securelevels and /dev/io documentation inconsistency
On 2006-07-12 15:47, Alexandros Kosiaris [EMAIL PROTECTED] wrote: Hello, I believe i have stumbled upon a documentation inconsistency concerning securelevels and usage of /dev/io From init(8) manpage 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, /dev/kmem and /dev/io (if your platform has it) may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded. Note the may not be opened for writing. It is correct for /dev/mem and /dev/kmem but incorrect for /dev/io as the following experiment shows: 3:40pm ~ # sysctl kern.securelevel kern.securelevel: 1 [EMAIL PROTECTED] 3:40pm ~ # head /dev/io head: /dev/io: Operation not permitted [EMAIL PROTECTED] 3:40pm ~ # Now the source code in /usr/src/sys/i386/i386/io.c just checks if securelevel is greater that 0 when opening the device and return accordingly. However from io(4) Note that even read-only access will grant the full I/O privileges. Which means that changing the code to check if the device is opened O_RDONLY and then allowing access would be a mistake cancelling the idea of blocking access to the device through usage of the securelevel. I am correct about the above ? Does the documentation need a correction in that place? It looks like it does. Would something like this be satisfactory? 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem and /dev/kmem may not be opened for writing and /dev/io (if your platform has it) may not be opened at all; kernel modules (see kld(4)) may not be loaded or unloaded. Regards, Giorgos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade bug: -M no longer works after v2.1.0
Sergey Matveychuk wrote at 14:24 +0400 on Jul 12, 2006: Both -m and -M works fine but do different things. -m pass its argument as make file argument(s) and -M pass its argument as environment variable(s). You can't set make variable with environment variable. They are different! -M has never worked as you expected. You can test it with a command: %cd /usr/ports/www/apache13 %env APACHE_HARD_SERVER_LIMIT=1024 make against of % make APACHE_HARD_SERVER_LIMIT=1024 I think you confuse the two variables types. This is incorrect. make(1) looks at the environment for variables. See the man page. If you tested your example, you'd see that it works fine. make APACHE_HARD_SERVER_LIMIT=22 -V CFLAGS -O2 -fno-strict-aliasing -pipe -DDOCUMENT_LOCATION=\/usr/local/www/data\ -DDEFAULT_PATH=\/bin:/usr/bin:/usr/local/bin\ -DHARD_SERVER_LIMIT=22 env APACHE_HARD_SERVER_LIMIT=22 make -V CFLAGS -O2 -fno-strict-aliasing -pipe -DDOCUMENT_LOCATION=\/usr/local/www/data\ -DDEFAULT_PATH=\/bin:/usr/bin:/usr/local/bin\ -DHARD_SERVER_LIMIT=22 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade bug: -M no longer works after v2.1.0
John E Hein wrote: This is incorrect. make(1) looks at the environment for variables. See the man page. OK, something really broke in portupgrade then. -- Dixi. Sem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Securelevels and /dev/io documentation inconsistency
It looks like it does. Would something like this be satisfactory? 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem and /dev/kmem may not be opened for writing and /dev/io (if your platform has it) may not be opened at all; kernel modules (see kld(4)) may not be loaded or unloaded. Regards, Giorgos Yes it would be. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade bug: -M no longer works after v2.1.0
Sergey Matveychuk said the following on 7/12/06 3:24 AM: Atanas wrote: Sergey Matveychuk said the following on 7/11/2006 10:08 PM: Atanas wrote: Recent portupgrade versions no longer obey the -M command line switch, i.e. any optional arguments to be prepended to each make command. How to reproduce: # portinstall -M APACHE_HARD_SERVER_LIMIT=1024 www/apache13 Everything work file. Use -m for getting what you want. For www/apache13 the -m switch could give the same result as -M would, but I'm not sure whether it's not just a coincidence. The -m switch was supposed to serve a different purpose: -m --make-argsSpecify arguments to append to each make(1) com- mand line. -M --make-env Specify arguments to prepend to each make(1) com- mand line. I tried testing another port where I used both: # portinstall -M 'WITH_SYSLOG_FACILITY=local5' -m '-DWITHOUT_IPV6' mail/courier-imap With portupgrade-2.0.1_1,1 (the stock 6.1-RELEASE package) it worked. With portupgrade-2.1.3.2,2 it failed (ignoring the -M part like for www/apache13 before). Then I joined both in one -m switch: # portinstall -m 'WITH_SYSLOG_FACILITY=local5 -DWITHOUT_IPV6' mail/courier-imap and the latest portupgrade-2.1.3.2,2 did it just fine. So, like you suggested, the -m switch seems to cover the functionality that -M used to provide. I'm not sure however whether this prepend to append conversion would work for all ports. But for these that I use it appears to work, so I have no problem and will update my scripts to use -m only. The no longer working (obsolete?) -M switch would need to be removed from the man page though. Both -m and -M works fine but do different things. -m pass its argument as make file argument(s) and -M pass its argument as environment variable(s). You can't set make variable with environment variable. They are different! Yes, I know that. That's why I quoted the man page in my previous post (see above). -M has never worked as you expected. I expected -M to work exactly as documented, like it has been doing so for years. You can test it with a command: %cd /usr/ports/www/apache13 %env APACHE_HARD_SERVER_LIMIT=1024 make Sure, the port build works: % cd /usr/ports/www/apache13 % env APACHE_HARD_SERVER_LIMIT=1024 make === src/os/unixcc -c -I../../os/unix -I../../include -I/usr/local/include -funsigned-char -O2 -fno-strict-aliasing -pipe -DDOCUMENT_LOCATION=\/usr/local/www/data\ -DDEFAULT_PATH=\/bin:/usr/bin:/usr/local/bin\ -DHARD_SERVER_LIMIT=1024 `../../apaci` os.c while portupgrade -M fails: % portinstall -M APACHE_HARD_SERVER_LIMIT=1024 www/apache13 === src/os/unixcc -c -I../../os/unix -I../../include -I/usr/local/include -funsigned-char -O2 -fno-strict-aliasing -pipe -DDOCUMENT_LOCATION=\/usr/local/www/data\ -DDEFAULT_PATH=\/bin:/usr/bin:/usr/local/bin\ -DHARD_SERVER_LIMIT=512 `../../apaci` os.c against of % make APACHE_HARD_SERVER_LIMIT=1024 This doesn't make much sense to me. Perhaps you meant: % make -DAPACHE_HARD_SERVER_LIMIT=1024 But I wouldn't expect this to succeed either: === src/os/unixcc -c -I../../os/unix -I../../include -I/usr/local/include -funsigned-char -O2 -fno-strict-aliasing -pipe -DDOCUMENT_LOCATION=\/usr/local/www/data\ -DDEFAULT_PATH=\/bin:/usr/bin:/usr/local/bin\ -DHARD_SERVER_LIMIT=512 `../../apaci` os.c Your suggestion however (to replace -M with -m) surprisingly worked: cc -c -I../../os/unix -I../../include -I/usr/local/include -funsigned-char -O2 -fno-strict-aliasing -pipe -DDOCUMENT_LOCATION=\/usr/local/www/data\ -DDEFAULT_PATH=\/bin:/usr/bin:/usr/local/bin\ -DHARD_SERVER_LIMIT=1024 `../../apaci` os.c And this is what's confusing. I think you confuse the two variables types. No, I think I know what these are for. But trying your suggestion to replace -M with -m and finding it to work (for some ports?), just threw some more fog into the case. Let's say it clear again - I have found that all recent versions of portupgrade (2.1.0+) fail to obey the -M switch and ignore any optional port parameters (i.e. arguments to prepend to each make command line) supplied there. Please, don't get me wrong. I'm not asking for help or for a workaround. I'm actually trying to help identifying a problem or regression. If this is not a bug, but a feature change, please have it documented. What the portupgrade(1) man page says about the -M switch is incorrect, as it no longer prepends any arguments specified to each make(1) command line. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
Since the iwi driver has been MFC'd, I cannot build a kernel any more. I csupped my src/sys to RELENG_6 a couple of hours ago. Everything compiles fine, but when linking the kernel, make barfs: linking kernel if_iwi.o(.text+0x29c4): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x29d3): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x2a1d): In function `iwi_put_fw': : undefined reference to `firmware_put' if_iwi.o(.text+0x49a5): In function `iwi_init_locked': : undefined reference to `firmware_get' I have device iwi in my kernel configuration. Should I remove it and use a module instead? Or is this supposed to work? - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
On 7/12/06, Bartosz Fabianowski [EMAIL PROTECTED] wrote: Since the iwi driver has been MFC'd, I cannot build a kernel any more. I csupped my src/sys to RELENG_6 a couple of hours ago. Everything compiles fine, but when linking the kernel, make barfs: linking kernel if_iwi.o(.text+0x29c4): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x29d3): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x2a1d): In function `iwi_put_fw': : undefined reference to `firmware_put' if_iwi.o(.text+0x49a5): In function `iwi_init_locked': : undefined reference to `firmware_get' I have device iwi in my kernel configuration. Should I remove it and use a module instead? Or is this supposed to work? You need to add device firmware to your kernel configuration file as well. This driver uses the new firmware(9) framework. - Bartosz -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Securelevels and /dev/io documentation inconsistency
On 2006-07-12 20:35, Alexandros Kosiaris [EMAIL PROTECTED] wrote: It looks like it does. Would something like this be satisfactory? 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem and /dev/kmem may not be opened for writing and /dev/io (if your platform has it) may not be opened at all; kernel modules (see kld(4)) may not be loaded or unloaded. Regards, Giorgos Yes it would be. Thank you. It should be fixed in HEAD now, with this commit: Revision ChangesPath 1.47 +4 -3 src/share/man/man7/security.7 After a short period (3 days or so), if there are no objections, corrections or other changes by fellow committers, I'll merge the change to RELENG_6 too. Thanks :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
On Wednesday 12 July 2006 20:07, Bartosz Fabianowski wrote: Since the iwi driver has been MFC'd, I cannot build a kernel any more. I csupped my src/sys to RELENG_6 a couple of hours ago. Everything compiles fine, but when linking the kernel, make barfs: linking kernel if_iwi.o(.text+0x29c4): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x29d3): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x2a1d): In function `iwi_put_fw': : undefined reference to `firmware_put' if_iwi.o(.text+0x49a5): In function `iwi_init_locked': : undefined reference to `firmware_get' I have device iwi in my kernel configuration. Should I remove it and use a module instead? Or is this supposed to work? This is from the firmware(9) support code. Add options firmware and you should be fine. You will still need to load the firmware blobs as modules, but that's another story. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpM3oBmnzNnn.pgp Description: PGP signature
cpufreq not working on AMD
Loading cpufreq.ko results in these messages: powernow0: Cool`n'Quiet K8 on cpu0 device_attach: powernow0 attach returned 6 powernow0: Cool`n'Quiet K8 on cpu0 device_attach: powernow0 attach returned 6 I've googled for it - there are many similar problems but no solution. This is: CPU: AMD Athlon(tm) 64 Processor 3000+ (1795.32-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff0 Stepping = 0 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF in i386 mode, and setting cpu frequency works in Windows. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PowerEdge 750 850 environtmental monitoring
Arnold Cavazos Jr. writes: | Does anybody have temperature and fan monitoring working on Dell | PowerEdge 750's 850's? I have done my share of googling without much | luck. The PE850 should just work with ipmi(4) in 6.1-stable/-current and ipmitool. The PE750 will work with ipmi if you have the Drac card. It is possible to get thermal stuff on the PE750 via smbus but that is more complicated. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bce0: Error mapping mbuf into TX chain!
David (Controller AE) Christensen writes: | Sorry, I've been out on vacation and just got back into town. I'll MFC | the patch within the next day or two. I'll let you merge in the down/up fix that I put into -current. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
missing mod_php4
Hi, Im trying to install Apache+ssl succesfully then i want to add mod_php4, the problem is, it is missing, /usr/ports/www/mod_php4 is non-existent, i tried running cvsup again just to make sure there's no error, but still it is missing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: missing mod_php4
Hi! Im trying to install Apache+ssl succesfully then i want to add mod_php4, the problem is, it is missing, /usr/ports/www/mod_php4 is non-existent, i tried running cvsup again just to make sure there's no error, but still it is missing. The php ports have been reorganized and cleaned up (IMHO for the better) - see /usr/ports/lang/php4 HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: missing mod_php4
Patrick M. Hausen wrote: Hi! Im trying to install Apache+ssl succesfully then i want to add mod_php4, the problem is, it is missing, /usr/ports/www/mod_php4 is non-existent, i tried running cvsup again just to make sure there's no error, but still it is missing. The php ports have been reorganized and cleaned up (IMHO for the better) - see /usr/ports/lang/php4 HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade bug: -M no longer works after v2.1.0
Atanas wrote: Please, don't get me wrong. I'm not asking for help or for a workaround. I'm actually trying to help identifying a problem or regression. If this is not a bug, but a feature change, please have it documented. It was a bug. Fixed. Thanks. -- Dixi. Sem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
