/usr/src/Makefile instructions
My professor told me about instructions being in /usr/src/Makefile for rebuilding my world. I feel better about following them because they are close to the command line to me and can't be out of date, right? I am looking at this list of makes: # check-old - List obsolete directories/files/libraries. # check-old-dirs - List obsolete directories. # check-old-files - List obsolete files. # check-old-libs - List obsolete libraries. # delete-old - Delete obsolete directories/files/libraries. # delete-old-dirs - Delete obsolete directories. # delete-old-files- Delete obsolete files. # delete-old-libs - Delete obsolete libraries. # I am wondering if I should try these out, or will it just be taken care of with the "cannonical" methods. I seem to have lots of big problems with my configuration.. I don't know. Things work, but dmesg has errors, and many ports fail and their makes, even if they succeed have errors and warnings. If I "delete-old-.." will I be messing things up? *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/Makefile instructions
On Fri, 2008-05-23 at 05:49 -0700, KAYVEN RIESE wrote: > My professor told me about instructions being in /usr/src/Makefile > for rebuilding my world. I feel better about following them because > they are close to the command line to me and can't be out of date, right? > > I am looking at this list of makes: > > # check-old - List obsolete directories/files/libraries. > # check-old-dirs - List obsolete directories. > # check-old-files - List obsolete files. > # check-old-libs - List obsolete libraries. > # delete-old - Delete obsolete directories/files/libraries. > # delete-old-dirs - Delete obsolete directories. > # delete-old-files- Delete obsolete files. > # delete-old-libs - Delete obsolete libraries. > # > > > I am wondering if I should try these out, or will it just be > taken care of with the "cannonical" methods. I seem to have lots > of big problems with my configuration.. I don't know. Things > work, but dmesg has errors, and many ports fail and their makes, > even if they succeed have errors and warnings. > > If I "delete-old-.." will I be messing things up? > No, it will "Delete obsolete directories/files/libraries", with the usual meaning of obsolete. You should only need to do this when moving to a new (major?) release. I've redirected this to questions@, as this seems more like a 'User question/technical support' rather than 'General technical discussion'. Please try to keep the mailing lists on topic. Cheers Tom signature.asc Description: This is a digitally signed message part
Re: /usr/src/Makefile instructions
On Fri, May 23, 2008 at 05:49:48AM -0700, KAYVEN RIESE wrote: > > My professor told me about instructions being in /usr/src/Makefile > for rebuilding my world. I feel better about following them because > they are close to the command line to me and can't be out of date, right? No. Any comments or documentation *can* be "out of date" or otherwise misleading or incorrect. > I am looking at this list of makes: Err.. that would be "make targets," yeah? > # check-old - List obsolete directories/files/libraries. > # check-old-dirs - List obsolete directories. > # check-old-files - List obsolete files. > # check-old-libs - List obsolete libraries. > # delete-old - Delete obsolete directories/files/libraries. > # delete-old-dirs - Delete obsolete directories. > # delete-old-files- Delete obsolete files. > # delete-old-libs - Delete obsolete libraries. > # > > > I am wondering if I should try these out, or will it just be > taken care of with the "cannonical" methods. I expect that depends a great deal on what your objectives are. If you are merely trying to keep a system up-to-date, you are (IMO) better off reading, then paying attention to changes in, /usr/src/UPDATING. If, on the other hand, you are curious about just what make(1) will do when told to make a given target, by all means experiment to your heart's content (on your own system(s)). But I encourage you to consider the utility of the "-n" flag to make(1). Well, that, as well as the value of good backup & restore procedures. > I seem to have lots > of big problems with my configuration.. I don't know. Things > work, but dmesg has errors, and many ports fail and their makes, > even if they succeed have errors and warnings. > > If I "delete-old-.." will I be messing things up? Hard to say without more information about your current configuration than is likely to fit in a message to the mailing list. If the complaints are sufficiently severe (note that the mere quantity of them isn't a relaible measure of this), you may be better off recording salient configuration information (e.g., what ports you tried to install), make a good backup (assuming there's data worth recovering), wiping the system clean, and starting over. It is certainly possible to mess a system up enough that recovery is problematic, at best. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpmFcMkftLhN.pgp Description: PGP signature
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, Tom Evans wrote: On Fri, 2008-05-23 at 05:49 -0700, KAYVEN RIESE wrote: I've redirected this to questions@, as this seems more like a 'User question/technical support' rather than 'General technical discussion'. Please try to keep the mailing lists on topic. That list is too busy. I find I don't have to unsubscribe to "hackers," and it doesn't seem as hard core to misinterpret what "hackers" are, than say "ports" or "acpi" I realized that "make delete-old" and "make delete-old-libs" are both part of the "cannonical," I guess because I am going RELENG_6_3 to RELENG_7 On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Cheers Tom *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/Makefile instructions
> On that note, was I given misinformation when I was advised > that it would be impossible to upgrade RELENG_6_2 directly to > RELENG_7 ? Close to implausible, perhaps? That would indeed be the case, unless you truly are longing for a major workout, either with mergemaster et al, or both with mergemaster and the ports. The former case, which assumes you don't have many ports installed, is often a no-brainer: install a fresh system. The latter case may be somewhat more complicated: install a fresh system for the least effort on your side, or go the update route if you need to keep your system up and usable during the process. I should note that I always took the update trail, and never regretted it afterwards (well, if only so slightly). For instance, my workstation lived through 5.2.1-R, 6.2-R, RELENG_6, and finally RELENG_7, all with the aid of cvsup. The process is straightforward, well-designed and easily executed (thanks to the developers), but problems often pop-up with ports (especially such messy ones as Gnome, etc) which take lots of time to correct. So, in summary, a sane person should probably go with clean system update. P.S.: whoever replies next, it's safe to drop hackers@ from CC: anytime now >Kayven Riese, BSCS, MS (Physiology and Biophysics) [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/Makefile instructions
KAYVEN RIESE <[EMAIL PROTECTED]> wrote: > Tom Evans wrote: > > I've redirected this to questions@, as this seems more like a 'User > > question/technical support' rather than 'General technical discussion'. > > Please try to keep the mailing lists on topic. > > That list is too busy. I find I don't have to unsubscribe to > "hackers," and it doesn't seem as hard core to misinterpret > what "hackers" are, than say "ports" or "acpi" Well, "hackers" usually means developers, i.e. people hacking on the FreeBSD code. Therefore I'm afraid I have to agree with Tom: Your questions should better go to the questions list. > I realized that "make delete-old" and "make delete-old-libs" > are both part of the "cannonical," I guess because I am going > RELENG_6_3 to RELENG_7 I always use "make delete-old", as instructed in the /usr/src/UPDATING file, and it has never bitten me. Please have a look at that file; the important part starts at the section titled "To rebuild everything". > On that note, was I given misinformation when I was advised > that it would be impossible to upgrade RELENG_6_2 directly to > RELENG_7 ? "Nothing is impossible!", as Dr. Farnsworth from the Futurama series used to say. :-) But seriously ... I think going from 6.2 to 7.0 should work fine. However, the official notion is that updates across major versions have to be supported only for the latest stable release. Any other configurations might work, but it's not guaranteed. If it fails, you're not expected to complain or ask for help, but instead try the officially supported way (i.e. first update to the latest stable on your existing branch, then update across the major version boundary). If that still fails, you may complain and ask for help. Note that it is IMPORTANT to rebuild *all* of your ports when you update from 6.x to 7.x. (This holds true for any major version update.) If you don't do this, you will get library dependency collisions, i.e. port A uses libc.so.7 and depends on port B, but port B still links against the older libc.so.6. Things will break sooner or later. That's why you should rebuild *all* ports after updating to 7.x. (You can keep older ports only if you are absolutely sure that they are not part of any dependencies, and never will be.) In your previous mail you mentioned: > Things work, but dmesg has errors, Would you please tell us what those errors are? We might be able to help you, but only if you tell us. > and many ports fail and their makes Again: Please post messages and everything relevant to the problems. There are really people on these lists that are willing to help, but we need as much information as possible in order to be able to help. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, [EMAIL PROTECTED] wrote: On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Close to implausible, perhaps? That would indeed be the case, unless you truly are longing for a major workout, either with mergemaster et al, or both with mergemaster and the ports. The former case, which assumes you don't have many ports installed, is often a no-brainer: install a fresh system. The latter case may be somewhat more complicated: install a fresh system for the least effort on your side, or go the update route if you need to keep your system up and usable during the process. I didn't really understand that and I don't understand why I am a bad person for spamming my idiotic thoughts on the matter, but in any case this is moot because I am up an runing RELENG_6_3 and making kernel after editing the stable-supfiles RELENG_6_3 to RELENG_7 let's all cross our fingers that communication has just happened. I should note that I always took the update trail, and never regretted it afterwards (well, if only so slightly). For instance, my workstation lived through 5.2.1-R, 6.2-R, RELENG_6, and finally RELENG_7, all with the aid of cvsup. The process is straightforward, well-designed and easily executed (thanks to the developers), but problems often pop-up with ports (especially such messy ones as Gnome, etc) which take lots of time to correct. I am feeling better about cvsup and even mergemaster nowadays. Thank you very much for your support. So, in summary, a sane person should probably go with clean system update. Is that what I am doing? Umm.. maybe not. I have all these errors that I don't understand and that people ignore but I have a browser and a terminal, so I feel like a functioning pile of carbon compounds. P.S.: whoever replies next, it's safe to drop hackers@ from CC: anytime now Nah.. hackers needs the publicity! Kayven Riese, BSCS, MS (Physiology and Biophysics) [SorAlx] ridin' VS1400 *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, [EMAIL PROTECTED] wrote: On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? pcm/mixer.c /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sndstat.c /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c /usr/src/sys/modules/sound/sound/../../../dev/sound/unit.c /usr/src/sys/module Close to implausible, perhaps? That would indeed be the case, unless you truly are longing for a major workout, either with mergemaster et al, or both with mergemaster and the ports. The former case, which assumes you don't have many ports installed, is often a no-brainer: install a fresh system. The latter case may be somewhat more complicated: install a fresh system for the least effort on your side, or go the update route if you need to keep your system up and usable during the process. awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/sym/../../dev/sym/sym_hipd.c ===> syscons (depend) ===> syscons/apm (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/apm/../../../dev/syscons/apm/apm_saver.c ===> syscons/blank (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/blank/../../../dev/syscons/blank/blank_saver.c ===> syscons/daemon (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/daemon/../../../dev/syscons/daemon/daemon_saver.c ===> syscons/dragon (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/dragon/../../../dev/syscons/dragon/dragon_saver.c ===> syscons/fade (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/fade/../../../dev/syscons/fade/fade_saver.c ===> syscons/fire (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/fire/../../../dev/syscons/fire/fire_saver.c ===> syscons/green (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/green/../../../dev/syscons/green/green_saver.c ===> syscons/logo (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/logo/../../../dev/syscons/logo/logo_saver.c /usr/src/sys/modules/syscons/logo/../../../dev/syscons/logo/logo.c I should note that I always took the update trail, and never regretted it afterwards (well, if only so slightly). For instance, my workstation lived through 5.2.1-R, 6.2-R, RELENG_6, and finally RELENG_7, all with the aid of cvsup. The process is straightforward, well-designed and easily executed (thanks to the developers), but problems often pop-up with ports (especially such messy ones as Gnome, etc) which take lots of time to correct. rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/sysvipc/sysvshm/../../../kern/sysv_shm.c ===> ti (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -sf /usr/obj/usr/src/sys/GENERIC/opt_ti.h opt_ti.h ln -sf /usr/obj/usr/src/sys/GENERIC/opt_zero.h opt_zero.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GEN
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, Oliver Fromme wrote: KAYVEN RIESE <[EMAIL PROTECTED]> wrote: > Tom Evans wrote: > > I've redirected this to questions@, as this seems more like a 'User > > question/technical support' rather than 'General technical discussion'. > > Please try to keep the mailing lists on topic. > > That list is too busy. I find I don't have to unsubscribe to > "hackers," and it doesn't seem as hard core to misinterpret > what "hackers" are, than say "ports" or "acpi" Well, "hackers" usually means developers, i.e. people hacking on the FreeBSD code. Therefore I'm afraid I have to agree with Tom: Your questions should better go to the questions list. ergo: because obviously I am a flumming idiot. I thought hacker was something you took eucalyptus fro. > I realized that "make delete-old" and "make delete-old-libs" > are both part of the "cannonical," I guess because I am going > RELENG_6_3 to RELENG_7 I always use "make delete-old", as instructed in the /usr/src/UPDATING file, and it has never bitten me. Please have a look at that file; the important part starts at the section titled "To rebuild everything". Actually, after composing this I kicked myself, because /usr/src/Makefile has clearly instructed me to do make delete-old after make installworld and I think I will throw caution to the wind and append -U to my subsequent mergemaster followed by make delete-old-libs > On that note, was I given misinformation when I was advised > that it would be impossible to upgrade RELENG_6_2 directly to > RELENG_7 ? "Nothing is impossible!", as Dr. Farnsworth from the Futurama series used to say. :-) Oh well. Water under the bridge. I expect to someday edit this to RELENG_7_1 or the like when freebsd.org says so and following the instructions in /usr/src/Makefile again. But seriously ... I think going from 6.2 to 7.0 should work fine. However, the official notion is that updates across major versions have to be supported only for the latest stable release. Any other configurations might work, but it's not guaranteed. If it fails, you're not expected to complain or ask for help, but instead try the officially supported way (i.e. first update to the latest stable on your existing branch, then update across the major version boundary). If that still fails, you may complain and ask for help. Interesting. No. Fascinitating. Captian Kirk, I believe this star will supernova in approximately 12 days, 13 hours, 34 minutes and 23.3425 seconds. Note that it is IMPORTANT to rebuild *all* of your ports when you update from 6.x to 7.x. (This holds true for any major version update.) If you don't do this, you will get library dependency collisions, i.e. port A uses libc.so.7 and depends on port B, but port B still links against the older libc.so.6. Things will break sooner or later. That's why you should rebuild *all* ports after updating to 7.x. (You can keep older ports only if you are absolutely sure that they are not part of any dependencies, and never will be.) My habit is to run cvsup standard-supfile followed by cvsup ports-supfile. IS that a dumb thing to do? In your previous mail you mentioned: > Things work, but dmesg has errors, Would you please tell us what those errors are? We might be able to help you, but only if you tell us. I told the ACPI folks and they told me nicely that my appropriate post was too much of a hassle to bother with. Some ding dong was attaching after the fact of the wing ding and the fact that the errors occured between the wing and the ding was irrelevant since the dong ding subsequent to the ding ding recalibrated the whosits in an adequate fashion before reaching single user mode. > and many ports fail and their makes Again: Please post messages and everything relevant to the problems. There are really people on these lists that are willing to help, but we need as much information as possible in order to be able to help. Best regards Oliver Well.. I reckon I mights a git up thah gumpshun whenis I's gonna get tootin' on sumptin that gits mah goat subsequently. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--*___ freebsd-hackers@freebsd.org mailing list http://li
