Re: PCI brokenness
> >> So it doesn't boot at all, that's different from "hard-hang during reboot". > >> :) After ppc your device probe is over. You could be getting an > >> interrupt storm. Can you break into ddb when this happens? > > > > Roger the diference. :-) > > > > No. I cannot break into DDB. The keyboard may as well not be there. > > Humm. :( This is definitely a regression that needs to be fixed. > (For the non-ACPI case). Did you have this problem on older kernels > as well? Does 4.x work ok w/o hanging? I'll check. The current problems are on my laptop, and I cannot afford the trauma that reverting it to RELENG_4 will cause. I have a crash box at home that I'll try. > >> > In practical terms, this is a regression, in that previous function > >> > has been removed before an adequate replacement was ready. > >> > >> Ok, I have a question now. How did ata get probed before? If you > >> add hints for it does it get probed? It doesn't appear to be a PCI > >> device. It may be that we need to make it work as an ATA attachment > >> somehow. Also, did ata1 show up before? > > > > Yes - I have hints. > > > > Here is my hints file (which has not changed in at least 6 months) > > Ok, so you only have ata0 and no ata1. So that means the ACPI ata > attachment almost worked. Humm, try doing a hack to change ATA_IOADDR_RID > in ata-all.h from 0 to 1 along with the previous patch to add an acpi > attachment for ata and see if that works. I still have no idea why > the ata hint device isn't working. It should be working fine. :( OK. I'll get back to you shortly. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > "Hard hang" means that the probe messages stop around the parallel > > device, and nothing else happens. The PCCARD ethernet remains dead. > > the disk is silent and no amount of keyboard activity does anything > > at all. Serial console dead. Reset needed to reboot. > > So it doesn't boot at all, that's different from "hard-hang during reboot". > :) After ppc your device probe is over. You could be getting an > interrupt storm. Can you break into ddb when this happens? Roger the diference. :-) No. I cannot break into DDB. The keyboard may as well not be there. > > In practical terms, this is a regression, in that previous function > > has been removed before an adequate replacement was ready. > > Ok, I have a question now. How did ata get probed before? If you > add hints for it does it get probed? It doesn't appear to be a PCI > device. It may be that we need to make it work as an ATA attachment > somehow. Also, did ata1 show up before? Yes - I have hints. Here is my hints file (which has not changed in at least 6 months) # $FreeBSD$ #hint.acpi.0.disabled="1" #hint.apm.0.at="nexus" #hint.apm.0.flags="0x20" hint.ata.0.at="isa" hint.ata.0.irq="14" hint.ata.0.port="0x1F0" hint.atkbd.0.at="atkbdc" hint.atkbd.0.flags="0x1" hint.atkbd.0.irq="1" hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.fdc.0.at="isa" hint.fdc.0.port="0x3F0" hint.fdc.0.irq="6" hint.fdc.0.drq="2" hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.npx.0.at="nexus" hint.npx.0.irq="13" hint.npx.0.port="0x0F0" hint.pcic.0.at="isa" #hint.pcic.0.irq="3" hint.pcic.0.maddr="0xd" hint.pcic.0.port="0x3e0" hint.pmtimer.0.at="isa" hint.ppc.0.at="isa" hint.ppc.0.irq="7" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.vga.0.at="isa" hint.pcm.0.at="isa" hint.pcm.0.irq="5" hint.pcm.0.drq="1" hint.pcm.0.flags="0x0" #hint.midi.0.at="isa" #hint.midi.0.irq="5" #hint.midi.0.flags="0x0" #hint.midi.0.at="isa" #hint.midi.0.port="0x2F8" #hint.midi.0.irq="3" hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x10" > >> Iwasaki-San's patch adds back in the only part of the extra "bogus" > >> stuff that legacy took out that could have an effect on your system > >> with respect to PCI. > > > > Ok. But it doesn't work. :-( > > Well, it does fix some things since we now find your PCI devices. > Assuming that works that is all that legacy changed. Adding > legacy didn't change anything wrt ata(4). Did you used to have > hints for ata and now don't perchance? No. I have 2 kernels - /boot/kernel (today's sources) /boot/kernel.old (sept 22nd sources) same device.hints. kernel.old works, kernel has no hard disk. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
gt; at port 0x100-0x10f irq 3 function 0 config 1 on pccard0 ep0: Ethernet address 00:10:5a:2d:39:c6 Mounting root from ufs:/dev/ad0s2a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > I tried this patch, and it made some progress (dmesg included). The > > ATA system still seems badly broken, there is a spurious mention of > > some kerneldump. I also have no console. > > Hmm, ata0 may be getting the wrong resources. Hmm. Try iwasaki-san's > patch to acpi_pcib_* instead and see if it that helps. Either that or > turn off ACPI for the time being. Iwasaki-San's patch made no difference that I could see. Disabling ACPI causes my system to hard-hang during reboot. I might be able to fix that by futzing with device.hints, but that took me a whole weekend and a reinstall last time I tried. Device.hints is a dangerous thing to play with. > > Perhaps the legacy stuff needs to be backed out or disabled pending fixing? > > Well, the problem here is that ACPI isn't working, not that legacy is broken. > What legacy does is make it so that if we try to use ACPI, we actually rely > on it to work. If we can't get ACPI to work like it is supposed to we need > to either fix it or disable it for now. 22nd September ACPI works. Suspend/resume, power shutdown, etc. > > Copyright (c) 1992-2002 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD 5.0-CURRENT #0: Wed Oct 2 12:15:40 BST 2002 > > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ce000. > > Preloaded elf module "/boot/kernel/linux.ko" at 0xc04ce0a8. > > Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04ce154. > > Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04ce200. > > Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04ce2ac. > > Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04ce358. > > Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04ce404. > > Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04ce4b0. > > Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04ce55c. > > Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04ce608. > > Preloaded elf module "/boot/kernel/random.ko" at 0xc04ce6b4. > > Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04ce760. > > Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04ce810. > > Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04ce8bc. > > Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04ce96c. > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cea1c. > > Timecounter "i8254" frequency 1193182 Hz > > Timecounter "TSC" frequency 233289544 Hz > > CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x581 Stepping = 1 > > Features=0x8001bf > > real memory = 67174400 (65600K bytes) > > avail memory = 60010496 (58604K bytes) > > Intel Pentium detected, installing workaround for F00F bug > > npx0: on motherboard > > npx0: INT 16 interface > > acpi0: on motherboard > > acpi0: power button is handled as a fixed feature programming model. > > Timecounter "ACPI-fast" frequency 3579545 Hz > > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 > > acpi_cpu0: on acpi0 > > acpi_tz0: on acpi0 > > acpi_lid0: on acpi0 > > acpi_acad0: on acpi0 > > acpi_cmbat0: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > atspeaker0 port 0x61 on acpi0 > > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > > atkbd0: flags 0x1 irq 1 on atkbdc0 > > kbd0 at atkbd0 > > psm0: irq 12 on atkbdc0 > > psm0: model IntelliMouse, device ID 3 > > ata0 port 0x3f6,0x1f0-0x1f7 irq 14 on acpi0 > > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > > sio0: type 16550A > > ppc0: parallel port not found. > > ppc0: parallel port not found. > > Timecounters tick every 10.000 msec > > Initializing GEOMetry subsystem > > acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% > > ad0: 19077MB [38760/16/63] at ata0-master BIOSPIO > > Mounting root from ufs:/dev/ad0s2a > > stray irq 7 > > stray irq 7 > > Kerneldump off=2239236096 len=134217728 > > Kerneldump off=2239236096 len=134217728 > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > > > syncing dis
Re: PCI brokenness
Hi I tried this patch, and it made some progress (dmesg included). The ATA system still seems badly broken, there is a spurious mention of some kerneldump. I also have no console. Perhaps the legacy stuff needs to be backed out or disabled pending fixing? M Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed Oct 2 12:15:40 BST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ce000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc04ce0a8. Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04ce154. Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04ce200. Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04ce2ac. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04ce358. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04ce404. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04ce4b0. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04ce55c. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04ce608. Preloaded elf module "/boot/kernel/random.ko" at 0xc04ce6b4. Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04ce760. Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04ce810. Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04ce8bc. Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04ce96c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cea1c. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 233289544 Hz CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 67174400 (65600K bytes) avail memory = 60010496 (58604K bytes) Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 atspeaker0 port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 ata0 port 0x3f6,0x1f0-0x1f7 irq 14 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0: parallel port not found. ppc0: parallel port not found. Timecounters tick every 10.000 msec Initializing GEOMetry subsystem acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% ad0: 19077MB [38760/16/63] at ata0-master BIOSPIO Mounting root from ufs:/dev/ad0s2a stray irq 7 stray irq 7 Kerneldump off=2239236096 len=134217728 Kerneldump off=2239236096 len=134217728 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 2 2 2 1 1 done Uptime: 22s Terminate ACPI Rebooting... > On 01-Oct-2002 Mark Murray wrote: > > Hi > > > > I'm running a kernel with your very latest nexus.c 1.49. > > > > The problem of the disappearing HD has not been fixed by this. > > > > Enclosed are verbose mesg's, one from a three-hour-ago > > (1st Oct 2002, 11:00 am, BST) kernel (broken), and another > > from a working Sept 22nd kernel. > > This is quite weird. You have a PCI bus and ACPI still finds > it fine, it just doesn't probe/attach any child devices. Hmm, > and your ATA controller isn't on the PCI bus. Ok, weird. Do > you have hints for your ata device? It looks like you had > hints for it in your good kernel boot since it was found on > isa0. Hmm, can you try this patch: > > Index: ata-isa.c > === > RCS file: /usr/cvs/src/sys/dev/ata/ata-isa.c,v > retrieving revision 1.9 > diff -u -r1.9 ata-isa.c > --- ata-isa.c 20 Sep 2002 18:08:57 - 1.9 > +++ ata-isa.c 1 Oct 2002 14:26:39 - > @@ -98,6 +98,7 @@ > }; > > DRIVER_MODULE(ata, isa, ata_isa_driver, ata_devclass, 0, 0); > +DRIVER_MODULE(ata, acpi, ata_isa_driver, ata_devclass, 0, 0); > > /* > * the following is a bandaid to get ISA only setups to link, > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> On Tue, 1 Oct 2002, Mark Murray wrote: > > I'm running a kernel with your very latest nexus.c 1.49. > > > > The problem of the disappearing HD has not been fixed by this. > > > > Enclosed are verbose mesg's, one from a three-hour-ago > > (1st Oct 2002, 11:00 am, BST) kernel (broken), and another > > from a working Sept 22nd kernel. > > I noticed both of yours and the other "me too" reply indicated ACPI was in > use. Is the behavior different when acpi is disabled? Yeah. Booting fails completely. Hard hang after probing the parallel port. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCI brokenness
Hi I'm running a kernel with your very latest nexus.c 1.49. The problem of the disappearing HD has not been fixed by this. Enclosed are verbose mesg's, one from a three-hour-ago (1st Oct 2002, 11:00 am, BST) kernel (broken), and another from a working Sept 22nd kernel. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Tue Oct 1 11:26:25 BST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ce000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc04ce0b4. Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04ce160. Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04ce20c. Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04ce2b8. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04ce364. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04ce410. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04ce4bc. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04ce568. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04ce614. Preloaded elf module "/boot/kernel/random.ko" at 0xc04ce6c0. Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04ce76c. Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04ce81c. Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04ce8c8. Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04ce978. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cea28. Calibrating clock(s) ... TSC clock: 233270316 Hz, i8254 clock: 1193097 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 233289783 Hz CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 67174400 (65600K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x004f5000 - 0x04007fff, 61943808 bytes (15123 pages) avail memory = 60010496 (58604K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f8e20 bios32: Entry = 0xfe95a (c00fe95a) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xc5f8 pnpbios: Found PnP BIOS data at 0xc00f8e30 pnpbios: Entry = f:90a8 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID c932f351 Other BIOS signatures found: Intel Pentium detected, installing workaround for F00F bug null: random: mem: npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 0, max = 2, width = 3 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 ACPI timer looks GOOD min = 0, max = 1, width = 2 Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atspeaker0 port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:, flags:, packet size:4 psm0: syncmask:08, syncbits:08 sio0: irq maps: 0x1 0x11 0x11 0x11 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A unknown: not probed (disabled) ppc0: parallel port not found. unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ppc0: parallel port not found. unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) BIOS Geometries: 0:03f8fe3f 0..1016=1017 cylinders, 0..254=255 heads, 1..63=63 sectors 0 a
ATA driver broken?
Hi I can't boot a kernel after my 22nd Sept one. The ATA disk controller does not probe at all, and no bootable disk is found by the kernel. The machine is a Toshiba Libretto 110CT. Here is a dmesg: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Sep 28 13:31:34 BST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO Preloaded elf kernel "/boot/kernel/kernel" at 0xc04cd000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc04cd0a8. Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04cd154. Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04cd200. Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04cd2ac. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04cd358. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04cd404. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04cd4b0. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04cd55c. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04cd608. Preloaded elf module "/boot/kernel/random.ko" at 0xc04cd6b4. Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04cd760. Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04cd810. Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04cd8bc. Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04cd96c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cda1c. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 233289368 Hz CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 67174400 (65600K bytes) avail memory = 60014592 (58608K bytes) Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 atspeaker0 port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77a,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port Timecounters tick every 10.000 msec Initializing GEOMetry subsystem acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% Mounting root from ufs:/dev/ad0s2a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ttys patch - any objections?
> I agree. I think that more ttys is a bad idea, since each one takes > more memory as well (since the data space isn't shared). While this > is a small amount, it is a pain for lower memory systems. > > I usually run three ttys myself (imp + root + spare), but it is a > matter of taste. Each time someone adds more of these goof things > turned on it turns into mergemaster hell for me (since I gotta do the > merge on about 25 machines). OK, I can take a hint! :-) I'll leave ttys alone. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ttys patch - any objections?
> This seems a lot like personal preferance to me, I for one don't like a > lot of tty's, because running getty on a bunch of ttys that I'm not going > to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run > kdm. I know I don't really have a say, but I'm sure everyone has his or > her own preference. Sure! That is why I'm doing a straw poll. If more people seem to like this, I'll commit it. If I get shouted down, I'll keep it as a local hack. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ttys patch - any objections?
> Are old-style non-F11, F12 keyboards still working with=20 > FreeBSD? I don't know, but as those are in the vast minority, its perhaps OK to ask those folks to edit ttys to something more useful to them, rather than the other way round. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ttys patch - any objections?
Hi
The attached patch gets done by me any time I set up a FreeBSD
box (I like lots of VTYs and X on ALT-F12).
Any objections to my committing this?
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
Index: etc.alpha/ttys
===
RCS file: /home/ncvs/src/etc/etc.alpha/ttys,v
retrieving revision 1.10
diff -u -d -r1.10 ttys
--- etc.alpha/ttys 17 Apr 2002 10:42:39 - 1.10
+++ etc.alpha/ttys 10 Aug 2002 08:26:39 -
@@ -41,7 +41,10 @@
ttyv5 "/usr/libexec/getty Pc" cons25 on secure
ttyv6 "/usr/libexec/getty Pc" cons25 on secure
ttyv7 "/usr/libexec/getty Pc" cons25 on secure
-ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
+ttyv8 "/usr/libexec/getty Pc" cons25 on secure
+ttyv9 "/usr/libexec/getty Pc" cons25 on secure
+ttyva "/usr/libexec/getty Pc" cons25 on secure
+ttyvb "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
# Serial terminals
# serial console for AlphaServer 8200 and 8400 ("TurboLaser")
#zs0 "/usr/libexec/getty std.9600" vt100 on secure
Index: etc.i386/ttys
===
RCS file: /home/ncvs/src/etc/etc.i386/ttys,v
retrieving revision 1.9
diff -u -d -r1.9 ttys
--- etc.i386/ttys 17 Apr 2002 10:42:41 - 1.9
+++ etc.i386/ttys 10 Aug 2002 08:27:04 -
@@ -41,7 +41,10 @@
ttyv5 "/usr/libexec/getty Pc" cons25 on secure
ttyv6 "/usr/libexec/getty Pc" cons25 on secure
ttyv7 "/usr/libexec/getty Pc" cons25 on secure
-ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
+ttyv8 "/usr/libexec/getty Pc" cons25 on secure
+ttyv9 "/usr/libexec/getty Pc" cons25 on secure
+ttyva "/usr/libexec/getty Pc" cons25 on secure
+ttyvb "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyd0 "/usr/libexec/getty std.9600" dialup off secure
Index: etc.ia64/ttys
===
RCS file: /home/ncvs/src/etc/etc.ia64/ttys,v
retrieving revision 1.2
diff -u -d -r1.2 ttys
--- etc.ia64/ttys 17 Apr 2002 10:42:41 - 1.2
+++ etc.ia64/ttys 10 Aug 2002 08:27:29 -
@@ -41,7 +41,10 @@
ttyv5 "/usr/libexec/getty Pc" cons25 on secure
ttyv6 "/usr/libexec/getty Pc" cons25 on secure
ttyv7 "/usr/libexec/getty Pc" cons25 on secure
-ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
+ttyv8 "/usr/libexec/getty Pc" cons25 on secure
+ttyv9 "/usr/libexec/getty Pc" cons25 on secure
+ttyva "/usr/libexec/getty Pc" cons25 on secure
+ttyvb "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyd0 "/usr/libexec/getty std.9600" vt100 on secure
Index: etc.sparc64/ttys
===
RCS file: /home/ncvs/src/etc/etc.sparc64/ttys,v
retrieving revision 1.3
diff -u -d -r1.3 ttys
--- etc.sparc64/ttys4 Aug 2002 19:16:13 - 1.3
+++ etc.sparc64/ttys10 Aug 2002 08:28:00 -
@@ -43,7 +43,10 @@
#ttyv5 "/usr/libexec/getty Pc" cons25 on secure
#ttyv6 "/usr/libexec/getty Pc" cons25 on secure
#ttyv7 "/usr/libexec/getty Pc" cons25 on secure
-#ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
+#ttyv8 "/usr/libexec/getty Pc" cons25 on secure
+#ttyv9 "/usr/libexec/getty Pc" cons25 on secure
+#ttyva "/usr/libexec/getty Pc" cons25 on secure
+#ttyvb "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttya "/usr/libexec/getty local.9600" dialup off secure
Re: cvs commit: src/sys/pci if_dc.c
> Can you try this PR patch and see if it helps ? Note that the patch isn't > 100% correct for other cards and will break them. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/35482 That patch (plus a couple of others from other PRs) is already applied. No help. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci if_dc.c
> I've got somewhere another dc card which made problems. I guess > it was PNIC. I have a Netgear FA510 (32-bit CardBus). When I insert it, I get: cardbus0: Expecting link target, got 0x0 cardbus0: Resource not specified in CIS: id=10, size=80 cardbus0: Resource not specified in CIS: id=14, size=400 dc0: port 0x1000-0x107f mem 0x88002400-0x880027ff irq 11 at device 0.0 on cardbus0 dc0: Ethernet address: 00:80:00:80:00:80 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Notice the funny MAC address. Any ideas? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Uncommitted dc0 fixes ...
OK, I've grabbed these... M > > Ups, forgot to add here the PR number ... > > > 3) ADMtek AN98x, enable automatically TX underrun recovery > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34236 > > > Patch No3 fixes some part of link problem on EN2242 cards. > > I've tested this patch and it makes by laptop working again with > > cvsup. > > Martin > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 release schedule?
On Thu, Aug 29, 2002 at 01:41:41PM -0700, David O'Brien wrote: > A 5.0 DP2 branch was created just yesterday. So how ever good > yesterday's -current was will affect DP2. I rather expected the release > engineers to at least querry the lists to ask what the known issues are > before picking which code to base DP2 on. We plan to keep the DP2 branch in Perforce in sync with -CURRENT for a while until things stabilize a bit more. That wasn't a branch point per se, just the initial integrate to populate the branch so we can begin tweaking the documentation and such. DP2 will certainly not be based on yesterday's -CURRENT, it was too problematic and doesn't contain the new GCC bits. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 release schedule?
On Wed, Aug 28, 2002 at 09:08:32AM -0400, Rod Smith wrote: > According to the timetable at > http://www.freebsd.org/releases/5.0R/schedule.html, DP2 for FreeBSD 5.0 I've updated that timetable to remove the specific date (it may take up to 24 hours for the website to be updated). We're actively working on it and I expect a stable DP2 release in the month of September. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM panic
> What kind of value do you use for N? It looks like lately the makefiles > are too aggressive when using -j, so you end up with N * N * 2 processes > running simultaneously. On my -current box with 128M RAM, I used -j13 > for a long time, but that runs out of swap nowadays, so I'm using -j4 > which does work. My machine is a PentiumMMX/200 x 2 SMP. I'm slowly working down from -j13, and I'm now at -j5 with the same panic. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libwrap bug?
> Such K&R way to declare functions sounds like an open invitation for > bugs. Agreed. > > I've been considering adding ANSI prototypes to tcpd.h, so we > > get more useful warnings from it. I have a local ISOfication (and lint cleanup) of tcp_wrappers that I've been meaning to contribute back to the author. Wanna play? :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VM panic
Hi all If I do a "make -jN world" build on my dual MMX/200 box, I usually end up in tears (well, a panic anyway). This is completely reproducible, and the panic always happens in swapout_procs while vmdaemon is running. Anyone else getting this? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Comments on Release Building for -current
On Wed, Jul 31, 2002 at 08:33:38AM -0400, W Gerald Hicks wrote: > Yup, it's been reported several times by various people and it seems > everyone > who can help is too busy to care. > > "This isn't fun anymore". :-( Uhm, did I miss something? Where does this attitude come from? Did you submit some patches for these problems that were ignored or something? Can we try to be a little more constructive here about solving problems? - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
The great perl script rewite - progress report
/usr/sbin/sysinstall* - fix - * /usr/bin/afmtodit Kyle Martin <[EMAIL PROTECTED]> - redo - * /usr/bin/mmroff Lester A Mesa <[EMAIL PROTECTED]> - redo - * /usr/sbin/adduser Mike Makonnen <[EMAIL PROTECTED]> - redo - * /usr/sbin/rmuserMike Makonnen <[EMAIL PROTECTED]> - redo - * /etc/periodic/* keramida - fix - ready? /usr/bin/catman John Rochester <[EMAIL PROTECTED]> - redo - done /usr/bin/makewhatis John Rochester <[EMAIL PROTECTED]> - redo - done /usr/bin/sockstat des - redo - done /usr/bin/whereisjohan - replace - done /usr/libexec/locate.mklocatedb Bob Willcox <[EMAIL PROTECTED]> - fix - done /usr/sbin/kbdmapJonathan Belson <[EMAIL PROTECTED]> - redo - done /usr/sbin/mergemaster dougb - fix - done /usr/sbin/pkg_updatepaul - del - done /usr/sbin/pkg_version reg - redo - done /usr/sbin/scriptdumpume - del - done /usr/sbin/spkrtest Riccardo Torrini <[EMAIL PROTECTED]> - redo - done /usr/sbin/vidfont Jonathan Belson <[EMAIL PROTECTED]> - redo - done release/scripts/*.plru - redo - done sys/*/conf/gethints.pl Cyrille Lefevre <[EMAIL PROTECTED]> - redo - done Key - "redo" == to be rewritten "replace" == toe be replaced with suitable 'outside' code "fix" == to have perl usage removed/redone "del" == to be deleted "feedback" == in progress, waiting for more/updates "ready" == work done, just waiting for commit. "done" == completed -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0 DP2 (was Re: KSE M-III status & junior hacker project.)
On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote: > Well with various hints from here and there I have fixed > the ^Z/fg problem (at least it seems fixed to me and others that > have tested) This basically leaves only one outstanding > problem that I know of which is a problem that Warner has with a > particular progam. (This may also be fixed but I don't know) Hi Julian, Thanks for your progress on KSE! How long should we wait before branching in Perforce for 5.0 DP2? I would like to give at least 10 more days for this and other changes to settle before making the branch. If all goes well, I would like to release 5.0 DP2 at the end of this month. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
> I think we should add a target to make world that checks for the
> existence of an old base install of Perl and removes it if it exists.
I agree that we may need a tool to do this, but I don't agree that it
gets done automatically by "make world".
> As a general principle, if we do things like remove code during -current
> development then make world needs to cater for that change. The idea of
> make world is that what you get at the end of it is a pristine install
> of a snapshot of FreeBSD from the current branch.
I disagree. This is force-feeding the user base too much.
> The bootstrap target was originally added for this purpose, to deal with
> issues during releases i.e. to bootstrap from one version of current to
> another. It's got misunderstood along the way to mean bootstrapping
> tools needed early in the build process.
>
> I'd like to resurrect it's original meaning and add code to clean out
> old versions of Perl.
Lots of things get deleted from current as time goes by; headers,
libraries, applets, etc. It is the responsibility of the CURRENT
builder/user to remove them as she sees fit. Our resposibility as
developers goes no further than to help provide removal tools/techniques
(I use "find ${DIR} -type f -ctime +1 -delete -print"), and guidance.
Of course, there are counterprecedents (libtelnet is one), but these
are the exception, and are unlikely to trample all over a user's
carefully crafted installation.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
> Hiya
Yo!
> Here's the updated version of vidfont/kbdmap. The changes are:
>
> WARNS=6 clean
> 80 columns max
> Now uses 'mkstemp()' rather than 'mktemp()'
> Fixed a couple of dumb bugs
> Copyrights added
> Removed '{}' from single lines
> Default strings now in vidfont.h
Good!
I'll check out and commit RSN. :-)
Thanks a lot!
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
> Kinda buggy. :) Ya, ya, ya. :-) That was the concept model. The actual author can make it robust. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
> > o Please shorten any long line or comment to less than 80 columns > > This is quite tricky when using 8 character tabs. Is 4 character indent > okay for userland source? "Real" tabs are best. Look at style(9) for ways to break the long lines. It is ok to break very long lines like this; > > o Please do not use mktemp(); use mkstemp() instead. > > I used mktemp() to get a filename to redirect to, eg. > > /* Improvised example */ > char *cmd; > asprintf(cmd, "prog > %s", mktemp(blah)); > system(cmd); > free(cmd); BIG security hole. Someone can exploit a race to compromise this. > I couldn't see a simple way around this, any clues? How's this? int handle; template = "/tmp/mumble"; char *cmd; handle = mkstemp(template); // template is modified asprintf(cmd, "prog > %s", template); system(cmd); close(handle); // bye-bye file M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Even more progress with perl script rewrites!
/usr/sbin/sysinstall* - fix - * sys/*/conf/gethints.pl * - del?/fix? - * /usr/bin/afmtodit Kyle Martin <[EMAIL PROTECTED]> - redo - * /usr/bin/mmroff Lester A Mesa <[EMAIL PROTECTED]> - redo - * /usr/bin/whereissheldonh - redo - * /usr/sbin/adduser Mike Makonnen <[EMAIL PROTECTED]> - redo - * /usr/sbin/rmuserMike Makonnen <[EMAIL PROTECTED]> - redo - * /usr/sbin/kbdmapJonathan Belson <[EMAIL PROTECTED]> - redo - feedback /usr/sbin/vidfont Jonathan Belson <[EMAIL PROTECTED]> - redo - feedback /usr/bin/sockstat des - redo - ready etc/periodic/* keramida - fix - ready /usr/bin/catman John Rochester <[EMAIL PROTECTED]> - redo - done /usr/bin/makewhatis John Rochester <[EMAIL PROTECTED]> - redo - done /usr/libexec/locate.mklocatedb Bob Willcox <[EMAIL PROTECTED]> - fix - done /usr/sbin/mergemaster dougb - fix - done /usr/sbin/pkg_updatepaul - del - done /usr/sbin/pkg_version reg - redo - done /usr/sbin/scriptdumpume - del - done /usr/sbin/spkrtest Riccardo Torrini <[EMAIL PROTECTED]> - redo - done release/scripts/*.plru - redo - done Key - "redo" == to be rewritten "fix" == to have perl usage removed/redone "del" == to be deleted "feedback" == in progress, waiting for more/updates "ready" == work done, just waiting for commit. "done" == completed -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
> Mark Murray wrote:
> >>These seem to be the same program. I'll take this if there are no
> >>objections.
> >
> > You have it!
>
> Okay, here's my vidfont/kbdmap rewrite for review. Any feedback
> is welcome, the same goes for bug reports :-)
Cool, thank you very much!
Some comments:
o Please put a copyright on the top of this. By preference, please use
/usr/share/examples/etc/bsd-style-copyright.
o The code style is generally good, but please don't put braces around
single lines of code, ie use
for (;;)
stuff;
rather than
for (;;) {
stuff;
}
o Please put all the macro strings like default font and directories into
macros and #include those from (say) vidfont.h.
o Please shorten any long line or comment to less than 80 columns
o Please do not use mktemp(); use mkstemp() instead.
o Please make this WARNS=6 clean as far as is possible.
Thanks!
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: The great perl rewrite - progress report
> Mark Murray <[EMAIL PROTECTED]> writes: > > /usr/bin/sockstat des - redo - * > > Done, but depends on other changes that aren't ready to be committed > yet. I expect to commit the whole shebang this weekend or early next > week. Cool! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl usage from mergemaster
> Ok, I've imported stat(1) and modified mergemaster to use it instead. For > now, I have simply disabled use of the user's umask for mode setting so > that I could get the non-perl version in the tree asap. I will look at > Giorgos' excellent patch and steal bits from it so that I can add that > feature back. Cool! > Once again, sorry for the delay. No problemo. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The great perl rewrite - progress report
> On Thu, Jun 06, 2002 at 05:31:12PM +0100, Mark Murray wrote: > > /usr/sbin/sysinstall* - fix - * > > What part of this uses perl?? None. But it needs to install perl by default (or near default) at some point. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
The great perl rewrite - progress report
/usr/sbin/sysinstall* - fix - * /usr/bin/afmtodit Kyle Martin <[EMAIL PROTECTED]> - redo - * /usr/bin/mmroff Lester A Mesa <[EMAIL PROTECTED]> - redo - * /usr/bin/sockstat des - redo - * /usr/bin/whereissheldonh - redo - * /usr/sbin/adduser Mike Makonnen <[EMAIL PROTECTED]> - redo - * /usr/sbin/rmuserMike Makonnen <[EMAIL PROTECTED]> - redo - * /usr/sbin/kbdmapJonathan Belson <[EMAIL PROTECTED]> - redo - * /usr/sbin/vidfont Jonathan Belson <[EMAIL PROTECTED]> - redo - * /usr/sbin/mergemaster dougb(?) - fix - * /usr/sbin/pkg_version reg - redo - ready(?) /usr/bin/catman John Rochester <[EMAIL PROTECTED]> - redo - done /usr/bin/makewhatis John Rochester <[EMAIL PROTECTED]> - redo - done /usr/sbin/pkg_updatepaul - del - done /usr/sbin/scriptdumpume - del - done /usr/sbin/spkrtest Riccardo Torrini <[EMAIL PROTECTED]> - redo - done release/scripts/*.plru - redo - done etc/periodic/* keramida - fix - done Key - "redo" == to be rewritten "fix" == to have perl usage removed/redone "del" == to be deleted "ready" == work done, just waiting for commit. "done" == completed -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl script rewrite (/usr/bin/mmroff)
> is someone currently converting /usr/bin/mmroff from perl to C ? Nope. > If no one is working on it, i'm willing to do it. You have it! Thanks! :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
> > > #pragma weak foo = bar
> >
> > What's the correct way to do this now?
>
> I dont know. :-( There are hacks that can work around it, but I think this
> is unintentional breakage. I tried changing this:
> #pragma weak foo = bar
> to
> __weak_reference(bar, foo);
void f () __attribute__ ((weak, alias ("__f")));
(But that may come to the same thing).
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /etc/periodic is hopefully perl-free [was: Perl script rewrites]
> On 2002-05-19 12:20, Mark Murray wrote: > > What I've done so far (and only slightly tested) is available at > > http://www.FreeBSD.org/~keramida/diff/periodic.diff > > Untested, but seemingly complete, the patch is available for review at > the address mentioned above. I am thinking a nice way to test this > would be: This looks excellent! For my miniscule data set and manual test, things seem OK. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl script rewrites - progress (2)
> I'm in the middle of rewriting release/scripts/*.pl scripts. Excellent. Thank you! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with new eventhandler.h (fwd)
> I believe that the new eventhandler.h is depending on newer compiler > tools. This makes it somewhat difficult to bootstrap. Can you make it so it > *doesn't* require gcc3 installed? Damn. Upgrades. OK, I'll fix. > cam/cam_xpt.c > In file included from ../../../sys/conf.h:48, > from ../../../cam/cam_xpt.c:38: > ../../../sys/eventhandler.h:95: badly punctuated parameter list in `#define' > ../../../sys/eventhandler.h:137: badly punctuated parameter list in `#define' > *** Error code 1 Thanks! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Stuff to prune - ptx ?
Hi all In src/gnu/usr.bin/ptx is a very old (v0.3) version of GNU ptx (a permuted index generator). This is not used in a make world, and I believe that we should ditch it. Anybody have any problems witgh me doing this? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl script rewrites - progress (2)
> Hello Mark and all, > > I've started digging around /etc/periodic, and have already done part > of the work. You might as well, have this assigned to me, unless > someone proves faster than me and gets it done in less than a day or > two. > > What I've done so far (and only slightly tested) is available at > http://www.FreeBSD.org/~keramida/diff/periodic.diff You have it! Don't wait for me. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl script rewrites - progress (2)
> On 05/18/02 12:05, "Mark Murray" <[EMAIL PROTECTED]> wrote: > > > Hi all > > > > The perl script rewrite is going really well! > > > > Here is my progress file, as it currently stands: > > To add one to the list.. /usr/sbin/mergemaster has two calls to perl in it, > to extract file/directory permissions -- anyone (doug?) working on this? Thank you! Added and assigned to doug locally. Doug, I hope that is OK?? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Perl script rewrites - progress (2)
Hi all The perl script rewrite is going really well! Here is my progress file, as it currently stands: /usr/bin/afmtodit Kyle Martin <[EMAIL PROTECTED]> - re /usr/bin/catman John Rochester <[EMAIL PROTECTED]> - re - done /usr/bin/makewhatis John Rochester <[EMAIL PROTECTED]> - re - done /usr/bin/mmroff /usr/bin/sockstat des - re /usr/bin/whereissheldonh - re /usr/sbin/adduser Mike Makonnen <[EMAIL PROTECTED]> - re /usr/sbin/kbdmapJonathan Belson <[EMAIL PROTECTED]> - re /usr/sbin/pkg_updatepaul - del - done /usr/sbin/pkg_version Jeremy Lea <[EMAIL PROTECTED]> - re - ready? /usr/sbin/rmuserMike Makonnen <[EMAIL PROTECTED]> - re /usr/sbin/scriptdumpHajimu UMEMOTO <[EMAIL PROTECTED]> - del - done /usr/sbin/spkrtest Riccardo Torrini <[EMAIL PROTECTED]> - re - done /usr/sbin/vidfont Jonathan Belson <[EMAIL PROTECTED]> - re etc/periodic/* (needs to have perl usage removed) Key - "re" == to be rewritten "del" == to be deleted "ready" == work done, just waiting for commit. "done" == completed Thanks to contributors! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pkg_version in C [was: Re: Perl scripts that need rewriting - Progress!]
> OK, the first revision is attached. It appears to work for me... It > needs some spit and polish, and probably a few more people to test. > > I've not implemented the -d flag since it sort of became unneeded, and > it's not really the way things are done in the rest of pkg_*. I've also > not implemented -c. There were enough warnings that it wasn't really > useful, and portupgrade does a much better job... > > Regards, > -Jeremy No need to wait for me on this one. If folks are happy, this is good for me! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewriting - Progress!
> Hi, > > >>>>> On Thu, 09 May 2002 20:33:22 +0100 > >>>>> Mark Murray <[EMAIL PROTECTED]> said: > > mark> /usr/sbin/scriptdump > > This script is from KAME. It seems that NetBSD doesn't install it. > Is someone actually using it? If okay, I'll change to don't install > it. That sounds good to me! Go right ahead! :) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewriting - Progress!
> On Thursday 09 May 2002 02:33 pm, Mark Murray wrote: > > Hi > > > > The response to the perl-script rewriting project has been > > very hearteningly _fantastic_! > > > > Here is the list as it stands. The gaps are fairly obvious (and > > probably mostly not critical in the short term): > > > > /usr/bin/afmtodit > > ill take this rewrite You got it! :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Perl scripts that need rewriting - Progress!
Hi The response to the perl-script rewriting project has been very hearteningly _fantastic_! Here is the list as it stands. The gaps are fairly obvious (and probably mostly not critical in the short term): /usr/bin/afmtodit /usr/bin/catman John Rochester <[EMAIL PROTECTED]> - re /usr/bin/makewhatis John Rochester <[EMAIL PROTECTED]> - re /usr/bin/mmroff /usr/bin/sockstat des - re /usr/bin/whereissheldonh - re /usr/sbin/adduser Mike Makonnen <[EMAIL PROTECTED]> - re /usr/sbin/kbdmapJonathan Belson <[EMAIL PROTECTED]> - re /usr/sbin/pkg_updatepaul - del - done /usr/sbin/pkg_version Jeremy Lea <[EMAIL PROTECTED]> - re /usr/sbin/rmuserMike Makonnen <[EMAIL PROTECTED]> - re /usr/sbin/scriptdump /usr/sbin/spkrtest Riccardo Torrini <[EMAIL PROTECTED]> - re - ready /usr/sbin/vidfont Jonathan Belson <[EMAIL PROTECTED]> - re Key - "re" == to be rewritten "del" == to be deleted "ready" == work done, just waiting for commit. "done" == completed M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
> On 09-May-2002 (15:38:45/GMT) Mark Murray wrote: > > >> I tryed this one. I'm not a committer, just a volunteer :-) > > > You're on! Please put appropriate (c) on this (Preferably > > 2-clause BSD license) and I'll commit it for you :-) > > Ahemm, I'm not sure to have done correct job. Please review last > version of this script from my site: > ftp://castle.torrini.org/pub/FreeBSD/spkrtest-current > and modify if I miss or don't understand something ;) > Thanks. Looks fine to me! Thanks! Commit will come later... M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> >From the keyboard of M. Warner Losh: > > My take on this. We should remove perl from the base, and > > automatically install the port for most users in sysinstall, just like > > we do with XFree86. > > OK, fine and if then an option "FETCH_MAKE_AND_INSTALL_PERL_FROM_PORTS" > is added to make.conf and made working so that make buildworld/installworld > updates go transparenly without loosing perl (or any other component of the > current base system, which will for shure be removed taking the perl > removal as a precedent case) then i'm calmed down. This won't work - perl won't cross-build. M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> > and just add enough file to build miniperl. > > I've read all the messages in this thread, but I'm still unclear -- are we > talking about building the "miniperl" that Perl already creates during the > build process? If not, the minimal perl for building the FreeBSD kernel > should have a different name, like: > smallperl > modestperl > tightperl > midgetperl > petiteperl Sure, whatever. Smallperl it is. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> On Thursday, May 2, 2002, at 12:56 , Mark Murray wrote: > >> For me, nowadays 45MB is nothing compared to medium HDD capacity, and > >> even > >> my POCKET PC will easily accomodate it... > > > > 45 MB is fine as a port - we have ports that are way bigger than that. > > And we even have bigger ports that does take longer to build than 'make > buildworld' the whole FreeBSD (which takes less than 30 minutes on > Athron XP 1400 -- the fastest box I have at my fingertip). > > > As part of the base OS? Nope. The only functionality that we _need_ > > is the basic language - effectively miniperl. > > But to sensibly strip down the distribution to just as much as needed > does take a lot of something the most precious -- intellectual power. Nope - it is trivial. We already make miniperl. We just need to install it and not install the rest of perl. 10 mins to do the work, and on-and-off fiddling to make the world build complete. M > That I consider a waste. I don't think anyone objects that there are > several hundred, or even thousand, files under /usr/src so long as it > builds and so long as it nicely fits -- say, in a CD-ROM. FreeBSD > 4.5-stable as of now is just 364,149 kBytes UNCOMPRESSED. Why don't you > just untargz what Perl 5 porter has to offer and forget about what files > should go and stay? You can easily install only needed parts. Bloat. Its easy to "rm -rf " where != unix, and other simple rules. > Speaking of which, the whole build process does not use objective-C > (correct me if I am wrong). So if you insist on stripping Perl it may > as well be unfair to leave GCC unstripped (I pretty much doubt GPL > allows you to do so, however). We strip GCC. We strip most things that we install in src/contrib. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> > I'm not sure that is acceptable. I believe that perl 5.8.0 will be > > +- 45 MB. I cannot afford to import all of that - I'd get lynched. > > that is price, for example, for Unicode. > Okay, when many platforms will be doing stripping their tools, everyone > should remember where his perl programs are able to run and where they are > not and require additional dowloading. (I remember how I was disappointed > that Redhat linux distribution did not contained Tk in its distribution, > even for optional installation. It was a pain to rebuild) > > For me, nowadays 45MB is nothing compared to medium HDD capacity, and even > my POCKET PC will easily accomodate it... 45 MB is fine as a port - we have ports that are way bigger than that. As part of the base OS? Nope. The only functionality that we _need_ is the basic language - effectively miniperl. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> NetBSD (-current, at least) does not have perl in the base. OpenBSD > has 5.6.. *NOD* > Perhaps FreeBSD could benefit from following NetBSD, and use awk or > whatever to replace the perl stuff for kernel build and wherever else. We've already sorted that out for the kernel build. I'm going to see how well miniperl works for the userland perl scripts. > People who actually want perl could then install a miniperl package > and as many modules as they need or like, up to and including the very > latest full-bloat^H^Hwn version, if desired. I reckon we'll keep miniperl for a while. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> > Perl stuff like perldoc, pod2man we would like to be able to build > > with sed/awk scripts if necessary. > > All the perl developers that I know like writing perl. I wonder why that is? ;-) > Given the choice of writing something in sed sed/awk versus writing something > in perl, which do you think they'd prefer? :-) No brainer! :-) > In fact, I don't know any awk, and I hardly know any sed. > Then again, I seem to spend more of my time writing perl in C than in perl. > > I don't understand the *BSD build paradigm, so I've no idea if I'm making > rash assumptions here, but perl's building paradigm (as I understand it) is > to build a minimal perl (miniperl) and then write the later stages of the > build in perl. BSD's build paradigm is to do it all in makefiles, using make's dependancy rules. > Having done a port to a non Unix system without a shell, it irritates > me that there *are* shell scripts used at all after miniperl is > built. For portability reasons it would be nicer if everything after > miniperl was written in 100% perl, as it's usually possible to > bootstrap a good-enough miniperl from a hand-edited config.h file. But > this is a digression. Hand crafted config.h files are a pain if you need to do some configs (word size, endianness, build vs. run architecture, etc). If you use system headers for this, then you are laughing. If building scripts (say, perldoc) is as simple as running a script through (only) miniperl, that would be OK - miniperl could be a part of the OS build toolchain. I had something in mind like %%FOO%% strings that would be simple to sed(1) into their real values at build time. I am under no illusions that doing this is major work for you guys. > Would I be right in guessing that the pain to *BSD in the perl build system > is that even if there is an existing /usr/bin/perl, we perl porters insist > on writing all our perl building scripts using perl features only found in > the perl we're bootstrapping. Hence it's not possible to use the probably > older /usr/bin/perl to finish making perl, and so *BSD has to use the > uninstalled new perl in /usr/obj. Which causes problems bootstrapping new > binary formats (eg existing kernel only runs a.out binaries, new kernel runs > a.out and ELF, new userspace is being built as ELF, but how does one run the > uninstalled ELF perl during make world?) At least, this was the stage where > I had fun when upgrading my FreeBSD box from 4.0 to 4.5. That is a big part of it. Another big part of the the problem is that build time requirements become run-time defaults, like where you put stuff for the build vs. where stuff is eventually put stuff at install time. This is particularly bad when trying to cross build, as perl decides at build time what CPU it is going to _run_ on, and fouls up :-). We've mostly fixed that, but it is very fragile, and I'm dreading the next perl upgrade. *BSD can fix most of this using the right headers (eg: sys/endian.h) and the right integer types (u_int32_t, int64_t, etc). We've dethreaded lots of the build, and we build libperl.(so|a) mostly with straight makefiles. We can build perl, suidperl and miniperl with just a little bit of scripting magic (mostly for Dynaloader), but the dependancy list is very big (MakeMaker etc). > (This may sound corny or obsequious, but people rarely seem to say thank you, > and assume it's taken for granted. My FreeBSD box works very well. Thank you > for FreeBSD. Please keep up the good work.) Thank you for Perl! We gripe about its build, but it is a very useful tool. Thank _you_! And a very hearty "Thank You" for this opportunity to discuss this thorny issue with you! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> I think Perl should be broken into two pieces: a "miniperl" distribution > that is called "Perl" and a separate "Standard Perl Module Library" > distribution. They would be versioned separately so what's considered part > of the core Perl language isn't confused with what version of CGI.pm or > other random module is included with a Perl distribution. It's clear that > the modules evolve much faster than Perl's release cycle, so the Perl > Library distribution could simply be on its release cycle. I would be _delighted_ with this arrangement! *BSD could use the "Perl" dist, and libraries would be excellent ports-fodder. > NetBSD (I) used to separate out Perl into a separate "miniperl" package + > extensions, but I gave up on doing this because it was just getting to be > a maintainence headache -- with every Perl release, I had to wade through > a different module list to see what should be removed and what should stay > and I just got fed up with the extra work. This is a lose for some of our > platforms that just don't have a lot of disk space to spare, e.g. > NetBSD/hpcmips. With a Perl + Perl Library setup, we could more easily > control via a package system which modules are installed in a simpler, > more additive way. A headache that would need to be addressed (IMO) is the one where Perl makes too many decisions about runtime at compile time. This makes things like cross building a real PITN. If the above "Perl" was really minimalist, that would be good. If it was basically some .c/.h (and .l/.y) files making the core language + Dynaloader, with no need to execute _any_ perl during the build, that would fit into the *BSD build paradigm very well indeed, and that would probably support the "Standard Perl Module Library" subsystem very well indeed, with no circular dependancies. A _big_ headache is the config.sh script that is sometimes read by a perl script, thus breaking any chance of putting shell variables and expressions in there and having them expand properly. Perl stuff like perldoc, pod2man we would like to be able to build with sed/awk scripts if necessary. I fully recognise as a programmer that this is not trivial work :-). M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> > Can we not come to a compromise here? > > One possible solution might be as follow; > > rename /usr/src/contrib/perl5 to /usr/src/contrib/miniperl5 Yes - in discussion the idea has already been brought up that all we need of perl is miniperl. I'm going to experiment with world builds that do this, and discuss it on our lists. For what its worth, we have exactly the same problem with GCC - it has 5 compilers in it already, and this is climbing. Our toolchain maintainers are tearing their hair out over bloat and other issues here. > Yes, I want p5-* cleaned up as well. I just 'grep ^p5- > /usr/ports/INDEX' and found 660! That's way too many (or, at least two > of which I have developed :). Maybe we should BSDPANize all these. I suspect that BSDPAN is used to some extent with all of these. > I think if whole perl5 is distributed via ports only it wouldn've raised > this much rants. FreeBSD does need perl in core but not the whole thing > and that is the problem. 100% agreement. I have even had a couple of folks asking for Perl 4 back! (No ways will I do that!) > But rule of the thumb is NOT TO REMOVE THE SOURCE. /usr/src MAY BLOAT > because it doesn't get installed by default (there are already bloated > charmingly; 34853 files under /usr/src on FreeBSD 4.5-stable). If you > need size control do so via install process. I would love to help in > this area. I think just a little tweak to hints file and you should be > able to build a minimum perl just by passing right Configure directive. I'm not sure that is acceptable. I believe that perl 5.8.0 will be +- 45 MB. I cannot afford to import all of that - I'd get lynched. > > You realise that you are asking for FreeBSD to bloat itself to > > unusable levels by setting this precedent? How many _other_ > > modules are coming in? How big is Perl going to get? How much > > longer is it going to take to build? What other software authors > > will thus have valid reasons for having _their_ software as part > > of the base system instead of as a port? > > I don't mean to include those that don't come with perl-x.x.x.tar.gz. > CGI.pm doesn't look like a necessity and it may even be true. But the > perl community voted to include it to perl standard distribution. If that becomes a license requirement, then FreeBSD may need to rethink the need for perl in the base system. WY too much bloat for too little gain. > Besides, this 'pick, grok and trash or keep' process should be too > time-consuming. perl-current is already > 3000 files big and it is > already beyond a power of individual to look through every one of them. > You need a better approach than handpick CGI.pm and others. Sure - but it is easy to blow away directories. > >> P.S. I would rather choose the NetBSD way of detaching Perl from core > >> distribution altogether. That is far more politically correct. > > > > There is merit to this point - make Perl5 a "super-port" (or > > something), that is closer to the OS than a usual port but not part > > of the base OS. I have no objection to this. > > Maybe python and ruby should go for that approach as well and I see > that's the way to go -- for ports. We still need perl to build FreeBSD > and we got to come up with a correct soultion -- not only politically > but also technically. Your current soultion is, to say the least yet > with all due respect, incorrect in both criteria. We are working on removing the need for perl in building the kernel. After that, it is just a case of rewiriting the userland utils that need it (perhaps with miniperl). > Dan the Proud Member of Both Communities :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> (I promise that this is my last message about this matter to this large a > recipient list. Who is the maintainer of the Perl package in FreeBSD? > Anton Berezin, I think? [EMAIL PROTECTED] CCed.) Me - [EMAIL PROTECTED] > Though I disagree with the tone of Dan Kogai, I must agree on the > technical grounds that leaving away standard modules and still calling > it "Perl" is not quite right. > > I think both from the viewpoints of the Perl distribution *and* an OS > distribution *IF* modules have to be left out for space-saving reasons > the fair thing to do would be to make it clear to the users of the OS > distribution that what they are getting is not the full Perl. This > will cut down the number of misunderstandings on both sides. Fair enough. > Firstly, both the outputs of perl -v and perl -V should be amended. > For example: > > $ perl -v > > This is perl, v5.6.1 built for i686-freebsd ... etc. I could do this. > Secondly, as the above message indicates, there should be a full Perl > installation available, using whatever packaging method is used by the > OS distribution. FreeBSD has the ports collection that has a full install of Perl 5.6.1. M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> Mark, and FreeBSD committers, > >I am deeply disappointed by the recent move to drop some of the files > (CGI.pm, et al.) in perl distribution /usr/src/contrib/perl5. By saving > a few hundred kilobytes, you are risking losing a few hundred perl > hackers that run FreeBSD thereon. OK... > I hate to tell you this but I believe FreeBSD has already paid the price > for disregarding the community. Are you--we (because I am part of the > FreeBSD community, at least for the time being) going to repeat the same > mistake? Well, look at it this way. Perl is very hard to build already, and it is very big, and you say it is getting bigger. All "base" freebsd needs is the core language. The rest bloats the source tree, slows down builds of the whole operating system and provides copious opportunities for cross-builds and upgrades to fail. Can we not come to a compromise here? > Rafael Garcia-Suarez also wrote: > > Wait, vendors will soon have to struggle with the Borgified 5.8.0 > > release... > > Now please allow me to get a little personal. I happened to maintain > Encode, the largest module in Perl 5.8.0 by far. If you are to > castrate, this will definitely the first one to be. The sad fact is > that I develop this very module on FreeBSD! And it sounds like a perfect candidate for a FreeBSD "port". The bash(1) developer develops on FreeBSD (IIRC). That is a port. I have no idea how many other of our 6000+ ports are developed on FreeBSD, we dont have those in the base system unless they are needed for the core operating system (such needs are things like, say, OpenSSH, Kerberos5/Heimdal, Bind, Less, etc in src/contrib/). > Since Encode is a part of Perl 5.8.0, I can't choose to license it so > that you can't castrate. But that will disappoint me so much that I may > join those who kissed FreeBSD good-bye like many others who have chosen > to do so for the lack of regards. You realise that you are asking for FreeBSD to bloat itself to unusable levels by setting this precedent? How many _other_ modules are coming in? How big is Perl going to get? How much longer is it going to take to build? What other software authors will thus have valid reasons for having _their_ software as part of the base system instead of as a port? > P.S. I would rather choose the NetBSD way of detaching Perl from core > distribution altogether. That is far more politically correct. There is merit to this point - make Perl5 a "super-port" (or something), that is closer to the OS than a usual port but not part of the base OS. I have no objection to this. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with rl
On Sat, Apr 13, 2002 at 10:51:16AM +0200, John Angelmo wrote: > The errormessage I get is: > > rl0: Irq 5 at device 2.0 pci 1 > Couldn't map ports/memory > device_probe_and_attatch( rl0 attatch retuned 6) Is "PNP OS installed" selected in your BIOS? If so, try without this option set. - Murray msg37226/pgp0.pgp Description: PGP signature
Re: DP 1 install report
On Thu, Apr 11, 2002 at 12:26:41AM -0700, Doug Barton wrote: > So far, the only other oddity I've noticed is that when I added > the src distribution, all of the files were set 444. The directories have > 755 permissions. Ahh. The problem here is related to the hoop we had to jump through to get "make release" to get the code for the source distribution out of Perforce instead of out of CVS (the default). Thanks for noticing this. I hope we're able to use a branch in CVS for the next DP, but if we have to use Perforce again I will fix the permissions. > While I'm doing a review, I should add that one of the menus in > sysinstall really bugs me... "Do you have a non-USB mouse connected to the > system?" which defaults to No. Something is wrong with that picture. :) Yes, I agree that the wording is bad. - Murray msg37155/pgp0.pgp Description: PGP signature
Re: comparing executables
> > >How can I find out which binaries have changed? > >they are all different according to cksum so I assume > >that there is a timestamp or something in them. > >Is there a way to compare only the text segments? > > You can do wonders with objdump(1) and diff. and ident(1). M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl build uses 'cc' and maybe 'gcc' directly.
> Any chance of getting the Perl build to properly use ${CC} rather than
> hard coding 'cc'? Also a "find . -type f | xargs grep gcc" shows that
> GCC may be called directly also.
OK - I'll look at that.
> This is a problem for cross builds, and using alternate versions of of
> the compiler (say gcc31 for testing).
Gotcha.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: USB mouse problem
On Sat, Mar 30, 2002 at 03:24:08PM +0200, Andrew Bliznak wrote: > On Sat, 30 Mar 2002, Masahide -mac- NODA wrote: > > Same here, solid lock, debug key not work. If I setup X to use /dev/ums0 > computer hang just after startx. All worked with kernel/world from Mar 12. "Me too". In my case I use an OmniView USB KVM switch. When I switch to my MacOS X box (which causes the keyboard and mouse to be disconnected from the FreeBSD machine), FreeBSD locks solid. This was working fine in -CURRENT just 2 weeks ago, and it works fine in -STABLE as of today. One of the recent NetBSD merges must be causing this. Any thoughts, Joe? - Murray msg36884/pgp0.pgp Description: PGP signature
Re: pam_opieaccess breaks world
> Is there an #include missing in pam_opieaccess.c? Yes. Added now. Thanks! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building 5.0 on 4.5 Broken in xlint?
> I have fixed this and these by making lint(1) a cross-tool. Excellent! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld messing up?
> > In ports/lang/gcl, a program is "undumped", and the resultant binary > > dumps core _very_ early in the startup. I can't get debugging info, > > because the undumping also seems to strip the program. > > I've also have had that same problem when I tried to build the port, > but was never able to find the reason for the program to segfault, I > even opened a PR on that. The program seems to work on NetBSD btw.=20 PR ports/34661 :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld messing up?
> > Technically, the ELF spec permits the ordering, so the assumptions > > are really "broken", even though they code for what's really a > > defacto-standard of many years, now. 8-(. > > Can you be more specific? To the best of my knowledge, I made no > assumptions beyond what the spec promised. The only exception is that > the dynamic linker relies on the program header being in the first > page of the file, an assumption shared by the kernel as well. I don't > think that assumption is wrong, or nothing would run at all. I'm going to sound like a prat here, mostly because I don't know what I'm talking about. :-) In ports/lang/gcl, a program is "undumped", and the resultant binary dumps core _very_ early in the startup. I can't get debugging info, because the undumping also seems to strip the program. Could you please try that port, and see what you can glean? I'm frobbing around in xemacs, which works, to see if I can't fix undump. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please backout recent ipfilter changes.
> > Better; please post the errors that you are seeing so that this can > > be fixed. > > > > I already posted a fix for ipfstat. ipmon and ipnat are > broken. What would appear to be the obvious fix for ipnat > doesn't work. It is clear that Darren did not try to build > ipfilter after his changes. Post the _errors_. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please backout recent ipfilter changes.
> The recent changes to ipfilter break world. Can > someone back out the changes? Better; please post the errors that you are seeing so that this can be fixed. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad fix for -current breakage
> > Now, to the next breakage in the tree :-)
> >
> Here's a "good" one:
YES!! Excellent! Please commit this.
M
> %%%
> Index: Makefile.inc
> ===
> RCS file: /home/ncvs/src/gnu/usr.bin/perl/Makefile.inc,v
> retrieving revision 1.29
> diff -u -r1.29 Makefile.inc
> --- Makefile.inc 16 Mar 2002 21:36:07 - 1.29
> +++ Makefile.inc 18 Mar 2002 09:19:07 -
> @@ -60,8 +60,14 @@
> @ln -sf ${PERL5SRC}/writemain.SH writemain.sh
> @ln -sf ${PERL5SRC}/regcomp.c regcomp.c
> @ln -sf ${PERL5SRC}/regexec.c regexec.c
> +.if defined(BOOTSTRAPPING)
> + @sed '/^d_eaccess=/s;define;undef;' \
> + ${PERL5LIBSRC}/config.SH-${OBJFORMAT}.${MACHINE_ARCH} \
> + > config.sh
> +.else
> @ln -sf ${PERL5LIBSRC}/config.SH-${OBJFORMAT}.${MACHINE_ARCH} \
> config.sh
> +.endif
> @touch ${.TARGET}
>
> scripts: links
> %%%
>
>
> Cheers,
> --
> Ruslan ErmilovSysadmin and DBA,
> [EMAIL PROTECTED] Sunbay Software AG,
> [EMAIL PROTECTED]FreeBSD committer,
> +380.652.512.251 Simferopol, Ukraine
>
> http://www.FreeBSD.orgThe Power To Serve
> http://www.oracle.com Enabling The Information Age
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World on -stable is busted
Hi I put up a patch to test this yesterday. Go to src/gnu/usr.bin/libperl, and in appropriate config*, find the "d_eaccess=" line, and change it to 'undef'. Please let me know if that works. M > cc -O -pipe -I/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl >-I/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5 >-DPERL_EXTERNAL_GLOB -DPERL_CORE -DAPPLLIB_EXP=\"/usr/libdata/perl/BSDPAN\" >-L/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl/../libperl -static -o >miniperl miniperlmain.o perl.o gv.o toke.o perly.o op.o regcomp.o dump.o util.o mg.o >hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o >utf8.o taint.o universal.o xsutils.o globals.o perlio.o -lm -lcrypt -lutil > pp_sys.o: In function `Perl_pp_fteread': > pp_sys.o(.text+0x5f57): undefined reference to `eaccess' > pp_sys.o: In function `Perl_pp_ftewrite': > pp_sys.o(.text+0x6023): undefined reference to `eaccess' > pp_sys.o: In function `Perl_pp_fteexec': > pp_sys.o(.text+0x60ef): undefined reference to `eaccess' > *** Error code 1 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-C KERNEL (Was: Re: problems with perl)
> cc1: warnings being treated as errors # make NO_WERROR=yes ... M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, Mar 17, 2002 at 02:13:16AM -0800, Annelise Anderson wrote: > > The source will be on the CDROM. Nor is there any major importance to > > DP1. Are you also upset that you cannot reproduce the July 17th, 1998 > > -CURRENT snapshot CD from WC? > > > If a tag was laid down can't it be retrieved indefinitely? A non-branching > tag? What am I missing? Tags were never laid down in the past. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with perl
> The perl upgrade seems to be having problems. I got this twice > towday making buildworld from 4.5: Please test the enclosed patch. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn Index: config.SH-elf.alpha === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.alpha,v retrieving revision 1.24 diff -u -d -r1.24 config.SH-elf.alpha --- config.SH-elf.alpha 16 Mar 2002 21:36:07 - 1.24 +++ config.SH-elf.alpha 17 Mar 2002 09:38:49 - @@ -138,7 +138,7 @@ d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define' Index: config.SH-elf.i386 === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.i386,v retrieving revision 1.22 diff -u -d -r1.22 config.SH-elf.i386 --- config.SH-elf.i386 16 Mar 2002 21:36:07 - 1.22 +++ config.SH-elf.i386 17 Mar 2002 09:38:55 - @@ -138,7 +138,7 @@ d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define' Index: config.SH-elf.ia64 === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.ia64,v retrieving revision 1.5 diff -u -d -r1.5 config.SH-elf.ia64 --- config.SH-elf.ia64 16 Mar 2002 21:36:07 - 1.5 +++ config.SH-elf.ia64 17 Mar 2002 09:39:01 - @@ -138,7 +138,7 @@ d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define' Index: config.SH-elf.sparc64 === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.sparc64,v retrieving revision 1.6 diff -u -d -r1.6 config.SH-elf.sparc64 --- config.SH-elf.sparc64 16 Mar 2002 21:36:07 - 1.6 +++ config.SH-elf.sparc64 17 Mar 2002 09:39:07 - @@ -138,7 +138,7 @@ d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define'
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote: > Minimally, pick a date, and then do a CVS diff against that > date, and include it on the CDROM. I would be happy to do this. I checked out a copy of the CVS tree right before we made the Perforce branch so that we could tag it later if absolutely necessary. > Max wants the commit messages to the developers pre-release > to go to an archived mailing list for similar reasons, it > seems to me. I have emailed Peter about this. I don't think the messages should go to cvs-all, because I don't think most people want to see them. But I do think that they should be available for people like Max. Max was CCed on my message to Peter. > Now say you have become involved in the process, because the > pre-release has done it's job. You want to fix the bug. > > In order to do this, you are going to need the delta against > the developer's prerelease source tree. To get this, the > process is: 1) Mount your DP1 CD, and view the diff. - Murray msg36241/pgp0.pgp Description: PGP signature
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote: > I think it's an incredibly bad idea that we are not going > to be able to reproduce what went onto any given CDROM in > ten years. I agree that it is very important to be able to reproduce official releases of FreeBSD N years down the road. However, that has never been a requirement of snapshot CDs. We have never even tagged the tree for previous snapshots. We are actually moving more in the direction you advocate by at least moving the snapshot production into Perforce so that more developers can participate. The release engineers would prefer to do this in CVS, but that is not advisable for the reasons Peter outlined in his mail. The source distribution is included in the output of "make release" for a reason. If you have a technical solution to the problems that Peter raised, then I'm sure [EMAIL PROTECTED] would like to hear about them. - Murray msg36234/pgp0.pgp Description: PGP signature
HEADS UP! Perl upgraded to 5.6.1
Hello all The system perl has been upgraded to Perl 5.6.1. This means that it is a _very_ good idea to rebuild all your p5-* ports. As usual, if there are any problems, I want to know about them. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf #text/plain; name=cv.txt [Mark Murray CV Plain Text] cv.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: -CURRENT Feature Slush is OVER
Thanks for your cooperation in keeping -CURRENT relatively stable over the past week. Due to a request from the CVS administrators, we are performing the code branch in the Perforce depot under //depot/releng/5_dp1/. Commits to this Perforce branch require re@ approval. This is not going to be a supported branch. It is solely a work area for the release engineers to tweak the release documentation, back out recent problematic changes, merge in a conservative set of new changes, and otherwise perform quality assurance work. Our two primary goals in all of this are (1) to provide a usable preview of the 5.0-CURRENT code, and (2) to minimize the impact on -CURRENT developers. After evaluating several different options, using Perforce was deemed the best tool for the job. Thanks, The FreeBSD Release Engineering Team msg36190/pgp0.pgp Description: PGP signature
Call for Submissions: FreeBSD 5.0 DP1 Testing Guide
As part of the release documentation for 5.0 DP1, we would like to provide a comprehensive testing guide. If you have code in -CURRENT that you would like to receive feedback on from the developer preview, then please submit a short email to [EMAIL PROTECTED] with the following: 1. A brief description of the new functionality to be tested. 2. A list of known issues / bugs. 3. Instructions for users who wish to help test the feature. If required, we can add test programs or additional patches to a separate directory of the ISO image and FTP install directory. This is somewhat analogous to the 4.5 Testing Guide, http://www.freebsd.org/releases/4.5R/qa.html, but our focus is slightly different. Please send submissions to [EMAIL PROTECTED] before Wednesday March 20. We would like to allow enough time for translation teams to do their work, so the earlier the better. Thanks, - The Release Engineering Team msg36138/pgp0.pgp Description: PGP signature
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Thu, Mar 14, 2002 at 04:40:08PM -0800, Peter Wemm wrote: > If this is going to be a "static" release (calling it RELENG_5_anything is > a mistake IMHO) then this isn't a big deal. But if people are expecting > it to have ongoing secirity fixes etc like we do with RELENG_4_5 etc then > we have a problem, because it cannot last very long at all. Ongoing security fixes for a SNAPSHOT ??? No, that is definitely not the case. > Accordingly, I would much prefer that the branch (if we have to have it) > would be called SNAPSHOT_5_DP1 or soemthing, so that the "RELENG_" prefix > doesn't unduely raise expectations that it will keep working, or move the > DP1 release elsewhere if we want it to remain cvsup'able long term. I think that the huge warning signs all over the release documentation will do a lot more to set the expectations that the name of a CVS tag, but just to be sure I suppose we can keep the RELENG namespace for official releases. Your proposed name change works for me. - Murray msg36136/pgp0.pgp Description: PGP signature
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Fri, Mar 15, 2002 at 03:32:00AM +0100, Dag-Erling Smorgrav wrote: > "Bruce A. Mah" <[EMAIL PROTECTED]> writes: > > Differences of opinion on naming aside...the branch isn't supposed to > > last long at all. The point is to provide a slightly polished snapshot > > to the wider developer community. We can't do the QA/releng work on > > HEAD without calling for a code freeze (which we early on decided that > > we would *not* do). > > Then you don't need a branch, you just need a simple tag, and you can > slide it forward if something needs fixing, and remove it after > rolling and shipping the snapshot. Sliding tags around at the request of hundreds of different developers making thousands of changes to -CURRENT over that time period is not very appealing. However, all of our other options are rapidly being shot down as well. Peter raises some valid concerns about the pains that branching CVS will cause. They would have been much more helpful if voiced to re@ a week ago, but that's another issue. At the very least a tag is going down in approximately 24 hours. - Murray msg36135/pgp0.pgp Description: PGP signature
Linker or startup brokenness?
Hi When building the gcl port (ports/lang/gcl), the build dies when ``saved_gcl'' is run. The symptiom during the buld is a sig11 and a core dump. This is _after_ the patches that Peter worked out (and David O'B later committed). Here is a backtrace: Core was generated by `saved_gcl'. Program terminated with signal 11, Segmentation fault. #0 0x0 in ?? () (gdb) where #0 0x0 in ?? () #1 0x8181578 in __do_global_ctors_aux () #2 0x80480b6 in _init () (gdb) Any ideas? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rtld messing up?
Hi Here is kaffe (from ports) post mortem after an at-load blowup. #0 0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0) at /usr/src/libexec/rtld-elf/i386/reloc.c:196 196 *where += (Elf_Addr) obj->relocbase; (gdb) where #0 0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0) at /usr/src/libexec/rtld-elf/i386/reloc.c:196 #1 0x2804fb30 in relocate_objects (first=0x28064000, bind_now=0 '\000') at /usr/src/libexec/rtld-elf/rtld.c:1398 #2 0x2804e663 in _rtld (sp=0xbfbffa58, exit_proc=0xbfbffa50, objp=0xbfbffa54) at /usr/src/libexec/rtld-elf/rtld.c:380 Other ports (like QT2) are also doing this. Any ideas? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf #text/plain; name=cv.txt [Mark Murray CV Plain Text] cv.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Package set for release media
Does anyone have suggestions for additional packages that should be included on the upcoming Developer Preview snapshot that are not already listed in src/release/scripts/print-cdrom-packages.sh? The only changes since the release of 4.5 have been the inclusion of samba and the upgrade to emacs21. Please send suggested packages to portmgr@ and re@; no need to flood the list. Thanks, - Murray msg35935/pgp0.pgp Description: PGP signature
Re: Preparing innocent users for -current
On Fri, Mar 08, 2002 at 04:55:29PM -0500, Garance A Drosihn wrote: > One thing to keep in mind here is that this is still going to be > a snapshot of -current, and not a production release of -stable. > We want a snapshot that does not have any serious problems, but > "innocent users" should still realize that there are definitely > going to be a lot of loose ends and rough edges around. Exactly. This text was included on the back of the 5.0 snapshot CDROM from last year : "The FreeBSD 5.0-CURRENT SNAPshots are works in progress, and are intended solely for developers who are developing software on FreeBSD. There are no guarantees about the stability of these snapshot releases, although we make every attempt to thoroughly test the releases before production." It's hard for me to have sympathy for a user who doesn't read the warning labels posted all over the CD and release documentation. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Fri, Mar 08, 2002 at 05:28:24AM -0500, Jeff Roberson wrote:
> Should I postpone my allocator commit then?
Hi Jeff,
Yes, I would prefer to wait a week on this. After we've created
the RELENG_5_0_DP1 branch, you may commit the new allocator code to
-CURRENT. That will give us plenty of time to iron out any problems
before shipping a second developer preview this summer.
Thanks,
- Murray
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Preparing innocent users for -current
On Fri, Mar 08, 2002 at 11:33:27AM -0800, Hiten Pandya wrote: > Shouldn't this be CC'ed to -doc as well? Maybe someone will write > an article on a little release note kinda thing for this issue. Just > an opinion from a -current user. :) We're collecting notes for a "Testing Guide" similar to the one we published leading up to FreeBSD 4.5. More than anything, we need information from developers about how users can best test the new functionality. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
> To this end, we would like to request that commits for the next 7 > days to HEAD be made with special care. -CURRENT is in pretty good > shape right now, so we're not requiring approval for all commits. I have a Perl-5.6.1 upgrade. Is that too risky? Apart from the perl stuff itself, there are some other makefiles and mtree things that need to be done. Also the ports will be affected (not by very much). M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
As discussed at BSDCon, the release engineers are committed to
releasing a relatively stable snapshot of FreeBSD -CURRENT on or
around April 1, 2002. Obviously, a lot of major components are still
in progress, but a great deal of work has already been accomplished,
and could benefit from the additional exposure that a polished
snapshot with full package set and documentation will provide.
To this end, we would like to request that commits for the next 7
days to HEAD be made with special care. -CURRENT is in pretty good
shape right now, so we're not requiring approval for all commits.
However, we do request that re@ be consulted for any commits with a
substantial risk. This includes non-trivial changes to the VM system,
filesystems, network stack, important userland components, and others.
If unsure about a commit, please ask. Changes specific to emerging
architectures (sparc64, ia64, powerpc) are exempt from this approval
requirement no matter how substantial the change (as long as it only
affects the given architecture).
On March 15, a RELENG_5_0_DP1 branch will be created in CVS for
final release polishing. This will allow us to provide translated
release notes, sync up sysinstall and the package set, bump version
numbers, and tweak default diagnostic settings without further
impacting -CURRENT developers. Commits to this branch will require
re@ approval.
For further information about our plans for 5.0 Developer Previews,
and the eventual release of FreeBSD 5.0 in November, please see the
new release engineering section of the FreeBSD web site :
http://www.FreeBSD.org/releng
If you would like to help out with some of the quality-assurance
work for the upcoming developer preview, please install a -CURRENT
snapshot from :
ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/i386
- or -
ftp://snapshots.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386
And post your findings to current@ or qa@.
(Sorry, Alpha -CURRENT snapshots are harder to come by at the moment,
but Compaq just donated some hardware to alleviate this problem in the
future.)
Thanks for your cooperation,
- Murray (on behalf of The Release Engineering Team)
msg35781/pgp0.pgp
Description: PGP signature
Re: 5-CURRENT, make buildworld break?
On Wed, Mar 06, 2002 at 01:25:01PM +0100, Dag-Erling Smorgrav wrote: > Ruslan Ermilov <[EMAIL PROTECTED]> writes: > > On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote: > > > Last I checked, 'make release' checks the sources out from CVS, and is > > > therefore useless to test changes that haven't yet been committed. > > There's such a thing as LOCAL_PATCHES since at least 1996. > > Great! Now if only that was *documented* somewhere... It _IS_ documented in the release engineering paper : http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/extensibility.html - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
> Mark Murray <[EMAIL PROTECTED]> writes: > > > Umm, IIRC 'make world' starts by doing a 'make includes' into > > > /usr/obj, which should take care of this. > > That is 'make world'. It was broken for "make obj && make depend && make", > > [...] > > IMO, the repo-copy is the cleanest, because it solves te above problems > > in the most canonical way. > > Please talk to Ruslan about this. I suggested doing just what you're > thinking of about a month or two ago, and he rejected it. Ruslan is not writing this code; we are. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
> > That is _my_ fault, not DES'. It was a crypt() problem which I have fixed. > > Ok, I see now. Could we please make a rule to send a heads-up in such > cases (i.e. in the cases when some serious misbehaviour was introduced > and then fixed shortly). This would save me (and probably others) > roughly a hour that I spent debugging what's going wrong. My apologies. I should have thought to do that. I'll remember if there is a next time ;-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
> Mark Murray <[EMAIL PROTECTED]> writes: > > The problem is in the headers; you changed #include "pam_mod_misc.h" > > to #include without ensuring that a (correct) > > pam_mod_misc.h was in an appropriate secure/ dir. > > Umm, IIRC 'make world' starts by doing a 'make includes' into > /usr/obj, which should take care of this. That is 'make world'. It was broken for "make obj && make depend && make", and pam_krb5 was just plain broken (../Makefile.inc had a broken path). > > I've just finished fixing this (includes a repo-copy) and it will go > > in shortly. > > No repo-copy should be necessary. IMO, the repo-copy is the cleanest, because it solves te above problems in the most canonical way. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
> OK; markm said it was a crypt() problem (that he caused & fixed); I'm > not going to belabor that. (I will, however, express appreciation for > Mark "taking the heat": thanks, Mark!) *blush* > But on the point of folks being unable to login, I'm not seeing the > failure here. You'll only see it if you have the bad version of crypt-md5.c(1.9) and you actually use md5 passwords (the salt begins with $1$ when you look in /etc/master.passwd). The breakage time was less than 24 hours. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
> I can't login as root either, I can only gain root access if I boot into > single-user. > > The login process just eats up all cpu-ressources and the login times out > after 300 seconds. A su doesn't work either, of course. Not a PAM problem, a crypt(3) problem. My fault, and fixed. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
> Bah, just completed `make world' after doing `make includes' and found > that I can't login as *any* user, not only root!!! Login just > hangs after entering password and nothing goes on. DES! PLEASE FIX > THAT FSKING PAM - within a very short timeframe it's the second time > I'm having problems due to it and this just isn't acceptable even for > -current. That is _my_ fault, not DES'. It was a crypt() problem which I have fixed. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
> Maxim Sobolev <[EMAIL PROTECTED]> writes: > > Looks like source upgrade path is broken due to PAM. My system is -CURRENT > > compiled on 19 February. Please fix. > > Please use 'make world' to upgrade your system. Its more broken than that. I have a fix. The problem is in the headers; you changed #include "pam_mod_misc.h" to #include without ensuring that a (correct) pam_mod_misc.h was in an appropriate secure/ dir. I've just finished fixing this (includes a repo-copy) and it will go in shortly. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c src/secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c crypt-des.c
> This comment is false. On my -CURRENT system with > this commit in place 'passwd' and 'login'/'su' commands > loops forever computing MD5 password. > > After reverting crypt-md5.c to rev. 1.8 all thouse > commands work as always. It was a signed/unsiged issue. Fixed! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1
> It would be nice to see this version of perl in -CURRENT. It would help > ease the development of mod_perl-2.0 by not having to install the port > and it just makes sense considering the bleeding-edge of the rest of the > system. Coming RSN. Maybe this weekend. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD/i386 "make release" breakage
On Wed, Feb 27, 2002 at 12:19:01AM +0900, Makoto Matsushita wrote: > murray> I'm currently looking into #2 and #3, as well as working with Ted > murray> Lemon from the ISC to fix some symbol pollution that this whole mess > murray> has exposed. Any other ideas? > > Currently nothing, it seems that #3 (or its variant) is better IMHO. Ok. Fixed in r1.15 of sbin/dhclient/Makefile. I'm not sure if make release will succeed now (just started a build), but release.4 will at least build a crunched dhclient again. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD/i386 "make release" breakage
On Tue, Feb 26, 2002 at 06:39:22PM +0900, Makoto Matsushita wrote: > Note that new dhclient requires some libraries which are *not* > installed to /usr/lib (libdhcp, libres, libomapi, and libdst). Installing them to /usr/lib wouldn't help for the crunched case anyway. > I have tried a quick hack to solve this; here is a patch to boot_crunch.conf. I tried a different approach and I was able to build a properly brunched dhclient. However, src/release/Makefile tries to rebuild all of the object files so my near-fix still falls over when building a release. There are several possible ways to solve this problem : 1. Use the existing boot_crunch.conf, but fix crunchgen(1) to recurse into subdirectories to find object files. This would require significant changes to the way that crunchgen currently works. 2. Use the existing boot_crunch.conf, but move sbin/dhclient/* back to a single top-level Makefile. This does not work at the moment, because the objects in each subdirectory are built with different command line options to conditionally compile different parts of the header files. 3. Add an explicit OBJ list in the top level dhclient Makefile wrapped in a .ifdef (RELEASE_CRUNCH). This works well to build a crunched dhclient binary, however, src/release/Makefile tries to rebuild all of the objects individually, and gets confused when asked to rebuild 'client/clparse.o' from the top level, for example. src/release/Makefile could be changed to fix this. I'm currently looking into #2 and #3, as well as working with Ted Lemon from the ISC to fix some symbol pollution that this whole mess has exposed. Any other ideas? - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
