Re: Version of XFree86 in FreeBSD Release 4.4
* Date: Tue, 18 Sep 2001 14:57:22 -0700 * From: "David O'Brien" <[EMAIL PROTECTED]> * On Mon, Sep 17, 2001 at 05:42:23PM -0700, Jordan Hubbard wrote: * > We're still waiting for 4.0's "support footprint" to widen What do you mean by "support footprint"? If you mean graphic cards, all we need to do is to provide XF3 servers in addition to the XF4 bits. * > a bit more before subjecting people to it by default. Hopefully * > by 4.5. * * Are you really considering using XFree86 4.x in FreeBSD-4.5? * When I asked you about this in the past, you had said you wanted to keep * the same X in RELENG_4 (presumable to not "rock the boat" mid-branch). Given that FreeBSD 5.0 is pushed back a year, I think you should seriously reconsider that position... Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A new package fetching utility, pkg_get
* From: Jaakko Salomaa <[EMAIL PROTECTED]> * poor in my opinion. I think we need something like this. I'll make a port * out of this if you want, or if it's my lucky day, perhaps it should even * be added to the base distribution (damn, I'm ambitious :-]). * % ** ./pkg_get -i gtk ** * Current server is the main distribution site, ftp.freebsd.org. * Do you want to use it? (Y/N) ** n ** : * Receiving glib-1.2.3.tgz (166214 bytes): 100% * 166214 bytes transferred in 21.9 seconds (7.40 Kbytes/s) * /usr/sbin/pkg_add gtk-1.2.3.tgz This looks great! Make it a port please! :) Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to go about making a compiler port
* From: Simon Marlow <[EMAIL PROTECTED]> * [originally sent to ports, resending to hackers at the suggestion of someone * on that list.] Sorry, you probably caught us at the busiest time right before the release * Hi Folks, * * I'd like to make a port for our Haskell compiler, GHC (see * http://research.microsoft.com/users/t-simonm/ghc). There are some subtle * problems with this: * * - GHC depends on itself. That is, you need GHC *installed in order to build GHC. * * - GHC depends on Happy, our parser generator. * * - Happy depends on GHC (it's written in Haskell). * * So, one solution would be to provide a binary port, say ghc-bin, which would * install a binary distribution. I checked the modula-3 port, and it doesn't * seem to have a binary port, so what's the accepted way of doing this? Look at lang/gnat. It has a similar situation. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to go about making a compiler port
* From: Simon Marlow * [originally sent to ports, resending to hackers at the suggestion of someone * on that list.] Sorry, you probably caught us at the busiest time right before the release * Hi Folks, * * I'd like to make a port for our Haskell compiler, GHC (see * http://research.microsoft.com/users/t-simonm/ghc). There are some subtle * problems with this: * * - GHC depends on itself. That is, you need GHC *installed in order to build GHC. * * - GHC depends on Happy, our parser generator. * * - Happy depends on GHC (it's written in Haskell). * * So, one solution would be to provide a binary port, say ghc-bin, which would * install a binary distribution. I checked the modula-3 port, and it doesn't * seem to have a binary port, so what's the accepted way of doing this? Look at lang/gnat. It has a similar situation. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: "bogomips" CPU performance metric
* From: Wilko Bulte * As Chris Costello wrote ... * >I don't think the local Ports Wraith would be amazingly happy * * No. He will turn into a Ports Wrath Hey, if you're going to make fun of me, at least CC: me or something so I know! ;) -PW (W?) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: "bogomips" CPU performance metric
* From: Wilko Bulte <[EMAIL PROTECTED]> * As Chris Costello wrote ... * >I don't think the local Ports Wraith would be amazingly happy * * No. He will turn into a Ports Wrath Hey, if you're going to make fun of me, at least CC: me or something so I know! ;) -PW (W?) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: "bogomips" CPU performance metric
* From: Jonathan Lemon * What I want is a simple new readable sysctl, something like: * * hw.clockrate: 132 * * I think that this would be useful both for development (how fast * is that stupid machine down in the bunker?), and system admininstration * (who needs a cpu upgrade this year?). I like that. * Doing this for Pentium and better systems should be trivial. Doing * it for 486 and lower would just add a timing loop. Doing it for SMP * would be harder. * * hw.cpu0.clockrate: 233 * hw.cpu1.clockrate: 233 * * Possibly? The implementer gets to pick a better name than these. How about hw.clockrate.cpu0: 233 hw.clockrate.cpu1: 233 (cpu0 only for uni-procs, of course). Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
* From: Tim Vanderhoek * differences are 1) entries in inetd.conf are sample entries only, 2) * ports have no way of adding those entries to inetd.conf themselves * (since touching /etc is illegal). Uh, you're contradicting yourself. Touching /etc is not illegal. * 2) The current system for having ports add their own usernames and * groupnames is very simple. It is a little messy in that there are a * number of different pkg/INSTALL scripts, some of them broken to * various degrees. Simply adding an mta username:groupname won't solve * that problem. Besides those that add uid/gids, most shell ports add entries to /etc/shells. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: "bogomips" CPU performance metric
* From: Jonathan Lemon <[EMAIL PROTECTED]> * What I want is a simple new readable sysctl, something like: * * hw.clockrate: 132 * * I think that this would be useful both for development (how fast * is that stupid machine down in the bunker?), and system admininstration * (who needs a cpu upgrade this year?). I like that. * Doing this for Pentium and better systems should be trivial. Doing * it for 486 and lower would just add a timing loop. Doing it for SMP * would be harder. * * hw.cpu0.clockrate: 233 * hw.cpu1.clockrate: 233 * * Possibly? The implementer gets to pick a better name than these. How about hw.clockrate.cpu0: 233 hw.clockrate.cpu1: 233 (cpu0 only for uni-procs, of course). Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
* From: Tim Vanderhoek <[EMAIL PROTECTED]> * differences are 1) entries in inetd.conf are sample entries only, 2) * ports have no way of adding those entries to inetd.conf themselves * (since touching /etc is illegal). Uh, you're contradicting yourself. Touching /etc is not illegal. * 2) The current system for having ports add their own usernames and * groupnames is very simple. It is a little messy in that there are a * number of different pkg/INSTALL scripts, some of them broken to * various degrees. Simply adding an mta username:groupname won't solve * that problem. Besides those that add uid/gids, most shell ports add entries to /etc/shells. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
* From: "Jordan K. Hubbard" Look, we're obviously not going to convince each other with this discussion. I'm sorry I caused you much trouble by adding it without working it with you first, but I believe the current state is workable for both of us. Can we leave it as it is? * 2. Your INDEX files can frequently be out of date with the ports *collection and someone should be able to do their own "make index" *when that happens. There is a "chopindex" script in ports/Tools/portbuild/scripts that anyone can use to clean up the index file (remove extra dependencies, lines for non-existent packages, etc.). *packages and that is simply not [yet] the case. The INDEX file *certainly isn't for the ports - they already get the dependency *information out of the Makefiles - it's for the packages and for *rudimentary search features. It is for all of them, as well as things like the ports web page. The one I commit is simply one with most information -- you can derive the package index from this one, but not the other way around. * To put it another way, consider me as Bruce and this as a really * egregious style(9) bug on your part. You can argue about it forever, * but it won't make you any less wrong in the end. :) If you want to declare yourself Bruce, go ahead. Then I'm going to take your advice about Bruce-filters and take note to your opinion but respectfully stand by my decision, thank you very much. :) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
* From: "Jordan K. Hubbard" <[EMAIL PROTECTED]> Look, we're obviously not going to convince each other with this discussion. I'm sorry I caused you much trouble by adding it without working it with you first, but I believe the current state is workable for both of us. Can we leave it as it is? * 2. Your INDEX files can frequently be out of date with the ports *collection and someone should be able to do their own "make index" *when that happens. There is a "chopindex" script in ports/Tools/portbuild/scripts that anyone can use to clean up the index file (remove extra dependencies, lines for non-existent packages, etc.). *packages and that is simply not [yet] the case. The INDEX file *certainly isn't for the ports - they already get the dependency *information out of the Makefiles - it's for the packages and for *rudimentary search features. It is for all of them, as well as things like the ports web page. The one I commit is simply one with most information -- you can derive the package index from this one, but not the other way around. * To put it another way, consider me as Bruce and this as a really * egregious style(9) bug on your part. You can argue about it forever, * but it won't make you any less wrong in the end. :) If you want to declare yourself Bruce, go ahead. Then I'm going to take your advice about Bruce-filters and take note to your opinion but respectfully stand by my decision, thank you very much. :) Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
* From: Tim Vanderhoek * I can claim a bit of the responsibility. It was done after Sue Blake * complained that there was no way to distinguish packages requiring X * from those that didn't. I wrote some extended message discussing * different types of dependencies, and then Satoshi wrote the change. * * However, my archives show I pointed-out the problem (with possible * solutions) from the start. Perhaps I would have been more urgent if * I'd forseen the future, but it's one of those things you look at and * figure "ah, it's so Freaking obvious that someone will fix it". * * The change was made long before the release and there was plenty of * time to fix any breakage. It was just never fixed. Ok, but also note that there aren't any dependencies left in packages anymore. I intend to ressurect those when the XFree86 port is broken up into more manageable chunks, but until then, the packages will ship with no XFree86 dependencies. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
* From: Tim Vanderhoek <[EMAIL PROTECTED]> * I can claim a bit of the responsibility. It was done after Sue Blake * complained that there was no way to distinguish packages requiring X * from those that didn't. I wrote some extended message discussing * different types of dependencies, and then Satoshi wrote the change. * * However, my archives show I pointed-out the problem (with possible * solutions) from the start. Perhaps I would have been more urgent if * I'd forseen the future, but it's one of those things you look at and * figure "ah, it's so Freaking obvious that someone will fix it". * * The change was made long before the release and there was plenty of * time to fix any breakage. It was just never fixed. Ok, but also note that there aren't any dependencies left in packages anymore. I intend to ressurect those when the XFree86 port is broken up into more manageable chunks, but until then, the packages will ship with no XFree86 dependencies. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
* From: "Jordan K. Hubbard" * Just to clear up a misconception; this isn't actually a sysinstall * problem. This is a ports bug which Satoshi or somebody introduced * when they added a dependency on the XFree86 port very prematurely. It * was premature because no actual package exists for XFree86 yet and yet * it's part of the dependancy chain now for a lot of packages, You are entitled to you opinion, but please don't misrepresent the facts. They are not part of the dependency chain for any *packages*. * resulting * in severe dysfunction unless it's removed by hand from the INDEX you * use for package adding. True, but all the INDEX files *I* make for package sets (and those are the only ones you ought to be using, since those are the only ones truly synced with the time of package builds) have the XFree86 stuff stripped. :) -PW To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
* From: "Jordan K. Hubbard" <[EMAIL PROTECTED]> * Just to clear up a misconception; this isn't actually a sysinstall * problem. This is a ports bug which Satoshi or somebody introduced * when they added a dependency on the XFree86 port very prematurely. It * was premature because no actual package exists for XFree86 yet and yet * it's part of the dependancy chain now for a lot of packages, You are entitled to you opinion, but please don't misrepresent the facts. They are not part of the dependency chain for any *packages*. * resulting * in severe dysfunction unless it's removed by hand from the INDEX you * use for package adding. True, but all the INDEX files *I* make for package sets (and those are the only ones you ought to be using, since those are the only ones truly synced with the time of package builds) have the XFree86 stuff stripped. :) -PW To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting strategy - pine4 + SSL
* From: Nick Sayer
*
* I have made a preliminary patch (hack?) to add SSL to pine (it's like
* clicking the 'server requires secure connection' box - POP or IMAP over
* SSL).
*
* The pine4 port is fairly involved. Adding my stuff is almost downright
* trivial. It amounts to adding
*
*
* BUILD_DEPENDS= ${PREFIX}/lib/libssl.a:${PORTSDIR}/security/SSLeay \
* ${PREFIX}/lib/libcrypto.a:${PORTSDIR}/security/SSLeay \
* ${PREFIX}/lib/libRSAglue.a:${PORTSDIR}/security/SSLeay \
* ${PREFIX}/lib/librsaref.a:${PORTSDIR}/security/rsaref
*
* RESTRICTED= "Contains cryptography - no export from US"
*
* DISTFILES+= pine4+ssl-1.0
* MASTER_SITES+= ftp://ftp.kfu.com/pub/
*
* (the pine4+ssl-1.0.tar.gz file isn't there yet. :-) )
*
* and modifying the Makefile to add "EXTRAAUTHENTICATORS=ssl" to the end
* of the "build" command.
*
* How should I do this? Should I copy the pine4 port entirely?
* Should I modify the existing pine4 adding conditional stuff to
* handle ssl? Can someone suggest a hackish way to piggyback onto
* the existing pine4 port with a new port consisting only of the
* steps above, but preserving the steps of the original port?
(1) Change pine4/Makefile to define stuff like PKGNAME with ?= and
*_DEPENDS with +=
(2) Set MASTERDIR=${.CURDIR}/../pine4 and put the above plus
.include "${MASTERDIR}/Makefile" in pine4-ssl/Makefile.
You may need to supply pkg/* files separately.
Satoshi
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: a two-level port system? (fwd)
* From: Ladavac Marino I don't really have time to butt in (I have to hop on a plane in a few hours and I haven't finished the presentation slides) but I'd like to throw in my two cents before this gets out of hand. * [ML] This would offer an advantage over the existing system * only if all ports are updated to the new schema, which is a lot of work. * shar approach could be easily mechanised, and requires no changes in the * makefiles or the ports themselves. OTOH, shar offers no advantages to * the folks who build all ports (or most of them) because they end up * creating all directories anyway. I think Satoshi is the only such * person :) I don't think that's really an issue. The question is, what is the problem you are trying to solve here? What are the requirements of the system? The requirements are: @ Easy to maintain. I have a tree checked out, I can go in there and type "make package", tweak the Makefile and type "make clean package", and type "cvs commit" when I'm done. A lot of committers work this way. Can you beat this? @ Version control. Can you check out an arbitrary version of any file? I want to do something like "give me the changes in Makefile between yesterday and today". @ Low on bandwidth. CVS combined with "individual files" approach is pretty darn efficient when it comes to not sending more than what changed. @ Easy to search. Does it let me grep something in all md5 files or all PLISTs? The current approach does this by letting the filesystem take care of the individual files. A shar file per port solution is just moving part of the problem from the kernel (filesystem) to userland (shar/unshar). Now, the problems are: @ It takes a long time to...what? cvsup the tree? That's already pretty fast. Read all files? Why do you want to read all files? It's more likely that you want to read all the Makefiles or all the md5 files or some such, which shar will slow down considerably. CVS update the entire tree? Ok, so that's pretty slow. But do people really do it often enough to hurt? @ It is large. Ok, so it's 44MB (the first poster had the size completely wrong -- probably had some distfiles or work/ subdirs lying around). That's less than 20KB per port. Ok, so you can keep only the Makefile, or even less, and let the network do the work for you whenever you type something. But does anybody have a system that has such a wonderful network connection but yet can't spare 44MB of disk space? It seems to me that you guys are arguing about a problem that doesn't really exist. Or at least all ideas proposed so far seem to hurt more than help. ;) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
