Re: new sigset_t and upgrading: a proposal
On 2 October 1999 at 9:45, "Rodney W. Grimes" [EMAIL PROTECTED] wrote: When did we go wrong and start saying that users should build the world before building a new kernel?If it was ``I'' that said it, I full retract any such statement, I was WRONG!. It may have been said in the patchkit days, or very early FreeBSD 1.x. We build world first, because we need an up-to-date toolchain and config to build the kernel. Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Filtering port 25 (was Re: On hub.freebsd.org refusing to talk to dialups)
[This thread is off topic, but ... ] On 24 September 1999 at 3:00, "Rodney W. Grimes" [EMAIL PROTECTED] wrote: Another thing that ISP coulds start doing (we are in process with this now, but on a monitoring only basis, instead of a deny we just log them) is to block all outbound from AS tcp 25 setup packets. Monitoring this is not a bad idea. However, if you are suggesting that an ISP should /filter/ TCP port 25 packets, I have to disagree strongly. Vehemently, even :-) An ISP is in the business of delivering IP traffic. An ISP that fails to deliver ALL packets that are well formed (according to the relevant IETF standards and have a legitimate source address) is not doing what they are being payed to do. This prevents your customers from being something that could get you on the RBL or the DUL MAP for bad behavior, it also inforces the use of your smart host relay, as it/they is/are the only way to get a tcp port 25 setup completed. Evil! How does the ISP know I'm not running some other protocol (which is none of its business) on port 25? How does it know that I don't have a policy reason for accessing some other mail server than its own? Don't throw out the baby with the water! end-of-rant :-) Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcl-cvs (was Re: ccd build failure)
Thanks for the script! I thought I'd point out pcl-cvs for emacs, which can be found at src/contrib/cvs/tools/pcl-cvs or it can be easily installed using XEmacs 21's package management. Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] On 23 September 1999 at 11:46, Darryl Okahata [EMAIL PROTECTED] wrote: In the interests of peace and harmony (;-), I'd like to submit the attached perl script, which lists the status of cvs-controlled files. [snip] CVS is severely lacking in many areas (it is all we have, though), and one thing it is missing is an easy way of showing concise file status. [snip] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FTP passive mode - a new default?
On 28 May 1999 at 14:05, Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: FTP servers which do not accept passive mode are, IMHO, broken. Their loss. I'll second that opinion. Netscape and Microsoft browsers, at least, have been using passive FTP for years (1994 or earlier). One could argue that these are the most used FTP clients in the world, and has made passive mode a de facto requirement for public FTP servers. Jacques Vidrine / n...@nectar.cc / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -current page fault at 0xdeadc0de
On 16 May 1999 at 12:47, Poul-Henning Kamp p...@critter.freebsd.dk wrote: This is by intention: cd /sys/kern grep -i deadc0de * kern_malloc.c:#define WEIRD_ADDR0xdeadc0de For those who like such factoids, AIX uses 0xdeadbeef similarly for uninitialized data. Prior to FreeBSD 2.1.0, we used 0xdeedbeef as well, but that was changed and accompanied by this cute log message: revision 1.11 date: 1995/04/16 11:25:15; author: davidg; state: Exp; lines: +3 -3 Make vegetarian and animal rights people happy and use 0xdeadc0de instead of 0xdeadbeef as the fill pattern. Decreased MAX_COPY to 64 (256 was a bit overzealous in most cases). Jacques Vidrine / n...@nectar.cc / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Protocol analyzer
I've made a port, which I will commit as soon as I figure out how/if this thing works. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org On 3 May 1999 at 22:33, Jeroen Ruigrok/Asmodai asmo...@wxs.nl wrote: On 03-May-99 Chuck Robey wrote: If you've EVER used tcpdump, go take a look at this site, I guarantee it's worth your time: http://www.capmedia.fr/mgall/xip/ What a GREAT idea! A full graphical tcpdump! Also has some probs compiling... Looking at it... Might be nice to have in the ports *chuckle* --- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The FreeBSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Panic: Invalid longjmp with vinum configured by novice
On 9 April 1999 at 11:31, Michael Reifenberger r...@nihil.plaut.de wrote: [snip] But vinum(8) doesn't offer you much in the way of editing facilities either. A command history and commandline editing :-) Use ile in ports/misc/lile [sic], e.g. ``ile vinum'' Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
On 8 April 1999 at 11:49, John Polstra j...@polstra.com wrote: [snip] Everything works fine for the initial installation. But now 3 months later you want to upgrade to the new version. About the only reliable way to do that is to manually track down all the dependencies, pkg_delete every one of them, and then make install in the KDE or gnome port. Otherwise you end up with a hodge-podge of new ports and old dependencies, and they don't play together nicely. Maintainers of these ports would appreciate PRs if the dependencies are broken. The ports infrastructure has the mechanisms necessary to handle these dependencies, but the port maintainer may not catch every dependency. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
port dependencies (was Re: /sys/boot, egcs vs. gcc, -Os)
On 8 April 1999 at 12:24, John Polstra j...@polstra.com wrote: [snip] Say you've got a bunch of ports that all depend on the same shared library -- maybe libjpeg or libXpm. You've had them installed for a few months, and they all work fine. Now you decide to upgrade one of them, the foo port. Oops, it requires a newer version of libjpeg. You have to remove the old libjpeg so that the newer one can be installed without a lot of complaints. Oops, a bunch of other ports used the old libjpeg. Now you have to upgrade those ports too. Oops, some of those ports depend on libXpm, and a new version of it is needed now. Oops, now some other ports that used the old libXpm need to be upgraded. Now I understand what you are saying. The current ports structure only goes one way through the dependency graph. Maybe when building a particular port, not only should dependencies be checked, but anything that depends on the port needs to be rebuilt. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
On 8 April 1999 at 19:25, Chuck Robey chu...@mat.net wrote: [snip] And on top of that, there are about 5 top tracks of libs, each of these 5 tracks (that have lots depending on them) has lived in both /usr/local and in /usr/X11R6 in recent times, both leave ascii configuration files behind (and in both sets of directories, depending on the age of the older ports). Yes, I do find that very annoying. I'd like to see everything (including X) use one prefix. The next time that I install a system from scratch, I'll have everything under /opt (I use /usr/X11R6 and /opt right now) to see how it goes. I can't recall why we have /usr/X11R6, other than because of assumptions in lotsa X packages. Just to make everything totally confused, because some insane folks want to have multiple versions active concurrently, the name of those config files, which exist in multiple places, have multiple names. Insane? ``Though this be madness, yet there is a method in 't.'' If we were to remove all gtk ports but the latest (gtk12), as an example, then we would have to remove also approximately 34 ports that depend upon the older versions of GTK. Each of the ports of the apps, which need all these libs, have configuration scripts that go looking for all these misnamed and misfiled config scripts, and those configuration scripts alway seem to find the oldest and most out-of-date config script possible. AFAIK, all of the ports that depend upon gtk (again for example), correctly search for the version-dependant configuration script name (i.e. gtk10-config, gtk12-config ...). If there are those that do not, please send-pr them. If you have a better suggestion for handling this necessary complexity, I'd like to hear it. Upgrading the ports is hard enough without tilting at windmills. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
On 8 April 1999 at 19:57, Chuck Robey chu...@mat.net wrote: Don't forget, with all the gnome and gtk ports (and the kde things) there are various files with config in their names, that a bunch of other ports depend on ... just to add confusion, and the rules for these dependencies aren't as cut and dried as the libs, because the libs follow usually one set of rules (laid down by the runtime linker) but the config files, every port seems to use it's own set of rules. And there is no static linking for config files, to save you. A lot of these config files only take effect while building other libs or applications, which means they sometimes won't affect regular runtime problems, just beating the heck out of the upgrade nightmare. Maybe I'm misunderstanding ... are we talking about scripts such as gnome-config or gtk12-config? These seem to be a blessing to me. It would be an order of magnitude harder to maintain GTK using ports if it weren't for the simplicity of passing GTK_CONFIG=gtk12-config (or whichever applies) to the configure script. What problems do you believe these are causing for upgrades? Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
I get the feeling (not for the first time) that perhaps it is a mistake to have the package database indexed by PKGNAME. Or at least, it seems that there isn't an easy way to get from what I'll refer to as the ``port name'' from PKGNAME. For example, the port gtk12 was once gtk-1.2.0. Now it is gtk-1.2.1. I think this contributes to the upgrade problem and tracking dependencies with the information in /var/db/pkg. I just reread that and seem to be having trouble making myself clear right now. If that didn't make perfect sense, I'll try again tomorrow after some sleep. ;-) Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: GNU regex (Was: egcs knob and objective C)
On 3 April 1999 at 7:49, Kurt D. Zeilenga k...@openldap.org wrote: [snip] If you mean a version of regex included in the LGPL'ed libc, yes, then this point might be mute. However, if you mean the regex/rx distributions, please, no. We're talking about gdb, so I mean the GNU regex implementation that is distributed as part of gdb. [snip] I would suggest GNU regex be made ports unless some base application required the -lgnuregex. As much as I would like to see us shipping only one regex implementation, and a BSD-style licensed one at that, some base applications require GNU regex, notably those found under src/gnu. However, as we import new things (a new GDB, a new CVS) perhaps we can try to drop the regex implementations that come with those, and use one that is already in the system. Then again, perhaps not. No telling what subtle bugs could be created by changing the regex implementation used in complex applications such as CVS. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs knob and objective C
On 2 April 1999 at 22:25, Doug Rabson d...@nlsystems.com wrote: We should also consider installing libbfd. If and when we bring in a newer version of gdb, it would be a good idea to avoid importing yet another version of libiberty and libbfd. ... and GNU regex. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Suggested change to rc.network
Sounds fair to me. send-pr a patch.
Jacques Vidrine / n...@nectar.com / nec...@freebsd.org
On 5 March 1999 at 12:09, James FitzGibbon ja...@ehlo.com wrote:
There is already a precedent for allowing users to use drop-in replacements
for certain network daemons by specifying the path to the daemon in rc.conf.
Examples include the ${ntpdate_program} and ${xtnpd_program} variables that
are used in /etc/rc.network.
Wietse Venema has for some time had a replacement portmapper that uses
libwrap to control access using hosts.allow. It doesn't protect the
daemons, but it can help disguise what RPC services you are running.
I'm suggesting to have rc.network use a ${portmap_program} variable, with a
suitable default in /etc/defaults/rc.conf of /usr/sbin/portmap.
Any comments appreciated.
--
j.
James FitzGibbonja...@ehlo.co
m
EHLO Solutions Voice/Fax (416)410-010
0
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: ack! LaTeX?
On 23 January 1999 at 19:44, Brett Taylor br...@peloton.physics.montana.edu wrote: How is teTeX not working? I'm using a month or so old version of -current (back in the 3.0 days) on my home machine and teTeX works fine there. The latex installed by the teTex port complained about not being able to find default settings, or some such. I'm now using teTeX-beta after rebuilding libwww. Previously it complained about undefined symbols. I thought my libwww was fresh, but now I must suppose not. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ack! LaTeX?
Do any of the LaTeX ports work anymore, or do I have something
grubby in my ${LOCALBASE}?
I tried latex, teTeX, and teTeX-beta... each had one problem
or another. latex can't be fetched, teTeX-beta can't build,
and teTeX doesn't work after being installed.
Jacques Vidrine / n...@nectar.com / nec...@freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
cvsup failures
I've been seeing this since yesterday morning when trying to cvsup: Rmdir ispell/word2x Delete ispell/yodl/Makefile,v Delete ispell/yodl/files/md5,v Rmdir ispell/yodl/files Delete ispell/yodl/patches/patch-aa,v Rmdir ispell/yodl/patches Delete ispell/yodl/pkg/COMMENT,v Delete ispell/yodl/pkg/DESCR,v Delete ispell/yodl/pkg/PLIST,v Rmdir ispell/yodl/pkg Rmdir ispell/yodl Rmdir ispell *** *** runtime error: ***ASSERT failed ***file ../src/FileStatus.m3, line 467 *** Abort trap (core dumped) Any known problems, or should I clear out my repository and start over? Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
