gemeral questions (noobish)

[mcassar]

On Saturday 02 August 2008 19:38:20 Michael Powell wrote:

> I can only speak to cvsup or csup (which I use) but I'd like to point out a
> very common mistake wrt either. It is a good idea to have two different sup
> files, as they will need to download different collections of material. For
> example this:
>
> *default release=cvs tag=RELENG_7_0
> src-all
>
> combination will pull down the system sources for the security updates to
> RELEASE. Read in the Handbook about the tags and collections.
>
> I keep a separate sup file for keeping the ports tree updated and the
> difference is here:
>
> *default release=cvs tag=.
> ports-all
>
> Please notice that if you use the "tag=." with "src-all" you will pull down
> HEAD, which is the "bleeding edge" of development and not what a beginner
> should be using. But when used with the ports "collection" you will get an
> up to date ports tree.

now this makes sense, i wasn't too sure from reading the handbook so i thought 
i'd play safe and use the example ports-supfiles, but then used the example 
stable-supfile instead of whichever is for release. lives and learns.

> > anyhow i think that only my nvidia driver instructions mentioned it
> > relies on what i think are system sources (kernel related - if i'm not
> > mistaken) - but i haven't touched that yet.
>
> Generally speaking before building something like the nvidia drivers using
> the ports system the best first step is to refresh the ports tree. With all
> dependencies tracked and updated you'll likely have more success. Notice,
> for instance, that the nvidia driver depends on having what we call
> the "linuxulator" installed. It'll do this for you but you may have to
> enter a line in your /boot/loader.conf to ensure the linux.ko kernel module
> gets loaded every time at boot. You will usually see some more instructions
> at the end if you need to do anything special. Also, be aware that the
> nvidia driver is only currently working with i386, _not_ amd64.

> Even if only using packages you should _still_ update the ports tree, as
> the package system relies on it for dependency tracking as well.
>
> > I hate to bother any further but have one thing to clarify about building
> > attempts - when building anything, if that's ok. I only have a basic
> > understanding of C so far, and can't really tell how critical warnings
> > are - such as undefined this and that, defined but not used...etc, when
> > building a
> > port.  should i stop those and see how i should fix them or let them
> > proceed as long as they're not errors? I can live with my current system
> > for now, but have a few things i need to update eventually.
>
> When you use ports and compile stuff, you may see all manners of warnings,
> errors, and sundry garbage spewing forth from the compiler. Most of this,
> most of the time, is benign and not something to get overly concerned about
> as it is fairly normal. The exception is if the build errors out and
> completely quits, and there is an error sequence that will indicate
> whereabouts it bombed. Sometimes ports do get broken and need fixing, but
> most ports have a person who maintains them. If/when many people see the
> same error someone usually notifies the port maintainer and he/she then
> looks into fixing it.
>
> But generally speaking, if the build completes and runs without segfaulting
> just ignore what you may have seen scrolling by while building. Most of the
> time it's just "noise".  :-)
>
> -Mike
>
with the nvidia-driver, i've tried both ways 
1-> using the ports tree off the install discs without updating (which has a 
ver 100...,, something and seems to work ok with xorg from packages) ,,,
2 -> after updating the ports tree (which has ver 173..something) and seems to 
work better if i update xorg from ports.
 
The thing is, this usually goes like dominos and ends up in updating one thing 
after another; and with at least 350 packages to update at once, i easily 
loose track and just hope for the best.

I've had different results from that with the system as a whole, generally 
with good improvements on one end, and some broken stuff on the other, but 
only seen a segmentation fault once, now that you mention it. (it was with 
firefox but only that one time - never happened before)

So overall i wanted to rule out those warnings with updates in general, know 
how critical they are and whether i needed to go through configuration files 
first and what not.

thanks for all the info - everything starts to make sense as you go.

mcassar    
>
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"