Kernel panic on 5.3-STABLE w/ ACPI
Hi there! I have sent this message before (Wed, 19 Jan 2005 04:11:40 +0100), but without respons. So I'll try again. --- I have gladly installed FreeBSD5 on my laptop to be free from M$ !! :D And soon I will install it on my worksation aswell. Here is (in my eyes) an unusual boot error. When I start my laptop everything is fine untill I have to choose how I want to boot FreeBSD. As a first try I choosed the default option just to see everything is working with the new kernel. It didn't.. I then tryed to boot with ACPI (choise nr 2 at the bootmenu), and everything started upp nicely. I normally only want to run with ACPI enabled, so it's not a large problem for me.. but maby for someone else? I have two questions.. 1: Is there something wrong with my kernelconfig or is it a bug? 2: How do I change the default boot procedure from menu nr 1 (without ACPI) to menu nr 2 (with ACPI)? I left some useful information at the bottom of this message. And here are a webpage that shows some information about my harware: http://support.packardbell.com/se/mypc/index.php?sernr=105601500123# Thanks! Anders --- START OF Boot without ACPI (default) --- Jan 19 03:05:38 laptop syslogd: kernel boot file is /boot/kernel/kernel Jan 19 03:05:38 laptop kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jan 19 03:05:38 laptop kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 19 03:05:38 laptop kernel: The Regents of the University of California. All rights reserved. Jan 19 03:05:38 laptop kernel: FreeBSD 5.3-STABLE #0: Sat Jan 15 21:23:58 CET 2005 Jan 19 03:05:38 laptop kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HAGGE Jan 19 03:05:38 laptop kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Jan 19 03:05:38 laptop kernel: CPU: mobile AMD Athlon(tm) XP 1600+ Processor (1400.06-MHz 686-class CPU) Jan 19 03:05:38 laptop kernel: Origin = AuthenticAMD Id = 0x680 Stepping = 0 Jan 19 03:05:38 laptop kernel: Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Jan 19 03:05:38 laptop kernel: AMD Features=0xc048MP,AMIE,DSP,3DNow! Jan 19 03:05:38 laptop kernel: real memory = 234815488 (223 MB) Jan 19 03:05:38 laptop kernel: avail memory = 224317440 (213 MB) Jan 19 03:05:38 laptop kernel: npx0: [FAST] Jan 19 03:05:38 laptop kernel: npx0: math processor on motherboard Jan 19 03:05:38 laptop kernel: npx0: INT 16 interface Jan 19 03:05:38 laptop kernel: pcib0: Host to PCI bridge pcibus 0 on motherboard Jan 19 03:05:38 laptop kernel: pir0: PCI Interrupt Routing Table: 5 Entries on motherboard Jan 19 03:05:38 laptop kernel: $PIR: BIOS IRQ 5 for 0.17.INTC is not valid for link 0x3 Jan 19 03:05:38 laptop kernel: $PIR: BIOS IRQ 11 for 0.11.INTA is not valid for link 0x3 Jan 19 03:05:38 laptop kernel: $PIR: BIOS IRQ 10 for 0.18.INTA is not valid for link 0x3 Jan 19 03:05:38 laptop kernel: pci0: PCI bus on pcib0 Jan 19 03:05:38 laptop kernel: agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xa000-0xa3ff at device 0.0 on pci0 Jan 19 03:05:38 laptop kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0 Jan 19 03:05:38 laptop kernel: pci1: PCI bus on pcib1 Jan 19 03:05:38 laptop kernel: pci1: display, VGA at device 0.0 (no driver attached) Jan 19 03:05:38 laptop kernel: cbb0: TI1410 PCI-CardBus Bridge at device 8.0 on pci0 Jan 19 03:05:38 laptop kernel: cardbus0: CardBus bus on cbb0 Jan 19 03:05:38 laptop kernel: pccard0: 16-bit PCCard bus on cbb0 Jan 19 03:05:38 laptop kernel: Jan 19 03:05:38 laptop kernel: Jan 19 03:05:38 laptop kernel: Fatal trap 12: page fault while in kernel mode Jan 19 03:05:38 laptop kernel: fault virtual address = 0xe7fe6 Jan 19 03:05:38 laptop kernel: fault code = supervisor read, page not present Jan 19 03:05:38 laptop kernel: instruction pointer = 0x8:0xc00e9eb5 Jan 19 03:05:38 laptop kernel: stack pointer = 0x10:0xc082193c Jan 19 03:05:38 laptop kernel: frame pointer = 0x10:0xc082193c Jan 19 03:05:38 laptop kernel: code segment = base 0x0, limit 0xf, type 0x1b Jan 19 03:05:38 laptop kernel: = DPL 0, pres 1, def32 1, gran 1 Jan 19 03:05:38 laptop kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Jan 19 03:05:38 laptop kernel: current process = 0 (swapper) Jan 19 03:05:38 laptop kernel: trap number = 12 Jan 19 03:05:38 laptop kernel: panic: page fault Jan 19 03:05:38 laptop kernel: Uptime: 1s Jan 19 03:05:38 laptop kernel: Automatic reboot in 15 seconds - press a key on the console to abort Jan 19 03:05:38 laptop kernel: Rebooting... --- END OF Boot without ACPI (default) --- --- START OF Boot with ACPI (Choise nr 2) --- Jan 19 03:05:38 laptop kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jan 19 03:05:38 laptop kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 19 03:05:38 laptop kernel: The Regents of the University of California. All rights reserved. Jan 19 03:05:38 laptop kernel: FreeBSD 5.3-STABLE #0: Sat Jan 15 21:23:58 CET 2005
Re: Kernel panic on 5.3-STABLE w/ ACPI
* Admin @ InterCorner [EMAIL PROTECTED] [20050129 20:09]: I have sent this message before (Wed, 19 Jan 2005 04:11:40 +0100), but without respons. So I'll try again. You didn't provide enough info to help with ACPI debugging http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html and your questions on disabling acpi might be more appropiate in [EMAIL PROTECTED] Try the following: echo hint.acpi.0.disabled=1 /boot/loader.conf For details, man acpi, man loader.conf qvb -- pica ___ 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 be gone
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]
Re: [HEADS UP] perl symlinks in /usr/bin will 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. 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. Anyway do not forget about mail to portmgr with the patch 's|#!/usr/bin/perl|#!/usr/bin/env perl' for Tools/* stuff before committing these changes. -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
Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? -- 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
This has a huge external impact. Yes they are easily corrected but unless there is a specific need to remove them my vote would be to not put people though such a potentially painful change. Steve - Original Message - From: Anton Berezin [EMAIL PROTECTED] 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. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.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 Sat, Jan 29, 2005 at 10:09:05PM +0100, Oliver Lehmann wrote: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? Yes, hence the HEADS UP with a possibility to back off if people really sure it is a bad idea. \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
Oliver Lehmann wrote: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl ...so long as /usr/local/bin is in the $PATH, they should still work fine. -- -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 Sat, Jan 29, 2005 at 04:19:21PM -0500, Chuck Swiger wrote: Oliver Lehmann wrote: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl ...so long as /usr/local/bin is in the $PATH, they should still work fine. True, but how many 3rd party scripts are well-behaved? A minority is my guess. -- 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: Seemingly odd disc i/o behaviour, need help to diagnose
On Fri, 28 Jan 2005, Oren Baum wrote: Description of Server configuration and problems. Configuration: FreeBSD 4.4-RELEASE apache+mod_ssl-1.3.22+2.8.5_1 mysql-server-3.23.42 Hard Drive (dual ATA disks, no RAID) on a Dell P4 PowerEDGE server It bears mentioning again ... these releases are very old and have known security issues. If this server is accessible to the public Internet its probably been hacked several times over. An upgrade to at least 4.8-RELEASE+patches, apache 1.3.33, and the latest mysql-server-3.23 is recommended. We had many speed and timeout issues so we recompiled the kernel with maxusers=128 instead of the previous 32 and moved the hard drives into a new P4 2.8Ghz PowerEdge Case. I'd think this is a PE1750 but those have SCSI disks, not IDE. atapci0: Generic PCI ATA controller port 0xffa0-0xffaf,0x374-0x377,0x170- 0x177,0x3f4-0x3f7,0x1f0-0x1f7 irq 11 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 atapci1: Generic PCI ATA controller port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20- 0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 mem 0xdff3fc00-0xdff3 irq 5 at device 31.2 on pci0 ata2: at 0xfe00 on atapci1 ata3: at 0xfe20 on atapci1 Also as noted before this may be causing your disks to run at UDMA33 and not at their full interface speed. The 'atacontrol mode ' command will display the current settings (although you'll have to specify a bus, in this case 0, 2, and 3). Server is configured to hold 2 medium sized MySQL DB's accessed through various perl and php scripts via websites on the server. Uptime: 78463 Threads: 18 Questions: 351685 Slow queries: 328 Opens: 2793 Flush tables: 1 Open tables: 64 Queries per second avg: 4.482 Each httpd process is of size 15MB to 20MB * about 15 processes Mysqld process is of size 32MB, resident 16MB How much RAM does the machine have? A full dmesg output would be nice for reference. If we run pine on a large mailbox or any other disk i/o intensive task, all other processes in motion seem to stall until the disk i/o is complete. This manifests itself in timeouts on webpages that require DB data, IMAP timeouts for other mail accounts, and even odd console/shell behaviour. I suspect this is simple I/O contention from one of two sources: 1. mysql keeps the disks loaded enough that when pine slurps in the big file its able to out-contend the other processes. 2. pine bloats badly with large mailboxes, enough to cause other processes to swap, which kills performance dead. I'd suggest running 'iostat 1' in one window or VTY, 'top -s1' in another, watch for a bit to get a baseline, then start up pine in another window and watch the numbers change. In the top window, watch for the Swap line to change with +In and +Out lines, and for the total use to go up. In the iostat window watch how big MB/s gets, and the 'sy' column on the far right, which is system CPU time as a percent. If you're seeing the iostat MB/s go up to a level and stop, but swap stay still, then its case #1. If you see iostat go up and Swap to start increasing then its case #2. In case #2 the System CPU % should go up radically (+10-20%) compared to baseline. To fix case #1 you'll need to get faster storage, either by upgrading the OS to make full use of the available ATA channels or by getting a more capable storage subsystem (SCSI+disk array, for example). To fix case #2 you need to install more physical RAM. ATA does not handle multiple transaction streams well since each bus can only take one command at a time. The ata driver attempts to optimize the order of these operations but compared to SCSI will not scale well in the face of large quantities of diverse transactions. (Before people get up in arms, I'll say that YMMV depending on workload, available cache, interface speeds, etc.) There is, of course, option #3 which is to move your mail to another machine. :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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, 29 Jan 2005, Oliver Lehmann wrote: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? The following URL: http://www.googlefight.com/cgi-bin/compare.pl?q1=%23%21%2Fusr%2Fbin%2Fperlq2=%23%21%2Fusr%2Fbin%2Fenv+perlB1=Make+a+fight%21compare=1langue=us Suggests firmly that the answer to that question is yes. What worries me particularly about the proposed change is that it requires administrators to touch the scripts of their user's files as part of an upgrade -- this is not a good situation for an ISP to be put in. That or to immediately re-add the symlink on the basis that the practical reality is that (despite some limited documentation to the contrary), that's the way everyone runs perl. I have the suspicion that while removing this symlink may encourage programming cleanliness, it's going to shoot a lot of feet unnecessarily. Also, since env isn't a built-in, it means exec runs twice for every perl script, not once... 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
Chuck Swiger wrote: Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl ...so long as /usr/local/bin is in the $PATH, they should still work fine. It seems that this usage is not that common. On my 5.3R system the stats are: 1101 scripts ending in .pl 490 of these have #! something/perl as their 1st line 10 of these use #!/usr/bin/env perl regards 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
On 2005-01-29 at 21:24:25 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. What purpose does this serve? To keep the base system clean? I'm not convinced that having just a few (2?) symlinks in /usr/bin will pollute the base system, but it does save having to modify potentially thousands of scripts. Isn't the latter *much* more expensive? pgpLbZrwYS2bs.pgp Description: PGP signature
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
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 have to vote no on this. This will fundamentally break a majority of systems, for no well defined reason. The clean removal of a single symlink does not justify the pain it will create. If you want to do this in 6-CURRENT, then fine, but leave 5-STABLE alone. Think of this as the equivalent of an ABI change we doesn't happen without really good reason in STABLE. This is not a really good reason. Phil. ___ 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:17:47PM +0100, Anton Berezin wrote: On Sat, Jan 29, 2005 at 10:09:05PM +0100, Oliver Lehmann wrote: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? Yes, hence the HEADS UP with a possibility to back off if people really sure it is a bad idea. With the removal of perl from the base-system, they put something in place to make sure that the installed version from the ports collection would be a drop-in replacement and that no functionality would be removed. It all worked like a charm. Be pragmatic, a little bit pollution (a handfull of symlinks only, not even real files) gives you the flexibility to run whatever Perl version you want. Please don't break it now. 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 Sat, 2005-Jan-29 21:24:25 +0100, Anton Berezin wrote: 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. I'd also like to object. The perl documentation has consistently stated that a symlink to /usr/bin/perl should be created so that scripts can use #!/usr/bin/perl. Removing this symlink will impact users as well as administrators and (IMHO) will adversely impact on the image of FreeBSD. -- Peter Jeremy ___ 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, 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. 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? 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. I would rather have a couple of symlinks chased down and removed than have potentially hundreds (or thousands) of scripts needing to be tweaked upon installation of a new piece of software that is predominantly Linux oriented. I try to wrote my stuff to work on multiple platforms (FreeBSD. Linux, Windows) without major modification as a practical thing. This would make it more platform dependent for patches or tech support. I would prefer to NOT see this change implemented. Doug ___ 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 Saturday 29 January 2005 21:24, Anton Berezin wrote: Unless I hear too many cries don't do that (with justification), I Please, don't do that! http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#DEFINE-POLA -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp9wLPC2pT6O.pgp Description: PGP signature
Re: [HEADS UP] perl symlinks in /usr/bin will be gone
Oliver Lehmann [EMAIL PROTECTED] writes: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? 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? I'd say let the ports patch the right location at install time and if they break after upgrading both perl and the port, they deserve no better. -- 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
On Sun, Jan 30, 2005 at 03:39:51AM +0100, Matthias Andree wrote: Oliver Lehmann [EMAIL PROTECTED] writes: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? 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. From the Perl documentation: It may seem obvious to say, but Perl is useful only when users can easily find it. When possible, it's good for both /usr/bin/perl and /usr/local/bin/perl to be symlinks to the actual binary. If that can't be done, system administrators are strongly encouraged to put (symlinks to) perl and its accompanying utilities, such as perldoc, into a directory typically found along a user's PATH, or in another obvious and convenient place. In this documentation, #!/usr/bin/perl on the first line of the script will stand in for whatever method works on your system. I'd say let the ports patch the right location at install time and if they break after upgrading both perl and the port, they deserve no 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. No, the proposed change is a bad idea that will create lots of problems for very little gain. -- 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
On Sun, 30 Jan 2005, Matthias Andree wrote: Oliver Lehmann [EMAIL PROTECTED] writes: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? 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? I'd say let the ports patch the right location at install time and if they break after upgrading both perl and the port, they deserve no better. Ports covers only a *very* small proportion of the perl scripts in use out there. There are for instance no end of CGI scripts and system automation scripts out there that are produced for in house use. Imagine what will be a fairly typical case: Some website owner who hired a programmer in the past to set stuff up suddenly finds their site is broken. They'll probably call their hosting provider first. The hosting provider might require all their affected customers to find someone who understands enough to fix this - which would add up to millions of dollars of expenditure worldwide if everyone took that approach. More likely, most hosting providers would put back in the symlinks that it is proposed to remove. They'll then have a 'non-standard' modification to maintain on their own systems, and this will probably be standard practice, not modifying all the scripts people want to put in. Seems like a lot of people wasting effort to me. Andrew McNaughton -- The United States is committed to the worldwide elimination of torture and we are leading this fight by example. - George Bush, 26 June 2003 --- Andrew McNaughton http://www.scoop.co.nz/ [EMAIL PROTECTED] Mobile: +61 422 753 792 ___ 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, 29 Jan 2005, Chuck Swiger wrote: Oliver Lehmann wrote: Anton Berezin wrote: 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. Wouldn't that break most of the 3rd party scripts out in the world? Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl ...so long as /usr/local/bin is in the $PATH, they should still work fine. I commonly use this approach, but I run into some problems with flags. Probably a simple gotcha someone can help with. Eg the following useful constructs don't work: #!/usr/bin/env perl -p #!/usr/bin/env perl -T #!/usr/bin/env perl -w Andrew McNaughton -- The United States is committed to the worldwide elimination of torture and we are leading this fight by example. - George Bush, 26 June 2003 --- Andrew McNaughton http://www.scoop.co.nz/ [EMAIL PROTECTED] Mobile: +61 422 753 792 ___ 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, 29 Jan 2005, 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. No, in practical terms this does not mean a one-time sweep at all. It means we now have to manually create this symlink on all machines instead. There is simply no realistic way to change all scripts to use /usr/local/bin/perl (and keep finding/replacing this for all new scripts users may install - they usually don't come from the ports collection) - while this may be doable on a single user's local workstation, it is just not doable in places like an ISP environment, and no doubt many others. So then we'll be forced to create this symlink manually anyway, on all servers, probably for all eternity, and face the screaming users everytime someone forgets it on one. It also goes against what every other platform does with regards to perl, and it is IMHO a big POLA violation. So please - don't do that. :( /leg ___ 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
Andrew McNaughton wrote: On Sat, 29 Jan 2005, Chuck Swiger wrote: [ ... ] Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl ...so long as /usr/local/bin is in the $PATH, they should still work fine. I commonly use this approach, but I run into some problems with flags. Probably a simple gotcha someone can help with. Eg the following useful constructs don't work: #!/usr/bin/env perl -p #!/usr/bin/env perl -T #!/usr/bin/env perl -w See man perlrun for some additional suggestions (and caveats), as it gives examples for passing -p to perl when invoked via /usr/bin/env or /bin/sh. You might also try putting a -- between the 'env' and the 'perl' to indicate the end of command-line option processing to env. It's possible that taint mode cannot be invoked this way (as that needs to be set very early on), though. There also seems to exist a PERL5OPT variable which could be set like so: #!/usr/bin/env PERL5OPT='-w' perl This should support -T, too, only it will zap any additional args specified afterwards (or so the docs say)... -- -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 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. 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
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. Please respect Reply-To. Thank you, \Anton. 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. Scott ___ 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
Changing this so it affects 5-STABLE is suicide it will annoy a lot of user's and draw people away from FreeBSD to other platforms, I dont see any benefit from doing this the symlinks have caused me no ill effect whatsoever Chris On Sat, 29 Jan 2005 22:51:37 -0700, Scott Long [EMAIL PROTECTED] 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. 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. 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. Scott ___ 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: Linking problems with gcc 3.4.2 and glibc on 5.3-stable
I mean them downloading from the psybnc website and installing from that tarball, I guess an option I can provide is to compile from ports and make some sort of script to install the binaries to the user's dir. Chris On Sat, 29 Jan 2005 21:10:53 +1300, Jonathan Chen [EMAIL PROTECTED] wrote: On Sat, Jan 29, 2005 at 02:45:27AM +, Chris wrote: I am talking about the psybnc source because its for users on the server who cannot compile software from ports. If they can't compile from ports, then they certainly won't be able to install it; won't that mean that they won't be able to use it? If they want to do is compile it, all they have to do is to apply the patches from the port. -- Jonathan Chen [EMAIL PROTECTED] -- Only the meek get pinched. The bold survive. - Ferris Bueller ___ 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
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. What purpose does this serve? To keep the base system clean? I'm not convinced that having just a few (2?) symlinks in /usr/bin will pollute the base system, but it does save having to modify potentially thousands of scripts. Isn't the latter *much* more expensive? Agreed. Removing perl symlinks in /usr/bin is an incredibly bad idea. 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]
