Re: sysinstall.8 Breaking buildworld
"David O'Brien" [EMAIL PROTECTED] writes:
On Thu, Jan 11, 2001 at 02:38:55PM -0800, John Baldwin wrote:
Erm, sysinstall can be used as a replacement for fdisk and disklabel,
both of which are in /sbin. In fact, in 4.2 the only tool you can
realistically use to splat a virgin disklabel onto a slice w/o weird
hoop jumping that isn't documented _is_ sysinstall. disklabel should
have that fixed by 4.3, however.
But disklabel/fdisk can't even accept MB's as a unit. Until they grow
the functionality of the NetBSD and OpenBSD versions of them, sysinstall
is really the only tolerable disk label manipulation tool our users have.
This includes those with a bummed /usr that needs to install a new disk
to get it back.
A full set of disklabel patches to support MB, GB, KB, %, and *
(everything not spoken for elsewhere) for sizes (and * for offsets to allow
disklabel to calculate them for you), etc are in Warner's hands. (I got
annoyed at it one evening...) Now, if Warner would commit them :-)
(Matt has looked at the patch also.)
They also have improved error checking, etc.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
In message [EMAIL PROTECTED] Randell Jesup writes: : A full set of disklabel patches to support MB, GB, KB, %, and * : (everything not spoken for elsewhere) for sizes (and * for offsets to allow : disklabel to calculate them for you), etc are in Warner's hands. (I got : annoyed at it one evening...) Now, if Warner would commit them :-) : (Matt has looked at the patch also.) I've looked at them, and I have found someone with more time than I have to review and commit them. They should be going in soon, unless there's problems that I've not encountered. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
In message [EMAIL PROTECTED] "David O'Brien" writes: : But disklabel/fdisk can't even accept MB's as a unit. Until they grow : the functionality of the NetBSD and OpenBSD versions of them, sysinstall : is really the only tolerable disk label manipulation tool our users have. : This includes those with a bummed /usr that needs to install a new disk : to get it back. I have patches in my tree from someone to do this the last time this issue came up. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Why does sysinstall have to move at all? Whenever I buildworld/installworld, I always go into release/sysinstall and do a make all install, as suggested in handbook/makeworld.html Why can't the man page be included and installed with this? Bap. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
If memory serves me right, "Crist J. Clark" wrote: I had some buildworld failures earlier this week. In src/share/man/man8 the Makefile includes code to get the sysinstall.8 manpage. Since the manpage lives in src/release, this requires that you CVSup src-release. I had not been. This broke buildworld which had worked in the past. sysinstall.8 is the only file in src-release that is required for a buildworld. It seems somewhat silly to me that you are required to grab the whole thing for that one file. OK...I was one of the people who (indirectly) pushed for this. In a nutshell, I (and, independently, several other people) noticed that the sysinstall(8) manpage never gets installed as a part of the binary distributions or by an installworld. (I got highly confused by this while rewriting some other parts of the documentation.) The solution was to make sure that an installworld installs this manpage. I made the change to the Makefile which makes sysinstall.8 and src-release optional. I included it in a reply to the PR that precipitated the change, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818 My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. A good counter-argument is that installworld doesn't touch /stand/sysinstall, and therefore shouldn't touch the manpage either. Idea: Maybe we need the release building process to do this instead? On all of my systems, the sysinstall binary came from a CD, and never got touched by any subsequent installworlds. Anyone have a good reason why everyone _must_ have src-release to buildworld? I never thought of trying to do a buildworld with anything less than src-all. I guess my counter question is: Anyone have a good reason to do buildworlds *without* /usr/src/release/? Bruce. PGP signature
Re: sysinstall.8 Breaking buildworld
My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. I think we should simply move the stupid man page into man8. It's a bit weird to have a man page and its utility live in seperate places, but the release/ directory in the hierarchy has always been a red-headed stepchild in any case. If I had it to do over, it would have all gone into /usr/src/sbin somewhere. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Crist J. Clark wrote: Anyone have a good reason why everyone _must_ have src-release to buildworld? No. Sorry. I kind of assumed people doing buildworlds would just get src-all. Pointy hat this way please... As I said in a reply to a private mail to Crist, I'll commit a fix for this tonight and MFC it soon. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Bruce A. Mah wrote: If memory serves me right, "Crist J. Clark" wrote: I had some buildworld failures earlier this week. In src/share/man/man8 the Makefile includes code to get the sysinstall.8 manpage. Since the manpage lives in src/release, this requires that you CVSup src-release. I had not been. This broke buildworld which had worked in the past. sysinstall.8 is the only file in src-release that is required for a buildworld. It seems somewhat silly to me that you are required to grab the whole thing for that one file. OK...I was one of the people who (indirectly) pushed for this. In a nutshell, I (and, independently, several other people) noticed that the sysinstall(8) manpage never gets installed as a part of the binary distributions or by an installworld. (I got highly confused by this while rewriting some other parts of the documentation.) The solution was to make sure that an installworld installs this manpage. I made the change to the Makefile which makes sysinstall.8 and src-release optional. I included it in a reply to the PR that precipitated the change, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818 My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. A good counter-argument is that installworld doesn't touch /stand/sysinstall, and therefore shouldn't touch the manpage either. Idea: Maybe we need the release building process to do this instead? On all of my systems, the sysinstall binary came from a CD, and never got touched by any subsequent installworlds. Anyone have a good reason why everyone _must_ have src-release to buildworld? I never thought of trying to do a buildworld with anything less than src-all. I guess my counter question is: Anyone have a good reason to do buildworlds *without* /usr/src/release/? The real fix is that sysinstall does not belong in /usr/src/release, it needs to move back into /sbin or /usr/sbin and be a part of the regular world build. Jordan, is there any reason why we keep sysinstall out of sync with world? We can still leave /stand on teh system, but having a 3.x sysinstall in /stand on a -current system is less than useless. Whereas having an up-to-date sysinstall in /sbin or /usr/sbin as well as an up-to-date sysinstall.8 manpage that doesn't require weird hacks to be installed would be useful. The new sysinstall isn't coming anytime soon and we both know that, so that is not a valid argument for not moving it. It used to live in /sbin, so my only question is which directory should it move to: /sbin or /usr/sbin? I will do all the legwork on this.. Bruce. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ PGP signature
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 09:29:45AM -0800, Bruce A. Mah wrote: [snip] My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. Bu-ut, as you point out... A good counter-argument is that installworld doesn't touch /stand/sysinstall, and therefore shouldn't touch the manpage either. I think getting the sysinstall binary and manpages out of sync, which is what the current configuration promises to do, is in itself a bug. Idea: Maybe we need the release building process to do this instead? On all of my systems, the sysinstall binary came from a CD, and never got touched by any subsequent installworlds. I had assumed that the 'release' target would do something like this which explains why I was so puzzled by this change. I now understand why some people wanted it. Anyone have a good reason why everyone _must_ have src-release to buildworld? I never thought of trying to do a buildworld with anything less than src-all. I guess my counter question is: Anyone have a good reason to do buildworlds *without* /usr/src/release/? When I was CVSup'ing over a phone line to a notebook PC with a 750MB HDD, I trimmed my supfile to only what I needed, no src-games, no src-kerberosIV, no src-kerberos5, no src-release, etc. But to reiterate, I think the best reason not to do this is the potential for getting /stand/sysinstall and sysinstall(8) out of sync on your system. That is Just Wrong. The manpage should only be installed when /stand/sysinstall changes. The fact that src-release is now required was just an annoyance since I lost a build before I tracked it down. I woulda got over it. ;) I had not even noticed the change on some builds over the weekend since I do ususally grab src-release. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 10:53:43AM -0800, John Baldwin wrote: On 11-Jan-01 Jordan Hubbard wrote: My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. I think we should simply move the stupid man page into man8. It's a bit weird to have a man page and its utility live in seperate places, but the release/ directory in the hierarchy has always been a red-headed stepchild in any case. If I had it to do over, it would have all gone into /usr/src/sbin somewhere. Let's put sysinstall back in sbin/ then. It _used_ to live there until someone moved it. :) -r--r--r-- 1 root src 62356 Dec 30 1995 /usr/cvs/src/sbin/sysinstall/Attic/sysinstall.c,v I had assumed that sysinstall was not part of the standard installworld for recovery purposes. That is, if a buildworld-installworld were to totally hose your system (but of course that _never_ happens), you would still have a reliable /stand/sysinstall uncorrupted by the errant installworld to aid in fixing things. Again, this is just what I assumed the reason for the design to be. And I have never actually used sysinstall to recover a hosed upgrade, I like the fixit.flp. But IMHO, either both /stand/sysinstall and sysinstall.8 get installed when building world or neither do. To me, that seems clear cut. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Let's put sysinstall back in sbin/ then. It _used_ to live there until someo ne moved it. :) I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Jordan Hubbard wrote: Let's put sysinstall back in sbin/ then. It _used_ to live there until someo ne moved it. :) I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. Yay! Thanks. Will do. :) - Jordan -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Crist J. Clark wrote: On Thu, Jan 11, 2001 at 10:53:43AM -0800, John Baldwin wrote: On 11-Jan-01 Jordan Hubbard wrote: My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. I think we should simply move the stupid man page into man8. It's a bit weird to have a man page and its utility live in seperate places, but the release/ directory in the hierarchy has always been a red-headed stepchild in any case. If I had it to do over, it would have all gone into /usr/src/sbin somewhere. Let's put sysinstall back in sbin/ then. It _used_ to live there until someone moved it. :) -r--r--r-- 1 root src 62356 Dec 30 1995 /usr/cvs/src/sbin/sysinstall/Attic/sysinstall.c,v I had assumed that sysinstall was not part of the standard installworld for recovery purposes. That is, if a buildworld-installworld were to totally hose your system (but of course that _never_ happens), you would still have a reliable /stand/sysinstall uncorrupted by the errant installworld to aid in fixing things. Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm Putting it in world wouldn't touch /stand, it would just add it to either /usr/sbin or /sbin and keep that copy updated. Again, this is just what I assumed the reason for the design to be. And I have never actually used sysinstall to recover a hosed upgrade, I like the fixit.flp. But IMHO, either both /stand/sysinstall and sysinstall.8 get installed when building world or neither do. To me, that seems clear cut. I vote for both, but not to touch /stand. We don't keep rm.1 in sync with /stand/rm, we keep it in sync with /bin/rm, so this seems to be the most consistent.. -- Crist J. Clark [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: [snip] Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, [592:~] ls -li /stand total 45250 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 -sh 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 [ 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 arp 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 boot_crunch 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 cpio 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 dhclient 3 drwx-- 3 root wheel 512 Jun 19 2000 etc 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 find 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 fsck 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 gunzip 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 gzip 29952 drwxr-xr-x 2 root wheel 1024 Jun 19 2000 help 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 hostname 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 ifconfig 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 minigzip 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 mount_mfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 mount_nfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 newfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pccardc 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pccardd 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 ppp 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pwd 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 rm 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 route 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sed 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sh 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 slattach 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sysinstall 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 test 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 zcat But it lives by many names. (Ignoring the directories.) Putting it in world wouldn't touch /stand, it would just add it to either /usr/sbin or /sbin and keep that copy updated. [snip] I vote for both, but not to touch /stand. We don't keep rm.1 in sync with /stand/rm, we keep it in sync with /bin/rm, so this seems to be the most consistent.. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Crist J. Clark wrote: On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. I'd prefer it in /usr/sbin, some of my root partitions are only 32MB, and that's not big enough at the moment. If your /usr is hosed to the extent you can't mount it you've probably got more problems than sysinstall will help you with. But that's just my opinion. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
If memory serves me right, Ben Smithurst wrote: yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. The thing in /stand is a crunchgen(8) binary. sysinstall itself is (chug, chug) 850K. After being stripped, it's 798K: 1616 -rwxr-xr-x 1 root wheel 817416 Jan 11 14:14 sysinstall Bruce. PGP signature
Re: sysinstall.8 Breaking buildworld
Jordan Hubbard wrote: Let's put sysinstall back in sbin/ then. It _used_ to live there until som eo ne moved it. :) I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. We cannot repo-copy it to src/sbin - there is a copy there already. We could blow the old one away and lose the history (RELEASE_2_0 and earlier) but I guess that is no big deal these days. Personally I would prefer it in src/usr.sbin/sysinstall and have it dynamically linked. The release crunchgen can still take the .o's and make the giant /stand version.. dynamic: 390769 shared: 892921 On the other hand, if we had the static version in src/sbin, we could have a "LINKS+= /sbin/sysinstall /stand/sysinstall" and blow away the old installed version with each make world. This would avoid POLA with people following old instructions to run /stand/sysinstall. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. This, however, is merely "post-installation behavior" - if you rebuild and reinstall sysinstall in order to catch up with a bug fix to it, however, then this behavior goes away. - Jordan Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. I'd prefer it in /usr/sbin, some of my root partitions are only 32MB, and that's not big enough at the moment. If your /usr is hosed to the extent you can't mount it you've probably got more problems than sysinstall will help you with. But that's just my opinion. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Ben Smithurst wrote: Crist J. Clark wrote: On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. I'd prefer it in /usr/sbin, some of my root partitions are only 32MB, and that's not big enough at the moment. If your /usr is hosed to the extent you can't mount it you've probably got more problems than sysinstall will help you with. But that's just my opinion. Erm, sysinstall can be used as a replacement for fdisk and disklabel, both of which are in /sbin. In fact, in 4.2 the only tool you can realistically use to splat a virgin disklabel onto a slice w/o weird hoop jumping that isn't documented _is_ sysinstall. disklabel should have that fixed by 4.3, however. However, 800k is big for /sbin: ll /sbin/ | sort -n -k 5 ... -r-xr-sr-x 2 root tty 299956 Jan 9 08:25 restore -r-xr-sr-x 2 root tty 299956 Jan 9 08:25 rrestore -r-xr-xr-x 1 root wheel 424448 Jan 9 08:24 ipfstat -r-xr-xr-x 1 root wheel 484912 Jan 9 08:24 fsdb -r-xr-xr-x 1 root wheel 513748 Jan 9 08:25 vinum -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On 11-Jan-01 Crist J. Clark wrote: On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: [snip] Erm, many things live in both /stand and other places: ll /stand/ | wc -l 35 ll /stand/rm /bin/rm -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, Heh, no. That is a crunch. It has the object code for _all_ of those binaries in it. So /stand/rm will remove a file just like the normal rm: /stand/rm usage: rm [-f | -i] [-dPRrvW] file ... unlink file Putting it in world wouldn't touch /stand, it would just add it to either /usr/sbin or /sbin and keep that copy updated. [snip] I vote for both, but not to touch /stand. We don't keep rm.1 in sync with /stand/rm, we keep it in sync with /bin/rm, so this seems to be the most consistent.. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. It isn't that big: file $owd/sysinstall /usr/obj/usr/src/sbin/sysinstall/sysinstall: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped ll !:1 ll /usr/obj/usr/src/sbin/sysinstall/sysinstall -rwxrwxr-x 1 john src 899374 Jan 11 14:06 /usr/obj/usr/src/sbin/sysinstall/sysinstall The stripped version is about 840k, which isn't but so bad. That is if it lives in /sbin (which I vote for). The dynamic version if it goes in /usr/sbin would be smaller again. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 02:38:55PM -0800, John Baldwin wrote: Erm, sysinstall can be used as a replacement for fdisk and disklabel, both of which are in /sbin. In fact, in 4.2 the only tool you can realistically use to splat a virgin disklabel onto a slice w/o weird hoop jumping that isn't documented _is_ sysinstall. disklabel should have that fixed by 4.3, however. But disklabel/fdisk can't even accept MB's as a unit. Until they grow the functionality of the NetBSD and OpenBSD versions of them, sysinstall is really the only tolerable disk label manipulation tool our users have. This includes those with a bummed /usr that needs to install a new disk to get it back. On Thu, Jan 11, 2001 at 02:22:23PM -0800, Peter Wemm wrote: Personally I would prefer it in src/usr.sbin/sysinstall and have it dynamically linked. That would be OK, *once* our fdisk/disklable grows some modern [heck even late 1990's] user interface. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 02:22:23PM -0800, Peter Wemm wrote: I won't argue - move away! Just have one of the CVSmeisters do it as a repo-copy, of course. We cannot repo-copy it to src/sbin - there is a copy there already. We could blow the old one away and lose the history (RELEASE_2_0 and earlier) but I guess that is no big deal these days. It wouldn't be that much history (how about moving /home/ncvs/src/sbin/sysinstall/Attic to /home/ncvs/src/sbin/sysinstall/Old to preserve it??) Unfortuneatly in those days repo copies weren't done as well as now. :-(( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sysinstall.8 Breaking buildworld
I had some buildworld failures earlier this week. In src/share/man/man8 the Makefile includes code to get the sysinstall.8 manpage. Since the manpage lives in src/release, this requires that you CVSup src-release. I had not been. This broke buildworld which had worked in the past. sysinstall.8 is the only file in src-release that is required for a buildworld. It seems somewhat silly to me that you are required to grab the whole thing for that one file. I made the change to the Makefile which makes sysinstall.8 and src-release optional. I included it in a reply to the PR that precipitated the change, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818 Steven G. Kargl ealier, independently submitted the almost exact same thing, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24122 In a separate PR. Anyone have a good reason why everyone _must_ have src-release to buildworld? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
