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
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.
-- -
Makoto `MAR' Matsushita
To
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
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).
They are built and linked statically. This is not possible with
crunch_gen?
To Unsubscribe: send
On Tue, Feb 26, 2002 at 05:30:50AM -0800, [EMAIL PROTECTED] wrote:
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
Current 5-current fails 'make release' when processing release.4
target (making a crunch binary). Here's sample session:
=== doc
rm -f cpio.info cpio.info.gz
rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH
/usr/obj/usr/src/gnu/usr.bin/cpio/GRTAGS
Ouch.
matusita src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target.
Of course that's normal, dhclient_clean target should be created by crunchgen.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the
At 01:27 PM 2/25/2002 +0900, Makoto Matsushita wrote:
Current 5-current fails 'make release' when processing release.4
target (making a crunch binary). Here's sample session:
=== doc
rm -f cpio.info cpio.info.gz
rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH
null After the cvs checkout completes:
Ah, big sorry... I just fixed in src/release/Makefile rev 1.658.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
With 5-current as of Dec/04/2001 15:00:00 GMT.
It seems that this is because 'WARNS=0' line is inside of
!defined(RELEASE_CRUNCH) clause. IMO, if an application's code
requires to set 'WARNS=0 for build, it should also be set when
building as a part of a crunched binary.
-- -
Makoto `MAR'
Makoto Matsushita [EMAIL PROTECTED] writes:
With 5-current as of Dec/04/2001 15:00:00 GMT.
It seems that this is because 'WARNS=0' line is inside of
!defined(RELEASE_CRUNCH) clause. IMO, if an application's code
requires to set 'WARNS=0 for build, it should also be set when
building as a
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
successfly finished this
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 understood the situation.
matusita However, this problem (use /usr/src/sys/modules for compilation) is
matusita disappeared already according to the logfile of Nov/02/2000.
Hmm, sorry, it is not yet fixed.
cd ../../modules env MAKEOBJDIRPREFIX=/usr/src/sys/compile/BOOTMFS/modules KMODIR=
make obj all
=== 3dfx
===
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 hours because
testing
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" works very well on my
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
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
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
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
Ilya Naumov wrote:
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
I just finished one a couple of hours ago
My make releases here keep falling over...
=== gnu/usr.bin/binutils/doc
=== gnu/usr.bin/binutils/gdb
Making init.c
yacc -o c-exp.c /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/c-exp.y
yacc -o f-exp.c /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/f-exp.y
yacc: 4
67 matches
Mail list logo