obrien> A while back I moved the install location for chown and chgrp
obrien> from /usr/sbin and /usr/bin to /sbin and /bin. This was
obrien> because of MAKEDEV(8)'s dependence on them, and thus forced
obrien> /usr to be mounted for correct operation of MAKEDEV(8).
But MAKEDEV(8) still depends
msmith> A release build requires a complete "make buildworld" of the
msmith> relevant world to have been completed before starting.
Not "make buildworld" but "make installworld" ? In anyway, "make
distrib-dirs distribution" depends on some tools (not only mknod), and
it's no way to install thes
msmith> No. I said "make buildworld".
Ah, sorry, I must say "make installworld in the process of make release".
msmith> The chroot area is populated via "make installworld" from the
msmith> abovementioned buildworld. The mknod that is then used to
msmith> build device nodes is the one inside
If you are NOT an US resident, and try to use FreeBSD 4.0-RELEASE
which was built with the source code of cvsup.internat.freebsd.org
(which is not available at ftp.freebsd.org 'cause it's in US), try:
ftp://current.jp.FreeBSD.org/pub/FreeBSD/releases/i386/4.0-RELEASE/>
This release is build at
I don't know how many people is thinking about release procedure, but
please give me some notes... with this change, we cannot do 'make
release' -current in a -stable environment (and vice versa, maybe).
Reason:
In a 'make release', all building procedures are done in a
chroot-ed
Preamble: 5-current CVSuped Jun/15/2000 04:00 JST from cvsup.jp.FreeBSD.org
Rebuild my kernel and reboot, then I've got following message:
Jul 16 00:48:32 martini /kernel: mfs_badop[vop_getwritemount]
Jul 16 00:48:32 martini /kernel: mfs_badop[vop_getwritemount] = 45
I'm using MFS as /tmp file
sheldonh> Have you sent your patch to Kirk McKusick <[EMAIL PROTECTED]>?
No, not yet. It seems that this change is incoroprated with FFS
snapshots feature, but I cannot decide it's true or not; other
filesystem are modified also (see commitlogs), but mfs is not changed...
Anyway, I'll try to em
I've already introduced before (last Auguest), but here it is again;
we have updated our service host and add some services.
current.jp.freebsd.org (CAUTION: not 'current.freebsd.org') is a yet
another daily SNAPSHOTs service host. Service contents are almost the
same of current.freebsd.org (pro
I've sent before that current.jp.FreeBSD.org provides 4.0-RELEASE
distribution with international CVS repository (at that time).
Now we are in the post 4.1-RELEASE age. It should be changed.
***
If you are NOT an US resident, and try to use FreeBSD 4.1-RELEASE
which was built with 'RSA_RESIDEN
freebsd> I suppose I could volunteer for this.
It would be great, but current /boot/loader has also the fancy
feature, tty screen handling (see /usr/share/examples/bootforth if you
have never seen before). I heavily depend on this feature for the
selection menu of boot kernel using a sample men
> Problems include "incomplete" cross tool building, header files, and
> of course, device support, in particular differences between the
> "old" vn stuff, and the new "md" device.
kris> I build worlds in a jail populated with the target release so there's
kris> no problems with this.
That's tr
kris> Yeah, like I said, you can do this in a jail under 5.0.
Yes, but your kernel should have 'vn' device driver which is already
deprecated in recent 5-current. Without vn, 4-stable build (make a
release) will fail when vnconfig(8) does its job for boot floppies.
Of course, we can fake vncon
This patch is the same of PR: bin/31009. I try to send to this list
for wider audience to check my patch.
***
Current 5-current sysinstall has a bug; when you want to install
FreeBSD to a fresh PC, and you try to make a partition except 'a'
(for example, 'ad0s1e'), sysinstall fails to do newfs
Again, 'disk full' problem is already disappeard in recent
5-current. But:
dsyphers> DEBUG: kget: error buffer sizing
This is because sysinstall still want to get userconfig data and put
the result to /boot/kernel.conf.
dsyphers> [: : out of range
dsyphers> [: : out of range
dsyphers> acd0t
dsyphers> DEBUG: kget: error buffer sizing
matusita> This is because sysinstall still want to get userconfig data
matusita> and put the result to /boot/kernel.conf.
Userconfig was gone in 5-current, so we can safely remove kget() from
sysinstall. Attached below is a patch to do (kget.c should b
obrien> Ok, who (and what) broke the kernel build?
If you met at modules/an, I've fixed with src/sys/modules/an/Makefile
rev 1.6. Sorry if your point is different.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
nelsont> I had to toss my 2001 snapshot because it still had
nelsont> the /mnt/dev sysinstall problem which was apparently
nelsont> fixed as of 2002. It isn't.
I'll try to investigate tomorrow (strictly speaking, 'late today in
JST'; I'm sleepy), but according to my intuitio
imp> Right. There is a forth tool available (authored I think by
imp> matsushita-san),
I never do that :-) Maybe the one you mentioned is by yokota-san,
http://people.freebsd.org/~yokota/vuserconfig.tar.gz>.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "un
jhb> Not sure what this is all about. /etc/fstab should exist in
jhb> theory. Actually, it might not exist yet.
/etc/fstab should *not* exist since /etc is in mfsroot.flp. If there
is /etc/fstab which is match your disk configulation, that's magic :-)
jhb> During an install w/o using existin
jhb> Err, well, when we run fsck on an existing partition, we
jhb> shouldn't say 'fsck /dev/ad0s1a', we should use 'fsck_ffs
jhb> /dev/ad0s1a'. Does that make sense now? We shouldn't be calling
jhb> fsck_4.2bsd for these filesystems because they aren't 4.2BSD file
jhb> systems per se, they are
matusita> Maybe we can try to put mount_devfs and mount devfs to /mnt/dev.
Moreover, sysinstall requires devfs on /mnt/dev only if trying to
mount filesystems. I've made a patch to do that (and more), and test
now (yes, *right now*).
If it seems fine for me, I'll post a patch. Current my patc
matusita> If it seems fine for me, I'll post a patch.
OK, a patch is attached below.
I've also made boot floppies (use 5-current code as of Nov/21/2001)
for anyone who try to find out that this problem is gone away.
http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/boot.
In /etc/rc, there is a "swapfile" feature, to configure a file to use
swap device. Here is a script for that.
# Add additional swapfile, if configured.
#
case ${swapfile} in
[Nn][Oo] | '')
;;
*)
if [ -w "${swapfile}" -a -c /dev/mdctl ]; then
echo "Adding ${swapf
matusita> OK, a patch is attached below.
Sorry, forget to add the patch... try again.
If anybody test with boot floppies, available at
http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/,
please let me know your results.
-- -
Makoto `MAR' Matsushita
Index: install.c
jkh> Looks good to me, I'd say commit it!
Thanks! I'll commit it in this weekend.
BTW, how dou you think my other patch (use 'devfs' while mounting
filesystems, use fsck_ffs instead of fsck) for sysinstall, which was
posted about a week before to [EMAIL PROTECTED]? You can fetch from:
http:/
I've posted (old version of) this patch before at cvs-committers, but
[EMAIL PROTECTED] is more appropriate list so I post a new version
of patch here.
***
Attached below is a patch to make more kernel-modularize installation
flopppies.
- Why need this?
Because we have very few space
I tried to install latest 5-current via ftp. However, when sysinstall
fetches all bin distribution, following dialog (sorry, I've forget to
copy a screenshot) is shown:
User Confirmation Requested
Unable to transfer the bin distribution from ...
Do you want to try to ret
Sorry for late reply.
jkh> Don't you want to try the devfs mount and only copy device files
jkh> if that returns an error code?
Hmm, it seems better to me. I'll try it again... I find that more
error handling is required if mounting devfs is failed.
-- -
Makoto `MAR' Matsushita
To Unsubscri
jkh> Don't you want to try the devfs mount and only copy device files
jkh> if that returns an error code?
How 'bout this patch (attached below)? I've recreate boot floppies
with this patch, then put them to:
http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/
-- -
Makoto
With the 5-current source as of Dec/02/2001 15:00 GMT.
-- -
Makoto `MAR' Matsushita
(cd /usr/src/usr.bin/telnet && make -DRELEASE_CRUNCH depend && make -DRELEASE_CRUNCH
commands.o main.o network.o ring.o sys_bsd.o telnet.o terminal.o utilities.o genget.o
getent.o misc.o)
rm -f .depend
mkd
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' Mat
coolvibe> What header file defines SWI_NOSWITCH?
http://snapshots.jp.freebsd.org/tour/current/cgi-bin/global.cgi?pattern=SWI_NOSWITCH&id=&type=symbol
SWI_NOSWITCH are used and/or defined by these files. You can easily
find that this list have only one *.h file -- sys/sys/interrupt.h.
% grep S
This error is occured when "make release" try to roll 'bin' distribution.
jhay> Make release of -current has been broken here for the past few
jhay> days. I had a look on the Japanese snapshot site and theirs
jhay> break with the same error. Do anybody have an idea about what
jhay> is going wro
jhay> The last one that worked here was on 20020108. The one on the
jhay> next day broke. The release builds are started from cron at
jhay> midnight SAST which is 2 hours ahead of UTC.
FYI: 5.0-CURRENT-20020113-JPSNAP builds goes fine here. I dunno what
change fixes this :-)
-- -
Makoto `MAR'
FYI: pam_setcred() call seems used in OpenSSH, ftpd, rshd, login, and su
already included in FreeBSD source code.
http://snapshots.jp.freebsd.org/tour/current/cgi-bin/global.cgi?pattern=pam_setcred&id=&type=reference>
imp> OK. This looks like a problem in 1.6.4p1 of sudo. It isn't a problem
i
I found that acd, ATAPI CD device, doesn't listed up to 'kern.disks'
kernel MIB which should list all disks in the running system.
Here is a sample:
ringo % sysctl kern.disks
kern.disks: ad0
ringo % grep acd /var/run/dmesg.boot
acd0: CDROM at ata1-master PIO4
ringo %
I've investigated that th
rwatson> If someone has a commercial license, it would make sense
rwatson> submitting this via a trouble ticket, as well as providing
rwatson> the VMware support people with some brief directions on
rwatson> installing 5.0.
I've just filed an incident (I have a license of VMware 3.0).
-- -
Mako
matusita> I've just filed an incident (I have a license of VMware 3.0).
I've received a reply from VMware:
> Thank you for submitting the incident and letting us know the
> potential workaround.
> I must apologize because we do not support FreeBSD 5.0 as a guest OS
> yet in Workstation 3.
ggombert> VMware tools for FreeBSD is woefully out of date as well,
Really?
% cd /usr/ports/emulators/vmware-tools
% make -V PORTVERSION
3.0.0.1455
VMware 3.0 bundles a new VMware tools, and it is up-to-date version as
of Linux guests.
% cd /usr/ports/emulators/vmware-tools
% make -V MAINTAIN
> I know this is probably offtopic but is there any problem with
> current.freebsd.org at the moment?
Hmm...
galtvalion % ftp current.freebsd.org
Connected to usw2.freebsd.org.
220 usw2.freebsd.org FTP server (Version 6.00LS) ready.
Name (current.freebsd.org:matusita): ftp
331 Guest login ok, s
will> Jordan announced recently that Qwest is upgrading the hardware
will> and that there would be intermittent problems with the server for
will> a certain period (a few days as I recall).
It would be:
> From: Jordan Hubbard <[EMAIL PROTECTED]>
> Subject: stable.freebsd.org AKA releng4.freebsd
will> Jordan announced recently that Qwest is upgrading the hardware
will> and that there would be intermittent problems with the server for
will> a certain period (a few days as I recall).
It would be:
> From: Jordan Hubbard <[EMAIL PROTECTED]>
> Subject: stable.freebsd.org AKA releng4.freebsd
> I know this is probably offtopic but is there any problem with
> current.freebsd.org at the moment?
Hmm...
galtvalion % ftp current.freebsd.org
Connected to usw2.freebsd.org.
220 usw2.freebsd.org FTP server (Version 6.00LS) ready.
Name (current.freebsd.org:matusita): ftp
331 Guest login ok, s
Sorry if you have seen before.
I've found that current 5-current is broken, since krb5 cannot compile.
Here is a typical compiler message:
In file included from
/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5_locl.h:142,
from
/usr/src/kerberos5/lib/libg
kuriyama> In my environment, buildworld was finished with attached
kuriyama> patch. I don't know KRB4 should be defined in this file or
kuriyama> not.
Sorry I should say when building of krb5 is failed; make buildworld
seems OK, but 'make release' will fail during 'release.2'
target; there is n
jhay> A, maybe this will also fix "make release". It has been
jhay> dying in the kerberos area the last few days.
Unfortunately, it does NOT fix "make release" breakage (already
reported by kuriyama-san). I've checked why, and make a patch to fix this.
--- src/kerberos5/lib/libgssapi/Makefi
I've found that current libcrypto/Makefile is not parallel make(1)
unfriendly, since it creates a temporary file to as(1). Followings are
sample session log with "make buildworld -j2":
perl
-I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/des/asm:/usr/src/secure/lib/libcrypto/../.
kris> We really need to provide a better rc.conf hook for doing this --
kris> expecting people to write their own script just to create a /tmp
kris> is lame.
Here is just an example script (CAUTION: not well-tested) to create a
filesystem/swap with mdconfig(8). This script support not only '/tmp
I've sent an email to [EMAIL PROTECTED], a maintainer of lnc ethernet
driver, to fix the module name of lnc almost two weeks before.
However, he maybe too busy working, there is no response from him. Are
there any committers to check my patch and fix the driver?
-- -
Makoto MATSUSHITA
Summary:
Our strptime(3) format string '%A' does not conform to Single UNIX
Specification v2, Solaris2, NetBSD, and maybe other implementation.
This comes from the changes of src/lib/libc/stdtime/strptime.c rev
1.13, which is commited by ache. Backout this changes (and apply to
4-stable) should f
ache> Fix already commited in -current strptime.c v1.23 and not yet in
ache> -stable.
Very glad to hear that, thank you.
We are in a freeze stage, but are there any chances to merge this into
4-stable... ah, maybe I'm dreamin' :-)
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMA
lib/libcrypt/crypt-blowfish.c
Have you update (or checkout) your src/secure, or which CVSup server you use?
-- -
Makoto MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kris> I believe Mark's intention was to keep crypt-blowfish.c optional for
kris> those who don't want to install crypto. Perhaps this is broken.
src/lib/libcrypt/Makefile says:
# Pull in the crypt-des.c source, assuming it is present.
.if exists(${.CURDIR}/../../secure/lib/libcrypt/crypt-des.c
of listen(2) should be '10'
which is defined statically. You can change with 'DaemonPortOptions'
option (see /usr/share/doc/smm/08.sendmailop/paper.ascii.gz), IIRC.
***
Speaking of tweaking SOMAXCONN value in kernel config file, why
/etc/sysctl.conf is not enough to do?
--
larse> I'd like to try -current on a few machines. Is there a recent
larse> snapshot available as an ISO image somewhere? It'd be much
larse> faster than cvsup'ing and making world.
ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386/ISO-IMAGES/>
It's not the same of current.FreeBSD.org's d
jkh> No, since I don't do release engineering that way, but someone else
jkh> should certainly feel free to do this. :)
Speaking about current.jp.FreeBSD.org...
I wrote shell/perl-scripts to do some job, and shifted the release
engineering responsibility onto cron(8) :-)
You can fetch from mos
There is a small typo in src/release/Makefile rev 1.161; not 'kernel',
but 'KERNEL' is correct.
-- -
Makoto `MAR' MATSUSHITA
--- Makefile.dist Mon Apr 16 10:02:01 2001
+++ MakefileMon Apr 16 10:02:52 2001
@@ -847,7 +847,7 @@
make KERNEL=${KERNEL} DESTDIR=${RD}/
I've tried to use (bootable) CD-ROM as root filesystem (I want have
this because it's good alternative of fixit.flp), but it seems that
GENERIC kernel doesn't understand where is root filesystem.
What I did are:
- make a 2.88MB boot floppy image, which contains:
* GENERIC kernel (gzippe
matusita> There is a small typo in src/release/Makefile rev 1.161; not '
matusita> kernel', but 'KERNEL' is correct.
Because of this, Current "make release" of 5-current is broken:
===> wi
install -c -o root -g wheel -m 555 -fschg if_wi.ko /R/stage/kernels/GENERIC
make KERNEL= DESTDIR=/R/stag
obrien> I think I got all these already. But I rev 1.161 is from back in 1995.
obrien> Are you sure you've got the right /usr/src/release/Makefile?
Oops it should be '1.611'.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
quinot> Formatting page, please wait...mdoc error: end-macro (.em) respecification is
not allowed. (#41)
quinot> Should this have been `.Em ...'?
quinot> User Abort.
Same here.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the mes
Oops... my fingers behave badly.
quinot> Formatting page, please wait...mdoc error: end-macro (.em) respecification is
not allowed. (#41)
quinot> Should this have been `.Em ...'?
quinot> User Abort.
Same here.
% zcat /usr/share/man/man1/ls.1.gz | nroff -mandoc |& head -2
mdoc erro
ru> cd /usr/src/gnu/usr.bin/groff/tmac && make cleandir obj && make all install
quinot> It works here, thanks!
It works also here. Thanks!
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ru> I always thought that ``obj'', ``all'' and ``install'' should be
ru> executed in sequence, not together. Hey, this even does not work
ru> for bin/cat:
IIRC, it is assumed that "make -jX install (where X > 1)" _doesn't_ work.
I've heard why, but I've forgotten :-)
-- -
Makoto `MAR' MATSUSHI
takhus> Perhaps the *.TXT files could be periodically regenerated to their
takhus> current location to 1) avoid a POLA violation and 2) allow for at
takhus> least some RELNOTES without needing DocBook and doc/ (even if they
takhus> may be slightly out of date).
I second this.
It is true that c
Sorry for late reply.
bmah> My first reaction is, "is doing doc.1 *that* much of a problem"? When
bmah> I was testing, it didn't seem like building this consumed much time or
bmah> disk space compared to the rest of the make release process (i.e.
bmah> building world and several kernels). A
tlambert2> Examples abound:
All of examples are just "we want yet another *generic* kernel for
specific machines".
Why you don't replace src/sys/${arch}/conf/GENERIC file to your own
(customized) version? It is too simple, and matches your requirements.
-- -
Makoto `MAR' MATSUSHITA
To Unsubsc
I've send a email before about this[1], but a situation is not changed
until now. My friends does confirm the situation recently[2], so I
send a email again...
***
It seems that recent (as of May/2001) 5-current kernel cannot mount
CD9660 filesystem (usually CD-ROM) as a root filesystem. The ke
Forge to mention that all tests are done with Intel PCs.
matusita> P.S.: A procedure to make a CD-ROM itself is shown in my previous email[1].
If you wanna get CD-ROM image to reproduce this with your PC, fetch
ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386/ISO-IMAGES/live-current.iso>
mi> Heh. That was a feature request only. I don't even know the details of
mi> NFS, much less SMB. Sorry,
Since amd is not FreeBSD specfic product, how 'bout sending your
request to the am-utils developers?
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "uns
jedgar> Commenting hints.psm.0.* and hint.atkbd.0.* from /boot/device.hints
jedgar> (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=84052+0+current/freebsd-current)
jedgar> works here.
I have similar problem; 'ata' bus is detected twice.
We jp.FreeBSD.org have donated TrustGuard iSV, which is 13
matusita> I have similar problem; 'ata' bus is detected twice.
I've just updated to 5-current as of yesterday (yeh!), but no helps.
'ata' driver detects the second devices which is _not_ on this machine.
Attached below is a full and verbose dmesg output. Most part of
kernel configulation is as
Forget to mention that:
matusita> I've just updated to 5-current as of yesterday (yeh!), but
matusita> no helps. 'ata' driver detects the second devices which is
matusita> _not_ on this machine.
Since the kernel detects ata1 which eats IRQ 15, the kernel fail to
attach the first fxp device (wh
tacho> lock order reversal
tacho> 1st 0xc03f0140 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007
tacho> 2nd 0xcaec972c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016
Exactly the same kernel message was here. Revision ID is:
galtvalion % grep FreeBSD: src/sys/ufs/ffs/ffs_vnops.c
ff
ck.c:239
***
Revision ID of these files are:
% cd /usr/src/sys; grep FreeBSD: vm/vm_glue.c kern/kern_lock.c
vm/vm_glue.c: * $FreeBSD: src/sys/vm/vm_glue.c,v 1.114 2001/05/23 22:35:45 jhb Exp $
kern/kern_lock.c: * $FreeBSD: src/sys/kern/kern_lock.c,v 1.46 2001/04/28 12:11:01
alfred Exp $
-- -
Makoto MATSUS
mark> This looks right to me. One main PIIX4 ATA controller with two
mark> independent IDE channels (usually referred to as a Primary and a
mark> Secondary IDE controller). Usually the PC BIOS will allow you to
mark> turn on/off these channels independently. Does your bios allow
mark> you to turn
sos> Thats because of the runtime attach/detach code in current, if the
sos> channel HW is there, its attached so you can add a device later
sos> with atacontrol without having to boot. In -stable the channel is
sos> not attached if no devices are present at probe time.
Thanks for your clear ex
sos> Well, sortof, the ata driver doesn't allow for sharing irq14&15
sos> since lots of boards doesn't work that way. However if you need
sos> it you can try to add the shared flag in the driver and see if
sos> it works on yours.
I've changed src/sys/dev/ata/ata-pci.c with:
--- ata-pci.c.dist
jhb> Can you turn on WITNESS_DDB in your kenrel config file (or set
jhb> the debug.witness_ddb loader tunable/sysctl before you get this
jhb> reversal) and get a backtrace from ddb?
Yes; I turned 'debug.witness_ddb' on now. I'll send a ddb 'trace'
output if next time lock-order-reversal is happe
tacho> lock order reversal
tacho> 1st 0xc03f0140 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007
tacho> 2nd 0xcaec972c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016
matusita> Exactly the same kernel message was here.
ddb trace output is as follows.
db> trace
Debugger(c02bd5ae) a
matusita> lock order reversal
matusita> 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
matusita> 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
I've caught tracelog of this reversal, with debug.witness_ddb=1.
Here's console log:
lock order reversal
1st 0xc5e3cfdc process
sos> Well, sortof, the ata driver doesn't allow for sharing irq14&15
sos> since lots of boards doesn't work that way. However if you need
sos> it you can try to add the shared flag in the driver and see if
sos> it works on yours. Hmm, maybe I should make this tunable...
It this patch OK? I've
wosch> What happens? Is -current now so unstable that we cannot make a
wosch> snapshot anymore?
current.jp.FreeBSD.org is for you until current.freebsd.org is back
again; it's not a *mirror*, but has almost same features.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECT
After importing a new cvs (located at src/gnu/usr.bin/cvs),
src/gnu/usr.bin/Makefile was modified not to compile cvs, since cvs is
temporary broken for bulid.
However, there is yet another makefile which builds cvs also --
src/kerberosIV/Makefile. Since this file is left unchanged, we cannot
bui
wosch> the 5.0-current snapshots on current.jp.freebsd.org are not updated
wosch> since 3-Aug-2001. What happens?
Really?
lrwxr-xr-x 1 root ftp 27 Aug 10 17:19 5-LATEST -> 5.0-CURRENT-20010810-JPSNAP
The last successfully finished release should be Aug/10/2001.
Current 5-current release i
wosch> Sorry, my fault.
Never mind :-)
wosch> Nevertheless, current sucks. No successfully builds since 9 days ;-{{
I've checked the original CVS code. It seems that
http://ccvs.cvshome.org/source/browse/ccvs/src/client.c.diff?r1=1.302&r2=1.303>
will fix our problem (sorry I don't test it).
IIRC, the only file that uses USA_RESIDENT is src/secure/lib/Makefile,
and now it is gone away. Does this change imply that we are free from
defining USA_RESIDENT when building the FreeBSD world ?
Moreover, can we also throw USA_RESIDENT variable away from ports ?
-- -
Makoto `MAR' MATSUSHITA
tanimura> You still need host.conf to run old binaries (including Netscape)
tanimura> linked against libc.so.3 and earlier. I prefer to warn 'host.conf is
tanimura> for compatibility with old libc.'
Is there any chance that compat1x, compat2*, compat3x includes
/etc/host.conf for backward compat
I'm an administrator of current.jp.FreeBSD.org, yet another snapshots
services in Japan. Now I'm going to make a bootable FreeBSD
installation CD which contains FreeBSD 3-stable, 4-stable and -current
(namely, 'triplex CD-ROM'). Maybe it's useful for installation events
at BUGs (BSD Users Groups
jkh> Thanks for reminding me to go look at that code - you're right,
jkh> the check is incorrectly done and insufficiently general. Fixed
jkh> in -current and -stable!
Very glad to hear that... thank you. Today is Wednesday and 3-stable
build will run at current.jp.FreeBSD.org. If it goes succe
Here is a status report of this PR. To announce more wider audiences,
this mail is also sent to [EMAIL PROTECTED]
* This PR keeps all committers away. No lucks.
* If you want to install 5.0-CURRENT to a *fresh* PC, you'll be warned
that your PC cannot find the kernel location.
-- -
Makoto `M
jkh> Done and fixed, thanks!
Wow, thank you ^_^
But.. maybe my PR is not clearly described, it does not fix current
situation; very sorry for my poor presentations.
Here is a current directory structure (just extracted tarballs) of
5-current as of Sep/29/2000.
% cd ~ftp/pub/FreeBSD/snapshots/
jkh> there should be a boot/kernel/kernel.ko file and I'm not sure why
jkh> there isn't.
This is because 'release.3' target (in src/release/Makefile) does not
know that the kernel should go to into ${RD}/trees/bin/boot/kernel.
Note that we cannot change 'doKERNEL' target, which is also used by
o
brian> I recently added the directory /usr/include/netnatm/ to
brian> BSD.include.dist, and the ppp build now depends on this.
Would you please add netnatm to 'LDIRS' definition of src/include/Makefile ?
Without this, "make buildworld" fails just like this, since no header
file in src/sys/netn
../../dev/bktr/bktr_os.c: In function `bktr_detach':
../../dev/bktr/bktr_os.c:484: `unit' undeclared (first use in this function)
../../dev/bktr/bktr_os.c:484: (Each undeclared identifier is reported only once
../../dev/bktr/bktr_os.c:484: for each function it appears in.)
More logfile:
http://
jkh> I'll look into this tomorrow morning, thanks.
I'm very interested if current.jp.freebsd.org was hung up when "make
release" procedure was running. current.jp.freebsd.org was hung up in
these two days, when making a boot floppy (the hungup was occured
*exactly* the same point).
-- -
Makoto
kana> I have same experience.My current-box was hung up when "make release".
kana> then, log is below:
Ya, exactly the same point of current.jp.FreeBSD.org. The same story
should be applied to current.FreeBSD.org. We cannot make a -current
distribution now. Changes from Oct/10/2000 to now cause
jhay> For now I just went back to an older kernel that works for me.
Would you please explain "an older kernel" ? I'm using a kernel as of
Sep/30/2000 and it panics.
***
Note that this (Sep/30/2000) kernel doesn't panic until Oct/13/2000.
Between Oct/14/2000 and Oct/17/2000, "make release" was
jhay> Not that old. 2000-10-05.
Hmm. I'll try it later, thank you.
***
I've tried with a kernel as of Oct/07/2000, kernel also panics.
However, panic point is different:
mfsroot: 71.5% <<-- THE POINT OF LAST HUNGUP
disklabel: ioctl DIOCWLABEL: Operation not su
>From
>http://current.jp.FreeBSD.org/build/i386/LINT/5.0-CURRENT-20001021-JPSNAP.bad>:
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-nostdinc -I- -I. -I../.. -I../../../include -DGP
1 - 100 of 218 matches
Mail list logo
