Re: cd writer recommendation?
Hi, >Any one care to recommend a CD writer for FreeBSD-current since thats >typically what I run over here. Yamaha CRW4416S "just works" with -current and cdrecord, both for CD-R and CD-RW. -- Bob Bishop +44 118 977 4017 [EMAIL PROTECTED]fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Most Cool! Is there a list of IDE cd writers which work FreeBSD? Tnks Again! > On Mon, 16 Aug 1999, Amancio Hasty wrote: > > > > > Sorry about that . The emphasis is more on the hardware and second is the > > software -- I usually get around problems with the software. > > > > Mkisofs is good for creating an ISO 9660 file systems. Wormcontrol and > dd are a good combination for writing them. > > > Is there any support for IDE CD writers or are they not worth bothering with > > on FreeBSD. > > > > Yes, there is support for them :) > > > Tnks! > > > > > On Sun, 15 Aug 1999, Amancio Hasty wrote: > > > > > > > > > > > Any one care to recommend a CD writer for FreeBSD-current since thats > > > > typically what I run over here. > > > > > > Are you asking for recommendation about hardware or software? It's not > > > evident from your wording. > > > > > > > > > > > Tnks > > > > -- > > > > > > > > Amancio Hasty > > > > [EMAIL PROTECTED] > > > > > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > > > [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > > > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | > > >http://www.FreeBSD.org/ _ |___/___/___/ > > > > > > > -- > > > > Amancio Hasty > > [EMAIL PROTECTED] > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | >http://www.FreeBSD.org/ _ |___/___/___/ > -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
On Mon, 16 Aug 1999, Amancio Hasty wrote: > > Sorry about that . The emphasis is more on the hardware and second is the > software -- I usually get around problems with the software. > Mkisofs is good for creating an ISO 9660 file systems. Wormcontrol and dd are a good combination for writing them. > Is there any support for IDE CD writers or are they not worth bothering with > on FreeBSD. > Yes, there is support for them :) > Tnks! > > > On Sun, 15 Aug 1999, Amancio Hasty wrote: > > > > > > > > Any one care to recommend a CD writer for FreeBSD-current since thats > > > typically what I run over here. > > > > Are you asking for recommendation about hardware or software? It's not > > evident from your wording. > > > > > > > > Tnks > > > -- > > > > > > Amancio Hasty > > > [EMAIL PROTECTED] > > > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > > [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | > >http://www.FreeBSD.org/ _ |___/___/___/ > > > > -- > > Amancio Hasty > [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
"Brian F. Feldman" wrote: > > : I suppose, but wouldn't the proper place be under machdep? I agree that > > : a linux top-level MIB would be easiest to remember. > > > > Linux isn't machdep. It is MI since we could have Linux/Alpha or > > Linux/MIPS emulators... > > Well then, we need to move it a directory level and take out machine > dependencies, and make it machine independent. A split of the Linux sources has been discussed already and isn't the issue here. Please stay on topic or change the subject. -- Marcel Moolenaar mailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ Amsterdam, The Netherlands tel: +31 20 4200655 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Sorry about that . The emphasis is more on the hardware and second is the software -- I usually get around problems with the software. Is there any support for IDE CD writers or are they not worth bothering with on FreeBSD. Tnks! > On Sun, 15 Aug 1999, Amancio Hasty wrote: > > > > > Any one care to recommend a CD writer for FreeBSD-current since thats > > typically what I run over here. > > Are you asking for recommendation about hardware or software? It's not > evident from your wording. > > > > > Tnks > > -- > > > > Amancio Hasty > > [EMAIL PROTECTED] > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | >http://www.FreeBSD.org/ _ |___/___/___/ > -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
On Sun, 15 Aug 1999, Amancio Hasty wrote: > > Any one care to recommend a CD writer for FreeBSD-current since thats > typically what I run over here. Are you asking for recommendation about hardware or software? It's not evident from your wording. > > Tnks > -- > > Amancio Hasty > [EMAIL PROTECTED] Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Amancio Hasty wrote: > > Any one care to recommend a CD writer for FreeBSD-current since thats > typically what I run over here. Well, im using a Sony 948S here, works fine under -CURRENT with GCOMBUST (as a front end to mkisofs, mkhybridfs and cdrecord).. except that GCOMBUST occasionally cant figure out the target, rerunning it seems to get past this minor problem. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cd writer recommendation?
Any one care to recommend a CD writer for FreeBSD-current since thats typically what I run over here. Tnks -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
On Sun, 15 Aug 1999, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Brian F. >Feldman" writes: > : I suppose, but wouldn't the proper place be under machdep? I agree that > : a linux top-level MIB would be easiest to remember. > > Linux isn't machdep. It is MI since we could have Linux/Alpha or > Linux/MIPS emulators... Well then, we need to move it a directory level and take out machine dependencies, and make it machine independent. > > Warner > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]> Mike Smith writes: : We're staying away from the term "emulation" because it's being : associated with things like the abominable 'lxrun' and virtual-machine : emulators like VMware. Also, there is a perception that "emulation" is slower than native, which isn't the case for the Linux ABI in FreeBSD. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]> "Brian F. Feldman" writes: : I suppose, but wouldn't the proper place be under machdep? I agree that : a linux top-level MIB would be easiest to remember. Linux isn't machdep. It is MI since we could have Linux/Alpha or Linux/MIPS emulators... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message <[EMAIL PROTECTED]> Narvi writes: : It's more the argument of "why do it *significantly* differently from : others?" VMS has done the PTYx: since the mid 80's :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message <[EMAIL PROTECTED]>, Greg Lehey writes: >On Sunday, 15 August 1999 at 12:27:57 +0200, Poul-Henning Kamp wrote: >> >> Well, autumn and winter is on us pretty soon. At least on my >> lattitude that means hot tea inside warm and cosy houses while the >> elements do their best to make life misserable for anything still >> left on the outside. >> >> Here are some tasks which could put an evening or more to >> productive and educational use for interested kernel hackers. >> >> They may also make a nice assignment for CS classes. >> >> 1. [easy] The SLIP device/interface could use the same >> makeover as tun, bpf and pty has received. (see also #5) > >Care to explain (read: document) the makeover? That would make this >and the following tasks even simpler. Please examine the most recent commit to tun, bpf or pty. That is much easier than me explaining it. >> 7. [medium] The current naming for ptys doesn't scale that >> well. Changing it to ttyp%d / pty%d would probably be a >> good idea in the long run, but the ramifications are >> relatively widespread (think: "ports") > >Is there any reason not to have both names, at least for the first 256 >devices? Size of /dev directory maybe ? I dunno, who ever implements this can do it however they like... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hacker tasks seek interested hackers
< said: > Here are some tasks which could put an evening or more to > productive and educational use for interested kernel hackers. But by all means, if you start on one of these, TELL someone about it, eh? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
On Sunday, 15 August 1999 at 12:27:57 +0200, Poul-Henning Kamp wrote: > > Well, autumn and winter is on us pretty soon. At least on my > lattitude that means hot tea inside warm and cosy houses while the > elements do their best to make life misserable for anything still > left on the outside. > > Here are some tasks which could put an evening or more to > productive and educational use for interested kernel hackers. > > They may also make a nice assignment for CS classes. > > 1. [easy] The SLIP device/interface could use the same > makeover as tun, bpf and pty has received. (see also #5) Care to explain (read: document) the makeover? That would make this and the following tasks even simpler. > 7. [medium] The current naming for ptys doesn't scale that > well. Changing it to ttyp%d / pty%d would probably be a > good idea in the long run, but the ramifications are > relatively widespread (think: "ports") Is there any reason not to have both names, at least for the first 256 devices? Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
Narvi wrote: > > > >So why not instead: > > > > I think that is needlessly complicated. > > It's a direct extension to the present tty naming scheme. That's what he said: it's needlessly complicated. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "You intend to eat me, then?" he asked the dragon. "Well, I must admit, more for the amusement than the taste." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make of vic broken in current
> excuse previous gibberish. i am at a loss as to how it happened, maybe vm > dealing with a very long line. i hope it is not reproducable. > > -current as of 99.08.14 could it be the compiler was upgraded recently ? I wrote grabber-x11.cc but i am far from being C++ literate so the most i could do is check that it would compile on the platform i was using (2.2.x at the time). Some review and cleanup from someone who knows C++ would be very welcome. cheers luigi > > c++ -O2 -DUSE_SHM -DED_YBITS=4 -DSIGRET=void -I/usr/local/include/tk8.0 \ > -I/usr/local/include/tcl8.0 -I/usr/X11R6/include -I./jpeg -I./p64 -I. \ > -o vic inet.o cellb_tables.o tkStripchart.o md5c.o random.o main.o net.o \ > net-ip.o source.o iohandler.o timer.o idlecallback.o media-timer.o \ > session.o session-rtpv1.o session-nv.o session-ivs.o decoder.o \ > decoder-jpeg.o decoder-nv.o decoder-h261.o decoder-h261v1.o \ > decoder-cellb.o device.o grabber.o vw.o Tcl.o Tcl2.o module.o \ > transmitter.o encoder-nv.o encoder-cellb.o encoder-h261.o \ > transcoder-jpeg.o framer-jpeg.o group-ipc.o confbus.o renderer.o \ > renderer-window.o color.o color-true.o color-pseudo.o color-dither.o \ > color-ed.o color-quant.o color-hi.o color-gray.o color-mono.o \ > color-hist.o rgb-converter.o jpeg/jpeg.o p64/p64.o dct.o compositor.o \ > rate-variable.o crypt.o crypt-dull.o grabber-still.o cm0.o cm1.o \ > huffcode.o version.o bv.o ui-ctrlmenu.o ui-main.o ui-resource.o \ > ui-srclist.o ui-stats.o ui-util.o ui-windows.o ui-switcher.o ui-extout.o \ > ui-grabber.o ui-unix.o cf-main.o cf-tm.o cf-confbus.o cf-network.o \ > cf-util.o tkerror.o entry.o tk.o strtol.o strtoul.o grabber-x11.cc \ > grabber-meteor.o -L/usr/local/lib -ltk80 -L/usr/local/lib -ltcl80 \ > -L/usr/X11R6/lib -lXext -lX11 -lm > grabber-x11.cc: In method `X11Device::X11Device(const char *)': > grabber-x11.cc:194: warning: the address of `free(void *)', will always be `true' > grabber-x11.cc: In method `int X11Grabber::X11Grab_Initialize(Window, int, int)': > grabber-x11.cc:572: warning: assuming & on `X11Grabber::X11Grab_LSBWhite1()' > grabber-x11.cc:572: warning: assuming & on `X11Grabber::X11Grab_MSBWhite1()' > grabber-x11.cc:574: warning: assuming & on `X11Grabber::X11Grab_LSBBlack1()' > grabber-x11.cc:574: warning: assuming & on `X11Grabber::X11Grab_MSBBlack1()' > grabber-x11.cc:585: warning: assuming & on `X11Grabber::X11Grab_Pseudo8()' > grabber-x11.cc:595: warning: assuming & on `X11Grabber::X11Grab_RGB16()' > grabber-x11.cc:609: warning: assuming & on `X11Grabber::X11Grab_TrueXBGR24()' > grabber-x11.cc:627: warning: implicit declaration of function `int >VidUtil_DestroyXImage(...)' > grabber-x11.cc: In method `X11Grabber::X11Grabber(const char *, const char *)': > grabber-x11.cc:1014: warning: assignment to `int8 *' from `uint8 *' changes >signedness > grabber-x11.cc:1015: warning: assignment to `int8 *' from `uint8 *' changes >signedness > grabber-x11.cc: In method `int X11Grabber::capture()': > grabber-x11.cc:1188: warning: implicit declaration of function `int >XShmGetImage(...)' > grabber-x11.cc:1194: must use .* or ->* to call pointer-to-member function in >`X11Grabber::c_grab (...)' > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-multimedia" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make cvsup broken
===> Cleaning for cvsup-16.0 To build this port without X11 (and without the GUI), define "NO_X11". >> cvsup-16.0.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/. Receiving cvsup-16.0.tar.gz (342698 bytes): 100% 342698 bytes transferred in 6.7 seconds (49.86 Kbytes/s) ===> Extracting for cvsup-16.0 >> Checksum OK for cvsup-16.0.tar.gz. ===> cvsup-16.0 depends on executable: m3build-6 - found ===> cvsup-16.0 depends on shared library: m3.6 - found ===> Patching for cvsup-16.0 ===> Configuring for cvsup-16.0 ===> Building for cvsup-16.0 mkdir FreeBSD2 --- building in FreeBSD2 --- ===> suptcp m3build mkdir FreeBSD2 --- building in FreeBSD2 --- m3 -w1 -why -O -a libsuptcp.a -F/var/tmp/qkG99460 new source -> compiling ../src/common/SupConnFD.i3 new source -> compiling ../src/common/SupTCP.i3 new source -> compiling ../src/POSIX/SupTCPPosix.i3 new source -> compiling ../src/POSIX/SupTCPHack.i3 new source -> compiling ../src/POSIX/SockOpt.i3 new source -> compiling ../src/common/TCPMisc.i3 new source -> compiling ../src/common/SupConnRW.i3 new source -> compiling ../src/POSIX/SupTCP.m3 new source -> compiling ../src/POSIX/SupTCPHackNull.m3 new source -> compiling ../src/POSIX/SockOptFBSD.m3 new source -> compiling ../src/common/SupConnRW.m3 -> archiving libsuptcp.a ===> suplib m3build mkdir FreeBSD2 --- building in FreeBSD2 --- m3 -w1 -why -O -a libsuplib.a -F/var/tmp/qkH99492 new source -> compiling ../src/FreeBSD/FileAttrOS.i3 new source -> compiling ../src/FreeBSD/UProcTitle.i3 new source -> compiling ../src/FreeBSD/UProcTitle.c new source -> compiling ../src/libglob/fnmatch.c new source -> compiling ../src/Uglob.i3 new source -> compiling ../src/PathComp.i3 new source -> compiling ../src/ChannelMux.i3 new source -> compiling ../src/Logger.i3 new source -> compiling ../src/LoggerClass.i3 new source -> compiling ../src/SplitLogger.i3 new source -> compiling ../src/SysLogger.i3 new source -> compiling ../src/TimeStampLogger.i3 new source -> compiling ../src/WrLogger.i3 new source -> compiling ../src/ProcTitle.i3 new source -> compiling ../src/Ugzip.i3 new source -> compiling ../src/UgzipP.i3 new source -> compiling ../src/Umd5.i3 new source -> compiling ../src/MySyslog.i3 new source -> compiling ../src/WatchDog.i3 new source -> compiling ../src/IOWatchDog.i3 new source -> compiling ../src/MD5Digest.i3 new source -> compiling ../src/MD5.i3 new source -> compiling ../src/AuthMD5.i3 new source -> compiling ../src/TokScan.i3 new source -> compiling ../src/DevT.i3 new source -> compiling ../src/FileAttr.i3 new source -> compiling ../src/FileAttrRep.i3 new source -> compiling ../src/FileID.i3 new source -> compiling ../src/CVProto.i3 new source -> compiling ../src/EscapedRd.i3 new source -> compiling ../src/EscapedWr.i3 new source -> compiling ../src/MD5Wr.i3 new source -> compiling ../src/ErrMsg.i3 new source -> compiling ../src/DirEntry.i3 new source -> compiling DirEntryList.i3 new source -> compiling DirEntryListSort.i3 new source -> compiling ../src/Glob.i3 new source -> compiling ../src/GlobTree.i3 new source -> compiling ../src/LockFile.i3 new source -> compiling ../src/ExecRec.i3 new source -> compiling ExecRecSeq.i3 new source -> compiling ExecRecSeqRep.i3 new source -> compiling ../src/RCSError.i3 new source -> compiling ../src/RCSString.i3 new source -> compiling ../src/RCSPhrase.i3 new source -> compiling ../src/RCSPhrases.i3 new source -> compiling ../src/RCSDate.i3 new source -> compiling ../src/RCSRevNum.i3 new source -> compiling ../src/RCSTag.i3 new source -> compiling RCSTagList.i3 new source -> compiling RCSTagListSort.i3 new source -> compiling ../src/RCSEdit.i3 new source -> compiling RCSEditTbl.i3 new source -> compiling SortedRCSEditTbl.i3 new source -> compiling ../src/RCSDelta.i3 new source -> compiling ../src/RCSKeyword.i3 new source -> compiling RCSDeltaTbl.i3 new source -> compiling ../src/RCSFile.i3 new source -> compiling RCSDeltaList.i3 new source -> compiling ../src/RCSDeltaClass.i3 new source -> compiling RCSDeltaListSort.i3 new source -> compiling SortedRCSDeltaTbl.i3 new source -> compiling ../src/SupFileRec.i3 new source -> compiling ../src/SupMisc.i3 new source -> compiling ../src/FileStatus.i3 new source -> compiling ../src/FileStatusRaw.i3 new source -> compiling ../src/StatusFile.i3 new source -> compiling ../src/CVTree.i3 new source -> compiling ../src/GzipError.i3 new source -> compiling ../src/GzipRd.i3 new source -> compiling ../src/GzipWr.i3 new source -> compiling ../src/RsyncBlock.i3 new source -> compiling RsyncBlockArraySort.i3 new source -> compiling ../src/RsyncFile.i3 new source -> compiling ../src/Reaper.i3 new source -> compiling ../src/SigHandler.i3 new source -> compiling ../src/UnixMisc.i3 new source -> compiling ../src/UnixMiscC.c new source -> compiling ../src/Attic.i3 new source -> compiling ../src/FreeBSD/FileAttrOS.m3 new source -> compiling ../src/FreeBSD/ProcTitl
make of vic broken in current
excuse previous gibberish. i am at a loss as to how it happened, maybe vm dealing with a very long line. i hope it is not reproducable. -current as of 99.08.14 c++ -O2 -DUSE_SHM -DED_YBITS=4 -DSIGRET=void -I/usr/local/include/tk8.0 \ -I/usr/local/include/tcl8.0 -I/usr/X11R6/include -I./jpeg -I./p64 -I. \ -o vic inet.o cellb_tables.o tkStripchart.o md5c.o random.o main.o net.o \ net-ip.o source.o iohandler.o timer.o idlecallback.o media-timer.o \ session.o session-rtpv1.o session-nv.o session-ivs.o decoder.o \ decoder-jpeg.o decoder-nv.o decoder-h261.o decoder-h261v1.o \ decoder-cellb.o device.o grabber.o vw.o Tcl.o Tcl2.o module.o \ transmitter.o encoder-nv.o encoder-cellb.o encoder-h261.o \ transcoder-jpeg.o framer-jpeg.o group-ipc.o confbus.o renderer.o \ renderer-window.o color.o color-true.o color-pseudo.o color-dither.o \ color-ed.o color-quant.o color-hi.o color-gray.o color-mono.o \ color-hist.o rgb-converter.o jpeg/jpeg.o p64/p64.o dct.o compositor.o \ rate-variable.o crypt.o crypt-dull.o grabber-still.o cm0.o cm1.o \ huffcode.o version.o bv.o ui-ctrlmenu.o ui-main.o ui-resource.o \ ui-srclist.o ui-stats.o ui-util.o ui-windows.o ui-switcher.o ui-extout.o \ ui-grabber.o ui-unix.o cf-main.o cf-tm.o cf-confbus.o cf-network.o \ cf-util.o tkerror.o entry.o tk.o strtol.o strtoul.o grabber-x11.cc \ grabber-meteor.o -L/usr/local/lib -ltk80 -L/usr/local/lib -ltcl80 \ -L/usr/X11R6/lib -lXext -lX11 -lm grabber-x11.cc: In method `X11Device::X11Device(const char *)': grabber-x11.cc:194: warning: the address of `free(void *)', will always be `true' grabber-x11.cc: In method `int X11Grabber::X11Grab_Initialize(Window, int, int)': grabber-x11.cc:572: warning: assuming & on `X11Grabber::X11Grab_LSBWhite1()' grabber-x11.cc:572: warning: assuming & on `X11Grabber::X11Grab_MSBWhite1()' grabber-x11.cc:574: warning: assuming & on `X11Grabber::X11Grab_LSBBlack1()' grabber-x11.cc:574: warning: assuming & on `X11Grabber::X11Grab_MSBBlack1()' grabber-x11.cc:585: warning: assuming & on `X11Grabber::X11Grab_Pseudo8()' grabber-x11.cc:595: warning: assuming & on `X11Grabber::X11Grab_RGB16()' grabber-x11.cc:609: warning: assuming & on `X11Grabber::X11Grab_TrueXBGR24()' grabber-x11.cc:627: warning: implicit declaration of function `int VidUtil_DestroyXImage(...)' grabber-x11.cc: In method `X11Grabber::X11Grabber(const char *, const char *)': grabber-x11.cc:1014: warning: assignment to `int8 *' from `uint8 *' changes signedness grabber-x11.cc:1015: warning: assignment to `int8 *' from `uint8 *' changes signedness grabber-x11.cc: In method `int X11Grabber::capture()': grabber-x11.cc:1188: warning: implicit declaration of function `int XShmGetImage(...)' grabber-x11.cc:1194: must use .* or ->* to call pointer-to-member function in `X11Grabber::c_grab (...)' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
>> "MS" == Mike Smith <[EMAIL PROTECTED]> writes: >> >> "MS" == Mike Smith <[EMAIL PROTECTED]> writes: >> >> >> Then after 5 seconds the screen blanks, the power light starts >> >> flashing (indicating suspend mode), but when I hit a key, the >> >> console says (slept 00:00:02) only, and programs in fact >> >> continued running (thus it didn't go or remain in suspend mode >> >> at all). >> MS> I think you'll find that programs didn't, in fact, continue MS> running; rather they paused and then resumed when you came out MS> of suspend. >> >> I'm running seti@home, and it really continued while my >> computer was 'suspended'. Also a little test program continued >> running. MS> What you're failing to offer here, and thus why I remain MS> skeptical, is any evidence that suggests that these programs MS> were "running" while the system believed itself to be MS> suspended. I can see that after one hour of 'suspend' mode, the program has done for one hour worth of calculations. Really, I am not insane and know when my programs have run and done work and when not. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make of vic broken in current
c++ -O2 -DUSE_SHM -DED_YBITS=4 -DSIGRET=void -I/usr/local/include/tk8.0
-I/usr/local/include/tcl8.0 -I/usr/X11R6/include -I./jpeg -I./p64 -I. -o vic inet.o
cellb_tables.o tkStripchart.o md5c.o random.o main.o net.o net-ip.o source.o
iohandler.o timer.o idlecallback.o media-timer.o session.o session-rtpv1.o
session-nv.o session-ivs.o decoder.o decoder-jpeg.o decoder-nv.o decoder-h261.o
decoder-h261v1.o decoder-cellb.o device.o grabber.o vw.o Tcl.o Tcl2.o module.o
transmitter.o encoder-nv.o encoder-cellb.o encoder-h261.o transcoder-jpeg.o
framer-jpeg.o group-ipc.o confbus.o renderer.o renderer-window.o color.o
color-true.o color-pseudo.o color-dither.o color-ed.o color-quant.o color-hi.o
color-gray.o color-mono.o color-hist.o rgb-converter.o jpeg/jpeg.o p64/p64.o dct.o
compositor.o rate-variable.o crypt.o crypt-dull.o grabber-still.o cm0.o cm1.o
huffcode.o version.o bv.o ui-ctrlmenu.o ui-main.o ui-resource.o ui-srclist.o
ui-stats.o ui-util.o ui-windows.o ui-switcher.o ui-extout.o ui-grabber.o ui-unix.o
cf-main.o cf-tm.o cf-confbus.o cf-network.o cf-util.o tkerror.o entry.o tk.o strtol.o
strtoul.o grabber-x11.cc grabber-meteor.o -L/usr/local/lib -ltk80 -L/usr/local/lib
-ltcl80 -L/usr/X11R6/lib -lXext -lX11 -lm
grabber-x11.cc: In method `X11Device::X11Device(const char *)':
grabber-x11.cc:194: warning: the address of `free(void *)', will always be `true'
grabber-x11.cc: In method `int X11Grabber::X11Grab_Initialize(Window, int, int)':
grabber-x11.cc:572: warning: assuming & on `X11Grabber::X11Grab_LSBWhite1()'
grabber-x11.cc:572: warning: assuming & on `X11Grabber::X11Grab_MSBWhite1()'
grabber-x11.cc:574: warning: assuming & on `X11Grabber::X11Grab_LSBBlack1()'
grabber-x11.cc:574: warning: assuming & on `X11Grabber::X11Grab_MSBBlack1()'
grabber-x11.cc:585: warning: assuming & on `X11Grabber::X11Grab_Pseudo8()'
grabber-x11.cc:595: warning: assuming & on `X11Grabber::X11Grab_RGB16()'
grabber-x11.cc:609: warning: assuming & on `X11Grabber::X11Grab_TrueXBGR24()'
grabber-x11.cc:627: warning: implicit declaration of function `int
VidUtil_DestroyXImage(...)'
grabber-x11.cc: In method `X11Grabber::X11Grabber(const char *, const char *)':
grabber-x11.cc:1014: warning: assignment to `int8 *' from `uint8 *' changes signedness
grabber-x11.cc:1015: warning: assignment to `int8 *' from `uint8 *' changes signedness
grabber-x11.cc: In method `int X11Grabber::capture()':
grabber-x11.cc:1188: warning: implicit declaration of function `int XShmGetImage(...)'
grabber-x11.cc:1194: must use .* or ->* to call pointer-to-member function in
`X11Grabber::c_grab (...)'
*** Error code 1
i suspect the latter form is what is desired, but am not sure.
randyN
'²æìr¸{û Ù[h¨èÚ&£ñkyàRú+û§²æìr¸yúÞy» ýË«éíþ)í
æèw* ¶¦zË
Re: rm works not properly
Dominik Rothert wrote: > Hello CURRENT-users, > > I noticed following (mysterious) behaviour today: > > [ snip ] > > <1> dr@speed:~ $ rm -rf test/ > rm: test: Operation not permitted > rm: test: Directory not empty This was caused by my fix to fts.c. I have reverted to revision 1.8. Sorry for the inconvenience. Regards, -- Peter Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pex5 and xie load errors
On Sun, 15 Aug 1999, Brian F. Feldman wrote: > Well, by "they" I hope you don't intend to mean modules in general. I am > happily using my Riva TNT with XFree86 3.3.3.1, which is a module (the GLX): > I mean specificly the pex.so module (xie module also usewd to be broken). > So what are the specific errors you get? > Unknown error loading module. Nothing more specific. I guess either everybody using pex on freebsd has fixed it for themselves or there are no such people. It is broken for many-many months. > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | >http://www.FreeBSD.org/ _ |___/___/___/ > > Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
> Hi, > > There're a couple of variables in the Linuxulator that can be put under > sysctl. These include the kernel version and the OSS version, among > probably others. > > The question is simply were in the MIB to put them? > 1) under "kern.linux" > 2) under "kern.emu.linux" > 3) under "linux" > 4) non of the above, because... kern.abi.linux or kern.compat.linux. We're staying away from the term "emulation" because it's being associated with things like the abominable 'lxrun' and virtual-machine emulators like VMware. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]>, "Brian F. Feldman" writes: >On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: > >> >The question is simply were in the MIB to put them? >>... >> >3) under "linux" >> >> I vote for 3. > >I suppose, but wouldn't the proper place be under machdep? I agree that >a linux top-level MIB would be easiest to remember. We may have to emulate linux on other platforms as well... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pex5 and xie load errors
On Sun, 15 Aug 1999, Narvi wrote: > > On Sat, 14 Aug 1999, Randy Bush wrote: > > > during X startup i get load errors for these. but i can see nothing unappy > > with X. do i > > delete them from /etc/XF86Config > > or > > rebuild X > > or > > what? > > > > Rebuilding X won't help last I tried. They have been broken for quite some > time now. Seems there aren't enough people who care enough. Well, by "they" I hope you don't intend to mean modules in general. I am happily using my Riva TNT with XFree86 3.3.3.1, which is a module (the GLX): Section "Module" Load "glx.so" EndSection (**) stands for supplied, (--) stands for probed/default values (--) no ModulePath specified using default: /usr/X11R6/lib/modules GLX extension module for XFree86 3.3.3.1 -- Mesa version 3.0 GLX package version 0.9, GLX protocol version 1.2. (**) module glx.so successfully loaded from /usr/X11R6/lib/modules So what are the specific errors you get? > > randy > > > > Sander > > There is no love, no good, no happiness and no future - > all these are just illusions. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: > >The question is simply were in the MIB to put them? >... > >3) under "linux" > > I vote for 3. I suppose, but wouldn't the proper place be under machdep? I agree that a linux top-level MIB would be easiest to remember. > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pex5 and xie load errors
On Sat, 14 Aug 1999, Randy Bush wrote: > i just upgraded to current. i still have the following in my > /etc/XF86Config > > Section "Module" > Load"pex5.so" > Load"xie.so" > EndSection > > during X startup i get load errors for these. but i can see nothing unappy > with X. do i > delete them from /etc/XF86Config > or > rebuild X > or > what? > Rebuilding X won't help last I tried. They have been broken for quite some time now. Seems there aren't enough people who care enough. > thanks. > > randy > Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
:>2) under "kern.emu.linux" :>3) under "linux" : :I vote for 3. : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." :FreeBSD -- It will take a long time before progress goes too far! Ditto. Linux emulation is going to become increasingly important, burying deep would just make everyone's life more difficult. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes: >Hi, > >There're a couple of variables in the Linuxulator that can be put under >sysctl. These include the kernel version and the OSS version, among >probably others. > >The question is simply were in the MIB to put them? >1) under "kern.linux" >2) under "kern.emu.linux" >3) under "linux" I vote for 3. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Q: Extending the sysctl MIB for Linuxulator variables
Hi, There're a couple of variables in the Linuxulator that can be put under sysctl. These include the kernel version and the OSS version, among probably others. The question is simply were in the MIB to put them? 1) under "kern.linux" 2) under "kern.emu.linux" 3) under "linux" 4) non of the above, because... thanks, -- Marcel Moolenaar mailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ Amsterdam, The Netherlands tel: +31 20 4200655 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message <[EMAIL PROTECTED]>, Narvi writes: >> I think that is needlessly complicated. > >It's a direct extension to the present tty naming scheme. That doesn't automatically imply that it is a good idea :-) >> I think tty%05d would solve all but the third of your objections, > >The first was more a question of radix, implying that 10 might be too low. You know, then make it tty%012d and pretty much everybody on this planet should be happy, right ? >IMHO base-32 has many good qualities to itself. It makes retaining the >policy of creating ptys in increments of 32 easy, the name space does not >grow as fast (pty allows for more ptys than pty%06d) and it is not >much different from the naming system. There is no "policy of creating ptys in increments of 32" that I know of. /dev/MAKEDEV does it that way, but it is neither a policy nor desirable in my mind. I would far rather have it like tun, bpf and other sane pseudodevices: sh MAKEDEV pty200 # Make me 200 ptys. >> and quite frankly the "we've never done that before" argument >> works badly with me. > >It's more the argument of "why do it *significantly* differently from >others?" Run that by me again: what is it ptys are called under Solaris, HPUX, AIX, generic SVR4 etc etc ? I think your suggestion belongs in the Obfuscated Sysadm Contest, not in FreeBSD. I'm also pretty convinced based on your past performances that you intend to argue this point until cows evolve into birds, so expect no more emails from me on this subject. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Narvi >writes: > > > >On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: > > > >[snip] > > > >> > >> 7. [medium] The current naming for ptys doesn't scale that > >>well. Changing it to ttyp%d / pty%d would probably be a > >>good idea in the long run, but the ramifications are > >>relatively widespread (think: "ports") > >> > > > >Which while being scaleable in one direction (you can have things like > >/dev/pty1234567890) as it is essentialy open ended, on the other hand: > > > > a) pty/tty names are now variable length > > b) the name length advances quite quickly as we add more ptys > > c) it is a totaly new "look and feel" > > > >So why not instead: > > I think that is needlessly complicated. It's a direct extension to the present tty naming scheme. > I think tty%05d would solve all but the third of your objections, The first was more a question of radix, implying that 10 might be too low. IMHO base-32 has many good qualities to itself. It makes retaining the policy of creating ptys in increments of 32 easy, the name space does not grow as fast (pty allows for more ptys than pty%06d) and it is not much different from the naming system. > and quite frankly the "we've never done that before" argument > works badly with me. > It's more the argument of "why do it *significantly* differently from others?" > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rm works not properly
Hello CURRENT-users, I noticed following (mysterious) behaviour today: [ snip ] <1> dr@speed:~ $ touch test/blah <1> dr@speed:~ $ ls -l test total 0 -rw-r--r-- 1 dr dr 0 Aug 15 14:52 blah <1> dr@speed:~ $ rm -rf test/ rm: test: Operation not permitted rm: test: Directory not empty <1> dr@speed:~ $ rm -rf test <1> dr@speed:~ $ ls -l test gnuls: test: No such file or directory [ snap ] My build is two hours old. Best wishes, Dominik Rothert. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message <[EMAIL PROTECTED]>, Narvi writes: > >On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: > >[snip] > >> >> 7. [medium] The current naming for ptys doesn't scale that >> well. Changing it to ttyp%d / pty%d would probably be a >> good idea in the long run, but the ramifications are >> relatively widespread (think: "ports") >> > >Which while being scaleable in one direction (you can have things like >/dev/pty1234567890) as it is essentialy open ended, on the other hand: > > a) pty/tty names are now variable length > b) the name length advances quite quickly as we add more ptys > c) it is a totaly new "look and feel" > >So why not instead: I think that is needlessly complicated. I think tty%05d would solve all but the third of your objections, and quite frankly the "we've never done that before" argument works badly with me. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: [snip] > > 7. [medium] The current naming for ptys doesn't scale that > well. Changing it to ttyp%d / pty%d would probably be a > good idea in the long run, but the ramifications are > relatively widespread (think: "ports") > Which while being scaleable in one direction (you can have things like /dev/pty1234567890) as it is essentialy open ended, on the other hand: a) pty/tty names are now variable length b) the name length advances quite quickly as we add more ptys c) it is a totaly new "look and feel" So why not instead: a) have a constant that tells how long the tty name "suffix "is supposed to be (#define TTY_NAMSUFL 4, for example) b) encode the tty name as: pty/ttykl..l where k=[p-sP-S] and l=[0123456789abcdefghijklmnopqrstuv] and the number of l-s is the number given above in TTY_NAMSUFL The current system would just be one where the number of "l-s" is hardwired to 1. Anybody who has been looking at tty names is used to base-32 anyways 8-) > > Poul-Henning > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hacker tasks seek interested hackers
Well, autumn and winter is on us pretty soon. At least on my lattitude that means hot tea inside warm and cosy houses while the elements do their best to make life misserable for anything still left on the outside. Here are some tasks which could put an evening or more to productive and educational use for interested kernel hackers. They may also make a nice assignment for CS classes. 1. [easy] The SLIP device/interface could use the same makeover as tun, bpf and pty has received. (see also #5) 2. [easy] The PPP device/interface ditto. (see also #5) 3. [easy] The snp/snoop device/interface ditto. 4. [not quite easy] The CCD device ditto. Earn brownie points: Make ccdconfig use sysctl instead of libkvm to read back configuration. 5. [unknown] The I4B devices ditto. Contact [EMAIL PROTECTED] before starting on this one. 6. [medium] The TUN, SLIP and PPP interfaces should probably clean up all the way including a if_detach on last close. Earn brownie points: Do The Right Thing for SNMP. 7. [medium] The current naming for ptys doesn't scale that well. Changing it to ttyp%d / pty%d would probably be a good idea in the long run, but the ramifications are relatively widespread (think: "ports") 8. [pretty easy] Track the API documented in draft-mogul-pps-api-*.txt and implement it in FreeBSD. 9. [all winter] Write a proper DEVFS based on the new dev_t, which handles chroot/jail partitions and clone devices and has interface to a "devd" daemon which can DTRT when devices come and go. Have at it, and send patches with send-pr... Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
