MIN()/MAX() definitions in sys/param.h
Is there a reason the definitions of the MIN() and MAX() macros in sys/param.h are under an '#ifndef _KERNEL'? Quite a few files in the kernel define these (well, at least MIN) themselves, so it would seem to make sense to define them globally in sys/param.h for the kernel as well. Any reason this isn't already done this way, or should I come up with a patch to fix that? Thanks for any insight, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD 4.2 ,kernel panic.
MY FreeBSD 4.2 system has begun to crash some time ago.. executing gdb -k kernel.o vmcore.0 i got this: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... IdlePTD 4579328 initial pcb at 3ab080 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x9ec03e00 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c4896 stack pointer = 0x10:0xc037827c frame pointer = 0x10:0xc0378288 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc029f120 stack pointer = 0x10:0xc0378074 frame pointer = 0x10:0xc0378078 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam trap number = 12 panic: page fault Uptime: 1d19h1m45s dumping to dev #ad/0x20001, offset 140867 dump ata0: resetting devices .. done 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc01aa6a2 in dumpsys () (kgdb) bt #0 0xc01aa6a2 in dumpsys () #1 0xc01aa4c3 in boot () #2 0xc01aa840 in poweroff_wait () #3 0xc030c2c9 in trap_fatal () #4 0xc030bfa1 in trap_pfault () #5 0xc030bb5b in trap () #6 0xc029f120 in acquire_lock () #7 0xc02a2eb4 in softdep_update_inodeblock () #8 0xc029e3fd in ffs_update () #9 0xc02a775d in ffs_fsync () #10 0xc02a60c3 in ffs_sync () #11 0xc01d8013 in sync () #12 0xc01aa296 in boot () #13 0xc01aa840 in poweroff_wait () #14 0xc030c2c9 in trap_fatal () #15 0xc030bfa1 in trap_pfault () #16 0xc030bb5b in trap () #17 0xc01c4896 in m_gethdr () #18 0xc01fbca6 in icmp_error () #19 0xc01fdaa1 in ip_forward () #20 0xc01fcbda in ip_input () #21 0xc01fce0b in ipintr () #22 0xc02ff4e5 in swi_net_next () #23 0xc01b00c9 in softclock () (kgdb) (kgdb) where #0 0xc01aa6a2 in dumpsys () #1 0xc01aa4c3 in boot () #2 0xc01aa840 in poweroff_wait () #3 0xc030c2c9 in trap_fatal () #4 0xc030bfa1 in trap_pfault () #5 0xc030bb5b in trap () #6 0xc029f120 in acquire_lock () #7 0xc02a2eb4 in softdep_update_inodeblock () #8 0xc029e3fd in ffs_update () #9 0xc02a775d in ffs_fsync () #10 0xc02a60c3 in ffs_sync () #11 0xc01d8013 in sync () #12 0xc01aa296 in boot () #13 0xc01aa840 in poweroff_wait () #14 0xc030c2c9 in trap_fatal () #15 0xc030bfa1 in trap_pfault () #16 0xc030bb5b in trap () #17 0xc01c4896 in m_gethdr () #18 0xc01fbca6 in icmp_error () #19 0xc01fdaa1 in ip_forward () #20 0xc01fcbda in ip_input () #21 0xc01fce0b in ipintr () #22 0xc02ff4e5 in swi_net_next () #23 0xc01b00c9 in softclock () (kgdb) I got this modules loaded on my system radiusd# kldstat Id Refs AddressSize Name 14 0xc010 33d920 kernel 21 0xc0d11000 c3000vinum.ko 31 0xc0e28000 12000fire_saver.ko 41 0xc0e3b000 11000linux.ko this is my kernel config: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.21 2001/01/12 23:45:14 scottl Exp $ machine i386 cpu I686_CPU ident CAPSULA maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options FFS options SOFTUPDATES #Enable FFS soft updates support option
Re: SSH Must Die
Thomas Quinot wrote: > Le 2001-05-13, Peter Wemm écrivait : > > > The simplest thing is to do a ssh-keygen to generate a new RSA key and > > update ~/.ssh/authorized_keys2 once per remote machine that you connect > > to. Once that is done, it never bothers you again. You can change > > /etc/ssh/ssh_config so that it says 'Protocol 1,2', but that is avoiding > > the problem rather than using the more robust, cryptographically secure > > sshv2 wire protocol. > > Ah. This seems to work around the very unfortunate situation described in > PR bin/27264. It seems very strange that one has to change the setup > on the *server* side to work around a regression on the client side. > > Why cannot one use the same RSA public key for v1 and v2 client > authentication? That is something that I'd like to know too. RSA keys are RSA keys, regardless of how they are encoded. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
Le 2001-05-13, Peter Wemm écrivait : > The simplest thing is to do a ssh-keygen to generate a new RSA key and > update ~/.ssh/authorized_keys2 once per remote machine that you connect > to. Once that is done, it never bothers you again. You can change > /etc/ssh/ssh_config so that it says 'Protocol 1,2', but that is avoiding > the problem rather than using the more robust, cryptographically secure > sshv2 wire protocol. Ah. This seems to work around the very unfortunate situation described in PR bin/27264. It seems very strange that one has to change the setup on the *server* side to work around a regression on the client side. Why cannot one use the same RSA public key for v1 and v2 client authentication? Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
On Sun, 13 May 2001, Peter Wemm wrote: > Mike Silbersack wrote: > > 1. Is ssh working yet? > > Yes, it is working perfectly. The only problem is that it now works > slightly differently to what people have expected. ie: it treats > sshv1 rsa keys as totally seperate to sshv2 rsa keys. Let me rephrase: 1. Terry, is ssh working for you yet? Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
Mike Silbersack wrote: > > On Sat, 12 May 2001, Terry Lambert wrote: > > > Erik Trulsson wrote: > > > Exactly how is rpping it out of FreeBSD supposed to make ssh work? > > > > I don't necessarily want it to work or not work, I just > > want it to quit being a pain in my backside. > > > > If it can't be made to upgrade correctly, then ripping it > > out also satisfies the criteria necessary to achieve the > > intended goal. > > Ok, backing this thread up briefly, two quick questions: > > 1. Is ssh working yet? Yes, it is working perfectly. The only problem is that it now works slightly differently to what people have expected. ie: it treats sshv1 rsa keys as totally seperate to sshv2 rsa keys. The simplest thing is to do a ssh-keygen to generate a new RSA key and update ~/.ssh/authorized_keys2 once per remote machine that you connect to. Once that is done, it never bothers you again. You can change /etc/ssh/ssh_config so that it says 'Protocol 1,2', but that is avoiding the problem rather than using the more robust, cryptographically secure sshv2 wire protocol. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
On Sat, 12 May 2001, Terry Lambert wrote: > Erik Trulsson wrote: > > Exactly how is rpping it out of FreeBSD supposed to make ssh work? > > I don't necessarily want it to work or not work, I just > want it to quit being a pain in my backside. > > If it can't be made to upgrade correctly, then ripping it > out also satisfies the criteria necessary to achieve the > intended goal. Ok, backing this thread up briefly, two quick questions: 1. Is ssh working yet? 2. Do you have multiple copies of ssh/sshd laying around the system in different places? I ask because the mergemaster & /etc track this thread has taken seems offbase; pam.conf would cause authentication errors, not RSA-related errors, if I recall correctly. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
On Sun, 13 May 2001, Karsten W. Rohrbach wrote:
> btw, mergemaster's version number generation for the help/syntax page is
> broken because it displays the number of the running kernel not the
> version of mergemaster itself:
> ---
> VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4`
> echo "mergemaster version ${VERSION_NUMBER}"
> ---
That would appear to be mergemaster grepping for the $FreeBSD$ line in
itself, then extracting the CVS revision number from that line.
> why is it this way? i would think about creating the version in the
> build process and s/@TAG@/version/ it in the to-be-installed mergemaster
> file.
The version is branded into the file during the cvs commit process, and is
extracted from the installed file when needed...
--
David Taylor
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
"Karsten W. Rohrbach" wrote: > is there a way to make the upgrade process easier by doing the thing > mergemaster does but with an interface that does not kill the average > ordinary user with a simple prompt without really useful help > incantating strange phrases to summon the subprocesses that diff and > patch and apply the arcane magic? > the average luser cannot deal with diff outputs There is a school of thought that says if you cannot handle something as simple as a diff output you probably shouldn't be running unix. I'm all for making things simpler for users, but there is a level beyond which it's not possible to go without turning into windows. That said, I am working on some things to make mm handle cases where the user has not modified the files easier to deal with. > so it would make sense > to have a simple program displaying the old version in the upper and the > new in the lower part of the screen, allowing the user to choose what to > do next. i am not quite sure, but i think about it "feeling" like vim or > emacs in splitscreen mode editing version-tagged files. As Kris said in his previous post, your patches are welcome. One problem with your approach however is that if you show the user all of both files they are very likely to miss important changes. Tools like diff were developed precisely because picking small changes out of large bodies of text is one thing that computers do well (or at least, better than humans). Also, with sdiff (which is what mm invokes to do the merge) it displays old and new on the left and right sides of the screen and gives you several options for how to merge the two together, including editing both old and new together. Check out the man page for sdiff. > btw, mergemaster's version number generation for the help/syntax page is > broken because it displays the number of the running kernel not the > version of mergemaster itself: It's completely impossible for mm to get "the number of the running kernel," whatever that is, as its version number. # mergemaster -h mergemaster version 1.18 . . . # ident /usr/sbin/mergemaster /usr/sbin/mergemaster: $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.18 2001/03/29 14:04:19 asmodai Exp $ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
Kris Kennaway([EMAIL PROTECTED])@2001.05.12 19:33:54 +:
> On Sat, May 12, 2001 at 04:24:48PM -0700, Terry Lambert wrote:
> > Jordan Hubbard wrote:
> > >
> > > ssh works just fine for me in 4.3. You must be doing something
> > > wrong.
> >
> > I used that "sysinstall" thing Jordan wrote to upgrade
> > from a 4.2 to a 4.3 system.
> >
> > Is that what I'm doing wrong? ;^).
>
> sysinstall does a very minimal job of merging the contents of /etc.
> Certainly it could be improved (mergemaster works nicely when you have
> the source tree around). Your patches would be appreciated.
is there a way to make the upgrade process easier by doing the thing
mergemaster does but with an interface that does not kill the average
ordinary user with a simple prompt without really useful help
incantating strange phrases to summon the subprocesses that diff and
patch and apply the arcane magic?
the average luser cannot deal with diff outputs so it would make sense
to have a simple program displaying the old version in the upper and the
new in the lower part of the screen, allowing the user to choose what to
do next. i am not quite sure, but i think about it "feeling" like vim or
emacs in splitscreen mode editing version-tagged files.
btw, mergemaster's version number generation for the help/syntax page is
broken because it displays the number of the running kernel not the
version of mergemaster itself:
---
VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4`
echo "mergemaster version ${VERSION_NUMBER}"
---
why is it this way? i would think about creating the version in the
build process and s/@TAG@/version/ it in the to-be-installed mergemaster
file.
>
> Kris
--
> A Puritan is someone who is deathly afraid that someone, somewhere, is
> having fun.
KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de
[Key] [KeyID---] [Created-] [Fingerprint-]
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
KAI C++
Hi, Do some of you have experience with this compiler on FreeBSD with Linux emulation? Are there known problems/pitfalls? Thanks, Arjan Knepper To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
´ÙÀ̾îÆ® ¿Í ¼ºÀÎ
Title: freebsd-hackers´Ô ¾È³çÇϼ¼¿ä ? ´ç»ç´Â ¹Ì±¹LA¿¡ ¼ÒÀçÇϸç ÀÎÅÍ³Ý ¼îÇθô Àü¹®¾÷ü ÀÔ´Ï´Ù. ¹Ì±¹¿¡¼ È®½ÇÈ÷ ÀÎÁ¤ ¹ÞÀº Ç°¸ñ¸¸ À¸·Î ¿©·¯ºÐÀ» À§ÇØ Áغñ Çß½À´Ï´Ù. ÄÚ¸®¾ÆŸ¿î »çÀ̹ö¸ô »õ´ÜÀå ±â³ä Ưº° ¼¼ÀÏ»óÇ° ¡¡ Á¦´ÏÄ®(Xenical) ´ÙÀ̾îÆ® ¹Ì±¹½ÄÇ°ÀǾ౹(FDA) ½ÂÀÎÀ» ¹ÞÀº ½Ä¿å ¾ïÁ¦¾øÀÌ Ã¼ÁßÁ¶Àý È¿°ú½Ä»ç¿¡ Æ÷ÇÔµÈ Áö¹æ·®ÀÇ 30%¿Í °áÇÕÇØ Áö¹æÀÌ Àå¿¡¼ Èí¼öµÇ´Â °ÍÀ» ¾ïÁ¦Àå¿¡¼ Á÷Á¢ ÀÛ¿ëÇÏ´Â ´ÙÀ̾îÆ® ¾àÀ¸·Î´Â ¼¼°è ÃÖÃÊÁ¦´ÏÄ®Àº ½ÄÀÌÁö¹æÀÇ Èí¼ö¸¦ ¸·¾ÆÁÖ±â À§ÇØ Àå¿¡¼ ÀÛ¿ëÇÏ´Â ¾ïÁ¦Á¦°¡ µé¾îÀÖ¾î ½Ä¿åÀ» ¾ïÁ¦ÇÏÁö ¾Ê°í üÁßÀ» ÁÙÀ̴µ¥ µµ¿òÀÌ µÈ´Ù.¿ø·¡°¡°Ý: $190 ¼¼ÀÏ°¡°Ý: $135 ÇÒÀξ×: $55 ¡¡ Dexatrim (´ÙÀ̾îÆ®¾à/½Ä¿å¾ïÁ¦) ¿©·¯°¡Áö ´Ù¾îÆ®¿¡ ½ÇÆÐÇÑ ºÐµéÀ» À§ÇÑ È¹±âÀûÀÎ ´Ù¾îÆ®¾à. 1 ÀÏ 1ȸ º¹¿ëÀ¸·Î 12½Ã°£ ½ÃÀå±â Á¦°ÅÇÏ¿© Ä®·Î¸® ¼·ÃëÀ» ÀÚ¿¬½º·´°Ô ÄÜÆ®·ÑÇÏ¿© ÀÚ¿¬½º·´°Ô üÁß ÀúÇÏ´Â ¼¼·Î¿î ´Ù¾îÆ®¾à. Á¦Á¶¿ø:¹Ì±¹ ¿ø·¡°¡°Ý: $45 ¼¼ÀÏ°¡°Ý: $22 ÇÒÀξ×: $23 ¡¡ Diurex(´ÙÀ̾îÆ®) »ý¸®Àü üÁßÁõ°¡¿Í ºÒÄè°¨À» Á¦°ÅÇØÁִ ƯȿÀÇ ¾àÇ°. 1ÀÏ1ȸ º¹¿ëÀ¸·Î »ý¸®Àü ¸ö¿¡ ¼öºÐÁõ°¡À» ¼Òº¯À¸·Î ¹è¼³ÇÏ¿© ÆÈ´Ù¸®¿¡ ºÎ±â¿Í ¾Æ·§¹è °ÅºÏÇÔÀ» ¾ø¿¡ÁÜ. Á¦Á¶¿ø: ¹Ì±¹ ¿ø·¡°¡°Ý: $45 ¼¼ÀÏ°¡°Ý: $22 ÇÒÀξ×$23 ¡¡ ¡¡ Nair(ü¸ð Á¦°Å ·Î¼Ç) ¿©¸§Ã¶¿¡ ³ëÃâµÇ¾î º¸±âÈäÇÑ °Üµå¶ûÀÌ,ÆÈ,´Ù¸® µîµî ÅÐÀ» ¸»²ûÈ÷ ¾ø¾ÖÁÖ´Â Å©¸².¡¡·Î¼ÇÀ» ³ëÃâµÇ´Â ºÎºÐ¿¡ ¹Ù¸¥ÈÄ 3-5ºÐÈÄ¿¡ ÈÞÁö·Î ´ÛÀ¸¸é º¸±â½ÈÀº ü¸ðÀ» ¿Ïº®ÇÏ°Ô Á¦°ÅÇØÁÜ.Á¦Á¶¿ø: ¹Ì±¹ ¿ø·¡°¡°Ý: $35 ¼¼ÀÏ°¡°Ý: $20 ÇÒÀξ×: $15 ¡¡ (ÈÀÌÆ®´× Å©¸²)¾ó±¼À» ¹é¿Áó·³! º½¿©¸§Ã¶¿¡ žçÜ¿¡ °Ë¾îÁö´Â ÇǺÎÀ» ¹é¿Áó·³ Èñ°Ô... Á×Àº±ú, ±â¹Ì¿¡µµ Ưȿ. Á¦Á¶¿ø:¹Ì±¹ ¿ø·¡°¡°Ý: $45 ¼¼ÀÏ°¡°Ý: $25 ÇÒÀξ×: $20 ¡¡ ¡¡ Yohimbe Advatage $50.00 ( ÃÊ°·Â Á¤·ÂÁ¦) ÃÊ°·Â Á¤·ÂÁ¦ ³Ê¹«³ª À¯¸íÇÑÁ¦Ç°. ¿äÈûºñ·Î´Â °¡Àå È®½ÇÇÑADVENTAGE INC.Á¦Ç° ÀÔ´Ï´Ù. ºÎºÎ°¡ ÇÔ²²º¹¿ëÇØ Áñ°Å¿î ¼º»ýÈ°À» À§ÇÑ Áغñ¹°.º¹¿ë¹æ¹ý:°¡º¿î ¼ú¿¡ 2-3¹æ¿ï¾¿ ³Ö¾îº¹¿ëÇÏ½Ã¸é °¡ÀåÈ¿°ú¸¦ º¼¼öÀÖ´ÂÁ¦Ç° Á¦Á¶¿ø: ¹Ì±¹ ¿ø·¡°¡°Ý: $75 ¼¼ÀÏ°¡°Ý: $50 ÇÒÀξ×: $25 ¡¡ ¡¡ ¡¡ ½ºÆä´Ï½º ÇöóÀÌ (¿©¼ºÈïºÐÁ¦) ±×³à¸¦ Áñ°Ì°Ô ÇÑ´Ù.!À̹ãÀ» ´õ¿í´õ ±×³à¿Í »ç¶ûÀ» ..20¾ËÀ̸ç 1ÀÏ3¾Ë±îÁö¸¸ º¹¿ë.Á¦Á¶¿ø:¹Ì±¹ÆǸŰ¡°Ý: $19 ¡¡ ¡¡ ¼½½º ¹é¹èÁñ±â±â Áöħ¼(ºñµð¿À Å×ÀÙ) 1,2 Æí ¹Ì±¹ Sex Clinic ÀÇ À¯¸í ÀÇ»çµéÀÌ Á»´õ ÇູÇÏ°í ¿Ïº®ÇÑ ºÎºÎ»ýÈ°À» À§ÇÏ¿© Á¦ÀÛÇÑ ºñµð¿ÀÅ×ÀÔ. ´Ù¾çÇÑ Ã¼À§¿Í üÀ§ÀÇ Àå´ÜÁ¡À» ÀÚ¼¼È÷ ¼³¸íÇÏ¸ç ¼ºÅ©¸®´Ð ȯÀÚµéÀÌ Á÷Á¢ ¸ðµ¨·Î µîÀåÇÔ. ¼º»ýÈ°¿¡ ¸¸Á·ÇÏÁö¸øÇϴºеéÀº ºÐµé¿¡°Ô´Â ÇʼöÁ¦Ç°ÀÌ¸ç ¸¸Á·ÇϴºеéÀº Á»´õ ¸¸Á·À»´À³¥¼öÀÖ°Ô µµ¿Íµå¸², 1Æí,2ÆíÀ¸·Î DVD¿øÆÇÀ» ºñµð¿À Å×ÀÙ À籸¼º.¿ø·¡°¡°Ý: $65 ¼¼ÀÏ°¡°Ý: $45 ÇÒÀξ×: $20 ¼¼°è¿¡¼ °¡Àå Àú·ÅÇÑ ºñ¿ëÀ¸·Î ¿©·¯ºÐÀÇ ¸ÞÀÏ ±¤°í¸¦ Ã¥ÀÓÁö°Ú½À´Ï´Ù. [EMAIL PROTECTED] ¡Iì¹» ®&Þ±éݨ¥¶Ý¢jçH:+éì¹» ®&Þ~·nÇaiÉ ®È§¶¡Ü¨~Ø^ë,j
GNATS doesn't like me
Hi, GNATS doesn't seem to send me email for some reason - I raised a PR yesterday which made it into the system OK but no confirming email. To whom should I complain? Should I raise a PR :-) ? -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about building source
In message <[EMAIL PROTECTED]> "David Mr. Hackers O'Brien" writes: : I went thru this last month -- bsd.*.mk assumes /usr/src and the base : compilers. Peroid. People didn't want to accept that, but you are : giving more proof of it. If you want to change the assumptions of about : the base system, you have to be willing to change bsd.*.mk. Peroid. All my systems that build sources have not had a /usr/src at all for at least three years, maybe 4 now. Nothing in bsd.*.mk assumes /usr/src and things work just fine without them. And have for years. Terry must be doing something else wrong. :-) You may be right about non-default compilers. We at timing solutions have a bunch of files that wrap bsd.*.mk that allow us to change the compiler to compile our sources. But I've always run into problems trying to do that in the past. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
