Re: Upgrading from 5.0-RELEASE to -CURRENT on sparc64
On Wed, Feb 12, 2003 at 02:46:21PM -0500, Andrew R. Reiter wrote: > I have a u60 (mp) and installed 5.0-RELEASE with the miniinst iso. I am > trying to buildworld, but am receiving: [snip] > > ... I did not script(1) this so I dont have a further backtrace (so to > speak). I can produce one if requested. > > Anyone have any thoughts? Or am I being a fool linking /usr/obj -> > /work/obj and building world in /work/arrwrk/src/ ? I had the same problem but on x86. My solution was to manually re- build world. I started out by building the libraries and then running a make includes after moving the old /usr/include out of the way. Then I built everything in gnu from the top level (/usr/src/gnu). I installed it all of course and then I ran a buildworld and it was fine afterwards. I can offer no explanation as to what was broken though: I didn't care at the time - I only cared about making it work. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf and make.conf(5)
On Wed, Nov 20, 2002 at 03:37:32PM -0500, Tom Rhodes wrote: > On Wed, 20 Nov 2002 10:10:14 -0500 > Carl Schmidt <[EMAIL PROTECTED]> wrote: > > > On Wed, Nov 20, 2002 at 09:53:35AM -0500, Tom Rhodes wrote: > > > On Wed, 20 Nov 2002 12:09:14 +0200 > > > Sheldon Hearn <[EMAIL PROTECTED]> wrote: > > > > On (2002/11/19 15:17), Carl Schmidt wrote: > > > > > > > > > The following PR has two patches attached which address the lack > > > > > of some documentation of make.conf in the manual page. It also > > > > > contains a patch for make.conf to fix style inconsistencies and > > > > > two(if I recall correctly) items which are documented in the > > > > > manual page but did not exist in the example conf. > > > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=45470 > > > > > > > > I see that Tom Rhodes has taken this one. > > > > > > > > Tom, I like this patch. When you commit it, please tidy up the > > > > new description for MAKE_SHELL, which I think is a bit more chatty > > > > than necessary. :-) > > > > > > > > Thanks, Carl. This work is always a pain in the butt to do, but > > > > readers of the manpage get very frustrated if it isn't done. > > > > > > > > Ciao, > > > > Sheldon. > > > > > > > > > > Not a problem, Sheldon. I'm going to clean up a tad bit of the > > > markup, unless Carl wants to hear my comments ;) > > > > > > I should get this done quickly. > > > > What markup are you referring to so I know in the future what not to > > do?-- > > Carl Schmidt > > > > For one, the '/' should be marked up as: > > .Pa / . > > and a hard sentence break exists (a hard sentence break is when we > don't start a new line for the new sentence) although its trivial > work. Would you like a copy of the completed patch? Nah I think I see what you mean. Thank you. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf and make.conf(5)
On Wed, Nov 20, 2002 at 09:53:35AM -0500, Tom Rhodes wrote: > On Wed, 20 Nov 2002 12:09:14 +0200 > Sheldon Hearn <[EMAIL PROTECTED]> wrote: > > On (2002/11/19 15:17), Carl Schmidt wrote: > > > > > The following PR has two patches attached which address the lack of > > > some documentation of make.conf in the manual page. It also > > > contains a patch for make.conf to fix style inconsistencies and two > > > (if I recall correctly) items which are documented in the manual > > > page but did not exist in the example conf. > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=45470 > > > > I see that Tom Rhodes has taken this one. > > > > Tom, I like this patch. When you commit it, please tidy up the > > new description for MAKE_SHELL, which I think is a bit more chatty > > than necessary. :-) > > > > Thanks, Carl. This work is always a pain in the butt to do, but > > readers of the manpage get very frustrated if it isn't done. > > > > Ciao, > > Sheldon. > > > > Not a problem, Sheldon. I'm going to clean up a tad bit of the > markup, unless Carl wants to hear my comments ;) > > I should get this done quickly. What markup are you referring to so I know in the future what not to do? -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make.conf and make.conf(5)
The following PR has two patches attached which address the lack of some documentation of make.conf in the manual page. It also contains a patch for make.conf to fix style inconsistencies and two (if I recall correctly) items which are documented in the manual page but did not exist in the example conf. http://www.freebsd.org/cgi/query-pr.cgi?pr=45470 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=116926+0+current/freebsd-doc -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Latest fetch on current broken
On Sun, Oct 27, 2002 at 10:38:36PM -0500, Craig Rodrigues wrote:
> On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
> > On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
> > > I noticed it when doing a portupgrade cdrtools
> > > So yes anything that uses fetch is not going to work
> >
> > OK, I started tracing this down.
> >
> > Here's how to get debugging versions:
> > cd /usr/src/lib/libfetch
> > make clean
> > make DEBUG_FLAGS=-g
> > make DEBUG_FLAGS=-g install
> >
> > cd /usr/src/usr.bin/fetch
> > make clean
> > make DEBUG_FLAGS=-g NOSHARED=yes
> > make DEBUG_FLAGS=-g NOSHARED=yes install
>
>
> I tracked this down further to the _fetch_writev() function
> in libfetch/common.c. Try this patch:
>
> --- lib/libfetch/common.c.origSun Oct 27 22:38:16 2002
> +++ lib/libfetch/common.c Sun Oct 27 22:40:12 2002
> @@ -525,7 +525,7 @@
> return (-1);
> }
> total += wlen;
> - while (iovcnt > 0 && wlen > iov->iov_len) {
> + while (iovcnt > 0 && wlen >= iov->iov_len) {
> wlen -= iov->iov_len;
> iov++;
> iovcnt--;
Yay, this works for me. :)
--
Carl Schmidt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol "__sF")
On Mon, Oct 14, 2002 at 12:45:41PM +0900, Makoto Matsushita wrote: > carl> 3.4 hours is a lot of time on a dial-up connection (granted it > carl> is not a one size fits all period of time). > > You forget that you still compressed image with about 30 hours (at > least, full 1 day or more), and it is not helpful for ordinal users, > not you. I fail to see how a reduction of hours (even just one) is insignificant to someone on a dial-up connection. Time is money for some people; even a meager three hours. > Again, reducing hours/percentages with compressed image doesn't > matter; please focus total download time which is actually needed for > all users. Missing the point is not helpful for the discussion. Again, I fail to see how a reduction in download time for -anyone- is insignificant. Can you explain how I am missing the point? I think it would be better to focus on whether or not the snapshot machine can even handle such a task, and, more importantly, whether the administrator even wants to do it. I e-mailed [EMAIL PROTECTED] about the task. If that is you I hope you'll forward your response to the freebsd-current list. -- Carl Schmidt [Random Quote] Be careful of reading health books, you might die of a misprint. -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol "__sF")
On Sun, Oct 13, 2002 at 10:40:20PM -0500, David W. Chapman Jr. wrote: > On Sun, Oct 13, 2002 at 11:29:32PM -0400, Carl Schmidt wrote: > > On Mon, Oct 14, 2002 at 11:43:20AM +0900, Makoto Matsushita wrote: > > > tlambert2> That's 3.4 hours saved on a 28.8K modem download time, > > > tlambert2> overall... a 14% reduction in size. > > > > > > The percentage doesn't matter. If ISO image is compressed, user who > > > downloads the image may de-compress that image to burn (I don't know > > > any about the burner softwares which support compressed ISO image). > > > What's happen if there is no space to make de-compressed image on a HDD? > > > > I do not follow this. If the user can not fit a non-compressed image > > on their drive then they certainly will not be downloading a non- > > compressed image nor a compressed image hence rendering this whole > > discussion moot for that user...it seems so to me at least. Maybe I am > > not seeing something? > > The temporary space required to do the decompression is what I am > assuming is being reference, although I'm not sure how accurate that > argument is. I did a little test to see how that works. If you gzip a file and gunzip it and follow the sizes of each file it seems that the file being de-compressed decreases in size while the new file increases in size. I think it is safe to say that gzip does not require temporary space, except an extra inode for de-compression. I could be wrong though. > > Whether we think the size is too large for dial-up or not people will > > still download it. And 200MB is absolutely nothing compared to what > > people put up with for full-size distribution ISOs. You could argue > > that not everyone has gzip (I would assume primarily a Windows user). > > As far as I know there is a DOS version of gzip. This would be where > > you might need both types of images (compressed and not compressed), > > and that is something up to the snapshots people. > > Winzip supports tar and gz, winrar supports bzip2 > > > One might argue that Mr. Lambert is simply speculating that anyone has > > a 28.8k connection anymore. What are the odds that everyone fits this: > > > > a: they live close enough to a provider to get broadband (see 'b'), > > I did not think distance was a requirement for cable modem, but I do > agree with your logic that not everyone has broadband. The distance argument is probably not relevant. I remember a long time ago some person from the UK complaining about having to use ISDN because NTL did not provide cable at that distance, or something. I honestly do not know about that. >From Qwest: <<
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol "__sF")
On Mon, Oct 14, 2002 at 11:43:20AM +0900, Makoto Matsushita wrote: > tlambert2> That's 3.4 hours saved on a 28.8K modem download time, > tlambert2> overall... a 14% reduction in size. > > The percentage doesn't matter. If ISO image is compressed, user who > downloads the image may de-compress that image to burn (I don't know > any about the burner softwares which support compressed ISO image). > What's happen if there is no space to make de-compressed image on a HDD? I do not follow this. If the user can not fit a non-compressed image on their drive then they certainly will not be downloading a non- compressed image nor a compressed image hence rendering this whole discussion moot for that user...it seems so to me at least. Maybe I am not seeing something? 3.4 hours is a lot of time on a dial-up connection (granted it is not a one size fits all period of time). > Also, the image size is still over 200MB; it is too large to fetch via > 28.8k link IMHO (saving 3.4hours doesn't help either). There are lots > of broadband connection services we can temporary buy (at airport, > starbucks, etc), so why not use it for large file downloads :-) I disagree with the first sentence; see my reply above. I simply disagree that 3.4 hours is not helpful. Whether we think the size is too large for dial-up or not people will still download it. And 200MB is absolutely nothing compared to what people put up with for full-size distribution ISOs. You could argue that not everyone has gzip (I would assume primarily a Windows user). As far as I know there is a DOS version of gzip. This would be where you might need both types of images (compressed and not compressed), and that is something up to the snapshots people. One might argue that Mr. Lambert is simply speculating that anyone has a 28.8k connection anymore. What are the odds that everyone fits this: a: they live close enough to a provider to get broadband (see 'b'), b: they can afford broadband, c: they live close enough to a Starbucks and/or airport, and d: is going to put out that kind of effort to do a-c when they can just as well hope that the snapshot server(s) have the space and power to compress an image so that they can stay in the comfort of their home with their 28.8k Internet connection? I think more than maybe is accounted for. I liken it to simply forgetting about the "others"...sort of like for a long time the blind, deaf, et cetera were left out of most people's thoughts when it came to accessibility (whether that is with computers or physical access to something). I think the FTP installation should be just fine for people with a dial-up connection if they really really really want to have -CURRENT. I've used it a few times for getting snapshots with no harm done. If the snapshot server(s) are not up to task then all of this is useless discussion. Someone ``in the know'' should simply get up and say "hey, our servers can not handle this; end of story" instead of speculating. No one has said that yet that I am aware of. As you might be able to tell I have no idea who actually runs the snapshot server(s) nor am I aware of how many, if there are more than one, there are. Sorry. Of course that's all just my opinion; I could be wrong. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New panic fun.
Decided to update my source tree today. Evidently this was not a bright
move. I built my kernel and whatnot, powered off (rebooting on my
laptop doesn't work...), and startx'ed. Then I ran mozilla.
poof
Fatal trap 9: general protection fault while in kernel mode
instruction pointer = 0x8:0xc028db0f
stack pointer = 0x10:0xd1e1c9e4
frame pointer = 0x10:0xd1e1c9e4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 665 (mozilla-bin)
Uptime: 4m53s
Dumping 255 MB
ata0: resetting devices ..
done
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
#1 0xc0190a75 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0190c4c in poweroff_wait (junk=0xc0298468, howto=-773732132)
at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc012343d in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc01233e0 in db_command (last_cmdp=0xc02ca100, cmd_table=0xc0298468,
aux_cmd_tablep=0x104, aux_cmd_tablep_end=0xc26775b0)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc01234ab in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc012599a in db_trap (type=9, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc027a982 in kdb_trap (type=9, code=0, regs=0xd1e1c9a4)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc0289358 in trap_fatal (frame=0xd1e1c9a4, eva=0)
at /usr/src/sys/i386/i386/trap.c:841
#9 0xc0288ebc in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -1078001648, tf_edi = -773731000, tf_esi =
-1033407056, tf_ebp = -773731868, tf_isp = -773731888, tf_ebx = 514, tf_edx =
-1033407056, tf_ecx = -773731696, tf_eax = -773731696, tf_trapno = 9, tf_err = 0,
tf_eip = -1071064305, tf_cs = 8, tf_eflags = 65538, tf_esp = -773731852, tf_ss =
-1071064388}) at /usr/src/sys/i386/i386/trap.c:643
#10 0xc027bd98 in calltrap () at {standard input}:98
#11 0xc028dabc in npxsetregs (td=0x0, addr=0x0)
at /usr/src/sys/i386/isa/npx.c:1000
#12 0xc028349d in set_fpcontext (td=0xc26775b0, mcp=0x0)
at /usr/src/sys/i386/i386/machdep.c:2230
#13 0xc0281ea0 in sigreturn (td=0xc26775b0, uap=0x0)
at /usr/src/sys/i386/i386/machdep.c:757
#14 0xc0289636 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 135491152, tf_ebp =
-1077942724, tf_isp = -773730956, tf_ebx = 677337812, tf_edx = 677337244, tf_ecx =
-1077942616, tf_eax = 344, tf_trapno = 22, tf_err = 2, tf_eip = 677510491, tf_cs = 31,
tf_eflags = 662, tf_esp = -1077942768, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#15 0xc027bded in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
And there you have it. I cannot begin to fathom what caused this. So far
it seems that only running mozilla causes it to occur.
I can supply more information if needed of course.
--
Carl Schmidt
[Random Quote]
Satellite Safety Tip #14:
If you see a bright streak in the sky coming at you, duck.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 08:26:03PM -0400, Robert Watson wrote: > On Sun, 6 Oct 2002, Carl Schmidt wrote: > > > > Mounting root from ufs:/dev/ad0s1a > > > > > > and hangs -- only a physical reset works. However, breaking into the > > > debugger, and running a trace, I get (hand-copied): > > Hmm. I actually ran into this problem on some diskless booting boxes, but > it went away so I assumed it was a local nit since I was messing with VFS > substantially on the boxes in question. Apparently not. (This was a > month or two ago, and quite pre-GEOM as default). > > Here's my first suggestion: the root file system is mounted by the init > process--your trace shows the stack of the current interrupt thread for > keyboard I/O, since that's the foreground thread when you break to the > debugger. Try using 'trace 1' to trace init instead; also, if you could > provide the output from the ddb ps command, that would be very useful. > BTW, you really want to be using a serial console for this sort of thing > -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). I believe you were addressing the originator of this thread but I will go ahead and show my trace/ps: db> trace 1 mi_switch(c0f014e0,cd33dca8,1,80202,c0f018f0) at mi_switch+0x1b3 ithread_schedule(c25e6b00,1) at ithread_schedule+0x10d sched_ithd(1) at sched_ithd+0x37 Xintr1() at Xintr1+0x67 --- interrupt, eip = 0xc025b5b0, esp = 0xcd33dcfc, ebp = 0xcd33dd04 --- cpu_unpend(cd33dd14,c018478d,cd33d3c,c019a750,2800) at cpu_unpend+0x28 cpu_critical_exit(cd33dd3c,c019a750,2800,1,73e) at cpu_critical_exit+0x12 critical_exit(2800,1,73e,0,c0f05c40) at critical_exit+0x21 ast(cd33dd48) at ast+0x39c doreti_ast() at doreti_ast+0x1a db> ps 33 c25dd528 cddbf000000 204 norm[SLPQ psleep c02dc580][SLP] bufdaemon 9 c25dd6e0 cddc000 20c norm[RUNQ] pagezero 8 c25dd898 cddc1000000 204 norm[SLPQ psleep c02df91c][SLP] vmdaemon 7 c25dda50 cddc2000000 204 norm[SLPQ psleep c02c9b18][SLP] pagedaemon 6 c25ddc08 cddc3000000 204 norm[SLPQ g_down c02b1a58][SLP] g_down 5 c25dddc0 cddc4000000 204 norm[SLPQg_up c02b1a54][SLP] g_up 4 c2615000 d1ddf000000 204 norm[SLPQ g_events c02b1a4c][SLP] g_event 32 c26151b8 d1de000 204 new [IWAIT] irq8: rtc 31 c2615370 d1de1000000 204 new [IWAIT] irq0: clk 30 c2615528 d1de2000000 204 norm[IWAIT] irq6: fdc0 29 c26156e0 d1de3000000 204 new [IWAIT] irq3: sio1 28 c2615898 d1de4000000 204 new [IWAIT] irq4: sio0 27 c0f071b8 cd395000000 204 new [IWAIT] swi0: tty:sio 26 c0f07370 cd396000000 204 new [IWAIT] irq12: psm0 25 c0f07528 cd397000000 204 norm[CPU 0] irq1: atkbd0 24 c0f076e0 cd398000000 204 norm[RUNQ] irq5: pcm0 23 c0f07898 cd399000000 204 norm[IWAIT] irq15: ata1 22 c0f07a50 cd39a000000 204 norm[IWAIT] irq14: ata0 3 c0f07c08 cd39b000000 204 norm[CVQ cbb cv c25e074c][SLP] cbb1 2 c0f07dc0 cd39c000000 204 norm[CVQ cbb cv c25e014c][SLP] cbb0 21 c25dd000 cdd7e000000 204 new [IWAIT] irq11: cbb0 cbb1+ 20 c25dd1b8 cdd84000000 204 norm[SLPQ nothing c042473c][SLP] acpi_thermal 19 c25dd370 cdd85000000 204 norm[IWAIT] irq9: acpi0 18 c0f0 cd319000000 204 new [IWAIT] irq13: 17 c0f001b8 cd38c000000 204 new [IWAIT] swi5: task queue 16 c0f00370 cd38d000000 204 norm[IWAIT] swi5: acpitaskq 15 c0f00528 cd38e000000 204 norm[SLPQ sleep c03e1aa0][SLP] random 14 c0f006e0 cd38f000000 204 new [IWAIT] swi1: net 13 c0f00898 cd39000 204 new [IWAIT] swi4: vm 12 c0f00a50 cd391000000 20c norm[IWAIT] swi6: tty:sio clock 11 c0f00c08 cd392000000 20c norm[Can run] idle 1 c0f00dc0 cd393000000 0004200 norm[RUNQ] init 10 c0f07000 cd394000000 204 norm[CVQ ktrace c02d7c44][SLP] ktrace 0 c02b2780 c0453000000 200 norm[SLPQ sched c02b2780][SLP] swapper -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 05:08:00PM -0600, Seth Hieronymus wrote:
> Hello,
>
> After recompiling a kernel after the GEOM transition, my boot gets as
> far as:
>
> Initializing GEOMetry subsystem
> ad0: 28629MB [58168/16/63] at ata0-master UDMA33
> acd0: CDROM at ata1-master PIO4
> afd0: 239MB [239/64/32] at ata1-slave PIO3
> Mounting root from ufs:/dev/ad0s1a
>
> and hangs -- only a physical reset works. However, breaking into the
> debugger, and running a trace, I get (hand-copied):
>
> Debugger("manual escape to debugger")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c0331a32,4,1,0,1) at Debugger+0x54
> scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445
> sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0
> atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c
> atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21
> ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at
> ithread_loop+0x182
> fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5
> fork_trampoline() at fork_trampoline+0x1a
> --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 ---
>
> Am I doing something wrong here? Thanks for any help. My pre-GEOM
> dmesg, and kernel config follow. A kernel and world from the day before
> the GEOM switch works fine.
I also have the aforementioned problem. I had this problem several
months before GEOM was enabled so I can not vouch for it being GEOM-
related. Any time I trace after this apparent hang I get a mostly
identical trace as you have shown. I have no idea why it happens. I
only know that it happens only with FreeBSD on my laptop. No other
operating system I have tried on it has this problem. Unfortunately I
cannot be more verbose (that I am aware of) than the trace. I have
been unsuccessful at forcing a core dump, and I do not know why.
I am at the point where if someone offers an idea to get more
information I could possily be more useful. I will try adding printf's
where I think would be useful but this is a needle in a haystack issue
for me since I am not 100% aware of the internals.
--
Carl Schmidt
[Random Quote]
Be different: conform.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
GEOM
ons UFS_DIRHASH options COMPAT_43 options COMPAT_FREEBSD4 options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options INCLUDE_CONFIG_FILE options DDB options ATA_STATIC_ID options RANDOM_IP_ID options TCP_DROP_SYNFIN options ZERO_COPY_SOCKETS options PSM_HOOKRESUME options PSM_RESETAFTERSUSPEND options SC_ALT_MOUSE_IMAGE options SC_HISTORY_SIZE=512 options SC_PIXEL_MODE options SC_KERNEL_CONS_ATTR="(FG_GREEN|BG_BLACK)" options SC_TWOBUTTON_MOUSE options GEOM device isa device eisa device pci device fdc device ata device atadisk device atapicd device atkbdc device atkbd device psm device vga device splash device sc device npx device pmtimer device cbb device pccard device cardbus device sio device loop device ether device pty device bpf -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Mon, Sep 23, 2002 at 09:43:59PM -0700, Kris Kennaway wrote: > Yes, I expect the problem will be resolved by those who have already > said they'll resolve it ;) Okay good. I obviously missed a lot of the discussion on this. While we're at it someone should close PR 43317 since I am a fucking idiot and don't know what is going on. Bleh. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Tue, Sep 24, 2002 at 12:37:24AM -0400, Carl Schmidt wrote: > On Mon, Sep 23, 2002 at 09:34:07PM -0700, Kris Kennaway wrote: > > On Tue, Sep 24, 2002 at 12:10:23AM -0400, Carl Schmidt wrote: [...] > Right, okay. But NetBSD's sort actually works. I should rephrase this ... NetBSD's sort works with the current world setup. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Mon, Sep 23, 2002 at 09:34:07PM -0700, Kris Kennaway wrote: > On Tue, Sep 24, 2002 at 12:10:23AM -0400, Carl Schmidt wrote: > > > Get rid of gnu-sort from contrib and use NetBSD's sort, which was > > imported five months ago but apparently never incorporated into the > > build process. > > It was, briefly, but was backed out because it's not a sufficiently > complete replacement for everyone's liking. > > > Gnu-sort does not appear to understand +# arguments whereas NetBSD's > > sort does. > > It's actually a case of NetBSD's sort not disabling non-standard > behaviour when you ask it to. Right, okay. But NetBSD's sort actually works. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A different light, perhaps.
On Mon, Sep 23, 2002 at 08:28:06PM -0700, walt wrote: > Carl Schmidt wrote: > > After running cvsup at about 5PM > > EDT (September 23, 2002 -- using cvsup3) and running a full build I am > > happy to report that everything worked fine... > > In an attempt to understand this black magic we practice every day > could I ask you to do two quick experiments for me? Heh... > 1. Type 'sort +1' at any command prompt. What do you see? > > 2. cd /usr/src/lib/libncurses > make clean && make > What do you see? >[Warning: this may break your world on the next go-round.] Okay I ran into the same problems everyone else ran into and I have a solution. Get rid of gnu-sort from contrib and use NetBSD's sort, which was imported five months ago but apparently never incorporated into the build process. Gnu-sort does not appear to understand +# arguments whereas NetBSD's sort does. This solved the problem for me. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
A different light, perhaps.
There seems to be many complaints of things being broken. Maybe I'm just lucky and never cvsup when things are broken. I have encountered -no- errors over the past month when building world and kernel. So anyway to add to that I'd just like to report on today's build so as to balance things out. After running cvsup at about 5PM EDT (September 23, 2002 -- using cvsup3) and running a full build I am happy to report that everything worked fine. No war stories to speak of. laptop% uname -a FreeBSD laptop.slackerbsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Sep 23 19:20:39 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP i386 Now if only my laptop would stop overheating whenever I run FreeBSD on it. That is all. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
