Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x
On Dec 17, 2010, at 23:41 , Doug Barton wrote: > Your feedback on the issue of upgrading BIND in RELENG_7 is welcome. > Sooner is better. :) Seriously? For RELENG_7 which is going to be with us a long time. Looks like we have a bunch of DNS mongers here that have tested out their stuff with RELENG_8 to no apparent "omg, iceberg" ill-effect. Light blue touch paper. Stand back. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [solved] Re: Re: Re: diskless - NFS root mount problem
On Nov 16, 2009, at 13:32 , Doug Barton wrote: > You're not a real sysadmin until you've firewalled yourself out of at > least one mission-critical system. > > Bonus points if it has no out-of-band control plane. > > Further bonus points if it is more than 100 miles away, and you are > the one who has to drive to the data center. Extreme bonus points if said system is on another continent, and you have to get on a plane _right_now_ (spending the flight wondering why the OOB system is dead). -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: Impending autotools changes
Note that the below instructions are not strictly accurate (*sigh*)
See http://freebsd.lovett.com/patches/autotools-updating.txt
for the UPDATING entry.
This has been tested on a machine with a full GNOME and KDE
environment installed and will become part of ports/UPDATING.
-aDe
On Jul 27, 2007, at 00:45 , Ade Lovett wrote:
Please note that this change will be committed some time this
coming weekend.
-aDe
Begin forwarded message:
From: Ade Lovett <[EMAIL PROTECTED]>
Date: July 23, 2007 19:13:21 PDT
To: [EMAIL PROTECTED]
Cc: Ade Lovett <[EMAIL PROTECTED]>
Subject: HEADS UP: Impending autotools changes
In the next few days, after extensive testing, the next major
update to the autotools infrastructure will be committed to the
ports tree.
These changes bring FreeBSD's autoconf/automake in line with
autotool suites available on other platforms, allowing for
multiple versions to be installed and run in isolation of each other:
[EMAIL PROTECTED]:/usr/local/bin] 4% ls autoconf* automake*
autoconf autoconf-wrapper automake-1.6
autoconf-2.13 automake automake-1.7
autoconf-2.53 automake-1.10 automake-1.8
autoconf-2.59 automake-1.4 automake-1.9
autoconf-2.61 automake-1.5 automake-wrapper
As you will see from the above, the naming conventions have been
changed to be "stock", with unversioned scripts allowing the use
of any version of the tools via a couple of wrapper scripts
written by [EMAIL PROTECTED]
There are 3 key points associated with this change:
1. The ports versions of autoconf* and automake* can now be used,
not only for building other ports, but also for developing
platform-independent code using this tools -- as such, the gnu-*
variants will be disappearing shortly.
2. For IDEs, or development in general, a new port, devel/
autotools (also available in a port Makefile as USE_AUTOTOOLS=
autotools:run) will bring in all available versions of the autotools.
3. When it comes to the actual update, a number of ports, most
notably IDEs and php{4,5}, but all software that embeds the
current names of autotools in build scripts etc. will need to be
updated, or bad things will happen. Regretfully, particularly in
the case of PHP, this will likely require manual intervention
outside of the portupgrade/portmaster update methodologies.
That aside, this is a significant step forward for autotools on
FreeBSD, and my thanks go out to those that have provided
assistance and testing. In particularly, I would like to thank
linimon@, pav@, kris@ and des@ for their respective efforts in
making this happen.
-aDe
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-
[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: HEADS UP: Impending autotools changes
Please note that this change will be committed some time this coming
weekend.
-aDe
Begin forwarded message:
From: Ade Lovett <[EMAIL PROTECTED]>
Date: July 23, 2007 19:13:21 PDT
To: [EMAIL PROTECTED]
Cc: Ade Lovett <[EMAIL PROTECTED]>
Subject: HEADS UP: Impending autotools changes
In the next few days, after extensive testing, the next major
update to the autotools infrastructure will be committed to the
ports tree.
These changes bring FreeBSD's autoconf/automake in line with
autotool suites available on other platforms, allowing for multiple
versions to be installed and run in isolation of each other:
[EMAIL PROTECTED]:/usr/local/bin] 4% ls autoconf* automake*
autoconf autoconf-wrapper automake-1.6
autoconf-2.13 automake automake-1.7
autoconf-2.53 automake-1.10 automake-1.8
autoconf-2.59 automake-1.4 automake-1.9
autoconf-2.61 automake-1.5 automake-wrapper
As you will see from the above, the naming conventions have been
changed to be "stock", with unversioned scripts allowing the use of
any version of the tools via a couple of wrapper scripts written by
[EMAIL PROTECTED]
There are 3 key points associated with this change:
1. The ports versions of autoconf* and automake* can now be used,
not only for building other ports, but also for developing platform-
independent code using this tools -- as such, the gnu-* variants
will be disappearing shortly.
2. For IDEs, or development in general, a new port, devel/
autotools (also available in a port Makefile as USE_AUTOTOOLS=
autotools:run) will bring in all available versions of the autotools.
3. When it comes to the actual update, a number of ports, most
notably IDEs and php{4,5}, but all software that embeds the current
names of autotools in build scripts etc. will need to be updated,
or bad things will happen. Regretfully, particularly in the case
of PHP, this will likely require manual intervention outside of the
portupgrade/portmaster update methodologies.
That aside, this is a significant step forward for autotools on
FreeBSD, and my thanks go out to those that have provided
assistance and testing. In particularly, I would like to thank
linimon@, pav@, kris@ and des@ for their respective efforts in
making this happen.
-aDe
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 5, 2006, at 19:34 , Kris Kennaway wrote: Based on successful testing on a machine with shared em interrupt, the following patch should work around the problem *in that case*. This solves the em(4) issue for me on a shared interrupt. Prior to this, the network hang (no watchdog timeouts) was trivially reproducible with an NFS-mounted FreeBSD repository to two builder boxes, and running cvs -q upd on the ports tree at the same time. (the builder boxes also have em(4) interfaces, which I haven't patched, but they're running 7.0-CURRENT). Everything is i386. [EMAIL PROTECTED]:/dtbox] 739# vmstat -i ... irq21: em0 acpi0 965426857 ... - -aDe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFKexJpXS8U0IvffwRArroAKCR69boUDor2t+L9rXsYXpoYsQkEQCeIcYg pSAbtbu28DAUE+EbOJUmIk8= =NbgC -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: www/en/releases/6.1R todo.sgml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While we're at it, bin/94028 points out a fundamental problem with ifconfig(8) as it stands on 6.1-PRERELEASE, preventing MTUs from being set on vlan interfaces. - -aDe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEDLzBpXS8U0IvffwRAon2AJ463hVinulXQWe4f/FnRLt5lbFQRgCghQK9 tZ8ICssIVEoUzPmrOPMfUuc= =7K0L -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ahd0: Invalid Sequencer interrupt occurred.
On Nov 11, 2005, at 23:10 , John-Mark Gurney wrote: obviously you haven't done any research or even talked with Seagate about this issue... Seagate has a Linux version of their Seagate Enterprise Utility that allows you to flash their drives... Yes, I have done plenty of research with Seagate, Adaptec, and a number of VARs. Edit your kernel config, add: options KVA_PAGES=384 (for a 2.5G/1.5G kernel/userland split, as opposed to 2G/2G) recompile, install, watch the linuxulator explode in a frenzy. I have absolutely no interest in putting Linux (or, indeed, anything *but* FreeBSD) on my production boxes. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ahd0: Invalid Sequencer interrupt occurred.
On Nov 11, 2005, at 12:51 , Amit Rao wrote: 0) Upgrade to Seagate 10K.7 drive firmware level 0008. That seems to help. One "ahd sequencer error" message still appears at boot, but after that it seems to work (with your fingers crossed). Of course, you then spend far too much time ensuring that any replacement drives are flashed appropriately (which, afaict, *requires* Windows to do), and also running the gauntlet of further problems down the road when you throw the drives into a new machine with a subtly different HBA bios. No thanks, I'll stick with option (2). A few more months, and Seagate drives will be a nice distant memory that I can look back on in a few years, and laugh nervously about. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ahd0: Invalid Sequencer interrupt occurred.
On Nov 10, 2005, at 05:30 , Ricardo A. Reis wrote: Reducing the problem to the relevant pieces: ahd0: port 0x2400-0x24ff, 0x2000-0x20ff mem 0xdd20-0xdd201fff irq 32 at device 2.0 on pci3 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x2c00-0x2cff, 0x2800-0x28ff mem 0xdd202000-0xdd203fff irq 33 at device 2.1 on pci3 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs [...] da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) Trying to mount root from ufs:/dev/da0s1a Adaptec HBAs and Seagate drives have a long and intensely painful history of not working well together. Adaptec blames Seagate. Seagate blames Adaptec. Throw in the myriad of subtly different AIC controllers that are commonplace on 1U and 2U rackmount servers, and things get even more entertaining. You essentially have 3 options 1) replace the HBA -- somewhat difficult to do if it's embedded and you need the PCIX slots for something else. 2) replace the drives -- IBM/Hitachi are fine choices here. Make sure to tell whomever you purchase systems from that you'll not accept Seagate drives in the future. 3) inside the adaptec bios, drop the drives to U160 speed, making sure that *both* packetizing *and* QAS are turned OFF. You'll lose a little bit of performance (but not all that much, Seagate drives really are garbage), and get some semblance of stability. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCSI troubles
Niki Denev wrote: > From what i understand this is not exactly a FreeBSD problem, but rather > a consequence of U320 being really hard on the hardware with pushing it > to the limits. Incorrect. The relevant parts of the output you pasted are: ahd Seagate drives Attaching more than one Seagate drive to a single Adaptec chain will result in various weird and wonderful behavior as you've described. This is above and beyond well known (and documented) issues with data loss and corruption with certain firmware revisions on Seagate drives. You have essentially two options: (1) disable the (on-board) adaptec controller, and use something else (LSI cards work pretty good) (2) chunk the Seagate drives, and replace them with some other vendor (Hitachi, for example, in our high-stress environments, show equivalent MTBFs) I've spent several years (no, I'm not kidding) going around the loop between Adaptec, Seagate, and various motherboard manufacturers, trying to get sensible U320 performance out of the hardware. Each vendor blames the other. Now, I'm a tenacious person by nature (guess it's part of being English), and I have no intention of letting this just go until I hear some real, valid, reasons as to the interoperability issues (are you listening Seagate?) However, in the meantime, if you don't want to cripple those expensive U320 drives by dropping the controller to U160 for each and every device, I strongly recommend either option (1) or (2) above, and move on. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA vs SCSI ...
Marc G. Fournier wrote: > > looking at the specs between two cards, the SATA card(s) seem to rate > ~100-150MB/s on each channel (if I'm reading right), with both the 3Ware > and ICP cards having 4 individual channels ... looking at the SCSI > cards, they are rated at 320MB/s, but that is total for the SCSI bus > itself, right? [snip] As is often the case, these kind of comparisons are only working against one side of the equation: "What happens when the system is operational" Now, for your average desktop system, the converse: "What happens when things break" becomes negligable. Slap in new drive, slap in DVD/CD install media, Do Stuff[tm], make working system. In the Non-Stop (probably a trademark of Tandem) server-class world, things work somewhat differently. This is why we run postgresql instead of mysql. This is also the reason we run U320 SCSI enclosures at twice the cost of equivalent SATA systems. The extra cash is well spent when things go wrong. Absolute performance (assuming it can be measured correctly for the specific environment you're in, as opposed to marketing figures) counts for less than 50% of the whole equation when it comes to the purchase decision. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.3p6-5.4RC3, Supermicro X6DHR-8G, Dual 3.6GHzXeons,Adaptec aic7902 SCSI interface doesn't work in UP kernel
Guy Helmer wrote: Reducing the problem to its relevant parts: > SuperMicro [...] Seagate [...] > on-board aic7902 and, from your dmesg output: da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers [...] Supermicro boards and Seagates generally hate each other. Supermicro blames Seagate, Seagate blames Supermicro. Even under normal operation, you'll see spurious SCSI errors, both at bootup, and under load, exacerbated if you put more than one Seagate drive on the same chain, or run them at their native U320 speeds. To make matters worse, your ST373207LC model is, even by Seagate standards, a piece of unmitigated crap. At an absolute minimum, have the existing drive swapped out for an ST373453LC model, making VERY certain that the firmware is rev 0006 -- prior revisions WILL corrupt your data, set fire to your cat, and otherwise ruin your entire life -- and that's before they've actually spun up. A second option is to change the drive out for one from a vendor that actually cares -- ok, maybe only *just* cares, but cares nonetheless. Hitachi drives work fine, and certainly seem to be in the same ballpark for overall reliability. Likewise, swapping out the motherboard for a non-Supermicro unit may be an option, though be wary of anything with onboard Broadcom gigabit ethernet if you plan on doing continuous high network I/O -- Seagate drives *appear* to have considerably fewer problems when connected to non-Adaptec hardware in general, and the onboard Supermicro variant in particular. If you're stuck with the hardware you have (modulo this particular 73GB drive model, as mentioned above), pick up another SCSI controller and use that, not forgetting to disable the onboard controllers. At an absolute pinch, head in to the adaptec bios and lock down the drive to U160 speeds -- that *may* help in a few edge cases. Someone (I forget who, sorry) recently suggested a considerable portition of the Supermicro vs Seagate mess was down to a weird interaction between the bios and the occasional SMM interrupt -- a hackaround to run at boot was even suggested -- check the archives for details, though unfortunately it did not appear to fix the issues I was seeing on boxes here. You may have better luck. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3 Buildworld Problems on AMD
Tom wrote: > I have an update - I just tried to build from source from the CD and the > FTP site, no dice... > I've tried cvsup'ing to 5.4-PRE and that doesn't build either. > > Anyone? I didn't see anything in the archives, and some googling > doesn't show anything either. > > Is 5.3-4 broken for AMD? Nope. RELENG_5 from around 1800 PST today (3/17) built just fine, and is currently being hammered pretty hard doing some tinderbox builds of GNOME 2.10 against the newly imported XOrg 6.8.2 on a couple of boxes here. What specific errors are you seeing? Without those, along with the contents of /etc/make.conf, it's going to be essentially impossible for anyone to give any further suggestions. -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel build failure amd64
Christopher Vance wrote: The only file mentioning KB_CONF_NO_PROBE_TEST in any version appears to be src/sys/dev/kbd/atkbd.c, with no definition anywhere. Your src/ tree is not up to date, or has been otherwise mangled. The commit that added KB_CONF_NO_PROBE_TEST touched two files: [EMAIL PROTECTED]:/sys/dev/kbd] 2% grep KB_CONF_NO_PROBE_TEST * atkbd.c:if (!(flags & KB_CONF_NO_PROBE_TEST)) atkbdreg.h:#define KB_CONF_NO_PROBE_TEST (1 << 3) /* don't test keyboard during probe */ -aDe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCB - timed out on FreeBSD 4.10-p2
Dave Hayes wrote: /kernel: da0: Fixed Direct Access SCSI-3 device /kernel: da1: Fixed Direct Access SCSI-3 device We use a metric boatload of these machines and disks at REALJOB. The mismatch on the drive firmware is almost certainly likely to be the issue here. What's the revision of the Adaptec BIOS on the motherboard (4.00? 4.10.1? 4.30.x?) -aDe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: databases/postgresql72 is dying
Sebastian Böck wrote: Have you considered that 7.2 is the last Version that doesn't have schemas. Out there may be some / are lot of applications that depend on this behaviour. I've considered lots of things. Nothing is *forcing* you to upgrade, and there will be packages for this port all the way up to 5.3-RELEASE (those that use older databases tend to stick with older OS releases, too). Speculations as to software that *may* be out there, that *does* want to run on a brand new 5.3+ OS, are not useful without concrete evidence to back them up. -aDe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: databases/postgresql72 is dying
FYI. Prior to the postgresql new-world-order in ports/, I have now tagged databases/postgresql72 (current version 7.2.5) as DEPRECATED, with it being removed from the tree on or about 1st January 2005. You are *strongly* urged to upgrade to either 7.3.x or 7.4.x As previously stated (on ports@), this will also affect the FreePascal in lang/fpc (but *not* lang/fpc-devel, corresponding to a relatively new beta prior to 2.0) which will be tagged as BROKEN once postgresql72 goes away, and will be subject to the usual reaper-timeout for defunct ports. Of course, if someone comes up with patches to fix databases/fpc-postgres to work with postgresql-7.3.x or (preferably) 7.4.x, feel free to mail me and I'll add them in. -aDe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.9-RC + XFree86-4 + nvidia weirdness
A few system details: FreeBSD scythe.lovett.com 4.9-RC FreeBSD 4.9-RC #0: Thu Oct 16 14:02:55 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Bootstrapped from a minimal install from the 4.9-RC2 ISO image. Relevant devices: agp0: mem 0xf800-0xfbff at device 0.0 on pci0 nvidia0: mem 0xf400-0xf7ff,0xf200-0xf2ff irq 11 at device 0.0 on pci1 Ports of the same vintage: XFree86-4.3.0,1 XFree86-FontServer-4.3.0_2 XFree86-Server-4.3.0_11 XFree86-clients-4.3.0_3 XFree86-documents-4.3.0 XFree86-font100dpi-4.3.0 XFree86-font75dpi-4.3.0 XFree86-fontCyrillic-4.3.0 XFree86-fontDefaultBitmaps-4.3.0 XFree86-fontEncodings-4.3.0 XFree86-fontScalable-4.3.0 XFree86-libraries-4.3.0_6 XFree86-manuals-4.3.0 Xft-2.1.2 nvidia-driver-1.0.4365 (compiled with WITH_FREEBSD_AGP=YES) The problem: Using the 'nv' driver brings up X with no problems. Switching to the 'nvidia' driver, I get: (EE) NVIDIA(0): Failed to allocate a DMA push buffer context (EE) NVIDIA(0): *** Aborting *** The exact same configuration and set of ports works fine on the same hardware with -current. After a quick conversation elsewhere, it was noted that USER_LDT, whilst the default in -current, is not present by default in -stable. Adding "options USER_LDT" to /sys/i386/conf/GENERIC, buildkernel/installkernel, and a rebuild of nvidia-driver later, I got a panic: [...] #11 0xc0702420 in ?? () #12 0xc026272a in spec_ioctl () #13 0xc0262455 in spec_vnoperate () #14 0xc033f06d in ufs_vnoperatespec () #15 0xc025ee1f in vn_ioctl () #16 0xc0238bae in ioctl () #17 0xc039e311 in syscall2 () #18 0xc038eec5 in Xint0x80_syscall () #19 0x8441a07 in ?? () Bugger. No debugging kernel built with GENERIC. Ok. Add in "makeoptions DEBUG=-g # (growl, maim, slash, burn)", buildkernel/installkernel, rebuild nvidia-driver and reboot, we switch back to the previous behavior (no panic! gah!): (EE) NVIDIA(0): Failed to allocate a DMA push buffer context (EE) NVIDIA(0): *** Aborting *** Any suggestions? -aDe (currently back to the 'nv' driver) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GNOME 1.4
FYI, GNOME 1.4 was released today. Sadly, with the magnitude of the changes (some 15,000 lines of diff now), and the timeline for the ports freeze (April 10th), I am not going to be able to get this in 4.3-RELEASE :( However, I should have final patches available for testing within the next couple of days, and will send out a note asking for testers who are prepared to completely trash their machines :) -aDe [FreeBSD/GNOME maintainer] -- Ade Lovett, Austin, TX.[EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: gnome 1.2 install
On Thu, Oct 19, 2000 at 09:44:51AM -0500, Ade Lovett wrote: > Find the port that installed /usr/local/include/malloc.h and delete it > with extreme prejudice. It's devel/libmalloc, which I've just marked as BROKEN so this issue won't come up again until either the port is fixed or just plain deleted. pkg_delete libmalloc-1.18 and start over, and you'll be fine. Thanks to Sean O'Connell <[EMAIL PROTECTED]> for kicking me hard enough to realise I could do this myself :) -aDe -- Ade Lovett, Austin, TX. [EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
