Re: one or two errors in installworld
* From Andrew Lankford [EMAIL PROTECTED]
In the file /usr/src/share/sendmail/Makefile:
copies::
.for dir in ${CFDIRS}
${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 755 -d ${DDIR}/${dir}
.endfor
...according to the fine man page, the -d option should appear before both the
target directory and all the other options.
Also, it appears that INSTALL is defined as install -C, which I
don't think is appropriate for use with the -d option either. I
think I noticed a few install -C -C ... 's flash by before the
last attempted installworld ground to a halt.
Change the override of INSTALL in /etc/make.conf.
Andrew Lankford
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve
I've coined new words, like, misunderstanding and Hispanically.
-- George W. Bush, Radio-Television Correspondents Association
dinner, Washington, D.C., March 29, 2001
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Perl wrapper bad
* From Joshua Goodall [EMAIL PROTECTED] ... when I say bad I don't mean in execution. I mean that the idea of a redirecting wrapper for one special program seems to me an architectural wart that shouldn't be pushed on the userbase. With no gain except supporting improperly-shebanged scripts. We can use s/// in ports to fix shebangs, so there's not much excuse there, and I'd rather have a tool using autoconf find the Real perl than the wrapper, but to do this I have to deviate from the path I normally use to prefer system utilities over local ones: /bin:/usr/bin:/usr/ucb:/usr/gnu/bin:/usr/local/bin:/a/pkg/bin: \ /sbin:/usr/sbin:/usr/etc:/usr/gnu/sbin:/usr/local/sbin:/a/pkg/sbin Can you spot all the places Perl might be there? Can you now tell me which one a ``wrapper'' for the 'real' Perl should look? And what about where autoconf scripts should find perl? -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: patches for [x]install
* From Steven G. Kargl [EMAIL PROTECTED]
The first patch fixes install(1). The reamining patches
correctly document the breakage of rev 1.55 of xinstall.c
The last patch is wrong, the others are good, though a warning about the
overriding of flags might be nice until this is ACCEPTED behaviour by the
user community.
The third patch is wrong because there are things other than -C that one
might want to override INSTALL with, for example an INSTALL that uses a
replacement program that static relinks an executable being installed
to a partition where its dynamic dependencies are not satisfied.
I've known people to do similar.
--- usr.bin/xinstall/xinstall.c.orig Thu Jun 6 22:45:29 2002
+++ usr.bin/xinstall/xinstall.c Fri Jun 7 17:55:44 2002
@@ -173,8 +173,11 @@
argv += optind;
/* some options make no sense when creating directories */
- if ((safecopy || docompare || dostrip) dodir)
- usage();
+ if (dodir) {
+ safecopy = 0;
+ docompare = 0;
+ dostrip = 0;
+ }
/* must have at least two arguments, except when creating directories */
if (argc 2 !dodir)
--- share/examples/etc/make.conf.orig Fri Jun 7 18:01:36 2002
+++ share/examples/etc/make.conf Fri Jun 7 18:01:58 2002
@@ -73,9 +73,6 @@
# be the highest optimization value used.
#WANT_FORCE_OPTIMIZATION_DOWNGRADE=1
#
-# Compare before install
-#INSTALL=install -C
-#
# Mtree will follow symlinks
#MTREE_FOLLOWS_SYMLINKS= -L
#
--- share/man/man5/make.conf.5.orig Fri Jun 7 18:02:30 2002
+++ share/man/man5/make.conf.5Fri Jun 7 18:03:46 2002
@@ -130,14 +130,6 @@
.Dq Li +=
instead of
.Dq Li = .
-.It Va INSTALL
-.Pq Vt str
-the default install command.
-To have commands compared before doing
-the install, use
-.Bd -literal -offset indent
-INSTALL=install -C
-.Ed
.It Va LOCAL_DIRS
.Pq Vt str
List any directories that should be entered when doing
--- share/mk/sys.mk.orig Fri Jun 7 18:05:26 2002
+++ share/mk/sys.mk Fri Jun 7 18:06:13 2002
@@ -67,7 +67,7 @@
.endif
EFLAGS ?=
-INSTALL ?= install
+INSTALL = install
LEX ?= lex
LFLAGS ?=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve
I've coined new words, like, misunderstanding and Hispanically.
-- George W. Bush, Radio-Television Correspondents Association
dinner, Washington, D.C., March 29, 2001
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: patches for [x]install
* From Steven G. Kargl [EMAIL PROTECTED] J. Mallett said: * From Steven G. Kargl [EMAIL PROTECTED] The first patch fixes install(1). The reamining patches correctly document the breakage of rev 1.55 of xinstall.c I should have stated that if the first patch isn't acceptable, then the remaining patches should be applied. The last patch is wrong, the others are good, though a warning about the overriding of flags might be nice until this is ACCEPTED behaviour by the user community. The third patch is wrong because there are things other than -C that one might want to override INSTALL with, for example an INSTALL that uses a replacement program that static relinks an executable being installed to a partition where its dynamic dependencies are not satisfied. No. The third patch is correct (see below); otherwise I could set INSTALL to install -C QED. And I could set BINOWN to something bogus. Don't protect the user by removing functionality. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: patches for [x]install
* From Steven G. Kargl [EMAIL PROTECTED] J. Mallett said: * From Steven G. Kargl [EMAIL PROTECTED] J. Mallett said: No. The third patch is correct (see below); otherwise I could set INSTALL to install -C QED. And I could set BINOWN to something bogus. Don't protect the user by removing functionality. Well, if the first patch is acceptable, then we would be restoring documented functionality; otherwise, rev 1.55 of xinstall.c will remove functionality. Add the word meaningful before functionality in my statement, and realise that overriding such things should ALWAYS be something you can do. Consider cross-builds, and so on. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ps seems broken
* From David Wolfskill [EMAIL PROTECTED] Yeah, I know about kernel world being out of sync; that ought not be the case, as I just finished the usual buildworld, kernel, installworld, mergemaster sequence. For further evidence: g1-9(5.0-C)[1] uname -a ls -lio `which ps` file `which ps` FreeBSD g1-9.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #19: Wed Jun 5 09:34:03 PDT 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W i386 15995 -r-xr-xr-x 1 root wheel - 398740 Jun 5 09:52 /bin/ps /bin/ps: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, stripped g1-9(5.0-C)[2] ps -ax ps: pid tt state time command: keyword not found ps: no valid keywords g1-9(5.0-C)[3] This is due to me un-breaking seperation of keywords and not testing enough. Sorry. Give me five minutes. CVSup was started at 0347 hrs. PDT against cvsup14.freebsd.org; had finished by 0355 hrs. PDT. More details available on that score should they prove of interest. I'll poke around see if I can see what's broken, but thought that mentioning this might be of use. Cheers, david -- David H. Wolfskill[EMAIL PROTECTED] Trying to support or use Microsoft products makes about as much sense as painting the outside of a house with watercolors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ps(1) -o peculiarity in CURRENT
Aphex% ps -ouser= ?? jmallett jmallett jmallett And then on STABLE: ps -ouser= flata flata flata flata flata And with a header provided: ps -ouser=WHO WHO flata flata flata flata flata However on CURRENT: Aphex% ps -ouser=WHO ?? jmallett jmallett jmallett -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ps(1) -o peculiarity in CURRENT
* From Cyrille Lefevre [EMAIL PROTECTED] On Tue, Jun 04, 2002 at 03:13:21PM -0700, J. Mallett wrote: Aphex% ps -ouser= ?? jmallett jmallett jmallett I remember to see something like that when a kernel dependent command, such as ps, is out of sync w/ the running kernel. did you upgrade your kernel recently w/o syncing your world ? also, are your world sources in sync w/ the kernel sources ? did you reboot since your last kernel/world installation ? nevermind, I fixed my own problem, seems to have been a side-effect of the malloc-me-harder weight loss plan. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getcwd() failed ...
* From Marc G. Fournier [EMAIL PROTECTED] I'm getting the following randomly while trying to do a 'make buildworld' ... library problem? Or something else that I'm not seeing? === gnu/lib/libstdc++ === gnu/lib/libstdc++/doc cd: getcwd() failed: No such file or directory *** Error code 2 Thanks ... Update sh. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
* From Matthew Dillon [EMAIL PROTECTED] No hold on a minute. Some of us believe that adding those extra braces and parenthesis makes the code a whole lot more readable. they are NOT gratuitous in the least, certainly not from my point of view! When you make the code more readable, you introduce further diffs, and you leave no reference against the original code of where the functional changes are. Either make the base code cleaned up by committing non-functional changes first, or commit against the base code your functional changes, and then clean it up. Otherwise, it's a pain in the ass to sort things out. And for what it's worth, I'm all for readability improvements in our code, I just also like to go and view diffs sometimes and try to figure out what's changed. But I think you're also right on the rule of thumb thing, if someone does not want to do this favor to everyone who might want to read diffs or annotate changes to the code and get something meaningful, that's fine. I've done it plenty of times myself. However, I tend to do that locally first, and then commit the harmless things as I go. If you ever look through one of my WIP repos (~jmallett/cvs on Freefall currently holds one, my sccs repo, as I did and do believe others should have easy access to it), I tend to piggyback a lot of stylistic nits, etc. as I go... But I don't think it's fair to do the merge like you're saying... But back to where this started, it's just a rule of thumb. Furthermore, it'd be nice if as people made stylistic changes for outside projects they committed them to the central repository, where applicable. Anyway, I'm out of paint. Good day. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
* From Matthew Dillon [EMAIL PROTECTED] : :When you make the code more readable, you introduce further diffs, and you :leave no reference against the original code of where the functional changes :are. Either make the base code cleaned up by committing non-functional :changes first, or commit against the base code your functional changes, :and then clean it up. Otherwise, it's a pain in the ass to sort things out. : :And for what it's worth, I'm all for readability improvements in our code, I :just also like to go and view diffs sometimes and try to figure out what's :changed. : :But I think you're also right on the rule of thumb thing, if someone does not :want to do this favor to everyone who might want to read diffs or annotate :changes to the code and get something meaningful, that's fine. I've done it Oh come on, that is not what I meant at all and you know it. What is this junk about 'not wanting to do this favor to everyone'? I never said that. I didn't even come CLOSE to saying that or infering that. It is complete and utter bullshit and a severe... nay, *EXTREME* twisting of what I said. I was twisting my own words, not yours. You missed the point entirely. Go back and READ WHAT I WROTE. I made it pretty damn clear. I was showing a parallel set of thoughts and points of my own. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Infinite 'make' loops while building ports
On Thu, May 23, 2002 at 03:46:01AM -0700, Shizuka Kudo wrote: You're right. The only reason it didn't show up several days before is that v 1.58 added the real path to MAKEFILE as mentioned in the commit log: Try with the current make(1) sources. -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve Vote for me for FreeBSD core or the cute little bunny gets it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make(1) patch to ReadMakefile() to use realpath(3)
Often I hear people complain about one lacking in FreeBSD's make(1), if an error is encountered in a Makefile, we only get the base of its name: what is passed to ReadMakefile(). This is confusing for people trying to debug Makefiles, I am told, and really, there's no reason not to always give the real path to what is passed to ReadMakefile(). Therefore, I would like to ask for review of the following patch to main.c http://people.freebsd.org/~jmallett/make.main.c.realpath.diff There is of course the edge case that Dir_FindFile will be used, and it will somehow give us something that is not a meaningful path. This is not all that likely, but if it is, I have a patch I use locally which tells Dir_FindFile to *always* use real paths. This bloats a buildworld log a tad, oh well, you might find it useful. I'm mostly concerned about getting the main.c patch reviewed and committed, but here is a patch for dir.c as well as main.c http://people.freebsd.org/~jmallett/make.realpath.diff One could easily argue though that the dir.c patch will represent an overhead increase withotu a real gain. Because I'm not sure of that, and because what sparked me digging out these patches from my local make(1) is the FreeBSD user community, I'm asking for thoughts, opinions, review, and flames from you guys, the FreeBSD -CURRENT users. If there's anyone who can blow a whole through this idea, or endorse it enough to make me commit it, it's you guys. Here's a small example of what this results in, with foo/Makefile being broken: Without these patches: ref5% make === foo Makefile, line 1: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /d/home/jmallett. ref5% You can see how one might be confused as to which Makefile that refers. With these patches: ref5% ~/jmake === foo /d/home/jmallett/foo/Makefile, line 1: Need an operator jmake: fatal errors encountered -- cannot continue *** Error code 1 Stop in /d/home/jmallett. ref5% Much clearer. Thanks in advance. -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve Vote for me for FreeBSD core or the cute little bunny gets it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make(1) patch to ReadMakefile() to use realpath(3)
On Sun, May 19, 2002 at 03:21:59PM +0200, Bernd Walter wrote: Why do people think that a realpath is always available? Because the manual page doesn't say it isn't. What is wrong with just extending using pwd? That won't handle . and .. and relative paths spanning symbolic links, which you may or may not want to see in the output, etc. And maybe optionally stripping .. and . elements if wanted. The ODE make(1) as seen in CMU buildtools4 did this by hand, there's no reason we couldn't either, except someone would likely come along and use realpath(3) in place of it at a later date. That's what I did to ODE. At least pwd doesn't break amd(8) pathnames. How does realpath _break_ amd(8) pathnames? I'm not very familiar with any functionality that would cause this. If realpath(3) gets broken, that sounds like we either need some new conditions in realpath(3), or we need to fix amd(8) paths. It became nearly impossible to use amd(8) today just because of all that realpath introduced breakage. To what end? More information is helpful. Thanks. -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve Vote for me for FreeBSD core or the cute little bunny gets it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make(1) patch to ReadMakefile() to use realpath(3)
On Sun, May 19, 2002 at 05:34:28PM +0200, Bernd Walter wrote: I even can't buildworld on another machine without taking care of realpath. If I don't enshure that the source has the same realpath on the machine to run installworld as it had on the machine where I did the buildworld it break. installworld does? How? The only possibility I can see here is that dependency rules might be bad because the full paths may differ, but that wouldn't affect installworld. And all that without a real benefit from blindly using realpath(3). Show me a canonpath(3) or something which will give the simplest symbolic i.e. a simplified full path given a relative or absolute path with all redundancies resolved, without resolving away any symbolic paths. I'm ``blindly'' using the only answer we have to a question: how can I get an absolute (thus unique) path to an object in the filesystem. I'm open to alternative ways of doing that, especially as I described canonpath(3) above. Thanks. -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve Vote for me for FreeBSD core or the cute little bunny gets it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make(1) patch to ReadMakefile() to use realpath(3)
On Sun, May 19, 2002 at 06:56:40PM +0200, Bernd Walter wrote: I'm ``blindly'' using the only answer we have to a question: how can I get an absolute (thus unique) path to an object in the filesystem. Forget it - it's not possible with FreeBSD (see below). I'm just a bit frustrated about all the brokenness with softlink handling I saw, without noticing that FreeBSD doesn't give you a chance to do it right. I really doubt there isn't a way to do it right somehow, stuff like this has been around forever. Consider how extensively @sys expansion was relied on by AFS, and so on. You just have to hide the physical path somehow. I'm open to alternative ways of doing that, especially as I described canonpath(3) above. After some digging it seems like it's worse. getcwd already returns a canonical path on FreeBSD, NetBSD and Solaris. Only HP-UX returns the accumulated chdir path. Very dissapointing. Look at getcwd_logical() in pwd.c -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve Vote for me for FreeBSD core or the cute little bunny gets it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make(1) patch to ReadMakefile() to use realpath(3)
On Sun, May 19, 2002 at 08:47:29PM +0200, Bernd Walter wrote: Look at getcwd_logical() in pwd.c Aha - but that does mean trusting $PWD. The only thing that can keep track of where we started vs. where we cd to is the shell, and so we'd have to trust what it says PWD is. A possible pseudo-solution would be to give our *build system* (note: NOT the make program) a .TOPDIR variable which would be intiailised to something sane to begin with, and build relative/logical paths on top of it, i.e. .TOPDIR + realpath(.) - (realpath(.TOPDIR) - .TOPDIR) To get the current directory. But damn that's messy, damn that's a lot of overhead, and I think at that point we're really stretching how much can be gained from such things. -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve Vote for me for FreeBSD core or the cute little bunny gets it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make(1) patch to ReadMakefile() to use realpath(3)
On Sun, May 19, 2002 at 01:21:49PM -0700, Terry Lambert wrote: Bernd Walter wrote: Why do people think that a realpath is always available? Because it would be really convenient if we could program without having to remember on line 17 what we did on line 3, because we have really, really short attention spans. No Terry, not quite the same thing. While we are at it, wouldn't it be nice if all locks just disappeared when we closed files, and all open files and memory allocations went away when our programs exitted? No, because then we'd get lazy programming style overall and expect const qualifiers to implicitly cast away in function arguments, etc. In fact, neither of those are particularly interesting or useful. Now, wouldn't it be nice if we had zero-copy one-to-many pipe file descriptor loaning. 8-). What is wrong with just extending using pwd? And maybe optionally stripping .. and . elements if wanted. At least pwd doesn't break amd(8) pathnames. It became nearly impossible to use amd(8) today just because of all that realpath introduced breakage. That's annoying. I guess it's because people would really like it to work, even though hard links make it completely impossible, unless you change a number of things in the kernel in some pretty serious ways. 8-(. That's right. Long story short there's no libc or kernel facility to do it, and there's no way to pull a canonical path out of a hat given . or getcwd(), unless any canonical path will do. -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve Vote for me for FreeBSD core or the cute little bunny gets it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/share/mk bsd.doc.mk bsd.docb.mk bsd.info.mk bsd.init.mk bsd.lib.mk bsd.libnames.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.prog.mk bsd.sgml.mk bsd.subdir.mk sys.mk
On Sun, May 05, 2002 at 10:05:18AM +1000, Bruce Evans wrote: On Fri, 3 May 2002, Kenneth D. Merry wrote: On Fri, May 03, 2002 at 22:00:05 -0600, Kenneth D. Merry wrote: The attached patch fixes it for me. I'm sure someone can come up with a cleaner way of fixing the problem. It doesn't seem to be very easy to fix. Kernel makefiles should not depend on anything outside of the kernel tree. Depending on bsd.kern.mk is bad enough. Nothing outside of it (except modules, which are arguably seperate) should be using bsd.kern.mk, should it? One could easily argue that such should be localised to sys/conf, and that way all you'd need to build would be src-sys, as far as cvsup collections go... And that way you will not end up using stale makerules in the default search path. Thoughts? -- [EMAIL PROTECTED] | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve I've never tried to give my life meaning by demeaning you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
