check that "make release" still works with it? Here a "make
release" bombs out with:
###
cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DA
UTHENTICATION -DENCRYPTION -I/usr/src/secure/libexec/telnetd/../../../crypto/te
lnet -DINET6 -DNO_IDEA
are still built for ``make release'' (RELEASEDIR).
The problem is certainly elsewhere.
[2 minutes of thinking]
Doh, now I see what happened. It is another commit that broke this.
Commit to secure/ Makefiles. Here is part of my original posting to
Mark Murray on secure/ build fixes regarding secure
Making fixit floppy.
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 6.
Warning: 1216 sector(s) in last cylinder unallocated
/dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors
1.4MB in 1 cyl groups (6
Does anyone have some free space that they can borrow the fixit floppy?
Created /R/stage/floppies/boot.flp
Regular and MFS boot floppies made.
touch release.8
Making fixit floppy.
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders
Maxim Sobolev wrote:
Slightly OT, but could we have a flag to disable building sysinstall during make
world? It's hardly a tool that is required for day-to-day operation, so in most
cases it will only waste considerable amount of root partitition.
1) Now sysinstall is /usr/sbin, and it is
3) Most of what FreeBSD installs is not required for day-to-day for most
users. Since many users use sysinstall to some extent as a system
managing tool, sysinstall is actually quite more oftenly used than many.
It's currently the best way to install packages IMHO. With the automatic
"Rogier R. Mulhuijzen" wrote:
3) Most of what FreeBSD installs is not required for day-to-day for most
users. Since many users use sysinstall to some extent as a system
managing tool, sysinstall is actually quite more oftenly used than many.
It's currently the best way to install packages
What are you talking about? pkg_add -r pkgname, that's all it takes.
*hides head in shame*
OK so I'm a sucker for the graphical interface =)
DocWilco
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On 19-Jan-01 Chris Knight wrote:
Howdy,
Since the sysinstall move, make release on FreeBSD-stable (as of 3 hrs ago)
breaks when building sysinstall. The output is:
rtermcap needs to be a build-tool in world. The 4.x upgrade path is b0rked
too. I think that file2c also needs to become
John Baldwin wrote:
On 19-Jan-01 Chris Knight wrote:
Howdy,
Since the sysinstall move, make release on FreeBSD-stable (as of 3 hrs ago)
breaks when building sysinstall. The output is:
rtermcap needs to be a build-tool in world. The 4.x upgrade path is b0rked
too. I think
On 19-Jan-01 Maxim Sobolev wrote:
John Baldwin wrote:
On 19-Jan-01 Chris Knight wrote:
Howdy,
Since the sysinstall move, make release on FreeBSD-stable (as of 3 hrs
ago)
breaks when building sysinstall. The output is:
rtermcap needs to be a build-tool in world. The 4.x upgrade
Howdy,
Since the sysinstall move, make release on FreeBSD-stable (as of 3 hrs ago)
breaks when building sysinstall. The output is:
=== usr.sbin/sysinstall
cc -o rtermcap /usr/src/usr.sbin/sysinstall/rtermcap.c -ltermcap
rm -f makedevs.tmp
echo '#include sys/types.h' makedevs.tmp
./rtermcap
On Tue, Jan 09, 2001 at 09:11:20AM +0100, Poul-Henning Kamp wrote:
=== rpcsvc
rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h
rpcgen: cannot find any C preprocessor (cpp)
*** Error code 1
Let me start a release. This means rpcgen has been using
/usr/libexec/cpp
=== rpcsvc
rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h
rpcgen: cannot find any C preprocessor (cpp)
*** Error code 1
Let me start a release. This means rpcgen has been using
/usr/libexec/cpp which is *only* for the compiler's use. rpcgen should
have
--
stage 4: populating /usr/obj/usr/src/i386/usr/include
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/
Poul-Henning Kamp wrote:
--
stage 4: populating /usr/obj/usr/src/i386/usr/include
--
=== rpcsvc
rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o
Hi,
I've been trying to create a -current release for awhile
now and have run into numerouse problems. However, this one
seems to be reproducible (last 3 days or so):
--
stage 4: populating /usr/obj/usr/src/i386/usr/include
--
stage 4: populating /usr/obj/usr/src/i386/usr/include
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj
On Wed, 29 Nov 2000, John Baldwin wrote:
On 29-Nov-00 Gray, David W. wrote:
Hmmm, I'm specifically talking about when you have MAKEOBJDIRPREFIX set to
something other than /usr/obj - it *almost* works, but /bin/sh uses files
generated on-the-fly that get put in the wrong places (in the
BTW, is it considered a bug or a feature that you MUST use /usr/obj to
have make release work? I went in circles for quite a while before figuring
this out (I just didn't have much room in /usr, so was using the make env
variable to move the obj tree. It failed in various amusing ways whilst
On 29-Nov-00 Gray, David W. wrote:
BTW, is it considered a bug or a feature that you MUST use /usr/obj to
have make release work? I went in circles for quite a while before figuring
this out (I just didn't have much room in /usr, so was using the make env
variable to move the obj tree
Current list
Subject: RE: more make release
On 29-Nov-00 Gray, David W. wrote:
BTW, is it considered a bug or a feature that you MUST use /usr/obj to
have make release work? I went in circles for quite a while before
figuring
this out (I just didn't have much room in /usr, so was using the make
of that.
-Original Message-
From: John Baldwin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 29, 2000 12:10 PM
To: Gray, David W.
Cc: FreeBSD Current list
Subject: RE: more make release
On 29-Nov-00 Gray, David W. wrote:
BTW, is it considered a bug or a feature that you
I want to start building releases on a home box since it's not doing much
else when I'm at work. But I have a rather low bandwidth, so I was
wondering about the CVS checkout of /usr/src that the make release does.
With my bandwidth the source may very well be out of synch with what
I want to start building releases on a home box since it's not doing much
else when I'm at work. But I have a rather low bandwidth, so I was
wondering about the CVS checkout of /usr/src that the make release does.
Well, it's fairly easy to keep a cvs repo up to date even at low
bandwidth
On Mon, 27 Nov 2000, Jordan Hubbard wrote:
I want to start building releases on a home box since it's not doing much
else when I'm at work. But I have a rather low bandwidth, so I was
wondering about the CVS checkout of /usr/src that the make release does.
Well, it's fairly easy
But I don't understand why you need the whole historical cvs repository
when you only use it to check out the current source, which you already
has online.
Or am I missing something too?
You're missing something too. You can build a release with the tag
set to anything you like - modulo
hosokawa Maybe it's current.jp.freebsd.org's problem
I don't think so. It's a mismatch that all object files are created
under /usr/src/modules but make install assumes that these are under
(maybe) /usr/obj. Maybe it's a fault of some Makefiles (sorry I dunno
who change the policy of module
At Fri, 03 Nov 2000 12:05:46 +0900,
Makoto MATSUSHITA [EMAIL PROTECTED] wrote:
BTW, I've not received your email; are you busy working?
Last night, I tested "make release" on my machine, and failed twice
because of unloaded vn driver (this causes last trouble). It
successfl
hosokawa Last night, I tested "make release" on my machine, and
hosokawa failed twice because of unloaded vn driver (this causes last
hosokawa trouble). It successfly finished this morning. I'm Sorry.
'vn' device is a great pitfall of "make release" :-)
hosokawa I unde
=== 3dfx
Warning: Object directory not changed from original /usr/src/sys/modules/3dfx
Maybe it doesn't occur before, and today's make release is also failed.
cd ../../modules env MAKEOBJDIRPREFIX=/usr/src/sys/compile/BOOTMFS/modules KMDDIR=
make install
=== 3dfx
install -c -o root -g wheel -m 555
Forget to note:
matusita Warning: Object directory not changed from original /usr/src/sys/modules/3dfx
dinosaur % pwd
${CHROOT_DIRECTORY_FOR_CURRENT}/usr/src/sys/modules
dinosaur % ls */*.o
3dfx/setdef0.o 3dfx/setdef1.o 3dfx/tdfx_pci.o
Only 3dfx module uses /usr/src/sys/modules for
I'm not sure whether the problem of loading secondary usb modules is a
problem in 4.x but it is easy to try.
Boot a machine without usb support compiled in. after login, kldload
usb, then the miibus and then the if_aue modules. If that works, you
should be ok.
I cannot test this as at the
I'm not sure whether the problem of loading secondary usb modules is a
problem in 4.x but it is easy to try.
Boot a machine without usb support compiled in. after login, kldload
usb, then the miibus and then the if_aue modules. If that works, you
should be ok.
I cannot test this as at the
My driver-floppy patch broke "make release" on current.jp.freebsd.org
(ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i3865.0-CURRENT-20001101-JPSNAP.log).
Of course "make boot.flp" works very well on my enviroment.
I'm debugging this problem, but it'll take hours and h
At Thu, 02 Nov 2000 10:34:03 +0900,
Tatsumi Hosokawa [EMAIL PROTECTED] wrote:
My driver-floppy patch broke "make release" on current.jp.freebsd.org
(ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i3865.0-CURRENT-20001101-JPSNAP.log).
Of course "make boot.flp" w
In message [EMAIL PROTECTED], Tatsumi Hosokawa さんいわく:
I moved PCI/PCCARD/USB if_xx.ko driver to mfsroot.flp, and I've got
100KB of free blocks in the first floppy. If we move more drivers to
mfsroot.flp or coming drivers.flp, we can get not only free blocks in
the first floppy, but
... are not liking each other after the lastest
ppp commits. I do not have time to look into this
until late tomorrow (and no, I don't see any commits
which would appear to fix this yet).
-John
crunchide -k _crunched_usbdevs_stub usbdevs.lo
cc -static -o boot_crunch boot_crunch.o sh.lo find.lo
Hi!
In "make release breakage" discussion, I said that I'll write a patch
to load kernel module from sysinstall to get more free space in the
first floppy. This is my implementation. I'll commit this patch to
-current if there's no objection.
I moved PCI/PCCARD/USB if_xx
Subject says it. I'll try to look at it later this evenning.
=== ipfilter
cc -O -pipe -DIPFILTER=1 -DIPFILTER_LKM -DIPFILTER_LOG -D_KERNEL -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
On Sat, Oct 28, 2000 at 01:54:52PM -0700, John W. De Boskey wrote:
/usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c:44:
@/netinet/ip_compat.h:268: osreldate.h: No such file or directory
*** Error code 1
This was fixed (two different ways) 2 days ago.
What rev of /sys/modules/Makefile
On Tue, 24 Oct 2000, Jordan Hubbard wrote:
Believe me, if we were to put out a serious call to kill NFS from the
installation boot images, you'd very quickly hear from all of those
people and they would be screaming. We need to exhaust all other
possibilities before we even contemplate that
At Wed, 25 Oct 2000 04:48:14 +0900,
Motomichi Matsuzaki [EMAIL PROTECTED] wrote:
I vote for 'remove NFS away'.
How about mergeing ifconfig kldload function into sysinstall, and move
/boot/kernel/if_xxx.ko into mfsroot.gz mfs image.
hosokawa
--
Tatsumi Hosokawa
[EMAIL PROTECTED]
At Wed, 25 Oct 2000 19:37:42 +0900,
Tatsumi Hosokawa [EMAIL PROTECTED] wrote:
How about mergeing ifconfig kldload function into sysinstall, and move
/boot/kernel/if_xxx.ko into mfsroot.gz mfs image.
or simply add,
main()
{
+ for ( i in /kernel/*.ko ) {
+ kdload(i);
+
Again. There is no public NFS servers for distributing FreeBSD as I know.
You can't get any FreeBSD, even if you sends NFS packets to the Internet.
Can I and anybody access your favorite NFS servers?
MIT, gatekeeper.dec.com, and Sunsite all run anonymous NFS
mountable archives.
Also, be
obrien I just diked out more bits. Lets see if that will give us
obrien enough space on tonights snapshot build.
Whole release procedures are works fine. Thank you. Here's summary of
current size of floppies (i386 architecture):
* boot.flp (639k left)
Filesystem 1K-blocks UsedAvail
At Wed, 25 Oct 2000 21:23:01 +0900,
[EMAIL PROTECTED] wrote:
From: "David O'Brien" [EMAIL PROTECTED]
Date: Tue, 24 Oct 2000 13:15:26 -0700
Before removing NFS, I'd remove the new `ncv', `nsp', and `stg' drivers.
Please do not remove them. Many people are waiting for them to switch
Other candidates I've been pointed to include the removal of
/boot/boot[12] and NFS
IMO NFS needs to stay. It is *very* useful to many (including me).
I vote for 'remove NFS away'.
Yes, there are many people using NFS install, but it is site-specific.
There are no services
Maybe kernel image for kern.flp is a little bit larger than a 1.44MB floppy.
***
linking BOOTMFS
textdata bss dec hex filename
2613503 196388 130744 2940635 2cdedb BOOTMFS
install -c -m 555 -o root -g wheel -fschg BOOTMFS /R/stage/kernels
mv /R/stage/kernels/BOOTMFS
The following patch brings the floppy size down enough to fix
the problem. One is a leftover from the config file syntax
change. Also, I don't know how useful INET6 is to a GENERIC
kernel on todays' networks (faith gif are already removed).
Index: dokern.sh
jwd Also, I don't know how useful INET6 is to a GENERIC kernel on
jwd todays' networks (faith gif are already removed).
It is mandatory for FreeBSD installation via IPv6 network (via network
devices; using gif(4) pseudo interface is a rare case, so it should be
removed). Please keep INET6
On Tue, Oct 24, 2000 at 09:51:32PM +0900, Makoto MATSUSHITA wrote:
It is mandatory for FreeBSD installation via IPv6 network (via network
devices; using gif(4) pseudo interface is a rare case, so it should be
removed). Please keep INET6 option as it is.
I agree with this sentiment.. please
will I'm sure there are better things to disable, like MFS, SYSV*,
will P1003_P1B and friends, and ICMP_BANDLIM.
MFS is required; don't forget we have mfsroot.flp :-)
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
On Tue, Oct 24, 2000 at 10:27:50PM +0900, Makoto MATSUSHITA wrote:
MFS is required; don't forget we have mfsroot.flp :-)
Oh yeah... time to drink some more caffeinated pop and wake up..
--
Will Andrews [EMAIL PROTECTED] - Physics Computer Network wench
To Unsubscribe: send mail to [EMAIL
will I'm sure there are better things to disable,
How about removing /boot/boot[12] from floppies ?
--- src/release/Makefile.oldMon Oct 23 23:53:50 2000
+++ src/release/MakefileTue Oct 24 22:38:15 2000
@@ -821,7 +821,7 @@
mv ${RD}/kernels/BOOTMFS
On Tue, 24 Oct 2000 08:15:12 -0500, Will Andrews [EMAIL PROTECTED] said:
I agree with this sentiment.. please leave INET6 support in the GENERIC
kernel. I'm sure there are better things to disable, like MFS, SYSV*,
P1003_P1B and friends, and ICMP_BANDLIM.
Um, let's only disable things that
On Tue, 24 Oct 2000 07:55:42 -0400
"John W. De Boskey" [EMAIL PROTECTED] said:
jwd The following patch brings the floppy size down enough to fix
jwd the problem. One is a leftover from the config file syntax
jwd change. Also, I don't know how useful INET6 is to a GENERIC
jwd kernel on todays'
Ok, folks want INET6. It's back..
It's been pointed out to me by "Thomas D. Dean"
[EMAIL PROTECTED] that the 'le' driver does
not work. Can someone provide additional information
about why it's in GENERIC?
Other candidates I've been pointed to include the removal
of /boot/boot[12] and NFS
In message [EMAIL PROTECTED] "John W. De Boskey" writes:
: The following patch brings the floppy size down enough to fix
: the problem. One is a leftover from the config file syntax
: change. Also, I don't know how useful INET6 is to a GENERIC
: kernel on todays' networks (faith gif are already
In message [EMAIL PROTECTED] "John W. De Boskey" writes:
: It's been pointed out to me by "Thomas D. Dean"
: [EMAIL PROTECTED] that the 'le' driver does
: not work. Can someone provide additional information
: about why it's in GENERIC?
Likely because it compiles and the devices are rare enough
On Tue, Oct 24, 2000 at 03:59:20PM +0900, Makoto MATSUSHITA wrote:
Maybe kernel image for kern.flp is a little bit larger than a 1.44MB floppy.
I just diked out more bits. Lets see if that will give us enough space
on tonights snapshot build.
--
-- David ([EMAIL PROTECTED])
To
On Tue, Oct 24, 2000 at 08:15:12AM -0500, Will Andrews wrote:
I'm sure there are better things to disable, like MFS, SYSV*, P1003_P1B
and friends, and ICMP_BANDLIM.
Only SYSVMSG is removed for the i386 case. SYS* for the Alpha. I'm
assuming the SYS* left compiled in on the i386 is for X?
On Tue, Oct 24, 2000 at 03:32:16PM +0200, John Hay wrote:
Why not remove NFS? That is what I do here when the snap floppy gets
too big. How many people install using NFS? (And can't easily change to
ftp.)
Many.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL
On Tue, Oct 24, 2000 at 10:44:31PM +0900, Makoto MATSUSHITA wrote:
How about removing /boot/boot[12] from floppies ?
Committed!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, Oct 24, 2000 at 12:43:16PM -0600, Warner Losh wrote:
apm is a good one to remove.
We used to, but we were trying to remove `apm0' from GENERIC. I've fixed
to just `apm'.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to
We used to, but we were trying to remove `apm0' from GENERIC. I've fixed
to just `apm'.
Might it be a good idea to make a INSTALL kernel config and a GENERIC
config? INSTALL goes on the floppies and has just enough for all the
different sorts of installations. GENERIC has almost LINT
Hi.
At Tue, 24 Oct 2000 12:15:09 -0700,
David O'Brien [EMAIL PROTECTED] wrote:
Other candidates I've been pointed to include the removal of
/boot/boot[12] and NFS
IMO NFS needs to stay. It is *very* useful to many (including me).
I vote for 'remove NFS away'.
Yes, there are many people
On Wed, Oct 25, 2000 at 04:48:14AM +0900, Motomichi Matsuzaki wrote:
Other candidates I've been pointed to include the removal of
/boot/boot[12] and NFS
IMO NFS needs to stay. It is *very* useful to many (including me).
I vote for 'remove NFS away'.
Yes, there are many people using
On Tue, Oct 24, 2000 at 09:42:54PM +0200, Rogier R. Mulhuijzen wrote:
We used to, but we were trying to remove `apm0' from GENERIC. I've fixed
to just `apm'.
Might it be a good idea to make a INSTALL kernel config and a GENERIC
config?
Nope, the two would be quickly out of sync. What
Before removing NFS, I'd remove the new `ncv', `nsp', and `stg' drivers.
Not to mention the `vpo' Parellel port Zip drive device.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On 24-Oct-00 David O'Brien wrote:
On Tue, Oct 24, 2000 at 09:42:54PM +0200, Rogier R. Mulhuijzen wrote:
We used to, but we were trying to remove `apm0' from GENERIC. I've fixed
to just `apm'.
Might it be a good idea to make a INSTALL kernel config and a GENERIC
config?
Nope, the two
At Tue, 24 Oct 2000 13:08:26 -0700,
David O'Brien [EMAIL PROTECTED] wrote:
I vote for 'remove NFS away'.
Yes, there are many people using NFS install, but it is site-specific.
And INET6 isn't site specific. It certainly is everywhere but maybe .jp.
I think INET6 is a grobal and public
will I'm sure there are better things to disable, like MFS, SYSV*,
will P1003_P1B and friends, and ICMP_BANDLIM.
MFS is required; don't forget we have mfsroot.flp :-)
The name is historical; we use md(4) not MFS.
--
... every activity meets with opposition, everyone who acts has his
- David O'Brien's Original Message -
On Tue, Oct 24, 2000 at 02:36:44PM -0400, John W. De Boskey wrote:
the 'le' driver does not work. Can someone provide additional
information about why it's in GENERIC?
Get confirmation that it does not work (one user isn't suffient in my
Only SYSVMSG is removed for the i386 case. SYS* for the Alpha. I'm
assuming the SYS* left compiled in on the i386 is for X?
That is correct. It's not mandatory, but it emits a scary-looking
error message when X starts up and a lot of folks were commenting
on it, so I put it (SYSVSHM) back
On Tue, Oct 24, 2000 at 02:36:44PM -0400, John W. De Boskey wrote:
Ok, folks want INET6. It's back..
It's been pointed out to me by "Thomas D. Dean"
[EMAIL PROTECTED] that the 'le' driver does
not work. Can someone provide additional information
That is correct. See kern/19219. I've
On Wed, Oct 25, 2000 at 04:48:14AM +0900, Motomichi Matsuzaki wrote:
Hi.
At Tue, 24 Oct 2000 12:15:09 -0700,
David O'Brien [EMAIL PROTECTED] wrote:
Other candidates I've been pointed to include the removal of
/boot/boot[12] and NFS
IMO NFS needs to stay. It is *very* useful to
On Tue, Oct 24, 2000 at 04:49:41PM -0400, John W. De Boskey wrote:
IMO NFS needs to stay. It is *very* useful to many (including me).
I haven't removed it. But it is an option. I was a very heavy
user of NFS, but it didn't matter to jkh when he removed it last
time. The switch to ftp
Again. There is no public NFS servers for distributing FreeBSD as I know.
You can't get any FreeBSD, even if you sends NFS packets to the Internet.
Can I and anybody access your favorite NFS servers?
I think this misses the point. Not everyone installs FreeBSD from
public servers and, in
[Why is -current on the cc line twice? One instance removed]
I haven't removed it. But it is an option. I was a very heavy
user of NFS, but it didn't matter to jkh when he removed it last
time. The switch to ftp isn't hard.
Well, that's not quite accurate. It did matter, it just seemed
At Wed, 25 Oct 2000 00:28:41 +0200,
Wilko Bulte [EMAIL PROTECTED] wrote:
IMO NFS needs to stay. It is *very* useful to many (including me).
I vote for 'remove NFS away'.
Yes, there are many people using NFS install, but it is site-specific.
The same argument goes for IPV6. In other
Believe me, if we were to put out a serious call to kill NFS from the
installation boot images, you'd very quickly hear from all of those
people and they would be screaming. We need to exhaust all other
possibilities before we even contemplate that option.
Are there maybe other large pieces
msmith The name is historical; we use md(4) not MFS.
I should read md(4) manpage... sorry.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Sigh,
In my attempt to make a cdrom to install 5.0-CURRENT-2818
I stumbled across a problem with the fixit floppy.
The /dev/MAKEDEV acd0 created 209 entries. The fixit floppy
only starts out with some 382. So the fixit floppy fails to be
properly populated with executables.
Tar does not
I had earlier written (to deafening silence) that I had
been unable to build a release from current. Buildworlds
worked OK, but make release didn't.
I have since figured out what was not working, but
this leads to another question. On my particular box,
I don't have a whole lot of room
Is it just me, or is make release broken?
I've been getting a bomb-out whilst making the boot crunch (in /bin/sh, I
think. Its at home, I'm not.) I haven't seen anybody kvetching (I *do* read
current...) Just to sanity check, I ran a 4.0 make release last night, that
worked just fine
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Is it just me, or is make release broken?
I've been getting a bomb-out whilst making the boot crunch (in /bin/sh, I
think. Its at home, I'm not.) I haven't seen anybody kvetching (I *do* read
current...) Just to sanity check, I ran
bsd.ports.mk don't have the version of new perl (5.006).
So, make release still broken.
chflags -R noschg /R/stage/trees
touch release.2
Making docs...
=== Extracting for docproj-1.1
No MD5 checksum file.
=== Patching for docproj-1.1
=== Configuring for docproj-1.1
=== Installing
make release is breaking in the crunch gen'ing:
gzip -cn /usr/src/release/sysinstall/sysinstall.8 sysinstall.8.gz
install -c -s -o root -g wheel -m 555 sysinstall /stand
install -c -o root -g wheel -m 444 sysinstall.8.gz /usr/share/man/man8
rm -rf /R/stage/crunch
mkdir -p /R/stage/crunch
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
You make it sound like a new thing - the release process has required
the vn device for years.
I would suggest that this driver be added to "GE
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
You make it sound like a new thing - the release process has required
the vn device for years.
Jordan,
Thanks for your time. I guess I need to rephrase m
In message [EMAIL PROTECTED], Mike Smith writes:
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
What do you mean "now"? It's _always_ been required.
I actually think you could still do
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
I would suggest that this driver be added to "GENERIC". For
what it's worth, I added the driver to my kernel, rebooted, and
completed the m
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
What do you mean "now"? It's _always_ been required.
I would suggest that this driver be added to "GENERIC". For
what it'
In [EMAIL PROTECTED] Mike Smith [EMAIL PROTECTED] wrote:
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
What do you mean "now"? It's _always_ been required.
I would suggest that th
Curious.
I've done several (say a dozen) make release builds in the last 4 months
of 4.0-CURRENT 5.0-CURRENT. The previous one was about 2 weeks ago.
I've never had "vn" in my kernel, nor had a problem. Maybe something
in the latest "loadable kernel modules" synchroniza
On Sun, May 07, 2000 at 07:15:56PM -0400, John W. DeBoskey wrote:
fyi...
=== Creating README.html for tkrat-1.2
=== mail/tkrat2
This belongs in [EMAIL PROTECTED], NOT [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
fyi...
=== Creating README.html for tkrat-1.2
=== mail/tkrat2
=== Creating README.html for tkrat-2.0b9
=== mail/wanderlust-emacs
Error: Bad value of EMACS_PORT_NAME: emacs.
Valid values are:
Emacs family: emacs19 mule19 emacs20
XEmacs family: xemacs19 xemacs20 xemacs21
"John W. DeBoskey" wrote:
fyi...
=== Creating README.html for tkrat-1.2
=== mail/tkrat2
=== Creating README.html for tkrat-2.0b9
=== mail/wanderlust-emacs
Error: Bad value of EMACS_PORT_NAME: emacs.
Valid values are:
Emacs family: emacs19 mule19 emacs20
XEmacs
Hello,
make release fails with the following diagnosis:
=== bin/csh/nls
=== bin/csh/nls/finnish
install -c -o root -g wheel -m 444 tcsh.cat
/R/stage/trees/bin/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat
*** Error code 71
--
Best regards,
Ilya mailto:[EMAIL
201 - 300 of 436 matches
Mail list logo
