Re: [HEADS UP] perl symlinks in /usr/bin will be gone
While I agree that correct ports shouldn't be affected, I think that this will make a difference in how FreeBSD is looked at as a whole. I know that when I write stuff for other people in perl, it is presumed that perl is in /usr/bin, not /usr/local/bin because most of these people are running some Linux distribution. I also thought that is was requested to have perl in /usr/bin? I agree, having perl available in /usr/bin is one of the nice points of FreeBSD. I see strong reactions against removing the /usr/bin symlinks in 5.x. Good, presumably they will be allowed to stay. But I would also like to keep them for 6.x. As others have pointed out, removing those symlinks would create a lot of hassle for the users, for very little gain. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.3 - 5 : sshd multiple log entries login_getclass: unknown class 'root'
Hello, As the topic says, I've experienced some unusual sshd behavior after I moved some of my systems from RELENG_5_3 to RELENG_5 recently. The unusuality of the behavior is illustrated by the following exerpt from the /var/log/auth.log on the RELENG_5 system: Jan 29 14:53:38 mail sshd[699]: login_getclass: unknown class 'root' Jan 29 14:53:38 mail last message repeated 3 times Jan 29 14:53:38 mail sshd[699]: Accepted publickey for root from 192.168.0.1 port 60094 ssh2 Jan 29 14:53:38 mail sshd[698]: Accepted publickey for root from 192.168.0.1 port 60094 ssh2 Jan 29 15:32:15 mail sshd[836]: login_getclass: unknown class 'root' Jan 29 15:32:15 mail last message repeated 3 times Jan 29 15:32:15 mail sshd[836]: Accepted publickey for root from 192.168.0.1 port 53837 ssh2 Jan 29 15:32:15 mail sshd[835]: Accepted publickey for root from 192.168.0.1 port 53837 ssh2 Jan 29 16:40:16 mail sshd[1034]: login_getclass: unknown class 'root' Jan 29 16:40:16 mail last message repeated 3 times Jan 29 16:40:16 mail sshd[1034]: Accepted publickey for root from 192.168.0.1 port 54714 ssh2 Jan 29 16:40:16 mail sshd[1033]: Accepted publickey for root from 192.168.0.1 port 54714 ssh2 Jan 29 17:10:27 mail sshd[1125]: login_getclass: unknown class 'root' Jan 29 17:10:27 mail last message repeated 3 times Jan 29 17:10:27 mail sshd[1125]: Accepted publickey for root from 192.168.0.1 port 54337 ssh2 Jan 29 17:10:27 mail sshd[1124]: Accepted publickey for root from 192.168.0.1 port 54337 ssh2 All of the systems have login.conf which contains entry for a root class. I've rebuild the login.conf.db database to make sure that it's not a filesystem glitch and even copied the default login.conf from /usr/src followed by rebuilding the login.conf.db database, but none of that helped. The manual page for the login_getclassbyname() explicitely states: In addition, if the referenced user has a UID of 0 (normally, root, although the user name is not considered) then login_getpwclass() will search for a record with an id of root before it searches for the record with the id of default. So, the root entry IS there but for some reason either sshd is being buggy or login_getclassbyname() is behaving strangely because as far as I know this shouldn't be happening. Also, for some reason, for each successful login attempt there are two identical entries apparently made by two different instances/fork's of sshd since they have different PID's. This started happening the same time when the first problem appeared, which is after recent upgrade from RELENG_5_3 to RELENG_5. I've taken a diff between RELENG_5_3 and RELENG_5 but didn't find any obvious changes that could have led to this unusual situation. I guess that only somewhat related change could be the addition of logpriv mechanism for protection against consequences of syslogd flooding. To convince myself that all of this is specific to RELENG_5_3 - RELENG_3 upgrade, I've just reversed one of the systems back to RELENG_5_3 and all of the above mentioned problems have disappeared. All of the upgrades and downgrades have been accompanied with mergemaster. Some addition info about the mail system above: mail# uname -rs FreeBSD 5.3-STABLE mail# grep ssh /etc/rc.conf sshd_enable=YES mail# grep syslog /etc/rc.conf syslogd_flags=-4 -s -b 192.168.0.7 mail# grep root /etc/master.passwd | head -1 root:*:0:0::0:0:Andrew Konstantinov:/root:/bin/csh mail# grep -EA 3 '^root:\\' /etc/login.conf root:\ :ignorenologin:\ :tc=default: mail# Am I missing something obvious here? Any pointes on debugging this? Please, let me know if additional info is needed. Thanks, Andrew pgpvPX3bb2iGR.pgp Description: PGP signature
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Hello. On Sat, Jan 29, 2005 at 09:24:25PM +0100, Anton Berezin wrote: Unless I hear too many cries don't do that (with justification), I plan to not create any perl symlinks in /usr/bin in the forthcoming upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). This will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT; the existing pollution of /usr/bin will still be performed for older versions of FreeBSD, if requested via use.perl script. In practical terms this will mean a one-time sweep of your scripts in order to convert them, in a typical case, from #! /usr/bin/perl to #! /usr/local/bin/perl. CORRECT perl-dependant ports should not be affected. In order to keep pkg-install simple, no old symlink chasing and removal will be done, although the detailed instructions will be posted in ports/UPDATING and in pkg-message for the ports. At least for -STABLE I see a big impact. I see no useful gain in that step anyway; I would just have to create the link on tens of machines by hand. If it turns out, that this will be the way to (which the discussion doesn't suggest), I would like to see something like this: - Don't change the behaviour on -STABLE (4.x, 5.x), but make an OPTION available, that would turn on the new behaviour. - For -CURRENT (6.x and beyond), if the change comes, make an OPTION available, to turn on the old behaviour. Something like make PERL_POLLUTES_BASE=yes install clean would just be fine. There are many good reasons, to have /usr/bin/perl available at just that place. Be it good style or not, the reality ist, that a lot of third party stuff depends on exactly that. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | pgpZjA9XAgcbg.pgp Description: PGP signature
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Saturday, 2005-01-29 at 21:24:25 +0100, Anton Berezin wrote: Unless I hear too many cries don't do that (with justification), ... don't do that, ever. Eben postponing this to the time 6.0 comes out does not change it. Any upgraded system will fail in interesting and mysterious ways. I see no benefit in not having a /usr/bin/perl, and I see many problems with it. Even when it does not affect my two insignificant ports, I'm against it. If you are still planning on going through with this, please take the idea to the perl5-porters list first. perl5-porters@perl.org My 2 Eurocents, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Ask not what your computer can do for you | | ask what you can do for your computer. | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Why would upgraded systems cause problems? I don't think the upgradesystem will delete any existing symlinks? Xander Lupe Christoph wrote: On Saturday, 2005-01-29 at 21:24:25 +0100, Anton Berezin wrote: Unless I hear too many cries don't do that (with justification), ... don't do that, ever. Eben postponing this to the time 6.0 comes out does not change it. Any upgraded system will fail in interesting and mysterious ways. I see no benefit in not having a /usr/bin/perl, and I see many problems with it. Even when it does not affect my two insignificant ports, I'm against it. If you are still planning on going through with this, please take the idea to the perl5-porters list first. perl5-porters@perl.org My 2 Eurocents, Lupe Christoph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Edwin Groothuis wrote: On Sat, Jan 29, 2005 at 11:51:36PM -0500, Chuck Swiger wrote: Andrew McNaughton wrote: #!/usr/bin/env PERL5OPT='-w' perl #!/usr/bin/perl -w sounds much easier. Sure, assuming there actually was a perl in /usr/bin. I would not choose to hardcode the path to perl when env is available to properly locate the interpreter for #!-based scripts via the $PATH. tobez@ is in the unenviable position of trying to support a language that was added and then removed from the base system. He can produce a port that respects $PREFIX by not changing anything outside of /usr/local, or one that provides backwards compatibility with Perl being part of the base system at the cost of creating extra symlinks and spamming /etc/make.conf. Since the decision to remove Perl from FreeBSD's base was not accompanied by universal recognition and acceptance that scripts should not hardcode a path to /usr/bin/perl, there exists a conflict which is not going to go away until either Perl gets added back to the base system, or the Perl scripts are fixed. I don't want to revisit a discussion of whether Perl should be part of base. I don't want the Perl port to change in a way that breaks existing scripts. I don't want perl scripts to assume that Perl is in /usr/bin, or /usr/local/bin, or any other specific place. I don't want to have perl symlinked between /usr/bin and /usr/local/bin. I do want scripts to use a portable mechanism to invoke Perl regardless of where the binary happens to be found, but if people are determined to do otherwise, well, that's up to them. One solution for those people might be to install the Perl port with a $PREFIX of /usr rather than /usr/local. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Hello Anton, Saturday, January 29, 2005, 11:24:25 PM, you wrote: AB Unless I hear too many cries don't do that (with justification), I AB plan to not create any perl symlinks in /usr/bin in the forthcoming AB upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). AB In practical terms this will mean a one-time sweep of your scripts in AB order to convert them, in a typical case, from #! /usr/bin/perl to AB #! /usr/local/bin/perl. In all scripts of all my friends, who have hosting on my server use perl scripts? NO, THANKS! -- Best regards, Levmailto:[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sat, Jan 29, 2005 at 10:51:37PM -0700, Scott Long wrote: Anton Berezin wrote: Unless I hear too many cries don't do that (with justification), I plan to not create any perl symlinks in /usr/bin in the forthcoming upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). This will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT; the existing pollution of /usr/bin will still be performed for older versions of FreeBSD, if requested via use.perl script. [...] I'm fine with this plan for 6-CURRENT. For 5-STABLE, it's a major user-visible change, and that is something that we promised to avoid with stable branches. It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. We had enough good arguments against this change already, so imho the correct thing to do is do just what Kris asked for: remove the _dangling_ symlinks. Regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 11:47:32AM +0100, Holger Kipp wrote: I'm fine with this plan for 6-CURRENT. For 5-STABLE, it's a major user-visible change, and that is something that we promised to avoid with stable branches. It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. If it's linux tradition to put perl in this path, perl programmers should assume another path on FreeBSD, so it isn't an argument for the proposed change. We had enough good arguments against this change already, so imho the correct thing to do is do just what Kris asked for: remove the _dangling_ symlinks. -Kirill ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 05:31:21AM -0500, Chuck Swiger wrote: I do want scripts to use a portable mechanism to invoke Perl regardless of where the binary happens to be found, but if people are determined to do otherwise, well, that's up to them. One solution for those people might be to install the Perl port with a $PREFIX of /usr rather than /usr/local. And I want a pony :-) In other words, it's an impossible dream to hope that all scripts will conform to this or any of the other possible choices (remember the perl motto). Even making everything perl in the ports collection use a uniform style is probably an infeasible task (recall 840 ports use /usr/bin/perl, and that's not counting the others that use another hardcoded variant of /usr/local/bin/perl). Kris pgpNvHMjnKQLY.pgp Description: PGP signature
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 11:53:23AM +0100, Kirill Ponomarew wrote: On Sun, Jan 30, 2005 at 11:47:32AM +0100, Holger Kipp wrote: I'm fine with this plan for 6-CURRENT. For 5-STABLE, it's a major user-visible change, and that is something that we promised to avoid with stable branches. It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. If it's linux tradition to put perl in this path, perl programmers should assume another path on FreeBSD, so it isn't an argument for the proposed change. Long before I ever saw FreeBSD or Linux, there were symlinks on the AIX, SunOS and Solaris machines from /usr/bin/perl pointing to the right executables. It's not a Linux-ism, it's like what somebody already pointed out, best practice for Perl. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sunday 30 January 2005 11:44, Lev Serebryakov wrote: AB Unless I hear too many cries don't do that (with justification), I AB plan to not create any perl symlinks in /usr/bin in the forthcoming AB upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). AB In practical terms this will mean a one-time sweep of your scripts in AB order to convert them, in a typical case, from #! /usr/bin/perl to AB #! /usr/local/bin/perl. In all scripts of all my friends, who have hosting on my server use perl scripts? NO, THANKS! Don't despair, ironically Perl itself can solve this problem for you, using something like find /some/directory -type f -print0 | \ xargs -0 perl -pi -e 's,^#! ?/usr(/local)?/bin/perl,#!/usr/bin/env perl' - Frerich -- Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? pgpCmjDmRMR3o.pgp Description: PGP signature
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 05:31:21AM -0500, Chuck Swiger wrote: Edwin Groothuis wrote: On Sat, Jan 29, 2005 at 11:51:36PM -0500, Chuck Swiger wrote: Andrew McNaughton wrote: #!/usr/bin/env PERL5OPT='-w' perl #!/usr/bin/perl -w sounds much easier. Sure, assuming there actually was a perl in /usr/bin. I would not choose to hardcode the path to perl when env is available to properly locate the interpreter for #!-based scripts via the $PATH. a) we had perl at /usr/bin/perl = many scripts are using #!/usr/bin/perl b) we have a symlink now = many new scripts are using #!/usr/bin/perl c) many ISPs have even more users who assume #!/usr/bin/perl works. = removing a symlink to create lots_of_trouble(tm) is not the freebsd-ish way of live. this single symlink is needed. d) calling env and then perl increases load unneccessarily = don't do that. = if you like _YOUR_ scripts to work like that, it is fine with me ;-) e) comparing #!/usr/bin/env PERL5OPT='-w' perl with #!/usr/bin/perl -w = I'd vote for the simpler second one. I don't want to revisit a discussion of whether Perl should be part of base. ok I don't want the Perl port to change in a way that breaks existing scripts. fine, so we must keep the symlink in /usr/bin/ I don't want perl scripts to assume that Perl is in /usr/bin, or /usr/local/bin, or any other specific place. Your problem. Write your scripts accordingly and be happy. Talk with several thousand programmers who use perl and assume it is located at /usr/bin/perl and convince them to write their programs differently. Otherwise, this breaks POLA. See c) I don't want to have perl symlinked between /usr/bin and /usr/local/bin. Fine, then _you_ can remove the symlink by hand on your systems every time. I do want scripts to use a portable mechanism to invoke Perl regardless of where the binary happens to be found, but if people are determined to do otherwise, well, that's up to them. One solution for those people might be to install the Perl port with a $PREFIX of /usr rather than /usr/local. Huh? It was removed from the base system, so it belongs to /usr/local. Get real. Removing the symlinks permanently is causing lots of trouble. Not removing them is fine with me and at least most other users. Regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
HANKS! Don't despair, ironically Perl itself can solve this problem for you, using something like find /some/directory -type f -print0 | \ xargs -0 perl -pi -e 's,^#! ?/usr(/local)?/bin/perl,#!/usr/bin/env perl' One problem I always had with env or equivalents... what happens if someone manages to polute $PATH with a perl that is not infact perl but something else, I remember being taught Always specify full paths to binaries, especially in cron. Cheers, Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
+-le 30/01/2005 12:19 +0100, Kirill Ponomarew écrivait : | On Sun, Jan 30, 2005 at 09:08:34PM +1000, Mark Sergeant wrote: | If it's linux tradition to put perl in this path, perl programmers | should assume another path on FreeBSD, so it isn't an argument for | the proposed change. | | As per the current perl-5.8.6 INSTALL file ... | | It may seem obvious, but Perl is useful only when users can easily | find it. It's often a good idea to have both /usr/bin/perl and | /usr/local/bin/perl be symlinks to the actual binary. | | /usr/bin and /usr/local/bin are *BOTH* in default $PATH. Last time I looked, cron did not have usr/local in it's path. -- Mathieu Arnold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
I think the color should be green. On Sat, 29 Jan 2005 21:24:25 +0100, Anton Berezin [EMAIL PROTECTED] wrote: Unless I hear too many cries don't do that (with justification), I plan to not create any perl symlinks in /usr/bin in the forthcoming upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). This will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT; the existing pollution of /usr/bin will still be performed for older versions of FreeBSD, if requested via use.perl script. In practical terms this will mean a one-time sweep of your scripts in order to convert them, in a typical case, from #! /usr/bin/perl to #! /usr/local/bin/perl. CORRECT perl-dependant ports should not be affected. In order to keep pkg-install simple, no old symlink chasing and removal will be done, although the detailed instructions will be posted in ports/UPDATING and in pkg-message for the ports. Please respect Reply-To. Thank you, \Anton. -- The moronity of the universe is a monotonically increasing function. -- Jarkko Hietaniemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 12:23:43PM +0100, Mathieu Arnold wrote: +-le 30/01/2005 12:19 +0100, Kirill Ponomarew ?crivait : | On Sun, Jan 30, 2005 at 09:08:34PM +1000, Mark Sergeant wrote: | If it's linux tradition to put perl in this path, perl programmers | should assume another path on FreeBSD, so it isn't an argument for | the proposed change. | | As per the current perl-5.8.6 INSTALL file ... | | It may seem obvious, but Perl is useful only when users can easily | find it. It's often a good idea to have both /usr/bin/perl and | /usr/local/bin/perl be symlinks to the actual binary. | | /usr/bin and /usr/local/bin are *BOTH* in default $PATH. Last time I looked, cron did not have usr/local in it's path. I meant user enviroments, not cron. -Kirill ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
writeprotected floppy not unmountable on STABLE
Hi, I mounted a write-pretected floppy on 5-STABLE and now I'm not able to unmount the floppy [EMAIL PROTECTED] /root mount_msdosfs /dev/fd0 /mnt/tmp [EMAIL PROTECTED] /root touch /mnt/tmp/test touch: /mnt/tmp/test: Read-only file system Exit 1 [EMAIL PROTECTED] /root mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1d on /var (ufs, local, soft-updates) /dev/ad0s3e on /usr/home (ufs, local, soft-updates) /dev/ad0s4e on /mnt/movies (ufs, local, soft-updates) file:/usr/ports on /usr/ports (nfs) file:/usr/src on /usr/src (nfs) file:/mnt/backups on /mnt/backups (nfs) file:/mnt/documents on /mnt/documents (nfs) file:/mnt/files on /mnt/files (nfs) www:/usr/local/www on /mnt/www (nfs) /dev/fd0 on /mnt/tmp (msdosfs, local) [EMAIL PROTECTED] /root umount /mnt/tmp umount: unmount of /mnt/tmp failed: Resource temporarily unavailable Exit 1 [EMAIL PROTECTED] /root what works is [EMAIL PROTECTED] /root umount -f /mnt/tmp [EMAIL PROTECTED] /root CURRENT correctly detects that the floppy is write-protected, and fails to mount it unless -o ro is specified. umount on CURRENT is also possible. [EMAIL PROTECTED] /root uname -a FreeBSD kartoffel.salatschuessel.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Sun Jan 16 15:35:29 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KARTOFFEL i386 please keep me CCed - I'm not subscribed -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, 30 Jan 2005, Holger Kipp wrote: I'm fine with this plan for 6-CURRENT. For 5-STABLE, it's a major user-visible change, and that is something that we promised to avoid with stable branches. It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. I have *never* assumed that Perl was in /usr/bin, so for me the POLA simply doesn't apply. In fact, the POLA would seem to say that you don't put a 3rd-party product into a system area. -- Dave, who was taught by JohnL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Kris Kennaway wrote: On Sun, Jan 30, 2005 at 05:31:21AM -0500, Chuck Swiger wrote: I do want scripts to use a portable mechanism to invoke Perl regardless of where the binary happens to be found, but if people are determined to do otherwise, well, that's up to them. One solution for those people might be to install the Perl port with a $PREFIX of /usr rather than /usr/local. And I want a pony :-) I don't expect to get what I want, either. :-) In other words, it's an impossible dream to hope that all scripts will conform to this or any of the other possible choices (remember the perl motto). Even making everything perl in the ports collection use a uniform style is probably an infeasible task (recall 840 ports use /usr/bin/perl, and that's not counting the others that use another hardcoded variant of /usr/local/bin/perl). Good word, that. It is infeasible to get hundreds of people to all follow a convention-- any convention, no matter how simple and reasonable-- simply by wishing for it. Since a perfect solution does not exist, it is fortunate that we don't actually need one: just something that is good enough for now, for the present tasks. The Perl software I actually use either works fine regardless of whether perl is in /usr/bin, /sw/bin, /opt/bin, /usr/local/bin, /usr/pkg/bin, or who knows where else, or else I fix it to suit my requirements when I notice a problem. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Holger Kipp wrote: On Sun, Jan 30, 2005 at 05:31:21AM -0500, Chuck Swiger wrote: Sure, assuming there actually was a perl in /usr/bin. I would not choose to hardcode the path to perl when env is available to properly locate the interpreter for #!-based scripts via the $PATH. a) we had perl at /usr/bin/perl = many scripts are using #!/usr/bin/perl If we means FreeBSD-4, OK. Otherwise, I remember using a /usr/local/bin/perl-4.036 several years before vendors started shipping Perl with the system in /usr/bin. I don't want the Perl port to change in a way that breaks existing scripts. fine, so we must keep the symlink in /usr/bin/ That is one solution, but it is not the only available choice. I don't want perl scripts to assume that Perl is in /usr/bin, or /usr/local/bin, or any other specific place. Your problem. Write your scripts accordingly and be happy. Talk with several thousand programmers who use perl and assume it is located at /usr/bin/perl and convince them to write their programs differently. Otherwise, this breaks POLA. See c) As I said to Kris, I'm perfectly willing to change existing software or write my own to suit my preferences. If other people want to do something else which pleases them better, fine, that's up to them. I don't want to have perl symlinked between /usr/bin and /usr/local/bin. Fine, then _you_ can remove the symlink by hand on your systems every time. Or I could not bother and simply let env deal with finding the right version of perl. Works for me. I do want scripts to use a portable mechanism to invoke Perl regardless of where the binary happens to be found, but if people are determined to do otherwise, well, that's up to them. One solution for those people might be to install the Perl port with a $PREFIX of /usr rather than /usr/local. Huh? It was removed from the base system, so it belongs to /usr/local. There is a conflict between installing perl to /usr/local/bin and expecting to invoke perl from /usr/bin. Perhaps you've decided to live with it and are happy with symlinks so that both paths work. Get real. Oh, I am. Mostly. :-) Removing the symlinks permanently is causing lots of trouble. For some people, agreed. It doesn't matter one bit to other people... Not removing them is fine with me and at least most other users. Leaving the symlinks as they are now is probably the least intrusive way of dealing with the current mess that Perl script invocation has become. Fortunately, people doing Python seemed to have learned from these problems, as a quick check via GoogleFight suggests that the majority of Python scripts use env rather than hardcoding a path. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, 30 Jan 2005, Oliver Brandmueller wrote: - Don't change the behaviour on -STABLE (4.x, 5.x), but make an OPTION available, that would turn on the new behaviour. - For -CURRENT (6.x and beyond), if the change comes, make an OPTION available, to turn on the old behaviour. I think I'd be against this also -- those who followed by google fight link will have seen there were about 1.6 million references to #!/usr/bin/perl in Google, vs only about 67,000 references to #!/usr/bin/env perl. One of the important goals in the 6.x work is to avoid creating unnecessary barriers to upgrades, in order to make transition from 5-STABLE to 6-STABLE much more seamless than the transition from 4-STABLE to 5-STABLE has been. Breaking everyone's perl scripts can hardly be described as making upgrades seamless. :-) Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, 30 Jan 2005, Xander Damen wrote: Why would upgraded systems cause problems? I don't think the upgradesystem will delete any existing symlinks? I don't know about other people, but I use incremental upgrades for only minor releases on larger multi-user systems, generally. Because of the level of effort and typical differences between releases, I want a break in period in which I can check for incompatibilities, etc, before taking the new system live. This means that there is no upgrade, there's only a new install -- the user data is migrated. Robert N M Watson Xander Lupe Christoph wrote: On Saturday, 2005-01-29 at 21:24:25 +0100, Anton Berezin wrote: Unless I hear too many cries don't do that (with justification), ... don't do that, ever. Eben postponing this to the time 6.0 comes out does not change it. Any upgraded system will fail in interesting and mysterious ways. I see no benefit in not having a /usr/bin/perl, and I see many problems with it. Even when it does not affect my two insignificant ports, I'm against it. If you are still planning on going through with this, please take the idea to the perl5-porters list first. perl5-porters@perl.org My 2 Eurocents, Lupe Christoph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 11:53:23AM +0100, Kirill Ponomarew wrote: On Sun, Jan 30, 2005 at 11:47:32AM +0100, Holger Kipp wrote: I'm fine with this plan for 6-CURRENT. For 5-STABLE, it's a major user-visible change, and that is something that we promised to avoid with stable branches. It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. If it's linux tradition to put perl in this path, perl programmers should assume another path on FreeBSD, so it isn't an argument for the proposed change. It is not a *Linux* tradition. It is a *Perl* tradition which predates both Linux and FreeBSD. Most Perl documentation, going back over a decade, has used #!/usr/bin/perl in example scripts and strongly suggested that system administrators should put Perl there. I would say that there are probably more Perl scripts out there that refer to #!/usr/bin/perl than all other variants put together. We had enough good arguments against this change already, so imho the correct thing to do is do just what Kris asked for: remove the _dangling_ symlinks. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Erik Trulsson [EMAIL PROTECTED] writes: Hardcoded paths in scripts are a mess. What if I installed Perl into /opt/mumble on some other machine? /usr/freeware? /what/ever? Changed $PREFIX and/or $LOCALBASE? Then you would have nobody but yourself to blame. So ports not heeding PREFIX or LOCALBASE aren't buggy? Interesting POV. And what about all the scripts that administrators and users write that are not part of any port? Scripts that were written according to the de-facto standard that having '#!/usr/bin/perl' on the first line of the script will work correctly. As mentioned before, #! /usr/bin/env perl is the canonic SHORT way to run perl, longer ways are in perlrun(1). -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Kris Kennaway [EMAIL PROTECTED] writes: In other words, it's an impossible dream to hope that all scripts will conform to this or any of the other possible choices (remember the perl motto). Even making everything perl in the ports collection use a uniform style is probably an infeasible task (recall 840 ports use /usr/bin/perl, and that's not counting the others that use another hardcoded variant of /usr/local/bin/perl). Well, broken ports are marked broken and removed after some months. How would broken Perl ports justify special treatment? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Holger Kipp [EMAIL PROTECTED] writes: a) we had perl at /usr/bin/perl = many scripts are using #!/usr/bin/perl b) we have a symlink now = many new scripts are using #!/usr/bin/perl c) many ISPs have even more users who assume #!/usr/bin/perl works. = removing a symlink to create lots_of_trouble(tm) is not the freebsd-ish way of live. this single symlink is needed. The admin who wishes to have that symlink can place one himself. Why burden the base system with it if it has no use for Perl? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Holger Kipp [EMAIL PROTECTED] writes: It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. POLA doesn't apply to -CURRENT. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5 tinderbox] failure on alpha/alpha
TB --- 2005-01-30 13:00:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-30 13:00:11 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2005-01-30 13:00:11 - checking out the source tree TB --- 2005-01-30 13:00:11 - cd /home/tinderbox/RELENG_5/alpha/alpha TB --- 2005-01-30 13:00:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-01-30 13:08:15 - building world (CFLAGS=-O -pipe) TB --- 2005-01-30 13:08:15 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2005-01-30 13:08:15 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything TB --- 2005-01-30 13:58:32 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-01-30 13:58:32 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2005-01-30 13:58:32 - /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Jan 30 13:58:32 UTC 2005 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/kern_mib.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/kern_module.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/RELENG_5/alpha/alpha/src/sys/kern/kern_mutex.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/alpha/alpha/src/sys -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/altq -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/pf -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000
Re: FreeBSD-stable
Where can I download latest FreeBSD-stable ? Thanks! http://snapshots.se.freebsd.org/ yw ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[HEADS UP] perl symlinks in /usr/bin will NOT be gone
On Sat, Jan 29, 2005 at 09:24:25PM +0100, Anton Berezin wrote: Unless I hear too many cries don't do that (with justification), I plan to not create any perl symlinks in /usr/bin in the forthcoming upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). This will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT; the existing pollution of /usr/bin will still be performed for older versions of FreeBSD, if requested via use.perl script. Out of all the arguments against this change the most persuasive for me was the one of ISPs having to modify all their customers' scripts. So - this change is out. Instead: - use.perl is gone in 5.X and -CURRENT, but not in 4.X; - its functions are delegated to pkg-install, namely: - symlink creation, due to the seeming consensus of this thread; it will be done better than it is done now; in particular, more symlinks will be created (perldoc, percc etc), and dangling symlinks will be removed on deinstall; - spamming of /etc/make.conf, which we need for ports; this is also going to be less intrusive than it is now; - spamming of /etc/manpath.config Thank you all for the discussion. \Anton. -- The moronity of the universe is a monotonically increasing function. -- Jarkko Hietaniemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 02:44:38PM +0100, Matthias Andree wrote: Erik Trulsson [EMAIL PROTECTED] writes: Hardcoded paths in scripts are a mess. What if I installed Perl into /opt/mumble on some other machine? /usr/freeware? /what/ever? Changed $PREFIX and/or $LOCALBASE? Then you would have nobody but yourself to blame. So ports not heeding PREFIX or LOCALBASE aren't buggy? Interesting POV. That is not what I said (but, no, they are not necessarily buggy depending on why the they don't heed PREFIX/LOCALBASE.) Respecting PREFIX and LOCALBASE is good, but keeping things working is even better. And what about all the scripts that administrators and users write that are not part of any port? Scripts that were written according to the de-facto standard that having '#!/usr/bin/perl' on the first line of the script will work correctly. As mentioned before, #! /usr/bin/env perl is the canonic SHORT way to run perl, longer ways are in perlrun(1). It might be the canonic way and it might even be the best way, but it is not the standard way. Older versions of perlrun(1) (like the one included in FreeBSD 4.x) does not even mention /usr/bin/env so don't expect too many scripts to use it (and the context in which 'env' is mentioned is handling OS-specific limitations of the #! mechanism.) perlrun(1) does however say that When possible, it's good for both /usr/bin/perl and /usr/local/bin/perl to be symlinks to the actual binary. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Anton Berezin wrote: In order to keep pkg-install simple, no old symlink chasing and removal will be done, although the detailed instructions will be posted in ports/UPDATING and in pkg-message for the ports. How about leaving it up to the installer? Much like the minicom port prompts the user if they would like to symlink a /dev/modem device, why not ask (post-install) Would you like to make a symlink in /usr/bin to your new installation? or as someone else has suggested add a make flag (make ADD_SYMLINK=yes). Those who wish to have an unpolluted /usr/bin can not opt for a symlink, those that want compatibility with a majority of the scripts already written can have the link created. Just a thought, Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sat, Jan 29, 2005 at 09:24:25PM +0100, Anton Berezin said: In practical terms this will mean a one-time sweep of your scripts in order to convert them, in a typical case, from #! /usr/bin/perl to #! /usr/local/bin/perl. options under discussion: 1) break *millions* of pieces of Perl software, plenty of it run by people unable or uninterested in modifying every last little corner of it (even with an automated find/replace, which is guaranteed to break *something*, and if I were them I would just switch to Debian at that point), so the FreeBSD's /usr/bin can have one less symlink by default. 2) respect the way the world actually is, and just leave the symlink in place. #1 does more than violate POLA; it's more akin to renaming /bin/cp to /bin/copy, in the name of progress, and saying everyone should just update their code. it's not clear to me how #1 is a serious choice. chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Slow Network with rl0 and 5.3
hello, after upgrading to 5.3 (cvsup) i have a lot of network problems with realtec 8139 cards. these cards worked fine with 4.x and 5.2.1. the network is slowing down heavily without seeing any problems reports on console or syslog (*.* logged). are there any known problems with these card and 5.3? this happens on different servers updated since the last 2 weeks. many thanks, karl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Vinum causes server to crash/reboot ...
Just got burnt on one of my machines, where I was looking to reconfigure my RAID drive ... right now, its down :( I cleared everything off the drive, unmount'd it and then did a 'vinum resetconfig' ... that all worked great, but as soon as I did a 'vinum create file' to recreate it, the server crashed/rebooted ... I forgot about that 'experience' from before, so failed to remember to comment out the line in /etc/fstab for that file system, so right now the server is sitting remotely at the 'choose shell for single user mode' prompt, but am wondering if this is actually expected behaviour, or a bug with vinum? I'm running 4.x from Oct 8th on that server, if its maybe a 'since been fixed' bug ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vinum causes server to crash/reboot ...
On Sunday, 30 January 2005 at 14:28:47 -0400, Marc G. Fournier wrote: Just got burnt on one of my machines, where I was looking to reconfigure my RAID drive ... right now, its down :( I cleared everything off the drive, unmount'd it and then did a 'vinum resetconfig' ... that all worked great, but as soon as I did a 'vinum create file' to recreate it, the server crashed/rebooted ... Where's the dump? Based on the information supplied, there's little anybody can do. I'd guess it won't show up again either. If it does, please supply the information requested in the man page or at http://www.vinumvm.org/vinum/how-to-debug.html. Greg -- See complete headers for address and phone numbers. pgpKz1aPKwJfM.pgp Description: PGP signature
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sun, Jan 30, 2005 at 02:47:08PM +0100, Matthias Andree wrote: Kris Kennaway [EMAIL PROTECTED] writes: In other words, it's an impossible dream to hope that all scripts will conform to this or any of the other possible choices (remember the perl motto). Even making everything perl in the ports collection use a uniform style is probably an infeasible task (recall 840 ports use /usr/bin/perl, and that's not counting the others that use another hardcoded variant of /usr/local/bin/perl). Well, broken ports are marked broken and removed after some months. How would broken Perl ports justify special treatment? As I mention above, it's a rule that would be impossible to enforce on third party scripts, so it would be wasted effort to try. Kris pgpobES3VncK8.pgp Description: PGP signature
Re: Vinum causes server to crash/reboot ...
'k, waiting for a tech to get at the server to get the server back up ... its happened before, and I *believe* that a core dump is generated, but, of course, my /var/crash is link'd onto the file system that I was in the process of rebuilding, so can't help there :( Will see if any of the other information is available ... On Mon, 31 Jan 2005, Greg 'groggy' Lehey wrote: On Sunday, 30 January 2005 at 14:28:47 -0400, Marc G. Fournier wrote: Just got burnt on one of my machines, where I was looking to reconfigure my RAID drive ... right now, its down :( I cleared everything off the drive, unmount'd it and then did a 'vinum resetconfig' ... that all worked great, but as soon as I did a 'vinum create file' to recreate it, the server crashed/rebooted ... Where's the dump? Based on the information supplied, there's little anybody can do. I'd guess it won't show up again either. If it does, please supply the information requested in the man page or at http://www.vinumvm.org/vinum/how-to-debug.html. Greg -- See complete headers for address and phone numbers. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
On Jan 30, 2005, at 12:17, Kris Kennaway wrote: On Sun, Jan 30, 2005 at 02:47:08PM +0100, Matthias Andree wrote: Kris Kennaway [EMAIL PROTECTED] writes: In other words, it's an impossible dream to hope that all scripts will conform to this or any of the other possible choices (remember the perl motto). Even making everything perl in the ports collection use a uniform style is probably an infeasible task (recall 840 ports use /usr/bin/perl, and that's not counting the others that use another hardcoded variant of /usr/local/bin/perl). Well, broken ports are marked broken and removed after some months. How would broken Perl ports justify special treatment? As I mention above, it's a rule that would be impossible to enforce on third party scripts, so it would be wasted effort to try. Many years ago in a far off version, perl was a port and all my loyal subjects worked in peace and harmony. However, someone changed perl to be part of the base system. My subjects rebelled and refused to work saying the the perl of great price could no longer be found. After many hours of chasing this perl and correcting its location my subjects returned to work, and peace and harmony reigned again. Now I see perl going back towards being a port. This realm is not looking forward to another strike by its subjects. The grocery store strike here was more than enough. Don't need any more of them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Sparc64 Install 5.3
Hi all Is it possible to install 5.3 on a sparc64 (Ultra 5) without using serial console, I seem to get garbled consoles when I try to install via normal screen and keyboard? Joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Network with rl0 and 5.3
I had a similar problem on a few boxes, you should check the mailing list archives for a recent discussion on how crappy the realtec nic's are. -- Ísak Ben, http://www.isak.is -- Original Message --- From: Karl M. Joch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sun, 30 Jan 2005 19:10:57 +0100 Subject: Slow Network with rl0 and 5.3 hello, after upgrading to 5.3 (cvsup) i have a lot of network problems with realtec 8139 cards. these cards worked fine with 4.x and 5.2.1. the network is slowing down heavily without seeing any problems reports on console or syslog (*.* logged). are there any known problems with these card and 5.3? this happens on different servers updated since the last 2 weeks. many thanks, karl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] --- End of Original Message --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: READ_DMA timeouts caused by ALI southbridge (5.3-STABLE)
Pertti Kosunen wrote: My READ_DMA timeout problem with 160GB disk partitially solved. Asus A7A266 southbridge (ALi 1535D+) don't support DMA with LBA48. This is somehow worked around with Windows drivers, so is same possible in FreeBSD also? I guess their workaround is to use PIO mode to access the portions that need 48bit access. There is currently no provision in ATA for doing this on a quirk basis, but that could be added at some time. I'll stick it on my TODO list... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Network with rl0 and 5.3
Hi, can you try the attached patch (relative to RELENG_5). It disables batch transfers from the system queue to the driver - an optimization introduced while enabling rl(4) for ALTQ. Please let me know if it improves the situation. If it does, this is a sign of a more fundamental problem in the driver locking (or the card timing) and needs further evaluation. Thanks. On Sunday 30 January 2005 22:12, Ísak Ben. wrote: I had a similar problem on a few boxes, you should check the mailing list archives for a recent discussion on how crappy the realtec nic's are. -- Ísak Ben, http://www.isak.is -- Original Message --- From: Karl M. Joch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sun, 30 Jan 2005 19:10:57 +0100 Subject: Slow Network with rl0 and 5.3 hello, after upgrading to 5.3 (cvsup) i have a lot of network problems with realtec 8139 cards. these cards worked fine with 4.x and 5.2.1. the network is slowing down heavily without seeing any problems reports on console or syslog (*.* logged). are there any known problems with these card and 5.3? this happens on different servers updated since the last 2 weeks. many thanks, karl -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News Index: if_rl.c === RCS file: /usr/store/mlaier/fcvs/src/sys/pci/if_rl.c,v retrieving revision 1.145 diff -u -r1.145 if_rl.c --- if_rl.c 9 Aug 2004 20:22:17 - 1.145 +++ if_rl.c 30 Jan 2005 18:24:23 - @@ -964,7 +964,7 @@ #endif ifp-if_capenable = ifp-if_capabilities; IFQ_SET_MAXLEN(ifp-if_snd, IFQ_MAXLEN); - ifp-if_snd.ifq_drv_maxlen = IFQ_MAXLEN; + ifp-if_snd.ifq_drv_maxlen = 0; IFQ_SET_READY(ifp-if_snd); callout_handle_init(sc-rl_stat_ch); pgp2w9R38nBiD.pgp Description: PGP signature
Size of metadata required for GBDE
Hi all, I just fiddled around with using GBDE for ISO images (it works) and stumbled across the need to guess the size required for the GBDE container. Looks like the size is not increasing linearly. Here are the numbers of 512 byte blocks available in md0 and md0.bde md0 | md0.bde | diff. 20481952 96 40963936 160 81927936 256 16384 15872 512 32768 31744 1024 65536 63520 2016 So, what's the correct formula? Ulrich Spoerlein -- PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. didn't you understand? pgpkPh0P7TCQk.pgp Description: PGP signature
Re: Size of metadata required for GBDE
In message [EMAIL PROTECTED], Ulrich Spoerlein writes: Hi all, I just fiddled around with using GBDE for ISO images (it works) and stumbled across the need to guess the size required for the GBDE container. Looks like the size is not increasing linearly. Here are the numbers of 512 byte blocks available in md0 and md0.bde md0 | md0.bde | diff. 20481952 96 40963936 160 81927936 256 16384 15872 512 32768 31744 1024 65536 63520 2016 So, what's the correct formula? First off, if you want to use gbde on a CDROM you should use a sectorsize of 2048 througout (-S 2048 argument to mdconfig). The amount of metadata in GBDE is pretty straight forward: 1. If do not use off-line keyfiles: deduct one sector. 2. Deduct the key sectors (1 to 4) 3. Find zone size: nsect = sectorsize / 16 nzone = nsect + 1 4. Find number of zones: z = remaining_sectors / nzone 5. Find usable size: size = z * nsect 6. Find overhead/metadata as: total_sectors - size -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with mailing lists
I've been trying to change my email address from [EMAIL PROTECTED] to [EMAIL PROTECTED] on all my subscriptions at freebsd.org, but the Change globally option isn't working. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
in message [EMAIL PROTECTED], wrote Anton Berezin thusly... Unless I hear too many cries don't do that (with justification), I plan to not create any perl symlinks in /usr/bin in the forthcoming upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2). This will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT I am for it. Please do do that. Thanks. - Parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
From: Matthias Andree [EMAIL PROTECTED] Date: Sun, 30 Jan 2005 14:49:41 +0100 Sender: [EMAIL PROTECTED] Holger Kipp [EMAIL PROTECTED] writes: It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT, especially as most perl programmers assume /usr/bin/perl to be the correct path. POLA doesn't apply to -CURRENT. POLA always applies, but major releases are considered a good opportunity to make needed changes that would generate excessive astonishment on a minor update. This is at least too big for a minor update POLA violation and may well be too big for even a major version. FreeBSD does NOT exist to justify hier(7), style(9) or anything of the sort. These are tools to provide consistent behavior and make FreeBSD maintainable and understandable to developers and users, not to say screw the users. Perl has been in /usr/bin on almost every Unix-like OS around for longer than FreeBSD has existed. I think changing something like this would be REALLY astonishing to way too many users and developers who happen to write Perl and expect to find it where the Perl documentation say to. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
