make release failure
make release fails on "make world" with: + make world -- >>> elf make world started on Tue Jan 25 18:53:25 GMT 2000 -- !! >>> You must define the value of USA_RESIDENT as 'YES' or >>> 'NO' as appropriate, in the environment or /etc/make.conf >>> before building can proceed. !! *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src/release. The problem is that $CHROOTDIR/etc/make.conf is never created by make release. What am I missing? Thanks, Rajappa -- <[EMAIL PROTECTED]> a.k.a. Rajappa Iyer. New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release failure
Bruce Burden <[EMAIL PROTECTED]> writes:
> >
> > make release fails on "make world" with:
> >
> > !!
> > >>> You must define the value of USA_RESIDENT as 'YES' or
> > >>> 'NO' as appropriate, in the environment or /etc/make.conf
> > >>> before building can proceed.
> > !!
> >
> > The problem is that $CHROOTDIR/etc/make.conf is never created by make
> > release. What am I missing?
> >
> /etc files are never installed by "make installworld". You
>have to install these files yourself, or use something like
>mergemaster(8).
>
> make.conf in found in /usr/src/etc/etc.[i386,alpha]/make.conf
Yes, but $CHROOTDIR/etc is populated by "make installworld" when I do
a "make release". My ``real'' /etc/make.conf exists and has the
appropriate value for USA_RESIDENT.
I see that /usr/src/release/Makefile does copy /etc/resolv.conf to
${CHROOTDIR}/etc. Maybe it should do the same for /etc/make.conf.
What do people think of the following patch?
Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.530
diff -c -r1.530 Makefile
*** Makefile2000/01/24 01:22:30 1.530
--- Makefile2000/01/25 20:52:53
***
*** 37,42
--- 37,46
# Unless set elsewhere, indicate the object format we'll be using.
OBJFORMAT?= elf
+ # make world needs make.conf which make installworld will not install
+ # in ${CHROOTDIR}/etc.
+ MAKECONF?=/etc/make.conf
+
# Uncomment this to disable the doc.1 target. It is also an ERROR
# to set NOPORTS and not set NODOC since docs depend on ports.
#NODOC= YES
***
*** 155,160
--- 159,167
cd ${.CURDIR}/../etc && ${MAKE} distribution DESTDIR=${CHROOTDIR}
if [ -f /etc/resolv.conf ]; then \
cp -p /etc/resolv.conf ${CHROOTDIR}/etc; \
+ fi
+ if [ -f ${MAKECONF} ]; then \
+ cp -p ${MAKECONF} ${CHROOTDIR}/etc; \
fi
cd ${.CURDIR}/.. && ${MAKE} installworld DESTDIR=${CHROOTDIR} NOMAN=1
mkdir ${CHROOTDIR}/${BOOTSTRAPDIR}
Thanks,
Rajappa
--
<[EMAIL PROTECTED]> a.k.a. Rajappa Iyer. New York, New York.
We're too busy mopping the floor to turn off the faucet.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make release failure
"David O'Brien" <[EMAIL PROTECTED]> writes: > On Tue, Jan 25, 2000 at 03:54:13PM -0500, Rajappa Iyer wrote: > > Yes, but $CHROOTDIR/etc is populated by "make installworld" when I do > > Why not just set USA_RESIDENT in your environment before starting > `make release'? That's certainly possible, although it might be a good idea to use a variable to point to a make.conf file. This way "make release" does not have to be too aware of what "make world" requires in /etc/make.conf. Failing that, perhaps /usr/src/release/Makefile could check for USA_RESIDENT early on to save checkouts of src, ports and docs. Rajappa -- <[EMAIL PROTECTED]> a.k.a. Rajappa Iyer. New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
chown/chgrp location and MAKEDEV
Sorry if this has been discussed before, but I couldn't find anything relevant in the mail archives. /dev/MAKEDEV contains references to chown and chgrp which are in /usr/sbin. This makes it impossible to run MAKEDEV when the /usr fs is not available. I had recent occasion when I had to execute MAKEDEV before /usr could be mounted---in fact, I had to execute MAKEDEV so that /usr could be mounted on the disk whose LUN id had changed to something for which there were no entries in /dev. Yes, I know that I should have run MAKEDEV before changing the id on the disk, but I do feel one should be able run MAKEDEV without needing to have /usr mounted. Shouldn't chown and chgrp be in /sbin? Thanks, Rajappa -- <[EMAIL PROTECTED]> a.k.a. Rajappa Iyer.New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current Uncompilable?
Adam Strohl <[EMAIL PROTECTED]> writes: > I just rebuilt from a system that was pre-sig update (cvsuped an hour or > so ago) and everything worked perfectly. > > I did however build, install, and boot a new kernel before doing a make > world. I had the same problem, but only with make -j8 world. Plain "make world" worked fine for me. Rajappa -- <[EMAIL PROTECTED]> a.k.a. Rajappa Iyer.New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
John Polstra <[EMAIL PROTECTED]> writes: > I've seen a few reports that CVSup has suddenly started dumping > core on a segmentation violation under -current, but I need more > information. For starters, I would like to know whether the static > binary (ports/net/cvsup-bin) works or not under the very latest > -current on the i386. Could somebody please check that and report > back to the list? I can't sacrifice my i386 -current machine to the > cause right now. I don't have access to the machine right now, but I installed the cvsup-bin (both GUI and non-GUI versions) and both core dumped for me. Both versions were obtained from ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/binaries This is on the latest -current (as of 9PM Oct 4, 99). Running it under truss helps with the core dump, but runs out of swap space very quickly. Truss keeps complaining about free()'ing a pointer that does not point to allocated memory. If you want more details, I shall be happy to provide them this evening. Hope this helps, Regards, Rajappa -- <[EMAIL PROTECTED]> a.k.a. Rajappa Iyer.New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Palm syncing over USB on FreeBSD, any hopes?
[ I sent this message to pilot-link-devel and coldsync-users. I'm trying in freebsd-current and freebsd-hardware to see if I have better luck. -rsi ] So I've tried everything I could to sync my Sony Clie SJ10 (PalmOS 4.0) with FreeBSD 4.8-STABLE and 5-CURRENT including setting up ppp over ucom0 for netsync as David Desrosiers suggested in: http://lists.pilot-link.org/pipermail/pilot-link-general/2003-February/000896.html. No dice. When I use ucom, the device_probe_and_attach fails. The exact message is: ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 Coldsync doesn't work with ugen0 either. I turned on USB debugging and it seems like the failure point is when the FreeBSD USB driver tries to do a bulk read at the second end point on ugen0. I've been digging into the USB code, but am not sure how to fix it. Any suggestions? I'll be more than happy to help with any testing and debugging, but need a pointer in the right direction. Thanks, Rajappa -- <[EMAIL PROTECTED]> a.k.a. Rajappa Iyer. Absinthe makes the tart grow fonder. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Palm syncing over USB on FreeBSD, any hopes?
Antoine Jacoutot <[EMAIL PROTECTED]> writes: > On Tuesday 29 July 2003 19:24, Rajappa Iyer wrote: > > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 > > ucom0: init failed, STALLED > > device_probe_and_attach: ucom0 attach returned 6 > > Try this: http://www.lphp.org/popups/articleswindow.php?id=13 > > It's been working great for me since FreeBSD-4.7 (now running 4.8) with > a Palm m505. Unfortunately, this doesn't seem to work with the Clie. I get the same messages as above. The behavior is the same on 4.8-STABLE and 5.1-CURRENT. There was a note in the usb-bsd mailing list about this issue: http://groups.yahoo.com/group/usb-bsd/message/1645 Is this an accurate statement? Rajappa -- <[EMAIL PROTECTED]> a.k.a. Rajappa Iyer. Absinthe makes the tart grow fonder. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
