How reliable is make delete-old and make delete-old-libs on 7.1-PRERELEASE?
I ask because I just upgraded a remote system from 6.3-stable to
7.1-PRERELEASE. All seems well so far. Apps are running fine. I just
figure I should do this final bit.
FYI, I've written up how I did this migration
It's known that 'make clean' will occasionally not nuke all the
necessary objects in /usr/obj/*.
rm -fr /usr/obj/* is a better bet. Do not rely on 'make clean'.
Oh? Should I look into why the make system isn't removing /usr/obj/ on
a make clean and submit a patch?
--
Sean Bruno
MiraLin
On Fri, Aug 29, 2008 at 03:39:30PM -0700, Sean Bruno wrote:
> Sean Bruno wrote:
>>
>> mkdep -f .depend -a-I/home/sbruno/bsd/6/lib/csu/i386-elf/../common
>> -I/home/sbruno/bsd/6/lib/csu/i386-elf/../../libc/include
>> /home/sbruno/bsd/6/lib/csu/i386-elf/crt1.c
>> /home/sbruno/bsd/6/lib/csu/
The feedback I've been getting indicates that it's safe to go back in the
water again.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED
Dan Allen wrote previously:
well I got bit by this and am dead in the water.
I got the tools and built everything okay once again. Thanks to
everyone for the help!
Dan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailma
Sean Bruno wrote:
mkdep -f .depend -a-I/home/sbruno/bsd/6/lib/csu/i386-elf/../common
-I/home/sbruno/bsd/6/lib/csu/i386-elf/../../libc/include
/home/sbruno/bsd/6/lib/csu/i386-elf/crt1.c
/home/sbruno/bsd/6/lib/csu/i386-elf/crti.S
/home/sbruno/bsd/6/lib/csu/i386-elf/crtn.S
/usr/bin/mkdep:
O. Hartmann wrote:
Steve Bertrand wrote:
Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
My 7.0 box upgraded fine this morning:
FreeBSD ids.eagle.ca 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug
29 11:
I've run into a variance in behavior between my SVN updated tree and my
CVSUP'd tree that is befuddling me.
Running a make depend on two freshly updated trees seems to generate
errors with my SVN tree but not my CVSUP tree. Here is the output of
the SVN tree. This is freshly checked out from
Steve Bertrand wrote:
Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
My 7.0 box upgraded fine this morning:
FreeBSD ids.eagle.ca 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug
29 11:38:12 EDT 2008 [
On Fri, 29 Aug 2008 22:08:47 +0300 Kostik Belousov wrote:
> On Fri, Aug 29, 2008 at 10:43:39AM -0600, Dan Allen wrote:
> > Well I got bit by this and am dead in the water. Nothing builds. I
> > tried the DEBUG_FLAGS=-g trick but to no avail.
> >
> > I get this:
> >
> >cc: Internal error:
> The breakage from the WITH_CTF build is indicated by Abort from the
> image activator. Signal 11, AKA segmentation fault, is not likely
> to be caused by the dtrace MFC problems.
>
> Just in case, if you have buildworld result intact, you should enter
> /usr/src/gnu/usr.bin/binutils/ld
> and do
On Fri, 29 Aug 2008 10:43:39 -0600 Dan Allen wrote:
> Well I got bit by this and am dead in the water. Nothing builds. I
> tried the DEBUG_FLAGS=-g trick but to no avail.
> I get this:
>cc: Internal error: segmentation fault: 11 (program ld)
Yep, you need some tools installed with debug f
On Friday 29 August 2008 03:57:46 am Henri Hennebert wrote:
> Henri Hennebert wrote:
> > John Baldwin wrote:
> >> This patch merges a few changes from HEAD back to 7.x. I think the
> >> endian changes specifically might solve the issue people saw with
> >> zpools created with non-dtrace kernels
So I have a patch to try and straighten out the ppbus/ppc interrupt stuff a
bit. Rather than passing IRQ numbers around as ivars, etc., ppc is smart
enough to let child devices ask for SYS_RES_IRQ rid 0 and let them use its
assigned IRQ resource. It then uses an interrupt event to mange the li
On Fri, Aug 29, 2008 at 10:43:39AM -0600, Dan Allen wrote:
> Well I got bit by this and am dead in the water. Nothing builds. I
> tried the DEBUG_FLAGS=-g trick but to no avail.
>
> I get this:
>
>cc: Internal error: segmentation fault: 11 (program ld)
>
> I do not have a backup ld. (My
John Birrell wrote:
I know that there are issues with upgrading from 6.X (where .X isn't the
most recent on RELENG6). I'll need help from someone with an old 6.2
box (say) to test out the builds. I have no hardware to run an old version
of 6 on.
This is most likely not exactly what you are aft
Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
My 7.0 box upgraded fine this morning:
FreeBSD ids.eagle.ca 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug
29 11:38:12 EDT 2008 [EMAIL PROTECTED]:/usr/o
On Fri, 29 Aug 2008, Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I tried
the DEBUG_FLAGS=-g trick but to no avail.
I get this:
cc: Internal error: segmentation fault: 11 (program ld)
I do not have a backup ld. (My bad.)
Where can I get a good one?
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
I get this:
cc: Internal error: segmentation fault: 11 (program ld)
I do not have a backup ld. (My bad.)
Where can I get a good one? I cannot find any servers with built
On Friday 29 August 2008 01:33:36 am Jonathan Bond-Caron wrote:
> Hi Everyone,
>
> I have a dell 1750 server with ERA/O card running on FreeBSD 7.0-STABLE
>
> According to Dell, the ERA card supports ipmi 1.0:
>
> http://linux.dell.com/ipmi.shtml
>
> But so far no luck with freebsd :/
If you
On Thursday 28 August 2008 06:36:30 pm John Birrell wrote:
> It goes without saying that this didn't go anywhere near as smoothly as
> I hoped it would. My attention to detail was less than perfect. Sorry
> for the pain I've caused.
>
> A big thanks to those who've put work into fixing the mistake
On Fri, Aug 29, 2008 at 4:48 AM, Bob Bishop <[EMAIL PROTECTED]> wrote:
> The only problem I have seen on em is that by default the driver resets the
> phy during boot which confuses IPMI; if a SOL console session is active, the
> driver is signalled not to do the reset.
Same here. The 1950-III
John Birrell wrote:
I know that there are issues with upgrading from 6.X (where .X isn't the
most recent on RELENG6). I'll need help from someone with an old 6.2
box (say) to test out the builds. I have no hardware to run an old version
of 6 on.
I've got a 6.2 box that needs upgrading anyway,
TB --- 2008-08-29 08:40:50 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 08:40:50 - starting RELENG_7 tinderbox run for ia64/ia64
TB --- 2008-08-29 08:40:50 - cleaning the object tree
TB --- 2008-08-29 08:41:03 - cvsupping the source tree
TB --- 2008-08-29 08:41:03 - /usr/bi
TB --- 2008-08-29 08:16:45 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 08:16:45 - starting RELENG_7 tinderbox run for i386/pc98
TB --- 2008-08-29 08:16:45 - cleaning the object tree
TB --- 2008-08-29 08:16:56 - cvsupping the source tree
TB --- 2008-08-29 08:16:56 - /usr/bi
Hi,
On 29 Aug 2008, at 08:44, Jeremy Chadwick wrote:
[...]That said, the feature you're referring to (IPMI piggybacking
on top of
an existing NIC on the mainboard) is called "ASF" from a NIC driver
perspective.
In implementations I've looked at, the interfaces really are distinct
hardware
TB --- 2008-08-29 07:36:05 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 07:36:05 - starting RELENG_7 tinderbox run for i386/i386
TB --- 2008-08-29 07:36:05 - cleaning the object tree
TB --- 2008-08-29 07:36:19 - cvsupping the source tree
TB --- 2008-08-29 07:36:19 - /usr/bi
TB --- 2008-08-29 06:42:04 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 06:42:04 - starting RELENG_7 tinderbox run for amd64/amd64
TB --- 2008-08-29 06:42:04 - cleaning the object tree
TB --- 2008-08-29 06:42:20 - cvsupping the source tree
TB --- 2008-08-29 06:42:20 - /usr/
Henri Hennebert wrote:
John Baldwin wrote:
This patch merges a few changes from HEAD back to 7.x. I think the
endian changes specifically might solve the issue people saw with
zpools created with non-dtrace kernels not being readable by dtrace
kernels and vice versa.
http://www.FreeBSD.org/
On Fri, Aug 29, 2008 at 02:17:17AM -0400, Zaphod Beeblebrox wrote:
> Curiously, IPMI shares the ethernet ports with the onboard ethernet
> controllers without FreeBSD's knowledge. It does use a different MAC
> address. It is also apparently capable of using vlans (haven't tested this
> yet). I'm
John Baldwin wrote:
This patch merges a few changes from HEAD back to 7.x. I think the endian
changes specifically might solve the issue people saw with zpools created
with non-dtrace kernels not being readable by dtrace kernels and vice versa.
http://www.FreeBSD.org/~jhb/patches/zfs_7.patch
31 matches
Mail list logo
